Merge branch 'master' into patch-3

.github/workflows/ci.yml

@@ -136,7 +136,7 @@ jobs:
       - name: Checkout EIP Repository
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
 
-      - uses: ethereum/eipw-action@b8de7ea9ad5cb842301e63898afb996c451c18cf
+      - uses: ethereum/eipw-action@be3fa642ec311d0b8e1fdb811e5c9b4ada3d3d93
         id: eipw
         with:
           token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/stale.yml

@@ -20,16 +20,16 @@ jobs:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
         ascending: true # Since we have so many issues, the stale bot finds it hard to keep track. This makes sure that at least the oldest are removed.
         # Issue config
-        stale-issue-message: There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
+        stale-issue-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity.
         close-issue-message: This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.
-        days-before-issue-stale: 7
-        days-before-issue-close: 49 # 49 + 7 weeks = 3 months
+        days-before-issue-stale: 183
+        days-before-issue-close: 190
         exempt-issue-labels: discussions-to
         stale-issue-label: w-stale
         # PR config
-        stale-pr-message: There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
+        stale-pr-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
         close-pr-message: This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.
-        days-before-pr-stale: 14
-        days-before-pr-close: 42 # 42 + 14 weeks = 3 months
+        days-before-pr-stale: 183
+        days-before-pr-close: 190
         exempt-pr-milestones: "Manual Merge Queue"
         stale-pr-label: w-stale

EIPS/eip-152.md

@@ -80,8 +80,8 @@ function callF() public view returns (bytes32[2] memory) {
   m[3] = hex"0000000000000000000000000000000000000000000000000000000000000000";
 
   bytes8[2] memory t;
-  t[0] = hex"03000000";
-  t[1] = hex"00000000";
+  t[0] = hex"0300000000000000";
+  t[1] = hex"0000000000000000";
 
   bool f = true;
 

EIPS/eip-2537.md

@@ -14,7 +14,7 @@ created: 2020-02-21
 
 Add functionality to efficiently perform operations over the BLS12-381 curve, including those for BLS signature verification.
 
-Along with the curve arithmetic, multiexponentiation operations are included to efficiently aggregate public keys or individual signer's signatures during BLS signature verification.
+Along with the curve arithmetic, multi-scalar-multiplication operations are included to efficiently aggregate public keys or individual signer's signatures during BLS signature verification.
 
 ## Motivation
 
@@ -123,7 +123,7 @@ Also referred to as the "zero point". For BLS12 curves, the point with coordinat
 
 #### Encoding of scalars for multiplication operation:
 
-A scalar for the multiplication operation is encoded as `32` bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer is **not** required to be less than or equal than main subgroup order `q`.
+A scalar for the multiplication operation is encoded as `32` bytes by performing BigEndian encoding of the corresponding (unsigned) integer. The corresponding integer is **not** required to be less than or equal to main subgroup order `q`.
 
 #### Behavior on empty inputs:
 
@@ -212,7 +212,7 @@ Pairing check call expects `384*k`  (`k` being a **positive** integer)  bytes as
 
 Each point is expected to be in the subgroup of order `q`.
 
-Output is `32` bytes where first `31` bytes are equal to `0x00` and the last byte is `0x01` if pairing result is equal to the multiplicative identity in a pairing target field and `0x00` otherwise.
+It checks the equation `e(P1, Q1) * e(P2, Q2) * ... * e(Pk, Qk) == 1` in the pairing target field where `e` is the pairing operation. Output is `32` bytes where first `31` bytes are equal to `0x00` and the last byte is either `0x00` (false) or `0x01` (true).
 
 Error cases:
 
@@ -273,7 +273,7 @@ Assuming a constant `30 MGas/second`, the following prices are suggested.
 
 #### G1/G2 MSM
 
-MSMs are expected to be performed by Pippenger's algorithm (we can also say that it **must** be performed by Pippenger's algorithm to have a speedup that results in a discount over naive implementation by multiplying each pair separately and adding the results). For this case there was a table prepared for discount in case of `k <= 128` points in the MSM with a discount cup `max_discount` for `k > 128`.
+MSMs are expected to be performed by Pippenger's algorithm (we can also say that it **must** be performed by Pippenger's algorithm to have a speedup that results in a discount over naive implementation by multiplying each pair separately and adding the results). For this case there was a table prepared for discount in case of `k <= 128` points in the MSM with a discount cap `max_discount` for `k > 128`.
 
 To avoid non-integer arithmetic, the call cost is calculated as `(k * multiplication_cost * discount) / multiplier` where `multiplier = 1000`, `k` is a number of (scalar, point) pairs for the call, `multiplication_cost` is a corresponding single multiplication call cost for G1/G2.
 

EIPS/eip-2935.md

@@ -2,7 +2,7 @@
 eip: 2935
 title: Serve historical block hashes from state
 description: Store and serve last 8192 block hashes as storage slots of a system contract to allow for stateless execution
-author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer)
+author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer), Sina Mahmoodi (@s1na)
 discussions-to: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565
 status: Review
 type: Standards Track
