Papers
Topics
Authors
Recent
Search
2000 character limit reached

SoK: Speedy Secure Finality

Published 23 Dec 2025 in cs.CR and cs.DC | (2512.20715v1)

Abstract: While Ethereum has successfully achieved dynamic availability together with safety, a fundamental delay remains between transaction execution and immutable finality. In Ethereum's current Gasper protocol, this latency is on the order of 15 minutes, exposing the network to ex ante reorganization attacks, enabling MEV extraction, and limiting the efficiency of economic settlement. These limitations have motivated a growing body of work on Speedy Secure Finality (SSF), which aims to minimize confirmation latency without weakening formal security guarantees. This paper surveys the state of the art in fast finality protocol design. We introduce the core theoretical primitives underlying this space, including reorganization resilience and the generalized sleepy model, and trace their development from Goldfish to RLMD-GHOST. We then analyze the communication and aggregation bottlenecks faced by single-slot finality protocols in large validator settings. Finally, we survey the 3-slot finality (3SF) protocol as a practical synthesis that balances fast finality with the engineering constraints of the Ethereum network.

Summary

  • The paper presents a systematic analysis of SSF protocols that balance adaptive liveness with deterministic finality in blockchain consensus.
  • It evaluates hybrid designs like Goldfish, RLMD-GHOST, single-slot, and 3-slot finality, highlighting key trade-offs between network delays and security.
  • The study identifies signature aggregation as a critical bottleneck and proposes parameter tuning to enhance performance and resilience against attacks.

Authoritative Summary of "SoK: Speedy Secure Finality" (2512.20715)

Context and Motivation

The paper presents a systematic overview of the "Speedy Secure Finality" (SSF) research agenda, which seeks to significantly reduce confirmation latency in permissionless blockchains—particularly Ethereum—without compromising safety or exposing systems to protocol-level attacks. Traditional Byzantine Fault Tolerant (BFT) protocols achieve deterministic finality but struggle with dynamic participation. In contrast, Nakamoto-style protocols offer adaptivity but only probabilistic finality. The impossibility results of Lewis-Pye and Roughgarden prove that no protocol achieves both in unsized, partially synchronous environments, guiding the evolution of hybrid "ebb-n-flow" architectures such as Ethereum's Gasper protocol.

Gasper pairs the dynamically available LMD-GHOST fork-choice rule with the Casper Finality Gadget (FFG), achieving both adaptive liveness and rigorous finality under certain network and participation assumptions. However, a pronounced delay (12–19 minutes) between block execution and finality persists, rendering the protocol susceptible to reorganization attacks, including ex-ante strategies that enable adversaries to manipulate future block orderings and maximize MEV extraction.

Formal Primitives of Speedy Secure Finality

The survey rigorously defines key concepts—finality, adaptivity, dynamic availability, and the sleepy consensus model—which are essential for analyzing trade-offs in consensus system design:

  • Finality: The property that once a block is confirmed, it remains immutable even under indefinite network partitions.
  • Adaptivity: Consensus liveness even as participation and resource pools fluctuate unpredictably.
  • Dynamic Availability: Liveness contingent on the honest majority among currently online validators.
  • Generalized Sleepy Model: Extends the original sleepy model to quantify resilience to vote staleness, refining the balance between dynamic availability and asynchrony tolerance.

The survey details why adaptive protocols with probabilistic confirmation cannot guarantee absolute finality under partial synchrony, driving the bifurcation in protocol designs.

Evolution of Fast Finality Protocols

Goldfish

Goldfish introduces message buffering and strict vote expiry to LMD-GHOST, confining votes counted in consensus to those from the immediately preceding slot. This modification blocks reorg and balancing attacks by ensuring all honest validators use similar, temporally aligned views. However, Goldfish reveals brittle asynchrony resilience—any unexpected network delay causes otherwise valid votes to expire, potentially stalling consensus progress.

RLMD-GHOST

RLMD-GHOST generalizes Goldfish by introducing a configurable vote-expiry parameter η\eta, enabling flexible trade-offs between resilience to asynchrony and dynamic availability. Subsampling is eliminated: all validators cast votes per slot, preventing accumulation-based attacks. As η\eta increases, the protocol admits older votes, improving robustness against transient network failures but simultaneously increasing risk of adversarial exploitation of stale votes. Formal analysis in the generalized sleepy model quantifies degree-η\eta dynamic availability, precisely defining protocol behavior under various network and participation regimes.

Single-Slot Finality

By layering a Casper-like finality gadget atop RLMD-GHOST with optimized message synchronization, D'Amato and Zanolini present a SSF protocol that theoretically achieves finality in a single slot. The protocol amalgamates propose, head-voting, finality voting, and merge phases into a synchronous cycle, dramatically narrowing the confirmation window for economic settlement and MEV risk mitigation. Despite its security guarantees, practical deployment is hampered by signature aggregation requirements; all validators must sign and aggregate within a slot, which is infeasible given Ethereum’s validator scale.

Engineering Bottlenecks and Pragmatic Convergence

Signature Aggregation Bottleneck

The dominant impediment to the rollout of SSF and other fast finality protocols lies in cryptographic overhead. The requirement to collect, verify, and aggregate signatures from every individual validator in real time currently exceeds network and software capacity—especially at scales exceeding one million keys. As outlined, the maximum effective balance constraint in Ethereum’s staking mechanism artificially inflates validator key count relative to the actual node count, exacerbating the aggregation problem. Ethereum’s recent adoption of EIP-7251, raising maximum effective balance, sets the stage for a major key-count reduction, mitigating—but not wholly eliminating—the cryptographic bottleneck.

Three-Slot Finality (3SF)

3SF protocol addresses the slot-time bottleneck by merging voting phases and extending the justification-finalization pipeline over three slots. This adaptation retains the safety and liveness properties of SSF while aligning practical slot times with the underlying signature aggregation bandwidth. Novel slashing conditions maintain accountable safety in more complex epoch boundary scenarios not covered by Casper’s original rules. By eliminating subsampling, 3SF maximizes security at the expense of bandwith, but it scales more realistically for Ethereum’s anticipated validator composition after key-count normalization.

Implications and Future Directions

The transition from Gasper’s epoch-based confirmation to SSF and 3SF is not simply an upgrade in latency metrics; it redefines the consensus protocol landscape in terms of adversarial robustness, economic efficiency, and client trust flexibility. Fast finality protocols will lower risk of MEV-driven reorganizations and improve transactional settlement for high-stakes applications, such as DeFi and stablecoins.

From a theoretical perspective, the survey highlights the irreducible design trade-offs imposed by network and participation dynamism. The parameterization of vote expiry and signature aggregation constraints will remain central to protocol research as blockchains scale decentralization.

Future efforts will revolve around:

  • Signature Aggregation: Exploring advanced BLS aggregation, committee-based aggregation schemes, or hardware-accelerated cryptography.
  • Validator Key Management: Further increasing effective balance or developing new staking mechanisms that align key count with physical node count.
  • Protocol Composability: Investigating hybrid designs beyond the current ebb-n-flow paradigm.
  • Decentralization Trade-offs: Assessing how reductions in validator key counts interplay with objective decentralization metrics and security.

Conclusion

The "SoK: Speedy Secure Finality" paper offers a rigorous account of the consensus protocol design space with respect to confirmation latency, network and security assumptions, and practical constraints. Goldfish and RLMD-GHOST introduce precise control over attack surfaces, culminating in the theoretical ideal of single-slot finality, while 3-Slot Finality provides a pragmatic solution for near-term deployment on Ethereum. The next frontier of speedy secure finality will depend on innovations in signature aggregation and validator management to harmonize protocol-level safety with engineering feasibility, thereby continuing the systematic evolution of permissionless blockchain consensus.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Sign Up to Generate All Videos Subscribe on YouTube

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Sign Up to Generate

Explain it Like I'm 14

Plain-English Summary of “SoK: Speedy Secure Finality”

Overview

This paper looks at how to make confirmations on the Ethereum blockchain much faster while still keeping them safe. Today, it usually takes about 12–15 minutes before a block (a batch of transactions) is locked in forever on Ethereum. During that waiting period, clever attackers can sometimes reorganize the chain to earn extra profit (called MEV). The paper surveys many ideas and protocols that try to shrink that delay to just a few seconds, without breaking important security rules.

What questions does the paper try to answer?

  • Why does Ethereum take so long to finalize a block?
  • Can we make finality happen faster without risking safety?
  • What basic rules about networks and participation affect what’s possible?
  • Which designs (like Goldfish, RLMD-GHOST, single-slot, and three-slot finality) work best, and what do they trade off?
  • How do huge validator sets (many thousands of participants) change what is practical, especially with communication limits?

How did the authors approach the topic?

This is a “SoK” paper, which means Systematization of Knowledge. Instead of proposing a brand-new system, the authors organized and explained existing ideas so readers can see the big picture and understand the trade-offs. They did this by:

  • Defining how different kinds of networks behave:
    • Synchronous: messages arrive within a known time (like guaranteed mail delivery by a set deadline).
    • Asynchronous: messages will arrive eventually, but you don’t know when (like sending mail without tracking).
    • Partially synchronous: it’s messy at first but eventually settles to predictable timing (like a storm that turns into clear weather).
  • Reviewing classic “finality” systems (like pBFT), which confirm blocks quickly and definitively, but need a stable, known group of participants.
  • Reviewing “sleepy” or “adaptive” systems (like Bitcoin-style longest chain), which keep working even when participants come and go, but only offer probabilistic finality (more confirmations make reorgs less likely, but not impossible).
  • Explaining a fundamental trade-off: you cannot have both perfect finality and full adaptivity at the same time in certain settings.
  • Detailing Ethereum’s current design (“Gasper”), which mixes:
    • LMD-GHOST (a rule for choosing the current head of the chain based on recent votes),
    • Casper FFG (a gadget that finalizes blocks using “supermajority” votes).
  • Analyzing known attacks that exploit the long finality window.
  • Surveying new fork-choice designs (Goldfish and RLMD-GHOST) that aim to resist reorgs and improve reliability.
  • Introducing the “generalized sleepy model,” which carefully accounts for how “old” votes can be safely used.
  • Discussing single-slot finality (finalizing in one block time) and why it’s hard with so many validators.
  • Presenting three-slot finality (3SF) as a practical, near-term compromise.

To make the technical terms intuitive:

  • Validator: a participant who has staked ETH and can vote on blocks (like jurors who cast votes).
  • Fork-choice rule: a way to pick the best current chain when there are multiple branches (like choosing the most supported path).
  • Finality gadget: a method to lock in blocks once enough validators sign off (like a courtroom verdict that makes a decision official).
  • Reorg (reorganization): undoing recent blocks and replacing them (like rewriting the last pages of a story).
  • MEV: extra profit from reordering transactions to your advantage (like cutting in line to buy something first).

