Update EIPs to follow the rules regarding EVM opcodes (as stated in EIP-1) (#2115)

* Update EIPs to follow the rules regarding EVM opcodes (as stated in EIP-1)

* One more case

EIPS/eip-1014.md

@@ -10,7 +10,7 @@ created: 2018-04-20
 
 ### Specification
 
-Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using `keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. 
+Adds a new opcode (`CREATE2`) at `0xf5`, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to `CREATE` (`0xf0`), except using `keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]` instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.
 
 The `CREATE2` has the same `gas` schema as `CREATE`, but also an extra `hashcost` of `GSHA3WORD * ceil(len(init_code) / 32)`, to account for the hashing that must be performed. The `hashcost` is deducted at the same time as memory-expansion gas and `CreateGas` is deducted: _before_ evaluation of the resulting address and the execution of `init_code`.
 
@@ -44,17 +44,17 @@ The `init_code` is the code that, when executed, produces the runtime bytecode t
 
 This EIP makes collisions possible. The behaviour at collisions is specified by [EIP 684](https://github.com/ethereum/EIPs/issues/684):
 
-> If a contract creation is attempted, due to either a creation transaction or the CREATE (or future CREATE2) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis.
+> If a contract creation is attempted, due to either a creation transaction or the `CREATE` (or future `CREATE2`) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. This applies retroactively starting from genesis.
 
 Specifically, if `nonce` or `code` is nonzero, then the create-operation fails. 
 
 With [EIP 161](https://eips.ethereum.org/EIPS/eip-161) 
 
-> Account creation transactions and the CREATE operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one
+> Account creation transactions and the `CREATE` operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one
 
 This means that if a contract is created in a transaction, the `nonce` is immediately non-zero, with the side-effect that a collision within the same transaction will always fail -- even if it's carried out from the `init_code` itself.
 
-It should also be noted that `SELFDESTRUCT` has no immediate effect on `nonce` or `code`, thus a contract cannot be destroyed and recreated within one transaction. 
+It should also be noted that `SELFDESTRUCT` (`0xff`) has no immediate effect on `nonce` or `code`, thus a contract cannot be destroyed and recreated within one transaction.
 
 ### Examples
 

EIPS/eip-1051.md

@@ -23,21 +23,21 @@ Two new flags are added to the EVM state: overflow (`ovf`) and signed overflow (
 
 The `ovf` flag is set in the following circumstances:
 
- - When an `ADD` opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.
+ - When an `ADD` (`0x01`) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.
- - When a `SUB` opcode, with both inputs treated as unsigned integers, produces an ideal output less than 0.
+ - When a `SUB` (`0x03`) opcode, with both inputs treated as unsigned integers, produces an ideal output less than 0.
- - When a 'MUL' opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.
+ - When a `MUL`(`0x02`) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1.
 
 The `sovf` flag is set whenever the `ovf` flag is set, and additionally in the following circumstances:
 
  - When an `ADD` opcode with both inputs having the same MSB results in the output having a different MSB (eg, `(+a) + (+b) = (-c)` or `(-a) + (-b) = (+c)`).
  - When a `SUB` opcode occurs and the result has the same MSB as the subtractand (second argument) (eg, `(+a) - (-b) = (-c)` or `(-a) - (+b) = (+c)`.
  - When a `MUL` opcode with both inputs being positive has a negative output.
- - When a 'MUL' opcode with both inputs being negative has a negative output.
+ - When a `MUL` opcode with both inputs being negative has a negative output.
- - When a 'MUL' opcode with one negative input and one positive input has a positive output.
+ - When a `MUL` opcode with one negative input and one positive input has a positive output.
 
-A new opcode, `OFV` is added, with number 0x0C. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `ovf` flag is set, and `0` otherwise. It then sets the `ovf` flag to false.
+A new opcode, `OFV` is added, with number `0x0c`. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `ovf` flag is set, and `0` otherwise. It then sets the `ovf` flag to false.
 
-A new opcode, `SOVF` is added, with number 0x0D. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `sovf` flag is set, and `0` otherwise. It then sets the `sovf` flag to false.
+A new opcode, `SOVF` is added, with number `0x0d`. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `sovf` flag is set, and `0` otherwise. It then sets the `sovf` flag to false.
 
 ## Rationale
 Any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. One option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. However, this limits the manner in which overflows can be handled.

EIPS/eip-1052.md

@@ -16,11 +16,11 @@ This EIP specifies a new opcode, which returns the keccak256 hash of a contract'
 ## Motivation
 Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
 
-Contracts can presently do this using the `EXTCODECOPY` opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, `EXTCODEHASH`, which returns the keccak256 hash of a contract's bytecode.
+Contracts can presently do this using the `EXTCODECOPY` (`0x3c`) opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, `EXTCODEHASH`, which returns the keccak256 hash of a contract's bytecode.
 
 ## Specification
 
-A new opcode, `EXTCODEHASH`, is introduced, with number 0x3F. The `EXTCODEHASH` 
+A new opcode, `EXTCODEHASH`, is introduced, with number `0x3f`. The `EXTCODEHASH` 
 takes one argument from the stack, zeros the first 96 bits 
 and pushes to the stack the keccak256 hash of the code of the account 
 at the address being the remaining 160 bits. 
@@ -43,8 +43,8 @@ The gas cost is the same as the gas cost for the `BALANCE` opcode because the
 execution of the `EXTCODEHASH` requires the same account lookup as in `BALANCE`.
 
 Only the 20 last bytes of the argument are significant (the first 12 bytes are 
-ignored) similarly to the semantics of the `BALANCE`, `EXTCODESIZE` and 
+ignored) similarly to the semantics of the `BALANCE` (`0x31`), `EXTCODESIZE` (`0x3b`) and 
-`EXTCODECOPY`.
+`EXTCODECOPY` (`0x3c`).
 
 The `EXTCODEHASH` distincts accounts without code and non-existing accounts.
 This is consistent with the way accounts are represented in the state trie.

EIPS/eip-1087.md

@@ -10,10 +10,10 @@ created: 2018-05-17
 ---
 
 ## Abstract
-This EIP proposes a change to how gas is charged for EVM SSTORE operations, in order to reduce excessive gas costs in situations where these are unwarranted, and to enable new use-cases for contract storage.
+This EIP proposes a change to how gas is charged for EVM `SSTORE` operations, in order to reduce excessive gas costs in situations where these are unwarranted, and to enable new use-cases for contract storage.
 
 ## Motivation
-Presently, SSTORE operations are charged as follows:
+Presently, `SSTORE` (`0x55`) operations are charged as follows:
 
  - 20,000 gas to set a slot from 0 to non-0
  - 5,000 gas for any other change
@@ -50,7 +50,7 @@ After these changes, transactions that make only a single change to a storage sl
 ## Rationale
 We believe the proposed mechanism represents the simplest way to reduce storage gas costs in situations where they do not reflect the actual costs borne by nodes. Several alternative designs were considered and dismissed:
 
- - Charging a flat 200 gas for SSTORE operations, and an additional 19800 / 4800 at the end of a transaction for new or modified values is simpler, and removes the need for a dirty map, but pushes a significant source of gas consumption out of the EVM stack and applies it at the end of the transaction, which is likely to complicate debugging and reduces contracts' ability to limit the gas consumption of callees, as well as introducing a new mechanism to the EVM.
+ - Charging a flat 200 gas for `SSTORE` operations, and an additional 19800 / 4800 at the end of a transaction for new or modified values is simpler, and removes the need for a dirty map, but pushes a significant source of gas consumption out of the EVM stack and applies it at the end of the transaction, which is likely to complicate debugging and reduces contracts' ability to limit the gas consumption of callees, as well as introducing a new mechanism to the EVM.
  - Keeping a separate refund counter for storage gas refunds would avoid the issue of refunds being limited to half the gas consumed (not necessary here), but would introduce additional complexity in tracking this value.
  - Refunding gas each time a storage slot is set back to its initial value would introduce a new mechanism (instant refunds) and complicate gas accounting for contracts calling other contracts; it would also permit the possibility of a contract call with negative execution cost.
 

EIPS/eip-1109.md

@@ -11,7 +11,7 @@ created: 2018-05-22
 
 ## Simple Summary
 
-This EIP creates a specific OPCODE named "PRECOMPILEDCALL" to call Precompiled contracts without the costs of a normal CALL.
+This EIP creates a specific opcode named `PRECOMPILEDCALL` to call Precompiled contracts without the costs of a normal `CALL`.
 
 ## Abstract
 
@@ -27,7 +27,7 @@ This makes no sense, and right now it's impossible to define a precompiled contr
 
 ## Specification
 
-If `block.number >= XXXXX`, define a new opcode named PRECOMPILEDCALL with code value 0xfb .
+If `block.number >= XXXXX`, define a new opcode named `PRECOMPILEDCALL` with code value `0xfb`.
 
 The gas cost of the OPCODE is 2 (Gbase) plus the Specific gas cost defined for each specific precompiled smart contract.
 
@@ -47,26 +47,26 @@ The return will be 1 in case of success call and 0 in any of the next cases:
 1.- mu_s[0] is an address of an undefined precompiled smart contract.
 2.- The precompiled smart contract fails (as defined on each smart contract). Invalid input parameters for example.
 
-Precompiled smart contracs, does not execute opcodes, so there is no need to pass a gas parameter as a normal CALL.  If the available gas is less that 2 plus the required gas required for the specific precompiled smart cotract, the context just STOPS executing with an "Out of Gas" error.
+Precompiled smart contracs, does not execute opcodes, so there is no need to pass a gas parameter as a normal `CALL` (`0xf1`).  If the available gas is less that 2 plus the required gas required for the specific precompiled smart cotract, the context just STOPS executing with an "Out of Gas" error.
 
 There is no stack check for this call.
 
-The normal CALLs to the precompiled smart contracts continue to work with the exact same behavior.
+The normal `CALL`s to the precompiled smart contracts continue to work with the exact same behavior.
 
-A PRECOMPILEDCALL to a regular address or regular smart contract, is considered a call to an "undefined smart contract", so the VM MUST not execute it and the opcode must return 0x0 .
+A `PRECOMPILEDCALL` to a regular address or regular smart contract, is considered a call to an "undefined smart contract", so the VM MUST not execute it and the opcode must return 0x0 .
 
 
 ## Rationale
 
-There was a first proposal for removing the gast consts for the CALL, but it looks that it's easier to implement and test a new opcode just for that.
+There was a first proposal for removing the gast consts for the `CALL`, but it looks that it's easier to implement and test a new opcode just for that.
 
-The code is just the next opcode available after the STATICCALL opcode.
+The code is just the next opcode available after the `STATICCALL` opcode.
 
 ## Backwards Compatibility
 
 This EIP is backwards compatible.  Smart contracts that call precompiled contracts using this new opcode will cost less from now on.
 
-Old contracts that call precompiled smart contracts with the CALL method, will continue working.
+Old contracts that call precompiled smart contracts with the `CALL` method, will continue working.
 
 ## Test Cases
 

EIPS/eip-1153.md

@@ -10,17 +10,17 @@ created: 2018-06-15
 ---
 
 ## Simple Summary
-Support for efficient transient storage in EVM. It is like regular storage (SLOAD/SSTORE), but with the lifetime limited to one Ethereum transaction.
+Support for efficient transient storage in EVM. It is like regular storage (`SLOAD`/`SSTORE`), but with the lifetime limited to one Ethereum transaction.
 Notable use case is efficient reentrancy lock.
 
 ## Abstract
 This proposal introduces transient storage, which behaves similar to storage,
-but the updates will only persist within one Ethereum transaction. Transient storage is accessible to smart contracts via new opcodes: TLOAD and TSTORE (“T” stands for Transient).
+but the updates will only persist within one Ethereum transaction. Transient storage is accessible to smart contracts via new opcodes: `TLOAD` and `TSTORE` (“T” stands for Transient).
 
 ## Motivation
-Running a transaction in Ethereum can generate multiple nested frames of execution, each created by CALL (or similar) instructions.
+Running a transaction in Ethereum can generate multiple nested frames of execution, each created by `CALL` (or similar) instructions.
 Contracts can be re-entered during the same transaction, in which case there are more than one frame belonging to one contract.
-Currently, these frames can communicate in two ways - via inputs/outputs passed via CALL instructions, and via storage updates.
+Currently, these frames can communicate in two ways - via inputs/outputs passed via `CALL` instructions, and via storage updates.
 If there is an intermediate frame belonging to another contract, communication via inputs/outputs is not secure. Notable example is a reentrancy lock which cannot rely on the intermediate frame to pass through the state of the lock.
 Communication via storage (`SSTORE`/`SLOAD`) is costly. Transient storage is a dedicated and gas efficient solution to the problem of inter frame communication.
 
@@ -35,11 +35,11 @@ Potential use cases unlocked by this EIP include:
 ## Specification
 Two new opcodes are added to EVM, `TLOAD` and `TSTORE`.
 
-They use the same arguments on stack as `SLOAD` and `SSTORE`.
+They use the same arguments on stack as `SLOAD` (`0x54`) and `SSTORE` (`0x55`).
 
 `TLOAD` pops one 32-byte word from the top of the stack, treats this value as the address, fetches 32-byte word from the transient storage at that address, and pops the value on top of the stack.
 
-`TSTORE` pops two 32-byte words from the top of the stack. The word on the top is the address, and the next is the value. TSTORE saves the value at the given address in the transient storage.
+`TSTORE` pops two 32-byte words from the top of the stack. The word on the top is the address, and the next is the value. `TSTORE` saves the value at the given address in the transient storage.
 
 Addressing is the same as `SLOAD` and `SSTORE`. i.e. each 32-byte address points to a unique 32-byte word.
 

EIPS/eip-1283.md

@@ -11,7 +11,7 @@ created: 2018-08-01
 
 ## Abstract
 
-This EIP proposes net gas metering changes for SSTORE opcode, enabling
+This EIP proposes net gas metering changes for `SSTORE` opcode, enabling
 new usages for contract storage, and reducing excessive gas costs
 where it doesn't match how most implementation works.
 
@@ -50,7 +50,7 @@ Definitions of terms are as below:
 * *Storage slot's new value*: This is the value of the storage after
   SSTORE operation happens.
 
-Replace SSTORE opcode gas cost calculation (including refunds) with
+Replace `SSTORE` opcode gas cost calculation (including refunds) with
 the following logic:
 
 * If *current value* equals *new value* (this is a no-op), 200 gas is
@@ -91,7 +91,7 @@ implementation details:
 
 ## Explanation
 
-The new gas cost scheme for SSTORE is divided into three different
+The new gas cost scheme for `SSTORE` is divided into three different
 types:
 
 * **No-op**: the virtual machine does not need to do anything. This is
@@ -109,11 +109,11 @@ We can see that the above three types cover all possible variations of
 **No-op** is a trivial operation. Below we only consider cases for
 **Fresh** and **Dirty**.
 
-All initial (not-**No-op**) SSTORE on a particular storage slot starts
+All initial (not-**No-op**) `SSTORE` on a particular storage slot starts
 with **Fresh**. After that, it will become **Dirty** if the value has
 been changed. When going from **Fresh** to **Dirty**, we charge the
 gas cost the same as current scheme. A **Dirty** storage slot can be
-reset back to **Fresh** via a SSTORE opcode. This will trigger a
+reset back to **Fresh** via a `SSTORE` opcode. This will trigger a
 refund.
 
 When a storage slot remains at **Dirty**, we charge 200 gas. In this
@@ -178,7 +178,7 @@ concept of "dirty maps", or an extra storage struct.
   refactoring on this. Nonetheless, no extra memory or processing cost
   is needed on runtime.
 
-Regarding SSTORE gas cost and refunds, see Appendix for proofs of
+Regarding `SSTORE` gas cost and refunds, see Appendix for proofs of
 properties that this EIP satisfies.
 
 * For *absolute gas used* (that is, actual *gas used* minus *refund*),

EIPS/eip-1285.md

@@ -1,6 +1,6 @@
 ---
 eip: 1285
-title: Increase Gcallstipend gas in the CALL OPCODE
+title: Increase Gcallstipend gas in the CALL opcode
 author: Ben Kaufman <ben@daostack.io>, Adam Levi <adam@daostack.io>
 discussions-to: https://ethereum-magicians.org/t/eip-1285-increase-gcallstipend-gas-in-the-call-opcode/941
 status: Draft
@@ -11,12 +11,12 @@ created: 2018-08-01
 
 ## Simple Summary
 <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
-Increase the ``Gcallstipend`` fee parameter in the ``CALL`` OPCODE from ``2,300`` to ``3,500`` gas units.
+Increase the ``Gcallstipend`` fee parameter in the ``CALL`` opcode from ``2,300`` to ``3,500`` gas units.
 
 ## Abstract
 <!--A short (~200 word) description of the technical issue being addressed.-->
-Currently, the ``CALL`` OPCODE forwards a stipend of ``2,300`` gas units for a non zero value ``CALL`` operations where a contract is called. This stipend is given to the contract to allow execution of its ``fallback`` function. The stipend given is intentionally small in order to prevent the called contract from spending the call gas or performing an attack (like re-entrancy).
+Currently, the ``CALL`` opcode forwards a stipend of ``2,300`` gas units for a non zero value ``CALL`` operations where a contract is called. This stipend is given to the contract to allow execution of its ``fallback`` function. The stipend given is intentionally small in order to prevent the called contract from spending the call gas or performing an attack (like re-entrancy).
-While the stipend is small it should still give the sufficient gas required for some cheap OPCODES like ``LOG``, but it's not enough for some more complex and modern logics to be implemented.
+While the stipend is small it should still give the sufficient gas required for some cheap opcodes like ``LOG``, but it's not enough for some more complex and modern logics to be implemented.
 This EIP proposes to increase the given stipend from ``2,300`` to ``3,500`` to increase the usability of  the ``fallback`` function.
 
 
@@ -30,7 +30,7 @@ By slightly increasing the gas units given in the stipend we allow proxy contrac
 
 ## Specification
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
-Increase the ``Gcallstipend`` fee parameter in the ``CALL`` OPCODE from ``2,300`` to ``3,500`` gas unit.
+Increase the ``Gcallstipend`` fee parameter in the ``CALL`` opcode from ``2,300`` to ``3,500`` gas unit.
 The actual change to the Ethereum clients would be to change the ``CallStipend`` they store as a constant.
 For an implementation example you can find a Geth client implementation linked [here](https://github.com/ben-kaufman/go-ethereum/tree/eip-1285). The actual change to the code can be found [here](https://github.com/ben-kaufman/go-ethereum/blob/eip-1285/params/protocol_params.go#L41).
 
@@ -40,7 +40,7 @@ The rational for increasing the ``Gcallstipend`` gas parameter by ``1,200`` gas
 
 ## Backwards Compatibility
 <!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
-This EIP requires a backwards incompatible change for the ``Gcallstipend`` gas parameter in the ``CALL`` OPCODE.
+This EIP requires a backwards incompatible change for the ``Gcallstipend`` gas parameter in the ``CALL`` opcode.
 
 
 ## Copyright