Ethereum reveals new vulnerability, smart contracts are rolled back to prototype

Generally speaking, vulnerabilities in software are common, but if they happen to ethereum, it is a very tricky thing.

This week, Ethereum’s programming language Solidity was exposed to a vulnerability that has affected some specific smart contracts, and most of the affected contracts cannot be dismantled or changed.

In short, owners of decentralized smart contracts (contracts that cannot be controlled by a single owner) are powerless against this kind of vulnerability.

Two days after the vulnerability was reported, developers released a fixed version of the Solidity programming language, 0.4.4. However, the vulnerability affected some addresses and data types in these contracts, making it impossible for contract owners to upgrade.

The good news is that this vulnerability probably doesn’t affect many smart contracts.

Solidity language creator Christian Reitwiessner told CoinDesk he ran a “semi-automated” analysis of every program listed on etherscan and found that out of 12,000 contracts, only 4 were usable.

Reitwiessner said that there is no ether in these contracts, so they may be used for testing purposes. But it is worth noting that not all contracts will be displayed on etherscan. (There are currently 20多万contracts in Ethereum, and it is difficult to say whether the remaining contract funds are safe).

Overall, the current vulnerability is only a minor flaw compared to the one that occurred in The DAO project. However, it has also caused a lot of discussion in the cryptocurrency community.

For example, one social media observer said the bug could be the tip of the iceberg of potential vulnerabilities in smart contracts.

A radical idea to solve this problem is to upgrade Ethereum contracts in the near future so that contract owners can disable or change these problematic contracts. But there is a concern that doing so may mean depriving Ethereum of its decentralized nature.

Loi Luu, a PhD student at the National University of Singapore, said it would be a better option if ethereum users could learn how to deploy smart contracts securely in a decentralized manner.

Luu said:

“I personally don’t think it’s a good idea, it goes against basically everything smart contracts are designed to do. If Ethereum is a test network, let its smart contracts fail so people can learn from it.”

But Luu’s comments suggest that upgrading all contracts might not be a good idea, especially since Ethereum is still a new technology.

Fixed issues

Programs written in Ethereum high-level languages, such as Solidity or Serpent, are compiled into byte code before being added to the blockchain. The problem here is that it happens with the compilation technology.

To solve this problem, Reitweissner recommends that developers do two things: First, if compiling a new contract, developers need to upgrade to a new version of the Solidity language to avoid this vulnerability.

The second method is even more strange because it requires upgrading or restarting your deployed contracts, which is probably not something that anyone would choose to use for projects like Ethereum.

Reitwiessner laid out a proposal in which he proposed two types of contracts: centrally controlled , and decentralized , where no one has “special privileges.”

The first might provide some upgrade mechanism, or a way to remove funds from the contract.

The second is tricky. On the other hand, since untrusted Ethereum smart contracts cannot be dismantled or changed once they are deployed, if developers do not use a centralized smart contract from the beginning, then they are actually limited in what they can do.

However, Reitwiessner said there are steps developers can take to prevent similar problems like Solidity from happening.

“My recommendation for these types of contracts is to either make them short-lived to reduce the potential impact, or to perform proper analysis of the contract’s bytecode. We are currently developing tools to help them do this,” he said.

Looking ahead

Since the Ethereum original chain (ETC) uses the same set of rules as the ETH chain, it is also affected by this vulnerability.

But according to its main organizer Arvicco, developers are exploring the development of a new programming language to avoid more vulnerabilities.

Especially for the Solidity language, if another unstoppable vulnerability appears, it may affect other smart contracts in the future.

Reitwiessner noted that compiler bugs are always a possibility, and there could be other undiscovered vulnerabilities in Solidity or Serpent (ethereum’s other smart contract language).

However, he noted that this is the first serious vulnerability found in the smart contract language in more than two years of development.