# Ethereum and Quantum: BLS12-381, Account Abstraction, EIPs **Source**: https://quantumsequrity.com/blog/ethereum-quantum-detail **Category**: Network Protocols --- [← Back to Blog](../../blog.html) Network Protocols # Ethereum and Quantum: BLS12-381, Account Abstraction, EIPs 12 min read Ethereum is a complex stack. Unlike Bitcoin, which uses one elliptic curve and one signature scheme for all wallet operations, Ethereum mixes multiple cryptographic systems. The execution layer uses ECDSA over secp256k1 for externally owned accounts. The consensus layer (post-merge) uses BLS signatures over BLS12-381 for validators. Smart contracts can use precompiles to verify a wider range of cryptography. Account abstraction proposals are in motion to make signature schemes upgradable per account. All of this matters when you start asking how Ethereum survives in a post-quantum world. This article walks through Ethereum's cryptographic landscape, where each piece fits, what quantum computers do to it, and how proposals like EIP-4337 and EIP-7503 fit into the longer-term migration story. ## ECDSA Over secp256k1: The Wallet Layer Externally owned accounts (EOAs) on Ethereum use ECDSA signatures over the secp256k1 curve, the same curve Bitcoin uses. When you sign a transaction with MetaMask or a hardware wallet, you produce an ECDSA signature. The transaction includes the signature and the recovery information that lets verifiers reconstruct the public key and check it against the sender address. Ethereum addresses are the last 20 bytes of the keccak-256 hash of the public key. This is similar to Bitcoin's pay-to-pubkey-hash scheme, except Ethereum hashes the uncompressed public key with keccak-256 instead of using SHA-256 plus RIPEMD-160. Either way, the public key is not revealed until the account makes a transaction. After an account makes its first outgoing transaction, the public key is recoverable from the signature. From that point, a quantum adversary could derive the private key using Shor's algorithm. So an EOA that has never sent a transaction is still cryptographically protected by the hash. An EOA that has sent even one transaction is exposed, the same way it works in Bitcoin. The threshold is different from Bitcoin's, though, because Ethereum users tend to reuse addresses much more aggressively. Most Ethereum users have one or two main wallets that have sent dozens of transactions. The hash protection is gone for almost everyone. To understand the cross-chain context, see our [Bitcoin and quantum detail](../../blog/pqc-blockchain-bitcoin-ethereum.html). ## BLS Signatures and the Consensus Layer Ethereum's proof-of-stake consensus layer (the Beacon Chain, post-merge) uses BLS signatures over the BLS12-381 curve. This is a different curve from secp256k1, designed for pairing-friendly operations. Pairings let validators aggregate signatures: thousands of validators sign the same message, and the resulting aggregate is a single 96-byte BLS signature plus the list of which validators contributed. BLS aggregation is what makes Ethereum's consensus layer scale. Instead of verifying half a million individual signatures per slot, the network verifies a single aggregate. Without BLS aggregation, the data and computational cost would be unmanageable. BLS12-381 is also broken by Shor's algorithm. Pairing-friendly curves do not save you from quantum attacks, because the underlying discrete logarithm problem is still solvable on a quantum computer. So Ethereum's consensus layer faces the same quantum challenge as the wallet layer, just at a different scale. A migration from BLS to post-quantum signatures is a major project. Aggregate signatures are not a feature of the current NIST-standardized post-quantum schemes. ML-DSA and SLH-DSA are individual signatures, not aggregates. Replacing BLS aggregation with thousands of individual ML-DSA signatures per slot would inflate consensus block sizes dramatically. To compare ML-DSA and SLH-DSA, see our [ML-DSA versus SLH-DSA](../../blog/mldsa-vs-slhdsa.html) explainer. There is research on post-quantum aggregate signatures (lattice-based aggregation, hash-based tree structures), but nothing standardized or production-ready as of late 2025. This is one of the most active research areas in cryptography because so many systems depend on aggregation. ## Precompiles and zk-SNARKs Ethereum has precompiles for common cryptographic operations: ecAdd, ecMul, and ecPairing on BN254 (alt_bn128), modexp for modular exponentiation, and a few others. Zero-knowledge rollups use these heavily. zk-SNARK proofs typically rely on pairing-based verification, which assumes pairing-friendly curves are hard. BN254 is broken by Shor's algorithm just like BLS12-381 and secp256k1. Any zk-SNARK system using these curves becomes insecure when sufficiently large quantum computers exist. zk-STARKs, on the other hand, are based purely on hash functions and finite field arithmetic, with no elliptic-curve assumptions. STARKs are post-quantum secure (they only lose half their security to Grover's algorithm, which is acceptable for practical security parameters). This is one reason rollup designers care about the SNARK versus STARK distinction. STARK proofs are larger but quantum-safe. SNARK proofs are smaller but quantum-vulnerable. The choice affects how a rollup ages. ## EIP-4337: Account Abstraction EIP-4337 introduces account abstraction without changing the Ethereum protocol. It defines a separate transaction type, called a UserOperation, that gets routed through a separate mempool, processed by bundlers, and included in regular transactions through a dedicated EntryPoint contract. The actual account is a smart contract, and the smart contract decides what counts as a valid signature. For post-quantum migration, EIP-4337 is a big deal. With EOAs, the signature scheme is hardcoded into the protocol (ECDSA over secp256k1). Adding a new signature scheme means a hard fork. With EIP-4337 accounts, the signature scheme is whatever the account contract verifies. You could deploy an account contract that verifies ML-DSA signatures, and as long as the contract logic is correct, your account uses post-quantum signatures from day one. The catch is that ML-DSA verification on Ethereum is expensive. ML-DSA signatures are around 2420 bytes (for ML-DSA-44) or 3309 bytes (for ML-DSA-65). Verifying them inside a smart contract burns gas: the polynomial arithmetic, NTTs, and hashing add up. As of late 2025, several projects have demonstrated ML-DSA verifiers in EVM bytecode, but the gas cost is high enough to make this impractical for everyday transactions. A new precompile for ML-DSA verification would change the economics, but no such EIP has been ratified. Once a precompile lands, account abstraction becomes the cleanest path to post-quantum Ethereum wallets. New accounts deploy with ML-DSA signature verification, old accounts can migrate by deploying a new contract and transferring balances. ## EIP-7503: Zero-Knowledge Wormholes EIP-7503 is a more speculative proposal that allows users to "burn" Ether at one address and prove (via a zero-knowledge proof) that the burn happened, allowing them to mint the equivalent Ether at a fresh address without an on-chain link. The motivation is privacy, but it has a side effect for post-quantum migration. If you have funds in an EOA whose public key has been exposed, you cannot move them to a fresh address without revealing on chain that the source and destination are linked. EIP-7503 (or a variation of it) could break that link by using a zero-knowledge proof. Combined with a post-quantum-safe destination address, this would let users escape the quantum-vulnerable side of the chain. The proposal has not been adopted, and there are concerns about its anti-money-laundering implications. But the technical idea is interesting: if you can prove ownership without revealing the underlying signature, you can migrate without re-exposing your keys. ## EIP-2938: Account Abstraction (Earlier Draft) EIP-2938 was an earlier account-abstraction proposal that would have changed the protocol itself, allowing certain transactions to be sponsored by contracts and validated by custom logic. It was not adopted in favor of the simpler EIP-4337. Conceptually, EIP-2938 covered similar ground: it would have let accounts use any signature scheme they wanted, with verification handled by EVM bytecode. The lesson from EIP-2938's history is that protocol-layer changes to support new signature schemes are politically and technically expensive. EIP-4337 succeeds where EIP-2938 stalled because it adds account abstraction without forcing a protocol change. For post-quantum migration, this matters: any path that requires a protocol change has a higher bar than a path that uses existing EVM features. ## What Migration Looks Like Realistically, post-quantum Ethereum will involve several phases. The first phase is awareness and tooling: client libraries that can handle post-quantum signatures, account-abstraction wallets that opt into ML-DSA, smart contract verifiers that work even if they are gas-expensive. The second phase is precompile addition. An EIP for an ML-DSA precompile would dramatically reduce the cost of post-quantum signature verification, making it cheap enough to use for everyday transactions. There is no public timeline, but the cryptographic primitives are now NIST-standardized, which is the prerequisite. Our [NIST FIPS guide](../../blog/nist-fips-guide.html) summarizes the relevant standards. The third phase is consensus-layer migration. Replacing BLS aggregation is the hardest change because the network relies on aggregation for scalability. This probably waits for post-quantum aggregate signature schemes to mature. Research is active but standards are years away. The fourth phase is migration tooling. Users with EOAs need a way to move funds to post-quantum accounts safely. Whether this looks like EIP-7503, a planned migration window, or just user-driven account upgrades remains an open question. ## Layer 2 and Rollups Layer 2 systems on Ethereum (Optimism, Arbitrum, zkSync, Starknet, and the rest) inherit different parts of Ethereum's quantum exposure. Optimistic rollups (Optimism, Arbitrum) use Ethereum's signature schemes for sequencer authentication and rely on Ethereum L1 for security. They are exposed to the same ECDSA vulnerability for user wallets that L1 has, plus whatever sequencer-specific cryptography they add. zk-rollups using SNARKs (zkSync Era, older zkSync versions) inherit BN254 vulnerability through their proof systems. zk-rollups using STARKs (Starknet) use only hash-based and finite-field cryptography in their proofs, which is post-quantum secure. Starknet's proofs survive a quantum computer in their proof system, though user wallets on Starknet still rely on classical signatures for transaction authentication. The migration story for rollups is similar to L1 in some ways and different in others. Rollups can independently upgrade their sequencer cryptography and their virtual machine semantics without waiting for Ethereum hard forks. Some rollups may move faster than L1 on PQC support, providing a path for users who want post-quantum protection sooner. ## Smart Contract Wallet Considerations Account-abstraction wallets are smart contracts. They have their own state, their own update logic, and their own signature verification. From a migration standpoint, smart contract wallets have a major advantage: their signature scheme can be upgraded without touching the underlying account. A typical smart contract wallet might verify ECDSA signatures today and add ML-DSA verification through an upgrade. The upgrade itself has to be authorized somehow, usually via a multi-signature or a recovery key. After the upgrade, both signature schemes are valid for some transition period, and eventually only ML-DSA is accepted. This pattern is much smoother than the EOA migration story. Users with smart contract wallets can migrate at their own pace, on their own schedule, without coordinated network-wide events. The cost is gas: every signature verification gets more expensive when ML-DSA is involved, until precompiles arrive. ## What Users Should Do Today If you hold ETH in a hot wallet that has signed many transactions, your public key is exposed. You cannot un-expose it. The pragmatic move is: - Generate a fresh wallet that has never signed anything - Move your funds there, but do not sign with the old wallet immediately if you can avoid it (each fresh signature gives a quantum adversary one more piece of harvested data) - Plan to migrate to a smart-contract account once tooling supports post-quantum signatures - Keep cold-storage holdings as cold as possible (no on-chain activity, no exposed public keys) Encrypt seed phrases, backups, and any documents with crypto details using a tool that uses post-quantum primitives. QNSQY combines ML-KEM-1024 with X25519 in hybrid mode, so encrypted backups stay confidential against both classical and quantum adversaries. Our [hybrid encryption](../../blog/hybrid-encryption.html) explainer covers why hybrid is the right choice during the transition period. ## FAQ **Are my Ethereum funds at risk today?** Not from quantum attacks, because no quantum computer powerful enough to break secp256k1 exists. The risk is in the harvest-now-decrypt-later sense: public keys that are visible on chain today (because you have sent transactions from them) could be cracked once quantum computers exist. **Are ETH validators at risk?** Validator BLS keys are public on the consensus layer. A quantum adversary who breaks BLS12-381 can derive validator private keys and forge attestations or sign slashable messages. This would be catastrophic for the consensus layer. Migration is essential before that capability exists. **What is the difference between EOA and contract account quantum risk?** EOAs use ECDSA hardcoded by the protocol. Their signature scheme cannot be upgraded without a hard fork. Contract accounts (used by EIP-4337) use whatever signature scheme their contract code verifies. They can migrate to post-quantum signatures as soon as the underlying primitives are deployable. **When will Ethereum support ML-DSA natively?** There is no committed timeline. EIPs for post-quantum precompiles will probably emerge as ML-DSA tooling matures. Expect proposals over the next few years, with adoption later. Account abstraction provides a path that does not require waiting for a hard fork. **Should I move funds to a layer-2 with PQ?** There are no Ethereum L2s with native post-quantum signatures today. zk-rollups using STARKs are quantum-safe in their proof system, but the user wallets still rely on ECDSA. Until L2s offer post-quantum account types, the underlying wallet risk remains. ## Sources 1. NIST FIPS 203 (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final 2. NIST FIPS 204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final 3. Ethereum EIP-4337 (Account Abstraction Using EntryPoint): https://eips.ethereum.org/EIPS/eip-4337 4. Ethereum EIP-2938 (Account Abstraction): https://eips.ethereum.org/EIPS/eip-2938 5. Ethereum EIP-7503 (Zero-Knowledge Wormholes): https://eips.ethereum.org/EIPS/eip-7503 6. Ethereum Documentation (Cryptography): https://ethereum.org/en/developers/docs/ ## Related Articles - [What is Post-Quantum Cryptography](../../blog/what-is-post-quantum-cryptography.html) - [PQC, Blockchain, Bitcoin, Ethereum](../../blog/pqc-blockchain-bitcoin-ethereum.html) - [Harvest Now, Decrypt Later](../../blog/harvest-now-decrypt-later.html) - [Hybrid Encryption](../../blog/hybrid-encryption.html) - [ML-DSA vs SLH-DSA](../../blog/mldsa-vs-slhdsa.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)