EIP-8355: Precompiles for ML-DSA verification

EIPs
1

Discussion topic for EIP-8355 (PR #12048)

Three precompiles that verify FIPS 204 ML-DSA signatures at NIST security levels II, III, and V (parameter sets ML-DSA-44, 65, and 87).

This overlaps with EIP-8051, and I want to be upfront that it isn’t a competing design so much as four specific disagreements with it. If those are resolved in EIP-8051, I would rather this be folded into it than shipped alongside or in lieu of.

Each precompile takes a single concatenated input with no length prefixes:


pubkey ++ signature ++ message

The public key and signature are fixed-length for a given parameter set, so the message is exactly the trailing bytes: len(message) = len(input) - PK_LEN - SIG_LEN. The precompile returns a 32-byte word, 1 for a valid signature and 0 otherwise. Cryptographic failure is a return value, never a revert, so callers branch with ISZERO.

Delta 1: levels III and V, not just II. EIP-8051 specifies ML-DSA-44 only. An account authenticator is long-lived and holds funds for years, and ML-DSA-65 and ML-DSA-87 are the tiers NIST recommends when you want margin above 128-bit classical security. Cheap to add now, awkward to retrofit later.

Delta 2: variable-length message, placed last. EIP-8051 fixes the message at a 32-byte pre-hash at the front of the input. My objection is that this puts the precompile outside FIPS 204 rather than inside it. A 32-byte input can only be a digest, so every caller is forced into pre-hashing — but FIPS 204 §5.4 makes pre-hashing a distinct construction, HashML-DSA, which binds the digest to the identifier of the hash that produced it. A bare 32-byte message carries no such binding, and a 32-byte-only precompile cannot verify a real HashML-DSA signature either, since the encoded OID pushes the message representative past 32 bytes. What’s left is neither pure ML-DSA nor HashML-DSA. Callers should stay free to pass a digest, and most will, but the precompile shouldn’t force it on callers who have a message they can sign directly.

Delta 3: Compressed public keys: EIP-8051 takes a pre-expanded 20512-byte key so its precompile can skip ExpandA; this draft takes the standard 1312/1952/2592-byte key and expands inside, pricing the work into gas. The reason is that the intended caller stores the key in account code, where every byte is persistent state — 2592 bytes is tolerable there and 20512 is not. Both tradeoffs are defensible and could coexist as siblings.

Delta 4: FIPS 204 verification only: This does not propose any alterations from the FIPs standard. No Ethereum specific hash functions and no decomposition of the components of the precompile.

Worth Noting: Empty context string: ctx is fixed to the FIPS 204 default, matching what X.509 and TLS do with ML-DSA. A caller wanting domain separation prefixes it onto the message. Also, not every cryptographic library exposes the context parameter so a context-carrying precompile would be unimplementable on top of some clients’ natural dependency.

Update Log

External Reviews

None as of 2026-07-30.

Outstanding Issues

  • 2026-07-30: Precompile addresses are unassigned; the proposal needs a contiguous three-address block allocated during standardization.
  • 2026-07-30: Gas costs are placeholders (6500/9000/13500 base, 6 per message word) and need benchmarking against a reference implementation. Measurements from anyone who has implemented compressed-key ML-DSA verification in a client codebase would be welcome.
2

What are your thoughts on EIP-8288? It seems like another way of achieving ML-DSA signed accounts.

Instead of being verified onchain directly, an ML-DSA sig can be wrapped in a STARK proof and aggregated with others into a single proof. Since the signatures are large it would be much cheaper this way than using the precompile.

Are there any benefits / use cases that would only work with the precompile and not the 8288 approach?

3

This is not an Either/Or situation. This is an And situation.

One major thing 8288 does not provide is a non-hash signature. Ethereum needs to be in a position that is cryptographically agile, meaning we can swap out signature algorithms with minimal problems. Making 8288 as the only solution locks the environment in.

EIP-8355 provides the industry standard lattice signature, and when they come online the EVM should gain access to MPC-in-the-head, isogeny, multivariate, etc. family signatures. Currently the EVM cannot efficiently do any of these without precompiles. Industry standard crypto provides easy access to HSMs, Cloud KMS, and all sorts of other items downstream users will want to use.

So in summary <Road to El Dorado meme>Both, both is good..</>

4

My understanding of 8288 is that it does support arbirtary signatures wrapped in a STARK. The EIP defines two pathways, LeanSPHINCS (hash-based, what you’re referring to) and LeanSTARK, which supports different circuits. So you could wrap an ML-DSA signature in a STARK to use this pipeline.
From the EIP:

Users who want to use quantum-resistant signature schemes other than leanSPHINCS signatures will have to either use them in the clear, and accept the onchain gas costs of doing so, or wrap them client-side in a STARK, and then reuse the leanSTARK route.

5

How soon is 8288 shipping? I*? J*? I’m still not seeing the either/or requirement against an EIP that is yet to be proposed for a fork.

Thats one to two extra years without any standard post-quantum sigs.

Don’t forget we need to save time for a large set of end users to migrate to post EC addresses, which in itself will take at least 2 years.

6

Yeah I agree, we could do both. I just think it changes the framing of the EIP - the precompile isn’t the endgame solution, but provides a way for users who don’t mind paying higher gas costs to migrate earlier.

7

The critical thing 8288 solves is the data load from post quantum signatures. All the current algos have a large footprint and there are only a couple on standardization track that have a key and sig size that I would characterize as “not awful”, and they have their warts (SQISign has a huge compute burden and MAYO-2 has a large pubkey). so zk aggregation needs to be in the toolbox.

But the penalty for staying out of that toolbox should be on the order of tens of gas, not tens of millions of gas.

8

That’s a good point, the cost of staying out of the toolbox is pretty significant though, probably too expensive for most users.

I think the motivation or rationale could mention this though - in the long-term it provides an opt-out from using zk aggregation. For some applications that care about proving latency, regulator compliance, or using certain HSMs might chose the precompile over the default path

9

FWIW, I oppose this EIP because I think it enshrines the wrong approach to precompiles. Ethereum has a poor track record with crypto-specific precompiles: we have added specialized primitives such as BLAKE and BLS that have seen limited adoption relative to the complexity they introduce, leaving the protocol with long-lived implementation, testing, and maintenance burden for functionality that few applications actually use. Adding another specialized cryptographic primitive risks repeating that mistake. It also makes the zkEVM direction somewhat harder: every new precompile introduces another special case that zkEVM implementations need to support and prove efficiently, adding complexity where the goal should be to move toward a more general and uniform execution environment. At the very least, the proposed precompile also appears to be mispriced in terms of gas, since implementing and proving it efficiently inside a zkEVM is substantially more expensive than its native execution cost would suggest.

A more promising direction is to align with the consensus-layer roadmap and LeanVM’s focus on hash-based signatures. Over the past few months, we have made substantial progress in this direction: we now have an efficient SPHINCS implementation with relatively cheap on-chain verification, leveraging formally verified Solidity, as well as fast signing implementations suitable for hardware wallets, with MPC support also underway. More importantly, this approach has a credible scaling path: as laid out in the roadmap, these signatures can eventually be aggregated, allowing their verification cost to be amortized across many signatures rather than paid independently for each one. In my view, this is the only credible, scalable path we currently have for post-quantum signatures on Ethereum.

10

There are a number of thing to respond to, but the general theme is that the no-precompiles hash based crypto only approach makes sense from an aesthetic research driven context, but this proposal comes from the perspective of what regulated users will need and the hardware and cloud support they will be looking for. You can today use a cloud KMS to store your ML-DSA keys and you can buy a USB device that will store and sign your keys too. Better ones are on the way from hardware companies that make hardened hardware their thing.

For the precompile comparisons, BLAKE and BLS are bad examples, they were added to support two crypto specific use cases: proving zcash proofs for blake and CL proofs for BLS. The real comparison is P256, which is currently being used as AA authorization on a number of L2s. This is the same slot ML-DSA fits in and should be the comparison.

For zkEVM, my hot take is that any zkEVM that survives is going to be one that proves RISC-V or WASM, not EVM, so adding a precompile there is only the task of compiling the C code into appropriate byte code and proving that like a guest program (such as how risczero does it.). So a cycle to cycle comparison is apt there and I exect the gas to be the same multiple.

From a hardware perspective, it should be noted that major cloud providers already have KMS service support for ML-DSA and USB enclave devices to sign ML-DSA already exist. Better and cheaper ones are in the pipe from well known providers.

Should ML-DSA be shipped in lieu of SPHINCS+? Absolutely not. Both should ship. By having two high quality signatures from different families it is an important hedge in case either one of them experiences an existential threat like ECDSA has with quantum computers. Any zk proving mechhanism that is suitable for XMSS family signatures can also support arbitrary signatures, so I do not see supporting ML-DSA as an aggregation barrier.

The biggest threat I see is trading one mono-algorithm authentication scheme for another mono-algorithm scheme. The reason that Q-Day is such a foundational threat is that we have no active and live alternative to ECDSA. If we had support for multiple families things would be a lot lower stakes because the process would be to sunset one family of signatures while a new one is brought online, and the other live alternates continue.

To not adopt cryptographic agility would just be taking all of our eggs out of one basket and putting it into a shinier, fancier basket that is again, just one basket.

11

I didn’t want to put it this bluntly, but I think EIP-8355 is also quite shortsighted. What happens if it actually sees significant adoption? With 2.36 KiB signatures and no aggregation, this could put substantial pressure on network bandwidth and blockspace. At that point, either the network bears the cost or gas pricing has to be adjusted upward again.

I don’t think the RISC-V/WASM point resolves my concern. Even if verification is compiled to RISC-V or WASM and proven through a general-purpose zkVM, its proving cost still needs to be measured and reflected in the gas price. The assumption that the native execution cost ratio will translate cleanly into proving cost is exactly what I think needs to be benchmarked before setting the price at 6,500 gas.

Separately, the software side is moving very quickly. Fireblocks just brought pure EVM ML-DSA-44 verification down to 1.23M gas, a 6.6x improvement over the previous implementation, and I expect that number to keep going down. At the same time, I expect a prover-aware price for the precompile to be materially higher than 6,500 gas. Those two numbers may end up much closer than they look today, with some margin for the precompile, of course. That makes me even less convinced that we should enshrine this now.

12

There is already a data carriage cost built in for calldata. If that is insufficient for validation then there are deeper issues. For transaction formats like frame they all need to keep the signature size cost calculated already.

I am not proposing that we go blindly with the gas price. Of couse we need to benchmark, But multiple indpendent benchmarking sites like pq zoo (NIST PQC Signature Zoo) sustantiate mldsa verifies faster than ecdsa. If the zk circuit is based off of the compiled ecdsa then there would need to be something else going on for the ratios not to hold (like a custom circuit). But of course, there will be benchmarking of the gas cost. 6.5k is probably high based on these cycle count estimates if done relative to ECDSA. I carired over the 8051 proposal costing because of course we benchmark to get real values.

1.23M gas for a signature is a non-starter for general usage, if anything this underscores why precompiles are needed. A signature scheme that is 100x-1000x the cost of the current ECDSA scheme will not be adopted because of price alone. And this is with AI assisted improvements. This is why I don’t see a bright future for EVMification of precompiles, the EVM is the wrong ISA to target.

My goal is to make a real PQ signature available for frame transacitons so it can fulfill it’s stated goal of enabling PQC.

13

My goal is to make a real PQ signature available for frame transacitons so it can fulfill it’s stated goal of enabling PQC.

I think this still misses my main point. The issue is that EIP-8355 does not scale well if it actually becomes widely used. A 2.36 KiB signature with no aggregation means every additional signature adds a substantial amount of data that has to be propagated, stored, and processed by the network. Saying that calldata already has a price does not make that scalability problem disappear. If adoption becomes significant, either the network absorbs that load or the pricing has to rise enough to discourage usage.

That is the part I think cannot be hand-waved away. We should be evaluating not only whether ML-DSA can be made cheap enough to use, but what happens if it succeeds and becomes common. A design that only looks reasonable at low adoption is not a scalable long-term solution.

14

Aggregation should be part of the long term solution, but that is making perfect be the enemy of better.

But we need to consider how that aggregation will actually work. Users will still sign transactions, and those signatures will need to be stripped before they are aggregated, so all that data will need to be sent to whoever is aggregating. That is why the transaction formats need to support stripping signatures from transactions. Frame as I understand it supports this, but the real dark horse here is SSZ encodingm which was built for stripping data and keeping the hash stable.

But you are right that nothing about post quantum cryptography can be hand waved. Every PQC algorithm has signficant trade offs. Every signature except SQISign is larger in either key or signature, and that one has an incredibly high compute hash based sigs have large keys and sigs. Multivariate has forms with large keys but small sigs, where if we support key registration it has potential for smaller unstripped transactions. But both of these will not see their final standardized forms until about 2029, assuming they don’t get killed in the standardization process.

Large key and signature sizes are not ideal, but the only other alternatives are waiting 2+ years for solutions that have not been proven in production yet, with performance profiles that are unknown, with hardware support that is also unknown. That is a huge bucket of risk to carry around.

This isn’t an instead-of proposal to what may be coming years from now, this is an in-addition-to proposal. And based on the principals of Cryptographic Agility we need to have support for multiple families, so we don’t experience the same brittleness if we go with only one family and problems are discovered. Especially for a bespoke specialied implementation.

1 Like
15

Where is the 2+ years figure coming from? We just launched a testnet yesterday with pure SPHINCS verification running today: http://daisugi.fyi:3000/

And aggregation is not some vague multi-year research item either. We expect to have an aggregation prototype in the next couple of weeks, which should let us prove out the core idea and get real performance numbers.

So I don’t think it is accurate to frame the alternative as “wait 2+ years for something unproven.” We are already testing the non-precompile path now, and we should have much better evidence on its aggregation and performance characteristics very soon.

16

strawmap slates this for J* release. At current pacing that’s on the order of 2 years to live.

17

well it is a strawmap…. it can change if needed (by definition)

18

Hi everyone,

Thank you for putting forward EIP-8355 and articulating the specific architectural deltas relative to EIP-8051. The framing—focusing on constructive integration rather than fragmentation—is the right approach for long-term cryptographic primitives at the EVM layer.

Below is technical feedback evaluating the four deltas, the state vs. gas trade-offs, and considerations for client implementations:

1. State Bloat vs. Verifier CPU Overhead (Delta 3: Compressed Keys)

The decision to enforce standard compressed public keys (1,312 / 1,952 / 2,592 bytes) over EIP-8051’s pre-expanded 20,512-byte keys is structurally the sounder direction for Ethereum’s state growth:

  • Storage Footprint: Account authenticators are persistent contract state. Storing ~20 KB per key severely degrades the state trie and disk footprint across all full nodes.

  • Pricing Execution: Moving matrix expansion (ExpandA via SHAKE-128) inside the precompile shifts the burden from perpetual global state storage to one-time transaction execution gas.

  • Potential Compromise: If ultra-high-throughput rollups or specific L2s want to avoid expansion latency at all costs, sibling precompile addresses for pre-expanded keys could exist, but the L1 default should favor the compressed standard representation.

2. Standard Compliance & Verification Integrity (Delta 2 & 4: Variable-Length Message & Pure FIPS 204)

The critique of EIP-8051’s fixed 32-byte header is compelling:

  • Avoiding Pseudo-Standards: A bare 32-byte message without the standardized OID prefix is neither pure ML-DSA nor standard HashML-DSA under FIPS 204 §5.4.

  • Calldata Layout (pubkey ++ signature ++ message): Placing the variable-length message as trailing calldata cleanly avoids complex RLP or ABI encoding inside the precompile, while ensuring out-of-the-box compatibility with external enterprise HSMs, TLS certificates, and WebAuthn authenticators that sign variable-length messages natively.

  • Fixed Context (ctx = ""): Freezing ctx to the empty default is a practical trade-off. It aligns with X.509/TLS norms and allows client teams to leverage existing, upstream audited libraries (e.g., liboqs, RustCrypto, OpenSSL) without requiring downstream patches for unexposed context parameters.

3. Security Margin (Delta 1: Parameter Sets 44, 65, and 87)

Supporting NIST security levels II, III, and V upfront is prudent:

  • Credential Lifespan: Unlike session keys or transient ZK proofs, account authenticators guard capital over multi-year or multi-decade horizons.

  • Retrofit Friction: Allocating a contiguous 3-address block today carries minimal overhead, whereas retrofitting levels III and V later would require another consensus hard fork.

Questions & Next Steps for Benchmarking

  1. Benchmarking Matrix Expansion (ExpandA):

    • The placeholder gas numbers (6,500 / 9,000 / 13,500 base) will be the primary point of scrutiny for client developers.

    • Has initial micro-benchmarking been run across multiple client runtimes (e.g., Go via go-ethereum, Rust via revm/reth, or C++ via Besu/EVMONE) to measure the real-world execution skew introduced by ExpandA under adversarial inputs?

  2. Path to Convergence with EIP-8051:

    • Have the authors of EIP-8051 engaged on these four points? If consensus forms around variable-length trailing messages and compressed keys, folding these specifications into an updated EIP-8051 would provide the cleanest path forward for All Core Devs (ACD) consideration.