In the coming weeks we will see some shifts in the All Core Devs (ACD) discourse and in the Ethereum community in general. For some, these discussions may come as a shock, as they did to me. I decided to put my thoughts on the topic into a single document, distilling what I think are the most important aspects of this discussion. I will describe what actually happened, why it happened, and what my preferred path forward is.

What happened

During the L1 workshop before Devcon, rumors circulated about the chances of AI breaking ECDSA in the near future (say, months). We all knew elliptic curve cryptography would eventually be broken by quantum computers, but these rumors implied it could be broken relatively soon by classical ones. The path to secure the chain is the same for both the “AI attack” and the “quantum computer attack”. So we sat down to finally work out a concrete path, down to the actual spec and details, for upgrading the chain to be post-quantum (PQ) safe in a timely manner (think this coming year).

At some point it looked (at least to me) as though this was a coordinated effort to sway Ethereum and circumvent its governance to simply ditch the current fork. I am now convinced this is not the case, and, perhaps for the wrong reasons, I believe that in the coming weeks we will adjust our roadmap into a more responsible and safer one.

Since the proposed response to both doom scenarios is the same, I will not write about AI here: I ultimately dismiss these rumors as irrelevant. I will consider them once I see a concrete academic consensus on the topic in public channels. Decentralized blockchains should not decide their course based on rumors, nor on private information coming from relatively few sources. However, the fact that we got together to actually think about shipping PQ within months immediately surfaced the problems of doing so, and the blatant contradictions in the current roadmap.

Why it happened

Ethereum research and development is driven by a more or less cohesive group of people who share a common long-term interest. We may disagree, sometimes very loudly, on what the short-term priorities should be, but we all agree on the values we want to see in a future Ethereum. In the short term, however, priorities are very dissimilar. Roughly speaking, there are three camps:

  • Team Dankrad: those who would like to improve execution, bring liquidity, and make the chain more appealing to capital as a trading and economic platform.
  • Team Micah: those who want to prioritize minimal trust assumptions, privacy at every level, maximal decentralization, and censorship resistance above all.
  • Team Justin: those who want to live at the frontier of technology, enabling all of the features that Team Dankrad and Team Micah want by means of zero-knowledge technology.

Features that Team Dankrad wants include maximal gas limit increases, minimal slot times, more efficient MEV markets, etc. Of course, it’s easy to get many of these by just turning some knobs in the existing machine. Getting them without increasing hardware requirements, and ultimately hindering censorship resistance for our users or stakers, is harder. We have come up with solutions that do make progress on these topics in a safe manner: Glamsterdam comes with gas limit increases enabled by better usage of slot time and block space, and quick slots is a feature CFI’d for Hegota and already implemented in at least 3 clients.

Features that Team Micah wants include trustless proposer-builder relations, FOCIL, LUCID, etc. The first two are the headliners for Gloas and Heze respectively, while the latter is actively being worked on.

Features that Team Justin wants include changing the signature scheme in both the execution layer (EL) and the consensus layer (CL), and making block validation simply the verification of a ZK STARK. This would allow for a much higher gas limit and very short slot times: validators would no longer need to re-execute the block, as long as someone can produce the ZK proof for it in time. We get PQ resistance out of this team’s roadmap.

Now, core devs have very fresh wounds and know very well that committing to change Ethereum several forks in advance simply does not work. How many years was Verkle the next fork? EOF was thrown out in just two days after a coordinated Twitter campaign, after many more years of work on it. Coordinated by a group that went on to build an alt L1, of all things! No one is willing to invest time and energy thinking 2 or 3 forks into the future, simply because there is no credible way to commit to it. But the ultimate outcome of this, which I think is responsible for the breakdown that happened this week, is that no one is allowed to use future forks to dismiss good features that are ready to be shipped today.

Two very clear examples are shorter slots and FOCIL; a slightly more subtle one is trustless payments.

Shorter slots. Discussions about shorter slots often dismissed the timing issue with sentences of the form “the ZK teams say they can handle the proving time”. In consensus we all knew that there is no way, none whatsoever, that we can have PQ and shorter slots with the current aggregation schemes. But we weren’t allowed to use this argument, both because of the black box (the ZK teams had complete authority on what these times were) and because PQ was in some distant future fork that we could not commit to in any way. We all thought: alright, perhaps these timing issues get solved by the work on decoupled consensus or by other future breakthroughs. Now we know that even 12 seconds may be too short to ship PQ with our current consensus algorithm.