Main findings and why they matter

  • A core trade-off is unavoidable:
    • Systems that are highly adaptive (keep working smoothly even when participants come and go) can’t guarantee perfect finality under all network conditions.
    • Systems with perfect finality need more stable participation and stricter assumptions.
  • Ethereum’s “ebb-and-flow” approach (Gasper) separates:
    • An available, quickly updated ledger (good for keeping things moving),
    • A finalized ledger (the safe, locked-in prefix).
    • This balance works, but it leaves a 12–15 minute window where reorgs are still possible.
  • Attacks are real:
    • “Balancing” and “ex-ante” reorg attacks can happen because validators may not share exactly the same view at the same time. This lets attackers time messages to sway votes and cause reorgs, chasing MEV.
  • Goldfish makes reorgs much harder by:
    • Buffering messages (so validators merge views in a coordinated way),
    • Expiring old votes (so stale information can’t be abused).
    • But strict vote expiry fails if the network has even brief periods of asynchrony—so Goldfish is fragile in practice.
  • RLMD-GHOST improves resilience by:
    • Allowing votes to stay valid for a tunable number of slots (a parameter called “η”),
    • Merging views more carefully,
    • Avoiding subsampling so attackers can’t accumulate weight across committees.
    • The trade-off: larger η handles longer network hiccups but risks reintroducing attack surfaces if votes get too old.
  • The generalized sleepy model formalizes exactly how old votes can be used safely. This helps designers pick η so they balance attack resistance against real-world network delays.
  • Single-slot finality is appealing but challenging with Ethereum’s huge validator set:
    • Finalizing in one slot needs a lot of messages to fly across the network quickly and be processed fast. Bandwidth and timing constraints make this very hard at Ethereum’s scale.
  • Three-slot finality (3SF) is a practical middle ground:
    • It can deliver fast finality in a small number of slots,
    • It is more realistic with today’s network and validator sizes,
    • It still preserves strong security guarantees.

What does this mean going forward?

Faster finality could:

  • Make the user experience smoother by confirming transactions in seconds instead of minutes.
  • Reduce MEV-related reorg risks, making the system fairer and more predictable.
  • Improve “economic settlement,” meaning big transfers and financial contracts can be safely completed more quickly.

But there are trade-offs. Designers must balance:

  • Security (no reorgs after finality),
  • Adaptivity (keeping the system live even if participation fluctuates),
  • Practical limits (bandwidth, message timing, and the size of the validator set).

The paper doesn’t push a single new protocol. Instead, it maps the space and clarifies the rules of the game. Its main impact is giving the community a shared framework to judge new proposals and highlighting 3-slot finality as a realistic path that could bring much faster confirmations to Ethereum without compromising safety.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The paper surveys fast-finality approaches but leaves several concrete issues unresolved that future work could address:

  • Quantifying RLMD-GHOST’s parameter η: no method is provided to choose η under real-world latency, churn, and adversarial scheduling; there is no guidance on adaptive tuning of η in response to observed asynchrony.
  • Unknown-Δ realism: proposed phase schedules (e.g., 3Δ/4Δ sub-slot phases) assume a known delay bound Δ; the paper does not show how to instantiate these protocols when Δ is unknown, time-varying, or adversarially manipulated.
  • Asynchrony detection and graceful degradation: there is no mechanism for detecting extended asynchrony and safely adjusting vote-expiry or protocol behavior without reintroducing reorg vulnerabilities.
  • Formal reorg-resilience bounds: the survey asserts reorg resilience for Goldfish/RLMD-GHOST but does not provide explicit adversary thresholds, reorg probability bounds, or tight worst-case analyses under realistic network models.
  • Full-set voting scalability: RLMD-GHOST removes subsampling, but the paper does not quantify bandwidth, CPU, memory, and aggregation overhead with Ethereum-scale validator sets, nor propose concrete aggregation schemes that meet slot time budgets.
  • Communication bottlenecks and engineering constraints: despite mention in the abstract, there is no quantitative analysis of message complexity, gossip fanout, or signature aggregation costs required to make SSF/3SF viable at current validator counts.
  • Join/dreamy-mode abuse and DoS: the “dreamy” joining protocol does not analyze adversarial wake-ups, buffer-flooding, or resource exhaustion from delayed message inclusion; bounds on buffer sizes and merge costs are missing.
  • Incentive compatibility of message buffering: there is no incentive design to deter strategic withholding of buffered votes/blocks or proposer-controlled “view curation,” especially in the presence of MEV and PBS.
  • Interactions with MEV-Boost/PBS: the effects of builders, relays, and withholding strategies on the timing-critical propose/vote/commit phases of fast-finality protocols are not analyzed.
  • New attack surfaces from view-merge: potential “merge-injection” or timing attacks that bias which buffered messages make it into the fork-choice view are not explored or mitigated.
  • Subsampling removal and centralization pressure: eliminating committees increases per-validator load; the paper does not evaluate whether this incentivizes delegation/centralization and what mitigations (e.g., hierarchical aggregation) are needed.
  • Light client support: there is no design for succinct finality proofs, sync committee analogs, or proofs-of-fork-choice suitable for light clients under SSF/3SF or RLMD-GHOST.
  • Inactivity leak and recovery in fast-finality designs: the paper discusses inactivity leak only for Gasper; it does not specify how leak/recovery should work for SSF/3SF when participation falls below thresholds.
  • Slashing conditions for propose–vote–merge: there is no specification of slashable offenses and on-chain verifiable evidence for RLMD-GHOST/SSF behavior (e.g., conflicting votes across phases or buffered-message manipulation).
  • Security under prolonged partitions (longer than η): the safety/liveness behavior and recovery procedures when asynchrony exceeds the configured η window are not characterized.
  • Confirmed-vs-final semantics in SSF/3SF: it remains unclear whether the proposed “single-slot finality” meets the paper’s earlier finality definition (security in partially synchronous settings) and what exact assumptions are required.
  • 3-slot finality specifics: although highlighted in the abstract, the paper does not detail 3SF’s protocol phases, quorum thresholds, aggregation plans, security proofs, or empirical performance.
  • Empirical validation: there is no testnet or simulation study quantifying fork-choice convergence time, reorg rates, bandwidth, and missed attestations under realistic latency distributions and adversarial schedulers.
  • Parameter sensitivity studies: the impact of η, committee sizes (if any), aggregation depths, and phase durations on safety, liveness, and performance is not evaluated.
  • Compatibility with Ethereum’s p2p stack: required changes to gossip topics, scoring, attestation flows, and timing to support propose–vote–merge protocols at 12-second slots are not specified.
  • Transition plan and backward compatibility: there is no migration path from Gasper to RLMD-GHOST/HFC/SSF/3SF, including handling of fork-choice changes, client diversity, and mixed upgrades.
  • Economic analysis: costs to execute residual reorg or timing attacks, expected MEV capture differentials, and validator revenue impacts under fast-finality designs are not quantified.
  • Formalization gaps in the generalized sleepy model: while degree-η dynamic availability is defined, the paper does not provide matching theorems linking η, network delay distributions, and adversarial online fractions to concrete safety/liveness guarantees.
