Merge pull request #5 from ethereum/master

Merge origin master into branch

.codespell-whitelist

@@ -5,3 +5,6 @@ readded
 crate
 developper
 ist
+iam
+espace
+acn

EIPS/eip-107.md

@@ -95,7 +95,7 @@ Rationale
 The design for that proposal was chosen for its simplicity and security. A previous idea was to use an oauth-like protocol in order for the user to accept or deny a transaction request. It would have required deeper code change in the node and some geth contributors argues that such change did not fit into geth code base as it would have required dapp aware code.
 The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guarantess by browsers' cross domain policies.
 
-The use of iframe/ window was required to have both security and user friendliness. The invisble iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653).
+The use of iframe/ window was required to have both security and user friendliness. The invisible iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653).
 
 
 Implementations

EIPS/eip-1559.md

@@ -45,28 +45,36 @@ The transition to this gas price system will occur in two phases, in the first p
 <!--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)).-->
 **Parameters**
 * `INITIAL_FORK_BLKNUM`: TBD
-* `BASEFEE_MAX_CHANGE_DENOMINATOR`: 8
-* `TARGET_GAS_USED`: 10,000,000
-* `MAX_GAS_EIP1559`: 16,000,000
-* `EIP1559_DECAY_RANGE`: `MAX_GAS_EIP1559 / 20` == `800,000`
-* `FINAL_FORK_BLKNUM`:  `INITIAL_FORK_BLKNUM + EIP1559_DECAY_RANGE`
-* `EIP1559_GAS_INCREMENT_AMOUNT`: `(MAX_GAS_EIP1559 / 2) / EIP1559_DECAY_RANGE` == `10`
+* `MIGRATION_DURATION_IN_BLOCKS`: 800,000
+* `FINAL_FORK_BLKNUM`: `INITIAL_FORK_BLKNUM + MIGRATION_DURATION_IN_BLOCKS`
+* `EIP1559_INITIAL_GAS_TARGET`: `BLOCK_GAS_TARGET / 2`
+* `LEGACY_INITIAL_GAS_LIMIT`: `BLOCK_GAS_TARGET - EIP1559_GAS_TARGET`
+* `EIP1559_GAS_TARGET`:
+  ```
+  if CURRENT_BLKNUM >= FINAL_FORK_BLOKNUM then
+    BLOCK_GAS_TARGET
+  elif CURRNT_BLKNUM < INITIAL_FORK_BLKNUM then
+    0
+  else
+    EIP1559_INITIAL_GAS_TARGET + LEGACY_INITIAL_GAS_LIMIT * (CURRENT_BLKNUM - INITIAL_FORK_BLKNUM) / MIGRATION_DURATION_IN_BLOCKS
+  ```
+* `LEGACY_GAS_LIMIT`: `BLOCK_GAS_TARGET - EIP1559_GAS_TARGET`
+* `EIP1559_GAS_LIMIT`: `EIP1559_GAS_TARGET * 2`
+* `BASEFEE_MAX_CHANGE_DENOMINATOR`: `8`
 * `INITIAL_BASEFEE` : 1,000,000,000 wei (1 gwei)
-* `PER_TX_GASLIMIT`: 8,000,000
 
 
 **Proposal**
 For all blocks where `block.number >= INITIAL_FORK_BLKNUM`:
 
 For the gas limit:
 
