# Lean Consensus: 2026 Planning

## Introduction and Vision

Initially presented as the Beam Chain by Justin Drake at Devcon 2024, the project has been rebranded as Lean Consensus. It represents a proposed redesign of the Ethereum Consensus Layer. The primary objective is to transition from the current Beacon Chain (specified five years ago) to a modernized, final design that incorporates the latest research in Maximum Extractable Value (MEV), zero-knowledge (ZK) technology, and consensus mechanisms.

The ultimate goal is to bundle these major upgrades into a single hard fork. This approach is intended to clear accumulated technical debt and accelerate Ethereum’s path to ossification—a state of protocol stability where the consensus layer enters maintenance mode.

### The Upgrade Roadmap

The proposal categorizes upgrades into three specific buckets based on priority. This structure guides our engineering focus:

| Priority | Block Production | Staking | Cryptography |
| :--- | :--- | :--- | :--- |
| **P0** | **censorship resistance**<br>e.g. FOCIL | **smarter issuance** <br>e.g. stake cap | **chain snarkification**<br>e.g. Poseidon + zkVMs |
| **P1** | **isolated validators** <br>e.g. execution auctions | **smaller validators**<br>e.g. 1 ETH Orbit staking | **quantum security**<br>e.g. hash-based sigs |
| **P2** | **faster slots**<br>e.g. 4 seconds | **faster finality**<br>e.g. 3-slot FFG | **strong randomness**<br>e.g. MinRoot VDF |

## 2025 Retrospective: Research & Specification

The year 2025 was dedicated to verifying the feasibility of the cryptography layer, exploring the social coordination layer, and establishing theoretical bounds for fast finality.

### Social Coordination

The early part of 2025 focused on community building and technical alignment. A series of lean Consensus calls were established to present specific work buckets (cryptography, fast finality, rainbow staking, P2P, etc). These calls successfully integrated contributors from both inside and outside the Ethereum Foundation.

### Cryptography and Zero-Knowledge Infrastructure

We prioritized the cryptography layer early in 2025, identifying it as the primary engineering bottleneck due to the reliance on nascent technologies such as SNARKs and zkVMs. Work in this domain progressed through five distinct phases:

1. **XMSS Scheme Design:** The cryptography team designed and published a new XMSS variant explicitly tailored for Ethereum.

2. **Implementation & Aggregation:** Engineering efforts subsequently shifted to the practical implementation of the scheme and the analysis of signature aggregation mechanics.
3. **Aggregation Strategy:** A significant portion of the year was dedicated to architecting the aggregation method. The selection of the underlying scheme—whether relying on custom circuit design, a specific zkVM, or folding schemes—is critical as it dictates the simplicity, security, and scalability of the consensus layer. This remains an active and sensitive area of research.
4. **LeanVM Design:** To support high-throughput aggregation, we initiated the development of a dedicated minimal zkVM. This effort entailed full-time work of Emile on the VM architecture (LeanVM) and the optimization of underlying primitives, specifically the WHIR polynomial commitment scheme and Plonky3.
5. **Specification:** Recent focus has expanded a bit toward formal specification. We are currently drafting a clean, executable Python specification to bridge the gap between experimental research and client implementation.

**Challenges and Successes**

We have encountered specific technical hurdles, particularly regarding the XMSS encoding scheme—which requires further optimization for zk-friendliness—and the aggregation performance of the LeanVM.

However, these challenges are balanced by significant collaborative successes. Engagement with client teams has been productive, yielding active spec reviews and bug identification. Furthermore, our cryptographic efforts have been bolstered by collaboration with external talent, culminating in the Cambridge PQ workshop where the best experts were present and ready to collaborate to this huge effort.

### Fast Finality Research

Throughout 2025, the Consensus Research team at the EF intensified its focus on fast finality. This research culminated in novel designs that align with the architectural goals of the original lean Consensus proposal, specifically targeting lower latency and higher fault tolerance. Key initiatives included:

