Ultimately, precompiles and EVM are both the wrong place to put most cryptography support into Ethereum. The reason is that precompiles and EVM both operate on data that has to be included into the ethereum chain somehow, which realistically means included in a block as calldata. That space is limited - even with PeerDAS and blocks-in-blobs, there's a practical cap of ~8 MB/s before it starts getting uncomfortable. Remember: it's not a blockchain. It's a cryptographic world computer. Any data/computation that does not need to be in the "main thread" of data/execution should not be put into the main thread. Instead, the correct solution is... EIP-8288 maximalism. If you have any heavy computation that's self-contained, compute it and STARK it client-side (this is quickly getting faster and faster, even on phones), and push the STARK through the EIP-8288 recursive aggregation mechanism. The chain sees the fact that the computation was done and what the result is; it never needs to see the actual data and computation. This way everyone can use whatever cryptography they want, the Ethereum chain can be lean, and we never need to add more precompiles again.

Big congratulations to the @zksync airbender team for this milestone. At this point, I consider the battle for speed to be definitively won, and the top priority for zkEVMs should shift fully to security. To me that means formally verifying (i) equivalence of the arithmetization to the ethereum spec (ii) a hard maximum bound on (prover cost) / (amount of gas in block) (iii) security of the proof system itself firefly.social/post/x/211001…