FOCIL. Something similar happens with FOCIL: we all knew that FOCIL is already too complicated, even without PQ complicating things further. Just as PQ aggregation in the CL makes the shorter-slot vision impossible, larger signatures on the EL also make the FOCIL vision impossible, at least for now. Even if you think these are exaggerations and that we could solve both problems, it’s undeniable that both are in fact problems: larger inclusion lists require more bandwidth than smaller ones, and STARK aggregation takes more time than BLS aggregation. Had we had a concrete PQ spec in the CL, as we now do, and had we aligned early on that we wanted to ship PQ as a priority, we would have dismissed both quick slots and FOCIL immediately. I have absolute certainty of this.

I like to think of myself as a member of Team Micah, so it pains me to be advocating for removing FOCIL from the fork and refocusing on PQ instead. I still want FOCIL, and I still think censorship resistance should be a defining property of Ethereum. But I cannot defend shipping it now while leaving its compatibility with PQ for someone else to solve later. We need to secure the chain first, and then come back to FOCIL with a concrete understanding of how to make it work in a PQ world.

Trustless payments. Something very similar happens with trustless payments, but here the choice of consensus algorithm matters. Unlike FOCIL, which faces the same PQ problem under both Gasper and decoupled consensus, trustless payments become harder specifically with decoupled consensus. To keep trustless payments we need to keep attestations in blocks, and this is harder to do with decoupled consensus + PQ. Had we not dismissed all future PQ work as some magical ZK-math world that would come to save us, and instead thought about the constraints of keeping attestations in blocks when they need to be STARK-aggregated, we would have been wiser.

So, in short, I think the real reason we are now facing the possibility of scrapping the current Hegota plan and redrawing it entirely is that we never really committed to a concrete, implementable PQ solution. We never sat down, like we did this week, to actually see how a solution would work in the real world, rather than in some magical future one.

This is in large part due to a disconnect between different groups. One part of Team Justin meets in academic workshops in Cambridge or works purely among researchers, while implementers hack at interops and plan forks and features of their own in different circles. It really took just 5 minutes of looking at what changes we would need to ship PQ + Gasper to realize that the roadmap relied on architecture that would take years to produce: external aggregators, erasure-coded P2P solutions, decoupled consensus, etc. I put myself in the shoes of those wanting to ship quick slots, and I agree with them: researchers were telling them that even in a PQ world we would have some slack. And yes, we may have slack in the future, but it is obvious that we don’t have it now.

We implementers are at fault for simply not prioritizing correctly. Essentially all of us knew that the decisions we were making were completely incompatible with PQ in the near future. We dismissed these issues as a problem for whichever core devs would deal with PQ years from now, instead of actually trying to spec out PQ and using those constraints to set our priorities responsibly.

We kept adding features whose compatibility with PQ depended on solutions we had neither specified nor tested. Different groups were working with different assumptions about what would be available and when, and we never brought those assumptions together on ACD to resolve the incompatibilities before moving ahead. Every such decision added another problem that the PQ fork would eventually have to solve. This is the concrete cost of the lack of communication: we kept committing to features while leaving the work needed to make them compatible with PQ to some unspecified future effort.

It may be true that we would not be having these conversations now if some weren’t worried about the AI threat, and that everything would still be on track for a PQ-safe future in 5 years instead of 1 or 2. But I think it’s a mistake not to have more people versed in the intersection of these groups’ interests. Team Justin only started to show up more often on ACD lately, and their proposals have mostly been punted because we felt they were just preparation for a distant future. Emile had some interesting constraints about attestation data size, UDP packet size, etc. Like it or not, ACD and the R&D Discord are the only public venues frequented by everyone, and the only places where coordination happens. These constraints should have been discussed there early enough to shape the roadmap.

The path forward

The following are the things I think we need to do, in decreasing order of importance and urgency. I will mostly focus on the CL side, since it is the only side whose technical intricacies I understand.

Commit to PQ

The very first thing we need to decide is whether or not we want to commit to solving the PQ threat as a high priority. Everything is downstream of this. If we keep delaying this decision, we’ll keep piling incompatible features onto mainnet. I believe that if we commit to this, we have a workable path to a PQ fork by 2027.

Shipping this fork is not the same as finishing the migration of every wallet, contract, and rollup. Those are related problems with different timelines, and I’ll come back to them below.

This is also why I think we need to move to PQ sooner rather than later. Existing contracts will need to change, and entire ecosystems, both on and off chain, will need to adapt. There are governance processes, audits, tooling, and infra to work through, and all of this takes a lot of time. Having a PQ-safe mechanism in place at the core protocol layer early gives these communities something concrete to build on, so they can change their contracts and infra at their own pace. The sooner we ship our part, the more time we give everyone else to do theirs.

