Progressive precompiles via CREATE2 shadowing

[matt]

It is no more difficult to deploy a precompile to an arbitrary address than it is to deploy to the next sequential address. You can see addresses are just hard coded: https://github.com/ethereum/go-ethereum/blob/8f2ae29b8f7743a14760e6f2b458ecddc8bb7d8f/core/vm/contracts.go#L112-L122

[xinbenlv]

Thank you for the feedback @matt.

The counter argument: hardcoded address can’t be progressive. Author of a precompile-contract-candidate can’t deploy one without permission from client team(s).

The core goal of this proposal is the process could be permission-less and progressive: make it possible for proposer to deploy a contract first and then get it recognized and accepted as precompile

I took that back. I misunderstand your point Matt. Thanks for the comment, that makes sense!

[gcolvin]

@dcposch

@ulerdogan oh for sure, this would be an optional standard for precompiles. It applies to pure functions which can be implemented reasonably efficiently in solidity.

That includes all the proposed cryptographic precompiles I’m aware of–P256, Blake3, BLS etc.

Why do these need to be Solidity code? If we want maximum performance hand-optimized assembly might be necessary.

[gcolvin]

Have we tried an EVM version with the gas counting turned off?

[dcposch]

Doesn’t have to be solidity. I should’ve just said “any pure function”.

–

Have we tried an EVM version with the gas counting turned off?

I’m not sure exactly what you mean, but it brings up another nice benefit:

When we ship a progressive precompile, an execution client can choose to implement it with no additional native code at all, just by overriding calls to that contract address (immutable, already onchain pure function) to cost a specific amount of gas.

[gcolvin]

I mean that if we had a special mode for running the EVM with gas counting and such off it might be performant enough to be used to write some precompiles as EVM code instead of native code.

[dcposch]

Cool idea.

We could test this. For EIP-7212, for example, we’d test by making an attack block that calls the fallback contract (30m gas / 3450 gas) = ~8000 times.

We run that block on a given client, setting a higher gas limit locally. If it the block processes acceptably quickly, then this approach would work on that client.

This would allow future precompiles in certain situations to be shipped as a configuration change, with no new code. Very minimalist.