Rename *CALL2

c.f. ipsilon/eof#64 and ipsilon/eof#68

EIPS/eip-7069.md

@@ -1,7 +1,7 @@
 ---
 eip: 7069
 title: Revamped CALL instructions
-description: Introduce CALL2, DELEGATECALL2 and STATICCALL2 with simplified semantics
+description: Introduce EXTCALL, EXTDELEGATECALL and EXTSTATICCALL with simplified semantics
 author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast), Danno Ferrin (@shemnon), Andrei Maiboroda (@gumb0), Charles Cooper (@charles-cooper)
 discussions-to: https://ethereum-magicians.org/t/eip-revamped-call-instructions/14432
 status: Draft
@@ -13,7 +13,7 @@ requires: 150, 211, 214, 2929
 
 ## Abstract
 
-Introduce three new call instructions, `CALL2`, `DELEGATECALL2` and `STATICCALL2`, with simplified semantics. Introduce another instruction, `RETURNDATALOAD` for loading a word from return data into stack. The existing call instructions remain unchanged.
+Introduce three new call instructions, `EXTCALL`, `EXTDELEGATECALL` and `EXTSTATICCALL`, with simplified semantics. Introduce another instruction, `RETURNDATALOAD` for loading a word from return data into stack. The existing call instructions remain unchanged.
 
 The new instructions do not allow specifying a gas limit, but rather rely on the "63/64th rule" ([EIP-150](./eip-150.md)) to limit gas. An important improvement is the rules around the "stipend" are simplified, and callers do not need to perform special calculation whether the value is sent or not. 
 
@@ -50,12 +50,12 @@ Lastly, the introduction of the `RETURNDATA*` instructions ([EIP-211](./eip-211.
 
 We introduce four new instructions:
 
-- `CALL2` (`0xf8`) with arguments `(target_address, input_offset, input_size, value)` 
-- `DELEGATECALL2` (`0xf9`) with arguments `(target_address, input_offset, input_size)`
-- `STATICCALL2` (`0xfb`) with arguments `(target_address, input_offset, input_size)`
+- `EXTCALL` (`0xf8`) with arguments `(target_address, input_offset, input_size, value)` 
+- `EXTDELEGATECALL` (`0xf9`) with arguments `(target_address, input_offset, input_size)`
+- `EXTSTATICCALL` (`0xfb`) with arguments `(target_address, input_offset, input_size)`
 - `RETURNDATALOAD` (`0xf7`) with argument `offset`
 
-Execution semantics of `*CALL2`:
+Execution semantics of `EXT*CALL`:
 
 1. Charge `WARM_STORAGE_READ_COST` (100) gas.
 2. Pop required arguments from stack, fail with error on stack underflow.
@@ -135,12 +135,12 @@ The order of parameters has been changed to move the `value` field to be the las
 
 ### Opcode encoding
 
-Instead of introducing three new `*CALL2` opcodes we have discussed a version with an immediate configuration byte (flags). There are two main disadvantages to this:
+Instead of introducing three new `EXT*CALL` opcodes we have discussed a version with an immediate configuration byte (flags). There are two main disadvantages to this:
 
 1. Some combination of flags may not be useful/be invalid, and this increases the testing/implementation surface.
-2. The instruction could take variable number of stack items (i.e. `value` for `CALL2`) would be a brand new concept no other instruction has.
+2. The instruction could take variable number of stack items (i.e. `value` for `EXTCALL`) would be a brand new concept no other instruction has.
 
-It is also useful to have these as new opcodes instead of modifying the exiting CALL series inside of EOF. This creates an "escape hatch" in case gas observability needs to be restored to EOF contracts. This is done by adding the GAS and original CALL series opcodes to the valid EOF opcode list.
+It is also useful to have these as new opcodes instead of modifying the existing CALL series inside of EOF. This creates an "escape hatch" in case gas observability needs to be restored to EOF contracts. This is done by adding the GAS and original CALL series opcodes to the valid EOF opcode list.
 
 ### `CALLCODE`