# 2026 stretch goals | PQ interop

## Prompt
#### What do you think a realistic but aggressive stretch goal for lean consensus in 2026 looks like?
- ➡️ **Fuctionality + Features**: Specifically, one year from now, what functionality should we aim to have in a devnet that would meaningfully cap off a successful 2026?
- ➡️ **Performance Metrics**: Alternatively, what key performance or reliability metrics should the final 2026 devnet hit?

## Feedback | Ethereum Foundation

#### Thomas Corateger (EF researcher, PQ consensus)
>So, in my opinion, I'd like to look at two distinct objectives if we're projecting 12 months from now.

>First, I'd like to see a devnet running realistically with the leanVM or an equivalent solution, capable of aggregating signatures and handling recursion without any issues and with the required performance. Currently, we're below expectations for the leanVM, and we haven't even tackled recursion yet. So, a great objective would be to solve this problem and have a realistic testnet running. An even more ambitious objective would be to already have the mainnet performance on the leanVM, even if we don't immediately need it for the devnets (1000 signatures aggregated per second and 2-to-1 recursive aggregation in 100ms).

>On the other hand, I'd like to see the research on fast finality come to fruition and have a global consensus among EF researchers to ship something in devnet at this level as well. It's completely separate from the post-quantum part, but it's something that also makes sense.

#### Emile (EF researcher, PQ consensus)
##### XMSS:
>Having a clear understanding of the best known attacks against XMSS (and the encoding). Ideally, having tight result: i.e. having the security from best known attacks very close to provable security (to be 100% sure our signatures are optimal on all the levels: signature size, number of hashes, zk friendliness of the encoding / of the tweak etc).
(For context, my intuition (and hope) is that the current XMSS parameters are overly conservative, and that there is some good juice to press here. But I don't have a formal proof, so maybe I am wrong).

##### Snark:
>Having 100% implemented the aggregation of XMSS via snark, + recursive aggregation (!!). Verifier code is clean and relatively short. Prover code is fast: > 1000 XMSS/s, < 0.25s for 2->1 recursion on a good laptop cpu.
Security: Formal verification has started, we are confident it will eventually work. No critical bugs are found in the zk-VM.
zkVM is at 128 bits of provable security.
Proof size when the proof generation is fast (resp slow) is bellow 400 KB (resp 250KB).

##### Proxmity gaps:
>In a ideal world, the conjecture is proven end of 2026, with good constants, which enables to further reduce proof size of our snarks.

#### Benedikt (EF researcher, cryptography)
>Functionality + Features: I would hope that we have signature aggregation using leanVM, with 128 bit provable security. With > 1000 signatures in reasonable aggregation time.

#### Felipe Selmo (leanSpecs + testing)
>I think the answer here has to be something to pill (lean) skeptics. Advances in real-time proving with appropriate security for key generation, working example of significantly shorter slot times and block propagation.

## Feedback | lean client teams
#### Lantern | Mihir
>From a development perspective, I think a good goal would be to have all Lean clients in a position where it is possible to launch one devnet per month, each with new features that will end up in the final hardfork.

>For this year (2025), we are hoping to successfully participate in Devnet 1, as that would give us confidence that Lantern can interop correctly with other clients. This would help accelerate progress toward Devnet 2, if the client teams are okay with Devnet 2’s timeline being December.

#### Qlean | Kamil'
>Sure, I think feasible goals for functionality/metrics might be:
>1. Implementation of a full pipeline of signature aggregation (subnets + global subnet). Metric: aggregation in under 2 seconds given 4096 validators and 3 KB signatures.
>2. Erasure-coded SNARK propagation. Metric: propagation of 256 KB SNARK in under a second.
>3. New consensus design (the current form of 3SF is not very very friendly to subnet aggregation).

#### Ream
##### Unnawut "O"
>**2026 (stretch!)**
>leanMultisig integrated
>5-client interop
>2-slot finality
>10,000-validators devnet
>long-running devnet (>1 month)
>6-minute zkCheckpoint (?)
>Snarkified PeerDAS (?)


##### Jun
>Basically I define PQ devnet as a sandbox or isolated environment for all cryptographic primitives that we need for lean consensus. This includes hash-based signature for a leaf signature and aggregation using leanVM. If we witness the metrics that it is doable with 1000+ physical nodes using post-quantum secure signatures, I think the result supports some promising future for us. Maybe p2p can be part of lean consensus but personally I prioritze those cryptographic primitives.

>Seems like 3SF and 4s slot time can be great marketing words if we fully achieve those with PQ signature, but if we don't prioritize cryptographic stuffs, it wouldn't be the best strategy that we can take. Maybe we might have to sacrifice the 4s slots if we favor signature aggreagtion (which takes quite a lot of time at this moment, hopefully there'll be some significant progress in next months)

#### Zeam
##### Gajinder
>I think the aim of lean consensus by end of 2026 should be what we want the lean hardfork to look like
>- PQ signatures, aggregation (2025)
- P2P topology experiments and optimizations for sig aggregators (2026)
> - full EL<>CL block proving (do we do this on EPBS model) so that a validator is just a lean ethereum node
- Poseidon hasher for SSZ
- enshrined leanVM?
> - Rainbow staking - validators only attests and do FOCIL and auction execution block (EPBS)
> - 1 eth validators
> - mobile
>- Final model for consensus 2SF/3SF/1SF

##### Guillaume
>Performance metric is pretty easy I think: whatever the test net contains, it's got to be running a combination of all clients, with active fuzzing, different locations worldwide, and not skip a beat.

## Feedback | external researchers
#### Katya (leanMetrics)
>Functionality + Features:
>- ZKVM implementation, at least 2-3 diversity options referring to the progress of the proof teams from EthProofs Day.
>- the final signatures scheme, tested and implemented.
>- one solid tool for devnets (Kurtosis, lean-start or any other).

>The other "non-lean" components could be borrowed later from EL/CL clients (networking part, APIs, etc).

>Performance:
>- solid devnet with the Fuctionality + Features implemented in minimum 3 clients using one tool
>- should feat into 4 sec slot (optimistic)

>For other metrics it's hard to announce any spesific values right now. Probably there will be more updates after running interop devnet-0 and devnet-1 metrics. I guess, researcher might have more clear picture.