Merge branch 'master' into ERC721Lockable

.github/workflows/ci.yml

@@ -45,9 +45,9 @@ jobs:
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
 
       - name: Install Ruby
-        uses: ruby/setup-ruby@08245253a76fa4d1e459b7809579c62bd9eb718a
+        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf
         with:
-          ruby-version: 2.6.0
+          ruby-version: 3.1.4 # 3.2 fails, see https://github.com/github/pages-gem/issues/879
           bundler-cache: true
 
       - name: Build Website
@@ -56,8 +56,7 @@ jobs:
           bundle exec jekyll build
 
       - name: HTML Proofer
-        run: bundle exec htmlproofer ./_site --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --disable-external
-
+        run: bundle exec htmlproofer --allow-missing-href --disable-external --assume-extension '.html' --log-level=:info --cache='{"timeframe":{"external":"6w"}}' --checks 'Links,Images,Scripts,OpenGraph' --no-check-sri --ignore-empty-alt --no-enforce_https ./_site
       - name: DNS Validator
         run: bundle exec github-pages health-check
 
@@ -112,7 +111,7 @@ jobs:
       - name: Checkout EIP Repository
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
 
-      - uses: ethereum/eipw-action@70379db401cbb3197454d8e02589af42d4ac5d21
+      - uses: ethereum/eipw-action@af0856c89aa1a245cf0da9ae904eafbbddb94ecf
         id: eipw
         with:
           token: ${{ secrets.GITHUB_TOKEN }}

EIPS/eip-2535.md

@@ -12,7 +12,7 @@ created: 2020-02-22
 
 ## Abstract
 
-<img align="right" src="../assets/eip-2535/diamond.svg" width="230" height="230">
+<img align="right" src="../assets/eip-2535/diamond.svg" width="230" height="230" alt="Diamonds contract structure">
 
 This proposal standardizes diamonds, which are modular smart contract systems that can be upgraded/extended after deployment, and have virtually no size limit. More technically, a **diamond** is a contract with external functions that are supplied by contracts called **facets**. Facets are separate, independent contracts that can share internal functions, libraries, and state variables.
 
@@ -38,7 +38,7 @@ The diagram below shows two diamonds using the same two facets.
 - `FacetB` is used by `Diamond1`
 - `FacetB` is used by `Diamond2`
 
-<img src="../assets/eip-2535/facetreuse.png">
+<img src="../assets/eip-2535/facetreuse.png" alt="Facet reuse">
 
 ### Upgradeable Diamond vs. Centralized Private Database
 