* **Asynchrony-Resilient Finality Gadgets (ARFG):** The team explored architectures that decouple availability from finality, specifically integrating ARFGs with high-throughput Available Chains. This separation allows the network to maintain a responsive user experience even during periods of instability.

* **Liveness-Favoring BFT Protocols:** Researchers, including Yann Vonlanthen, proposed protocol optimizations for adverse scenarios where the actual fault count ($t$) exceeds the theoretical safety threshold ($f$). These designs prioritize chain progress and liveness, ensuring the network can continue to function even when finality is temporarily halted.

## Technical Architecture Reference

The 2025 research phase crystallized a new architectural standard for the Ethereum Consensus Layer. This blueprint, established through rigorous analysis and prototyping, forms the foundation of our 2026 engineering plan.

### Cryptography: The Post-Quantum Shift

We are transitioning the consensus layer from the Proof-of-Stake era to the zk era. The core architectural shift replaces BLS signatures with hash-based signatures, simultaneously achieving quantum resistance and SNARK-friendliness.

**XMSS (eXtended Merkle Signature Scheme)**
* **Generalized Framework:** We utilize a generalized XMSS framework rather than a rigid instance. This employs a many-time signature structure where a Merkle tree commits to a sequence of one-time public keys (Winternitz chains). The Merkle root functions as the validator's persistent public key.
* **Poseidon2 Integration:** To optimize for circuit efficiency within the aggregation layer, the design exclusively uses the Poseidon2 hash function. This replaces SHA-256 to minimize constraint overhead in the zkVM.
* **Standard Model Security:** We aim to prove security based on explicit Standard Model properties, such as multi-target collision resistance, offering a more rigorous security guarantee.

### The Aggregation Engine: LeanVM

Aggregating thousands of post-quantum signatures requires a specialized execution environment. We are developing LeanVM, a minimal zkVM purpose-built for high-throughput recursive aggregation.

**Design Specifications:**
* **KoalaBear Field:** The VM operates on the KoalaBear prime ($p = 2^{31} - 2^{24} + 1$). This small field size allows elements to fit within standard 32-bit integers and enables highly efficient S-boxes for Poseidon2.
* **Deterministic Architecture:** The architecture is a simplified ISA with a read-only memory model.
* **The Precompile Bus:** To achieve the target throughput of 1,000 signatures/sec, the VM offloads heavy cryptographic operations via a Logup* integration bus. Key precompiles include:
* `POSEIDON_16` / `POSEIDON_24`: Native permutations.
* `DOT_PRODUCT`: Accelerated linear algebra for vector operations.
* `MULTILINEAR_EVAL`: Polynomial evaluation supporting the **WHIR** Polynomial Commitment Scheme.

### Consensus: The Decoupled Protocol

The consensus discussions have evolved recently into a hierarchical Decoupled Protocol (things can continue to evolve). This architecture separates the chain into three distinct layers, optimizing for speed at the tip and absolute security at the base.

**Layer 1: ChFast (The Available Chain)**
* **Protocol:** **Goldfish** (based on GHOST-Eph).
* **Role:** High-throughput, low-latency block production.
* **Logic:** Uses an Ephemeral fork-choice rule that only considers votes from the immediately preceding slot ($\Delta_{AC}$), anchored to the latest stable checkpoint from Layer 2.

**Layer 2: ChMaj (The Majority Chain)**
* **Protocol:** **RLMD**.
* **Role:** Filters the probabilistic ChFast into a justified chain using majority votes ($>50\%$).

**Layer 3: ChFin (The Finalized Chain)**
* **Protocol:** **BFT** (Byzantine Fault Tolerance).
* **Role:** Provides economic finality and accountability.

**The ARFG & The Synchronizer**

Layers 2 and 3 combined form the Asynchrony-Resilient Finality Gadget (ARFG). A critical innovation in this layer is the replacement of the traditional Block Proposer with a Synchronizer.
* **Role:** The Synchronizer does not produce blocks (this is isolated to ChFast).
* **Function:** Its sole responsibility is network alignment—broadcasting a view to ensure honest validators converge on the same data set, facilitating rapid "healing" after periods of asynchrony.

