Ethereum Bug Sends Smart Contracts Back to the Drawing Board

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, 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 that the bug may not have affected many smart contracts.

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 that can update them if something goes wrong.

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, in a decentralized manner.

Luu said:

"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 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.

Upgradeable contracts

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 fishy is going on.

He said they don't necessarily need to be centralized, or under the control of one owner. For example, you could have a smart contract that puts a limit on how much of an asset can be withdrawn at a time.

"So if an attacker attempts to drain the contract of funds or an asset, it can trigger a decentralized response like locking them out and notifying other people who use the contract that they may need to withdraw their funds," he said.

He described a few other methods, including hacking detection, shut-off switches and multi-signature transactions where more than one person needs to sign off on a transaction before ether can be dispensed.

Looking forward

Smart contracts on ethereum classic (the group that split off from ethereum due an ideological disagreement) are also affected by the bug since its blockchain relies on the same set of tools.

But according to its lead organizer Arvicco, developers are exploring a different long-term way of developing a programming language that’s more resistant to bugs.

"One of the possible ways is to move smart contract language development from object/procedural to functional paradigm," he said.

Whatever the possible fix, the discussion implies that ethereum developers shouldn't expect their smart contracts to work without potentially dangerous consequences quite yet, which may or may not be fully apparent to those who already deployed code on the network.

As for Solidity in particular, another unstoppable bug could potentially affect other smart contracts in the future.

Reitwiessner noted that it’s always possible for a compiler to introduce a bug, and it's possible that Solidity or Serpent (ethereum's other smart contract language) have other undiscovered flaws.

However, he noted that in over two years of development, this was the first severe bug found in the smart contract language.

Construction image via Shutterstock