Bugs are a normal part of software, but on ethereum, they may be uniquely hazardous.
That may be the takeaway from an ethereum programming language bug found this week that affects a specific style of smart contract and, because of how ethereum works (it promises applications will run exactly as programmed), most of the contracts affected can’t be taken down or changed.
In short, owners of decentralized smart contracts (those that aren’t able to be upgraded by one owner) can’t do anything to fix the bug.
Two days after the bug report was issued by catageek, developers rolled out a fix in Solidity version 0.4.4, but the bug affects some of the addresses and types of data in these contracts so that they still can’t be changed with the upgrade.
The good news is decentralized smart contract use is, for now, limited.
Solidity creator Christian Reitwiessner told CoinDesk he ran a “semi-automated” analysis of every ethereum program listed by a popular block explorer and found that of 12,000 contracts, just four were exploitable.
Reitwiessner said none of these contracts have any ether in them, as they were likely used for testing purposes. But it’s worth noting that not all contracts are shown on Etherscan, the selected block explorer. (There are more than 200,000 contracts total, so it’s hard to say how safe the remaining contract funds are).
Overall, it appears to be a minor flaw when compared to The DAO, the most notable example of a smart contract not working as intended. However, it generated discussion about what might happen in the case of other major bugs given that not all smart contracts will have a central owner.
One observer on social media, for example, argued that it could be a “molehill on the side of a big mountain” of similar issues.
One of the more radical ideas for fixing this problem is to make ethereum contracts upgradeable in the near-term so that owners have some way of deactivating or changing the code in the case of a mishap. But the fear is that doing that could mean stripping away what makes ethereum (or other decentralized platforms) unique.
National University of Singapore PhD student Loi Luu said that it would be better for ethereum if users learned how to deploy secure smart contracts the hard way, centralized or decentralized.
“I personally don’t think its a good idea. It’s basically against everything smart contracts are designed for. If ethereum is a beta network, let smart contracts fail, let people learn their lessons.”
But while Luu’s comments suggest that it may not be a good idea to make all contracts upgradeable, there are some ways to prepare for potential future bugs, especially while ethereum is still a new technology.
Fixing the problem
Programs written in ethereum’s higher level, easy-to-read languages, such as Solidity or Serpent, are compiled into byte-level code before they are added to the blockchain. The problem here was with the technology doing the compiling.
To fix the problem, Reitweissner recommended that developers do two things. One, if compiling a new contract, developers need to upgrade to the new version of Solidity if they want to avoid the bug.
The second way to avoid the problem is the more curious example, since it requires upgrading or defunding smart contracts that are already deployed – something you might not expect is possible with ethereum.
Reitwiessner elaborated on this advice, explaining that there are two types of contracts: centrally controlled and decentralized, where no one has “special privileges”.
The first type probably offers some upgrading mechanism or a way to remove funds from the contract.
The second type is trickier. On the other hand, since trustless ethereum smart contracts can’t be taken down or modified once they’re deployed, there isn’t a lot that developers can do if they didn’t use a centralized smart contract from the beginning.
However, Reitwiessner said that developers can guard against future problems (like those with Solidity) by doing a couple of things.
“My recommendation for such contracts would be to either keep them short-lived, so that potential bad effects are small or do a proper formal analysis of the bytecode of the contract. We are currently developing tools to help in doing that,” he said.
There are some ways to get around this, however.
Ethereum Foundation external relations lead Hudson Jameson described a way of upgrading smart contracts that could potentially be decentralized, arguing that adding a way to upgrade live code is a necessity.
“The general feeling from our developers is that at this early stage it is important to have fail-safes in your code in order to safely deactivate or upgrade contracts that hold a lot of value,” he said.
Jameson described some potential smart contract “fail-safes,” where owners are able to upgrade their contracts even after they’re deployed to ethereum, or where smart contracts can detect when something…