[[2209.03255] Goldfish: No More Attacks on Proof-of-Stake Ethereum](https://arxiv.org/abs/2209.03255) [[LMD-GHOST]] is brittle, and has had recent attacks and patching attempts [[Goldfish]] satisfies the properties required of a drop-in replacement for LMD-GHOST: - secure in synchronous networks under dynamic participation - reorg resilient - honestly produced blocks guaranteed inclusion - fast confirmation - expected confirmation latency independent of desired security level - subsampling validators can improve communication efficiency - composable with finality gadgets and accountability gadgets LMD-GHOST attacks exploit lack of locking mechanism/coordination among honest validators, since locking isn't compatible with dynamic availability/ [[dynamic participation]] # Introduction ## History of Attacks and Patches for LMD-GHOST Proceeds in synchronized slots, randomly executed leader proposes a block at tip of canonical chain committee vote for tip of canonical chain following LMD-GHOST fork choice rules Validator chooses the heaviest subtree, the largest number of unique latest votes Only latest vote cast by each committee member of previous slots considered First version subject to [[balancing attacks]] - [[Proposer Boost]] added as mitigation - Gives temp weight boost to new proposals to ensure committees vote for their slot's now heavier proposals - Balancing attacks still possible - Equivocation discounting added as a mitigation - Now it's too complex to get formal security proofs and see further attacks ## Requirements for LMD GHOST in the Context of Ethereum It's vulnerability is due to lack of coordination mechanism Classic BFT synchronize by requiring a quorum of votes to certify blocks Locking rule requires that honest validators lock onto ceritifed blocks and vote for them or their descendants Quorum not possible under dynamic participation **WHY CAN'T WE/WHY DOESNT the validator withdrawal period and joining announcement message allow for dynamic participation and locking? Could we not tell every new validator joining to say something, same with leaving, and require at any given step a response from 2/3? The issue would be if less than 2/3 are online due to a crash fault I guess.** [[dynamic participation]] formalized by [[sleepy model]] Possible that validators could selectively abstain from voting for certain blocks and behave like temp crash faults Look at PoS variants of [[Nakamoto Consensus]] Ouroboros, Snow White New block acts as vote in favor of ancestors Long time to confirm blocks Small number of blocks and long confirmation latency enable longest chain to serve as synch mechanism LMD GHOST supports fast confirmations - expected confirmation latency not depending on security parameter k Low failure probability without increasing latency Must satisfy [[Reorg resilience]] Whenever honest validator selected as proposer, its block eventually enters all ledgers output by honest validators ## Key Techniques of [[Goldfish]] Since longest chain protocols can't be reorg resilient and have fast confirmation because of too little votes spread across too much time, we need a committee that can create a quorum supporting honest proposals - absolute quorums incompatible with liveness under dynamic participation - dynamically available protocol must use relative weights to favor blocks with stronger support during fork choice We need slot structure with proposer and committee that votes using relative weights of quorums Goldfish employs following techniques **Message Buffering**: - Each validator required to buffer votes received from the network - Time the inclusion of these votes into its local view - Priority given to votes relayed by proposer - Leads to validators adopting view of proposer and voting in favor of proposed block - Honest proposals in canonical chain -> reorg resilience - Honest validator's won't immediately consider adversary's late votes, preventing adversary from swaying them and doing a balancing attack - Safety and liveness when *every validator votes in every slot* **Vote Expiry:** - During each slot, only votes from previous slot influence protocol behavior - Stale votes of offline validators can't support blocks conflicting with proposals of future slots - Reorg resilience and security under dynamic participation - Also allows for subsampling committees per slot - Only few messages need to be buffered and considered at any given time ## Properties Achieved by Goldfish - Provably secure - safe and live under dynamic participation and a network synchrony with adversarial network delay up to a known upper bound $\Delta$ - Reorg Resilient - honest proposals enter all ledgers output by honest validators - Optimistic fast confirmation - when participation is high and 3/4 validators honest, txs confirmed with constant expected latency independnet of k - Validator subsampling - resilience to adaptive corruption, improved comms efficiency - Compatible with finality and accountability gadgets - ebb-and-flow with beacon chain **GREAT INFO ABOUT MMR, MR** ![[Pasted image 20230929115711.png]] # Protocol Slots of 3$\Delta$ rounds Validator has a state block-vote-tree based on which it takes consensus decisions and actions buffer B of network messages that sit between network and consensus protocol Validator unpacks messages from buffer and merges into T in a way that preserves T's consistency Only happens at specific points $\Delta$ rounds into slot, each awake validator indentifies a slot leader and merges the bvtree proposed by leader into its bvtree 2$\Delta$ rounds in, each awake validator merges its buffer into its bvtree GHOST-Eph used as fork choice Starting at genesis, function iterates over a sequence of blocks from bvtree Selects as next block the child of the current block with the maximum number of validators that have cast a slot t vote for a block within the child's subtree Continue until reaches leaf Ignores votes from other than slot t in its decision ## Complete Goldfish Protocol 3 phases - propose, vote, confirm #### Propose Round 3$\Delta t$ Validator checks if its lottery ticket is winning block proposer If so: Temp merges bvtree with buffer identifies GHOST-Eph chain tip using slot t-1 votes Proposes its temp bvtree and a new block based on it #### Vote Round $3\Delta t+\Delta$ Leader for slot t identified Merges leading proposal's bvtree into its bvtree If it's winning vote lottery: runs GHOST-Eph using slot t-1 votes and votes for it #### Confirm Round $3\Delta t+2\Delta$ Validator merges its buffer into its bvtree Identifies GHOST-Eph chain tip using slot t votes Outputs confirmed ledger Includes transactions of blocks in GHOST-Eph chain that are from slots less than or equal to t - $\kappa$ In this phase, dreamy validators finally come back awake and do everything. Before this, they simply relay messages #### Key mechanism: Message buffering Ensures that if, in slot t, the leading proposal is honest, then all honest voters in t will vote for the proposed block Reasoning: In propose phase, the leader's temporary bvtree is a superset of all honest validators' bvtrees Thus, in VOTE, all honest validators adopt the leader's bvtree Vote expiry allows us to say: If, in slot t, all honest voters have voted into the subtree rooted at block B, *then* all honest voters in slot t+1 will also vote into the subtree rooted at B So we get [[Reorg resilience]] ### Goldfish with Accountability Gadgets Partially synchronous accountably-safe consensus protocol, with accountable safety resilience of n/3, determines checkpoints of Goldfish's output ledger Fork choice modified to respect earlier checkpoint decisions # Optimistic Fast Confirmations Reorg resilience is an advantage goldfish has over other protocols that use blocks as votes But the k-slot deep confirmation rule has the same latency in best and worst case We can add a fast-confirm phase to achieve constant expected confirmation latency under optimistic conditions (high participation and honest supermajority) Validators can confirm blocks proposed by honest leaders immediately In FAST-CONFIRM, validator merges its buffer into its bvTree Marks a block as fast confirmed if the votes for it at slot t are greater than 3n/4 In confirm, we output the higher of the fast confirmation and the normal k-deep standard confirmation Here's why we use an extra phase: - Whenever an honest validator fast confirms a block, all honest awake validators see the votes responsible for fast confirm by the time their bvtrees are updated for the last time in a given slot - Ensures fast confirmed block eventually enters the ledger in the view of all validators - Implies fast confirmations are safe Validators input only blocks standard confirmed into the finality gadget Ensures all validators agree on confirmation status of blocks input for checkpointing Prerequisite for liveness Otherwise, a block fast confirmed by one valiadtor may not be confirmed in the view of another for k slots - stalls checkpointing process for that block Fast confrimation reduces latency for available chain, doesn't impact finality Protocol is safe when both fast and standard confirmations are safe Live when one of the rules are live ## From LMD-GHOST to Goldfish In first iteration of LMD in Gasper, there were possible ex-ante reorgs and balancing attacks Prevent security even in full participation setting without subsampling Proposer boost mitigated. However, its not compatible with dynamic participation Lower adversarial tolerance than what's possible with message buffering ex-ante still possible with subsampling Because of consideration of votes from older slots