This question of Finalized is dedicated to the contextualization of a recent history article published describing three possible attacks against Ethereum’s proof-of-stake algorithm.
tl;dr
These are serious attacks with formally analyzed and technically simple mitigation. A fix will be deployed before the merge and will not be delay Merge timelines.
Forkchoice attacks, mitigations and delays
There has been a lot of talk recently about a new article published co-authored by a Stanford team and EF researchers. This article has made public three activity and reorganization attacks against the beacon chain consensus mechanism. without provide any mitigation or contextualization of what this means for the upcoming Ethereum merge upgrade. The document was released in an effort to better facilitate review and collaboration before introducing fixes to the mainnet. However, it failed to provide context on the impact and mitigation measures. This left room for uncertainty in the discussions that followed.
Let’s get to the bottom of it.
Yes, these are serious attacks ⚔️
Let us first clarify that this is serious issues that, if not mitigated, threaten the stability of the beacon chain. To this end, it is essential that patches are put in place before the beacon chain supports the security of Ethereum’s execution layer at the time of merge.
But with a simple solution 🛡
The good news is that two simple fixes to forkchoice have been proposed: “proposer enhancement” and “proposer view synchronization”. The reinforcement of propositions has been formally analyzed by Stanford researchers (article to follow shortly), has been specified since Apriland was even implemented at least one customer. Synchronizing submitter views also seems promising, but it is earlier in its formal analysis. For now, researchers expect proposal boosting to be included in the specifications due to its simplicity and maturity of analysis.
At a high level, the journal’s attacks are caused by an overreliance on the signal of attestations – particularly for a small number of contradictory attestations aimed at swaying honest opinion in one direction or another. This confidence is justified: the certificates almost entirely eliminate ex post blocking reorganizations in the beacon chain – but these attacks demonstrate that this comes at a high cost – ex ante reorganizations and other attacks of liveliness. Intuitively, the solutions discussed above regulate the balance of power between attestations and block proposals rather than living at one end or the other of the extremes.
Caspar did a great job succinctly explaining the attacks and proposed fixes. Check this Twitter feed for the best tl;dr you’ll find.
And what about the merger? ⛓
Ensuring a patch is in place before the merge is a an absolute must. But there is a solution, and it is simple to implement.
This patch only targets forkchoice and therefore complies with the merge spec as written today. Under normal conditions, the choice of fork is exactly the same as today, but in case of attack scenarios, the patched version helps ensure the stability of the chain. This means that deploying a patch does not not introduce radical changes or demand a hard fork.
Researchers and developers expect that by the end of November, proponent boosting will be formally integrated into the consensus specifications and will be operational on Merge testnets by mid-January.
Finally, I would like to warmly thank Joachim Neu, Nusret Taş and David Tse, members of the Tsé Laboratory at Stanford – as they were invaluable not only to identify, but also to remedy the critical issues discussed above 🚀
