Merge branch 'master' into add-xinbenlv

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

@@ -1,5 +1,7 @@
 on:
   pull_request_target:
+    branches:
+      - master
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}

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

@@ -5,10 +5,6 @@ on:
     types:
       - completed
 
-concurrency:
-  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: true
-
 name: Auto Review Bot
 jobs:
   auto-review-bot:
@@ -24,32 +20,15 @@ jobs:
 
       - name: Save PR Number
         id: save-pr-number
-        run: echo "::set-output name=pr::$(cat pr-number.txt)"
-
-      - name: Checkout
-        uses: actions/checkout@2541b1294d2704b0964813337f33b291d3f8596b
-        with:
-          repository: ethereum/EIPs # Default, but best to be explicit here
-          ref: master
-
-      - name: Setup Node.js Environment
-        uses: actions/setup-node@2fddd8803e2f5c9604345a0b591c3020ee971a93
-        with:
-          node-version: 16
+        run: echo "pr=$(cat pr-number.txt)" >> $GITHUB_OUTPUT
 
       - name: Auto Review Bot
         id: auto-review-bot
-        uses: ethereum/EIP-Bot@b81356bd8302a99e2d2bcf2bb5d2d983a12f7b8d
+        uses: Pandapip1/eip-review-bot@dist
         with:
-          GITHUB-TOKEN: ${{ secrets.TOKEN }}
-          PR_NUMBER: ${{ steps.save-pr-number.outputs.pr }}
-          CORE_EDITORS: '@lightclient,@axic,@gcolvin,@SamWilsn,@Pandapip1,@xinbenlv'
-          ERC_EDITORS: '@axic,@SamWilsn,@Pandapip1,@xinbenlv'
-          NETWORKING_EDITORS: '@lightclient,@axic,@SamWilsn'
-          INTERFACE_EDITORS: '@lightclient,@axic,@SamWilsn,@Pandapip1'
-          META_EDITORS: '@lightclient,@axic,@gcolvin,@SamWilsn,@Pandapip1,@xinbenlv'
-          INFORMATIONAL_EDITORS: '@lightclient,@axic,@gcolvin,@SamWilsn,@Pandapip1,@xinbenlv'
-          MAINTAINERS: '@alita-moore,@mryalamanchi'
+          token: ${{ secrets.TOKEN }}
+          config: config/eip-editors.yml
+          pr_number: ${{ steps.save-pr-number.outputs.pr }}
 
       - name: Enable Auto-Merge
         uses: reitermarkus/automerge@a25ea0de41019ad13380d22e01db8f5638f1bcdc

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

@@ -1,14 +1,6 @@
 on:
   pull_request_target:
-    types:
-      - opened
-      - reopened
-      - synchronize
-      - ready_for_review
   pull_request_review:
-    types:
-      - submitted
-      - dismissed
   workflow_dispatch:
     inputs:
       pr_number:

.github/workflows/ci.yml

@@ -38,32 +38,45 @@ jobs:
 
   htmlproofer:
     name: HTMLProofer
-    runs-on: ubuntu-latest
-    
+    runs-on: ubuntu-20.04
+
     steps:
       - name: Checkout EIP Repository
         uses: actions/checkout@2541b1294d2704b0964813337f33b291d3f8596b
 
-      - name: Install OpenSSL
-        run: sudo apt-get update && sudo apt-get install -y libcurl4-openssl-dev
-
       - name: Install Ruby
         uses: ruby/setup-ruby@08245253a76fa4d1e459b7809579c62bd9eb718a
         with:
           ruby-version: 2.6.0
           bundler-cache: true
-        
+
       - name: Build Website
         run: |
           bundle exec jekyll doctor
           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
-      
+
       - name: DNS Validator
         run: bundle exec github-pages health-check
 
