Goldfish: No More Attacks on Ethereum?!

TL;DR

Goldfish is a new protocol that satisfies key properties required of a drop-in replacement for LMD GHOST, and is structurally similar to LMD GHOST, providing a credible path to adoption in Ethereum.

Abstract

The LMD GHOST consensus protocol is a critical component of proof-of-stake Ethereum. In its current form, this protocol is brittle, as evidenced by recent attacks and patching attempts. We propose Goldfish, a new protocol that satisfies key properties required of a drop-in replacement for LMD GHOST: Goldfish is secure in the sleepy model, assuming a majority of the validators follows the protocol. Goldfish is reorg resilient so that honestly produced blocks are guaranteed inclusion in the ledger, and it supports fast confirmation with expected confirmation latency independent of the desired security level. Subsampling validators can improve the communication efficiency of Goldfish, and Goldfish is composable with finality/accountability gadgets. Crucially, Goldfish is structurally similar to LMD GHOST, providing a credible path to adoption in Ethereum. Attacks on LMD GHOST exploit lack of coordination among honest validators, typically provided by a locking mechanism in classical BFT protocols. However, locking requires votes from a quorum of all participants and is not compatible with fluctuating participation. Goldfish is powered by a novel coordination mechanism to synchronize the honest validators' actions. Experiments with our prototype implementation of Goldfish suggest practicality.

Figures (7)

• Figure 1: Gasper gasper consists of two sub-protocols: LMD GHOST ('fork choice rule') and Casper FFG casper ('finality gadget'). The desiderata for Gasper were formalized by ebb-and-flowebbandflowaadilemmasankagiri_clc, which consists of security of the full chain under dynamic participation of validators, and accountable security of a finalized prefix.
• Figure 2: Ledger growth rate and average broadcast load of Goldfish as a function of block production lottery threshold, for experiments (\ref{['leg:experiment-thrb-len-measurement']}, \ref{['leg:experiment-thrb-comms-measurement']}) with $n=1000$, $\mathsf{thr}_{\mathrm{v}} = 0.1$, $\Delta=4\,\mathrm{s}$, under full honest participation. For the block production lottery, we expect the number of proposals per slot to be binomially distributed with mean $n\,\mathsf{thr}_{\mathrm{b}}$. The measurements fit the predictions for the probability of zero proposals in a given slot ($1-e^{-n\,\mathsf{thr}_{\mathrm{b}}}$, \ref{['leg:experiment-thrb-len-theory']}), and that the communication load is affine ($5723\cdot\mathsf{thr}_{\mathrm{b}}+4.472$ with coefficients to four digit accuracy, \ref{['leg:experiment-thrb-comms-theory']}) with the constant term accounting for votes.
• Figure 3: Ledger length / age of most recently confirmed block under fast (\ref{['leg:experiment-trace-exp4-D-0030-fast-len']}) / slow (\ref{['leg:experiment-trace-exp4-D-0030-slow-len']}) confirmation, and resulting broadcast load (\ref{['leg:experiment-trace-exp4-D-0030-comms']}), for Goldfish with $n=1000$, $\mathsf{thr}_{\mathrm{v}} = 0.1$, $\Delta=4\,\mathrm{s}$, $\mathsf{thr}_{\mathrm{b}} = 3/n$, $\kappa = 10$, block size $80\,\mathrm{kByte}$, different environments of dynamic participation (\ref{['leg:experiment-trace-exp4-D-0030-awake']}). When participation is above the fast-confirmation threshold of approx. $3n/4$ (\ref{['leg:experiment-trace-exp4-D-0030-fastquorum']}), transactions are confirmed swiftly ($4\Delta$, \ref{['leg:experiment-trace-exp4-D-0030-fast-age']}, , ), otherwise fast confirmation stalls. When participation is volatile (cf. $600\,\mathrm{s}$ to $950\,\mathrm{s}$, ), many honest validators are dreamy (\ref{['leg:experiment-trace-exp4-D-0030-dreamy']}, cf. protocol-goldfish-joining-procedure). Then, or when participation is steady but at a low level (cf. $1400\,\mathrm{s}$ to $1700\,\mathrm{s}$, ), effective participation (by honest validators who are neither asleep nor dreamy) is low. Slow confirmation ($4\Delta\kappa$ base latency, \ref{['leg:experiment-trace-exp4-D-0030-slow-age']}) takes place throughout, but since $\mathsf{thr}_{\mathrm{b}} = 3/n$, slow confirmation degrades (cf. experiment-thrb) when effective participation is low (cf. slots with no proposal around $650\,\mathrm{s}$ or $1600\,\mathrm{s}$, \ref{['leg:experiment-trace-exp4-D-0030-comms']}, lead to latency spikes, \ref{['leg:experiment-trace-exp4-D-0030-slow-age']}). Communication load is modest (\ref{['leg:experiment-trace-exp4-D-0030-comms']}).
• Figure 4: LMD GHOST has slots with two phases of $\Delta$ duration each. Each slot has a pseudorandomly elected proposer and a committee of voters. Propose: At the start of a slot, the proposer runs fork-choice and proposes a block extending the tip of the identified canonical chain. Vote: Midway into a slot, voters run fork-choice and vote for the block at the tip of the identified chain. * For greedy heaviest observed sub-tree fork-choice gasper (cf. ghost), conceptually, a validator walks the block tree in its view, starting at the genesis block, and at each block $B$, the validator proceeds to the child of $B$ whose subtree is heaviest, i.e., received the largest number of votes.
• Figure 5: Throughout the execution, validators buffer received proposals and pieces, and merge the blocks and votes contained therein into their bvtrees only as explicitly instructed. Goldfish has slots of three phases of $\Delta$ rounds each. Each slot has proposers (one of which will later be recognized as the slot's leader) and a committee of voters. Propose: At the start of a slot, proposers temporarily merge their buffers into their local bvtrees, and propose their temporary bvtrees and a new block based on it. Vote: One-thirds into a slot, voters identify the slot's leader's proposal, merge the proposed bvtree into their local bvtrees, and cast a vote based on their local bvtrees. Confirm: Two-thirds into a slot, all awake validators merge their buffers into their local bvtrees, and confirm a ledger based on their local bvtrees.

Theorems & Definitions (51)

• definition 1: Security
• theorem 1
• theorem 2: Security
• theorem 3: Reorg resilience
• lemma 1
• lemma 2
• lemma 3
• definition 2
• lemma 3
• proof : Proof of honest-leader-almost-everywhere