DLT Interoperability and More ⛓️#18 — Ethereum Proof-of-Stake under Scrutiny⛓️
In this series, we analyze papers on blockchain and interoperability.
This edition covers a paper on a paper that formalizes the post-merge Ethereum protocol.
➡️ Title: Ethereum Proof-of-Stake under Scrutiny
➡️ Authors: Ulysse Pavlof, Yackolley Amoussou-Guenou, Sara Tucci-Piergiovanni
➡️ Paper source: https://hal.uca.fr/hal-03906880/document
➡️ Background:
Quoting from the paper:
The main design goal is to keep using a Nakamoto-style consensus, i.e., a protocol that constantly creates blocks in a tree-like form and selects a branch as the current chain using a fork-chain rule. However, a new mechanism (called finality gadget) incrementally finalizes blocks in the chain as opposed to pure Nakamoto-style consensus. A finalized block is a block that is voted by at least two-thirds of validators. In a system with less than one-third of Byzantine validators, a finalized block is never revoked.”
The Ethereum blockchain combines two designs: a Nakamoto-style protocol that builds a tree of blocks (candidate chain) and a BFT finalization protocol, the finality gadget (Casper FFG), that finalizes blocks from the tree (creates a finalized chain). The fork choice rule to select the candidate chains (different views) is LMD Ghost.
More background can be found on the paper or in the official documentation: https://ethereum.org/en/developers/docs/
➡️ Contributions:
- The authors lay a formal ground for analysis of the Ethereum Proof-of-Stake (PoS) protocol, and describe the protocol with pseudocode.
- The authors propose a variant of the bouncing attack, that forces forks on the network with decreased probability of success.
💪 Strong points:
- This paper defines the background properties that Ethereum needs to provide. Furthermore, basilar concepts such as Slots, Epochs & Checkpoints, Validators, Committees, Votes, Attestations, Finalization, and others are explored.
- The finalization process is depicted in figures, which helps a lot in understanding the process.
🤞 Suggestions for improvement:
- It feels that if the authors provided some examples using the Beacon explorer, it would be easier to the reader to understand the different concepts. For instance, providing an example of an attestation (checkpoint vote + block vote) from a particular validator, in a particular slot: https://beaconscan.com/slot/5452511
🔥 Points of interest:
- The concept of view we explored in our paper is important to analyze the different attacks on the blockchain. In particular, attackers use the fact that validators have (temporary) different views on the canonical chain and attempt to prolonge these disparate views. Resolving such an attack is to resolve the disparate views to a consolidated one (where the merging algorithm is Ethereum’s LMD GHOST for outputting a finalized chain, instead of the simpler ones we explore in our paper).
- The substrate of this paper is based on a delicate equilibrium that Ethereum tries to obtain, with regard to the CAP theorem:
“As in any distributed system, blockchains are faced with the dilemma brought by the CAP-Theorem [13]. This theorem states that distributed systems cannot satisfy these three properties at the same time: consistency availability, and partition tolerance. Indeed, if network partitions occur, either the system remains available at the expense of consistency, or it stops making progress until the network partition is resolved to guarantee consistency. This means that no blockchain can simultaneously be available and safe. However, by maintaining the candidate and the finalized chain at the same time, Ethereum Proof-of-stake aims to offer both safety and availability. The candidate chain aims to be available but without guaranteeing consistency all the time, while the finalized chain falls on the other side of the spectrum, guaranteeing consistency without availability. Therefore, the finalized chain will finalize blocks only when it is safe to do so where the candidate chain will still be available during network partitions (caused by network failures or attacks). The only caveat here is that finalized chain grows by finalizing blocks of the candidate chain, which means that the properties of the two chains are interdependent. In particular to assure liveness it is necessary that the candidate chain steadily grows. This interdependence is a source of vulnerability that must be thoroughly analyzed.”
As such, this paper will explore this interdependency between the candidate(s) and the finalized chain.
- Finalization is done on finalized checkpoints. Checkpoints need to be justified before finalized. Let us have epochs A and B such that epoch A is justified. Justification happens between two epochs, by having a supermajority of nodes issuing a checkpoint such that the source is an epoch and the target another epoch. If the checkpoint comprises epoch A as source and epoch B as target, we say that epoch A has been finalized. The “gap” between epochs cannot be more than 4 for a finalization.
- The substrate for the proposed attack is as follows: “The Bouncing Attack exploits the fact that the candidate chains should start from the justified checkpoint with the highest epoch. It is possible for Byzantine validators to divide honest validator’s opinion by justifying a new checkpoint once some honest validators have already cast their vote (made an attestation) during the asynchronous period”.
- The attack is as follows:
🚀 What are the implications for our work?
Understanding Ethereum’s proof of stake protocol in detail helps build up reliable bridge solutions.
