@xinbenlv curious, how would implement a progressive precompile without CREATE2?
It seems CREATE2 is the best for now. But in theory CREATE could be used if people can agree with sender and always use the same nonce.
Another question, when using CREATE2, which sender do we plan to use?
Could there be any security implication when using Foundry default CREATE2 sender?
I think it’s a reasonable choice for sender. It’s this contract, small and widely used:
I think there is a potential complexity of how do we make all (today and future) EVM chains and L2s, capable to use the exactly same sender. Which is a requirement if we want to make it progressively precompile in the future.
Seems the other big problem is that we don’t have source code / bytecode for any of precompiles (except Identity).
See a previous discussion about a precompile for CREATE2
To my understanding, there is no need for a precompile: there is no real benefit of creating a new opcode just for this purpose, it is enough to adopt the de-facto deterministic deployer mentioned (0x4e59b44847b379578588920cA78FbF26c0B4956C), and only require that chains make it available - it might require a "irregular state " as @MicahZoltu mentions in the above post.
Note that once deployed, this contract is fully compatible with any EVM chain.
To my knowledge, BASE chain (which is EIP-155 from day one) did do this state-change to deploy the contract
1 Like
For any contract that wants to petition to become a precompile, they are supposed to share the full transparency of computation and source code so that clients could implement them inside their own client. They need to make it clear mathematically what’s steps expected to be executed and provide test case data, just like all existing precompile proposal.
@dror: I think that’s a different topic (though it could be a pre-requisite for this EIP to be feasible).
To clarify, the matter of discussion here are about “Can we allow a path for contracts to go from normal contract to precompile contract, whereas specifically the address of this contract’s deployment follow some deterministic provided by CREATE2”
@dcposch maybe we shall change the topic to “Progressive Path towards Precompile” to avoid confusion?
Soliciting feedback: @abdelhamidbakhta (Author of EIP-5988), @Recmo (Author of EIP-1829), @chris
And everyone welcome.
Hi @spalladino, as we are searching a possible route here, we discover you previously proposed a CREATE2 precompile, in which you argue in this tweet
But how can you ensure the generic factory is available at the same address across all networks, so the resulting deployment address is the same?
We agree with you. The topic disucssed here propose a progressive way to make a contract become precompile. One of the dependency is to find the same sender across all networks. It shows the usefulness of your idea. We here ask for your feedback about our idea too.
Cross-posting a technical feedback from Tobias Oberstein author of EIP-665 introducing Ed25519 signature verification
I understand the idea, maybe it would help, I don’t know. What I would
expect is massive gas cost for such a standard EVM (non-precompile)
based Ed25519 verify function. The cost will render it practically
useless on mainnet.
So if it doesn’t gain traction using a non-precompile, that might then
be the case since it is not a real solution to Ed25519.
My response:
Here is how I see it: the way to convince EVM builders to accept a contract worthy of precompile is that: such computations are critically useful and lack alternatives, so much so that people are using their non-compile despite the high cost of gas.
- An example would be Poseidon Hash which has unique usefulness in the ZK without better alternatives in the existing instructions and precompiles.
- Another example is the alt_bn128 (EIP-196 / 197) which is also critical and lacks alternatives.
For Ed25519, the original rationale is that it has a lower cycle. But whether EVM shall support them depends on whether there are wide enough adoptions. For example, if there are many signatures out there signed with Ed25519 that we want to on-chain verify, it shows an usefulness regardless of (currently) high gas cost.
We are proposing an approach so authors of precompile can demonstrate they point progressively, that’s the intention of our proposal.
And as you (Tobias Oberstein) mention in the EIP-665 which says
Despite being around only for some years, post-Snowden, these curves have gained wide use quickly in various protocols and systems:
- TLS / ECDH(E) (session keys)
- TLS / x.509 (client and server certificates)
- DNSSEC (zone signing)
- OpenSSH (user keys)
- GNUPG/OpenPGP (user keys)
- OpenBSD Signify (software signing)
Which mentioned DNSSEC.
One example of possible route for a non-precompile could be that so much people are wanting to verify DNSSEC or OpenSSH on-chain that they end-up using the non-precompile despite its high gas cost, and ultimately gain large enough traction to convince Client Devs to build it as a precompile and reduce gas cost.
A few quick thoughts:
Picking a good sender
I’m open to alternatives.
0x4e59b44847b379578588920cA78FbF26c0B4956C is widely used and seems to be available on all popular EVM chains. I’ve checked:
CC @Arachnid - let me know if 0x4e59... is a good choice. I’m curious what your level of confidence is that it’ll continue to be deployed to new EVM chains going forward.
Also happy to hear any arguments for a better already-existing CREATE2 deployer contract to use as our sender.
Lastly some context. While we’d like a stable and universal sender, it’s not a rigid commitment we’re stuck with. This proposal is about a clean path to ship new precompiles. Each precompile could use a different sender and nothing would necessarily break; specifying a good universal default is convenient but not essential.
Re: a precompile for CREATE2 itself
An interesting idea, but seems a ways off and not directly related to this idea. I think we can keep discussion separate–this proposal doesn’t depend on it.
Proposed precompiles like Ed25519 and gas costs
Even if the contract for a given function is too expensive for mainnet, it can still be valuable for compatibility on rollups. L2 costs are dominated by L1 data availability (calldata/blob data post 4844) – computation gas on L2 is cheap.
I think picking the sender (let’s call it “Designated Sender”) will be one of the key problem to make this Progressive approach work.
The ultimate promise is that: All EVM chains (including future EMV chain that don’t exist today) shall be able to deploy with the identical address of Designated Sender.
That means there needs to be a consistent way for that Designated Sender to come into existance in new chains, in all constraints to these chains.
For example, if a chain is designed to be permissionless, the Designated Sender needs to come into existence in a permissionles way. For example, if the one that you suggested, which is the Default Foundry Factory 0x4e59…956c that you referred to is created in the TX by The Wolves of Wall Street: Deployer 0x3fab…5362,
Which means the Wolves of Wall Street Deployer might have to publish they private key so new chain could establish them, which could have security implications.
Therefore, it seems so far, the sender itself needs to be a precompile (or have its own address), as proposed in the thread proposed by @spalladino
Which means the Wolves of Wall Street Deployer might have to publish they private key so new chain could establish them, which could have security implications.
That is wrong: the deployment of this deployer’s deployment is completely permissionless.
The deployment transaction is the same on all network, which means the network must accept non-EIP155 transactions and 100wei gas price.
So either the network accepts this conditions always, or it performs a one-time “non-standard state change” to include this transaction.
Note that regardless of how the deployer gets deployed, using it, doesn’t require any non-standard transaction, as it is a normal contract call.
BTW: the Base (testnet) network didn’t have the deployer deployed to begin with, and it has EIP-155 enabled fro day one, so we couldn’t install it ourselves.
We reached them out to deploy it, so that EIP4337 EntryPoint could be deployed at the standard address as on other networks.
The deployer’s code (by @Arachnid ) is here:
And an article describing this permissionless deployment method.
2 Likes
Makes sense, thank you!
So I think we have a clean way to deploy a contract at a deterministic address.
I’m curious about two other aspects:
-
Is there a good reason not to do it this way? In other words, a good reason to keep using low-numbered
0x00..0a,0x00..0bprecompiles. - What are the implementation challenges? Would love to hear from client developers on how much additional effort it would be to ship, say, the P256 or BLS precompile progressively.
2 Likes
@dror : thanks for the feedback, but if you mean to use pre-EIP-155 TX to deploy to deterministic address, IMHO, EIP-155 is enabled by default for most new chains that I know of, for the re-play attack exactly demonstrated by the old Nick’s method: Replay the same TX everywhere from any chain disregarding chainId.
Asking those new chains to include legacy Pre-EIP-155 transaction is no different than asking for their permission. If I understand it correctly, that alternatives of using permissionless deterministic deployment requires as strong of consensus as getting a hard-fork in those new chains, yet non-standard each time.
Alternatively, this proposal here provides a standardized way to do so.
The need for a deployer is clear.
It can either be a precompiled contract, which requires developer support on all existing (and future) networks, and it can be done by accepting an already proven solution on 20-some major networks, and thus only OTHER network need to do anything explicitly to support it.
Also, the required change is not any code modification, but nonstandard inclusion of a valid transaction.
Also, do you think you can convince the developers of ethereum, polygon, bsc, optimism, arbitrum, etc, that they need to push an EVM change, when their network already supports that feature ?
1 Like
CC @matt ; do you have a sense of relative effort for client developers?
For example, from where we are today, how difficult would it be to put a precompile like BLS or P256 at an existing CREATE2 address vs next sequential?
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
1 Like
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!
2 Likes
Why do these need to be Solidity code? If we want maximum performance hand-optimized assembly might be necessary.
1 Like