Remove TXCREATE and InitcodeTransaction
#76
Conversation
You can do that by calling EOFCREATE in the initcode. |
Yes, but it's a tiny bit hacky, and constrained by max_initcode_size (unless the code is the same for each instance), which was not the case with InitcodeTx+TXCREATE. I'll amend the bullet point to make it clearer. |
spec/eof.md
Outdated
| - concatenate data section with `(aux_data_offset, aux_data_offset + aux_data_size)` memory segment and update data size in the header | ||
| - if updated deploy container size exceeds `MAX_CODE_SIZE` instruction exceptionally aborts | ||
| - set `state[new_address].code` to the updated deploy container | ||
| - push `new_address` onto the stack |
There was a problem hiding this comment.
self-note: this line needs fixing in case this is ever considered.
spec/eof.md
Outdated
| - it is checked if the initcode container has its `len(data_section)` equal to `data_size`, i.e. data section content is exactly as the size declared in the header (see [Data section lifecycle](#data-section-lifecycle)) | ||
| - transaction fails if any of those checks were invalid (gas for initcode execution is not consumed. Only intrinsic creation transaction costs were consumed) | ||
| - execute the container in "initcode-mode" and deduct gas for execution | ||
| - calculate `new_address` as `keccak256(sender || sender_nonce)[12:]` |
There was a problem hiding this comment.
Can address be calculated with CREATE2-like scheme here instead? as we're anyway applying special EOF-rules to this kind of transaction.
There was a problem hiding this comment.
I didn't have an idea how to supply salt to here, so I punted it for now. Unless this approach is partially revived to do away with the Creator Contract, this is probably not useful (TXCREATE has good reasons to exist). Salt would need to be crammed into some non-standard place or given as argument to RETURNCONTRACT, I don't see an elegant solution, any ideas?
There was a problem hiding this comment.
I guess we could cram salt into data section, next to calldata 🙈
There was a problem hiding this comment.
But then how do you fetch it and apply? Note that salt is an argument to TXCREATE, which is implicit here, we start execution just after the moment where it "would-have-been".
You either need to move it to RETURNCONTRACT or have a ugly special rule, that it is first bytes of the data_section, and the creation logic peeks there.
There was a problem hiding this comment.
Yeah seems even uglier than I thought, probably not worth it, let's stick with the nonce-based scheme.
|
I'll close this PR to demonstrate we're not actively considering a design without TXCREATE (I think we aren't at this point). I'll add the motivation for TXCREATE, which we unearthed here, to the EIP-7620. Meanwhile, we can still continue any discussions we have here ofc. |
|
Cherry-picked improvements from #78 and reopened |
|
I would move TXCREATE / InitcodeTransaction spec into another file in a separate PR, then probably merge #78 |
|
I decided to use this PR as the "separate PR". Rebased on top of |
TXCREATETXCREATE and InitcodeTransaction
|
Decided to move ahead with this during the EOF impl call:
|
This PR for now is just to visualize the impact of substituting TXCREATE/InitcodeTransaction/Deployer Contract with some application of "legacy-like" creation tx adapted to EOF.
Even if late, the amount of simplification this enables warrants considering it, at least for the sake of establishing the motivation for having TXCREATE and friends in EOF.
Advantages so far:
Disadvantages:
MAX_INITCODE_SIZE, where all contracts must fit in.msg.kind == EVMC_EOFCREATE), so thatRETURNCONTRACTis interpreted correctly in EOF-creation txsTXCREATEto exist)