[Evolution of the Ethereum Proof-of-Stake Consensus Protocol - Part II - HackMD](https://notes.ethereum.org/@luca-zanolini/Skf98kZ_i) Will analyze Gasper's problems and present current solutions # Problems and Solution ### Problem: Balancing Attack Original version of Gasper has a liveness issue that could lead to loss of safety for dynamically available ledger [[balancing attacks]] *The other problems are not re-stated here, as they don't seem terribly relevant to SSF and the main point of this research* ### Problem: Ex-Ante Reorg [[Ex-ante reorgs]] Reorg is when a block that was part of canonical chain loses its place because a competing block beats it out Can happen naturally due to latency or maliciously Malicious reorgs allow for double-spending or frontrunning *ex-post reorgs:* adversary observes a block and attempts to fork it out Requires 51%+ of validators and staking power *ex-ante reorgs:* adversary attempts to fork out a future block unknown to the adversary at the start of an attack **Finality:** Situation where a fork-choice rule so strongly favors a block that it is mathematically impossible or economically infeasible for that block to get reorged Gasper prevents reorgs longer than 2 epochs, as everything else is finalized [[view-merge]] joins the view of the honest proposer with those of all the other honest validators before they cast a vote in their slot In slots with an honest proposer, all honest validators vote in favor of the proposal ## [[Goldfish]] Simplified variant of [[LMD-GHOST]] that implements view-merge and equivocation discounting *equivocation discounting* relies on all validators eventually recognizing equivocations and ignoring them by not giving them weight Dynamic participation Subsampling Provably secure and reorg resilient in synch networks with dynamic participation Implements vote expiry Implements a version of GHOST and GHOST-Eph for fork choice rule Ignores votes before slot t, hence the ephemeral in its name Uses VRFs to both decide voter and committees In high participation and honest supermajority, a fast confirmation rule can be added to allow validators to confirm honest blocks proposed at tip of canonical GHOST-Eph chains within the same slot At start of each slot: - Proposer merges buffered views into local view, determine their canonical chain, proposes and broadcasts a block extending it with their local view - Voters merge proposed view into local, cast a vote on the determined canonical chain - All awake validators then merge buffers into local view and run optimistic fast confirmation rule - Marks a block B as fast confirmed if their view G contains a subset G' of slot t votes by distinct validators for B such that more than 3/4 of the eligible voters of slot t voted for B - In this case, B and its prefix are output as the Goldfish ledger - If no block is fast confirmed, validators use $\kappa$-slots-deep confirmation rule, the slow one - That being said, validators don't roll back ledgers, and if a validator has previously fast confirmed a block within the last $\kappa$ slots, it continues to output that block - Finally, all awake validators merge their buffers into local view and output a ledger Goldfish guarantees the following properties: 1. [[Reorg resilience]] - Suppose the proposer is honest. Then the block proposed by that validator enters and stays in the canonical GHOST-Eph chain adopted by any honest validator at future slots 2. Dynamic availability - Under synchronous network in sleepy model, Goldfish ledger provides 1/2 safety and 1/2 liveness at all times One issue is no safety against asynchrony - One vote expiry means Goldfish can't tolerate a single slot in which all honest validators are asleep or in which they cannot hear from the other honest validators due to adversarial induced network delay ### [[RLMD-GHOST]] A single slot of asynchrony in goldfish can lead to failure that jeopardizes the safety of any previously confirmed block RLMD-ghost parameterizes the vote expiry period $\eta$ Implemented in the $\tau$ -sleepy model, allowing for more generalized and stronger constraints in the corruption and sleepiness power of the adversary Honest validators participating in slot t are always more than the adversarial + honest validators that actively participated during some slots before t and are no longer participating Slots of 3 rounds, each having a proposer that proposes a block All active validators vote after merging their view with that of the proposer Fork-choice rule is RLMD-GHOST, considers the last non equivocating messages sent by validators that aren't older than t - $\eta$ slots Resilient to asynchronous periods lasting less than $\eta$ - 1 slots Along with LMD-GHOST and Goldfish, part of [[propose-vote-merge]] family of protocols Structure of proposing phase, voting phase, and merge phase Proceed in slots of k rounds, each with a proposer Then all validators vote Last rounds are needed for [[view-merge]] synch Defined through fork choice rule to tell voters how to vote ### Path Towards Single Slot Finality Gasper takes between 94 and 95 slots to finalize blocks - significant portion of chain susceptible to reorgs Possibility to capture MEV from these breaks correspondence of honest and rational behavior Users have to choose between economic security and faster transaction confirmation RLMD-GHOST + finality gadget can create a secure ebb-and-flow protocol that can finalize one block per slot ![[Pasted image 20230912120947.png]] Head-votes represent votes cast w.r.t the dynamically available component Introduces a new type of vote, the FFG vote A tuple \[$C_{1},C_{2},v$] where C1,C2 are checkpoints where C1 prefixes C2, and v is the validator. Checkpoints are referred to as source and target FFG votes are links between source and target Head votes work the same as they do for any propose-vote-merge protocol FFG votes always use latest justified checkpoint as source Target is the highest confirmed descendant of the latest justified block, or the latest justified block itself if there is none ![[Pasted image 20230912121401.png]] When a proposer is honest, network is synchronous, and honest supermajority online, the proposal gets fast confirmed and then justified before the end of the slot **It follows a similar logic to Tendermints precommit then commit!** Moreover, if honest validators see the justification before the next slot, they'll never cast an FFG vote with an earlier source Therefore that block will never be reorged, even if the network later becomes synchronous **Block unreorgability is not known to observers by the end of the slot and no economic penalty can yet be ensured in case of a reorg** Rely on honesty assumptions Finality only achieved at the earliest after two slots For SSF in the sense that an honest proposal can be finalized within its proposed slot, then we need another FFG voting round OR have validators send a different type of message acknowledging the justification This is like finalizing the justified block They signal that in future slots they will never cast a FFG vote with a source from a slot earlier than t. Slashing condition can be attached when a FFG vote surrounds an acknowledged checkpoint