**Liveness-Favoring Variants**

To handle adverse network conditions, researchers from the EF are thinking about Liveness-Favoring protocols (e.g., Live-Simplex, Live-Minimmit). These variants allow the system to progress through views and maintain an inactivity leak even if the number of active replicas drops below the standard finalization threshold ($t > f$), provided at least $2f+1$ replicas remain online.

## 2026 Engineering Roadmap: Implementation and Integration

The primary objective for 2026 is to transition from research feasibility to production-grade implementation. The year will focus on concretizing the cryptographic schemes, optimizing the aggregation environment, and validating the consensus architecture through rigorous multi-client interoperability testing.

### Post-Quantum Cryptography and Aggregation

The priority is to fully derisk the XMSS signature scheme and the LeanVM aggregation pipeline, ensuring they meet strict security and performance standards.

* **XMSS Security Analysis:** Conduct a comprehensive gap analysis between the best-known attacks and provable security bounds for the chosen XMSS parameters. The goal is to verify the security of the encoding and tweaking mechanisms without relying on overly conservative parameters.
* **LeanVM Performance Targets:** Achieve specific throughput metrics for the minimal zkVM:
* Aggregate **1,000 XMSS signatures per second**.
* Execute a 2-to-1 recursive proof aggregation in approximately **200ms**.
* **Architectural Simplicity:** Reduce the complexity of the LeanVM architecture. The logic should be as comprehensible as the XMSS scheme itself for example (explainable in under 30 minutes to a beginner) to facilitate auditing and correctness.
* **Reliability and Testing:** Establish a robust testing suite for the VM, including unit tests, fuzzing, and formal verification efforts, aiming for 128-bit provable security.

### Optimization of Cryptographic Primitives

We will refine the underlying cryptographic primitives to ensure the proving system is efficient enough for mainnet constraints.

* **Plonky3 Enhancements:** Implement low-level optimizations in Plonky3, including SIMD vectorization, matrix operation improvements, and FFT optimizations.
* **WHIR Stability:** Finalize the WHIR Polynomial Commitment Scheme. We aim to implement identified optimizations (e.g., sumcheck, Fiat-Shamir improvements) to reach a stable, high-performance version that can be upstreamed to Plonky3.

### Consensus Logic and Fast Finality

We will formalize the Fast Finality research into executable specifications and simulation tools.

* **Specification Integration:** Incorporate the chosen Fast Finality design (e.g., Live-Simplex, Live-Minimmit, or ARFG) into the official Lean Consensus specifications.
* **Simulation Environment:** Develop a Python-based simulation playground. This tool will allow researchers to model various proposals (such as 2-Slot vs. 3-Slot Finality) and generate empirical data regarding complexity, latency, and fault tolerance beyond theoretical models.

### Devnet Milestones and Interoperability

The engineering cycle will culminate in long-running developer networks that validate the interaction between the Available Chain and the Finality Gadget under realistic network conditions.

* **Multi-Client Interoperability:** Achieve a stable devnet featuring at least 5 distinct client implementations (e.g., Lantern, Qlean, Ream, Zeam).
* **Scale Testing:** Deploy a long-running devnet (duration >1 month) supporting 10,000 validators to test system stability and epoch processing at scale.
* **Network Performance:** Validate P2P topology and propagation latencies, targeting the propagation of a 256KB SNARK in under one second.
* **Release Cadence:** Establish a goal of monthly devnet launches, progressively integrating new features.

### Specification and Tooling

We will continue to refine the Python executable specification to serve as the reference implementation for client teams.

* **Spec Quality:** Modernize the codebase to ensure it is lightweight, modular, and extensively documented.
* **Client Onboarding:** Use the specification as the primary onboarding tool for existing Ethereum client teams. The focus will be on code clarity and reviewability to minimize implementation friction and identify consensus bugs early in the development cycle.