Ethereum Constantinople delayed after re-entrancy vulnerability found
Here's a simple, non-technical explainer of the newly discovered re-entrancy vulnerability.
Ethereum developers have decided to delay the Constantinople hard fork following the discovery of a potential vulnerability. The vulnerability is a potential re-entrancy attack, discovered by ChainSecurity, which the update would have opened up.
The issue isn't with the Constantinople code itself. As far as anyone knows that would still work exactly as intended.
Rather, some types of Ethereum contracts would have become vulnerable to a so-called "re-entrancy attack" under Constantinople.
Re-entrancy attacks are a way of stealing funds from vulnerable contracts. They're basically the blockchain equivalent of finding a way to repeatedly press the coin return button on a vending machine to keep getting money back.
There have been a few high-profile re-entrancy attacks in Ethereum's history. The DAO hack is the most famous example of a re-entrancy attack, followed by that time someone repeatedly re-entered SpankChain and plundered its BOOTY.
Re-entrancy attacks involve exploiting other contracts that send funds under certain circumstances. To perpetrate them, attackers write their own scripts that deliberately trigger those sending conditions in ways that the original script writer did not anticipate.
Why Constantinople opened up new vulnerabilities
There are different ways to write the part of a smart contract that instructs Ethereum to transfer funds, and different situations will often call for a different programming "word."
Depending on the exact word a programmer uses, the transfer function of their smart contract might work differently. For example, one word might transfer funds with a maximum gas budget of only 2,300 gas, while a different word might transfer funds without that budget restriction.
Using a word that imposes a gas budget was popular because of its relatively easy protection against re-entrancy attacks. When the contract is running on such a tight budget, an attacker can't afford to make it too much else. But when you reduce the gas costs for certain functions (which is undeniably a good thing on the whole), people can start sliding certain extra functions into contracts alongside the budget-restricted transferring words.
And Constantinople is set to reduce the gas costs for some functions.
So, before Constantinople, the contracts using those budget-limited transferring words didn't really need to worry about an attacker getting cheeky because the gas budget just wasn't there. But after Constantinople, there are some still mostly hypothetical situations where a sufficiently creative attacker could manipulate a send contract in a way that previously wasn't possible.
In this case, Constantinople will be dropping the cost of some storage functions from at least 5,000 gas to as low as 200.
This means contracts that used those specific gas-limiting words for its transferring functions, which also use certain storage-related words in specific ways, and that have gas budgets within a suitable range might have become vulnerable after Constantinople.
It would be a very specific contract which would become vulnerable, and after a relatively cursory scan of the main Ethereum blockchain, ChainSecurity did not find any such contracts. A more detailed scan is underway though.
What this all means
It means building a decentralised world computer is really, really complicated.
To clarify the situation
- This is not a bug or a vulnerability in Constantinople or Ethereum itself. It's a hypothetical way certain smart contracts could be vulnerable to attack.
- No vulnerable smart contracts have been found yet.
- The Constantinople update is being delayed to make sure there are no vulnerable smart contracts and to give programmers time to double check their work, not to change Constantinople.
Disclosure: At the time of writing, the author holds ETH.