this problem of Finalized is dedicated to the contextualization of a recent published article describing three possible attacks on Ethereum’s proof-of-stake algorithm.
tl; dr
These are serious attacks with formally vetted and technically simple mitigation. A solution will be implemented before the merger and I will not do it delay Merge timelines.
Forkchoice attacks, mitigations and schedules
There has been quite a bit of chatter recently about a new published article co-authored with a Stanford team and some EF researchers. This document made public three life hacks and reshuffles on the beacon chain consensus mechanism. without providing mitigations or contextualization of what this means for the next Ethereum Merge update. The document was published in an effort to better facilitate review and collaboration prior to pushing fixes to the mainnet. However, it did not provide context on the impact and mitigations. This left room for uncertainty in subsequent discussions.
Let’s get to the bottom of this.
Yes, these are severe attacks ⚔️
First of all, let’s clarify, these are serious issues that, if not mitigated, threaten the stability of the beacon chain. To that end, it is critical that fixes are implemented before the beacon chain takes over the security of the Ethereum execution layer at the merge point.
But with a simple solution 🛡
The good news is that two simple fixes have been proposed for branch choice: “proposer boost” and “proposer view synchronization”. Stanford researchers formally analyzed the proponents’ momentum (writing to follow shortly), it has been specified since apriland has even been implemented in at least one client. Synchronization of the proposer view also looks promising but is earlier in its formal analysis. As of now, the researchers expect the proponent’s momentum to land on the specifications due to its simplicity and maturity in the analysis.
At a high level, paper attacks are caused by over-reliance on the attestations signal, specifically a small number of adversarial attestations to tilt an honest view in one direction or another. This confidence is for good reason: certifications almost completely eliminate former post block reorganizations in the beacon chain, but these attacks show that this has a high cost, since before reorgs and other life attacks. Intuitively, the solutions mentioned above adjust the balance of power between certifications and block proposals instead of living at one extreme or the other.
Caspar did an excellent job of succinctly explaining both the attacks and the proposed solutions. Verify this twitter thread for the best tl; dr you will find.
And what about the merger? ⛓
Making sure there is a solution before the merge is a absolute necessity. But there is a solution, and it is easy to implement.
This fix targets branch choice only and is therefore consistent with the Merge spec as written today. Under normal conditions the fork option is exactly the same as it is now, but for attack scenarios the fixed version helps provide stability to the chain. This means that implementing a fix will not not introduce major changes or require a “hard fork”.
The researchers and developers expect that by the end of November, the push for proposals will be formally integrated into the consensus specifications, and that it will be available on the Merge testnets in mid-January.
Finally, I want to say a big thank you to Joachim Neu, Nusret Taş and David Tse, members of the Tzu Laboratory at Stanford, as they have been invaluable to not only identify, but also remedy, the critical issues discussed above 🚀
