EIP-8200: EVMification

Discussion topic for EVMification of precompiles. Replaces blake2f, ripemd160, blake2f and the bls12 map to curve precompiles with equivalent bytecode.

2 Likes

Precompiles are good performance-wise. Complex operations such as keccak and ecrecover can be much faster when run natively than when run in the EVM. So, we would need some serious motivation to justify this change.

There should be a large prize for the gas golfing or we’re gonna end up with something suboptimal. And before that we’ll want to re-evaluate our gas costs for some of the cheaper operations so that the golfing is actually optimizing the right things.

Just to clarify, this would not apply to precompiles like ecrecover and the keccak opcode.

There should be a large prize for the gas golfing or we’re gonna end up with something suboptimal. And before that we’ll want to re-evaluate our gas costs for some of the cheaper operations so that the golfing is actually optimizing the right things.

Let me provide another way to look at it using the blake2f precompile:

blake2f has so far only been called by 3 contracts when we look at blocks 2M to 24M. In the last year, it has been called by 2 contracts, where one of the calls was a failure, so essentially one contract has been using this precompile.

If we were to 1000x the cost of blake2f due to evmification, the total tx cost for this contract on average would go up by 2% on average (because blake2f is not the dominant cost). Assuming this is true, and we of course need to quadruple check my numbers to make sure I didn’t make a mistake, I think it wouldn’t make sense to go through the efforts of gas golfing etc.

See the bottom of Precompile Detail for references to the data I mentioned above.

For others like modexp, its a bit more nuanced because there are two main usecases:

  • modexp where modulus is <= 256 bits
  • modexp where the modulus is > 256 bits

99.99% of its use is with the former since (snark verifiers) use elliptic curves and they need 256 bit modulo arithmetic.
The latter usecase seems to only be called for the RSA usecase and between blocks 2M - 24M, this has taken up ~300M gas, where half of that is a stress testing contract for zkVMs.

In this case, I think it makes sense to have an if statement for 256 bit modulus using mulmod (my current poc says this increases the precompile cost by 4-7x) and then using montgomery/barrett to cover the rsa usecase, I see an increase of about 15x for these rsa modulis because osaka made modexp more expensive)

1 Like