–
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
What if this “precompiled” EVM code was run without gas checks and other overhead – thus giving better performance – but with gas costs assigned in the same ways that precompiles are. Might expand the number of precompiles that can replaced with EVM code without too bad of a performance regression.
1 Like
I like that this preserves the constant cost of precompiles. But perhaps precompiles should not have a constant cost. Consider modular inverse; it uses approximately 1000x more computational gas in the worst case than in the best case.
Hmmm. They should priced by computational complexity.
1 Like