+  link-check:
+    name: Link Check
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout EIP Repository
+        uses: actions/checkout@2541b1294d2704b0964813337f33b291d3f8596b
+
+      - name: Link Checker
+        uses: gaurav-nelson/github-action-markdown-link-check@0a51127e9955b855a9bbfa1ff5577f1d1338c9a5
+        with:
+          config-file: config/mlc_config.json
+          use-quiet-mode: no
+          use-verbose-mode: yes
+          check-modified-files-only: yes
+
   codespell:
     name: CodeSpell
     runs-on: ubuntu-latest
@@ -99,7 +112,7 @@ jobs:
       - name: Checkout EIP Repository
         uses: actions/checkout@2541b1294d2704b0964813337f33b291d3f8596b
 
-      - uses: ethereum/eipw-action@d57d2afb71253fc7447d8a7a28d60f9dead2290b
+      - uses: ethereum/eipw-action@451d4e314183dd83401171908ca784e047122d70
         id: eipw
         with:
           token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/post-ci.yml

@@ -23,14 +23,15 @@ jobs:
       - name: Save PR Data
         id: save-pr-data
         run: |
-          echo "::set-output name=pr_number::$(cat pr_number)"
-          echo "::set-output name=pr_sha::$(cat pr_sha)"
-          echo "::set-output name=merge_sha::$(cat merge_sha)"
+          echo "pr_number=$(cat pr_number)" >> $GITHUB_OUTPUT
+          echo "pr_sha=$(cat pr_sha)" >> $GITHUB_OUTPUT
+          echo "merge_sha=$(cat merge_sha)" >> $GITHUB_OUTPUT
 
       - name: Add Comment
         uses: marocchino/sticky-pull-request-comment@39c5b5dc7717447d0cba270cd115037d32d28443
         if: ${{ github.event.workflow_run.conclusion == 'failure' }}
         with:
+          number: ${{ steps.save-pr-data.outputs.pr_number }}
           recreate: true
           message: |
             The commit ${{ steps.save-pr-data.outputs.pr_sha }} (as a parent of ${{ steps.save-pr-data.outputs.merge_sha }}) contains errors.
@@ -41,8 +42,9 @@ jobs:
         if: ${{ github.event.workflow_run.conclusion == 'failure' }}
         with:
           labels: w-ci
-          number: ${{ steps.save-pr-data.outputs.pr_number }}'
+          number: ${{ steps.save-pr-data.outputs.pr_number }}
           repo: ${{ github.repository }}
+          github_token: ${{ github.token }}
 
       - name: Remove Waiting Label
         uses: actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0
@@ -51,3 +53,4 @@ jobs:
           labels: w-ci
           number: ${{ steps.save-pr-data.outputs.pr_number }}
           repo: ${{ github.repository }}
+          github_token: ${{ github.token }}

.github/workflows/stale.yml

@@ -24,13 +24,12 @@ jobs:
         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
-        exempt-issue-labels: discussions-to, e-consensus
+        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.
         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
-        exempt-pr-labels: e-review, e-consensus
         exempt-pr-milestones: "Manual Merge Queue"
         stale-pr-label: w-stale

.gitignore

@@ -7,6 +7,7 @@ vendor
 # Editor files
 .gitpod.yml
 .DS_Store
+/.idea
 
 # Secrets
 .vercel

404.html

@@ -18,7 +18,6 @@
 
 <div class="container">
   <h1>404</h1>
