search

ipsilon / eof

Validation code for the EOF specification
Apache License 2.0
43 stars 19 forks source link

Have creation transactions run in runtime mode #118

Closed pdobacz closed 5 months ago

pdobacz commented 5 months ago

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: https://github.com/ipsilon/eof/pull/119

pdobacz commented 5 months ago

Idea dropped on the EOF impls call (reasons in comments here and #119 also and here: https://github.com/ethereum/pm/issues/1051#issuecomment-2137790609 )

pdobacz commented 5 months ago

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 commented 5 months ago

@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.