--- # System prepended metadata title: FORT MODE - PQ Devnet Roadmap & Ream's View tags: [ethcc, pq, ethereum] --- # FORT MODE - PQ Devnet Roadmap & Ream's View ![Screenshot 2026-04-06 at 11.13.23](https://hackmd.io/_uploads/ryS-QhgnZe.png) This document summarizes the roundtable discussion on the PQ devnet roadmap, the closing 90-minute session of FORT MODE — a post-quantum consensus day at [EthCC[9]](http://ethcc.io/). The roundtable followed a full day of presentations covering lean consensus, PQ cryptographic foundations, fast finality, ethp2p, leanVM, leanSpec, and leanMetrics, and served as a chance for client implementers, cryptographers, and networking researchers in the room to surface concerns and align on next steps for the devnet. --- ## TL;DR - **Devnet Participation Readiness**: A formal readiness process and tiered entry system are needed as more client teams join - **Infrastructure**: Urgency to have a stable baseline; followed by aggressive scale up - **Roadmap planning**: A dedicated session proposed for the next pqinterop call where each client team pitches their ideal roadmap for the next 6 months - **Heartbeat chain**: Start with the heartbeat chain (~512 validators) running Goldfish, collect real metrics, then layer in stabilization and full finality - **Networking after finality**: Networking experiments to follow once consensus mechanics are well-defined, as the protocol requirements (who needs what data, when) must be understood before a networking design can be derived - **Aggregation hardware**: CPU-based aggregators remain the target; GPU assistance may be considered only at the final aggregation layer - **Formal verification**: Incremental verification of small stable components for now; a more ambitious Python-subset interpreter idea was floated but remains undecided --- ## 1. Devnet Participation Readiness As participation grows, ensuring a consistent level of readiness across devnet participants has become an important challenge. The main concern is that teams may join before their clients are sufficiently stable, which can affect overall network health. Key issues raised: - Some clients have been experiencing challenges with signature management - The current low barrier to entry, while welcoming and aligned with Ethereum's open values, means that network stability can be impacted before clients are fully ready - The pace of new client submissions makes it difficult for maintainers to keep up with testing and validation - Currently the process relies entirely on client teams self-reporting readiness, with no independent verification **Proposed solutions discussed:** - Requiring clients to run and pass a standardized test suite (similar to Hive) before joining a devnet — clients would simply add their Dockerfile and run through a standardized battery of tests, with a public dashboard (similar to EthPandaOps's work) showing a readiness score for each client - A **client-by-client compatibility matrix** showing which clients have been tested against each other, replacing the current self-reporting process - A **tiered/league system** (analogous to sports leagues) where new clients demonstrate readiness at lower tiers before participating in higher-stakes testnets, allowing teams to learn and grow progressively - Appointing one responsible contact person per client team to ensure node availability - Keeping well-established clients as the majority of the network while newer clients onboard gradually as a minority ## 2. Devnet Stability & Infrastructure Scaling With the current network sitting at only ~12–13 nodes, the group discussed how to scale up infrastructure in a way that unlocks benchmarking and network analysis at scale. **On scaling the devnet:** - A more dynamic infrastructure was proposed — the ability to spin up a configurable number of nodes with adjustable CPU/bandwidth settings, paying only for runtime rather than a fixed monthly cost - Tools discussed: Kurtosis (for local/smaller-scale testing with latency simulation) and Shadow (for single-machine network simulation) - Wireshark dissectors for Ethereum protocols were mentioned as a new tool for bit-accurate on-wire debugging ## 3. Roadmap Planning & Governance for Future Devnets A proposal was made to hold a roadmap planning session on the next pqinterop call, where each lean client team proposes their ideal roadmap from now until Cambridge. Consensus, networking, and other researchers would potentially be invited to provide feedback on the proposals. The motivation was that devnet feature decisions currently happen somewhat informally, and having a more structured process with shared alignment would help the whole effort move forward more effectively. ## 4. Future Devnet Feature Priorities: Fast Finality & Networking The group discussed what features to target in upcoming devnets. Two major tracks emerged: **Fast Finality:** - Integrating fast finality algorithm was discussed - The **Goldfish spec** (a branch by Francesco) was identified as the starting point, with the stabilization gadget and full finality to follow - The primary value of early devnets for finality is not security testing, but collecting **metrics and real data** from a running network - A suggestion was made to start with just the **heartbeat chain** with Goldfish at 256 – 512 validators, observe chain behavior under non-finality conditions, and layer the stabilization gadget on top later **New Networking Stack (ethp2p):** - A broad discussion took place on whether and how to co-design consensus and networking - The Beacon Chain experience was referenced as a valuable lesson: adopting an existing networking stack without deep co-design led to constraints that are still being worked around today - The recommendation was to start from first principles: define who needs which information at what time, design the protocol around those requirements, and only then think about the transport layer - The ethp2p broadcast framework could ship on top of libp2p as a non-headline EIP, providing a practical transition path - Routing and peering were identified as the most fruitful near-term research areas; transport is largely understood **Interdependencies:** The group acknowledged that consensus and networking are deeply interdependent — slot time and validator count directly affect block propagation budgets, as seen in devnet-3. A proposal was made to run simulations using the existing simulator to quantify the performance impact of introducing the broadcast framework for block propagation and attestation aggregation before committing to a design direction. Jan volunteered to run these simulations in collaboration with Raul. ## 5. Aggregation Hardware Assumptions (SNARKs / PQ Signatures) A discussion arose about what hardware to assume for aggregators — specifically **CPU vs. GPU**: - Assuming CPUs at ~1,000 signatures/second requires a **two-tier aggregation architecture** (subnet-level aggregation → global aggregation) - Assuming GPUs at ~10,000 sigs/second would allow a single large subnet with one aggregator, potentially simplifying the architecture significantly - This choice was flagged as having major downstream consequences for network design — membership, node selection, and attack surface all shift considerably depending on the answer The focus is firmly on CPU-based aggregators to keep participation accessible and democratized. The idea of a GPU-assisted aggregator at the final layer was briefly entertained but is not a near-term consideration. A related discussion touched on stake-proportional resource requirements, with a note that requiring GPUs represents a significantly heavier operational burden than, say, adding storage — and that the implications for node operators deserve careful analysis. ## 6. Formal Verification Strategy Briefly discussed toward the end of the meeting. The question of how to approach formal verification of the Lean Ethereum spec was raised, given that both the zkVM and signature scheme are still evolving. - Current approach: verify small, stable sub-components (e.g., the polynomial commitment scheme, hash functions) incrementally in Lean/Lean4 - Yoichi proposed an experimental idea: building a Lean interpreter for a subset of Python (since the executable spec is written in Python), enabling continuous comparison between the Python spec and a formally verified counterpart, using generative testing for validation — acknowledged as an unconventional but potentially interesting direction worth exploring ## Ream's View - **PQ Devnet's highest priority should be to scale up to 10,000 validators** (stretch goal based on Ethernodes's [mainnet estimation](https://ethernodes.org/)) to test and benchmark PQ signature behavior at mainnet scale. And therefore needs: - **Stricter devnet readiness criteria starting in devnet-4** that each client must have provable tests against test vectors and client-by-client compatibility matrix before entering each devnet - **Infrastructure tooling that supports 1,000 logical validators in devnet-4**, enough to test 2 aggregation subnets with 500 signatures aggregation per interval per subnet — then doubling in size with each following devnet - Even if the 10,000 validator goal is not reached, the stretch goal keeps the PQ Devnet effort directionally on track to produce production ready post-quantum consensus - The team still needs to analyze Goldfish and ethp2p more in details. However we want to propose that **any consensus or networking experimentations in PQ Devnet should only be carried out only if it serves toward the 8,000 PQ validators goal**, i.e. mainnet readiness - We look forward to share a roadmap proposal covering the next 6 months **in the next pqinterop call (Apr 8)** We will refine our view further in the coming weeks and we look forward discuss more in the pqinterop call on April 8th.