Merge branch 'master' of github.com:ethereum/EIPs

.github/workflows/auto-review-bot.yml

@@ -25,6 +25,7 @@ jobs:
       - name: Auto Review Bot
         id: auto-review-bot
         uses: ethereum/eip-review-bot@3e9905fcb72cf81ae9ed732df429c28b17e155b1
+        continue-on-error: true
         with:
           token: ${{ secrets.TOKEN }}
           config: config/eip-editors.yml

.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-1.md

@@ -213,7 +213,7 @@ Which renders to:
 Permitted Execution Client Specifications URLs must anchor to a specific commit, and so must match this regular expression:
 
 ```regex
-^(https://github.com/ethereum/execution-specs/blob/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$
+^(https://github.com/ethereum/execution-specs/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$
 ```
 
 ### Consensus Layer Specifications
@@ -231,7 +231,7 @@ Which renders to:
 Permitted Consensus Layer Specifications URLs must anchor to a specific commit, and so must match this regular expression:
 
 ```regex
-^https://github.com/ethereum/consensus-specs/blob/[0-9a-f]{40}/.*$
+^https://github.com/ethereum/consensus-specs/(blob|commit)/[0-9a-f]{40}/.*$
 ```
 
 ### Networking Specifications
@@ -249,7 +249,81 @@ Which renders as:
 Permitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression:
 
 ```regex
-^https://github.com/ethereum/devp2p/blob/[0-9a-f]{40}/.*$
+^https://github.com/ethereum/devp2p/(blob|commit)/[0-9a-f]{40}/.*$
+```
+
+### World Wide Web Consortium (W3C)
+
+Links to a W3C "Recommendation" status specification may be included using normal markdown syntax. For example, the following link would be allowed:
+
+```markdown
+[Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/)
+```
+
+Which renders as:
+
+[Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/)
+
+Permitted W3C recommendation URLs MUST anchor to a specification in the technical reports namespace with a date, and so MUST match this regular expression:
+
+```regex
+^https://www\.w3\.org/TR/[0-9][0-9][0-9][0-9]/.*$
+```
+
+### Web Hypertext Application Technology Working Group (WHATWG)
+
+Links to WHATWG specifications may be included using normal markdown syntax, such as:
+
+```markdown
+[HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/)
+```
+
+Which renders as:
+
+[HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/)
+
+Permitted WHATWG specification URLs must anchor to a specification defined in the `spec` subdomain (idea specifications are not allowed) and to a commit snapshot, and so must match this regular expression:
+
+```regex
+^https:\/\/[a-z]*\.spec\.whatwg\.org/commit-snapshots/[0-9a-f]{40}/$
+```
+
+Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard.
+
+### Internet Engineering Task Force (IETF)
+
+Links to an IETF Request For Comment (RFC) specification may be included using normal markdown syntax, such as:
+
+```markdown
+[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)
+```
+
+Which renders as:
+
+[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)
+
+Permitted IETF specification URLs MUST anchor to a specification with an assigned RFC number (meaning cannot reference internet drafts), and so MUST match this regular expression:
+
+```regex
+^https:\/\/www.rfc-editor.org\/rfc\/.*$
+```
+
+### Bitcoin Improvement Proposal
+
+Links to Bitcoin Improvement Proposals may be included using normal markdown syntax, such as:
+
+```markdown
+[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki)
+```
+
+Which renders to:
+
+[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki)
+
+Permitted Bitcoin Improvement Proposal URLs must anchor to a specific commit, and so must match this regular expression:
+
+```regex
+^(https://github.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\.mediawiki)$
 ```
 
 ### Digital Object Identifier System

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).