Merge branch 'upstream'

.github/renovate.json

@@ -10,6 +10,7 @@
   "ignoreDeps": [
     "Pandapip1/jekyll-label-action",
     "ethereum/eipw-action",
-    "ethereum/eip-review-bot"
+    "ethereum/eip-review-bot",
+    "ethereum/EIP-Bot"
   ]
 }

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

@@ -2,6 +2,7 @@ on:
   schedule:
     # A job that runs every sunday at 00:00
     - cron:  '0 0 * * 0'
+  workflow_dispatch:
 
 name: Auto Stagnant Bot
 jobs:
@@ -17,7 +18,7 @@ jobs:
         with:
           node-version: '14'
       - name: auto-stagnant-bot
-        uses: ethereum/EIP-Bot@fe4c395bd8bd1f006c353f9b04e694da890ad69a # mark-eips-stale
+        uses: ethereum/EIP-Bot@b3ac0ba3600aea27157fc68d1e36c08cc5a6db77 # mark-eips-stale
         id: auto-stagnant-bot
         with:
           GITHUB-TOKEN: ${{ secrets.TOKEN }}

.github/workflows/ci.yml

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

EIPS/eip-1.md

@@ -24,7 +24,7 @@ There are three types of EIP:
 - A **Standards Track EIP** describes any change that affects most or all Ethereum implementations, such as—a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the [formal specification](https://github.com/ethereum/yellowpaper). Furthermore, Standards Track EIPs can be broken down into the following categories:
   - **Core**: improvements requiring a consensus fork (e.g. [EIP-5](./eip-5.md), [EIP-101](./eip-101.md)), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of [EIP-86](./eip-86.md)).
   - **Networking**: includes improvements around [devp2p](https://github.com/ethereum/devp2p/blob/readme-spec-links/rlpx.md) ([EIP-8](./eip-8.md)) and [Light Ethereum Subprotocol](https://ethereum.org/en/developers/docs/nodes-and-clients/#light-node), as well as proposed improvements to network protocol specifications of [whisper](https://github.com/ethereum/go-ethereum/issues/16013#issuecomment-364639309) and [swarm](https://github.com/ethereum/go-ethereum/pull/2959).
-  - **Interface**: includes improvements around client [API/RPC](https://github.com/ethereum/execution-apis#README) specifications and standards, and also certain language-level standards like method names ([EIP-6](./eip-6.md)) and [contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html). The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
+  - **Interface**: includes improvements around language-level standards like method names ([EIP-6](./eip-6.md)) and [contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html).
   - **ERC**: application-level standards and conventions, including contract standards such as token standards ([ERC-20](./eip-20.md)), name registries ([ERC-137](./eip-137.md)), URI schemes, library/package formats, and wallet formats.
 
 - A **Meta EIP** describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.
@@ -118,7 +118,7 @@ EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wik
 
 Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order.
 
-`eip`: *EIP number* (this is determined by the EIP editor)
+`eip`: *EIP number*
 
 `title`: *The EIP title is a few words, not a complete sentence*
 
@@ -451,7 +451,7 @@ If the EIP isn't ready, the editor will send it back to the author for revision,
 
 Once the EIP is ready for the repository, the EIP editor will:
 
-- Assign an EIP number (generally the PR number, but the decision is with the editors)
+- Assign an EIP number (generally incremental; editors can reassign if number sniping is suspected)
 - Merge the corresponding [pull request](https://github.com/ethereum/EIPs/pulls)
 - Send a message back to the EIP author with the next step.
 

EIPS/eip-1175.md

@@ -14,7 +14,7 @@ requires: 20
 ## Simple Summary
 Make wallets and shops created from certified contracts make erc20 tokens easy to use for commerce.
 
-![wallet](/assets/eip-1175/wallet.png)
+![wallet](../assets/eip-1175/wallet.png)
 
 ## Abstract
 The mutual trust between the wallet and the shop created by the authenticated contract allows you to pay for and purchase items at a simple process.
@@ -25,7 +25,7 @@ New standards with improvements have been released, but the majority of tokens c
 And if you only reuse the store interface, you can also trade using `payUnsafe (address _shop, uint256 _item)`.
 
 ## Specification
-![workflow](/assets/eip-1175/workflow.png)
+![workflow](../assets/eip-1175/workflow.png)
 ## WalletCenter
 ### Methods
 #### createWallet

EIPS/eip-1271.md

@@ -57,7 +57,7 @@ This function should be implemented by contracts which desire to sign messages (
 ## Rationale
 We believe the name of the proposed function to be appropriate considering that an *authorized* signers providing proper signatures for a given data would see their signature as "valid" by the signing contract. Hence, a signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart wallet. 
 
-Two arguments are provided for simplicity of separating the hash signed from the signature. A bytes32 hash is used instead of the unhashed message for simplicy, since contracts could expect a certain hashing function that is not standard, such as with [EIP-712](./eip-712.md). 
+Two arguments are provided for simplicity of separating the hash signed from the signature. A bytes32 hash is used instead of the unhashed message for simplicity, since contracts could expect a certain hashing function that is not standard, such as with [EIP-712](./eip-712.md). 
 
 `isValidSignature()` should not be able to modify states in order to prevent `GasToken` minting or similar attack vectors. Again, this is to simplify the implementation surface of the function for better standardization and to allow off-chain contract queries.
 

EIPS/eip-1438.md

@@ -25,7 +25,7 @@ While many projects are under development in an open source way, they are simply
 
 
 #### The following avatar store, badge system, and universal wallet are kind of examples about component dApp.
-![intro](/assets/eip-1438/intro.png)
+![intro](../assets/eip-1438/intro.png)
 
 ## Specification
 ### 1. Avatar
@@ -38,11 +38,11 @@ The avatar's information & assets are stored in the event log part of the block
 - Assets are SVG format. (compressed with gzip)
 - avatar information data is json (compressed with msgpack)
 
-![avatar](/assets/eip-1438/avatar.png)
+![avatar](../assets/eip-1438/avatar.png)
 ** The avatar assets from [Avataaars](https://github.com/fangpenlin/avataaars) developed by [Fang-Pen Lin](https://twitter.com/fangpenlin), the original avatar is designed by [Pablo Stanley](https://twitter.com/pablostanley).
 
 ### 2. Universal Wallet
-![wallet](/assets/eip-1438/wallet.png)
+![wallet](../assets/eip-1438/wallet.png)
 #### 2.1. ERC20 interface
 ``` js
 contract ERC20Interface {

EIPS/eip-1613.md

@@ -89,7 +89,7 @@ Glossary of terms used in the processes below:
 * `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](/assets/eip-1613/sequence.png)
+![Sequence Diagram](../assets/eip-1613/sequence.png)
 
 The process of registering/refreshing a `Relay`:
 

EIPS/eip-1820.md

@@ -339,7 +339,9 @@ The contract has the address above for every chain on which it is deployed.
 <details>
 <summary>Raw metadata of <code>./contracts/ERC1820Registry.sol</code></summary>
 <pre>
-<code>{
+
+```json
+{
         "compiler": {
           "version": "0.5.3+commit.10d17f24"
         },
@@ -655,7 +657,9 @@ The contract has the address above for every chain on which it is deployed.
           }
         },
         "version": 1
-      }</code>
+      }
+```
+
 </pre>
 </details>
 

EIPS/eip-1822.md

@@ -9,36 +9,6 @@ category: ERC
 created: 2019-03-04
 ---
 
-## Table of contents
-
-<!-- TOC -->
-
-- [Table of contents](#table-of-contents)
-- [Simple Summary](#simple-summary)
-- [Abstract](#abstract)
-- [Motivation](#motivation)
-- [Terminology](#terminology)
-- [Specification](#specification)
-  - [Proxy Contract](#proxy-contract)
-    - [Functions](#functions)
-      - [`fallback`](#fallback)
-    - [`constructor`](#constructor)
-  - [Proxiable Contract](#proxiable-contract)
-    - [Functions](#functions-1)
-      - [`proxiable`](#proxiable)
-      - [`updateCodeAddress`](#updatecodeaddress)
-- [Pitfalls when using a proxy](#pitfalls-when-using-a-proxy)
-  - [Separating Variables from Logic](#separating-variables-from-logic)
-  - [Restricting dangerous functions](#restricting-dangerous-functions)
-- [Examples](#examples)
-  - [Owned](#owned)
-  - [ERC-20 Token](#erc-20-token)
-    - [Proxy Contract](#proxy-contract-1)
-    - [Token Logic Contract](#token-logic-contract)
-- [References](#references)
-- [Copyright](#copyright)
-    <!-- /TOC -->
-
 ## Simple Summary
 
 Standard upgradeable proxy contract.
@@ -60,7 +30,7 @@ The following describes a standard for proxy contracts which is universally comp
 - **Logic Contract** - The contract **B** which contains the logic used by Proxy Contract **A**
 - **Proxiable Contract** - Inherited in Logic Contract **B** to provide the upgrade functionality
 
-<p align="center"><img src="../assets/eip-1822/proxy-diagram.png" alt="diagram" width="600"/></p>
+![](../assets/eip-1822/proxy-diagram.png)
 
 ## Specification
 

EIPS/eip-2025.md

@@ -65,7 +65,7 @@ FOR BENEFICIARY in BENEFICIARY_ADDRESSES:
 *With a price of Etheruem at $150.00 this will raise approx USD $2,325,000.00 for developing Eth1.X over the next 18 months.*
 
 
-![Block Rewards Distribution](/assets/eip-2025/block_rewards_distribution.png) *Specific Addresses to be determined
+![Block Rewards Distribution](../assets/eip-2025/block_rewards_distribution.png) *Specific Addresses to be determined
 
 * [FAQ - Why hardcoded values?]( #why-hardcoded-values )
 
@@ -80,7 +80,7 @@ The Eth1x initiative needs funding now, not in 18 months. A loan is necessary to
 
 ### Loan Repayment
 
-![Loan State Diagram](/assets/eip-2025/loan_state.png)
+![Loan State Diagram](../assets/eip-2025/loan_state.png)
 
 There is a risk that the investors lose part of their contribution in the case that this EIP is rejected by the community between the time the funds have been collected and the beginning of the payout schedule. In this case all remaining funds will be returned to the contributors. The interest on the loan is an incentive for investors to participate in spite of this risk. Their downside is limited to the amount of funds spent before this EIP is accepted or rejected, which should be no more than about 5%, while their upside consists of the 10% simple interest paid over the period.
 

EIPS/eip-210.md

@@ -29,11 +29,11 @@ If `block.number >= CONSTANTINOPLE_FORK_BLKNUM`, then when processing a block, b
 * `GAS`: 1000000
 * `TO`: BLOCKHASH_CONTRACT_ADDR
 * `VALUE`: 0
-* `DATA`: <32 bytes corresponding to the block's prevhash>
+* `DATA`: &lt;32 bytes corresponding to the block's prevhash&gt;
 
 If `block.number >= CONSTANTINOPLE_FORK_BLKNUM + 256`, then the BLOCKHASH opcode instead returns the result of executing a call (NOT a transaction) with the parameters:
 
-* `SENDER`: <account from which the opcode was called>
+* `SENDER`: &lt;account from which the opcode was called&gt;
 * `GAS`: 1000000
 * `TO`: BLOCKHASH_CONTRACT_ADDR
 * `VALUE`: 0

EIPS/eip-2135.md

@@ -1,11 +1,10 @@
 ---
 eip: 2135
 title: Consumable Interface (Tickets, etc)
-description: An interface extending EIP-721 and EIP-1155 for consumability, supporting use case such as an event ticket.
+description: An interface extending ERC-721 and ERC-1155 for consumability, supporting use case such as an event ticket.
 author: Zainan Victor Zhou (@xinbenlv)
 discussions-to: https://ethereum-magicians.org/t/eip-2135-erc-consumable-interface/3439
-status: Last Call
-last-call-deadline: 2023-02-01
+status: Final
 type: Standards Track
 category: ERC
 created: 2019-06-23
@@ -32,7 +31,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 ```solidity
 pragma solidity >=0.7.0 <0.9.0;
 
-/// The EIP-165 identifier of this interface is 0xdd691946
+/// The ERC-165 identifier of this interface is 0xdd691946
 interface IERC2135 {
     /// @notice The consume function consumes a token every time it succeeds.
     /// @param _consumer the address of consumer of this token. It doesn't have
@@ -74,9 +73,9 @@ interface IERC2135 {
 }
 ```
 
-2. If the compliant contract is an [EIP-721](./eip-721.md) or [EIP-1155](./eip-1155.md) token, in addition to `OnConsumption`, it **MUST** also emit the `Transfer` / `TransferSingle` event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to `consume` method succeeds.
+2. If the compliant contract is an [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md) token, in addition to `OnConsumption`, it **MUST** also emit the `Transfer` / `TransferSingle` event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to `consume` method succeeds.
 
-3. `supportsInterface(0xdd691946)` **MUST** return `true` for any compliant contract, as per [EIP-165](./eip-165.md).
+3. `supportsInterface(0xdd691946)` **MUST** return `true` for any compliant contract, as per [ERC-165](./eip-165.md).
 
 ## Rationale
 
@@ -85,29 +84,29 @@ interface IERC2135 {
 - who has the power to perform consumption
 - under what condition consumption can occur
 
-It does, however, assume the asset can be identified in a `uint256` asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the EIP-721 pattern.
+It does, however, assume the asset can be identified in a `uint256` asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the ERC-721 pattern.
 
 2. The event notifies subscribers whoever are interested to learn an asset is being consumed.
 
 3. To keep it simple, this standard *intentionally* contains no functions or events related to the creation of a consumable asset. This is because the creation of a consumable asset will need to make assumptions about the nature of an actual use-case. If there are common use-cases for creation, another follow up standard can be created.
 
-4. Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like `ERC721Metadata` from [EIP-721](./eip-721.md)
+4. Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like `ERC721Metadata` from [ERC-721](./eip-721.md)
 
 5. We choose to include an `address consumer` for `consume` function and `isConsumableBy` so that an NFT MAY be consumed for someone other than the transaction initiator.
 
 6. We choose to include an extra `_data` field for future extension, such as
 adding crypto endorsements.
 
-7. We explicitly stay opinion-less about whether EIP-721 or EIP-1155 shall be required because
-while we design this EIP with EIP-721 and EIP-1155 in mind mostly, we don't want to rule out
+7. We explicitly stay opinion-less about whether ERC-721 or ERC-1155 shall be required because
+while we design this EIP with ERC-721 and ERC-1155 in mind mostly, we don't want to rule out
 the potential future case someone use a different token standard or use it in different use cases.
 
 8. The boolean view function of `isConsumableBy` can be used to check whether an asset is
 consumable by the `_consumer`.
 
 ## Backwards Compatibility
 
-This interface is designed to be compatible with EIP-721 and NFT of EIP-1155. It can be tweaked to used for [EIP-20](./eip-20.md), [EIP-777](./eip-777.md) and Fungible Token of EIP-1155.
+This interface is designed to be compatible with ERC-721 and NFT of ERC-1155. It can be tweaked to used for [ERC-20](./eip-20.md), [ERC-777](./eip-777.md) and Fungible Token of ERC-1155.
 
 ## Test Cases