Post Quantum migrations, Crypto-agility and how to prevent EIP-7932 from failing

EIPs
1

At the current moment the correct path to post quantum Ethereum transactions looks more like Shibuya Crossing, there are too many proposals all with different ways of doing the same fundamental thing. Some of the proposals that can achieve PQ migration are:

The proposals are wildly different and touch different parts of the EVM to achieve PQ migration. Unfortunately, they share the same common problem in that they all maintain their own separate list of cryptographic primitives or risk doing so, even EIP-7932 is guilty of this as it is only used by EIP-6404.

EIP-7932 was designed expressly to prevent this exact problem from occurring, so instead of worrying “how can I convert secp256k1 → generic PQ algorithm?”, new proposals can worry about “how can I convert secp256k1 → standard algorithm-agnostic interface?”.

After doing some reading on EIP-8164, I drafted #11357: Update EIP-7932: Add support for public key / signature separation
 to make it easier to integrate EIP-7932 with EIP-8164. However, what I think is the best for keeping this EIP maximally standardized has not seemed to work out so well. So before I change any more things, I have decided to ask everyone else:

  • What can I do to make EIP-7932 not another PQ algorithm pathway to irritate ACDE call members with?
  • What needs to happen to EIP-7932 before it is technically feasible to have a Crypto frame type, an EIP-8164 ⟷ EIP-7932 integration and a stable interface for all future proposals?

CCs for visibility: (Apologies if you hate being pinged)
@prestwich @shemnon @matt

7 Likes
2

I’ll share where I’m coming from: I’m building SPECTER (x - @specter_pqspecter_pq), a post quantum stealth address protocol for Ethereum using ML-KEM-768, with a draft ERC extending ERC-5564. So I’ve been living in exactly this confusion, as someone writing a spec that sits above the transaction layer, I constantly have to make uncomfortable assumptions about what the signature layer below me is going to look like. That uncertainty is a real blocker for application layer PQ work.

For SPECTER specifically, I’m watching EIP-8141 most closely because the account
decides model maps cleanly to stealth address receivers generating ephemeral PQ keypairs. But without a stable EIP-7932 interface to anchor the algorithm side, I’m having to build against moving ground.

Would genuinely love to see a joint discussion between the EIP-7932, EIP-8141, and EIP-8164 authors to at least define the interface contract before any of these go further. Happy to contribute from the stealth/privacy/PQ application layer perspective.

2 Likes
3

Thank you for contributing, It’s nice to know that the problem of PQ interfaces constantly moving is an actual problem for developers. My current priority at the moment is ensuring flexibility with everything else, but once EIP-7932 goes into review, the interface would be pretty much complete.

Is there any specifics you would want from a stable interface, i.e. many precompiles with different functions, well-defined signatures, etc?

1 Like
4

This points to something broader than post-quantum migration itself: crypto-agility.

Crypto-agility is an process to clearly separate three concerns that are currently getting mixed together:

- transaction and account model evolution,

- migration mechanisms for EOAs and smart accounts,

- algorithm registration, encoding, and verification interfaces.

The real risk is beyond cryptographic algorithms; it is fragmentation: wallets, apps, account implementations, and future EIPs could all converge on slightly different crypto interfaces.

From a crypto-agility perspective, the goal should be to make cryptographic transitions transparent, standardized, and measurable. That is what will reduce uncertainty for the ecosystem and make future migrations easier to coordinate.

1 Like
5

Can you please explain why key/signature detachment matters?

6

The current system forces all signatures to be self-contained, this means that for non-recoverable signature schemes, they would have to embed the full public key inside each signature. Given that most post-quantum signature schemes have public keys in the size of KiBs, this is really inefficient.

If an account already has a key stored on chain and we already know it (e.g. EIP-8164: Native Key Delegation for EOAs), the signature does not have to be self-contained and we can embed the public key information later in the verification process. This’ll reduce the size of the transaction by a considerable amount.

7

I have updated this thread with the newest list of PQ EIPs. I’ll probably continue updating it with different proposals and their statuses.

1 Like