EOF creator contract for devnets

[chfast]

After removal of the Creator Contract from the TXCREATE EIP we have to design a workflow for EOF code deployments on devnets and testnets.

Goals

Goals

1. Have a stable address for the Creator Contract.

Maybe goals

1. Have the creator contract in EOF.
2. Reuse the Creator Contract from the earlier revision of the EIP.
3. Mine a nice address for the creator contract.

Non-goals

1. Have a full-featured creator contract.

Creator contracts

Pass-though

txcreate(calldataload(0), calldataload(32), 64, calldatasize()-64, callvalue())

Initcode-bounded

txcreate(calldataload(0), calldataload(0), 32, calldatasize()-32, callvalue())

or

txcreate(calldataload(0), calldataload(0), 0, 0, callvalue())

Initcode and arguments bounded

calldatacopy(0, 0, calldatasize())
let final_salt := keccack(0, calldatasize())
txcreate(calldataload(0), final_salt, 32, calldatasize()-32, callvalue())

One-off

let fixed_initcode_hash := 0x...
txcreate(fixed_initcode_hash, fixed_initcode_hash, 0, calldatasize(), callvalue())

Workflow

1. Deploy the legacy creator contract with TXCREATE: either initcode-bounded, initcode-and-arguments-bounded or one-off with the hash of the EOF creator contract initcode. Use Nick's method to create and publish such transaction. This gives the stable address of this factory. This is the same as all system contracts' addresses are defined.
2. Deploy the EOF creator contract using the legacy creator contract from 1. Because 1 has a stable address, the EOF creator contract will have a stable address too: the addresses derived from TXCREATE used only depend on the legacy creator contract itself ("sender") and the final salt which depends on EOF creator contract initcode only (it should have empty arguments).

Which legacy creator contract?

• If we want to discourage any usage of it in the future, the one-off may be a good selection. However, it feels slightly wasteful.
• Because the EOF creator contract initcode doesn't use any arguments, we can ignore bounding these and use initcode-bounded one.

[pdobacz]

Re:

Use Nick's method to create and publish such transaction

We have the alternative to use an established factory (CreateX for example) which provides stable address toe-hold contracts across multiple chains. I haven't dug deeper, but I think it would also be possible to deploy on devnets using pre-signed transactions CreateX provides.

The benefit is that we get stable address on a probably wider spectrum of chains (Nick's method is not universal). Downside is that it is maybe less standard, less neutral, and different from what system contracts used. Needs discussion

[gumb0]

Initcode-bound and Initcode-and-arguments-bound variants here use inticode hash as salt, which makes deploying the same code more than once impossible. If it's an issue, need to include separate salt in the input separately.

[chfast]

Initcode-bound and Initcode-and-arguments-bound variants here use inticode hash as salt, which makes deploying the same code more than once impossible. If it's an issue, need to include separate salt in the input separately.

Ah, good point.

After some discussions yesterday, my short list was: initcode-bounded variant 2 or one-off. With the difference that initcode-bounded is minimally useful to external users, but maybe not so much after @gumb0 comment.