@@ -34,21 +34,42 @@ A side benefit of this approach could be that it allows building/validating proo
 
 This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length. Note that `HISTORY_SERVE_WINDOW` > `BLOCKHASH_SERVE_WINDOW` (which remains unchanged).
 
-At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), update the state directly in the following way:
+### Block processing
 
-```python
-def process_block_hash_history(block: Block, state: State):
-    if block.timestamp >= FORK_TIMESTAMP:
-        state.insert_slot(HISTORY_STORAGE_ADDRESS, (block.number-1) % HISTORY_SERVE_WINDOW , block.parent.hash)
-```
+At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), call to `HISTORY_STORAGE_ADDRESS` as `SYSTEM_ADDRESS` with the 32-byte input of `block.parent.hash`, a gas limit of `30_000_000`, and `0` value. This will trigger the `set()` routine of the history contract. This is a system operation following the same convention as [EIP-4788](./eip-4788.md) and therefore:
+
+* the call must execute to completion
+* the call does not count against the block's gas limit
+* the call does not follow the [EIP-1559](./eip-1559.md) burn semantics - no value should be transferred as part of the call
+* if no code exists at `HISTORY_STORAGE_ADDRESS`, the call must fail silently
 
-Alternatively clients can also choose to do a system update via a system call to the contract `set` mechanism defined in the following sections.
+Note: Alternatively clients can choose to directly write to the storage of the contract but EVM calling the contract remains preferred. Refer to the rationale for more info.
 
 Note that, it will take `HISTORY_SERVE_WINDOW` blocks after `FORK_TIMESTAMP` to completely fill up the ring buffer. The contract will only contain the parent hash of the fork block and no hashes prior to that.
 
-As mentioned earlier the `BLOCKHASH` opcode semantics remains the same as before. However the clients which want to leverage the history from state may do so making sure the query is within `BLOCKHASH_SERVE_WINDOW` and is available in the contract.
 
-### Contract Implementation
+### EVM Changes
+
+The `BLOCKHASH` opcode semantics remains the same as before.
+
+### Block hash history contract
+
+The history contract has two operations: `get` and `set`. The `set` operation is invoked only when the `caller` is equal to the `SYSTEM_ADDRESS` as per [EIP-4788](./eip-4788.md). Otherwise the `get` operation is performed.
+
+#### `get`
+
+It is used from the EVM for looking up block hashes.
+
+* Callers provide the block number they are querying in a big-endian encoding.
+* If calldata is bigger than 2^64-1, revert.
+* For any output outside the range of [block.number-`HISTORY_SERVE_WINDOW`, block.number-1] return 0.
+
+#### `set`
+
+* Caller provides `block.parent.hash` as calldata to the contract.
+* Set the storage value at `block.number-1 % HISTORY_SERVE_WINDOW` to be `calldata[0:32]`.
+
+#### Bytecode
 
 Exact evm assembly that can be used for the history contract:
 
@@ -136,10 +157,6 @@ stop
 Corresponding bytecode:
 `0x3373fffffffffffffffffffffffffffffffffffffffe1460575767ffffffffffffffff5f3511605357600143035f3511604b575f35612000014311604b57611fff5f3516545f5260205ff35b5f5f5260205ff35b5f5ffd5b5f35611fff60014303165500`
 
-#### Contract `get` and `set` mechanism
-
-The update mechanism is the same as [EIP-4788](./eip-4788.md). While executing the system contract is not future-proof, this update method remains the favored one until the verkle fork.
-
 #### Deployment
 
 A special synthetic address is generated by working backwards from the desired deployment transaction:
@@ -200,6 +217,23 @@ Second concern was how to best transition the BLOCKHASH resolution logic post fo
 
 We choose to go with the former. It simplifies the logic greatly. It will take roughly a day to bootstrap the contract. Given that this is a new way of accessing history and no contract depends on it, it is deemed a favorable tradeoff.
 
+### Inserting the parent block hash
+
+Clients have generally two options for inserting the parent block hash into state:
+
+1. Performing a system call to `HISTORY_STORAGE_ADDRESS` and letting that handle the storing in state.
+2. Avoid EVM processing and directly write to the state trie.
+
+The latter option is as follows:
+
+```python
+def process_block_hash_history(block: Block, state: State):
+    if block.timestamp >= FORK_TIMESTAMP:
+        state.insert_slot(HISTORY_STORAGE_ADDRESS, (block.number-1) % HISTORY_SERVE_WINDOW , block.parent.hash)
+```
+
+The first option is recommended until the Verkle fork, to stay consistent with [EIP-4788](./eip-4788.md) and to issues for misconfigured networks where this EIP is activated but history contract hasn't been deployed. The recommendation may be reconsidered at the Verkle fork if filtering the system contract code chunks is deemed too complex.
+
 ## Backwards Compatibility
 
 This EIP introduces backwards incompatible changes to the block validation rule set. But neither of these changes break anything related to current user activity and experience.