Summary

The next generation Ethereum consensus decouples the dynamically-available chain (“heartbeat”) from finality, addressing both Gasper’s theoretical weaknesses and practical demands for faster confirmation, PQ readiness, and sub-256-validator slots. Goldfish provides the dynamically-available layer (safe and live as long as most awake validators are honest); Majorum adds a stabilizing finality gadget. The two-layer architecture is a fundamental impossibility result: no single protocol can be both dynamically available and provide finality.

Why Change Gasper?

Gasper = LMD-GHOST + Casper FFG. Problems:

  1. LMD-GHOST is not provably dynamically available: adversarial strategies can violate both safety and liveness in the synchronous model (Neu, Tas, Tse 2021).
  2. Complex interaction: LMD-GHOST and FFG interact in ways that are hard to reason about formally; multiple patches have not fully closed known attack vectors.
  3. Slot time bottleneck: current 12-second slots require aggregating ~30,000 attestations through multiple aggregation rounds. Reducing to the full validator set (1M+) under SSF would make this worse.
  4. PQ challenge: BLS signature aggregation has no PQ equivalent at practical sizes; ~256 validators per slot makes naive concatenation feasible.

The Availability-Finality Dilemma

A fundamental impossibility result (blockchain CAP theorem):

No single protocol can simultaneously guarantee:

  • Liveness under dynamic participation: chain continues to grow as the awake validator set fluctuates
  • Safety under network partitions: confirmed transactions cannot be reverted even if the network temporarily splits

BFT protocols (PBFT, Tendermint, HotStuff) achieve partition safety but halt when >⅓ validators go offline. Longest-chain protocols (Bitcoin) achieve dynamic availability but offer only probabilistic confirmation. The two-layer architecture is mathematically necessary.

Why Dynamic Availability Matters

Ethereum has never stopped producing blocks, even through:

  • May 2023: Prysm/Teku bugs caused first mainnet inactivity leak. >90% of slots still proposed.
  • Nov 2020: Geth consensus bug; small fork, but chain continued.
  • Real-world outages push participation as low as ~33% — below any BFT fault threshold.

Dynamic availability ensures:

  1. Resilience: bugs/outages don’t halt the chain; recovery is “rejoin, don’t restart”
  2. Censorship resistance: a minority can continue building an alternative fork under majority censorship
  3. Application continuity: DeFi, rollups, and bridges depend on a functioning L1 — a halt simultaneously freezes all composable protocols

Compare: Solana’s Feb 2024 halt (5 hours, DeFi completely frozen) vs. Ethereum’s May 2023 (no block production halt).

Goldfish Protocol

Goldfish is a propose-and-vote protocol designed for dynamic availability:

Key Properties

  • Constant expected confirmation latency: confirmation time does not grow with target security level (key separation from longest-chain protocols)
  • Reorg resilience: blocks by honest proposers remain canonical — eliminates a class of attacks plaguing LMD-GHOST
  • Subsampling: ~256 validators per slot, small enough for a single subnet broadcast; no aggregation rounds needed
  • Composability: serves as the dynamically-available component in an ebb-and-flow protocol

Mechanism (Simplified)

  1. Each slot: a random proposer broadcasts a block.
  2. A subsampled committee (~256 validators) votes for the block.
  3. Vote expiry: old votes don’t accumulate indefinitely (unlike LMD-GHOST’s “ghost” votes) — prevents long-range attacks.
  4. View-merge: validators synchronize their local views upon receiving new blocks, ensuring consistent fork-choice.
  5. A block is confirmed when it accumulates sufficient votes in the current view.

3-Step Fork-Choice

  1. Validate block and check vote count
  2. Apply view-merge rule
  3. Select the head with the most recent sufficient quorum

Majorum: The Finality Gadget

Majorum stabilizes the dynamically-available heartbeat by providing irreversible finality:

Design

  • Runs in parallel with Goldfish, not on the critical path for block production
  • Uses the full active validator set for finality votes (currently ~1M validators)
  • Finalizes checkpoints in the Goldfish chain after sufficient votes accumulate
  • Inactivity leak: if finality stalls, inactivity penalties gradually reduce the stake of non-participating validators until finality can resume with the remaining stake
  • During finality stalls, the Goldfish heartbeat continues uninterrupted

Properties

  • Strictly accountable safety: ≥⅓ of stake must be slashed for a finality reversion
  • Liveness: if ≥⅔ awake stake is honest, finality resumes
  • Decoupled from heartbeat: a finality stall has no effect on block production

Target Architecture

┌─────────────────────────────────────────────────────┐
│ Heartbeat: Goldfish (~256 validators/slot)           │
│ - Dynamic availability                               │
│ - ~200ms–1s sub-slot confirmations (with TOOL)       │
│ - PQ-ready: 256 concatenated signatures              │
└──────────────────────┬──────────────────────────────┘
                       │ feeds
┌──────────────────────▼──────────────────────────────┐
│ Finality: Majorum (full validator set)               │
│ - Trails heartbeat by N checkpoints                  │
│ - Off critical path; inactivity leak for recovery    │
│ - BLS signatures today; PQ aggregation in future     │
└─────────────────────────────────────────────────────┘

Post-Quantum Benefits

With ~256 validators per slot:

  • Signatures can be naively concatenated (no aggregation needed)
  • 256 signatures at ~3 KB each = ~768 KB total
  • leanMultisig (zkVM targeting XMSS aggregation) can compress to ~300–500 KB
  • This means a post-quantum heartbeat can be deployed before PQ aggregation for the full validator set is solved
  • The two-layer architecture converts PQ migration from an all-or-nothing problem into two independent sub-problems

Leaderless BFT (Longer Term)

Beyond Goldfish, leaderless BFT completely removes the proposer/leader role:

  • No designated block proposer — any validator can propose transactions
  • Blocks emerge from Byzantine consensus without a leader
  • Eliminates timing games (no proposer has a privileged position to delay) and removes the primary motivation for PBS
  • Building blocks: Reliable Broadcast, Binary Byzantine Agreement (BBA), Common Coin
  • Representative protocols: HoneyBadgerBFT, Dumbo, Shoal++

MEV implication: without a designated block proposer, the current PBS model (proposer sells block production rights to a builder) no longer makes sense. MEV auctions would need to be redesigned for committee-level competition.

Open Questions

  • What exact slot time does the Goldfish/Majorum architecture target? (Vitalik proposed: 12 → 8 → 6 → 4 → 3 → 2 seconds, gradually by √2 factor)
  • Can the inactivity leak mechanism be simplified for the decoupled architecture?
  • How does the 256-validator committee selection interact with PeerDAS data custody responsibilities?
  • When does Native DVT (protocol-embedded DVT) make it into the roadmap?

Key Sources

  • Unblocking Faster Finality with Decoupled Consensus (2026) — Goldfish code + formal proofs; Majorum; 3-step fork-choice
  • Why Ethereum Needs a Dynamically Available Protocol (Luca Zanolini, Mar 2026) — impossibility result; Solana halt comparison; PQ benefit; Goldfish properties
  • Preface Research for Leaderless BFT Protocol Designs (2026) — leaderless BFT survey; MEV/timing game motivation