New post on EthResear.ch!
Why Ethereum Needs a Dynamically Available Protocol
By:
- Luca Zanolini
🔗 ethresear.ch/t/24418
Highlights:
- Dynamic availability should be a strict requirement for Ethereum’s next heartbeat layer: the chain should stay safe and keep producing blocks as long as a majority of the currently awake stake is honest (offline validators shouldn’t count against liveness).
- This property improves resilience, self-recovery, and censorship resistance: Ethereum can continue operating through client bugs, cloud/ISP outages, or adversarial censorship attempts, without requiring coordinated “everyone restart now” social recovery.
- A two-layer design (dynamically available heartbeat + trailing finality gadget) is not just an optimization; it is forced by the availability-finality dilemma (a CAP-like impossibility result): you cannot simultaneously guarantee liveness under dynamic participation and safety under network partitions in a single protocol.
- Off-the-shelf BFT protocols (PBFT/Tendermint/HotStuff) assume a mostly-awake fixed validator set and tend to halt when participation drops, which doesn’t match Ethereum’s real-world operating conditions; meanwhile, current LMD-GHOST cannot be proven dynamically available due to known adversarial strategies.
- Protocols like Goldfish (and related designs such as RLMD-GHOST) aim to provide a provably dynamically available heartbeat with small per-slot committees (~256 validators), enabling faster slots (no multi-round attestation aggregation) and offering a practical near-term path to a post-quantum heartbeat by avoiding the need for large-scale signature aggregation.
ELI5:
Ethereum needs to keep making blocks even when lots of validators “fall asleep” (go offline). The article argues for splitting Ethereum’s consensus into two parts: (1) a fast “heartbeat” chain made by a small randomly chosen group so blocks keep coming no matter what, and (2) a separate finality system that later “locks in” those blocks permanently. This split is necessary because you can’t have one single system that both never stops during outages and also stays perfectly safe during network splits. Using a small heartbeat committee can also make blocks faster and help Ethereum switch to post-quantum signatures sooner.
Why Ethereum Needs a Dynamically Available Protocol
By:
- Luca Zanolini
🔗 ethresear.ch/t/24418
Highlights:
- Dynamic availability should be a strict requirement for Ethereum’s next heartbeat layer: the chain should stay safe and keep producing blocks as long as a majority of the currently awake stake is honest (offline validators shouldn’t count against liveness).
- This property improves resilience, self-recovery, and censorship resistance: Ethereum can continue operating through client bugs, cloud/ISP outages, or adversarial censorship attempts, without requiring coordinated “everyone restart now” social recovery.
- A two-layer design (dynamically available heartbeat + trailing finality gadget) is not just an optimization; it is forced by the availability-finality dilemma (a CAP-like impossibility result): you cannot simultaneously guarantee liveness under dynamic participation and safety under network partitions in a single protocol.
- Off-the-shelf BFT protocols (PBFT/Tendermint/HotStuff) assume a mostly-awake fixed validator set and tend to halt when participation drops, which doesn’t match Ethereum’s real-world operating conditions; meanwhile, current LMD-GHOST cannot be proven dynamically available due to known adversarial strategies.
- Protocols like Goldfish (and related designs such as RLMD-GHOST) aim to provide a provably dynamically available heartbeat with small per-slot committees (~256 validators), enabling faster slots (no multi-round attestation aggregation) and offering a practical near-term path to a post-quantum heartbeat by avoiding the need for large-scale signature aggregation.
ELI5:
Ethereum needs to keep making blocks even when lots of validators “fall asleep” (go offline). The article argues for splitting Ethereum’s consensus into two parts: (1) a fast “heartbeat” chain made by a small randomly chosen group so blocks keep coming no matter what, and (2) a separate finality system that later “locks in” those blocks permanently. This split is necessary because you can’t have one single system that both never stops during outages and also stays perfectly safe during network splits. Using a small heartbeat committee can also make blocks faster and help Ethereum switch to post-quantum signatures sooner.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
