# EOFv2 [toc] ## Background The EVM Object Format (EOF) was proposed as a number of separate EIPs during 2021, because we did not anticipate it could be included in the same protocol upgrade due to the sheer surface of changes. For the same reason, while we initially considered introducing specific instructions for various sections (such as [DATACOPY](https://notes.ethereum.org/t-1tLFnLSKCtLZpb-Rw0IA?view)), we brushed off these and went for the least amount of changes. The recent idea of [banning instrospection of EOF accounts](https://ethereum-magicians.org/t/eof-proposal-ban-code-introspection-of-eof-accounts/12113) is of a similar vein. Going back some years we also thought about revamping the transaction format to more explicitly differentiate the create transaction (e.g. separate code and calldata). The never ending quest for removing gas introspection is also an enviable target. After the last month of heavy implementation and testing of what is called "Big EOF" ([EIP-3540](https://eips.ethereum.org/EIPS/eip-3540)/[EIP-3670](https://eips.ethereum.org/EIPS/eip-3670)/[EIP-4200](https://eips.ethereum.org/EIPS/eip-4200)/[EIP-4750](https://eips.ethereum.org/EIPS/eip-4750)/[EIP-5450](https://eips.ethereum.org/EIPS/eip-5450)) we seem to be at the limit of what amount of changes can be rolled out at the same time safely. Because of this we suggest the following: 1. Roll out EOFv1 with what is currently specified, as soon as possible. 2. Optional: Restrict some opcodes (such as `CREATE`) in EOFv1, and potentially enable it in the following upgrade if incremental improvements can be made. - We need a strong commitment that *something* will be done in the follow up upgrade, even if it is just enabling them without any changes, because with these disabled contracts can't create other contracts. 4. Plan and design EOFv2 with the following goals in mind, and roll it out when ready. Possibly 1 or 2 upgrades later. We do not see it being possible to roll out changes envisioned in this document together with the introduction of EOF, because that is akin to completely replacing the EVM in terms of complexity. ## Goals of EOFv2 1. No account code introspection, neither for the actual or any other account. 2. Complete abstraction of container format for the EVM runtime. There should not be a need to understand the structure from within EVM code at runtime. 3. Better separation of the account creation process. - This means the ability to access "constructor arguments" (calldata) vs code. - Involves a new transaction format. 4. No introspection and control over gas limits. - This means the revamping of the `CALL` instructions, which allows rectifying a number of pain points. 6. Could consider the requirements of [Address Space Extension](https://notes.ethereum.org/t5r5dxOTS3eJynqMK5Kc5A#ASE) and also explicitly introduce [EIP-1985](https://eips.ethereum.org/EIPS/eip-1985). ## Changes ### Headers No changes needed for headers. ### Instructions #### Introspection - Disallow `(EXT)CODE{COPY,SIZE,HASH}` in EOFv2. - In other contexts where they are available, `(EXT)CODE{COPY,SIZE,HASH}` to return a specific value on EOFv2 accounts. #### Contract creation - Disallow `CREATE` and `CREATE2`. - Introduce `CREATE3`. (<small>Or call it `EXTCREATE`?</small>) - It calculates the address the same way as `CREATE2`. - Takes `endowment`, `salt`, `initcode_memory_start`, `initcode_memory_length`, `data_memory_start`, `data_memory_length`. - Introduce a new transaction format. - It calculates the address the same way as `CREATE2` - Fields: `endowment`, `salt`, `initcode`, `data`. - (Side note: because [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) introduces a new transcation format, perhaps considering this and launching it together is prudent.) - The "data" argument is the same field we have today accessible via the `CALLDATA*` opcodes. This remains accessible. - Introduce `DATACOPY` and `DATASIZE`. - These instructions are usable to access the data section. Can consider adding an 8-bit immediate argument signaling the data section number, should we allow multiple sections. - Arguments: `memory_offset`, `data_offset`, `size`. - Copies data_i[data_offset .. data_offset+size] to memory[memory_offset .. memory_offset+size]. #### Account calls (gas introspection) - Remember that `CALLCODE` and `SELFDESTRUCT` are already disallowed in EOFv1. - Disallow `CALL`, `DELEGATECALL`, `STATICCALL`. - Disallow `GAS`. - Introduce `EXTCALL`. - This instruction has an 8-bit immediate for `flags`. The flags defined are: - `0x01` - View-context (static call). - `0x02` - Delegate-context. - (This may be a stretch, and perhaps keeping a number of opcodes for these different call types is better.) - The stack arguments are: `endowment`, `destination`, `data_memory_offset`, `data_memory_size`. - The return value is an enum: - 0 - Success - 1 - Failure - 2 - Revert - Note that the gas field and return offsets are removed.