Vitalik Buterin explains security issues following delayed Constantinople fork

16 Jan, 2019 | Updated: 16 Jan, 2019
by Fifi Arisandi
Ethereum
Vitalik Buterin explains security issues following delayed Constantinople fork

Vitalik Buterin steps up and explains the reasons behind the delay of the long-awaited Constantinople hardfork.

Following the recent update on the delay of Constantinople hardfork, Ethereum’s co-founder, Vitalik Buterin steps up and explains the reasons behind the decision.

Read more: Ethereum's Constantinople hard fork has been delayed over discovered vulnerability

Communicating via Reddit, Buterin said that his team has been facing the “nasty security issues” related to the interactions between different components.

He mentioned that several potential threats, such as the quadratic DoS attacks combined with EVM memory and the call stack frame arise due to the interactions between the default gas in send, SSTORE gas costs and re-entrancy issues.

The issues potentially cause multiple break downs (N2 potential breaks for N protocol features), thus he thinks it would be better to write down invariants, meaning the properties guaranteed by the protocol more explicitly, so it can be checked while things are being changed.

In more understandable words, Taylor Monahan from Mycrypto.com puts the Constantinople saga this way:

- A developer wrote, audited, tested and deployed a smart contract in the past

- It is not possible to exploit the smart contract

- The Constantinople update goes live

- It is now possible to exploit the smart contract, due to the changes made in EIP1283

“Now, you see the words “potentially vulnerability” and “abundance of caution” being used. That is because, as of right now, there has *not* been a contract found on Ethereum mainnet or testnets that is vulnerable (besides proof of concept ones). And people have been looking hard,” she added.

Answering the question on why it's just found out, Monahan said, "It isn’t found by auditing the EIP or Geth or Parity. It is found by auditing every existing contract while that contract is on an already-updated chain. Or by researchers imagining what devs could write that could be inadvertently exploitable."

She then concluded that, “What this incident has shown is: the entire stack needs to be analyzed when reviewing EIPs, existing conditions & contract patterns being used have to be explored, needs imagination / research across all levels, not just technical reviews and audits.”

So, that’s the story of Constantinople. What will happen next? Stay with Chepicap for updates. 

Follow Chepicap now on Twitter, YouTubeTelegram and Facebook!

Poll

Are you disappointed with the delay?

(12 votes)

Add a comment

Check out the latest news

You will be logged out and redirected to the homepage