-
   <p><strong>Page not found :(</strong></p>
   <p>The requested page could not be found.</p>
 </div>

EIPS/eip-1.md

@@ -100,7 +100,7 @@ Each EIP should have the following parts:
 - Preamble - RFC 822 style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details.
 - Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
 - Motivation *(optional)* - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident.
-- 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 (cpp-ethereum, go-ethereum, parity, ethereumJ, ethereumjs-lib, [and others](https://ethereum.org/en/developers/docs/nodes-and-clients).
+- 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 (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).
 - Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should discuss important objections or concerns raised during discussion around the EIP.
 - Backwards Compatibility *(optional)* - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backwards incompatibilities, but this section must be included if backward incompatibilities exist.
 - Test Cases *(optional)* - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs, or included in `../assets/eip-###/<filename>`. This section may be omitted for non-Core proposals.
@@ -374,7 +374,7 @@ The `description` field in the preamble:
 
 ### EIP numbers
 
-When referring to an EIP by number, it should be written in the hyphenated form `EIP-X` where `X` is the EIP's assigned number.
+When referring to an EIP with a `category` of `ERC`, it must be written in the hyphenated form `ERC-X` where `X` is that EIP's assigned number. When referring to EIPs with any other `category`, it must be written in the hyphenated form `EIP-X` where `X` is that EIP's assigned number.
 
 ### RFC 2119 and RFC 8174
 

EIPS/eip-1153.md

@@ -70,6 +70,10 @@ Another option to solve the problem of inter-frame communication is repricing th
 
 Another approach is to keep the refund counter for transient storage separate from the refund counter for other storage uses, and remove the refund cap for transient storage. However, that approach is more complex to implement and understand. For example, the 20% refund cap must be applied to the gas used _after_ subtracting the uncapped gas refund. Otherwise, the refund amount available subject to the 20% refund cap could be increased by executing transient storage writes. Thus it is preferable to have a separate mechanism that does not interact with the refund counter. Future hard forks can remove the complex refund behavior meant to support the transient storage use case, encouraging migration to contracts that are more efficient for the Ethereum clients to execute.
 
+There is a known objection to the word-addressed storage-like interface of the `TSTORE` and `TLOAD` opcodes since transient storage is more akin to memory than storage in lifecycle. A byte-addressed memory-like interface is another option. The storage-like word-addressed interface is preferred due to the usefulness of mappings in combination with the transaction-scoped memory region. Often times, you will need to keep transient state with arbitrary keys, such as in the [EIP-20](./eip-20.md) temporary approval use case which uses a mapping of `(owner, spender)` to `allowance`. Mappings are difficult to implement using linear memory, and linear memory must also have dynamic gas costs. It is also more complicated to handle reverts with a linear memory. It is possible to have a memory-like interface while the underlying implementation uses a map to allow for storage in arbitrary offsets, but this would result in a third memory-storage hybrid interface that would require new code paths in compilers.
+
+Some think that a unique transaction identifier may obviate the need for transient storage as described in this EIP. This is a misconception: a transaction identifier used in combination with regular storage has all the same issues that motivate this EIP. The two features are orthogonal.  
+
 Relative cons of this transient storage EIP:
 
 - Does not address transient usages of storage in existing contracts
@@ -242,6 +246,8 @@ However, if you only spend 1M gas allocating memory in each context, and make ca
 
 Smart contract developers should understand the lifetime of transient storage variables before use. Because transient storage is automatically cleared at the end of the transaction, smart contract developers may be tempted to avoid clearing slots as part of a call in order to save gas. However, this could prevent further interactions with the contract in the same transaction (e.g. in the case of re-entrancy locks) or cause other bugs, so smart contract developers should be careful to _only_ leave transient storage slots with nonzero values when those slots are intended to be used by future calls within the same transaction. Otherwise, these opcodes behave exactly the same as `SSTORE` and `SLOAD`, so all the usual security considerations apply especially in regard to reentrancy risk.
 
+Smart contract developers may also be tempted to use transient storage as an alternative to in-memory mappings. They should be aware that transient storage is not discarded when a call returns or reverts, as is memory, and should prefer memory for these use cases so as not to create unexpected behavior on reentrancy in the same transaction. The necessarily high cost of transient storage over memory should already discourage this usage pattern. Most usages of in-memory mappings can be better implemented with key-sorted lists of entries, and in-memory mappings are rarely required in smart contracts (i.e. the author knows of no known use cases in production).
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-1328.md

@@ -33,11 +33,14 @@ WalletConnect request URI with the following parameters:
 Required parameters are dependent on the WalletConnect protocol version:
 
 For WalletConnect v1.0 protocol (`version`=`1`) the parameters are:
+
 - `key` - symmetric key used for encryption
 - `bridge` - url of the bridge server for relaying messages
 
 For WalletConnect v2.0 protocol (`version`=`2`) the parameters are:
+
 - `symKey` - symmetric key used for encrypting messages over relay
+- `methods` - jsonrpc methods supported for pairing topic
 - `relay-protocol` - transport protocol for relaying messages
 - `relay-data` - (optional) transport data for relaying messages
 
@@ -49,7 +52,7 @@ For WalletConnect v2.0 protocol (`version`=`2`) the parameters are:
 wc:8a5e5bdc-a0e4-4702-ba63-8f1a5655744f@1?bridge=https%3A%2F%2Fbridge.walletconnect.org&key=41791102999c339c844880b23950704cc43aa840f3739e365323cda4dfa89e7a
 
 # 2.0
-wc:c9e6d30fb34afe70a15c14e9337ba8e4d5a35dd695c39b94884b0ee60c69d168@2?relay-protocol=waku&symKey=7ff3e362f825ab868e20e767fe580d0311181632707e7c878cbeca0238d45b8b
+wc:7f6e504bfad60b485450578e05678ed3e8e8c4751d3c6160be17160d63ec90f9@2?relay-protocol=irn&symKey=587d5484ce2a2a6ee3ba1962fdd7e8588e06200c46823bd18fbd67def96ad303&methods=[wc_sessionPropose],[wc_authRequest,wc_authBatchRequest]"
 ```
 
 ## Rationale

EIPS/eip-1459.md

@@ -3,12 +3,12 @@ eip: 1459
 title: Node Discovery via DNS
 description: Scheme for authenticated updateable Ethereum node lists via DNS.
 author: Felix Lange (@fjl), Péter Szilágyi (@karalabe)
+discussions-to: https://github.com/ethereum/devp2p/issues/50
+status: Draft
 type: Standards Track
 category: Networking
-status: Review
 created: 2018-09-26
 requires: 778
-discussions-to: https://github.com/ethereum/devp2p/issues/50
 ---
 
 ## Abstract
@@ -90,15 +90,13 @@ packets. This limits the number of hashes that can be placed into an
 
 Example in zone file format:
 
-```text
-; name                        ttl     class type  content
-@                             60      IN    TXT   enrtree-root:v1 e=JWXYDBPXYWG6FX3GMDIBFA6CJ4 l=C7HRFPF3BLGF3YR4DY5KX3SMBE seq=1 sig=o908WmNp7LibOfPsr4btQwatZJ5URBr2ZAuxvK4UWHlsB9sUOTJQaGAlLPVAhM__XJesCHxLISo94z5Z2a463gA
-C7HRFPF3BLGF3YR4DY5KX3SMBE    86900   IN    TXT   enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2@morenodes.example.org
-JWXYDBPXYWG6FX3GMDIBFA6CJ4    86900   IN    TXT   enrtree-branch:2XS2367YHAXJFGLZHVAWLQD4ZY,H4FHT4B454P6UXFD7JCYQ5PWDY,MHTDO6TMUBRIA2XWG5LUDACK24
-2XS2367YHAXJFGLZHVAWLQD4ZY    86900   IN    TXT   enr:-HW4QOFzoVLaFJnNhbgMoDXPnOvcdVuj7pDpqRvh6BRDO68aVi5ZcjB3vzQRZH2IcLBGHzo8uUN3snqmgTiE56CH3AMBgmlkgnY0iXNlY3AyNTZrMaECC2_24YYkYHEgdzxlSNKQEnHhuNAbNlMlWJxrJxbAFvA
-H4FHT4B454P6UXFD7JCYQ5PWDY    86900   IN    TXT   enr:-HW4QAggRauloj2SDLtIHN1XBkvhFZ1vtf1raYQp9TBW2RD5EEawDzbtSmlXUfnaHcvwOizhVYLtr7e6vw7NAf6mTuoCgmlkgnY0iXNlY3AyNTZrMaECjrXI8TLNXU0f8cthpAMxEshUyQlK-AM0PW2wfrnacNI
-MHTDO6TMUBRIA2XWG5LUDACK24    86900   IN    TXT   enr:-HW4QLAYqmrwllBEnzWWs7I5Ev2IAs7x_dZlbYdRdMUx5EyKHDXp7AV5CkuPGUPdvbv1_Ms1CPfhcGCvSElSosZmyoqAgmlkgnY0iXNlY3AyNTZrMaECriawHKWdDRk2xeZkrOXBQ0dfMFLHY4eENZwdufn1S1o
-```
+    ; name                        ttl     class type  content
+    @                             60      IN    TXT   enrtree-root:v1 e=JWXYDBPXYWG6FX3GMDIBFA6CJ4 l=C7HRFPF3BLGF3YR4DY5KX3SMBE seq=1 sig=o908WmNp7LibOfPsr4btQwatZJ5URBr2ZAuxvK4UWHlsB9sUOTJQaGAlLPVAhM__XJesCHxLISo94z5Z2a463gA
+    C7HRFPF3BLGF3YR4DY5KX3SMBE    86900   IN    TXT   enrtree://AM5FCQLWIZX2QFPNJAP7VUERCCRNGRHWZG3YYHIUV7BVDQ5FDPRT2@morenodes.example.org
+    JWXYDBPXYWG6FX3GMDIBFA6CJ4    86900   IN    TXT   enrtree-branch:2XS2367YHAXJFGLZHVAWLQD4ZY,H4FHT4B454P6UXFD7JCYQ5PWDY,MHTDO6TMUBRIA2XWG5LUDACK24
+    2XS2367YHAXJFGLZHVAWLQD4ZY    86900   IN    TXT   enr:-HW4QOFzoVLaFJnNhbgMoDXPnOvcdVuj7pDpqRvh6BRDO68aVi5ZcjB3vzQRZH2IcLBGHzo8uUN3snqmgTiE56CH3AMBgmlkgnY0iXNlY3AyNTZrMaECC2_24YYkYHEgdzxlSNKQEnHhuNAbNlMlWJxrJxbAFvA
+    H4FHT4B454P6UXFD7JCYQ5PWDY    86900   IN    TXT   enr:-HW4QAggRauloj2SDLtIHN1XBkvhFZ1vtf1raYQp9TBW2RD5EEawDzbtSmlXUfnaHcvwOizhVYLtr7e6vw7NAf6mTuoCgmlkgnY0iXNlY3AyNTZrMaECjrXI8TLNXU0f8cthpAMxEshUyQlK-AM0PW2wfrnacNI
+    MHTDO6TMUBRIA2XWG5LUDACK24    86900   IN    TXT   enr:-HW4QLAYqmrwllBEnzWWs7I5Ev2IAs7x_dZlbYdRdMUx5EyKHDXp7AV5CkuPGUPdvbv1_Ms1CPfhcGCvSElSosZmyoqAgmlkgnY0iXNlY3AyNTZrMaECriawHKWdDRk2xeZkrOXBQ0dfMFLHY4eENZwdufn1S1o
 
 ### Client Protocol
 
@@ -163,6 +161,12 @@ enable client implementations to sync these trees independently. A client
 wanting to get as many nodes as possible will sync the link tree first and add
 all linked names to the sync horizon.
 
+## Security Considerations
+
+Discovery via DNS is less secure than via DHT, because it relies on a trusted
+party to publish the records regularly. The actor could easily eclipse
+bootstrapping nodes by only publishing node records that it controls.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).

EIPS/eip-1822.md

@@ -306,7 +306,7 @@ contract LibraryLock is LibraryLockDataLayout {
     }
 }
 
-contact ERC20DataLayout is LibraryLockDataLayout {
+contract ERC20DataLayout is LibraryLockDataLayout {
   uint256 public totalSupply;
   mapping(address=>uint256) public tokens;
 }