View Paper Prompt  View All Prompts 

Practical Applications

Practical, real-world applications derived from the paper

Below are actionable applications that build on the survey’s findings about reorg resilience, dynamic availability, fork-choice design (Goldfish, RLMD-GHOST), and fast finality (single-slot and three-slot finality). Each item notes relevant sectors and key assumptions/dependencies that affect feasibility.

Immediate Applications

These can be piloted or adopted now using today’s Ethereum/Gasper stack, client software, and operational practices, or as near-term client enhancements and ecosystem policies.

  • Exchange and custodian confirmation policies calibrated to reorg risk
    • What to do: Replace fixed “12–15 minute” finality heuristics with dynamic confirmation policies derived from the paper’s formal notions of security, reorg risk, and finality vs. availability. Use shorter thresholds when conditions indicate low ex-ante reorg risk; increase thresholds during turbulence.
    • Sectors: Finance (exchanges, custodians, brokers), Compliance.
    • Tools/workflows: Risk dashboards that ingest fork-choice weight, attestation timeliness, and network health; policy templates for conditional holds/unlocks; customer-facing SLAs that distinguish “available ledger” vs “finalized ledger.”
    • Assumptions/dependencies: Requires reliable telemetry from consensus clients; assumes current Gasper and <33% Byzantine stake; depends on robust monitoring of asynchronous episodes and attestation splits.
  • Cross-chain bridge and rollup timeout tuning
    • What to do: Adjust challenge windows, bridge lock/unlock timers, and L2 withdrawal periods based on documented finalization latency (64–95 slots) and observed ex-ante reorg risk under Gasper; revisit parameters as RLMD-GHOST/3SF/SSF features arrive on testnets.
    • Sectors: Software (bridges, rollups), Finance (tokenized assets), Payments.
    • Tools/workflows: Parameter calculators that map risk tolerance ε to safe confirmation depths under varying network conditions.
    • Assumptions/dependencies: Safety bounds presume partial synchrony and current Gasper behavior; incorrect tuning can amplify reorg exposure.
  • Wallet and merchant UX that surfaces availability vs. finality
    • What to do: Present two progress states (available vs. finalized) per the ebb-n-flow model; show ETA for finality and contextual risk (e.g., during inactivity leak).
    • Sectors: Payments, Commerce, Consumer software.
    • Tools/workflows: Wallet SDKs that query client finality status and fork-choice head; merchant POS integrations that accept “available” with insurance or hedging and auto-settle on “finalized.”
    • Assumptions/dependencies: Accurate client finality metadata; user education to avoid confusing probabilistic and absolute guarantees.
  • Validator client instrumentation and testbed for view-merge and “dreamy” joining
    • What to do: Prototype message buffering (view-merge) and the “dreamy → awake” joining protocol from RLMD-GHOST in client labs/testnets to measure latency, memory overhead, and slashing safety before any fork-choice change.
    • Sectors: Software (consensus clients), Ethereum core R&D.
    • Tools/workflows: Toggle-able forks in clients; network simulators that vary Δ and offline rates; slashing-protection tests; interop testnets.
    • Assumptions/dependencies: No change to mainnet fork-choice until specified; must maintain Casper slashing invariants; requires client diversity testing.
  • MEV relay, builder, and proposer strategies hardened against ex-ante reorgs
    • What to do: Incorporate reorg-resilience signals (attestation age, weight splits, delayed reveal patterns) into relay acceptance, block auction timing, and proposer policies to reduce incentive for withheld attestations and balancing attacks.
    • Sectors: Finance (MEV markets), Software (PBS infrastructure).
    • Tools/workflows: Heuristics for detecting latent attestations; penalties or filters for risky timing; analytics on fork-choice tipping points.
    • Assumptions/dependencies: Voluntary adoption by builders/relays; relies on accurate, low-latency network observations.
  • Incident-response runbooks for catastrophic crash and inactivity leak
    • What to do: Prepare exchange/validator procedures for prolonged non-finalization: confirmation-depth escalation, fee/limit controls, and customer communications; validator-side monitoring of inactivity penalties.
    • Sectors: Finance (exchanges, custodians), Infrastructure.
    • Tools/workflows: Playbooks tied to inactivity-leak triggers; alert pipelines; automated policy switches.
    • Assumptions/dependencies: Accurate detection of finality stalls; ecosystem coordination.
  • Academic curriculum and reproducible research kits
    • What to do: Integrate the paper’s taxonomy (dynamic availability, generalized sleepy model, impossibility of adaptivity+finality) into distributed systems/blockchain courses; provide labs reproducing balancing attacks, vote-expiry effects, and fork-choice behavior under asynchrony.
    • Sectors: Academia, Education.
    • Tools/workflows: Open-source simulators parameterized by η (vote expiry), Δ (delay), validator online rates; datasets of attestation timing.
    • Assumptions/dependencies: Availability of reference implementations and simulation harnesses.
  • Governance, disclosures, and standards alignment
    • What to do: Update protocol docs, risk disclosures, and industry guides to precisely define “confirmation,” “security,” “finality,” and the distinction between LOG_da and LOG_fin; align with settlement-finality regulations.
    • Sectors: Policy, Compliance, Industry consortia.
    • Tools/workflows: Glossaries, standard risk rubrics, reporting formats for confirmation-depth policies.
    • Assumptions/dependencies: Cross-stakeholder agreement; evolving regulatory interpretation of “finality.”

