Allow RETURN/STOP in EOF creation tx code #119
Conversation
| - load deploy-contract from EOF subcontainer at `deploy_container_index` in the container from which `RETURNCONTRACT` is executed | ||
| - concatenate data section with `(aux_data_offset, aux_data_offset + aux_data_size)` memory segment and update data size in the header | ||
| - let `deployed_code_size` be updated deploy container size | ||
| - if `deployed_code_size > MAX_CODE_SIZE` instruction exceptionally aborts | ||
| - set `state[new_address].code` to the updated deploy container | ||
| 7. deduct `200 * deployed_code_size` gas | ||
| - deduct `200 * deployed_code_size` gas | ||
| 3. If execution ends with `RETURN` or `STOP`, no code is deployed |
There was a problem hiding this comment.
Is the account created (e.g. have nonce 1)?
|
This feels to me more hacky than other variants, because
|
Is this rule still applied? |
|
If we would go with this, it seems kinda logical to also allow STOP/RETURN in EOFCREATE-referenced containers, but I don't think it's a good idea. |
|
To quote @pdobacz from discord discussions
I think this is what my original idea was about how validation tests should work in regard to inicode mode validation, but then I realized it's pretty confusing, and better to explicitly validate either initcode mode or runtime mode for toplevel container of validation tests. And I think similar idea applies to the spec: the spec is more clear and behaviour is better defined if we require specific mode of validation for toplevel container in all contexts where we do validation (so in the spec it is only in creation tx and later possibly TXCREATE).
This exception makes it more complicated to figure out all the rules. |
|
Idea dropped on the EOF impls call (reasons in comments) |
Sibling PR of #118. This time we drop the requirement for
initcontainers in EOF creation txs be actually validated to be... "initcontainers", in the sense of not containing RETURN/STOP.The effect of this is that they can actually RETURN or STOP (without deploying any contract!), in addition to RETURNCONTRACT. So now the creation tx has access to the salt-based hashing scheme, and we also don't care about runtime/initcode mode of such containers.
Opening the PR just to assess the fresh idea in writing, does not mean yet we're changing the spec.