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:
- Pure ERC-4337 account abstraction and doing the PQ verification on the EVM
- EIP-6404: SSZ transactions that use the EIP-7932: Secondary Signature Algorithms rails.
- EIP-8141: Frame Transaction that make the PQ migration up to the account to decide.
- EIP-8164: Native Key Delegation for EOAs that acts as a foundation for PQ migration.
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