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.