# EOFv1.1 aka *EOF rollout Cancun+Prague* ###### tags: `EOF` During the Edelweiss interop we discussed how to avoid code (& gas) observability within EOF. This work culminates in a long document ([EOFv2 Design Space]( https://notes.ethereum.org/@ipsilon/eof2-design-space)) introducing a larger design mostly focusing around contract creation. We also agreed that rolling out EOFv1+EOFv2 in the same protocol upgrade is ambitious, and the following roadmap seems more realistic: 1. First update: Roll out a restricted EOFv1 - EOF contracts can be created via transactions, but not via CREATE-instructions 2. Second update: Roll out EOFv2 - Enables contract creation ## EOFv1 As described today in the EIPs: 3540/3670/4200/4750. Addition: we want to disallow cross-`DELEGATECALL`s between legacy↔EOF accounts. ## EOFv1.1 We only list the changes compared to EOFv1 here. ### Creation 1. `CREATE`/`CREATE2` instructions are disallowed in EOF accounts 2. EOF contracts can be created only via creation transactions For 2) we have two options: 1) Initcode is legacy bytecode, i.e. it operates as today. 2) Initcode is a "special EOF" context, because we change `CALLDATA*` to return what `CODECOPY` would ### Introspection 1. `EXT*` and `CODE*` instructions are disallowed in EOF accounts 2. When `EXT*` instructions in legacy accounts target EOF - `EXTCODECOPY` to copy nil - `EXTCODESIZE`/`EXTCODEHASH` to operate a) as currently; b) as if the account had `EF00` as its code 3. `GAS` instruction is disallowed in EOF accounts 4. The gas argument of `CALL*` is removed and always all the remaining gas is passed ## EOFv2 As described in [EOFv2 Design Space]( https://notes.ethereum.org/@ipsilon/eof2-design-space) (subject to improvements). Some questions we discussed but are not included in the doc: 1. Should there be a way to *insert code into the state* without creation, i.e. an EOF container is inserted at an address, and that address can be cloned with proper initialisation. 2. Do we want to support data contracts? 3. Do we want to support the "Solidity immutables" concept, or force people to use storage instead?