# Ethereum PQ Interop 4-6 Oct '25 Notes

I took part in the Ethereum post-quantum interop between 4-6 October 2025 at Cambridge. This post is a braindump of all the learnings of the sessions I attended.

## Day 1, 4 Oct

We started with some intro sessions of all the tracks over the next few days. Playlist is [here](https://www.youtube.com/watch?v=7it17ANqdBE&list=PLJqWcTqh_zKGPctGzVOBllZnCPQj-g7d3&index=5)

During day 1, we had a devnet spec session and a P2P session which kind of merged into the same discussion, so I will write them as such.

The devnet session was led by Unnawut, and the P2P session by Raul.

### Devnet / P2P discussion

Raul gave us an initial look on what the networking stack would look like in future.

In summary, we will go from libp2p -> minp2p -> ethp2p.

libp2p: the networking stack as we currently use it.
minp2p: a minimal version of libp2p containing only of the parts that ethereum requires.
ethp2p: we roll our own networking stack.

Q: why not go from libp2p straight to ethp2p?

The transition to minp2p comes from immediate needs of the beacon chain clients. Prysm for example suffers from libp2p being too heavy for usage, go-minp2p is going to help with that.

ethp2p will be a roll-our-own-stack approach, so no libp2p. The underlying layer stays the same though, we will use QUIC transport for both minp2p and ethp2p.

There was a decision made to remain with our current networking stack used for devnet0, but there were also some open questions to the P2P discussion:

1. How much should we experiment with network topology in the upcoming devnets? (grid topology? continue with gossipsub?)
2. What kind of parameters should we choose for devnet 1? (the discussion ranged between 10 nodes to 10,000 nodes)

## Day 2, 5 Oct

### Bindings

led by: Guillaume

The current state of lean implementation is that all the reference implementation is in Rust, which does not play well when used in bindings in other languages:

- long compilation times
- compiler versioning problem, especially with compilers that update often (eg. Rust)
- single lib vs multilib

Some FFI function symbols might be duplicated during the build process, leading to bugs if we call the wrong version

Solution:
1) objcopy
2) use nim to produce C code

Long term:
We still want to eventually have 'implementation diversity' - redundancy is almost always good in the case of bugs. In that case we should have 2-3 implementations of one of each: LeanVM, XMSS and LibP2P, so that when 1 fails we at least have one fallback.

Nim here looks promising since we can produce C code from Nim and we can also use `zig cc` within Nim.

### LeanVM

led by: Emille

Emille walked through the LeanVM whitepaper.

One of the main points of contention was on the memory checking: currently it is a flat memory layout, with 3 AIR tables (Poseidon-16, Poseidon-24, dot-product) doing LogUp* lookups into memory. Aki proposed using an indexed merkle tree architecture.

(ps. was not at followup sessions, so am not aware of the conclusion)

### LeanP2P brainstorming

led by: Raul

Raul went through the early specs of ethp2p, which will use network erasure coding (using Reed-Solomon codewords). The proposed cryptographic library to use is c-kzg-4844 (but keep in mind that we're not proving or verifying anything, just using the erasure coding properties provided by the library)

Some other areas of discussion:

1) Are there other existing erasure coding schemes we can use?

[RLNC](https://en.wikipedia.org/wiki/Linear_network_coding#Random_Linear_Network_Coding), and [raptor codes](https://en.wikipedia.org/wiki/Raptor_code). [Monad](https://www.category.xyz/blogs/raptorcast-designing-a-messaging-layer) uses an implementation of Raptor codes known as R10.

Ethereum is not going to use the above because both RLNC and raptor codes are a patent minefield (unfortunately).

2) Could we not do something like what Solana does with shreds?

Shreds work as well as they do because they operate under a known validator set, under a very specific structure. Since Ethereum does not make the same assumptions, we are unable to take advantage of structure to achieve faster propagation speeds.

## Day 3, 6 Oct

### KeyGen

Led by: Benedikt

In the XMSS scheme that leanEthereum is adopted, key generation is pre-done (done before validators enter the network), because keys are one-time use only (or in leanEthereum's case, used once per slot). As such, we generate ~500 years worth of keys within the span of a few days (can be further improved).

~500 years is about 2^32 leafs (secret keys), this provides a safe buffer since the current target is 4-second slots, but this can drop to ~100 years if we're targetting 1-second slot for example.

The main tradeoff we see with this scheme is trading off key sizes for compute time:

We could in theory generate the entire tree once, but we would need to store the keys somewhere.

We could also generate the tree on the fly, but this means we have slower signing.

The solution is probably somewhere in the middle.

There were 2 main questions coming out of this session:

1) How do we find the middle ground? A solution suggested was to chop the tree in half (we get log time compute in this case), then we only generate the bottom half of the tree (say every 3 days). Then we'd also save on memory requirements.

2) How do we improve UX for validators? Having to make validators generate keys prior to entering the network is a huge UX issue. It's a bigger issue if the validator has to rotate keys, because now they have to repeat the whole process + exit/re-enter the queue, which can be an issue depending on exit queue length (right now it's about a month)