In light of the chain split on Ethereum today as reported by Geth Core Developer Marius Van Der Wijden here, and the troubles being seen on other EVM networks, our solution remains to fix this in the E-Hardfork as explained in our original statement on the Geth 1.10.8 patch here.
As we explained there, the bug fixed in go-ethereum v1.10.8 affects smart contract execution in an extreme edge case, and therefore can be rolled out safely on the next hard fork, to ensure that all nodes agree on when the new rules come into effect.
Rolling out the fix without the hard-fork mechanism (which is what was done on some other EVM networks) can produce a consensus failure (due to different nodes using different rules) and is therefore unsafe. In the case of Celo due to IBFT consensus, such a consensus failure could result in a network stall rather than a chain split.
In the case of Ethereum, using a hard fork would not have helped, because they have multiple client implementations and therefore already had different nodes using different rules no matter which course of action was followed.
Given that fixing it safely requires a hard fork there were two options: an emergency hard fork or including it in the next regular hard fork. As explained in the forum post, we chose the second option due to the bug only affecting contracts specifically crafted to trigger it.
Feel free to reach out to the cLabs Blockchain team, either on this forum post or on Celo’s Discord server.
Given that it was exploited deliberately on Ethereum, isn’t it trivial for someone to simply deploy the same smart contract specifically designed to exploit the bug on Celo? What’s to stop this from happening in a block right now?
Do we know the exploit is possible on Celo? Has it been attempted on a local network just to make sure?
Are there any mitigation plans or a runbook for a stalled network? I believe it happened a few times in the testnet competition, but not sure if we restarted or fixed in place at the time.
@Thylacyne There is nothing stopping someone from trying this on Celo.
We at cLabs tried it on a local 4-validator network and the result was as expected: incorrect execution of the crafted contract, but no impact on the network. Further, by spinning up a patched node (i.e. a node using v1.3.2 but adding to it the fix from v1.10.8) today and trying to sync it to mainnet, we’ve now determined that someone already did this on Celo’s mainnet this morning in block 8498434!
Here, too, the effect was as we expected: the Celo network was unaffected, but patched nodes with the fix from v1.10.8 would be unable to sync past that block. This is in line with what we described in the original forum post on Tuesday, and confirms the soundness of deciding then to not roll out a patch in an unsafe manner.
Even though such a transaction has already taken place on the Celo network, it is still the case that rolling out the fix in a safe manner has to be done as part of a hard fork, which will be done in the upcoming “E” hard fork.