Thank you @dcposch
Yes, I value overall idea for allowing a precompile contract to be used as regular contract first, demonstrate the adoption and usefulness and then be migrated to precompile. To give it a name to refer to this approach, I’d call it “Progressive Precompile Contract” just like the “progressive” in “*Progressive Web Apps” .
This could turn into two EIPs:
(1) one EIP for Progressive Precompile Contract (
Information EIP as a “recommendation” or
Meta EIP as a formal policy) and
(2) one EIP for the solution of CREATE2 Shadowing (likely to be categorize as an ERC).
The CREATE2 Shadowing and similar approach provides one of the solutions.
In particular, using CREATE2 Shadowing allows a cross-chain consistency for precompile contract to stay the same.
Note this is not the only possible approach to achieve the Progressive Precompile Contract. This could potentially unblock many Precompiles such as EIP-2537 EIP-2537: Precompile for BLS12-381 curve operations
Here are the prior discussion on the github and I am cross-posting here for better awareness
dcposch 2 days ago •
Curious if people are interested in
In short, if we make
PRECOMPILED_ADDRESS the CREATE2 address of a contract that implements identical functionality–instead of a special low address like
0x00..0019–then it allows a smoother deployment.
Chains will adopt this EIP at different times; maybe certain L2s are first, others later, and mainnet last. With CREATE2 shadowing, contracts can work on all chains immediately. They just become more gas-efficient once a given chain adds the precompile.
This is especially salient for this particular precompile, since a primary use-case for it is hardware backed wallets. A 4337 account is itself a CREATE2 contract that runs on all chains with identical code.
A related benefit is that it reduces the need for upgradeability in user contracts.
xinbenlv 2 days ago •
@dcposch I like your idea. I see the biggest merit of what you describe being a route reduce barrier for adding precompile contracts, mitigating the chicken-and-egg problem of “needs to demonstrate usage and interest to convince adding precompile” vs “needs adding the precompile to get more usage”.
I would be happy to collaborate if you want to propose an EIP for Create2 shadowing
The idea looks very interesting. I also would love to follow future plans and integrations about it.
dcposch 15 hours ago •
@xinbenlv happy to, but does it need an EIP? this is more a general pattern that can be applied to all precompiles that are pure functions
for future pure-function precompiles, CREATE2 shadowing seems like a win/win
xinbenlv 15 hours ago •
I agree with you having a CREATE2 will be a wthat it’s win/win
To answer your question “does it need an EIP”? I’d assume the question being: Do we need to standardize it?
Here is what I think:
When there are many ways and variables (“moving pieces”) to do the same thing, standardization helps people coordinate. An example would be screw driver and screw, the size of screw bing standardize so people can manufacture screw and drivers independently and they will work together.
In the CREATE2 shadowing, I presume there are a few “moving pieces.” that if people make different choices, they will end up with the different sizes of screw, hence there are value to standardize.
For the same functionality, ideally everyone use the same contact address generated by CREATE, so that ultimately, with a hard-fork we can change them to precompile and with lower gas cost. We don’t want people generating different contacts deployed at different addresses.
How to determine the input of CREATE2? Which
- 2.1 Are there going to be a sender that everyone want to use so if nonce and bytecode are also determined it we can all agree upon the contract address generated by CREATE2?
- 2.2 How do we generate
nonce? Shall we do something like ERC-600 / ERC-601 or BIP-32?
- 2.3 Should there be any magic in bytecode? E.g. Should bytecode be consistent should there be any additional behavior that caller can expect?
These are a few things I can think of.
To this point, I think the discussion of CREAT2 shadwing seems a bit off topic from this EIP.
If you are open to it, we shall probably make a ethereum-magician.org post to discuss, and leave this PR for the Precomiple of secp256r1 Curve support.
dcposch 11 hours ago
Yeah, fair points. The CREATE2 address would eventually have to be part of the proposed precompile regardless. I agree re: standardizing how it’s created.
Happy to make an ethmagicians post
ulerdogan 5 hours ago
Considering that the solutions that are expected to be presented as precompiled contracts cannot always be implemented as a Solidity smart contract, can we say that this is a downside for the standardization purpose?