There were some discussions about having an emergency path and a normal path. I believe this was misguided: our emergency path should be the normal path. We should commit to solving this first and foremost; let’s fix this problem and only later worry about anything else. By solving only this I really mean solving only this: shipping the bare minimum that is viable, as long as it doesn’t constrain us in the future. Examples are below, but think along the lines of “if gossipsub can handle the bandwidth, do not propose a different P2P scheme right now”. Anything that is not absolutely needed will delay the fork. If a feature is not strictly needed, but would be a game changer in the future and would be blocked by not working on it right now, we should consider it, but this should be a rare situation and not the norm.

Making the commitment credible

After what I wrote about Verkle and EOF, I think it’s fair to ask why this commitment would be any different. We need a public spec for the minimum fork, client teams committing people to implement it, and a shared devnet where we can test it. We need to agree on the hardware and network conditions we want to support, and on what results would convince us that PQ + Gasper is viable. The remaining work needs clear owners, and progress and blockers need to be discussed on ACD.

No one can promise today that Ethereum will ship a particular design on a particular date. But we can commit engineering time now and use the concrete requirements of this fork to set priorities for competing features. If the measurements tell us we need decoupled consensus or a different P2P protocol, we should adjust the design while keeping PQ as the priority. That is the commitment I am asking for.

Outreach and tooling

We need to finalize all the details of the signature scheme. We need to produce the tooling to generate these keys ourselves. We need to reach out to hardware wallet providers as soon as possible so their support is production ready in time for the migration. We need to contact and educate our users so they move to these keys as soon as the tooling is ready. On the CL side, this work can and should start immediately. The impact on affected parties will be large, and community coordination will be as much of an issue as the technical aspects.

We also need safe tooling for backups, restoring validators, switching clients, and failover. With leanSig, accidentally signing twice with the same key for the same epoch can compromise security, so operational tooling is part of the security work itself.

The shape of the fork

To get validators to be PQ safe, we need two things to happen:

  • Existing validators need to commit to their PQ key material early, while we are still safe.
  • Once existing validators have committed to their PQ keys, we need to fork, mass-exit every BLS validator, and start validating with the PQ validator set.

At this fork, deposits using BLS keys are disabled and only PQ validators are enabled on the chain.

These two parts in fact break down into three very concrete steps:

  • a) We deploy a contract on L1 where validators can commit to their future PQ keys. This is a system contract of the execution requests type, very much like withdrawal requests or builder deposits.
  • b) We fork once, and starting at the fork the EL informs the CL of the keys committed by validators. In this very light fork, the CL records these commitments and starts building the future PQ validator set. Validators still use BLS at this stage.
  • c) We fork again and disable every non-PQ validator.

a) does not need to wait for a fork. There is no need to delay this deployment once we have finalized the signing scheme. We should work on auditing existing contracts and prioritize deployment as soon as we have key generation tooling.

c) is the bulk of the work. Getting client implementations ready and tested will take time. We should commit all our energy to getting the absolute minimum needed to do c) safely, as quickly as possible.

b) has flexible timing. It is a trivial fork: it could come together with a), it could come later, closer to c), or b) and c) could be shipped in the same client release with staggered activation times. The important part is that the CL has built the PQ validator set before we switch to it.

Bandwidth

The biggest priority on the engineering side is the P2P front. I’ll assume Gasper in what follows; some changes are necessary for decoupled consensus (DC).

Attestations will now come with 2KB or 1.2KB signatures (I disagree with supporting native DVTs at the cost of doubling the signature size, but I seem to be alone on this one). We broadcast 30K of them at the 3-second mark. These are aggregated, and then the aggregates, now 300KB, need to reach the proposer on time. All this broadcasting needs to happen alongside a much larger execution payload, while each transaction in the mempool will also carry its own much larger signature.

Solutions for handling this, and doing so securely, need to be developed urgently. We need POCs on the CL right now to see whether gossipsub is even viable, or whether we will be forced to move to Waggle or whatever its replacement is. While I know clients are already working on these replacements, we should not prioritize them if they aren’t needed: P2P protocols have taken forever to ship in clients, and they are notoriously hard to test across multiple implementations. Unfortunately, knowing whether the network will handle the load is very hard without actually deploying en masse. We need to verify and audit the simulations, and not just trust the few eyes that have gone over them. On the EL side: good luck finding a proper way to harden the public mempool!

One of the biggest “gains” from ePBS pipelining was moving from 150KB blocks to negligible ones, since most of the current block is the payload. That gain is now lost, as the CL block will take at least 300KB just for the attestation STARK. In the event of slashings, we are looking at CL blocks on the order of MBs. If gossipsub fails, we need to start prototyping and working right away on erasure coding, or at least chunking.

Compute

