This year has proved to be a demonstration of just how “smart” smart contracts are in practice. I could say they are “not so smart”, but that misses the point. Executable contracts actually can be really clever, but they will never be perfect. Buggy software is normal, buggy software that involves financial transactions but cannot be corrected if buggy is, well, a problem.
The entire concept of Bitcoin and smart contracts is that once a transaction is entered on the blockchain it can never be deleted or altered. This is basically the key feature of cryptocurrency and “smart contracts” extend the pattern with unalterable code that is robotically executed as part of a transaction.
Basically, the blockchain is permanent, write-once memory, and “smart contracts” are permanent, write-once programs. (We’ll skip over the fact that the humans involved aren’t authenticated, which is a whole other kettle of fish.)
In most of life, we don’t generally use either memory or code that can never be modified. We need to update and fix data and software. All the time. (Pretty much my entire decades long career as a software engineer was issuing patches and upgrades.)
We now see the cryptocurrency community trying to simulate erasable memory on top of the blockchain. This isn’t easy to do, and, worse, violates the fundamental feature of the blockchain: any ability to “take back” or “revise” a transaction already on the chain has to ba anathema.
Two examples of this process have been discussed recently. Alyssa Hertig writes for coindesk that “Ethereum Bug Sends Smart Contracts Back to the Drawing Board”. The bug in question is actually in the implementation of one of the programming languages used for writing contracts—one of the links in the chain, which is sometimes overlooked. Remember, uniike conventional programs which can be erased or updated, the output of this compiler is put out on the blockchain and can never be changed or deleted. Even fixing the bug in the compiler can’t undo the damage already done.
The discussion of how to mitigate the problem would be funny if it weren’t so sad. One solution is to use “centrally controlled” contracts, which would allow you to modify the buggy contract. Huh? Why use a blockchain, if you have a central control? Just use a DBMS, people.
For decentralized contracts, there is little that can be done, except to put on time limits or, well, try not to make mistakes. You should “do a proper formal analysis of the bytecode of the contract.” (Tools to do this will be available Real Soon Now.)
How do we know that the formal analysis is correct?
Anyway, if you haven’t bailed out of using Ethereum contracts by now, you are not likely to pay any attention to anything I say anyway.
On the Bitcoin front, Hertig discusses a concept for an “Anti-Theft Feature” for transactions on blockchains. In this case, the goal is to be able to put Bitcoin in a “vault” where it is difficult to remove even if you have the key. If a thief gets your key, he will try to transfer your Bitcoin to his own accounts. The “vault” enforces a delay on this transfer, and allows a second key to cancel the transfer.
Putting on my Anthropologist hat, I note that Bitcoin is designed to emulate gold bullion, and this mechanism emulates the bank vaults used to slow the transfer of physical bullion. It seems that you can try to “disrupt” the age-old financial industry, but you often end up simply recreating it, piece by piece.
Unfortunately, implementing this simple concept violates the aforementioned immutability feature, and would require a hard fork, i.e., change to the code accepted by everyone. This may prove contentious.
Perhaps with Ethereum’s hard lessons in mind, Hertig inquired about these “covenants”:
Right. And the Titanic is trivially unsinkable, if steered correctly.
Cryptocurrency is said to be a “trustless” system, but these days you certainly have to place a lot of trust in the correctness of software.