Long-tail precompiles to EVM, retiring rarely used special contracts

Strawmap J* (2028~29) · EVMify long-tail precompiles

Three rarely used precompiles, RIPEMD-160, MODEXP, and BLAKE2f, are replaced with ordinary EVM code that does the same job. The addresses and functionality stay the same, and only the special implementations that clients maintained separately are removed.

Why it is needed

Ethereum has special contracts called precompiles, implemented separately inside client software to process certain computations quickly. Every client team has to build and maintain them on its own, so there is a continuing maintenance cost. If implementations diverge, it can lead to consensus bugs. For zkEVMs, which verify EVM execution with zero-knowledge proofs, each precompile needs an optimized implementation separate from the EVM, so the burden is even greater. Yet the three precompiles RIPEMD-160, MODEXP, and BLAKE2f are in practice rarely used. RIPEMD-160 has extremely little onchain usage. 99.99% of MODEXP usage is concentrated in a single use, zero-knowledge proof (SNARK) verification, and BLAKE2f is effectively used by just one contract. This item replaces the internal implementations of the three addresses with ordinary EVM bytecode, which reduces the number of special implementations clients must maintain and also shrinks the zero-knowledge proof circuits and the audit scope. However, the exact bytecode to deploy and a gas comparison table are not yet specified, and MODEXP calls with large inputs are expected to become more expensive. It was submitted as a Hegotá candidate in July 2026, but in the September call it was excluded on the grounds that performance benchmarks for the replacement code were not mature. Everyone agreed on the direction, and Strawmap places it in the J* fork (2028 to 29) slot, but that is only an estimate, not a commitment.

How it works

  1. Today the three addresses are precompiles When addresses 0x03, 0x05, and 0x09 are called, the client handles them with code implemented separately inside its software and charges gas using a precompile-specific formula.
  2. Install code at the fork block At the start of execution in the block where the change activates, EVM bytecode with the same functionality is placed at the three addresses, and from that block on they are no longer treated as precompiles. This is the same approach as EIP-7666, which changes the identity precompile (0x04).
  3. Afterward they run like ordinary contracts The address and functionality seen by the caller stay the same. Gas is charged as the sum of the costs of the executed instructions instead of a dedicated formula, so the cost changes.

Related EIPs

← Roadmap