This issue of Finalized is dedicated to the contextualization of a recently published paper describing three possible attacks on Ethereum's proof-of-stake algorithm.
tl;dr
These are serious attacks with a formally-analyzed, technically-simple mitigation. A fix will be rolled out prior to the Merge and will not delay Merge timelines.
Forkchoice attacks, mitigations, and timelines
There has recently been quite a bit of chatter around a newly published paper co-authored by a team at Stanford and some EF researchers. This paper made public three liveness and reorg attacks on the beacon chain's consensus mechanism without providing any mitigations or any contextualization of what this means for Ethereum's coming Merge upgrade. The paper was released in an effort to better facilitate review and collaboration before introducing fixes on mainnet. It failed however to provide context on impact and mitigations. This left room for uncertainty in ensuing discussions.
Let's get to the bottom of it.
Yes, these are serious attacks βοΈ
First of all let us make clear, these are serious issues that, if unmitigated, threaten the stability of the beacon chain. To that end, it is critical that fixes are put in place prior to the beacon chain taking over the security of Ethereum's execution layer at the point of the Merge.
But with a simple fix π‘
The good news is that two simple fixes to the forkchoice have been proposed -- "proposer boosting" and "proposer view synchronization". Proposer boosting has been formally analyzed by Stanford researchers (write-up to follow shortly), has been spec'd since April, and has even been implemented in at least one client. Proposer view synchronization also looks promising but is earlier in its formal analysis. As of now, researchers expect proposer boosting to land in the specs due to it's simplicity and maturity in analysis.
At a high level, the attacks from the paper are caused by an over-reliance on the signal from attestations β specifically for a small number of adversarial attestations to tip an honest view in one direction or another. This reliance is for a good reason -- attestations almost entirely eliminate ex post block reorgs in the beacon chain -- but these attacks demonstrate that this comes at a high cost -- ex ante reorgs and other liveness attacks. Intuitively, the solutions mentioned above tune the balance of power between attestations and block proposals rather than living at one end of the extreme or the other.
Caspar did an excellent job succinctly explaining both the attacks and proposed fixes. Check out this twitter thread for the best tl;dr you'll find.
And what about the Merge? β
Ensuring a fix is in place before the Merge is an absolute must. But there is a fix, and it is simple to implement.
This fix targets only the forkchoice and is therefore congruous with the Merge specs as written today. Under normal conditions, the forkchoice is the exact same as it is now, but in the event of attack scenarios the fixed version helps provide chain stability. This means that rolling out a fix does not introduce breaking changes or require a "hard fork".
Researchers and developers expect that by the end of November, proposer boosting will be integrated formally into the consensus specs, and that it will be live on the Merge testnets by mid-January.
Lastly, I want to give a huge shoutout to Joachim Neu, Nusret TaΕ, and David Tse -- members of the Tse Lab at Stanford -- as they have been invaluable in not only identifying, but remedying, the critical issues discussed above π