Constantinople Explained: The Tom Cruise/Cyborg Edition
(All characters in this story, including Tom Cruise, are fictional. Any resemblance to actual persons or events is for entertainment purposes only.)
So, by now you know that the Constantinople fork was delayed. You’ve probably heard that the reason for the delay is a security issue that may leave some contracts vulnerable to attack. Before this even happened, you were all set and ready for the Ethereum update and knew that there was nothing you needed to do if your interaction with the blockchain is limited to storing/managing ETH and tokens.
But do you need to do anything now? What’s the vulnerability about? Will it affect you? Will they go ahead with Constantinople anyway? And, for the love of crypto, what is reentrancy?
Read on for the MEW explanation and be the coolest guy or gal at your next crypto gathering.
All contracts are accounts, but not all accounts are contracts
First of all, the vulnerability — which comes from Ethereum Improvement Proposal or EIP 1283 — only affects a specific type of contract. If you’re just holding ETH on an Ethereum address to which you hold the private key (either in the form of a hardware wallet, keystore file, mnemonic phrase, etc.), it shouldn’t affect you in any way.
However: ICOs, tokens, automatic payout mechanisms are all contracts, so if any of this sounds relevant — the contract vulnerability might be relevant to you as well.
That being said, as of this writing, no contract has been found “in the wild” (actually existing on the Ethereum mainnet) that would be susceptible to this attack. Right now it’s just a theoretical vulnerability, but it has the potential to become a very real catastrophe. The infamous DAO attack in 2016 also involved a reentrancy vulnerability. Hence, the abundance of caution exercised by the Ethereum Foundation.
Gone in 2.3 seconds
On to the actual problem! So, imagine a bank robber wants to rob a bank. They are able to get in and out of a vault, without being noticed, in 2.3 seconds. Yes, this is a very fast, possibly a Cyborg bank robber, or Tom Cruise. On second thought, definitely Tom Cruise, Cyborgs aren’t that fast.
However, the vaults in this particular bank at this time, without Constantinople, take 5 seconds to open. Even though the robber is very fast, the vault door is super slow. (Remember, this is in Tom Cruise/Cyborg time, so 5 seconds is slow. I mean, imagine a web page loading for 5 seconds. Really, set a timer and wait for 5 s..e..c..o..n..d..s. That’s slow.) Since just opening the vault door will take 5 seconds and the robber only has 2.3 seconds, they are out of luck!
Now, the bank wants to provide the best possible service to its customers. To this end, it optimizes the time of opening a vault to 0.2 seconds. (At this point, the bank hasn’t been acquainted with Tom Cruise and his amazing bank robbing powers.)
When vaults can be opened or re-opened in 0.2 seconds, 2.3 seconds are plenty of time for the robber to:
- Enter the bank under the pretense of depositing their own funds;
- Deposit their own funds and take them out;
- Use the rest of the time to steal other people’s funds — re-entering into vaults other than their own and picking up more money each time. Thus, reentrancy!
It turns out that making the entire bank’s operations more efficient also helped the attacker be more efficient.
In, and out, and back in again
We find the bank robber metaphor to be really helpful for understanding the issue, but if you’re game for a slightly more detailed technical explanation, read on!
(The following is only a proof of concept — illustrating one example. There might be different cases, so you may want to check out the original ChainSecurity post for more details.)
The vulnerability affects contracts that automatically split funds between two or more people, and then withdraw those funds from the contract to the designated recipients.
Such a contract requires a function to define the way funds will be split first, and another function to withdraw the funds to the respective addresses. Without Constantinople, the defining function needs a minimum of 5000 gas to execute.
An attack contract operates approximately like this:
- Attacker deposits funds into the vulnerable contract to “open” it — as you would have to enter your pin in the ATM to access the bank’s records at all;
- Attacker withdraws the funds they deposited;
- While the vulnerable contract remains open, attack contract redefines the split and withdraws more crypto — going back in to steal funds deposited by honest contract users.
The attack contract’s ability to re-enter the vulnerable contract and withdraw other users’ funds depends on the execution of a fallback function. The fallback function always has just 2300 gas, so for now, actions that require 5000 gas are safe because the attack function will not have enough “juice” to break in.
As Constantinople attempts to improve the efficiency of the entire Ethereum blockchain, the gas required for executing STORE (changing values of a variable) function can go down to 200 gas! This would be an enormous improvement for honest users, but it will also mean that the attack contract functions will gain access that they didn’t have before.
Trade-offs and compromises
Hopefully, this clarifies the Constantinople delay issue. Also, this situation highlights the enduring truth about optimizing processes — there is always a tradeoff… until better technology solutions make tradeoffs unnecessary.
Ethereum researchers and developers will continue to search for existing instances of contracts that will be vulnerable to reentrancy if Constantinople is implemented with EIP 1283. Even if they don’t find anything, it’s likely that caution will prevent them from including EIP 1283 in the next update, choosing user safety over user convenience — which, in a high risk space like cryptocurrency, is the wise thing to do. Besides, that just means that a better, more secure option for increasing Ethereum efficiency will be discovered for the next update!
If you want to dive into more detail with respect to what Ethereum core developers are considering as a solution, check out this all-hands call recording.
Always here to de-mystify crypto,
#teamMEW
