Ethereum is about to undergo one of the most important updates in its history with the rollout of version 2.0. However, the move from proof of work (PoW) to proof of stake (PoS) will not be a risk-free process. Researchers take stock of the situation.
Ethereum’s big upgrade
The Ethereum network, as we know it, ensures the functioning of its consensus via a proof of work mechanism, similar to that of Bitcoin. However, since its launch, developers, including co-founder Vitalik Buterin, have identified limitations to this model. Thus, as early as 2016, the Ethereum developer community is planning a transition from proof of work to proof of stake.
Since then, things have evolved. After several years of development, the transition to PoS has never been so close. In practice, it is planned by developers for the first quarter of 2022. Unfortunately, some researchers are starting to point the finger at this transition by highlighting several attack vectors.
Ethereum 2.0: the proof of stake at risk?
On October 19, Caspar Schwarz-Schilling, Barnabé Monnot, Aditya Asgaonkar of the Ethereum Foundation, Joachim Neu, Ertem Nusret Tas and David Tse of Stanford University published a scientific paper entitled “Three Attacks on Proof-of-Stake Ethereum”.
As the name suggests, this publication highlights 3 attack vectors that could endanger Ethereum 2.0.
A reorg attack
The first attack vector would allow a reorg attack to be performed, without necessarily having significant resources.
“The strategy shows that a block proponent who controls a single committee member on the same slot can successfully perform a reorganization of the chain.”
This attack would take place in four steps:
- At the beginning of an n+1 slot, the attacker would create a block privately based on the previous n block. Because the block is private, honest validators would not see it and would attest that the head of the chain is block n ;
- At the beginning of the next slot (n+2), an honest validator would propose block n+2. At the same time, the attacker would publish his private block and attest it for slot n+2. As a result, the 2 blocks would be in conflict, as they would share the same parent block ;
- As the attacker’s block would have its attestation and would have more weight by its anteriority, honest validators would consider it as the head of the chain;
- At the beginning of slot n+3, a new honest validator would propose a block n+3, pointing to block n+1 as its parent (the attacker’s). This would orphan block n+2, bringing the reorg attack to its conclusion.
Note, however, that this entire attack can only be performed if the network has no latency, which is very unlikely. The paper concludes that this is a “non-trivial, but practically feasible problem”.
Unfortunately, all of the actions described above would not be considered fraudulent and therefore would not incur any penalty (slashing), leaving the attacker free to repeat as many times as he wants until completion.
A balancing attack
The second attack vector identified is a so-called balancing attack. The objective of this attack is to block the consensus mechanism of Ethereum 2.0.
In practice, this attack has 2 main steps:
- Malicious block proposers would propose 2 competing chains, named Left and Right ;
- The proposers would maliciously vote for the 2 chains in order to direct the vote of the honest validators. The attackers would make sure to maintain a tie between the 2 channels in order to keep the system equal and block the consensus.
Since the validators would not be able to agree on which chain to choose, the consensus would be blocked until resolution.
Once again, this attack requires preparation and perfect timing. Although it is possible in practice, there is no guarantee that it will be possible to carry it out in real conditions, with the several thousands of validators on the network.
Again, these actions would not be susceptible to punishment by the network. This again leaves the attacker free to persevere until the attack takes.
A combination of the first 2 attacks
The ultimate attack would be to combine the 2 attacks presented earlier.
“By combining the ideas of these two attacks, we now describe an attack in which the adversary can execute a long-range reorganization with infinitesimally low stakes and no network delay control.”
Fortunately, this publication came several months before the transition to Proof of Stake. Thus, developers can now take these risks into account in order to, why not, release a new hard fork that would provide patches to mitigate the risk of attacks.
Recently, the Ethereum 2.0 network had its first hard fork with the deployment of the Altair update. First of a long series, this one could well be followed by another one, following the revelations of this publication.