# Post-Quantum Devnet-1 Plan - ReamLabs’ View

*To learn more about the overall Lean Consensus effort, its research and development progress, we recommend checking out beamroadmap.org. Also check out our [ReamLabs website](https://reamlabs.com) to learn more about our team.*

---

Following our participation at [Beam Day during EthCC\[8\]](https://hackmd.io/@willcorcoran/BkZ-gs5Bll) in Cannes, we are excited by the shared enthusiasm surrounding the Lean Ethereum Consensus effort, especially the [initiative to develop the first Post-Quantum testnet](https://hackmd.io/@willcorcoran/SyHBto9See). We look forward to collaborating with all teams to achieve the first devnet/testnet for the Lean Consensus effort.

Given the rapid pace of research progress in each sub-specification, **we favor many iterations of “incomplete devnets” over a wait to build a “complete testnet” of the full specs**. This is so that implementation can be parallelized/interleaved with speccing, feedback loops between research and engineering are tightened, speccing gaps are discovered sooner, and therefore ultimately shortening the time to production-readiness.

This inaugural devnet should be the **testing ground for how the Lean Consensus effort can be coordinated between researchers and both existing and new client teams alike**. It will be the first “integration tests” of multiple components of the Lean Ethereum Consensus, giving researchers and client teams the first glimpse into how the sub-specs work together, not as standalone components but as a consensus client, and identifying missing gaps to turn a specification into an implementation.

Because of how relatively fragile and fast moving the specifications are at this stage, this devnet **should not be intended for public use**, i.e. validator set will be whitelisted, block explorer will be minimal, short-lived and likely unstable, etc.

We anticipate that we will face many unknown unknowns. Therefore, we propose that the first devnet is **feature-limited** to PQ-signing and propagation of blocks and attestations only. The devnet development should be **timeboxed and completed by December 2025**, in order to carry over the knowledge and lessons learnt to a fresh start and potentially more feature-complete devnets and testnets in 2026.

Critical questions that require resolution and consensus across all participating teams before proceeding with any detailed planning, due to their highly consequential nature, include:

1. What are the objectives of this devnet that **absolutely require interop**?
2. What is the **timeline** for executing and completing this devnet?
3. Who needs to be involved? And the key person from e.g. **client teams, PQ signature and networking sub-specs authors**

Along with the view above, we would like to propose the PQ Devnet-1 Plan below, which is our initial draft of how we envision the devnet be planned and executed. We hope the document can be the starting template for the coordination between researchers, all client teams and all related participants to achieve PQ Devnet-1. All feedback and suggestions are welcomed and we are more than happy for the community to have a shared ownership over this document.

---

# Objectives

## Primary Objectives

1. **Prove PQ signature viability:** Demonstrate that hash-based multi-signatures with the proposed parameters can operate within Ethereum's timing constraints (sub-second signing/verification)
2. **Validate multi-client interoperability:** Ensure all participating client implementations can sync and validate each other's blocks and attestations within Ethereum’s timing constraints
3. **Validate resource requirements:** Confirm whether the devnet with minimum sub-specs can operate within [EIP-7870](https://eips.ethereum.org/EIPS/eip-7870)’s hardware constraints (CPU, memory, storage)
4. **Identify specification gaps:** Discover missing or ambiguous elements in PQ signature and other parts of the specs through implementation attempts

## Secondary Objectives

1. **Establish common metrics and performance baselines:** Create reference benchmarks for future PQ signature implementations to target
2. **Develop multi-client coordination protocols:** Establish effective processes for coordinating development priorities and devnets across teams. Feedback into future development estimates based on devnet implementation experience
3. **Document implementation challenges:** Identify missing specifications, operational issues, integration difficulties, performance bottlenecks and optimization opportunities.
4. **Create reusable testing infrastructure:** Build monitoring, benchmarking, and analysis tools that can be reused for pqdevnet-2 and beyond

# Target Features

## Signature

- Reference papers:
- [Hash-Based Multi-Signatures for Post-Quantum Ethereum](https://eprint.iacr.org/2025/055)
- [At the Top of the Hypercube \-- Better Size-Time Tradeoffs for Hash-Based Signatures](https://eprint.iacr.org/2025/889)
- Specs:
- **\[TBC\]** Parameters
- Hash chains: 64 (chosen for efficiency and power of two)
- Chain length: 8 (chosen for efficiency and power of two)
- Max lifetime: 2^18
- Reference implementation: [https://github.com/b-wagn/hash-sig](https://github.com/b-wagn/hash-sig)

## Signature Aggregation

- No signature aggregation yet for this devnet. Each attester is expected to receive each individual attestation from other attesters.

## Types & Containers

- Root: `Bytes32`
- PubKey: **[TBD by PQ sub-specs]**
- PQSignature: **[TBD by PQ sub-specs]**
- Validator:
- index: `uint64`
- pubkey: `PubKey`
- BlockHeader
- slot: `uint64`
- proposer\_index: `uint64`
- body: `Root` (of empty block)
- signature: `PQSignature`
- Attestation
- slot: `uint64`
- attester\_index: `uint64`
- signature: `PQSignature`

## Serialization & Hashing

- Serialization: [https://ethereum.github.io/consensus-specs/ssz/simple-serialize/](https://ethereum.github.io/consensus-specs/ssz/simple-serialize/)
- Hashing: Poseidon2
- Paper: [https://eprint.iacr.org/2023/323](https://eprint.iacr.org/2023/323)
- Reference implementation: [https://github.com/HorizenLabs/poseidon2](https://github.com/HorizenLabs/poseidon2)

## Consensus

- No global consensus mechanism. Each validator only verifies the received attestations and tallies up each block’s attestations locally.
- A block is justified when the validator receives valid individual attestations from 2/3 of the validators.
- A block is finalized when its child block becomes justified.
- Block validation
- Validate only slot number
- Does not refer to parent block
- Exclusions
- No beam committees (i.e. attester committees)
- No sync committees
- No RANDAO. Use round-robin proposer selection by validator_index

## Networking

- Transport: QUIC on IPv4
- Multiplexing: QUIC’s built-in multiplex
- Gossipsub v1.1
- `beam\_block`
- `beam\_attestation`
- Req/Resp domains
- Out of scope

# Success Criteria

- The network is able to justify and finalize at least `300 x NUM_CLIENT_IMPLEMENTATIONS` blocks
- Full block pipeline finishes within 6 seconds (all validators received and verified all attestations for the current slot)
- Block proposal
- Each block is signed within 1 second (ideal target: 500us)
- Each block is propagated within 1 second
- Attestation
- Each block is verified within 1 second upon receival (ideal target: 300us)
- Each attestation is signed within 1 second (ideal target: 500us)
- Each attestation is propagated within 1 second
- Benchmark is produced with metrics defined in Instrumentation & Metrics section

# Parameters

- NUM\_CLIENT\_IMPLEMENTATIONS \= `[number of participating clients]`
- MIN\_GENESIS\_ACTIVE\_VALIDATOR\_COUNT \= `10 * NUM_CLIENT_IMPLEMENTATIONS`
- SLOT\_TIME\_SECONDS \= `12`

# Test Infrastructure

- **\[TBC\]** What infrastructure will the devnet be run on? And costing
- **\[TBC\]** Who is responsible for setting up the infrastructure?
- **\[TBC\]** What is the separation of responsibility between client team and infrastructure person/team?

# Readiness Checklist

Prerequisite activities before starting pqdevnet-1 execution.

| | Researcher | Client Team 1 | Client Team 2 | Client Team … |
| :---- | ----- | ----- | ----- | ----- |
| PQ-sig directional paper is published | ✅ | Not Applicable | Not Applicable | Not Applicable |
| PQ-sig specification is published | ⏳ | Not Applicable | Not Applicable | Not Applicable |
| PQ-sig reference implementation is published | ⏳ | Not Applicable | Not Applicable | Not Applicable |
| pqdevnet-1 specs[^1] reached consensus with \>= 2 clients | ⏳ | ⏳ | ⏳ | ⏳ |
| Client implemented pqdevnet-1 specs & passing reference tests[^2] | Not Applicable | ⏳ | ⏳ | ⏳ |
| Client successfully ran their single-client devnet for 200+ slots | Not Applicable | ⏳ | ⏳ | ⏳ |

# Genesis State

- `get_active_validator_indices() > MIN_GENESIS_ACTIVE_VALIDATOR_COUNT`
- **TBD: how to compute** `get_active_validator_indices()`

# Instrumentation & Metrics

## Instrumentation

- Structured JSON logging format following [OpenTelemetry logging standard](https://opentelemetry.io/docs/concepts/signals/logs/#log-record)
- The metrics SHOULD behave under the guidelines set by the [Prometheus documentation](https://prometheus.io/docs/practices/instrumentation/#things-to-watch-out-for)
- A shared instance of Prometheus, Loki, Grafana for shared visibility **(TBD: ownership)**

## Tracing

- `key_generation`
- `block_signing`
- `block_validation`
- `attestation_signing`
- `attestation_validation`
- `block_pipeline` (from start of slot time to all attestations received)

## Logging

- `key_generation_started`
- `key_generation_completed`
- `network_peer_connected`
- `block_created`
- `block_published`
- `block_received`
- `block_validated`
- `attestation_created`
- `attestation_published`
- `attestation_received`
- `attestation_validated`
- It should also log the count of its known valid attestations for the same slot

## Metrics

*Inspired by [https://github.com/ethereum/beacon-metrics/blob/master/metrics.md](https://github.com/ethereum/beacon-metrics/blob/master/metrics.md)*

| Name | Metric Type | Usage | Sample collection event |
| :---- | :---- | :---- | :---- |
| libp2p\_peers | Gauge | Tracks the total number of libp2p peers | On peer add/drop |
| beam\_head\_slot | Gauge | Latest slot of the chain | On fork choice |
| beam\_finalized\_slot | Gauge | Current finalized slot | On slot transition |
| beam\_justified\_slot | Gauge | Current justified slot | On slot transition |
| beam\_current\_active\_validators | Gauge | Current total active validators | On slot transition |

### Optional Metrics

| Name | Metric Type | Usage | Sample collection event |
| :---- | :---- | :---- | :---- |
| process\_cpu\_load | Gauge | Current CPU load | Every second |
| process\_memory\_usage | Gauge | Current memory usage (MiB) | Every second |
| process\_storage\_usage | Gauge | Current storage usage (MiB) | Every second |
| process\_upload\_throughput | Gauge | Current upload throughput (Mb/s) | Every second |
| process\_download\_throughput | Gauge | Current download throughput (Mb/s) | Every second |

# Timeline

| Date | Target |
| :---- | :---- |
| 31-Jul-2025 | PQ-sig specifications & reference implementations published |
| 31-Aug-2025 | pqdevnet-1 specifications reach consensus (researchers \+ all participating clients) |
| 30-Sep-2025 | Client implementation |
| 31-Oct-2025 | Client implementation |
| 20-Nov-2025 | Successful single-client devnet by all participating client teams |
| 20-Dec-2025 | Successful multi-client devnet |

# Communications

- Bi-weekly sync on Google Meet
- A new channel on Eth R\&D discord for cross-team communication & visibility to other core devs & client teams

# Contacts

Contacts should include

- Overall coordinator for the devnet effort
- Key contact person(s) of each client team
- Authors of the relevant subspecs

# Rationales

## Naming: Devnet vs. Testnet

- **Devnet:** A devnet is a private, controlled environment used by protocol developers to test new features, consensus mechanisms, and network upgrades before deploying them to public testnets or mainnet.
- **Testnet:** A testnet is a public environment that mimics mainnet functionality using test tokens, allowing developers and users to test applications and protocol upgrades in a production-like setting. Unlike devnets, testnets are accessible to anyone and serve as the final testing stage before going live on mainnet.

In this sense, “devnet” is the more appropriate term for the scope of work.

## Multiple small devnets over mega-devnet/testnet

“Separate devnets were preferred and worked well over a consolidated mega-devnet for Pectra/Peerdas/EOF” \- [Devcon SEA R\&D Workshop on Devnets](https://github.com/ethereum/pm/blob/master/Interop-Notes/DevconSEA/R%26D-workshop/Devnets.md)

## Why no consensus mechanism?

While we aspire to implement [3-Slot Finality](https://arxiv.org/abs/2411.00558), we prefer to scope down this first devnet to achieve the primary objectives (PQ signature viability, minimum multi-client interop drill, minimum hardware requirements, sub-speccing gaps) sooner than later. 3-Slot Finality and other features can be prioritized for the 2nd devnet onwards and most likely will benefit from the feedback of the 1st devnet’s primary objectives.

## Why QUIC?

Beacon clients are [already prioritizing migrating to QUIC](https://discord.com/channels/595666850260713488/646778960830660623/1386093062002053120).

## Why `300 x NUM_CLIENT_IMPLEMENTATIONS` blocks for the success criteria

- With 2 clients, the devnet will be running for `300 * 2 * 6 / 60 = 60` minutes, which should be ample enough time to discover any issues given how minimal this devnet scope is

## Why does the success criteria use 6 seconds but slot time is 12 seconds?

The goal is to complete each slot processing within 6 seconds. The extra 6 seconds is the buffer to debug any delay issues that may arise from being the first devnet

## Why need reference tests before the Devnet initiation?

Standing on the shoulder of giants by learning from the past: “Define clear testing requirements pre-devnet participation” \- [https://github.com/ethereum/pm/blob/master/Interop-Notes/DevconSEA/R%26D-workshop/Devnets.md\#spec-tests](https://github.com/ethereum/pm/blob/master/Interop-Notes/DevconSEA/R%26D-workshop/Devnets.md#spec-tests)

## Why need a shared Prometheus, Loki and Grafana instance?

Standing on the shoulder of giants by learning from the past: “EthPandaOps to publicize their Loki instance and empower everyone with log aggregation ability for devnets” \- [https://github.com/ethereum/pm/blob/master/Interop-Notes/DevconSEA/R%26D-workshop/Devnets.md](https://github.com/ethereum/pm/blob/master/Interop-Notes/DevconSEA/R%26D-workshop/Devnets.md)

# Acknowledgements

We acknowledge the accumulated lessons learnt from the Beacon Chain launch, the merge, and all previous hardforks, including but not limited to:

- [https://github.com/djrtwo/writing/blob/main/docs/2023-02-23\_2023-Reflections.md](https://github.com/djrtwo/writing/blob/main/docs/2023-02-23_2023-Reflections.md)
- [https://cointelegraph.com/news/eth2-dev-talks-about-challenges-and-lessons-learned-ahead-of-mainnet-launch](https://cointelegraph.com/news/eth2-dev-talks-about-challenges-and-lessons-learned-ahead-of-mainnet-launch)
- [https://etherworld.co/2025/03/03/aftermath-of-holesky-testnet-incident-lessons-learned/](https://etherworld.co/2025/03/03/aftermath-of-holesky-testnet-incident-lessons-learned/)
- [https://github.com/ethereum/pm/blob/master/Pectra/holesky-postmortem.md](https://github.com/ethereum/pm/blob/master/Pectra/holesky-postmortem.md)

[^1]: Devnet specs example: [https://notes.ethereum.org/@ethpandaops/fusaka-devnet-0](https://notes.ethereum.org/@ethpandaops/fusaka-devnet-0)

[^2]: Reference tests example: [https://hackmd.io/@manunalepa/BJzNsCnvyx](https://hackmd.io/@manunalepa/BJzNsCnvyx)