Buterin Addresses Concerns Regarding Potential Attack Vectors in Upcoming Ethereum Upgrade

  • Ethereum developers concerned about potential security vulnerabilities in new smart contract code.
  • Buterin addresses concerns from other developers regarding potential attack vectors once Constantinople is activated.

Several Ethereum (ETH) developers have expressed concerns regarding a potential security vulnerability in a new type of smart contract creation feature - which will be integrated into Ethereum’s codebase in its upcoming Constantinople hard fork upgrade.

In response to these concerns, Ethereum co-founder Vitalik Buterin stated, during a developers meeting on February 15, that the scheduled codebase modifications will not create vulnerabilities on the Ethereum blockchain . According to statements from other Ethereum developers, the “Skinny CREATE2” feature, which is part of the ethereum improvement proposal (EIP) 1014, could potentially introduce a security threat to the Ethereum network.

As CryptoGlobe covered, “Skinny CREATE2” allows users to interact with a smart contract that has not yet been issued on the Ethereum blockchain. As explained by Ethereum’s developers, “Skinny CREATE2” enables interactions with “addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code.” This feature may be exploited because smart contracts could be programmed to alter their address after they’ve been issued, according to several Ethereum developers.

Independent Blockchain Researcher Expresses His Concerns

Rajeev Gopalakrishna, an independent researcher on Ethereum and cybersecurity, has said that CREATE2 might have negative security implications for the Ethereum network. Gopalakrishna, who earned his Phd in computer science from Purdue University, explained that in certain cases, using the CREATE2 function might allow an attacker to replace a previously benign smart contract with a malicious one. Meanwhile, Jason Carver, an engineer at the Ethereum Foundation, has argued that potential attack vectors could be introduced by replacing a self-destruct contract with a newer version (by using CREATE2).

Notably, Gopalakrishna raised the following questions (earlier this month): 

Doesn’t this change a major invariant assumed by users today and introduce a potentially serious attack vector with CREATE2? Doesn’t this mean that any contract post-Constantinople with a selfdestruct [function call] is now more suspect than before?

"Non-Deterministic Init Codes Are A Problem"

Responding to these questions, Ethereum developer Jeff Coleman noted: 

"One of the things that is counter-intuitive about CREATE2 is that theoretically redeployments can change the contract byte code, because the address is only a commitment to the init code. People need to be aware that init codes are part of auditing, [...] that non-deterministic init codes are a problem.”

According to blockchain developer, Noel Maersk, the self-destruct function by itself may not have negative security implications. Maersk also argued that adding non-deterministic init (initialization) code to smart contracts issued on a CREATE2-enabled blockchain might potentially introduce attack vectors.

Moreover, Coleman pointed out that developers planning to audit code written by other programmers must look out for “weird phenomena ... especially if you combine CREATE2 with CREATE1, because the latter has a really weak assumption around address identity whatever the nonce is.”

Buterin's Comments On CREATE2, Ethereum's Long-Term Roadmap

Coleman suggested “throwing out the idea of a contract nonce” is possible if CREATE2 is set as the “standard” - while “getting rid of [the] self destruct” function completely. He stressed the need for “content-based addressing” of smart contracts rather than only relying on “order-based addressing” - “which is what CREATE1 is.”

Buterin also discussed the implications of CREATE2 and Ethereum’s long-term roadmap: 

The one thing we need to keep in mind is more for the future, when thinking about rents and deletion; that’s a way that can lead to contracts being in a state to being not in a state without a self-destruct operation ... It’s not something we need to figure out in the next few weeks, but it's still useful to keep in mind when getting the ETH 2.0 sharding to a VM (virtual machine) spec very soon.

Ether (ETH) Futures 'Likely' to Launch in 2020, Says CFTC Chairman

Heath Tarbert, the Chairman of the U.S. Commodity Futures Trading Commission (CFTC) has revealed he believes ether (ETH) futures contracts will be launched in 2020.

Speaking at a fireside chat during the first day of the DC Fintech Week, Tarbert revealed he believes ether futures contracts could soon launch, saying it’s “likely that you would see a futures contract in the next six months to a year.”

The CFTC, as reported, declared ether a commodity earlier this month and revealed the agency would be willing to approve ETH futures contracts. At the time, Tarbert said:

We've been very clear on bitcoin: bitcoin is a commodity. We haven't said anything about ether—until now. It is my view as chairman of the CFTC that ether is a commodity.

During the fireside chat, according to CoinDesk, Tarbert noted that to his knowledge no company has, so far, applied to launch ether futures contracts, even though the CFTC is open to approving such a product. Approval will, nevertheless, depend on the application itself.

Tarbert also revealed other cryptocurrencies may soon be seen as commodities, and there other crypto derivatives are coming soon. As there are thousands of cryptoasset out there, it’s unclear which he may have been referring to, if any.

The CFTC Chairman added that an asset can evolve from a commodity to a security and vice versa, although when asked he revealed there may not be a precedent to this happening. The Securities and Exchange Commission, he said, is the entity that determines when an asset is a security.

The SEC has notably been cracking down on initial coin offering (ICO) projects in the last few months, It recently filed an emergency action against Telegram for issuing its Gram tokens without registering with it, and earlier sued messaging app Kik for allegedly running an illegal securities offering that raised $100 million, in which it issued its KIN token.

Featured image by Chris Liverani on Unsplash.