From d670d04e8b176f4f9fc2dc8abcc3a0ac93a57561 Mon Sep 17 00:00:00 2001 From: Ignacio Hagopian Date: Fri, 30 Aug 2024 15:42:27 -0300 Subject: [PATCH] eip7620: typos and eip links Signed-off-by: Ignacio Hagopian --- EIPS/eip-7620.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-7620.md b/EIPS/eip-7620.md index 410f4620d86c8e..dc378097b3cf1a 100644 --- a/EIPS/eip-7620.md +++ b/EIPS/eip-7620.md @@ -53,7 +53,7 @@ We introduce two new instructions on the same block number [EIP-3540](./eip-3540 In EOF EVM, new bytecode is delivered by means of creation transactions (with an empty `to`) in the form of an EOF container (`initcontainer`). Such a container may contain arbitrarily deeply nesting subcontainers. The `initcontainer` and its subcontainers are recursively validated according to all the validation rules applicable for the EOF version in question. Next, the 0th code section of the `initcontainer` is executed and may eventually call a `RETURNCONTRACT` instruction, which will refer to a subcontainer to be finally deployed to an address. -EOF creation transactions (ones with an empty `to` and with `data` starting with `EF00` magic) are defined in detail in a separate EIP. +EOF creation transactions (ones with an empty `to` and with `data` starting with `EF00` magic) are defined in detail in [EIP-7698](./eip-7698.md). `EOFCREATE` instruction is in turn a replacement of the `CREATE` and `CREATE2` legacy instructions allowing factory contracts to create other contracts. The main difference to the creation transaction is that the `initcontainer` is selected to be one of the subcontainers of the EOF container calling `EOFCREATE`. It is worth noting that no validation is performed at this point, as it has already been done when the factory contract containing `EOFCREATE` was deployed. @@ -70,11 +70,11 @@ Details on each instruction follow in the next sections. - deduct `GAS_KECCAK256_WORD * ((initcontainer_size + 31) // 32)` gas (hashing charge) - check that current call depth is below `STACK_DEPTH_LIMIT` and that caller balance is enough to transfer `value` - in case of failure return 0 on the stack, caller's nonce is not updated and gas for initcode execution is not consumed. -- caller's memory slice [`input_offset`:`input_size`] is used as calldata +- caller's memory slice `[input_offset:input_size]` is used as calldata - execute the container and deduct gas for execution. The 63/64th rule from [EIP-150](./eip-150.md) applies. - increment `sender` account's nonce - calculate `new_address` as `keccak256(0xff || sender || salt || keccak256(initcontainer))[12:]` -- behavior on `accessed_addresses` and address colission is same as `CREATE2` (rules for `CREATE2` from [EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md) apply to `EOFCREATE`) +- behavior on `accessed_addresses` and address collision is same as `CREATE2` (rules for `CREATE2` from [EIP-684](./eip-684.md) and [EIP-2929](./eip-2929.md) apply to `EOFCREATE`) - an unsuccessful execution of initcode results in pushing `0` onto the stack - can populate returndata if execution `REVERT`ed - a successful execution ends with initcode executing `RETURNCONTRACT{deploy_container_index}(aux_data_offset, aux_data_size)` instruction (see below). After that: @@ -175,7 +175,7 @@ Creation transaction, `CREATE` and `CREATE2` cannot have its *code* starting wit ## Security Considerations -It is the EOF creation transaction (specified in a separate EIP) which needs a detailed review and discussion as that is where external unverified code enters the state. Among others: +It is the EOF creation transaction (specified in [EIP-7698](./eip-7698.md)) which needs a detailed review and discussion as that is where external unverified code enters the state. Among others: 1. Is its complexity under control, ruling out any DoS attempts 2. Is it correctly priced and always charged for