Apart from propagating aggregates, the CL now needs to aggregate single attestations and then do the final STARK recursion. Aggregators are chosen randomly among the validators; some may not be able to handle the load and will produce bad aggregates that still take up bandwidth. The final STARK recursion can take between 2 and 3 seconds, which means proposers need to start preparing their CL block much earlier than today. This recursion happens while the EL is still executing the payload. Luckily, today we have some slack with regard to including attestations: we can explore techniques in which proposers simply skip this final recursion and include their best aggregate. Builders could also provide aggregates with their bid as a service.

Lean VM

We should only ship a PQ solution once we feel it is safer than the attack itself. We need to start working on independent implementations of Lean VM and get more eyes on the existing implementation: fuzzing it, breaking it. I am pretty certain people have been looking at the specs, formally verifying them, etc., but what we will be running is an actual machine that executes untrusted code. We need to be certain that it can’t be crashed. Soundness matters just as much: we need to be certain that neither the proof system nor the signature-verification program lets an invalid signature pass as valid.

Decoupled consensus

Decoupled consensus solves both compute and bandwidth by simply moving the big broadcast out of the hot path. Weak validators do not need to include and aggregate finality attestations right away, and we can get a stable chain by broadcasting 512 votes instead of the current 30K. However, it is a very large change affecting every aspect of the clients, and is very likely to require much more effort than Gasper. Moreover, the PQ work for Gasper seems to be directly applicable to DC.

A preliminary exploration we did during Devcon shows that Gasper may be viable. If it is, I believe we should focus on shipping PQ + Gasper, and only later upgrade to DC, as it will unlock further improvements and stabilization. On the other hand, if Gasper cannot handle the attestation load with 12-second slots, and we need to start tweaking slots per epoch, slot duration, or any of those parameters that will blow up our codebases, I would rather invest in moving to DC at that point and delay the fork.

Rollups

I may be wrong on this one, but I believe PQ-safe data availability (DA) can be deprioritized for the first fork and shipped as an upgrade. Optimistic rollups can be somewhat covered by posting PQ-safe commitments (like Merkle roots) along with their blobs, and upgrading their challenge protocols if Q-Day were to happen before we ship PQ DA.

Light clients

Light clients are not strictly needed to ship the fork, so they should not be treated as critical for now. Still, I think we need to find a good solution for them. PQ will raise the hardware requirements for regular, non-validating full nodes, and users who can no longer afford to run one should still have a trustless way to follow the chain.

The EL side is in good shape: with block access lists (BALs), it is relatively easy to keep the state up to date. The CL side is the problem. Keeping the sync committee, and with it the current light client protocol, looks unviable in a first PQ iteration of the protocol. We should start thinking now about what will replace it, even if it ships in a later fork.

Affected users

If we do commit to forking PQ next, this fork will bring pain throughout the community. To fellow core devs: be prepared to be insulted and called out everywhere.

On the CL side, decentralized staking pools will take a big hit, mostly on coordination and infra deployment. I suspect that for someone like Lido or Rocket Pool, the upgrade will involve at least the following (and surely a lot more):

  • They need tooling to let node operators generate PQ validator keys.
  • They need to deploy the UX to let operators submit their PQ key and get it registered through an execution layer transaction to the pre-registration contract.
  • The execution request needs to be authorized through the existing validator’s withdrawal address to prove ownership, which requires upgrading the pools’ contracts.
  • The BeaconState structure changes quite a bit, including the validator structure itself, so any contract that relies on Beacon State proofs will need to be upgraded.
  • Validators that still have BLS (0x00) withdrawal credentials at the transition will be deprecated and their funds likely burnt. Discussions about saving those funds should start urgently in the community.
  • BLS validators with execution withdrawal credentials that do not upgrade will be exited and withdrawn.

The entire community will have to upgrade their EL keys to SPHINCS, and multisig contracts will have to adapt accordingly. DAOs will need to upgrade, etc. This migration will take years, even if we manage to ship this fork in 2027/2028. But this ball needs to start rolling, and it only starts with us announcing a fork: the community will not start developing their own infra until we have settled the scope and committed to the fork.

We also need to research precisely where users who have migrated or preregistered PQ keys may still be exposed through shared vulnerable dependencies, like approvals to addresses controlled by ECDSA keys.

PQ Ethereum

Ultimately, while I think the news of refocusing on PQ for 2027, instead of the original, already ambitious, plan of PQ for 2028, will come as a shock, it will be good news for the whole crypto community. It will be good PR for Ethereum that we are finally moving and acting on the first real threat to crypto. It will finally clarify the situation for players who either need to adapt their systems or want to enter the market. It will also make our own lives easier in the future by giving us real numbers to work with when planning important features like FOCIL or LUCID, or by pointing out the need for intermediate infra like erasure coding or decoupled consensus: not as ends in themselves, but as means to an end.