Bugs are a normal part of software, but in Ethereum they can be uniquely dangerous.
This may be the reason for a bug in the Ethereum programming language discovered this week that affects a certain style of smart contracts. Due to the way Ethereum works (it promises that applications will run exactly as programmed) most of the affected contracts cannot be accepted down or changed.
In short, decentralized smart contract owners (those that cannot be updated by an owner) cannot do anything to fix the bug.
Two days after Error Report was released, developers introduced a fix in Solidity version 0.4.4. However, the bug affects some of the addresses and data types in these contracts, so they still cannot be changed during the upgrade.
The good news is that the bug may not have affected many smart contracts.
Solidity inventor Christian Reitwiessner told CoinDesk that he had carried out a “semi-automatic” analysis of all Ethereum programs listed by a popular block explorer and found that only four out of 12,000 contracts could be exploited.
According to Reitwiessner, none of these contracts contain ether, as they were probably used for testing purposes. It should be noted, however, that not all contracts will show up in Etherscan, the selected block explorer. (There are more than 200,000 contracts in total, so it’s hard to say how secure the remaining contract funds are.)
Overall, it seems like a minor flaw compared to The DAO, the most notable example of a smart contract not working as intended. However, a discussion has started about what could happen with other major bugs, as not all smart contracts have a central owner who can update them if something goes wrong.
For example, one social media observer argued that it might be a “molehill on the side of a great mountain” with similar themes.
One of the more radical ideas for addressing this issue is to make Ethereum contracts updatable at short notice so owners can disable or change the code in the event of a mishap. However, the fear is that this could mean removing what makes Ethereum (or other decentralized platforms) unique.
National University of Singapore PhD student Loi Luu said it would be better for Ethereum if users learned how to deploy secure smart contracts the hard way on a decentralized basis.
Luu said:
“Personally, I don’t think that’s a good idea. It’s basically against anything smart contracts are designed for. When Ethereum is a beta network, let smart contracts fail and let people learn their lessons. “
While Luu’s comments suggest that making all contracts updateable may not be a good idea, there are some ways to prepare for potential future failures, especially while Ethereum is still a new technology.
Fix problem
Programs written in the high-level, easy-to-read languages of Ethereum such as Solidity or Serpent are compiled into byte-level code before being added to the blockchain. The problem here was that the technology was doing the compiling.
To fix the problem, Reitweissner recommended developers do two things. For one, developers have to update to the new version of Solidity when compiling a new contract to avoid the bug.
The second way to avoid the problem is to use the stranger example, as already implemented smart contracts need to be updated or defused – something you may not expect is possible with Ethereum.
Reitwiessner responded to this advice and explained that there are two types of contracts: centrally controlled and decentralized, in which nobody has “special privileges”.
The first type is likely to provide an upgrade mechanism or a way to remove funds from the contract.
The second type is more difficult. Since trusted Ethereum smart contracts cannot be removed or changed once they are deployed, there’s not much developers can do if they don’t use a centralized smart contract to begin with.
Reitwiessner said, however, that there are a few things that developers can do to protect themselves from future problems (like those with Solidity).
“My recommendation for such contracts would be to either keep them short-lived to minimize any potential negative impact, or to do a proper formal analysis of the contract’s bytecode. We are currently developing tools to support this, ”he said.
Upgradeable contracts
However, there are a few ways to get around this.
Hudson Jameson, head of external relations for the Ethereum Foundation, described a way to update smart contracts that could potentially be decentralized, arguing that adding a way to update live code was a necessity.
“The general feeling from our developers is that at this early stage it is important to have failovers in your code to safely disable or update high-value contracts,” he said.
Jameson described some potential smart contract fail-safes that allow owners to update their contracts even after they’re deployed to Ethereum, or where smart contracts can detect when something is wrong.
He said they don’t necessarily have to be centralized or under the control of an owner. For example, you could have a smart contract that limits how much of an asset can be withdrawn at one time.
“If an attacker tries to drain the contract on funds or assets, it can trigger a decentralized response such as locking out and notifying other people using the contract that they may need to withdraw their money,” he said.
He described a few other methods, including hacking detection, shutdown switches, and multi-signature transactions that require more than one person to sign a transaction before ether can be released.
I’m looking forward to
Smart contracts for Ethereum Classic (the group that split off from Ethereum due to ideological disagreements) are also affected by the bug as their blockchain is based on the same tools.
However, according to main organizer Arvicco, developers are looking for another long-term method to develop a programming language that is more resistant to errors.
“One of the possible ways is to shift the development of intelligent contract language from the object / procedural to the functional paradigm,” he said.
Regardless of the possible solution, the discussion implies that Ethereum developers should not just yet expect their smart contracts to work without potentially dangerous consequences, which may not be fully apparent to those who have already deployed code on the network.
At Solidity in particular, another unstoppable mistake could potentially impact other smart contracts in the future.
Reitwiessner noted that it is always possible for a compiler to introduce a bug, and that Solidity or Serpent (Ethereum’s other intelligent contractual language) have other undetected bugs.
However, he found that in more than two years of development, this was the first serious flaw found in smart contract language.
Construction image via Shutterstock
Comments are closed.