Let’s start on a positive note.
Ethereum’s Constantinople upgrade was suppose to roll out on the 16th or 17th.
On the 1/15 ChainSecurity discovered a potential vulnerability if the upgrade were to be implemented as planned. ChainSecurity is an independent audit and not part of the Ethereum foundation. It is still part of Ethereum’s open community. It’s a good sign that the community was able to find a bug and react appropriately instead of going ahead to implement the upgrade.
This vulnerability also reveals the fact that Ethereum’s did NOT have the greatest foundation in its early stages of development. Even Vitalik Buterin, Co-founder and the lead architect of Ethereum, admitted on Reddit that a different approach (at the beginning of development) would have been better.
“All of the really nasty security issues that we had have been around the interactions between different components. The quadratic DoS attacks combined EVM memory and the call stack frame or reverts and the call stack frame, this potential threat arose because of interactions between the default gas in send, SSTORE gas costs and re-entrancy issues. So if you have N protocol features, there are N2 ways they could potentially break. I would say my personal takeaway from this is to be much more explicit about writing down invariants (properties guaranteed by the protocol) that we rely on so we can check against them when changing things.” (Reddit)
The last statement translates to - we should have clearly written down mathematical proofs and models for the protocol even before development.
The industry term for this is “Formal Verification”.
In the context of hardware and software systems, formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics. (Wikipedia)
Apparently, a functional programming language best suits this approach, but Ethereum uses a different species of programming language. Cardano on the other hand does use a functional programming language and did employ the formal verification approach. Indeed, Charles Hoskinson wasted no time pointed that out on twitter:
So what was this vulnerability anyway?
The best resource will be from the Medium article by ChainSecurity:
The upcoming Constantinople Upgrade for the ethereum network introduces cheaper gas cost for certain SSTORE operations. As an unwanted side effect, this enables reentrancy attacks when using address.transfer(...) or address.send(...) in Solidity smart contracts. Previously these functions were considered reentrancy-safe, which they aren’t any longer.
From: Constantinople enables new Reentrancy Attack (Medium)
The upgrade was going to lower the gas for storage operations among other things. This particular change would have made it possible for an attacker to steal money through an Ethereum smart contract - namely the PaymentSharer contract.
According to Toshitimes.com, “This vulnerability, if exploited, would allow malicious actors to repeatedly siphon ETH out of a smart contract through a bug similar to that which led to the DAO hack. “ (Toshi Times)
Ethereum has postponed the Constantinople upgrade so many times, it is not a surprise anymore. But these vulnerabilities keep reminding the community that a lot of work is still to be done if Ethereum is to sustain as a leader in the smart contract blockchain space.
Many will be referring to this bug as evidence that Cardano is a better blockchain. At the moment, we can at least say that Cardano had the better, more sound approach in laying its development foundation. If Ethereum does not reign in its complexity, it will likely become a victim of its own ambition and success.