-* `MAX_GAS_EIP1559` acts as the hard in-protocol gas limit, instead of the gas limit calculated using the previously existing formulas
-* The `GASLIMIT` field in the block header is the gas limit for the EIP1559 gas pool, and over the transition period this value increases until it reaches `MAX_GAS_EIP1559` at `FINAL_FORK_BLKNUM`
-* The gas limit for the legacy gas pool is `MAX_GAS_EIP1559 - GASLIMIT`, as `GASLIMIT` increases towards `MAX_GAS_EIP1559` gas is moved from the legacy pool into the EIP1559 pool until all of the gas is in the EIP1559 pool
-* At `block.number == INITIAL_FORK_BLKNUM`, let `GASLIMIT = (MAX_GAS_EIP1559 / 2)` so that the gas maximum is split evenly between the legacy and EIP1559 gas pools
-* As `block.number` increases towards `FINAL_FORK_BLKNUM`, at every block we shift `EIP1559_GAS_INCREMENT_AMOUNT` from the legacy pool into the EIP1559 gas pool
-* At `block.number >= FINAL_FORK_BLKNUM` the entire `MAX_GAS_EIP1559` is assigned to the EIP1559 gas pool and the legacy pool is empty
-* We enforce a maximum gas usage on individual transactions: `PER_TX_GASLIMIT`
+* The field in the block header previously referred to as `GASLIMIT` will now be referred to colloquially as `GAS_TARGET`.  Its value will still be controlled by miners in the same way as previously.  It represents the total gas available to the legacy gas pool as well as the target gas of the EIP1559 gas pool.
+* `EIP1559_GAS_LIMIT` is the space available for EIP1559 transactions (EIP1559 gas pool) and it is a function of `BLOCK_GAS_TARGET` and blocks since `INITIAL_FORK_BLKNUM`.  It becomes equal to `BLOCK_GAS_TARGET * 2` for blocks >= `FINAL_FORK_BLKNUM`
+* The gas limit for the legacy gas pool is `BLOCK_GAS_TARGET - EIP1559_GAS_TARGET`.  As `EIP1559_GAS_TARGET` increases towards `BLOCK_GAS_TARGET`, gas is moved from the legacy pool into the EIP1559 pool until all of the gas is in the EIP1559 pool
+* At `block.number == INITIAL_FORK_BLKNUM`, let `EIP1559_GAS_LIMIT = (GASLIMIT / 2)` so that the gas maximum is split evenly between the legacy and EIP1559 gas pools
+* As `block.number` increases towards `FINAL_FORK_BLKNUM`, at every block we shift `1/MIGRATION_DURATION_IN_BLOCKS` gas from the legacy pool into the EIP1559 gas pool (effectively doubling it as it moves, since the EIP1559 gas target is half of the limit)
+* At `block.number >= FINAL_FORK_BLKNUM` the entire `BLOCK_GAS_TARGET` is assigned to the EIP1559 gas pool and the legacy pool is 0
 
 For the gas price:
 

EIPS/eip-1581.md

@@ -10,7 +10,7 @@ created: 2018-11-13
 ---
 
 ## Simple Summary
-This EIP describes a derivation path structure for [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) wallets to be used for non-wallet keypairs.
+This EIP describes a derivation path structure for [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) wallets to be used for non-wallet key pairs.
 
 ## Abstract
 BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets.

EIPS/eip-1613.md

@@ -86,7 +86,7 @@ Glossary of terms used in the processes below:
 
 * `RelayHub` - the RelayHub singleton contract, used by everyone.
 * `Recipient` - a contract implementing `RelayRecipient`, accepting relayed transactions from the RelayHub contract and paying for the incoming transactions.
