Ethereum’s long-term security plan recognizes that today’s cryptography won’t hold forever. The Ethereum Foundation’s public roadmap calls for proactive quantum resistance to secure the chain “for centuries to come.”

Lean Ethereum is the initiative that translates this intent into concrete protocol work. Pier Two is proud to be one of the client teams committed to building Lean Ethereum. The quantum resistance motivation is straightforward: today’s widely used signature schemes (ECDSA and BLS) rest on assumptions that sufficiently powerful quantum computers could threaten. Lean pivots Ethereum toward hash-centric building blocks that we understand deeply and can reason about in formal models. In practice, that means exploring hash-based signature families and aggregation strategies that keep validator operations simple, bandwidth predictable, and finality fast enough to preserve Ethereum’s user experience.

As part of this effort, Pier Two is developing Lantern, a C implementation of the Lean consensus client. From 4–6 October 2025 in Cambridge, UK, our team attended the PQ interop to meet researchers shaping the protocol and client teams bringing the specs to life. In this article we share what we learned at the event and how we plan to contribute to the Lean consensus roadmap.

a1

Roadmap

The first public mention of a target date came when Justin Drake unveiled the proposal originally called "Beam" at Devcon in Bangkok in 2024, framing it as a multi year redesign of Ethereum's consensus layer. The proposal was later rebranded as "Lean" in 2025 when Drake published the public Lean roadmap. At the PQ interop event in Cambridge he reiterated that the schedule remains unchanged, with a target year of 2028; his introductory talk is available on YouTube.

Between now and any mainnet hardfork, there are two buckets that will consume the majority of the work and calendar time. First is formal verification and specification hardening: Lean explicitly calls out formal verification, minimal modules, and provable security as a core part of the craft, and much of the protocol timeline depends on turning designs into machine checked proofs, verified reference implementations, and auditable invariants. Those are deep engineering tasks that benefit from new tooling and steady review cycles.

Second is devnets and multi client testing. The community has already organized a PQ devnet series and readiness plans that treat devnets as the primary mechanism for reducing risk: short life multiclient nets, interop tests, and postmortems are how parameter choices, network effects, and operational UX are validated before any production transition. Running those devnets, iterating specs based on measured metrics, and scaling each iteration to more realistic validator sets is expected to take dozens of engineering sprints across teams.

Post Quantum Signatures

In Ethereum’s proof of stake design, digital signatures are the core evidence that a validator created or attested to a message. They protect block proposals, attestations, and the entire economic safety model that enables finality. The current stack leans on BLS for compact aggregation and fast verification, but those schemes rest on elliptic curve and pairing assumptions that a sufficiently powerful quantum computer could break. That risk is why Lean is actively exploring existing post quantum signature options: https://leanroadmap.org/

The most practical direction under study is hash based signatures, especially stateful schemes like XMSS, which draw security from the properties of hash functions. Standards bodies have endorsed these for long term protection because they rely on primitives that are relatively straightforward to analyze for quantum resistance. That makes them appealing as either a stopgap or a durable choice for a system that must stay secure for decades. However, unlike BLS, many hash based approaches are stateful and limit how many messages a single key can safely sign, which pushes protocol decisions about key life cycles and requires tools for rotation and backups.

a2

Source: https://drive.google.com/file/d/1bO3-eXZTsCfMy2QCqC3yiT2RNAlpdULx/view

The Cambridge discussion focused on real world trade offs. Hash based signatures often have larger signatures and demand careful record keeping to prevent one time key reuse. These factors influence gossip bandwidth, block size planning, and storage. Recent benchmarks and parameter studies, including work published in 2025, show how parameter choices affect public key and signature sizes, the number of signatures allowed per key, and verification speed. Protocol designers are giving users flexibility in how they manage validator keys, for example by giving them to ability generate up to $2^{32}$ secret keys to allow sufficient resusable windows that fit their operational needs. At the same time, implementation work is reducing the storage and metadata overhead of hash sig key material so keys can support longer lifecycles; see the experimental hashsig repository and its recent pull request for compact key storage ideas.

How This May Effect Staking in Future

This early work suggests validators will need to shift operations in a few compact ways while the spec is still settling. These notes are speculative and early stage.

  • Key lifecycle and tooling become central. If Lean adopts stateful hash based schemes like XMSS or LMS validators will need reliable key rotation tracking and backup workflows to avoid one time key reuse.
  • Larger signatures raise network and storage needs. Gossip and block payloads may grow so validator hardware and bandwidth recommendations could change.
  • Aggregation and economics will evolve. Without cheap pairing based aggregation new merkle or hash multisig approaches or heavier per validator costs may alter reward and slash models.
  • Centralisation risk grows without simple reference tooling. Custodial and managed validator services may expand unless lightweight secure implementations and wallets appear.

These are informed guesses useful for planning but still provisional. The Lean specs are evolving quickly and updates appear in the official leanSpec repository on GitHub: https://github.com/leanEthereum/leanSpec

Devnets

During the initial development of Beacon Chain, there was often a lack of feedback loop between protocol researchers and client implementers: designs were proposed in spec meetings and papers, and client teams implemented them in isolation, with limited opportunities to exercise changes together under real network conditions. Devnets are meant to close that gap by providing a practical bridge between specification and operation. A devnet is a coordinated, short lived network run by researchers, client teams, and operators to integrate new protocol changes, test multi client interoperability, collect real telemetry, and validate assumptions before larger scale rollout.

At the PQ interop event, on the third day the community successfully demoed Devnet 0 to prove P2P cross client interoperability and messaging semantics. The following client teams participated in that demo:

For Pier Two, devnets are where we will be most active. Lantern will be exercised in multi client PQ devnets, producing the test vectors, telemetry, and interoperability fixes that turn research into operational code. Our practical contributions will include shipping Lantern images for devnet runners, integrating the PQ signature container and SSZ types, adding the metrics hooks that protocol teams need to evaluate gossip and verification behavior, and publishing postmortems.

Our Progress

Pier Two kicked off this effort by building a set of C libraries intended to provide the low level plumbing Lantern needs to be a first class Lean client. The first library we completed was an SSZ implementation, available at https://github.com/Pier-Two/c-ssz/tree/main/src, which reached completion in February 2025.

Since March 2025 we have been developing a C implementation of libp2p at https://github.com/Pier-Two/c-libp2p. This work focuses on the networking primitives and protocol framing required to participate in multi client devnets. The implementation is progressing steadily; the remaining major task is implementing the gossip sub system, which is the last piece of P2P functionality before Lantern can join an upcoming PQ devnet. Completing gossip sub will let us exercise real world message propagation, subscription semantics, and the metrics hooks that protocol teams rely on for evaluation.

Looking ahead, Devnet 1 is targeted for mid November 2025 and will be the first devnet to run one of Lean’s core technologies end to end: post quantum signatures. Pier Two will use that devnet to run Lantern in a multi client environment, produce test vectors, collect metrics on gossip and verification behavior, and iterate on any interoperability fixes that surface. Our goal is to turn these learnings into concrete improvements so subsequent devnets land faster and the path from research to production is evidence driven.