Long-Term Applications

These require protocol changes, scaling, or significant research/engineering to reach production reliability.

  • Single-Slot Finality (SSF) on Ethereum
    • What it enables: Near-instant settlement with rigorous safety by combining a hybrid RLMD-GHOST fork-choice (HFC) with a partially synchronous finality gadget that finalizes within the proposing slot.
    • Sectors: Finance (payments, DvP, intraday collateral), DeFi, Exchanges.
    • Tools/products: Upgraded consensus clients; aggregated BLS signatures; finality-aware APIs for apps; risk engines recalibrated to sub-minute finality.
    • Assumptions/dependencies: Communication/computation bottlenecks with large validator sets; robust signature aggregation; partial synchrony bounds (Δ) hold; <1/3 Byzantine stake; hard-fork governance; formal proofs and exhaustive testnet trials.
  • Three-Slot Finality (3SF) as pragmatic near-term protocol upgrade
    • What it enables: Fast finality with reduced bandwidth pressure compared to SSF, fitting Ethereum’s large validator set constraints.
    • Sectors: Same as SSF; also enterprise blockchains that need predictable, fast finality.
    • Tools/products: Client upgrades implementing 3-phase commit over three slots; new fork-choice/attestation timing; finality timers in apps.
    • Assumptions/dependencies: Network can sustain 3-slot commit cadence; secure committee design; parameterization validated on mainnet-like testnets.
  • RLMD-GHOST as a replacement for LMD-GHOST in Gasper
    • What it enables: Reorg resilience with explicit tuning of the asynchrony vs. dynamic-availability trade-off via vote-expiry η; removal of subsampling to reduce weight-accumulation attacks.
    • Sectors: Core protocol, DeFi (reduced reorg risk), Bridges.
    • Tools/products: Fork-choice libraries implementing propose–vote–merge; configuration tooling to choose η from measured Δ and target resilience.
    • Assumptions/dependencies: Choosing η too low harms asynchrony resilience; too high reintroduces balancing attack surfaces; needs real-time network-measurement to set parameters.
  • Standardized “Finality APIs” for applications and risk engines
    • What it enables: Programmatic access to available-head, latest justified, and finalized checkpoints, with confidence metrics and ETA.
    • Sectors: Software (SDKs), Finance (risk), Commerce.
    • Tools/products: Cross-client API spec; libraries for wallets/exchanges; observability dashboards.
    • Assumptions/dependencies: Client consensus on API semantics; backward compatibility; application developer adoption.
  • Safer, faster cross-chain bridges using reorg-resilient fork-choice and fast finality
    • What it enables: Lower lock durations and faster unlocks with bounded reorg risk; light clients tracking justified/finalized checkpoints instead of raw heads.
    • Sectors: Interoperability, Tokenized assets, Payments.
    • Tools/products: Light-client bridges tuned to RLMD-GHOST/3SF/SSF semantics; proof systems aggregating attestation quorums.
    • Assumptions/dependencies: Counterparty chains must verify Ethereum’s finality proofs; security relies on Ethereum’s <1/3 Byzantine and synchrony assumptions.
  • New financial products and workflows predicated on fast finality
    • What it enables: Real-time DvP/RvP, intraday collateral reuse, T+0 settlement for tokenized RWAs, on-chain FX/derivatives with reduced counterparty risk windows.
    • Sectors: Capital markets, Treasury, Payments.
    • Tools/products: Settlement orchestrators that trigger off finalized checkpoints; risk and capital models updated for shorter settlement cycles.
    • Assumptions/dependencies: Legal recognition of on-chain finality; oracle and custody integrations; throughput and fee constraints remain acceptable.
  • MEV market redesign aligned with fast finality
    • What it enables: Reduced window for ex-ante strategies; potential shift to pre-commit or encrypted mempools; PBS evolutions that internalize reorg-resilience.
    • Sectors: MEV infrastructure, Core protocol.
    • Tools/products: Builders/relays supporting commit–reveal or encryption; proposer policies tuned to new finality cadence.
    • Assumptions/dependencies: Additional cryptographic and networking overhead; incentive compatibility research.
  • Enterprise and CBDC platforms adopting fast-finality design patterns
    • What it enables: Deterministic or near-deterministic finality at public-network scale; hybrid availability/finality ledgers usable for retail and wholesale settlement.
    • Sectors: Central banking, Enterprise DLT, Payments.
    • Tools/products: Consortia chains that adapt 3SF/SSF patterns; compliance modules mapping to finality guarantees.
    • Assumptions/dependencies: Governance and identity layers; regulatory approvals; performance engineering for large committees.
  • Formal verification and conformance testing for fork-choice and finality gadgets
    • What it enables: Machine-checked safety/liveness proofs for RLMD-GHOST/3SF/SSF; regression suites across client implementations.
    • Sectors: Academia, Core protocol, Tooling.
    • Tools/products: TLA+/Ivy/Coq specs; network-fault model generators; cross-client conformance tests.
    • Assumptions/dependencies: Precise formalization of generalized sleepy model and protocol phases; funded verification efforts.
  • Network measurement and synchrony estimation services
    • What it enables: Continuous estimates of Δ, attestation propagation, and partition risk to inform η selection and application risk thresholds.
    • Sectors: Infrastructure, Analytics, Risk.
    • Tools/products: Public measurement networks; client-integrated telemetry; parameter recommender services.
    • Assumptions/dependencies: Wide vantage coverage; privacy-preserving telemetry; community acceptance to drive parameter updates.
  • Standards and policy for settlement finality in crypto systems
    • What it enables: Industry-wide norms that map probabilistic vs. absolute finality to operational requirements (e.g., reserves, capital, disclosure).
    • Sectors: Policy, Compliance, Industry associations.
    • Tools/products: Standard definitions, certification schemes, audit guidelines referencing LOG_da vs LOG_fin and failure probabilities.
    • Assumptions/dependencies: Multi-stakeholder consensus; alignment with existing payment/finality statutes; evolving jurisprudence.

