Update EIP-7480: match to EOF Megaspec

Merged by EIP-Bot.

EIPS/eip-7480.md

@@ -27,10 +27,10 @@ The `DATALOAD`, `DATASIZE`, `DATACOPY` instruction pattern follows the design of
 
 We introduce four new instructions on the same block number [EIP-3540](./eip-3540.md) is activated on:
 
-1 `DATALOAD` (0xe8)
-2.`DATALOADN` (0xe9)
-3.`DATASIZE` (0xea)
-4.`DATACOPY` (0xeb)
+1 `DATALOAD` (0xd0)
+2.`DATALOADN` (0xd1)
+3.`DATASIZE` (0xd2)
+4.`DATACOPY` (0xd3)
 
 If the code is legacy bytecode, all of these instructions result in an *exceptional halt*. (*Note: This means no change to behaviour.*)
 
@@ -62,7 +62,7 @@ If the code is valid EOF1, the following execution rules apply:
 
 1. Pops three values from the stack: `mem_offset`, `offset`, `size`.
 2. Performs memory expansion to `mem_offset + size` and deducts memory expansion cost.
-3. Deducts `3 * ((size + 31) // 32)` gas for copying.
+3. Deducts `3 + 3 * ((size + 31) // 32)` gas for copying.
 4. Reads `[offset:offset+size]` segment from the data section and writes it to memory starting at offset `mem_offset`.
 5. If `offset + size` is greater than data section size, 0 bytes will be copied for bytes after the end of the data section.
 
@@ -71,7 +71,7 @@ If the code is valid EOF1, the following execution rules apply:
 
 We extend code section validation rules (as defined in [EIP-3670](./eip-3670.md)).
 
-1. Code section is invalid in case an immediate argument `offset` of any `DATALOADN` is such that `offset + 32` is greater than data section size.
+1. Code section is invalid in case an immediate argument `offset` of any `DATALOADN` is such that `offset + 32` is greater than data section size, as indicated in the container header *before deployment*.
 2. `RJUMP`, `RJUMPI` and `RJUMPV` immediate argument value (jump destination relative offset) validation: code section is invalid in case offset points to one of two bytes directly following `DATALOADN` instruction.
 
 
@@ -83,6 +83,12 @@ Existing instructions for reading other kinds of data implicitly pad with zeroes
 
 It is benefitial to avoid exceptional failures, because compilers can employ optimizations like removing a code that copies data, but never accesses this copy afterwards, but such optimization is possible only if instruction never has other side effects like exceptional abort.
 
+### Lack of `EXTDATACOPY`
+
+`EXTCODECOPY` instruction is deprecated and rejected in EOF contracts and does not copy contract code when being called in legacy with an EOF contract as target. A replacement instruction `EXTDATACOPY` has been considered, but decided against in order to reduce the scope of changes.
+
+Data-only contracts which previously relied on `EXTCODECOPY` are thereby discouraged, but if there is a strong need, support for them can be easily brought back by introducing `EXTDATACOPY` in a future upgrade.
+
 ## Backwards Compatibility
 
 This change poses no risk to backwards compatibility, as it is introduced only for EOF1 contracts, for which deploying undefined instructions is not allowed, therefore there are no existing contracts using these instructions. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted).