Finalized No. 31: Analyzing Ethereum’s Proof-of-Stake Attacks

This edition of Finalized is focused on positioning a recently published paper that outlines three potential attacks on Ethereum’s proof-of-stake protocol.

In brief

These represent significant vulnerabilities that have straightforward, formally assessed solutions. A remedy will be implemented before the Merge and will not affect the timeline for the Merge.

Forkchoice attacks, solutions, and timelines

Recently, there has been a surge of discussion regarding a freshly published paper co-authored by researchers from Stanford and several from the EF. This paper disclosed three types of liveness and reorganization attacks targeting the beacon chain’s consensus system without offering any mitigatory measures or clarifying what this signifies for the impending Merge upgrade for Ethereum. The intention behind releasing the paper was to encourage review and collaboration before implementing fixes on the mainnet but it didn’t provide context regarding impacts and mitigations, resulting in some uncertainty in the discussions that followed.

Let’s break it down.

Indeed, these are serious attacks

To be clear, these are serious matters that pose a risk to the stability of the beacon chain if not addressed. Therefore, it is crucial to implement fixes before the beacon chain assumes responsibility for the security of Ethereum’s execution layer during the Merge phase.

However, there is a straightforward fix

The positive aspect is that two straightforward remedies for the forkchoice have been suggested — “proposer boosting” and “proposer view synchronization”. Proposer boosting has undergone formal analysis by Stanford researchers (a detailed write-up will be available soon), has been specified since April, and haseven been implemented in at least one client. Proposer view synchronization also shows potential but is still early in its formal evaluation. Currently, researchers anticipate proposer boosting to be incorporated into the specifications due to its straightforwardness and maturity in assessment.

On a conceptual level, the attacks described in the paper arise from an excessive dependence on the signal originating from attestations — particularly how a small quantity of adversarial attestations can skew an honest perspective one way or the other. This reliance is warranted — attestations predominantly prevent ex post block reorganizations in the beacon chain — however, these attacks underscore the significant costs involved — ex ante reorganizations and various liveness threats. Intuitively, the proposed solutions adjust the power balance between attestations and block proposals rather than positioning themselves at one extreme or the other.

Caspar has succinctly clarified both the attacks and the proposed remedies. For a concise summary, check out this Twitter thread.

And what’s the situation with the Merge?

It is an absolute necessity that a fix is implemented prior to the Merge. Fortunately, there is a straightforward solution that can be easily applied.

This fix is tailored exclusively for the forkchoice, thus aligning with the current Merge specifications. Under standard conditions, the forkchoice will remain unchanged, but in the presence of attack scenarios, the updated version will enhance chain stability. This means that introducing a fix will not create any breaking changes or necessitate a “hard fork”.

Developers and researchers expect that by late November, proposer boosting will be formally integrated into the consensus specifications, with it going live on the Merge testnets by mid-January.

Lastly, I want to express immense gratitude to Joachim Neu, Nusret Taş, and David Tse — members of the Tse Lab at Stanford — for their invaluable contributions in identifying and addressing the crucial issues discussed above!