Notes on global assumptions across applications:

  • Security bounds rely on <1/3 Byzantine stake for finality gadgets and honest-majority-on-line for dynamic availability; deviations can break guarantees.
  • Partial synchrony is assumed post-GST/GAT; extended asynchrony stresses protocols and requires conservative parameters (η, finality slots).
  • Ethereum’s large validator set imposes bandwidth and aggregation limits; signature aggregation and gossip optimization are critical for SSF/3SF.
  • Parameter choices (η, Δ, committee sizes) materially affect safety/liveness and must be validated on realistic testnets prior to mainnet adoption.
View Paper Prompt  View All Prompts 

Glossary

  • Accountable Safety: A safety condition stating that two conflicting checkpoints cannot both be finalized without slashing at least one-third of the total stake. "With these slight changes, Gasper ensures that Ethereum can run a Proof of Stake protocol with Accountable Safety and Plausible Liveness."
  • Adaptivity: The property of remaining live without knowing the total available resource in the system. "A protocol is adaptive if it is live in the unsized setting."
  • Aggressive Client: In ebb-n-flow protocols, a client that trusts the dynamically available ledger for liveness under changing participation. "the aggressive client trusts an available ledger $\text{LOG}_{\text{da}$ that is live under dynamic participation."
  • Asynchrony Resilience: The ability of a protocol to tolerate asynchronous network periods without catastrophic failure. "To address the challenges of asynchrony resilience, D'Amato and Zanolini introduced RLMD-GHOST \cite{rlmd-ghost} which is a dynamically available protocol with asynchrony resilience."
  • Asynchronous Network: A network model where message delay is finite but unknown, making timing assumptions impossible. "An asynchronous network is one where Δ\Delta is finite but unknown."
  • Attestation: A digitally signed message that links a source checkpoint to a target checkpoint, serving as a vote. "An attestation is a digitally signed message which contains a link from one checkpoint to another s→ts \rightarrow t where ss and tt are not conflicting checkpoints and ht>hsh_t > h_s."
  • Balancing Attack: An adversarial strategy that splits committee votes to enable long-range reorganizations. "Balancing attacks have been discovered \cite{attacks} that can allow a validator controlling a small fraction of total network stake and no control over network delay to achieve long-range reorg attacks."
  • Byzantine Fault Tolerant (BFT): A class of protocols that achieve deterministic finality under partial synchrony despite a bounded fraction of Byzantine faults. "Classical Byzantine Fault Tolerant (BFT) (see \cite{zhong2023byzantine} for a comprehensive survey) protocols achieve deterministic finality under partial synchrony..."
  • Casper FFG: A finality gadget meta-protocol layered on a consensus protocol to justify and finalize checkpoints. "Casper FFG is a meta-protocol that can be used on top of a consensus protocol to achieve finality."
  • Checkpoints: Special blocks at fixed heights that serve as sources and targets for justification and finalization. "More accurately, Casper FFG finalizes checkpoints."
  • Confirmation Rule: A rule that maps a node’s message state to its locally confirmed chain. "and CC is a confirmation rule."
  • Conservative Client: In ebb-n-flow protocols, a client that trusts the finalized ledger for safety under partition. "The conservative client trusts a finalized ledger $\text{LOG}_{\text{fin}$ which is safe under network partition..."
  • Degree of Dynamic Availability: A formalization of dynamic availability parameterized by how old votes can be to still count toward liveness. "A protocol has degree-η\eta dynamic availability if, for every slot tt, liveness is preserved whenever the set of honest validators that were awake at least once in the window"
  • Dreamy: A transitional validator state after waking, during which buffered messages are received but voting is not yet allowed. "Until this point, the validator is considered dreamy \cite{goldfish} and only after the merge is it allowed to participate in the protocol as a regular awake node."
  • Dynamic Availability: Liveness guaranteed whenever the honest-online set has a majority at each time step. "A consensus protocol is dynamically available if it maintains liveness (i.e., honest transactions are eventually confirmed) whenever, at every time step, the set of online honest replicas has a majority over online adversarial replicas."
  • Ebb-n-Flow Protocols: Flexible consensus protocols offering both a finalized ledger for safety and an available ledger for liveness. "An ebb-n-flow protocol is a flexible consensus protocol that supports a conservative client and an aggressive client."
  • Epoch: A scheduling unit in Ethereum consisting of 32 slots used for committee assignments and voting. "An epoch has 32 slots, each 12 seconds long."
  • Epoch Boundary Pairs: A pair (block, epoch) used in Gasper to play the role of checkpoints for justification and finalization. "In Gasper, blocks are chosen to play the role of what checkpoints do in Casper... we define an epoch boundary pair (B,j)(B, j)."
  • Ex ante attack: A reorganization attack targeting future blocks unknown at the time of attack. "However, Gasper allows for a type of reorg attack called ex ante attack."
  • Ex post attack: A reorganization attack targeting a block already observed to capture its value. "This is called a ex post attack."
  • Finality: The guarantee that a confirmed block will not be reverted in any admissible execution. "A central property governing the security and usability of such systems is finality: the guarantee that once a block is confirmed, it will not be reverted in any admissible execution."
  • Finality Gadget: A mechanism, often BFT-style, that provides strong finality atop an availability protocol. "pairing a dynamically available fork-choice rule with a BFT-style finality gadget in an ebb-and-flow architecture."
  • FLP impossibility result: A foundational result showing impossibility of deterministic consensus in fully asynchronous systems with certain faults. "Such models are subject to fundamental constraints, most notably the FLP impossibility result."
  • Fork-Choice Rule: An algorithm that selects the head of the chain given a node’s view of blocks and votes. "A fork-choice rule is an algorithm which, when given a view VV of all proposed blocks, deterministically outputs a block BVB_V..."
  • Gasper: Ethereum’s Proof of Stake consensus protocol combining LMD-GHOST with Casper FFG in an ebb-and-flow design. "Ethereum’s consensus protocol, Gasper \cite{gasper}, is the most prominent example, pairing a dynamically available fork-choice rule with a BFT-style finality gadget..."
  • GAT (Global Awake Time): The time after which all honest nodes are awake in the Gasper model. "It considers a partially synchronous network, where honest nodes are sleepy until global awake time GAT\text{GAT}, \cite{ebbnflow} after which all nodes are awake."
  • Generalized Sleepy Model: A refinement of the sleepy model that accounts for vote age via an expiry parameter. "RLMD\text{-}GHOST is analyzed in the generalized sleepy model introduced by D'Amato and Zanolini~\cite{rlmd-ghost}..."
  • GHOST: The Greedy Heaviest-Observed Sub-Tree protocol used for fork choice in blockchain systems. "LMD-GHOST is an adaptation of the GHOST protocol introduced by Sompolinsky and Zohar \cite{ghost}."
  • Goldfish: A propose-vote-merge fork-choice protocol using message buffering and strict vote expiry to resist reorgs. "Goldfish was proposed as a drop-in replacement for LMD-GHOST in Gasper which came with security guarantees in the sleepy model for reorg resilience."
  • Greedy Heaviest-Observed Sub-Tree (GHOST): A strategy that recursively chooses the child branch with the highest accumulated vote weight. "It comprises of two acronyms that stand for \"Latest Message Driven\" and \"Greedy Heaviest-Observed Sub-Tree\"."
  • GST (Global Stabilization Time): The unknown time after which the network becomes synchronous with bounded delay. "A partially-synchronous network is one where Δ\Delta is a finite and known time bound following a period known as the global stabilization time GST\text{GST}."
  • HLMD GHOST: Hybrid LMD-GHOST that anchors fork choice at the latest justified pair and filters views accordingly. "Gasper also uses a slightly modified fork-choice rule HLMD GHOST (which stands for Hybrid LMD-GHOST)."
  • HFC: A hybrid fork-choice rule based on RLMD-GHOST used in the single-slot finality proposal. "The protocol uses a hybrid version of RLMD-GHOST as its fork choice rule, called HFCHFC."
  • Impossibility of adaptivity and finality: A theorem asserting no protocol can be both adaptive and have finality in the unsized, partially synchronous setting. "No protocol is both adaptive and has finality."
  • Inactivity leak: A penalty mode that drains inactive validators’ stake to re-establish a supermajority for finalization. "In such a catastrophic situation, Ethereum enters an inactivity leak mode."
  • k-reorg: A reorganization that replaces k blocks to gain time or extract value. "This can be done to reorg kk number of blocks (also called k−reorgk-reorg)..."
  • LMD-GHOST: Latest-Message-Driven fork-choice rule that selects the heaviest observed subtree by vote weight. "LMD-GHOST is the fork-choice rule for the Ethereum consensus protocol."
  • Liveness: The property that the confirmed chain grows during sufficiently long synchronous intervals. "A protocol is live if, for every ε>0\varepsilon>0, there exists ℓε∈N\ell_\varepsilon \in \mathbb{N} such that the following holds..."
  • LOG_da: The dynamically available ledger maintained by aggressive clients in ebb-n-flow protocols. "the aggressive client trusts an available ledger $\text{LOG}_{\text{da}$ that is live under dynamic participation."
  • LOG_fin: The finalized ledger maintained by conservative clients, safe under partitions. "The conservative client trusts a finalized ledger $\text{LOG}_{\text{fin}$ which is safe under network partition..."
  • MEV: Maximal Extractable Value that adversaries may capture via reorganization. "This is predominant in PoW blockchains where the adversary wants to get the MEV in the block for themselves."
  • Message Buffering: A technique that delays incorporating received messages into the local view via a buffer to enable view-merge. "With message buffering, messages received by a validator VV enter a buffer BV\mathcal{B}_V."
  • Nakamoto consensus: Longest-chain consensus underpinning PoW systems with probabilistic finality. "For example, the longest-chain rule used in the Nakamoto consensus is a fork-choice rule..."
  • Partially-Synchronous Network: A network that behaves asynchronously until GST, then synchronously with known delay Δ. "A partially-synchronous network is one where Δ\Delta is a finite and known time bound following a period known as the global stabilization time GST\text{GST}."
  • pBFT (Practical Byzantine Fault Tolerance): A three-phase BFT replication protocol under partial synchrony with the bound n ≥ 3f+1. "Practical Byzantine Fault Tolerance (pBFT) was introduced by Castro and Liskov \cite{pbft} in 1999..."
  • Plausible Liveness: A property of Casper/Gasper that enables new checkpoints to be finalized under honest supermajority and ongoing block production. "With these slight changes, Gasper ensures that Ethereum can run a Proof of Stake protocol with Accountable Safety and Plausible Liveness."
  • Probabilistic finality: A confirmation guarantee where reorg probability decreases with depth but never reaches zero. "This sort of guarantee is called probabilistic finality."
  • Proof of Stake: A consensus model where voting power is proportional to stake deposited by validators. "It uses a Proof of Stake model as its consensus protocol."
  • Quorum intersection: The property that overlapping quorums share honest nodes, ensuring agreement and safety. "They assume a fixed replica set and guarantee safety through quorum intersection: once a value is committed by a quorum, it cannot be reverted, yielding immediate finality."
  • Reorg attack: An attempt to replace part of the chain by building a competing branch with strategic timing. "A reorg attack typically refers to an attempt by an adversary to fork out a block it has observed."
  • Reorg resilience: The resistance of a protocol to chain reorganizations due to its design features. "Goldfish was proposed as a drop-in replacement for LMD-GHOST in Gasper which came with security guarantees in the sleepy model for reorg resilience."
  • Resource pool: An abstraction assigning per-user resource balances (e.g., stake or hashrate) over time for protocol analysis. "Protocols in~\cite{resourcepool} are analyzed relative to a resource pool RR..."
  • RLMD-GHOST: Recent Latest Message Driven GHOST, a family of fork-choice protocols parameterized by vote expiry to balance availability and resilience. "D'Amato and Zanolini introduced RLMD-GHOST \cite{rlmd-ghost} which is a dynamically available protocol with asynchrony resilience."
  • Security: The compatibility of all confirmed blocks across honest users with high probability. "A protocol is secure if for every ε>0\varepsilon>0, for all honest users U1,U2U_1,U_2 and all times t1,t2t_1,t_2, with probability at least 1−ε1-\varepsilon..."
  • Single-Slot Finality: The goal and design of achieving finality within one slot/block in Ethereum. "The initial goal of the foundation with these efforts is to achieve finality within a single block or single-slot finality."
  • Sleepy Model: A consensus model that permits fluctuating node availability by allowing nodes to be online or offline. "We next examine the Sleepy Model of Consensus, which relaxes these assumptions and enables agreement in settings with fluctuating node availability."
  • Sleepy Node: A node that may be online or offline at each time step and produces no messages while offline. "A replica ii is sleepy if at each time step it may be either online (awake) or offline (asleep), where the online/offline state may change arbitrarily throughout the execution."
  • SMR (State Machine Replication): The distributed systems abstraction of replicating a deterministic state machine across processes. "consensus in blockchains can be understood through the lens of state machine replication (SMR), a classical abstraction in distributed systems"
  • Subsampling: Voting by a subset (committee) of validators per slot, which can enable certain balancing attacks. "balancing attacks with accumulation of weight are only possible due to subsampling of the validator set in LMD-GHOST."
  • Supermajority link: A checkpoint link supported by at least two-thirds of validators by deposit. "A link s→ts \rightarrow t is said to be a supermajority link if at least 23\frac{2}{3} of validators (by deposit) have made an attestation with ss as the source and tt as the target."
  • Synchronous Network: A network model with a known finite upper bound on message delay. "A synchronous network is one where the network delay Δ\Delta is finite and known i.e for any message, the adversary can delay a message by at most a known Δ<∞\Delta < \infty."
  • Unsized setting: A resource setting where the total resource is not known and only bounded within intervals. "Unsized setting: RR (and hence TT) is undetermined, subject only to coarse bounds T(t,M)∈[I0,I1]T(t,M)\in[I_0,I_1]..."
  • Validator: A network participant that stakes ETH to propose blocks and cast attestations in Proof of Stake. "These nodes are called validators."
  • View-change mechanism: The pBFT process to replace a faulty leader under partial synchrony to restore progress. "Under partial synchrony, pBFT eventually selects a correct primary through the view-change mechanism..."
  • View-merge: The act of merging buffered messages into the working view; synonymous with message buffering. "Goldfish was proposed as a drop-in replacement... on the concepts of message buffering (also known as view-merge) and vote expiry."
  • Vote Expiry: A rule that limits fork-choice to consider only recent votes, preventing weight accumulation across slots. "Vote expiry means that in any given slot tt, only votes from the slot t−1t-1 will be considered to run the GHOST fork-choice rule on."
  • Weight: The effective-balance-based contribution of a validator’s vote to a block’s subtree weight. "The weight of a single vote or attestation on a block is the effective balance of the validator which cast the vote."
View Paper Prompt  View All Prompts 

Open Problems

We found no open problems mentioned in this paper.

Authors (2)

  1. Yash Saraswat 
  2. Abhimanyu Nag 

Collections

Sign up for free to add this paper to one or more collections.

Sign Up

Tweets

Sign up for free to view the 8 tweets with 169 likes about this paper.

Sign Up for Free