Precompiles continue to be a pain point for zkVMs: each one is a special case that needs its own hand-built proving logic, and they're among the slowest and most expensive parts of a block to prove. EIP-8200 aims at replacing precompiles with ordinary EVM bytecode. Same behavior, but a zkVM can prove it like any other contract. Plus it simplifies the protocol by removing a set of special cases every EL client has to implement and maintain separately. Precompiles today run natively inside EL clients as fast compiled code ('cheap gas'), while their replacements would run as interpreted EVM bytecode (slower, using more gas). Closing that gap is akin to gas-golfing: squeeze the bytecode until it's as cheap as possible. turns this into an open, verified challenge. Anyone with good prompts and sufficient token budget can compete —> AI accelerating L1 R&D (make sure to check out the other autoresearch challenges as well) EIP-8200 is PFI'd for Hegota and facilitates EIP-8025 (execution proofs on L1). This is the L1-zkEVM route to scaling; when validators verify proofs instead of re-executing every TX, so the gas limit can grow significantly: —> More premium blockspace, more onchain activity, more economic bandwidth on L1 itself

Wanted to shine some light on a Hegotá non-headliner worth paying attention to in the run-up to zkAttesting: EIP-7709 ('Read BLOCKHASH from storage and update cost'), to be proposed for inclusion at this Thursday's ACDE Tl;dr a forward-looking, minimally invasive EIP that simplifies stateless execution and removes a protocol special case Background: BLOCKHASH as an EVM opcode lets contracts read a recent block's hash (up to 256 back), which is used for example in the context of commit-reveal schemes. Today it's priced at 20 gas, i.e. very cheap and close to free in practice, because for a stateful node holding recent blocks locally, that's roughly what it costs. Meanwhile, EIP-2935 (live since Pectra) has been quietly writing those hashes into a system contract's storage every block. The data is already in state. BLOCKHASH just does not acknowledge it. The opcode still behaves as a bespoke in-memory lookup rather than a regular state read. This duplication is fine for stateful clients, which already hold the data locally. But the stateless execution path – what provers target and zkAttesters verify – has to carry an extra path just for this one opcode, on top of the standard state-proof handling already used for everything else. EIP-7709 removes this special case. It treats in-range BLOCKHASH as the storage read it already is, with regular SLOAD pricing. No behavior change for users or contracts. By routing it through the same witness machinery as every other state read, the execution witness becomes more standardised and provers stop paying for a workaround. Honest tradeoff: contracts that rely on cheap BLOCKHASH will pay more gas. A benchmarking analysis on user impact is underway. Zooming out, every special case the protocol carries today, zkAttesting inherits tomorrow. Optional zkEVM proofs (EIP-8025) are on the horizon, and cleaning this up now thus appears worth considering.