Have creation transactions run in runtime mode

[pdobacz]

Formalization of the idea tossed on discord and discussed briefly during the EOF implementers call.

Opening the PR just to assess the fresh idea in writing, does not mean yet we're changing the spec.

Another PR with the version to relax the RETURN/STOP validation instead: #119

[pdobacz]

Added some first thoughts which occurred to me during writing this down

[pdobacz]

Potential Problem 1: applying initcode-specific rules (eip-3860) to something which is not initcode

[pdobacz]

Potential Problem 2: this smells to me. I even consider adding a magic to the tx_address keccak256 for good measure. Decided not to, but I don't like this.

[chfast]

This is commonly discussed thing: should the storage persist in such account. In this context this address is used only once so this is not very practical.

The first version of 7702 actually sets code for the duration of the transaction. I think this may be fine too.

[pdobacz]

I invented a new name for this. Calling it "an EOF runtime container" seemed somewhat off (?) not sure why

[pdobacz]

Idea dropped on the EOF impls call (reasons in comments here and #119 also and here: ethereum/pm#1051 (comment) )

[pdobacz]

Taking the liberty to duplicate @shemnon 's feedback on this here for completeness, and also to reply to it:

Danno's take on #118 - It causes problems with (a) storage and (b) nonce-based addresses.

For storage, the runtime could read/write storage from an EOA, which is an ongoing issue with EIP-7702. We don't want to be mis-alighed with their decisions.

For nonce-based addresses, the returned contract address from the create tx call will not have a contract at it, as the EOFCREATE call would create a different contract ad a salt based address. This for sure broke older dev tooling that assumed the contract address was nonce based from the account and never checked the transaction receipt, some may still do that when polling the address for info from RPC. It also makes repeated deployements difficult as we would have to chagne the salt on each call.

We would either introduce inconsistencies with legacy without need or we would need to re-work some assumptions, such as allowing EOFCREATE to inherit the calling address if it is a create transactions, which feels just as hacky as it sounds.

[pdobacz]

@shemnon

It also makes repeated deployements difficult as we would have to chagne the salt on each call.

All valid points, I just want to throw in here I'm not sure about the part quoted above - the "sender" address for the top-level frame changes every time (it is keccak(sender | sender_nonce), so every creation tx changes it). Unless you've meant calling a couple of EOFCREATE in a single creation tx, which is no different from how CREATE/2 would work in such context.

---

But nevertheless, I think the storage (and value!) are problems for this #118 here.