-* `Sender` - an external address with a valid keypair but no ETH to pay for gas.
+* `Sender` - an external address with a valid key pair but no ETH to pay for gas.
 * `Relay` - a node holding ETH in an external address, listed in RelayHub and relaying transactions from Senders to RelayHub for a fee.
 
 ![Sequence Diagram](https://bit.ly/2WZqM23)

EIPS/eip-1930.md

@@ -88,7 +88,7 @@ This is an issue for contracts that require external call to only fails if they
 
 But this is also true for simple use case, like checking if a contract implement an interface via EIP-165. Indeed as specified by such EIP, the ```supporstInterface``` method is bounded to use 30,000 gas so that it is theorically possible to ensure that the throw is not a result of a lack of gas. Unfortunately due to how the different CALL opcodes behave contracts can't simply rely on the gas value specified. They have to ensure by other means that there is enough gas for the call.
 
-Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interepreting wrongly that the callee is not implementing the interface in question. 
+Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interpreting wrongly that the callee is not implementing the interface in question. 
 
 While such requirement can be enforced by checking the gas left according to EIP-150 and the precise gas required before the call (see solution presented in that [bug report](https://web.solidified.io/contract/5b4769b1e6c0d80014f3ea4e/bug/5c83d86ac2dd6600116381f9) or after the call (see the native meta transaction implementation [here](https://github.com/pixowl/thesandbox-contracts/blob/623f4d4ca10644dcee145bcbd9296579a1543d3d/src/Sand/erc20/ERC20MetaTxExtension.sol#L176), it would be much better if the EVM allowed us to strictly specify how much gas is to be given to the CALL so contract implementations do not need to follow [EIP-150](https://eips.ethereum.org/EIPS/eip-150) behavior and the current gas pricing so closely.
 

EIPS/eip-2315.md

@@ -74,101 +74,128 @@ These changes do not affect the semantics of existing EVM code.
 
 This should jump into a subroutine, back out and stop.
 
-Bytecode: `0x6004b300b2b7`
-
+Bytecode: `0x60045e005c5d` (`PUSH1 0x04, JUMPSUB, STOP, BEGINSUB, RETURNSUB`)
 
 |  Pc   |      Op     | Cost |   Stack   |   RStack  |
 |-------|-------------|------|-----------|-----------|
 |    0  |      PUSH1  |    3 |        [] |        [] |
-|    2  |    JUMPSUB  |    5 |       [4] |        [] |
-|    5  |  RETURNSUB  |    2 |        [] |      [ 2] |
+|    2  |    JUMPSUB  |   10 |       [4] |        [] |
+|    5  |  RETURNSUB  |    5 |        [] |      [ 2] |
 |    3  |       STOP  |    0 |        [] |        [] |
 
+Output: 0x
+Consumed gas: `18`
+
 ### Two levels of subroutines
 
 This should execute fine, going into one two depths of subroutines
-Bytecode: `0x6800000000000000000cb300b26011b3b7b2b7`
+
+Bytecode: `0x6800000000000000000c5e005c60115e5d5c5d` (`PUSH9 0x00000000000000000c, JUMPSUB, STOP, BEGINSUB, PUSH1 0x11, JUMPSUB, RETURNSUB, BEGINSUB, RETURNSUB`)
 
 |  Pc   |      Op     | Cost |   Stack   |   RStack  |
 |-------|-------------|------|-----------|-----------|
 |    0  |      PUSH9  |    3 |        [] |        [] |
-|   10  |    JUMPSUB  |    5 |      [12] |        [] |
+|   10  |    JUMPSUB  |   10 |      [12] |        [] |
 |   13  |      PUSH1  |    3 |        [] |      [10] |
-|   15  |    JUMPSUB  |    5 |      [17] |      [10] |
-|   18  |  RETURNSUB  |    2 |        [] |   [10,15] |
-|   16  |  RETURNSUB  |    2 |        [] |      [10] |
+|   15  |    JUMPSUB  |   10 |      [17] |      [10] |
+|   18  |  RETURNSUB  |    5 |        [] |   [10,15] |
+|   16  |  RETURNSUB  |    5 |        [] |      [10] |
 |   11  |       STOP  |    0 |        [] |        [] |
 
+Consumed gas: `36`
 
 ### Failure 1: invalid jump
 
-This should fail, since the given `location` is outside of the code-range. The code is the same as previous example,
-except that the pushed `location` is `0x01000000000000000c` instead of `0x0c`.
+This should fail, since the given location is outside of the code-range. The code is the same as previous example, 
+except that the pushed location is `0x01000000000000000c` instead of `0x0c`.
 
-Bytecode: `0x6801000000000000000cb300b26011b3b7b2b7	`
+Bytecode: `0x6801000000000000000c5e005c60115e5d5c5d` (`PUSH9 0x01000000000000000c, JUMPSUB, STOP, BEGINSUB, PUSH1 0x11, JUMPSUB, RETURNSUB, BEGINSUB, RETURNSUB`)
 
 |  Pc   |      Op     | Cost |   Stack   |   RStack  |
 |-------|-------------|------|-----------|-----------|
 |    0  |      PUSH9  |    3 |        [] |        [] |
-|   10  |    JUMPSUB  |    5 |[18446744073709551628] |        [] |
+|   10  |    JUMPSUB  |   10 |[18446744073709551628] |        [] |
 
 ```
-Error: at pc=10, op=JUMPSUB: evm: invalid jump destination
+Error: at pc=10, op=JUMPSUB: invalid jump destination
 ```
 
 ### Failure 2: shallow `return stack`
 
-This should fail at first opcode, due to shallow `return stack`
-
-Bytecode: `0xb75858` (`RETURNSUB`, `PC`, `PC`)
+This should fail at first opcode, due to shallow `return_stack`
 
+Bytecode: `0x5d5858` (`RETURNSUB, PC, PC`)
 
 |  Pc   |      Op     | Cost |   Stack   |   RStack  |
 |-------|-------------|------|-----------|-----------|
-|    0  |  RETURNSUB  |    2 |        [] |        [] |
+|    0  |  RETURNSUB  |    5 |        [] |        [] |
 
 ```
-Error: at pc=0, op=RETURNSUB: evm: invalid retsub
+Error: at pc=0, op=RETURNSUB: invalid retsub
 ```
 
 ### Subroutine at end of code
 
 In this example. the JUMPSUB is on the last byte of code. When the subroutine returns, it should hit the 'virtual stop' _after_ the bytecode, and not exit with error
 
-Bytecode: `0x600556b2b75b6003b3`
+Bytecode: `0x6005565c5d5b60035e` (`PUSH1 0x05, JUMP, BEGINSUB, RETURNSUB, JUMPDEST, PUSH1 0x03, JUMPSUB`)
 
 |  Pc   |      Op     | Cost |   Stack   |   RStack  |
 |-------|-------------|------|-----------|-----------|
 |    0  |      PUSH1  |    3 |        [] |        [] |
 |    2  |       JUMP  |    8 |       [5] |        [] |
 |    5  |   JUMPDEST  |    1 |        [] |        [] |
 |    6  |      PUSH1  |    3 |        [] |        [] |
-|    8  |    JUMPSUB  |    5 |       [3] |        [] |
-|    3  |   BEGINSUB  |    1 |        [] |      [ 8] |
-|    4  |  RETURNSUB  |    2 |        [] |      [ 8] |
+|    8  |    JUMPSUB  |   10 |       [3] |        [] |
+|    4  |  RETURNSUB  |    5 |        [] |      [ 8] |
 |    9  |       STOP  |    0 |        [] |        [] |
 
-Consumed gas: `26`
+Consumed gas: `30`
+
+### Error on "walk-into-subroutine"
+
+In this example, the code 'walks' into a subroutine, which is not allowed, and causes an error
+
+Bytecode: `0x5c5d00` (`BEGINSUB, RETURNSUB, STOP`)
+
+
+|  Pc   |      Op     | Cost |   Stack   |   RStack  |
+|-------|-------------|------|-----------|-----------|
+|    0  |   BEGINSUB  |    2 |        [] |        [] |
+
+```
+Error: at pc=0, op=BEGINSUB: invalid subroutine entry
+```
+
+**Note 5**: The content of the error message, (`invalid subroutine entry`) is implementation-specific.
 
 ## Implementations
 
-Three clients have implemented the previous version of proposal:
+Three clients have implemented this (or an earlier version of) this proposal:
 
 - [geth](https://github.com/ethereum/go-ethereum/pull/20619) .
 - [besu](https://github.com/hyperledger/besu/pull/717), and
 - [openethereum](https://github.com/openethereum/openethereum/pull/11629).
 
-The changes for the current version are trivial.
 
 ### Costs and Codes
 
-We suggest that the cost of `JUMPSUB` be _low_, and `RETURNSUB` be _verylow_.
- Measurement will tell.  We suggest the following opcodes:
+We suggest that the cost of 
+
+- `BEGINSUB` be _base_ (`2`)
+  - Although formally specified, the cost of `BEGINSUB` does not matter in practice, since `BEGINSUB` never executes without error. 
+- `JUMPSUB` be _high_ (`10`)
+  - This is the same as `JUMPI`, and `2` more than `JUMP`.
+- `RETURNSUB` be _low_ (`5`).
+
+Benchmarking might be needed to tell if the costs are well-balanced. 
+
+We suggest the following opcodes:
 
 ```
-0xb2 BEGINSUB
-0xb3 JUMPSUB
-0xb7 RETURNSUB
+0x5c BEGINSUB
+0x5d RETURNSUB
+0x5e JUMPSUB
 ```
 
 ## Security Considerations

EIPS/eip-2333.md

@@ -68,7 +68,7 @@ Every key generated via the key derivation process derives a child key via a set
 
 ##### Outputs
 
-* `lamport_SK`, an array of 255 32-octet stings
+* `lamport_SK`, an array of 255 32-octet strings
 
 ##### Definitions