# EOFv1 spec open questions ###### tags: `EOF` ## Must be decided before V1 rollout - [x] `SWAPMN` (instead of `SWAPN`) - wanted by Vyper. Solidity is fine with either `SWAPN` or `SWAPMN`. - Most wanted variants: `SWAPMN` with one byte immediate (`M` and `N` 4 bits each), `SWAPMN` with 2 byte immediate (`M` and `N` 1 byte each) - Proposal: [EXCHANGE](https://github.com/ethereum/EIPs/pull/7819) - *1.11.2023 decision: Include both SWAPN and EXCHANGE (1-byte-immediate), EXCHANGE to be added to EIP-663.* - [x] Validate ~~first-level~~ subcontainers at deploy time so that `CREATE3` doesn't need to validate initcode at runtime - suggested by Vyper - Maybe we can recursively validate all subcontainers at deploy time, if we drop `DATALOADN` and only have `DATALOAD`. - Another idea is to provide deploy-size of subcontainer e.g. in subcontainer header, then we can validate all `DATALOADN`s against it. - decided to try this change - *Decided for recursive validation with the expected appended data section size encoded in subcontainer header* - [x] ~~[`CREATEF`](https://hackmd.io/@shemnon/CREATEF) - gets rid of one level of container nesting~~ withdrawn by Danno - [x] Gas costs for some instructions not specified yet - [x] `CREATE3` - 32000 - [x] `CREATE4` - 32000 - [x] `RETURNCONTRACT` - Only memory expansion cost for `(offset, size)` arguments - Security considerations of the EIP should mention possibility of additionally charging for aux_data appending, probably same cost as *data copy cost (`3 + 3 * data_words_appended`) - [x] Creator Contract and deprecation of creation transaction - spec is amended - [x] `CREATE4` needs to define limits for initcontainers transaction field. Relevant section: https://notes.ethereum.org/ZOEv9yyHQdmxTVaYiJmy9Q?both#Transaction-Types - 256 initcodes - EIP-3860 limit (48K) for each initcode - [x] Should `CREATE4` address initcodes by hash instead of indices - suggested by Danno - Hashes are larger - Hashes allow for block-level deduplicaiton - *Decided for hashes* - [x] `CREATE4` initcode validation failure semantics (what happens to gas and nonce) - Perhaps it makes sense to make it a light failure. - Validation is done only before CREATE4 initcode execution, otherwise CREATE3 and CREATE4 executions are the same. - Light failure would split gas charge in two parts: - Check if initcode with this hash exists - Charge 2 gas per word for validation (EIP-3860 charge) - Do validation - Charge 6 per word for hashing. - *29.11.23 decision: go with light failure, might consider pushing validation into transaction validity rules* - [x] Does `CREATE3` need an initcode limit to be 48K (`CREATE4` has it as transaction initcode limit) - Originally we intended not to have it, because implicit limit of 64K is okay. - Observation: `CREATE3` inside factory contract will always have initcode below 24K, because any contract is below 24K. Only if `CREATE3` is called inside `CREATE4`'s initcode it can go up to 48K. - *29.11.23 decision: makes sense not to have explicit limit for CREATE3* - [x] CREATE3/4 initcode and deploy code size limits checks - could be done at validation, given that we have all info about init/deploy sizes encoded in the header - i.e. validating CREATE3 we can check initcode limit, validating RETURNCONTRACT we can check deploy code limit - but depending on header design this may require parsing subcontainer first - *Turns out we still want to support variable-size aux_data and encode in container only minimum expected size. This means that deploy size has to be validated at run time.* - [x] `DATALOAD` and `DATACOPY` exceptionally abort if out of bounds, Solidity is in favor of returning 0s instead. - Solidity's issue with exceptional abort: if some code does DATACOPY into memory, and never accesses that memory afterwards, optimizer would like to remove this "dead" code, but it's possible only if DATACOPY would never abort. - *29.11.23 decision: fine to change to 0-padding* - [ ] Verkle friendliness? - whether or not to optimize against the future 32-chunking of code in terms of header content layout - tradeoff of future-proofing-risk vs optimizing gas costs, but maybe there are some improvements not specific to current Verkle design we can research ### Minor nice-to-haves: - [x] Forbid unreachable sections - *Decided to have this bar implementation issues to be found* ## Can be rolled out later without bumping EOF version - [x] `CREATE3` variant that has additional address parameter to get initcode from a container of another account - suggested by Vyper - *Decision:* not important right now - [x] `JUMPFI` - highly desirable by Vyper, code size regressions without it. - [x] 4b. or alternatively less restricted stack validation (one idea at https://github.com/ethereum/evmone/pull/676) - *Decision:* creating detailed write up of the problem and the two solutions - https://notes.ethereum.org/Fk1TksgjTxOotvQNL07mEQ - *1.11.23 decision: include relaxed stack validation and keep JUMPF and non-returning functions, but don't include JUMPFI. Solidity suggests to evaluate later whether JUMPF can be dropped.* - [x] `RETURNDATALOAD` alongside revamped CALLs - suggested by Vyper, code size regressions without it. - https://github.com/ethereum/EIPs/pull/7820 - Concern: semantics of OOB - *4.1.24 decision accepted to Megaspec in https://github.com/ipsilon/eof/pull/36* - [ ] `EXCHANGE` immediate encoding https://github.com/ethereum/EIPs/pull/7819 - [x] `EXTDATACOPY` - decided to be proposed in a separate EIP, EIP pending ### Minor nice-to-haves: - [x] Make data section optional again - Downside: appending data section in CREATE3/4 may be more than just append then. - *Decision: no strong arguments one way or another, we can keep it mandatory* - [x] Make `max_stack_height` in the header to mean upper bound - simplifies testing - *Decided not to change from equality requirement* --- ## EIPs TODO - [x] EIP-3540: Format spec to include subcontainers - [x] EIP-3540: Update creation semantics and `CREATE`/`CREATE2` and creation transactions mentions, replace with `CREATE3`/`CREATE4`. Legacy code is not allowed to deploy EOF. - [x] EIP-3540: Remove `PC` instruction changes? - [x] EIP-3670: Test cases shouldn't mention `CREATE`/`CREATE2` - [x] EIP-4750: Fix Execution section to remove runtime stack checks - [x] EIP-6206: Forbid CALLF to non-returning function - [x] EIP-4750 and EIP-6206: First section is non-returning, also semantics of RETF in first section not needed - [x] EIP-5450: Update for less restrictive stack validation - [x] Forbid unreachable sections (in EIP-4750) - [x] EIP for `CREATE3`/`CREATE4`, new transaction type, creator contract, ban `CREATE`/`CREATE2` (https://eips.ethereum.org/EIPS/eip-7620) - [x] Ban (EXT)CODECOPY etc. and semantics for legacy reading EOF contracts (EIP-3540) - [x] Ban gas introspection - [x] EIP-663: Merge `EXCHANGE` https://github.com/ethereum/EIPs/pull/7819 - [x] EIP-4200: tidy - [x] EIP-7480: tidy - [x] EIP-7069: tidy if included? - [x] Add Meta EIP?