Ethereum’s Vitalik Buterin Dismisses Rumors About A New Vulnerability In The Upcoming Constantinople Fork

The Ethereum Constantinople upgrade has been on the way for a while now. However, members of the core Ethereum department team have postponed the upgrade twice due to some vulnerability issues. This is because they intend to make sure that the upgrade goes on successfully and the transition to the proof-of-stake consensus algorithm is smooth. As reported by, the core developers found a solution to the vulnerability that was detected by ChainSecurity. However, new rumors started circulating that the upgrade would come with a smart contract vulnerability that will allow hackers to change codes on the network.

Create2 Has Smart Contract Vulnerabilities?

The Create2 feature that is part of the EIP-1014, was designed to allow interactions with non-existent contracts. These addresses contain codes but do not exist on the chain. Some members of the ETH development community claim that this Create2 feature may leave the blockchain vulnerable to a serious attack from bad actors. This is because smart contracts could be coded to change addresses even after deployment. One developer asked if this feature makes any smart contract that is created after the Constantinople upgrade with a self destruct function more suspicious than before.

Ethereum (ETH) Price Today – BTC / USD

NamePrice24H %

Another developer, Jeff Coleman, said that the Create2 feature is counter-intuitive because redeployments allow developers to change the contract byte code since the address is no more than a commitment to the init code. He said that people need to know that the init codes are key in auditing. So, non-denominational init codes are vulnerable.

In Coleman’s opinion, actors who want to audit the code of other actors need to look for any weird phenomena. This is especially important when Create1 is combined with Create2 as Create2 has weak assumption when it comes to address identity irrespective of the nonce. In his words:

“When we consider where we want to end up, it would be to have all addresses contracted through the init code. This is why order-based addressing is more important than content-based addressing. Create1 is based on content-based addressing. If we get to a place where the Create2 is standard and get rid of self destruct, we may be able to throw out this idea of a contract nonce.”

Vitalik Buterin Debunks These Vulnerability Claims

Dismissing these claims, Vitalik Buterin talked about the long-term roadmap and the role of Create2. In his words:

“One thing we should keep in mind is that Create2 is important for the future. When you think about deletion and rent, this is something that can lead contracts to be in a state without a self destruct operation. This is something we intend to figure out in the next few weeks. However, it’s important to keep this in mind when progressing the ETH 2.0 sharding to a VM spec.”

Apart from the possible Create2 vulnerability, the developers also talked about a prospective independent company that would benchmark the trading of the ASIC algorithm called ProgPoW. All the Ethereum developers agreed to implement the new algorithm as a step forward to the eventual goal of migrating to the proof-of-stake consensus algorithm.

The Constantinople upgrade is now scheduled for the last week of February. Hopefully, the developers will not have any need to postpone it once again.

Do you think the possible vulnerability is a cause for concern? Share your thoughts in the comment session.


Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.