@@ -140,7 +140,7 @@ fallback() external payable {
 
 This diagram shows the structure of a diamond:
 
-<img src="../assets/eip-2535/DiamondDiagram.png">
+<img src="../assets/eip-2535/DiamondDiagram.png" alt="Mapping facets and storage">
 
 ### Storage
 
@@ -160,7 +160,7 @@ In this diagram
 - `FacetA` and `FacetB` share access to `DataAB`.
 - The diamond's own code, `FacetA` and `FacetB` share access to `DataABD`.
 
-<img src="../assets/eip-2535/diamondstorage1.png">
+<img src="../assets/eip-2535/diamondstorage1.png" alt="Mapping code, data, and facets">
 
 ### Solidity Libraries as Facets
 

EIPS/eip-2537.md

@@ -1,7 +1,7 @@
 ---
 eip: 2537
 title: Precompile for BLS12-381 curve operations
-author: Alex Vlasov (@shamatar), Kelly Olson (@ineffectualproperty)
+author: Alex Vlasov (@shamatar), Kelly Olson (@ineffectualproperty), Alex Stokes (@ralexstokes)
 discussions-to: https://ethereum-magicians.org/t/eip2537-bls12-precompile-discussion-thread/4187
 status: Stagnant
 type: Standards Track
@@ -35,15 +35,15 @@ Multiexponentiation operation is included to efficiently aggregate public keys o
 
 |Precompile   |Address   |
 |---|---|
-|BLS12_G1ADD          | 0x0a  |
-|BLS12_G1MUL          | 0x0b  |
-|BLS12_G1MULTIEXP     | 0x0c  |
-|BLS12_G2ADD          | 0x0d  |
-|BLS12_G2MUL          | 0x0e  |
-|BLS12_G2MULTIEXP     | 0x0f  |
-|BLS12_PAIRING        | 0x10  |
-|BLS12_MAP_FP_TO_G1   | 0x11  |
-|BLS12_MAP_FP2_TO_G2  | 0x12  |
+|BLS12_G1ADD          | 0x0c  |
+|BLS12_G1MUL          | 0x0d  |
+|BLS12_G1MULTIEXP     | 0x0e  |
+|BLS12_G2ADD          | 0x0f  |
+|BLS12_G2MUL          | 0x10  |
+|BLS12_G2MULTIEXP     | 0x11  |
+|BLS12_PAIRING        | 0x12  |
+|BLS12_MAP_FP_TO_G1   | 0x13  |
+|BLS12_MAP_FP2_TO_G2  | 0x14  |
 
 ## Motivation
 
@@ -122,6 +122,7 @@ Certain operations have variable length input, such as multiexponentiations (tak
 G1 addition call expects `256` bytes as an input that is interpreted as byte concatenation of two G1 points (`128` bytes each). Output is an encoding of addition operation result - single G1 point (`128` bytes).
 
 Error cases:
+
 - Either of points being not on the curve must result in error
 - Field elements encoding rules apply (obviously)
 - Input has invalid length
@@ -131,6 +132,7 @@ Error cases:
 G1 multiplication call expects `160` bytes as an input that is interpreted as byte concatenation of encoding of G1 point (`128` bytes) and encoding of a scalar value (`32` bytes). Output is an encoding of multiplication operation result - single G1 point (`128` bytes).
 
 Error cases:
+
 - Point being not on the curve must result in error
 - Field elements encoding rules apply (obviously)
 - Input has invalid length
@@ -140,6 +142,7 @@ Error cases:
 G1 multiexponentiation call expects `160*k` bytes as an input that is interpreted as byte concatenation of `k` slices each of them being a byte concatenation of encoding of G1 point (`128` bytes) and encoding of a scalar value (`32` bytes). Output is an encoding of multiexponentiation operation result - single G1 point (`128` bytes).
 
 Error cases:
+
 - Any of G1 points being not on the curve must result in error
 - Field elements encoding rules apply (obviously)
 - Input has invalid length
@@ -150,6 +153,7 @@ Error cases:
 G2 addition call expects `512` bytes as an input that is interpreted as byte concatenation of two G2 points (`256` bytes each). Output is an encoding of addition operation result - single G2 point (`256` bytes).
 
 Error cases:
+
 - Either of points being not on the curve must result in error
 - Field elements encoding rules apply (obviously)
 - Input has invalid length
@@ -159,6 +163,7 @@ Error cases:
 G2 multiplication call expects `288` bytes as an input that is interpreted as byte concatenation of encoding of G2 point (`256` bytes) and encoding of a scalar value (`32` bytes). Output is an encoding of multiplication operation result - single G2 point (`256` bytes).
 
 Error cases:
+
 - Point being not on the curve must result in error
 - Field elements encoding rules apply (obviously)
 - Input has invalid length
@@ -168,6 +173,7 @@ Error cases:
 G2 multiexponentiation call expects `288*k` bytes as an input that is interpreted as byte concatenation of `k` slices each of them being a byte concatenation of encoding of G2 point (`256` bytes) and encoding of a scalar value (`32` bytes). Output is an encoding of multiexponentiation operation result - single G2 point (`256` bytes).
 
 Error cases:
+
 - Any of G2 points being not on the curve must result in error
 - Field elements encoding rules apply (obviously)
 - Input has invalid length
@@ -176,12 +182,14 @@ Error cases:
 #### ABI for pairing
 
 Pairing call expects `384*k` bytes as an inputs that is interpreted as byte concatenation of `k` slices. Each slice has the following structure:
+
 - `128` bytes of G1 point encoding
 - `256` bytes of G2 point encoding
 
 Output is a `32` bytes where first `31` bytes are equal to `0x00` and the last byte is `0x01` if pairing result is equal to multiplicative identity in a pairing target field and `0x00` otherwise.
 
 Error cases:
+
 - Any of G1 or G2 points being not on the curve must result in error
 - Any of G1 or G2 points are not in the correct subgroup
 - Field elements encoding rules apply (obviously)
@@ -193,6 +201,7 @@ Error cases:
 Field-to-curve call expects `64` bytes an an input that is interpreted as a an element of the base field. Output of this call is `128` bytes and is G1 point following respective encoding rules.
 
 Error cases:
+
 - Input has invalid length
 - Input is not a valid field element
 
@@ -201,6 +210,7 @@ Error cases:
 Field-to-curve call expects `128` bytes an an input that is interpreted as a an element of the quadratic extension field. Output of this call is `256` bytes and is G2 point following respective encoding rules.
 
 Error cases:
+
 - Input has invalid length
 - Input is not a valid field element
 
@@ -267,6 +277,7 @@ For multiexponentiation and pairing functions gas cost depends on the input leng
 Define a constant `LEN_PER_PAIR` that is equal to `160` for G1 operation and to `288` for G2 operation. Define a function `discount(k)` following the rules in the corresponding section, where `k` is number of pairs.
 
 The following pseudofunction reflects how gas should be calculated:
+
 ```
   k = floor(len(input) / LEN_PER_PAIR);
   if k == 0 {
@@ -286,6 +297,7 @@ We use floor division to get number of pairs. If length of the input is not divi
 Define a constant `LEN_PER_PAIR = 384`;
 
 The following pseudofunction reflects how gas should be calculated:
+
 ```
   k = floor(len(input) / LEN_PER_PAIR);
 
@@ -317,13 +329,13 @@ Subgroup check **is mandatory** during the pairing call. Implementations *should
 
 ### Field to curve mapping
 
-Algorithms and set of parameters for SWU mapping method is provided by a separate [document](../assets/eip-2537/field_to_curve.md) 
+Algorithms and set of parameters for SWU mapping method is provided by a separate [document](../assets/eip-2537/field_to_curve.md)
 
 ## Test Cases
 
-Due to the large test parameters space we first provide properties that various operations must satisfy. We use additive notation for point operations, capital letters (`P`, `Q`) for points, small letters (`a`, `b`) for scalars. Generator for G1 is labeled as `G`, generator for G2 is labeled as `H`, otherwise we assume random point on a curve in a correct subgroup. `0` means either scalar zero or point of infinity. `1` means either scalar one or multiplicative identity. `group_order` is a main subgroup order. `e(P, Q)` means pairing operation where `P` is in G1, `Q` is in G2. 
+Due to the large test parameters space we first provide properties that various operations must satisfy. We use additive notation for point operations, capital letters (`P`, `Q`) for points, small letters (`a`, `b`) for scalars. Generator for G1 is labeled as `G`, generator for G2 is labeled as `H`, otherwise we assume random point on a curve in a correct subgroup. `0` means either scalar zero or point of infinity. `1` means either scalar one or multiplicative identity. `group_order` is a main subgroup order. `e(P, Q)` means pairing operation where `P` is in G1, `Q` is in G2.
 
-Requeired properties for basic ops (add/multiply):
+Required properties for basic ops (add/multiply):
 
 - Commutativity: `P + Q = Q + P`
 - Additive negation: `P + (-P) = 0`
@@ -334,7 +346,8 @@ Requeired properties for basic ops (add/multiply):
 - Multiplication by the unnormalized scalar `(scalar + group_order) * P = scalar * P`
 
 Required properties for pairing operation:
-- Degeneracy `e(P, 0*Q) = e(0*P, Q) = 1` 
+
+- Degeneracy `e(P, 0*Q) = e(0*P, Q) = 1`
 - Bilinearity `e(a*P, b*Q) = e(a*b*P, Q) = e(P, a*b*Q)` (internal test, not visible through ABI)
 
 ### Benchmarking test cases
@@ -344,6 +357,7 @@ A set of test vectors for quick benchmarking on new implementations is located i
 ## Reference Implementation
 
 There are two fully spec compatible implementations on the day of writing:
+
 - One in Rust language that is based on the EIP1962 code and integrated with OpenEthereum for this library
 - One implemented specifically for Geth as a part of the current codebase
 
@@ -354,4 +368,5 @@ Strictly following the spec will eliminate security implications or consensus im
 Important topic is a "constant time" property for performed operations. We explicitly state that this precompile **IS NOT REQUIRED** to perform all the operations using constant time algorithms.
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-4337.md

@@ -408,7 +408,7 @@ Clients maintain two mappings with a value for staked entities:
 
 If an entity doesn't use storage at all, or only reference storage associated with the "sender" (see [Storage associated with an address](#storage-associated-with-an-address)), then it is considered "OK", without using the rules below.
 
-When the client learns of a new staked entity, it sets `opsSeen[paymaster] = 0` and `opsIncluded[paymaster] = 0` .
+When the client learns of a new staked entity, it sets `opsSeen[entity] = 0` and `opsIncluded[entity] = 0` .
 
 The client sets `opsSeen[entity] +=1` each time it adds an op with that `entity` to the `UserOperationPool`, and the client sets `opsIncluded[entity] += 1` each time an op that was in the `UserOperationPool` is included on-chain.
 

EIPS/eip-4844.md

@@ -43,7 +43,7 @@ Compared to full data sharding, this EIP has a reduced cap on the number of thes
 | `FIELD_ELEMENTS_PER_BLOB` | `4096` |
 | `BLS_MODULUS` | `52435875175126190479447740508185965837690552500527637822603658699938581184513` |
 | `BLOB_COMMITMENT_VERSION_KZG` | `Bytes1(0x01)` |
-| `POINT_EVALUATION_PRECOMPILE_ADDRESS` | `Bytes20(0x14)` |
+| `POINT_EVALUATION_PRECOMPILE_ADDRESS` | `Bytes20(0x0A)` |
 | `POINT_EVALUATION_PRECOMPILE_GAS` | `50000` |
 | `MAX_DATA_GAS_PER_BLOCK` | `786432` |
 | `TARGET_DATA_GAS_PER_BLOCK` | `393216` |

EIPS/eip-5564.md

@@ -97,11 +97,11 @@ A one byte integer (`schemeId`) is used to identify stealth address schemes. The
 
 - The algorithm for the `computeStealthKey` method.
 
-This specification additionally defines a singleton `ERC5564Messenger` contract that emits events to announce when something is sent to a stealth address. This MUST be a singleton contract, with one instance per chain. The contract is specified as follows:
+This specification additionally defines a singleton `ERC5564Announcer` contract that emits events to announce when something is sent to a stealth address. This MUST be a singleton contract, with one instance per chain. The contract is specified as follows:
 
 ```solidity
 /// @notice Interface for announcing when something is sent to a stealth address.
-contract IERC5564Messenger {
+contract IERC5564Announcer {
   /// @dev Emitted when sending something to a stealth address.
   /// @dev See the `announce` method for documentation on the parameters.
   event Announcement (
@@ -165,7 +165,7 @@ Stealth meta-addresses may be managed by the user and/or registered within a pub
 
 ### Initial Implementation of SECP256k1 with View Tags
 
-This EIP provides a foundation that is not tied to any specific cryptographic system through the `IERC5564Messenger` contract. In addition, it introduces the first implementation of a [stealth address scheme](../assets/eip-5564/scheme_ids.md) that utilizes the SECP256k1 elliptic curve and view tags. The SECP256k1 elliptic curve is defined with the equation $y^2 = x^3 + 7 \pmod{p}$, where $p = 2^{256} - 2^{32} - 977$.
+This EIP provides a foundation that is not tied to any specific cryptographic system through the `IERC5564Announcer` contract. In addition, it introduces the first implementation of a [stealth address scheme](../assets/eip-5564/scheme_ids.md) that utilizes the SECP256k1 elliptic curve and view tags. The SECP256k1 elliptic curve is defined with the equation $y^2 = x^3 + 7 \pmod{p}$, where $p = 2^{256} - 2^{32} - 977$.
 
 The following reference is divided into three sections:
 

EIPS/eip-7044.md

@@ -0,0 +1,63 @@
+---
+eip: 7044
+title: Perpetually Valid Signed Voluntary Exits
+description: Lock voluntary exit signature domain on capella for perpetual validity
+author: Lion (@dapplion)
+discussions-to: https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-voluntary-exits/14348
+status: Draft
+type: Standards Track
+category: Core
+created: 2023-05-18
+---
+
+## Abstract
+
+Lock validator voluntary exit signature domain on Capella for perpetual validity. Currently, signed voluntary exits are only valid for two upgrades.
+
+## Motivation
+
+Currently, signed voluntary exits are valid up-to only two upgrades for block inclusion due to the Beacon Chain state considering only the current and previous fork version. This limitation increases the complexity of some staking operations, specifically those in which the staking operator (holder of active key) is distinct from the owner of the funds (holder of the withdrawal credential). Because voluntary exits can only be signed by the active key, such a relationship requires the exchange of signed exits ahead of time for an unbounded number of forks.
+
+The limited validity of voluntary exits was originally motivated to isolate them in the event of a hard fork that results in two maintained chains. If fork A and B exist and a validator operates on both, if they send an exit, it will be replayable on both. However, this possibility is not sufficient to justify the UX degradation exposed above, as no funds are at risk and the staker can re-stake on one or both of the chains.
+
+## Specification
+
+### Consensus Layer
+
+Specification changes are built into the Consensus Specs Deneb upgrade.
+
+The specific makes one change to the state transition function:
+
+- Modify [`process_voluntary_exit`](https://github.com/ethereum/consensus-specs/blob/75971a8c218b1d76d605dd8b88a08d39c42de221/specs/deneb/beacon-chain.md#modified-process_voluntary_exit) to compute the signing domain and root fixed on `CAPELLA_FORK_VERSION`.
+
+Additionally, the `voluntary_exit` gossip conditions are implicitly modified to support this change.
+
+To make the change backwards compatible the signature domain is locked on the Capella fork
+
+### Execution Layer
+
+This specification does not require any changes to the Execution Layer.
+
+## Rationale
+
+Perpetually valid signed voluntary exits allow simpler staking operation designs. It also aligns the UX of such objects to `BLSToExecutionChanges` and deposits, such that downstream tooling does not need to be updated with fork version information.
+
+## Backwards Compatibility
+
+This change is backwards compatible to the Consensus Layer of Ethereum block processing logic.
+
+The expectation of future validity of exits is not forward compatible. Specifically, users who have already pre-signed exits utilizing the Deneb fork domain with an expectation of their validity should be aware that these pre-signed exits will no longer be recognized as valid. Consequently, users should adjust their approach moving forward. For continued validity across forks, including Deneb and subsequent forks, users should ensure that their exits are signed using the Capella fork domain.
+
+There are no forwards/backwards compatibility issues with the Execution Layer.
+
+## Test Cases
+
+Test cases are work-in-progress within the standard Consensus Layer tests.
+
+## Security Considerations
+
+The divergent signature domains across forked networks would previously have prevented the replay of VoluntaryExits after two hard forks. This specification change causes the replay protection to no longer exist. These potential replays could impact individual stakers on both sides of a fork, but does not put funds at risk and does not impact the security of the chain.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).