*Basically* [[RLMD-GHOST]] with a 1-slot vote expiry period Brittle in asynchrony - if new votes are not receievd timely to replace expiring ones, blocks can be reorged (up to the latest checkpoint if used with finality gadget) ## Model Adversary is probabilistic poly-time algorithm that can leverage corruption, sleepiness, and network delay to undermine consensus Corrupted validators act in arbitrary and coordinated fashion for remainder of execution. Part of f set of corrupted validators Asleep validator don't execute protocol Messages sent between validators are delivered with a network delay that can differ for each recipient Before GST, message delays are arbitrarily adversarial. After, they're subject to the delay upper bound $\Delta$ (synchronous) Before GAT, adversary can set sleep schedule for honest validators. After, all honest validators are awake ### Consensus Security Deisderata *Security* - Ideally after a certain time. - Parameterized by $\kappa$, which in the context of Goldfish and longest-chain protocols, determines the confirmation delay for transactions - Consider finite time horizon $T_{hor}$ polynomial in $\kappa$ - $ch_{r}^i$ is the output ledger in the view of validator i at round r ![[Pasted image 20231010073844.png]] - One chain always the prefix of the other - All transactions received by an honest validator will be included at some point *Accountable Safety* - Provides trust-minimizing strengthening of safety *ebb and flow formulation*- Goldfish outputs dynamically available ledger so it can't satisfy accountable safety Similarly, it can't satisfy safety under a partially synchronous network Adding an accountability gadget can create a separate prefix ledger that gets accountable safety under partial synchrony AND stays consistent with the output of Goldfish *Ebb-and-flow formulation* - Accountable prefix has accountable safety resilience n/3 at all times - There exists a constant C such that $ch_{acc}$ provides n/3-liveness with confirmation time $T_{conf}$ after round max(GST,GAT) + C$\kappa$ - Dynamic Availability: under synchronous network in sleepy model, available ledger provides 1/2 safety and 1/2 liveness at all times - Accountable chain is prefix of available # Protocol Layout Slots of 3$\Delta$ rounds Uses VRF-based lotteries, where each validator receives a ticket for each time slot Can be multiple winning tickets ordered by increasing precedence A block consists of the tag 'block', the ticket (id,t), the opening to the block production lottery, hash committing to the new block's parent block and transactions 'txs', and a signature $\sigma$ binding together the block production opportunity and the block's content Vote consists of tag 'vote', ticket, opening to voting lottery, hash committing to the block voted for, and signature $\sigma$ binding voting opportunity and vote's content *block-vote-set (bvset)* is a set of blocks and votes, denoted by T T\[h] is the block $B\in T$ with H(B) = h Votes and blocks exchanges in two message types - Piece consists of a tag 'piece' and a payload x and is valid iff the payload is valid - Used to propagate blocks, abstract of Ethereum's p2p broadcast - If a validator doesn't have a matching block in T, it can't validate the piece and holds onto it until its validity or lack thereof is established Proposal is (propose, T, B, $\sigma$ ) Valid if its consistent on T, meaning $B_{0}$ is in T and for every vote and block in T the referenced target/parent block is also on tree A bvset T with IsConsistent(T) is a block-vote-tree (bvtree) Each validator maintains a bvtree T Uses it to take consensus decisions and actions Each validator maintains a buffer B Network messages 'sitting between' network and consensus Messages delivered regardless of sleep status, but picked up only once awake Upon picking up a valid, non-in-limbo message, the validator re-broadcasts and adds to buffer If its a proposal, validator re-broadcasts the block and votes as pieces, then adds those pieces to its own buffer Merge(T,$\mathcal{B}$) outputs largest bvtree T' that's a subset of the union of T and the pieces in $\mathcal{B}$ Only happens at carefully chosen points $\Delta$ rounds into a slot, each awake validator identifies a slot leader and merges the bvtree proposed by the leader into its bvtree 2$\Delta$ rounds into a slot, each awake validator merges its buffer into its bvtree GHOST-Eph fork-choice used to determine canonical chain Takes bvtree T and slot t as input, and finds canonical GHOST-Eph chain determined by the votes within T that were cast for slot t Ignores votes from other than slot t in its decision Three phases per slot: propose, vote, confirm **PROPOSE** Round 3$\Delta$t: - Validator 'id' checks if its lottery ticket is winning - If so: - temporarily merges its bv tree with its buffer - identifies GHOST-Eph chain tip using slot t-1 votes - proposes temporary bvtree and new block based on it **VOTE** Round 3$\Delta$t + $\Delta$: - Validator identifies the leader for slot t as any of the proposals with smallest precedence - Merges leading proposal's bvtree into its bvtree - Checks if its lottery ticket for voting is winning - If so: - identifies the GHOST-Eph chain tip using slot t-1 votes - Votes for it **CONFIRM** Round 3$\Delta$t + 2$\Delta$: - validator merges its buffer $\mathcal{B}$ into its bvtree T - Identifies GHOST-Eph chain tip using only slot t votes - Outputs as confirmed ledger: - Transactions of blocks in GHOST-Eph chain that are from slots k-deep in time (slots $\leq$ t-$\kappa$ ) Message buffering is key If leading proposal in slot t is honest, then all honest voters in t will vote for the proposed block In PROPOSE, the leader's temporary bvtree is a superset of all honest validator's bvtrees Thus in VOTE, all honest validators adopt that leader's bvtree Vote expiry ensures that: - If in slot t all honest voters have voted into the subtree rooted at some block B, then: - all honest voters in slot t+1 will also vote into the subtree rooted at B - Leads to [[Reorg resilience]] Every interval of k slots has at least one honest leading proposer - The prefix of that proposal stabilizes - And the proposal includes unconfirmed transactions - Leads to safety and liveness of k-deep confirmation rule ### Accountability Gadgets fork choice rule modified to respect earlier checkpoint decisions Partially synchronous consensus protocol with accountable safety resilience of n/3 determines checkpoints of Goldfish's output ledger # Optimistic Fast Confirmations - The above Goldfish protocol has reorg resilience as an advantage over protocols that use blocks as votes (longest chain) - However, the k-slots deep confirmation rule causes $\theta(\kappa)$ latency in both worst and expected case - Falls behind propose-and-vote style protocols that get constant expected latency - Introduce a fast confirmation rule and FAST CONFIRM phase - Get constant expected confirmation latency under optimistic conditions (high participation and honest supermajority) - Validators can confirm blocks proposed by honest leaders immediately, in the FAST-CONFIRM phase, under honest conditions - $\kappa$-deep still applies and guarantees liveness when optimistic conditions don't hold **FAST-CONFIRM** Slots now consist of 4$\Delta$ rounds and 4 phases, (PROPOSE, VOTE, FAST-CONFIRM, CONFIRM) FAST-CONFIRM at 4$\Delta$ + 2$\Delta$ - Validator merges its buffer into its bvtree T - Marks block B as fast confirmed if the number of votes for B at slot t with bvtree T is greater than or equal to 3n/4 + $\epsilon$n/2 for some $\epsilon$ > 0 - Updates $ch_{fast}^{id}$ to the highest fast confirmed block In CONFIRM, the highest of the fast confirmed chain and the k-deep prefix is outputted Reasoning for the extra $\Delta$ rounds, as opposed to running the fast confirmation rule in the CONFIRM phase: - Guarantees that when an honest validator fast confirms a block: - All honest validators see the votes responsible for fast confirm by the time their bvtrees are updated for the last time in a given slot (round 4$\Delta$t + 3$\Delta$) - Ensures the fast confirmed block eventually enters the Goldfish ledger in the view of all honest awake validators Require that validators only add blocks confirmed with k-deep to confirmation rule - Ensures all honest validators agree on the confirmation status of the blocks input to the gadget for checkpointing - Otherwise: possible that two validators could have different views about a block's confirmation status # Questions How can we know that there are over 3n/4 awake, honest validators? What are we comparing n to? Initial idea is to check how many validators have changed in between blocks and then if it's not more than a certain proportion we can go into turbo consensus mode