diff --git a/.github/workflows/auto-merge-bot.yml b/.github/workflows/auto-merge-bot.yml index 3c75a1009dc5b..44d499ac67d9a 100644 --- a/.github/workflows/auto-merge-bot.yml +++ b/.github/workflows/auto-merge-bot.yml @@ -1,15 +1,10 @@ on: [pull_request_target] name: Auto-Merge Bot jobs: - enable-auto-merge: - runs-on: ubuntu-latest - steps: - - uses: alexwilson/enable-github-automerge-action@main - with: - github-token: ${{ secrets.TOKEN }} auto_merge_bot: runs-on: ubuntu-latest name: EIP Auto-Merge Bot + if: github.event.pull_request.draft == false steps: - name: Checkout uses: actions/checkout@v2 @@ -18,8 +13,21 @@ jobs: with: node-version: '14' - name: auto-merge-bot - uses: ethereum/EIP-Bot@b6cf981087e888b5d7fbd4726458c453f8491532 # master + uses: ethereum/EIP-Bot@d627d305e33d8cdfe0310588ba74670d4a882600 # master id: auto-merge-bot with: GITHUB-TOKEN: ${{ secrets.TOKEN }} MERGE_ENABLED: false + CORE_EDITORS: "@MicahZoltu,@lightclient,@axic" + ERC_EDITORS: "@lightclient,@axic" + NETWORKING_EDITORS: "@MicahZoltu,@lightclient,@axic" + INTERFACE_EDITORS: "@lightclient,@axic" + META_EDITORS: "@lightclient,@axic" + INFORMATIONAL_EDITORS: "@lightclient,@axic" + enable-auto-merge: + runs-on: ubuntu-latest + needs: ["auto_merge_bot"] + steps: + - uses: alexwilson/enable-github-automerge-action@1.0.0 + with: + github-token: ${{ secrets.TOKEN }} diff --git a/.github/workflows/auto-stagnate-bot.yml b/.github/workflows/auto-stagnate-bot.yml index 51585eacf0674..cc92019cc8bfd 100644 --- a/.github/workflows/auto-stagnate-bot.yml +++ b/.github/workflows/auto-stagnate-bot.yml @@ -16,7 +16,7 @@ jobs: with: node-version: '14' - name: auto-stagnant-bot - uses: ethereum/EIP-Bot@695e64c194456ebde5b9a102adc7443958bd364a # mark-eips-stale + uses: ethereum/EIP-Bot@b3ac0ba3600aea27157fc68d1e36c08cc5a6db77 # mark-eips-stale id: auto-stagnant-bot with: GITHUB-TOKEN: ${{ secrets.TOKEN }} diff --git a/.github/workflows/greetings.yml b/.github/workflows/greetings.yml index effc1d05ee0ad..e93f7004a8a36 100644 --- a/.github/workflows/greetings.yml +++ b/.github/workflows/greetings.yml @@ -9,5 +9,5 @@ jobs: - uses: actions/first-interaction@v1 with: repo-token: ${{ secrets.GITHUB_TOKEN }} - issue-message: 'Since this is your first issue, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.' - pr-message: 'Since this is your first pull request, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.' + issue-message: 'Since this is your first issue, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.\n\nIf this issue was created as a “discussions-to” for an EIP or to discuss an idea for an EIP, please close it and create a thread at [Fellowship of Ethereum Magicians](https://ethereum-magicians.org/).' + pr-message: 'Since this is your first pull request, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance.\n\nIf this issue was created as a “discussions-to” for an EIP or to discuss an idea for an EIP, please close it and create a thread at [Fellowship of Ethereum Magicians](https://ethereum-magicians.org/).' diff --git a/.github/workflows/manual-bot-rerun.yml b/.github/workflows/manual-bot-rerun.yml new file mode 100644 index 0000000000000..e6f6087533473 --- /dev/null +++ b/.github/workflows/manual-bot-rerun.yml @@ -0,0 +1,35 @@ +name: Manual Bot Rerun +on: + workflow_dispatch: + inputs: + pullRequestNumber: + description: "PR number (with the run you'd like to re-run)" + required: true + eventType: + description: "event type (of the run you want to re-run)" + required: true + default: "pull_request_target" + idOfBotWorkflow: + description: "id of the bot workflow (just leave as default if you don't know)" + required: true + default: "6519716" + +jobs: + rerun-bot: + runs-on: ubuntu-latest + name: Manual Bot Rerun + steps: + - name: Checkout + uses: actions/checkout@v2 + - name: Setup Node.js Environment + uses: actions/setup-node@v2 + with: + node-version: '14' + - name: rerun-workflow + uses: ethereum/EIP-Bot@90d0591e71314dc1430c6cde91bb787e185e0b4b # manual-bot-rerun + id: rerun-workflow + with: + GITHUB-TOKEN: ${{ secrets.TOKEN }} + PULL-NUMBER: ${{github.event.inputs.pullRequestNumber }} + ID-TO-RERUN: ${{ github.event.inputs.idOfBotWorkflow }} + EVENT-TYPE: ${{ github.event.inputs.eventType }} diff --git a/.github/workflows/rerun-bot-workflow-run.yml b/.github/workflows/rerun-bot-workflow-run.yml index a93393304973d..8b3fea9a227aa 100644 --- a/.github/workflows/rerun-bot-workflow-run.yml +++ b/.github/workflows/rerun-bot-workflow-run.yml @@ -18,8 +18,10 @@ jobs: with: node-version: '14' - name: auto-merge-bot - uses: ethereum/EIP-Bot@983960684e010eb6ad6e7bd168169e4d57a17cf8 # rerun-pull-request-target-on-review + uses: ethereum/EIP-Bot@1f05ace5691062379bd910aa27402eecb8f295ac # rerun-pull-request-target-on-review id: rerun-auto-merge-bot with: GITHUB-TOKEN: ${{ secrets.TOKEN }} WORKFLOW-ID: ${{github.event.workflow_run.id}} + ID-TO-RERUN: "6519716" + RUN-EVENT-TYPE: "pull_request_target" diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml index 6ea4c6afd1e42..6df01704b1d30 100644 --- a/.github/workflows/stale.yml +++ b/.github/workflows/stale.yml @@ -1,4 +1,4 @@ -name: "Mark stale PRs" +name: "Mark stale PRs & Issues" on: schedule: @@ -6,14 +6,28 @@ on: - cron: "0 * * * *" jobs: - stale: + stale-pr: runs-on: ubuntu-latest + name: "Mark stale PRs" steps: - uses: actions/stale@v3 with: repo-token: ${{ secrets.GITHUB_TOKEN }} - stale-pr-message: 'There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP 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-stale: 60 days-before-close: 7 stale-pr-label: 'stale' + stale-pr-message: 'There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP 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.' + stale-issue: + runs-on: ubuntu-latest + name: "Mark stale issues" + steps: + - uses: actions/stale@v3 + with: + repo-token: ${{ secrets.GITHUB_TOKEN }} + days-before-stale: 180 + days-before-close: 14 + exempt-issue-labels: 'discussions-to' + stale-issue-label: 'stale' + stale-issue-message: 'There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP 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-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 or request a review in a comment.' diff --git a/.travis.yml b/.travis.yml index da1ab55d8926b..570868ad53c94 100644 --- a/.travis.yml +++ b/.travis.yml @@ -30,7 +30,7 @@ matrix: - language: rust cache: cargo before_script: - - cargo install eipv --version=0.2.0 + - cargo install eipv --version=0.4.0 env: TASK='eip-validator' - python: 3.3 env: TASK='codespell' diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 01166edb4db27..49d68352be646 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -70,7 +70,7 @@ These calls generally result in a "rough consensus" around what EIPs should be i The following is the standardization process for all EIPs in all tracks: -![EIP Status Diagram](../assets/eip-1/EIP-process.png) +![EIP Status Diagram](../assets/eip-1/EIP-process-update.jpg) **Idea** - An idea that is pre-draft. This is not tracked within the EIP Repository. @@ -78,13 +78,13 @@ The following is the standardization process for all EIPs in all tracks: **Review** - An EIP Author marks an EIP as ready for and requesting Peer Review. -**Last Call** - This is the final review window for an EIP before moving to `FINAL`. An EIP editor will assign `Last Call` status and set a review end date (review-period-end), typically 14 days later. +**Last Call** - This is the final review window for an EIP before moving to `FINAL`. An EIP editor will assign `Last Call` status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to `REVIEW`. **Final** - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications. -**Stagnant** - Any EIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is moved to `STAGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `DRAFT`. +**Stagnant** - Any EIP in `DRAFT` or `REVIEW` or `LAST CALL` if inactive for a period of 6 months or greater is moved to `STAGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `DRAFT` or it's earlier status. If not resurrected, a proposal may stay forever in the this status. >*EIP Authors are notified of any algorithmic change to the status of their EIP* @@ -113,7 +113,7 @@ EIPs should be written in [markdown] format. There is a [template](https://githu ## EIP Header Preamble -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. Headers marked with "*" are optional and are described below. All other headers are required. +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) @@ -121,29 +121,23 @@ Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style ` description:` *Description is one full (short) sentence* -` author:` *a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.* +` author:` *The list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.* -` * discussions-to:` *a url pointing to the official discussion thread* +` discussions-to:` *The url pointing to the official discussion thread* ` status:` *Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living* -` * review-period-end:` *date review period ends* +` last-call-deadline:` *The date last call period ends on* (Optional field, only needed when status is `Last Call`) -` type:` *Standards Track, Meta, or Informational* +` type:` *One of `Standards Track`, `Meta`, or `Informational`* -` * category:` *Core, Networking, Interface, or ERC* (fill out for Standards Track EIPs only) +` category:` *One of `Core`, `Networking`, `Interface`, or `ERC`* (Optional field, only needed for `Standards Track` EIPs) -` created:` *date created on* +` created:` *Date the EIP was created on* -` * updated:` *comma separated list of dates* +` requires:` *EIP number(s)* (Optional field) -` * requires:` *EIP number(s)* - -` * replaces:` *EIP number(s)* - -` * superseded-by:` *EIP number(s)* - -` * resolution:` *a url pointing to the resolution of this EIP* +` withdrawal-reason:` *A sentence explaining why the EIP was withdrawn.* (Optional field, only needed when status is `Withdrawn`) Headers that permit lists must separate elements with commas. @@ -169,15 +163,11 @@ It is not possible to use both an email and a GitHub username at the same time. At least one author must use a GitHub username, in order to get notified on change requests and have the capability to approve or reject them. -#### `resolution` header - -The `resolution` header is required for Standards Track EIPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the EIP is made. - #### `discussions-to` header -While an EIP is a draft, a `discussions-to` header will indicate the mailing list or URL where the EIP is being discussed. As mentioned above, an example of a place to discuss your EIP is [Ethereum Magicians](https://ethereum-magicians.org/) (this is suitable for EIPs that may be contentious or have a strong governance aspect). +While an EIP is a draft, a `discussions-to` header will indicate the URL where the EIP is being discussed. -As an exception, `discussions-to` cannot point to GitHub pull requests. +The preferred discussion URL is a topic on [Ethereum Magicians](https://ethereum-magicians.org/). The URL cannot point to Github pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics). #### `type` header @@ -191,18 +181,10 @@ The `category` header specifies the EIP's category. This is required for standar The `created` header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14. -#### `updated` header - -The `updated` header records the date(s) when the EIP was updated with "substantial" changes. This header is only valid for EIPs of Draft and Active status. - #### `requires` header EIPs may have a `requires` header, indicating the EIP numbers that this EIP depends on. -#### `superseded-by` and `replaces` headers - -EIPs may also have a `superseded-by` header indicating that an EIP has been rendered obsolete by a later document; the value is the number of the EIP that replaces the current document. The newer EIP must have a `replaces` header containing the number of the EIP that it rendered obsolete. - ## Linking to other EIPs References to other EIPs should follow the format `EIP-N` where `N` is the EIP number you are referring to. Each EIP that is referenced in an EIP **MUST** be accompanied by a relative markdown link the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. The link **MUST** always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main EIPs site, mirrors of the main EIP site, etc. For example, you would link to this EIP with `[EIP-1](./eip-1.md)`. @@ -221,16 +203,19 @@ If you are interested in assuming ownership of an EIP, send a message asking to The current EIP editors are -- Nick Johnson (@arachnid) +- Alex Beregszaszi (@axic) +- Matt Garnett (@lightclient) +- Micah Zoltu (@MicahZoltu) +- Greg Colvin (@gcolvin) + +Emeritus EIP editors are + - Casey Detrio (@cdetrio) -- Hudson Jameson (@Souptacular) +- Nick Johnson (@arachnid) - Vitalik Buterin (@vbuterin) +- Hudson Jameson (@Souptacular) - Nick Savers (@nicksavers) - Martin Becze (@wanderer) -- Greg Colvin (@gcolvin) -- Alex Beregszaszi (@axic) -- Micah Zoltu (@MicahZoltu) -- Matt Garnett (@lightclient) ## EIP Editor Responsibilities @@ -256,8 +241,16 @@ The editors don't pass judgment on EIPs. We merely do the administrative & edito ## Style Guide +### 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. +### RFC 2119 + +EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: + +> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + ## History This document was derived heavily from [Bitcoin's BIP-0001] written by Amir Taaki which in turn was derived from [Python's PEP-0001]. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors. diff --git a/EIPS/eip-101.md b/EIPS/eip-101.md index 91dd8d86c108c..06d4619605235 100644 --- a/EIPS/eip-101.md +++ b/EIPS/eip-101.md @@ -2,7 +2,7 @@ eip: 101 title: Serenity Currency and Crypto Abstraction author: Vitalik Buterin -status: Draft +status: Stagnant type: Standards Track category: Core created: 2015-11-15 diff --git a/EIPS/eip-1010.md b/EIPS/eip-1010.md index b6bf09987c68d..1192de6e52225 100644 --- a/EIPS/eip-1010.md +++ b/EIPS/eip-1010.md @@ -3,7 +3,7 @@ eip: 1010 title: Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c author: Anderson Wesley (@andywesley) discussions-to: https://github.com/andywesley/EIPs/issues/1 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-04-18 diff --git a/EIPS/eip-1011.md b/EIPS/eip-1011.md index 3e3087b1f5e7b..69acd18d08419 100644 --- a/EIPS/eip-1011.md +++ b/EIPS/eip-1011.md @@ -1,7 +1,7 @@ --- eip: 1011 title: Hybrid Casper FFG -status: Draft +status: Stagnant type: Standards Track category: Core author: Danny Ryan (@djrtwo), Chih-Cheng Liang (@ChihChengLiang) diff --git a/EIPS/eip-1015.md b/EIPS/eip-1015.md index e21c7f1720166..bff3ebacc1f14 100644 --- a/EIPS/eip-1015.md +++ b/EIPS/eip-1015.md @@ -3,7 +3,7 @@ eip: 1015 title: Configurable On Chain Issuance author: Alex Van de Sande discussions-to: https://ethereum-magicians.org/t/eip-dynamic-block-rewards-with-governance-contract/204 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-04-20 diff --git a/EIPS/eip-1046.md b/EIPS/eip-1046.md index ab29e214b3504..df7e96b90bf2b 100644 --- a/EIPS/eip-1046.md +++ b/EIPS/eip-1046.md @@ -3,7 +3,7 @@ eip: 1046 title: ERC20 Metadata Extension author: Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler), Matt Condon (@shrugs) discussions-to: https://www.reddit.com/r/raredigitalart/comments/8hfh1g/erc20_metadata_extension_eip_1046/ -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-04-13 diff --git a/EIPS/eip-1051.md b/EIPS/eip-1051.md index 309f4137743ae..7638f3314ebb8 100644 --- a/EIPS/eip-1051.md +++ b/EIPS/eip-1051.md @@ -3,7 +3,7 @@ eip: 1051 title: Overflow checking for the EVM author: Nick Johnson discussions-to: https://ethereum-magicians.org/t/eip-arithmetic-overflow-detection-for-the-evm/261 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-05-02 diff --git a/EIPS/eip-1056.md b/EIPS/eip-1056.md index a600cb92fdc87..2af473930acf2 100644 --- a/EIPS/eip-1056.md +++ b/EIPS/eip-1056.md @@ -5,7 +5,7 @@ author: Pelle Braendgaard , Joel Torstensson , Andrea Lanfranchi (@AndreaLanfranchi), Michael Carter (@bitsbetrippin), IfDefElse discussions-to: https://ethereum-magicians.org/t/eip-progpow-a-programmatic-proof-of-work/272 -status: Review +status: Stagnant type: Standards Track category: Core created: 2018-05-02 diff --git a/EIPS/eip-1062.md b/EIPS/eip-1062.md index 022467747dc0e..2265daef6e26b 100644 --- a/EIPS/eip-1062.md +++ b/EIPS/eip-1062.md @@ -3,7 +3,7 @@ eip: 1062 title: Formalize IPFS hash into ENS(Ethereum Name Service) resolver author: Phyrex Tsai , Portal Network Team discussions-to: https://ethereum-magicians.org/t/eip-1062-formalize-ipfs-hash-into-ens-ethereum-name-service-resolver/281 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-05-02 diff --git a/EIPS/eip-1066.md b/EIPS/eip-1066.md index 9f057326ec683..061e8538c0a17 100644 --- a/EIPS/eip-1066.md +++ b/EIPS/eip-1066.md @@ -3,7 +3,7 @@ eip: 1066 title: Status Codes author: Brooklyn Zelenka (@expede), Tom Carchrae (@carchrae), Gleb Naumenko (@naumenkogs) discussions-to: https://ethereum-magicians.org/t/erc-1066-ethereum-status-codes-esc/ -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-05-05 diff --git a/EIPS/eip-107.md b/EIPS/eip-107.md index d6a79c2b53cf3..fd1e23b0bbbb9 100644 --- a/EIPS/eip-107.md +++ b/EIPS/eip-107.md @@ -3,7 +3,7 @@ eip: 107 title: safe "eth_sendTransaction" authorization via html popup author: Ronan Sandford (@wighawag) created: 2016-06-05 -status: Draft +status: Stagnant type: Standards Track category: Interface --- diff --git a/EIPS/eip-1077.md b/EIPS/eip-1077.md index 3d37476ce9b42..f31a054672d3b 100644 --- a/EIPS/eip-1077.md +++ b/EIPS/eip-1077.md @@ -3,7 +3,7 @@ eip: 1077 title: Gas relay for contract calls author: Alex Van de Sande , Ricardo Guilherme Schmidt (@3esmit) discussions-to: https://ethereum-magicians.org/t/erc1077-and-1078-the-magic-of-executable-signed-messages-to-login-and-do-actions/351 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-05-04 diff --git a/EIPS/eip-1078.md b/EIPS/eip-1078.md index 9c40dd8132136..0ce1df73cc6ff 100644 --- a/EIPS/eip-1078.md +++ b/EIPS/eip-1078.md @@ -3,7 +3,7 @@ eip: 1078 title: Universal login / signup using ENS subdomains author: Alex Van de Sande discussions-to: https://ethereum-magicians.org/t/erc1077-and-1078-the-magic-of-executable-signed-messages-to-login-and-do-actions/351 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-05-04 diff --git a/EIPS/eip-1080.md b/EIPS/eip-1080.md index a60a52c976bd9..2c3b5a3e870f0 100644 --- a/EIPS/eip-1080.md +++ b/EIPS/eip-1080.md @@ -3,7 +3,7 @@ eip: 1080 title: Recoverable Token author: Bradley Leatherwood discussions-to: https://ethereum-magicians.org/t/erc-1080-recoverabletoken-standard/364 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-05-02 diff --git a/EIPS/eip-1081.md b/EIPS/eip-1081.md index 754966e2a5d40..cb64299a42e39 100644 --- a/EIPS/eip-1081.md +++ b/EIPS/eip-1081.md @@ -3,7 +3,7 @@ eip: 1081 title: Standard Bounties author: Mark Beylin , Kevin Owocki , Ricardo Guilherme Schmidt (@3esmit) discussions-to: https://gitter.im/bounties-network/Lobby -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-05-14 diff --git a/EIPS/eip-1087.md b/EIPS/eip-1087.md index fcf5cca50fd93..8e3ba78b1885c 100644 --- a/EIPS/eip-1087.md +++ b/EIPS/eip-1087.md @@ -3,7 +3,7 @@ eip: 1087 title: Net gas metering for SSTORE operations author: Nick Johnson (@arachnid) discussions-to: https://ethereum-magicians.org/t/eip-net-storage-gas-metering-for-the-evm/383 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-05-17 diff --git a/EIPS/eip-1102.md b/EIPS/eip-1102.md index cf26f0006dfa3..f80bae486cf6a 100644 --- a/EIPS/eip-1102.md +++ b/EIPS/eip-1102.md @@ -3,7 +3,7 @@ eip: 1102 title: Opt-in account exposure author: Paul Bouchon , Erik Marks (@rekmarks) discussions-to: https://ethereum-magicians.org/t/eip-1102-opt-in-provider-access/414 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2018-05-04 diff --git a/EIPS/eip-1109.md b/EIPS/eip-1109.md index d666a5f209064..8f946d68f096b 100644 --- a/EIPS/eip-1109.md +++ b/EIPS/eip-1109.md @@ -3,7 +3,7 @@ eip: 1109 title: PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts) author: Jordi Baylina (@jbaylina) discussions-to: https://ethereum-magicians.org/t/eip-1109-remove-call-costs-for-precompiled-contracts/447 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-05-22 diff --git a/EIPS/eip-1123.md b/EIPS/eip-1123.md index b0ea91705bde6..ebd579f22cada 100644 --- a/EIPS/eip-1123.md +++ b/EIPS/eip-1123.md @@ -7,7 +7,6 @@ status: Withdrawn type: Standards Track category: ERC created: 2018-06-01 -replaces: 190 --- This ERC has been abandoned in favor of the EthPM V3 smart contract packaging standard defined in [ERC-2678](./eip-2678.md) diff --git a/EIPS/eip-1129.md b/EIPS/eip-1129.md index bce6407fb963d..f30b962b21c90 100644 --- a/EIPS/eip-1129.md +++ b/EIPS/eip-1129.md @@ -3,7 +3,7 @@ eip: 1129 title: Standardised DAPP announcements author: Jan Turk (@ThunderDeliverer) discussions-to: https://ethereum-magicians.org/t/eip-sda-standardised-dapp-announcements/508?u=thunderdeliverer -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-05-31 diff --git a/EIPS/eip-1132.md b/EIPS/eip-1132.md index d80c41c733279..b1b6ebe42bbea 100644 --- a/EIPS/eip-1132.md +++ b/EIPS/eip-1132.md @@ -4,7 +4,7 @@ title: Extending ERC20 with token locking capability author: nitika-goel type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-06-03 discussions-to: https://github.com/ethereum/EIPs/issues/1132 --- diff --git a/EIPS/eip-1153.md b/EIPS/eip-1153.md index e4668f5732ac7..ec4e9ca9469e2 100644 --- a/EIPS/eip-1153.md +++ b/EIPS/eip-1153.md @@ -3,7 +3,7 @@ eip: 1153 title: Transient storage opcodes author: Alexey Akhunov (@AlexeyAkhunov) discussions-to: https://ethereum-magicians.org/t/eip-transient-storage-opcodes/553 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-06-15 diff --git a/EIPS/eip-1175.md b/EIPS/eip-1175.md index 6da0dc669e80b..f8a3384f2462a 100644 --- a/EIPS/eip-1175.md +++ b/EIPS/eip-1175.md @@ -3,7 +3,7 @@ eip: 1175 title: Wallet & shop standard for all tokens (erc20) author: Jet Lim (@Nitro888) discussions-to: https://github.com/ethereum/EIPs/issues/1182 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-06-21 diff --git a/EIPS/eip-1178.md b/EIPS/eip-1178.md index 0bcf6814fc20f..0c4572b02dddc 100644 --- a/EIPS/eip-1178.md +++ b/EIPS/eip-1178.md @@ -3,7 +3,7 @@ eip: 1178 title: Multi-class Token Standard author: Albert Chon discussions-to: https://github.com/ethereum/EIPs/issues/1179 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-06-22 diff --git a/EIPS/eip-1185.md b/EIPS/eip-1185.md index 88b9672799e43..ccfbf16d98a37 100644 --- a/EIPS/eip-1185.md +++ b/EIPS/eip-1185.md @@ -2,7 +2,7 @@ eip: 1185 title: Storage of DNS Records in ENS author: Jim McDonald (@mcdee) -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-06-26 diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 7443ea22ff54e..7acfd1db0c06c 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -3,7 +3,7 @@ eip: 1186 title: RPC-Method to get Merkle Proofs - eth_getProof author: Simon Jentzsch , Christoph Jentzsch discussions-to: https://github.com/ethereum/EIPs/issues/1186 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2018-06-24 diff --git a/EIPS/eip-1191.md b/EIPS/eip-1191.md index a8c0f07e5e43a..560d35492a49c 100644 --- a/EIPS/eip-1191.md +++ b/EIPS/eip-1191.md @@ -3,7 +3,7 @@ eip: 1191 title: Add chain id to mixed-case checksum address encoding author: Juliano Rizzo (@juli) status: Last Call -review-period-end: 2019-11-18 +last-call-deadline: 2019-11-18 type: Standards Track category: ERC created: 2018-03-18 diff --git a/EIPS/eip-1202.md b/EIPS/eip-1202.md index f979466c18a80..29c0048857b8a 100644 --- a/EIPS/eip-1202.md +++ b/EIPS/eip-1202.md @@ -39,32 +39,103 @@ Voting is one of the earliest example of EVM programming, and also a key to DAO/ ## Specifications ```solidity -pragma solidity ^0.5.8; - - -/** - * - Multiple issue - * - Multiple selection - * - Ordered multiple result - **/ -contract ERC1202 { - - // Vote with an option. The caller needs to handle success or not - function vote(uint issueId, uint option) public returns (bool success); - function setStatus(uint issueId, bool isOpen) public returns (bool success); - - function issueDescription(uint issueId) public view returns (string desc); - function availableOptions(uint issueId) public view returns (uint[] options); - function optionDescription(uint issueId, uint option) public view returns (string desc); - function ballotOf(uint issueId, address addr) public view returns (uint option); - function weightOf(uint issueId, address addr) public view returns (uint weight); - function getStatus(uint issueId) public view returns (bool isOpen); - function weightedVoteCountsOf(uint issueId, uint option) public view returns (uint count); - function topOptions(uint issueId, uint limit) public view returns (uint[] topOptions_); - - event OnVote(uint issueId, address indexed _from, uint _value); - event OnStatusChange(uint issueId, bool newIsOpen); +// SPDX-License-Identifier: GPL-3.0 + +pragma solidity >=0.7.0 <0.9.0; + + +/// @title Core interface of ERC1202: A list of *REQUIRED* methods and events for +/// a contract to be considered conforming to ERC1202. +/// +/// @author Zainan Victor Zhou +/// +/// @dev Each ERC1202 contract is a cluster of issues being voted on, or done voted. +/// Any contract of ERC1202 **MUST** implement ALL the following methods and events. +/// +/// Each *issue* is identified with an `issueId`, +/// For any given `issue`, each available option in that issue is +/// identified with an `optionId`. +interface ERC1202Core { + + /// @dev Cast a vote for an issue with `issueId` for option with `optionId` + /// @param _issueId: the issue this vote is casting on. + /// @param _optionIds: an *ordered* array of the options being casted for the issue. + /// Whenever referring to the options as a whole, the order MUST be maintained. + /// @return a boolean if TRUE means the vote is casted successfully. + function vote(uint _issueId, uint[] memory _optionIds) external returns (bool); + + /// @dev Query the top ranked options of an issue given issueId and + /// a limit of max number of top options. + /// @param _issueId: the issue being queried for the top options. + /// @param _limit: the max number of top options the caller expect to return. + /// @return an ordered list of the top options for given issueId and limit, + /// where the first in array is the most favorite one, and the last in + /// array is the least favorite one among the list. + /// Specifically, WHEN limit = 0, returns the default length of winning + /// options in their ranking in an issue. + function topOptions( + uint _issueId, uint _limit + ) external view returns (uint[] memory); + + /// @dev This event is emitted when a vote has been casted. + /// @param issueId the issue the vote is being cased on. + /// @param optionIds an ordered list of the options the vote is casting for. + event OnVote(uint indexed issueId, uint[] optionIds, address indexed voterAddr); + +} + +/// @title Metadata interface for ERC1202: A list of *RECOMMENDED* methods and events for +/// a contract to be considered conforming to ERC1202. +/// +/// @author Zainan Victor Zhou +interface ERC1202Metadata { + + /// @notice A descriptive text for an issue in this contract. + function issueText() external view returns (string memory _text); + + /// @notice A distinct Uniform Resource Identifier (URI) for a given issue. + /// @dev Throws if `_issueId` is not a valid issue; + /// URIs are defined in RFC 3986. + function issueURI(uint256 _issueId) external view returns (string memory _uri); + + /// @notice A descriptive text for an option in an issue in this contract. + function optionText(uint _issueId, uint _optionId) external view returns (string memory _text); + + /// @notice A distinct Uniform Resource Identifier (URI) for a given option in a given issue. + /// @dev Throws if `_issueId` is not a valid option-issue combination; + /// URIs are defined in RFC 3986. + function optionURI(uint _issueId, uint _optionId) external view returns (string memory _uri); } + +/// @title Status interface for ERC1202: A list of *RECOMMENDED* methods and events for +/// a contract to be considered conforming to ERC1202. +/// +/// @author Zainan Victor Zhou +interface ERC1202Status { + + /// @dev This event is emitted when an issue has changed status. + /// @param issueId the issue about which a status change has happened. + /// @param isOpen the status + event OnStatusChange(uint indexed issueId, bool indexed isOpen); + + /// @dev Sets the status of a issue, e.g. open for vote or closed for result. + /// @param _issueId the issue of Status being set. + /// @param _isOpen the status to set. + /// @return _success whether the setStatus option succeeded. + function setStatus(uint _issueId, bool _isOpen) external returns (bool _success); + + /// @dev Gets the status of a issue, e.g. open for vote or closed for result. + /// @param _issueId the issue of Status being get. + /// @return _isOpen the status of the issue. + function getStatus(uint _issueId) external view returns (bool _isOpen); + + /// @dev Retrieves the ranked options voted by a given voter for a given issue. + /// @param _issueId the issue + /// @param _voter the aaddres of voter. + /// @return _optionIds the ranked options voted by voter. + function voteOf(uint _issueId, address _voter) external view returns (uint[] memory _optionIds); +} + ``` ## Rationale @@ -82,20 +153,6 @@ We made the following design decisions and here are the rationales. ## Backward Compatibility There is no backward compatibility issue we are aware of. -## Simple Code Examples -### Example 1: Simplest Version: Single Issue Yes/No Question Per Smart Contract Address Per Non-Weighted Vote - - - [Source Code](https://github.com/xinbenlv/eip-1202-draft/blob/master/contracts/simple-version/SimplestVote1202.sol) - - [Deployment (Ropsten)](https://ropsten.etherscan.io/address/0x067e76ddd9c67f7ae606b18d881545512d4b680c#code) - -### Example 2: TokenVote with Simple Interface with Weight Assigned by Token and Pre-registered Snapshot of Token-Holders - - [Source Code](https://github.com/xinbenlv/eip-1202-draft/blob/master/contracts/simple-version/TokenVote1202.sol) - - [Deployment (Ropsten)](https://ropsten.etherscan.io/address/0x5bd007a224fe8820b19cc0bce8e241f4752ce74d#code) - -### Example 3: TokenVote with Advanced Interface - - [Source Code](https://github.com/xinbenlv/eip-1202-draft/blob/master/contracts/advanced-version/AdvancedTokenVote1202.sol) - - [Deployment (Ropsten)](https://ropsten.etherscan.io/address/0xfd8b3be5f9db4662d1c9269f948345b46e37fd26#code) - ## Security Considerations EIP-1202 is a voting standard. We expect the voting standard to be used in connection with other contracts such as token distributions, conducting actions in consensus or on behalf of an entity, multi-signature wallets, etc. @@ -113,32 +170,6 @@ The third consideration is non-trivialness. Some voting applications assume ***a The fourth consideration is potential abuse. When voting is standardized and put on contract, it is possible to write another contract that rewards a voter to vote in a certain way. It creates potential issues of bribery and conflict of interest abuse that is previously hard to implement. - -## Bibliography -### Related EIPs - - [EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)](./eip-20.md) - - [EIP-165: Standard Interface Detection](./eip-165.md) - - [EIP-721: Non-Fungible Token Standard(a.k.a. ERC-721)](./eip-721.md) - - [EIP-735: ERC: Claim Holder](https://github.com/ethereum/EIPs/issues/735) - - [EIP-780: ERC: Ethereum Claims Registry](https://github.com/ethereum/EIPs/issues/780) - - [EIP-777: A New Advanced Token Standard](./eip-777.md) - - [EIP-897: ERC DelegateProxy](./eip-897.md) - - [EIP-1155: Crypto Item Standard](./eip-1155.md) - - [EIP-1178: Multi-class Token Standard](./eip-1178.md) - - [EIP-1167: Minimal Proxy Contract](./eip-1167.md) - - [EIP-1203: Multi-class Token Standard(ERC-20 Extension)](./eip-1203.md) - -### Worthnoting Projects - - [Ethereum DAO: How to build a DEMOCRACY on the blockchain](https://www.ethereum.org/dao) - - [Carbon Vote](http://carbonvote.com/) - - [Paper: A Smart Contract for Boardroom Voting with Maximum Voter Privacy](https://eprint.iacr.org/2017/110.pdf) - *Suggested by @aodhgan* - - [Private Voting for TCR](https://blog.enigma.co/private-voting-for-tcrs-with-enigma-b441b5d4fa7b) - - [Consensus/PLCR implementation](https://github.com/ConsenSys/PLCRVoting) - - [Aragon Voting App](https://wiki.aragon.org/dev/apps/voting/) - -## Acknowledgement -We appreciate Ansley, Andrew, Fred from Enigma, Fan and Raullen from IoTex for sharing us their use cases. we also appreciate the valuable input for designing an EIP from distinguished community members including: @frozeman, @fulldecent, @bingen, @aodhgan. - ## Work Directory The drafting and revision of EIP-1202 is conducted at [GitHub/xinbenlv/eip-1202](https://github.com/xinbenlv/eip-1202) diff --git a/EIPS/eip-1203.md b/EIPS/eip-1203.md index 12ccfba22872d..6148bd0b96d08 100644 --- a/EIPS/eip-1203.md +++ b/EIPS/eip-1203.md @@ -3,7 +3,7 @@ eip: 1203 title: ERC-1203 Multi-Class Token Standard (ERC-20 Extension) author: Jeff Huang , Min Zu discussions-to: https://github.com/ethereum/EIPs/issues/1203 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-07-01 diff --git a/EIPS/eip-1207.md b/EIPS/eip-1207.md index 5f769b7564a30..732d964f11e56 100644 --- a/EIPS/eip-1207.md +++ b/EIPS/eip-1207.md @@ -3,7 +3,7 @@ eip: 1207 title: DAuth Access Delegation Standard author: Xiaoyu Wang (@wxygeek), Bicong Wang (@Wangbicong) discussions-to: https://github.com/ethereum/EIPs/issues/1207 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-07-10 diff --git a/EIPS/eip-1227.md b/EIPS/eip-1227.md index be566ead875d1..526720790f38b 100644 --- a/EIPS/eip-1227.md +++ b/EIPS/eip-1227.md @@ -3,7 +3,7 @@ eip: 1227 title: Defuse Difficulty Bomb and Reset Block Reward author: SmeargleUsedFly (@SmeargleUsedFly) discussions-to: https://github.com/ethereum/EIPs/issues/1227 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-07-18 diff --git a/EIPS/eip-1261.md b/EIPS/eip-1261.md index d8224f7763565..eac7711abd104 100644 --- a/EIPS/eip-1261.md +++ b/EIPS/eip-1261.md @@ -4,7 +4,7 @@ title: Membership Verification Token (MVT) author: Chaitanya Potti (@chaitanyapotti), Partha Bhattacharya (@pb25193) type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-07-14 requires: 165, 173 discussions-to: https://github.com/ethereum/EIPs/issues/1261 diff --git a/EIPS/eip-1271.md b/EIPS/eip-1271.md index 6557d8831323e..f5bc73f8579a0 100644 --- a/EIPS/eip-1271.md +++ b/EIPS/eip-1271.md @@ -4,7 +4,7 @@ title: Standard Signature Validation Method for Contracts author: Francisco Giordano (@frangio), Matt Condon (@shrugs), Philippe Castonguay (@PhABC), Amir Bandeali (@abandeali1), Jorge Izquierdo (@izqui), Bertrand Masius (@catageek) discussions-to: https://github.com/ethereum/EIPs/issues/1271 status: Last Call -review-period-end: 2021-07-26 +last-call-deadline: 2021-07-26 type: Standards Track category: ERC created: 2018-07-25 diff --git a/EIPS/eip-1276.md b/EIPS/eip-1276.md index d5bcc711b3a4c..eda1176721c63 100644 --- a/EIPS/eip-1276.md +++ b/EIPS/eip-1276.md @@ -5,7 +5,7 @@ author: EOS Classic (@eosclassicteam) discussions-to: https://ethereum-magicians.org/t/eip-1276-eliminate-difficulty-bomb-and-adjust-block-reward-on-constantinople-shift/908 type: Standards Track category: Core -status: Draft +status: Stagnant created: 2018-07-31 --- diff --git a/EIPS/eip-1285.md b/EIPS/eip-1285.md index 16b5a992176d5..53ce10c9ade3d 100644 --- a/EIPS/eip-1285.md +++ b/EIPS/eip-1285.md @@ -3,7 +3,7 @@ eip: 1285 title: Increase Gcallstipend gas in the CALL opcode author: Ben Kaufman , Adam Levi discussions-to: https://ethereum-magicians.org/t/eip-1285-increase-gcallstipend-gas-in-the-call-opcode/941 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-08-01 diff --git a/EIPS/eip-1295.md b/EIPS/eip-1295.md index 33fb4a453c509..553511d9cb1e9 100644 --- a/EIPS/eip-1295.md +++ b/EIPS/eip-1295.md @@ -3,7 +3,7 @@ eip: 1295 title: Modify Ethereum PoW Incentive Structure and Delay Difficulty Bomb author: Brian Venturo (@atlanticcrypto) discussions-to: https://github.com/atlanticcrypto/Discussion/issues/1 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-08-05 diff --git a/EIPS/eip-1319.md b/EIPS/eip-1319.md index 94991c0a9c877..5bb7d0e5a4fdd 100644 --- a/EIPS/eip-1319.md +++ b/EIPS/eip-1319.md @@ -4,7 +4,7 @@ title: Smart Contract Package Registry Interface author: Piper Merriam , Christopher Gewecke , g. nicholas d'andrea , Nick Gheorghita (@njgheorghita) type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-08-13 discussions-to: https://github.com/ethereum/EIPs/issues/1319 --- diff --git a/EIPS/eip-1328.md b/EIPS/eip-1328.md index 63d61278f0faf..997f98e8c2852 100644 --- a/EIPS/eip-1328.md +++ b/EIPS/eip-1328.md @@ -4,7 +4,7 @@ title: WalletConnect Standard URI Format author: ligi , Pedro Gomes type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-08-15 discussions-to: https://ethereum-magicians.org/t/wallet-connect-eip/850 --- diff --git a/EIPS/eip-1337.md b/EIPS/eip-1337.md index 5db84b8bcaeb6..3f26185d224af 100644 --- a/EIPS/eip-1337.md +++ b/EIPS/eip-1337.md @@ -4,7 +4,7 @@ title: Subscriptions on the blockchain author: Kevin Owocki , Andrew Redden , Scott Burke , Kevin Seagraves , Luka Kacil , Štefan Šimec , Piotr Kosiński (@kosecki123), ankit raj , John Griffin , Nathan Creswell discussions-to: https://ethereum-magicians.org/t/eip-1337-subscriptions-on-the-blockchain/4422 type: Standards Track -status: Draft +status: Stagnant category: ERC created: 2018-08-01 requires: 20, 165 diff --git a/EIPS/eip-1352.md b/EIPS/eip-1352.md index 11416bbad847a..4dc1ad8e8eb91 100644 --- a/EIPS/eip-1352.md +++ b/EIPS/eip-1352.md @@ -3,7 +3,7 @@ eip: 1352 title: Specify restricted address range for precompiles/system contracts author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-1352-specify-restricted-address-range-for-precompiles-system-contracts/1151 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-07-27 diff --git a/EIPS/eip-1380.md b/EIPS/eip-1380.md index f8476e1f4673b..4ef435e87a84f 100644 --- a/EIPS/eip-1380.md +++ b/EIPS/eip-1380.md @@ -3,7 +3,7 @@ eip: 1380 title: Reduced gas cost for call to self author: Alex Beregszaszi (@axic), Jacques Wagener (@jacqueswww) discussions-to: https://ethereum-magicians.org/t/eip-1380-reduced-gas-cost-for-call-to-self/1242 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-08-31 diff --git a/EIPS/eip-1386.md b/EIPS/eip-1386.md index 481c0b18a207e..a83217050eabf 100644 --- a/EIPS/eip-1386.md +++ b/EIPS/eip-1386.md @@ -3,7 +3,7 @@ eip: 1386 title: Attestation management contract author: Weiwu Zhang , James Sangalli discussions-to: https://github.com/ethereum/EIPs/issues/1386 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-09-08 diff --git a/EIPS/eip-1387.md b/EIPS/eip-1387.md index 360ab3de2b59a..1061ffec26dc8 100644 --- a/EIPS/eip-1387.md +++ b/EIPS/eip-1387.md @@ -3,7 +3,7 @@ eip: 1387 title: Merkle Tree Attestations with Privacy enabled author: Weiwu Zhang , James Sangalli discussions-to: https://github.com/ethereum/EIPs/issues/1387 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-09-08 diff --git a/EIPS/eip-1417.md b/EIPS/eip-1417.md index aa9f51c36821d..ece22ceba9967 100644 --- a/EIPS/eip-1417.md +++ b/EIPS/eip-1417.md @@ -4,7 +4,7 @@ title: Poll Standard author: Chaitanya Potti (@chaitanyapotti), Partha Bhattacharya (@pb25193) type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-09-16 requires: 165, 1261 discussions-to: https://github.com/ethereum/EIPs/issues/1417 diff --git a/EIPS/eip-1438.md b/EIPS/eip-1438.md index 3d13ac80e9ff5..5a4ffaec83f5f 100644 --- a/EIPS/eip-1438.md +++ b/EIPS/eip-1438.md @@ -3,7 +3,7 @@ eip: 1438 title: dApp Components (avatar) & Universal Wallet author: Jet Lim (@Nitro888) discussions-to: https://ethresear.ch/t/avatar-system-and-universal-wallet-for-ethereum-address/3473 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-09-21 diff --git a/EIPS/eip-1444.md b/EIPS/eip-1444.md index 4977ed7de67e0..378ac7e5e70ca 100644 --- a/EIPS/eip-1444.md +++ b/EIPS/eip-1444.md @@ -3,7 +3,7 @@ eip: 1444 title: Localized Messaging with Signal-to-Text author: Brooklyn Zelenka (@expede), Jennifer Cooper (@jenncoop) discussions-to: https://ethereum-magicians.org/t/eip-1444-localized-messaging-with-signal-to-text/ -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-09-23 diff --git a/EIPS/eip-1450.md b/EIPS/eip-1450.md index c905b7a2d4f78..d8476050bdca6 100644 --- a/EIPS/eip-1450.md +++ b/EIPS/eip-1450.md @@ -3,7 +3,7 @@ eip: 1450 title: ERC-1450 A compatible security token for issuing and trading SEC-compliant securities author: John Shiple (@johnshiple), Howard Marks , David Zhang discussions-to: https://ethereum-magicians.org/t/erc-proposal-ldgrtoken-a-compatible-security-token-for-issuing-and-trading-sec-compliant-securities/1468 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-09-25 diff --git a/EIPS/eip-1459.md b/EIPS/eip-1459.md index e559fc2bd8110..72d689c2c25ca 100644 --- a/EIPS/eip-1459.md +++ b/EIPS/eip-1459.md @@ -4,7 +4,7 @@ title: Node Discovery via DNS author: Felix Lange , Péter Szilágyi type: Standards Track category: Networking -status: Draft +status: Stagnant created: 2018-09-26 requires: 778 discussions-to: https://github.com/ethereum/devp2p/issues/50 diff --git a/EIPS/eip-1462.md b/EIPS/eip-1462.md index 6893c3878b889..32f7f0daaf914 100644 --- a/EIPS/eip-1462.md +++ b/EIPS/eip-1462.md @@ -3,7 +3,7 @@ eip: 1462 title: Base Security Token author: Maxim Kupriianov , Julian Svirsky discussions-to: https://ethereum-magicians.org/t/erc-1462-base-security-token/1501 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-10-01 diff --git a/EIPS/eip-1470.md b/EIPS/eip-1470.md index ee705c4685617..7ecd9d304896e 100644 --- a/EIPS/eip-1470.md +++ b/EIPS/eip-1470.md @@ -3,7 +3,7 @@ eip: 1470 title: Smart Contract Weakness Classification (SWC) author: Gerhard Wagner (@thec00n) discussions-to: https://github.com/ethereum/EIPs/issues/1469 -status: Draft +status: Stagnant type: Informational created: 2018-09-18 --- diff --git a/EIPS/eip-1474.md b/EIPS/eip-1474.md index 82bbce978b7ef..90646ba153635 100644 --- a/EIPS/eip-1474.md +++ b/EIPS/eip-1474.md @@ -3,7 +3,7 @@ eip: 1474 title: Remote procedure call specification author: Paul Bouchon , Erik Marks (@rekmarks) discussions-to: https://ethereum-magicians.org/t/eip-remote-procedure-call-specification/1537 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2018-10-02 diff --git a/EIPS/eip-1482.md b/EIPS/eip-1482.md index 9f25ec464320a..e63f6f2fedf4a 100644 --- a/EIPS/eip-1482.md +++ b/EIPS/eip-1482.md @@ -3,7 +3,7 @@ eip: 1482 title: Define a maximum block timestamp drift author: Maurelian (@Maurelian) discussions-to: https://ethereum-magicians.org/t/define-a-maximum-block-timestamp-drift/1556 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-10-09 diff --git a/EIPS/eip-1484.md b/EIPS/eip-1484.md index d5777e8ca8dec..6176bb7f4a542 100644 --- a/EIPS/eip-1484.md +++ b/EIPS/eip-1484.md @@ -3,7 +3,7 @@ eip: 1484 title: Digital Identity Aggregator author: Anurag Angara , Andy Chorlian , Shane Hampton , Noah Zinsmeister discussions-to: https://github.com/ethereum/EIPs/issues/1495 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-10-12 diff --git a/EIPS/eip-1491.md b/EIPS/eip-1491.md index 2905d79701866..6b34f463dab86 100644 --- a/EIPS/eip-1491.md +++ b/EIPS/eip-1491.md @@ -3,7 +3,7 @@ eip: 1491 title: Human Cost Accounting Standard (Like Gas but for humans) author: Iamnot Chris (@cohabo) discussions-to: https://github.com/freeworkculture/kazini/issues/11 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-10-12 diff --git a/EIPS/eip-1523.md b/EIPS/eip-1523.md index 3a08cab63f19c..cb6e0a4bccdcd 100644 --- a/EIPS/eip-1523.md +++ b/EIPS/eip-1523.md @@ -73,36 +73,40 @@ In analogy to the “ERC721 Metadata JSON Schema”, the tokenURI **MUST** point "type": "string", "description": "Describes the asset to which this NFT represents", }, - "carrier": { - "type": "string", - "description": "Describes the carrier which takes the primary risk", - }, - "risk": { - "type": "string", - "description": "Describes the risk", - }, - "parameters": { - "type": "string", - "description": "Describes further parameters characterizing the risk", - }, - "status": { - "type": "string", - "description": "Defines the status of the policy, e.g. Applied, Underwritten, Claimed, Paid out, etc." - } + \[additional parameters according to the following table\] } } ``` +### Additional parameters for the metadata JSON Schema + +| Parameter | Type | Mandatory | Description | +| ------------- | ------------- | ----------| ---------------------------------------------------------------------------------- | +| carrier | string | yes | Describes the carrier which takes the primary risk | +| risk | string | yes | Describes the risk | +| status | string | yes | Describes the status of the policy, e.g. applied for, underwritten, expired | +| parameters | string | no | Describes further parameters characterizing the risk | +| terms | string | no | Describes legal terms & conditions which apply for this policy | +| premium | string | no | A string representation of the premium, **MAY** contain currency denominator | +| sum_insured | string | no | A string representation of the sum insured, **MAY** contain currency denominator | + +Parameters which are mandatory **MUST** be included in the metadata JSON. Other parameters **MAY** be included. However, the proposed optional parameters **SHOULD** be used for the intended purpose, so e.g. if the premium amount would be included in the metadata, the parameter name **SHOULD** be "premium". +All parameters **MAY** be plain text or **MAY** also be URIs pointing to resources which contain the respective information, and which **MAY** be protected by an authentication mechanism. + ## Rationale Insurance policies form an important class of financial assets, and it is natural to express those assets as a class of non-fungible tokens which adhere to the established ERC-721 standard. -We propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy. +We propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy. Standardization is key because we expect decentralized insurance to receive widespread adoption and it is crucial to establish a unified standard to enable composability and the creation of universal toolsets. +We therefore propose a standardized naming scheme for the different parameters describing an insurance policy. We propose three mandatory parameters which need to be included in every NFT and further parameters which **MAY** be used, and for which we only standardize the naming conventions. +### Mandatory parameters While policies can have a multitude of possible properties, it is common that policies are issued by some entity, which is basically the entity responsible for paying out claims. Second, an insurance policy is typically related to a specific risk. Some risks are unique, but there are cases where many policies share the same risk (e.g. all flight delay policies for the same flight). In general, the relation of policies to risks is a many-to-one relation with the special case of a one-to-one relation. -Third, most policies need more parameters to characterize the risk and other features, like premium, period etc. -Forth, a policy has a lifecycle of different statuses. +Third, a policy has a lifecycle of different statuses. Therefore the NFT We believe that those four properties are necessary to describe a policy. For many applications, those properties may be even sufficient. + +### Optional parameters +Most policies need more parameters to characterize the risk and other features, like premium, period etc. The naming conventions are listed in the above table. However, any implementation **MAY** chose to implement more properties. ### On-chain vs. off-chain metadata diff --git a/EIPS/eip-1571.md b/EIPS/eip-1571.md index 88655fe8fb094..a0206f4d0daea 100644 --- a/EIPS/eip-1571.md +++ b/EIPS/eip-1571.md @@ -3,7 +3,7 @@ eip: 1571 title: EthereumStratum/2.0.0 author: Andrea Lanfranchi (@AndreaLanfranchi), Pawel Bylica (@chfast), Marius Van Der Wijden (@MariusVanDerWijden) discussions-to: https://github.com/AndreaLanfranchi/EthereumStratum-2.0.0/issues -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2018-11-09 diff --git a/EIPS/eip-1577.md b/EIPS/eip-1577.md index f73fd507eeb0c..f21066ad9f6f9 100644 --- a/EIPS/eip-1577.md +++ b/EIPS/eip-1577.md @@ -4,7 +4,7 @@ title: contenthash field for ENS author: Dean Eigenmann , Nick Johnson type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-11-13 --- diff --git a/EIPS/eip-158.md b/EIPS/eip-158.md index 6dde3019a62ef..e3008846d5235 100644 --- a/EIPS/eip-158.md +++ b/EIPS/eip-158.md @@ -6,7 +6,6 @@ type: Standards Track category: Core status: Final created: 2016-10-16 -superseded-by: 161 --- # Specification diff --git a/EIPS/eip-1581.md b/EIPS/eip-1581.md index 1c5808fc5d820..b5b3ed73fe962 100644 --- a/EIPS/eip-1581.md +++ b/EIPS/eip-1581.md @@ -1,17 +1,14 @@ --- eip: 1581 title: Non-wallet usage of keys derived from BIP-32 trees +description: A derivation path structure for BIP32 trees to generate key pairs not meant to hold crypto assets. author: Michele Balistreri (@bitgamma) discussions-to: https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817 -status: Draft +status: Review type: Standards Track category: ERC created: 2018-11-13 --- - -## Simple Summary -This EIP describes a derivation path structure for [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) wallets to be used for non-wallet key pairs. - ## Abstract BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets. diff --git a/EIPS/eip-1588.md b/EIPS/eip-1588.md index f25760a697adb..acf406231f126 100644 --- a/EIPS/eip-1588.md +++ b/EIPS/eip-1588.md @@ -2,7 +2,7 @@ eip: 1588 title: "Hardfork Meta: Ethereum ProgPoW" author: Ikmyeong Na (@naikmyeong) -status: Draft +status: Stagnant type: Meta created: 2018-11-16 requires: 1057 diff --git a/EIPS/eip-1592.md b/EIPS/eip-1592.md index 9345541329cf9..4399fe907effe 100644 --- a/EIPS/eip-1592.md +++ b/EIPS/eip-1592.md @@ -5,7 +5,7 @@ author: Cyril Lapinte , Laurent Aapro , Dror Tirosh , Alex Forshtat discussions-to: https://github.com/yoav-tabookey/EIPs/issues/1 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-11-18 diff --git a/EIPS/eip-1633.md b/EIPS/eip-1633.md index 7fddba9bbff12..d62c3f5f16250 100644 --- a/EIPS/eip-1633.md +++ b/EIPS/eip-1633.md @@ -3,7 +3,7 @@ eip: 1633 title: Re-Fungible Token Standard (RFT) author: Billy Rennekamp (@okwme), Dan Long , Kiryl Yermakou , Nate van der Ende discussions-to: https://github.com/ethereum/EIPs/issues/1634 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2018-11-18 diff --git a/EIPS/eip-1681.md b/EIPS/eip-1681.md index 28c6b2fca4a72..645809f207e33 100644 --- a/EIPS/eip-1681.md +++ b/EIPS/eip-1681.md @@ -3,7 +3,7 @@ eip: 1681 title: Temporal Replay Protection author: Martin Holst Swende (@holiman) discussions-to: https://ethereum-magicians.org/t/temporal-replay-protection/2355 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-01-08 diff --git a/EIPS/eip-1706.md b/EIPS/eip-1706.md index f7ac77a38fec8..9be30b6d94dab 100644 --- a/EIPS/eip-1706.md +++ b/EIPS/eip-1706.md @@ -4,13 +4,12 @@ title: Disable SSTORE with gasleft lower than call stipend author: Alex Forshtat , Yoav Weiss discussions-to: https://github.com/alex-forshtat-tbk/EIPs/issues/1 status: Withdrawn +withdrawal-reason: The authors prefer [EIP-2200](./eip-2200.md) type: Standards Track category: Core created: 2019-01-15 requires: 1283 -superseded-by: 2200 --- -> :information_source: **[EIP-2200] has superseded [EIP-1706].** :information_source: ## Simple Summary The proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. This proposal will make the old assumptions hold even after a network upgrade. diff --git a/EIPS/eip-1710.md b/EIPS/eip-1710.md index f18e9f5f6db77..f363cbba9fdc0 100644 --- a/EIPS/eip-1710.md +++ b/EIPS/eip-1710.md @@ -3,7 +3,7 @@ eip: 1710 title: URL Format for Web3 Browsers author: Bruno Barbieri (@brunobar79) discussions-to: https://ethereum-magicians.org/t/standarize-url-format-for-web3-browsers/2422 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-01-13 diff --git a/EIPS/eip-173.md b/EIPS/eip-173.md index bc77693e94c80..bca0622f6f0ea 100644 --- a/EIPS/eip-173.md +++ b/EIPS/eip-173.md @@ -6,7 +6,7 @@ discussions-to: https://github.com/ethereum/EIPs/issues/173 type: Standards Track category: ERC status: Last Call -review-period-end: 2020-09-06 +last-call-deadline: 2020-09-06 created: 2018-06-07 --- diff --git a/EIPS/eip-1767.md b/EIPS/eip-1767.md index 84c83bc114ca6..9118741ffd293 100644 --- a/EIPS/eip-1767.md +++ b/EIPS/eip-1767.md @@ -3,7 +3,7 @@ eip: 1767 title: GraphQL interface to Ethereum node data author: Nick Johnson (@arachnid), Raúl Kripalani (@raulk), Kris Shinn (@kshinn) discussions-to: https://ethereum-magicians.org/t/graphql-interface-to-ethereum-node-data/2710 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2019-02-14 diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 9eb79ee299c16..4e4e6800a7cba 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -3,7 +3,7 @@ eip: 1775 title: App Keys, application specific wallet accounts author: Vincent Eli (@Bunjin), Dan Finlay (@DanFinlay) discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-02-20 diff --git a/EIPS/eip-1803.md b/EIPS/eip-1803.md index 855b51242ec32..fd8db3f5d5eba 100644 --- a/EIPS/eip-1803.md +++ b/EIPS/eip-1803.md @@ -5,7 +5,7 @@ author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-1803-rename-opcodes-for-clarity/3345 type: Standards Track category: Interface -status: Draft +status: Stagnant created: 2017-07-28 requires: 141 --- diff --git a/EIPS/eip-1812.md b/EIPS/eip-1812.md index 7b496dadd2f49..c5cf8c877a24f 100644 --- a/EIPS/eip-1812.md +++ b/EIPS/eip-1812.md @@ -3,7 +3,7 @@ eip: 1812 title: Ethereum Verifiable Claims author: Pelle Braendgaard (@pelle) discussions-to: https://ethereum-magicians.org/t/erc-1812-ethereum-verifiable-claims/2814 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-03-03 diff --git a/EIPS/eip-1820.md b/EIPS/eip-1820.md index 641555ff3064e..59c5a98c78008 100644 --- a/EIPS/eip-1820.md +++ b/EIPS/eip-1820.md @@ -8,7 +8,6 @@ type: Standards Track category: ERC requires: 165, 214 created: 2019-03-04 -replaces: 820 --- > :information_source: **[ERC-1820] has superseded [ERC-820].** :information_source: diff --git a/EIPS/eip-1822.md b/EIPS/eip-1822.md index ec1f7aeb83de1..cac79fba7162e 100644 --- a/EIPS/eip-1822.md +++ b/EIPS/eip-1822.md @@ -3,7 +3,7 @@ eip: 1822 title: Universal Upgradeable Proxy Standard (UUPS) author: Gabriel Barros , Patrick Gallagher discussions-to: https://ethereum-magicians.org/t/eip-1822-universal-upgradeable-proxy-standard-uups -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-03-04 diff --git a/EIPS/eip-1829.md b/EIPS/eip-1829.md index 49e82e894b506..66a7f762a8f89 100644 --- a/EIPS/eip-1829.md +++ b/EIPS/eip-1829.md @@ -3,7 +3,7 @@ eip: 1829 title: Precompile for Elliptic Curve Linear Combinations author: Remco Bloemen discussions-to: https://ethereum-magicians.org/t/ewasm-precompile-for-general-elliptic-curve-math/2581 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-03-06 diff --git a/EIPS/eip-1844.md b/EIPS/eip-1844.md index 1245ecd5ce6f9..33d92e791a3f5 100644 --- a/EIPS/eip-1844.md +++ b/EIPS/eip-1844.md @@ -3,7 +3,7 @@ eip: 1844 title: ENS Interface Discovery author: Nick Johnson (@arachnid) discussions-to: https://ethereum-magicians.org/t/ens-interface-discovery/2924 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-03-15 diff --git a/EIPS/eip-1872.md b/EIPS/eip-1872.md index fe840d1497e49..36535369602dd 100644 --- a/EIPS/eip-1872.md +++ b/EIPS/eip-1872.md @@ -3,7 +3,7 @@ eip: 1872 title: Ethereum Network Upgrade Windows author: Danno Ferrin (@shemnon) discussions-to: https://ethereum-magicians.org/t/eip-1872-ethereum-network-upgrade-windows/2993 -status: Draft +status: Stagnant type: Meta created: 2018-03-25 --- diff --git a/EIPS/eip-1895.md b/EIPS/eip-1895.md index 60fe433aac6e0..f6b85ae00f74d 100644 --- a/EIPS/eip-1895.md +++ b/EIPS/eip-1895.md @@ -3,7 +3,7 @@ eip: 1895 title: Support for an Elliptic Curve Cycle author: Alexandre Belling discussions-to: https://ethresear.ch/t/reducing-the-verification-cost-of-a-snark-through-hierarchical-aggregation/5128 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-03-31 diff --git a/EIPS/eip-1898.md b/EIPS/eip-1898.md index 8a387deddcaae..47a2f4a13b4aa 100644 --- a/EIPS/eip-1898.md +++ b/EIPS/eip-1898.md @@ -4,7 +4,7 @@ title: Add `blockHash` to JSON-RPC methods which accept a default block paramete author: Charles Cooper (@charles-cooper) type: Standards Track category: Interface -status: Draft +status: Stagnant created: 2019-04-01 requires: 234, 1474 --- diff --git a/EIPS/eip-1900.md b/EIPS/eip-1900.md index decd47e06d7c7..a335625036559 100644 --- a/EIPS/eip-1900.md +++ b/EIPS/eip-1900.md @@ -3,7 +3,7 @@ eip: 1900 title: dType - Decentralized Type System for EVM author: Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu) discussions-to: https://github.com/ethereum/EIPs/issues/1882 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-03-28 diff --git a/EIPS/eip-1901.md b/EIPS/eip-1901.md index cb0397f944842..eb6585cfea24a 100644 --- a/EIPS/eip-1901.md +++ b/EIPS/eip-1901.md @@ -3,7 +3,7 @@ eip: 1901 title: Add OpenRPC Service Discovery To JSON-RPC Services author: Shane Jonas (@shanejonas), Zachary Belford (@belfordz) discussions-to: https://github.com/ethereum/EIPs/issues/1902 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2019-02-25 diff --git a/EIPS/eip-1921.md b/EIPS/eip-1921.md index 8c530a056e3d1..57fa9917dd179 100644 --- a/EIPS/eip-1921.md +++ b/EIPS/eip-1921.md @@ -3,7 +3,7 @@ eip: 1921 title: dType Functions Extension author: Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu) discussions-to: https://github.com/ethereum/EIPs/issues/1921 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-04-06 diff --git a/EIPS/eip-1922.md b/EIPS/eip-1922.md index aa6d0810699b2..1243272d7f99e 100644 --- a/EIPS/eip-1922.md +++ b/EIPS/eip-1922.md @@ -5,7 +5,7 @@ author: Michael Connor , Chaitanya Konda , Chaitanya Konda , pinkiebell (@pinkiebell) discussions-to: https://ethereum-magicians.org/t/erc-non-fungible-data-token/3139 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-04-18 diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index 36c9624734e1a..a50a81e09f8b7 100644 --- a/EIPS/eip-1959.md +++ b/EIPS/eip-1959.md @@ -5,7 +5,7 @@ author: Ronan Sandford (@wighawag) category: Core type: Standards Track discussions-to: https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170 -status: Draft +status: Stagnant created: 2019-04-20 requires: 155 --- diff --git a/EIPS/eip-1962.md b/EIPS/eip-1962.md index d880f2be50609..b0c7365036d4f 100644 --- a/EIPS/eip-1962.md +++ b/EIPS/eip-1962.md @@ -5,7 +5,7 @@ author: Alex Vlasov (@shamatar) discussions-to: https://ethereum-magicians.org/t/generalised-precompile-for-elliptic-curve-arithmetics-and-pairings-working-group/3208/2 type: Standards Track category: Core -status: Draft +status: Stagnant created: 2019-04-22 requires: 1109 --- diff --git a/EIPS/eip-1965.md b/EIPS/eip-1965.md index 89357acbd80f0..4c648a89ae5e2 100644 --- a/EIPS/eip-1965.md +++ b/EIPS/eip-1965.md @@ -5,7 +5,7 @@ author: Ronan Sandford (@wighawag) category: Core type: Standards Track discussions-to: https://ethereum-magicians.org/t/eip-1965-valid-chainid-for-specific-blocknumber-protect-all-forks/3181 -status: Draft +status: Stagnant created: 2019-04-20 requires: 155 --- diff --git a/EIPS/eip-1967.md b/EIPS/eip-1967.md index ecd84c76603ff..ac49a405242f5 100644 --- a/EIPS/eip-1967.md +++ b/EIPS/eip-1967.md @@ -1,6 +1,7 @@ --- eip: 1967 title: Standard Proxy Storage Slots +description: Standardise where proxies store the address of the logic contract they delegate to, as well as other proxy-specific information. author: Santiago Palladino (@spalladino) discussions-to: https://ethereum-magicians.org/t/eip-1967-standard-proxy-storage-slots/3185 status: Draft @@ -9,20 +10,17 @@ category: ERC created: 2019-04-24 --- -## Simple Summary -Standardise how proxies store the address of the logic contract they delegate to, and other proxy specific information. - ## Abstract Delegating **proxy contracts** are widely used for both upgradeability and gas savings. These proxies rely on a **logic contract** (also known as implementation contract or master copy) that is called using `delegatecall`. This allows proxies to keep a persistent state (storage and balance) while the code is delegated to the logic contract. -To avoid clashes in storage usage between the proxy and logic contract, the address of the logic contract is typically saved in a [specific storage slot](https://blog.zeppelinos.org/upgradeability-using-unstructured-storage/) guaranteed to be never allocated by a compiler. This EIP proposes a set of standard slots to store proxy information. This allows clients like block explorers to properly extract and show this information to end users, and logic contracts to optionally act upon it. +To avoid clashes in storage usage between the proxy and logic contract, the address of the logic contract is typically saved in a [specific storage slot](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/#unstructured-storage) guaranteed to be never allocated by a compiler. This EIP proposes a set of standard slots to store proxy information. This allows clients like block explorers to properly extract and show this information to end users, and logic contracts to optionally act upon it. ## Motivation -Delegating proxies are widely in use, as a means to both support upgrades and reduce gas costs of deployments. Examples of these proxies are found in [ZeppelinOS](https://blog.zeppelinos.org/the-transparent-proxy-pattern/), [Terminal](https://medium.com/terminaldotco/escape-hatch-proxy-efb681de108d), [Gnosis](https://blog.gnosis.pm/solidity-delegateproxy-contracts-e09957d0f201), [AragonOS](https://github.com/aragon/aragonOS/blob/dev/contracts/common/DelegateProxy.sol), [Melonport](https://github.com/melonproject/melon-mail/blob/782aeff9418ac8cdd80875fd6c400bf96f3b03b3/solidity/contracts/DelegateProxy.sol), [Limechain](https://github.com/LimeChain/UpgradeableSolidityContract/blob/14bcabc338130fb2aba2ce8bd27b885305566fce/contracts/Upgradeability/Forwardable.sol), [WindingTree](https://github.com/windingtree/upgradeable-token-labs/blob/af3b66096091d8282d5c9c55c33365315d85f3e1/contracts/upgradable/DelegateProxy.sol), [Decentraland](https://github.com/decentraland/land/blob/5154046844f6f94a5074e82abe01381e6fd7c39d/contracts/upgradable/DelegateProxy.sol), and many others. +Delegating proxies are widely in use, as a means to both support upgrades and reduce gas costs of deployments. Examples of these proxies are found in [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/4.x/api/proxy), [Terminal](https://medium.com/terminaldotco/escape-hatch-proxy-efb681de108d), [Gnosis](https://blog.gnosis.pm/solidity-delegateproxy-contracts-e09957d0f201), [AragonOS](https://github.com/aragon/aragonOS/blob/dev/contracts/common/DelegateProxy.sol), [Melonport](https://github.com/melonproject/melon-mail/blob/782aeff9418ac8cdd80875fd6c400bf96f3b03b3/solidity/contracts/DelegateProxy.sol), [Limechain](https://github.com/LimeChain/UpgradeableSolidityContract/blob/14bcabc338130fb2aba2ce8bd27b885305566fce/contracts/Upgradeability/Forwardable.sol), [WindingTree](https://github.com/windingtree/upgradeable-token-labs/blob/af3b66096091d8282d5c9c55c33365315d85f3e1/contracts/upgradable/DelegateProxy.sol), [Decentraland](https://github.com/decentraland/land/blob/5154046844f6f94a5074e82abe01381e6fd7c39d/contracts/upgradable/DelegateProxy.sol), and many others. However, the lack of a common interface for obtaining the logic address for a proxy makes it impossible to build common tools that act upon this information. -A classic example of this is a block explorer. Here, the end user wants to interact with the underlying logic contract and not the proxy itself. Having a common way to retrieve the logic contract address from a proxy would allow a block explorer, among other things, to show the ABI of the logic contract and not that of the proxy (see [this proxy](https://etherscan.io/token/0x00fdae9174357424a78afaad98da36fd66dd9e03#readContract) for an example). The explorer should check the storage of the contract at the distinguished slots to determine if it is indeed a proxy, in which case it should show information on both the proxy and the logic contract. +A classic example of this is a block explorer. Here, the end user wants to interact with the underlying logic contract and not the proxy itself. Having a common way to retrieve the logic contract address from a proxy allows a block explorer to show the ABI of the logic contract and not that of the proxy (see [this proxy](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#readProxyContract). The explorer checks the storage of the contract at the distinguished slots to determine if it is indeed a proxy, in which case it shows information on both the proxy and the logic contract. Another example are logic contracts that explicitly act upon the fact that they are being proxied. This allows them to potentially trigger a code update as part of their logic, as is the case of [Universal Upgradeable Proxy Standard (EIP1822)](./eip-1822.md). A common storage slot allows these use cases independently of the specific proxy implementation being used. @@ -42,7 +40,7 @@ Monitoring of proxies is essential to the security of many applications. It is t Storage slot `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` (obtained as `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)`). -Holds the address of the logic contract that this proxy delegates to. SHOULD be empty if a beacon is used instead. Changes to this slot should be notified by the event: +Holds the address of the logic contract that this proxy delegates to. SHOULD be empty if a beacon is used instead. Changes to this slot SHOULD be notified by the event: ```solidity event Upgraded(address indexed implementation); @@ -52,18 +50,32 @@ event Upgraded(address indexed implementation); Storage slot `0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50` (obtained as `bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)`). -Holds the address of the beacon contract this proxy relies on (fallback). SHOULD be empty if a logic address is used directly instead, and should only be considered if the logic contract slot is empty. See the Beacons section below. Changes to this slot should be notified by the event: +Holds the address of the beacon contract this proxy relies on (fallback). SHOULD be empty if a logic address is used directly instead, and should only be considered if the logic contract slot is empty. Changes to this slot SHOULD be notified by the event: ```solidity event BeaconUpgraded(address indexed beacon); ``` +Beacons are used for keeping the logic address for multiple proxies in a single location, allowing the upgrade of multiple proxies by modifying a single storage slot. A beacon contract MUST implement the function: + +``` +function implementation() returns (address) +``` + +Beacon based proxy contracts do not use the logic contract slot. Instead, they use the beacon contract slot to store the address of the beacon they are attached to. In order to know the logic contract used by a beacon proxy, a client SHOULD: + +- Read the address of the beacon for the beacon logic storage slot; +- Call the `implementation()` function on the beacon contract. + +The result of the `implementation()` function on the beacon contract SHOULD NOT depend on the caller (`msg.sender`). + + ### Admin address Storage slot `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103` (obtained as `bytes32(uint256(keccak256('eip1967.proxy.admin')) - 1)`). -Holds the address that is allowed to upgrade the logic contract address for this proxy (optional). Changes to this slot should be notified by the event: +Holds the address that is allowed to upgrade the logic contract address for this proxy (optional). Changes to this slot SHOULD be notified by the event: ```solidity event AdminChanged(address previousAdmin, address newAdmin); @@ -81,29 +93,310 @@ From [_Malicious backdoors in Ethereum proxies_](https://medium.com/nomic-labs-b > > Because the function selectors use a fixed amount of bytes, there will always be the possibility of a clash. This isn’t an issue for day to day development, given that the Solidity compiler will detect a selector clash within a contract, but this becomes exploitable when selectors are used for cross-contract interaction. Clashes can be abused to create a seemingly well-behaved contract that’s actually concealing a backdoor. -The fact that proxy public functions are potentially exploitable makes it necessary to standardise the logic contract address in a different way. This approach is also used as part of [Universal Upgradeable Proxy Standard (EIP1822)](./eip-1822.md), which could become a specialization of this EIP. - -## Beacons - -Some use-cases rely on multiple proxy contracts delegating their calls to the same logic contract. If each contract was to store the address of the logic contract using the logic contract storage slot, upgrading them would require writing to the corresponding storage slot of every instance, which could be very expensive in terms of gas. +The fact that proxy public functions are potentially exploitable makes it necessary to standardise the logic contract address in a different way. This approach is also used as part of [Universal Upgradeable Proxy Standard (EIP1822)](./eip-1822.md). -Another approach is to have each proxy retrieve the logic contract's address from a dedicated "beacon". Using this pattern, the address of the logic contract can be modified in the beacon and take immediate effect for all the corresponding proxy contracts. +## Reference Implementation -A beacon MUST implement the function: +A reference implementation for this standard can be found in the [OpenZeppelin Contracts repository](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.3.0/contracts/proxy/ERC1967/ERC1967Proxy.sol). -``` -function implementation() returns (address) +```solidity +/** + * @dev This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an + * implementation address that can be changed. This address is stored in storage in the location specified by + * https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the + * implementation behind the proxy. + */ +contract ERC1967Proxy is Proxy, ERC1967Upgrade { + /** + * @dev Initializes the upgradeable proxy with an initial implementation specified by `_logic`. + * + * If `_data` is nonempty, it's used as data in a delegate call to `_logic`. This will typically be an encoded + * function call, and allows initializating the storage of the proxy like a Solidity constructor. + */ + constructor(address _logic, bytes memory _data) payable { + assert(_IMPLEMENTATION_SLOT == bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1)); + _upgradeToAndCall(_logic, _data, false); + } + + /** + * @dev Returns the current implementation address. + */ + function _implementation() internal view virtual override returns (address impl) { + return ERC1967Upgrade._getImplementation(); + } +} + +/** + * @dev This abstract contract provides getters and event emitting update functions for + * https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots. + */ +abstract contract ERC1967Upgrade { + // This is the keccak-256 hash of "eip1967.proxy.rollback" subtracted by 1 + bytes32 private constant _ROLLBACK_SLOT = 0x4910fdfa16fed3260ed0e7147f7cc6da11a60208b5b9406d12a635614ffd9143; + + /** + * @dev Storage slot with the address of the current implementation. + * This is the keccak-256 hash of "eip1967.proxy.implementation" subtracted by 1, and is + * validated in the constructor. + */ + bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc; + + /** + * @dev Emitted when the implementation is upgraded. + */ + event Upgraded(address indexed implementation); + + /** + * @dev Returns the current implementation address. + */ + function _getImplementation() internal view returns (address) { + return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value; + } + + /** + * @dev Stores a new address in the EIP1967 implementation slot. + */ + function _setImplementation(address newImplementation) private { + require(Address.isContract(newImplementation), "ERC1967: new implementation is not a contract"); + StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation; + } + + /** + * @dev Perform implementation upgrade + * + * Emits an {Upgraded} event. + */ + function _upgradeTo(address newImplementation) internal { + _setImplementation(newImplementation); + emit Upgraded(newImplementation); + } + + /** + * @dev Perform implementation upgrade with additional setup call. + * + * Emits an {Upgraded} event. + */ + function _upgradeToAndCall( + address newImplementation, + bytes memory data, + bool forceCall + ) internal { + _upgradeTo(newImplementation); + if (data.length > 0 || forceCall) { + Address.functionDelegateCall(newImplementation, data); + } + } + + /** + * @dev Perform implementation upgrade with security checks for UUPS proxies, and additional setup call. + * + * Emits an {Upgraded} event. + */ + function _upgradeToAndCallSecure( + address newImplementation, + bytes memory data, + bool forceCall + ) internal { + address oldImplementation = _getImplementation(); + + // Initial upgrade and setup call + _setImplementation(newImplementation); + if (data.length > 0 || forceCall) { + Address.functionDelegateCall(newImplementation, data); + } + + // Perform rollback test if not already in progress + StorageSlot.BooleanSlot storage rollbackTesting = StorageSlot.getBooleanSlot(_ROLLBACK_SLOT); + if (!rollbackTesting.value) { + // Trigger rollback using upgradeTo from the new implementation + rollbackTesting.value = true; + Address.functionDelegateCall( + newImplementation, + abi.encodeWithSignature("upgradeTo(address)", oldImplementation) + ); + rollbackTesting.value = false; + // Check rollback was effective + require(oldImplementation == _getImplementation(), "ERC1967Upgrade: upgrade breaks further upgrades"); + // Finally reset to the new implementation and log the upgrade + _upgradeTo(newImplementation); + } + } + + /** + * @dev Storage slot with the admin of the contract. + * This is the keccak-256 hash of "eip1967.proxy.admin" subtracted by 1, and is + * validated in the constructor. + */ + bytes32 internal constant _ADMIN_SLOT = 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103; + + /** + * @dev Emitted when the admin account has changed. + */ + event AdminChanged(address previousAdmin, address newAdmin); + + /** + * @dev Returns the current admin. + */ + function _getAdmin() internal view returns (address) { + return StorageSlot.getAddressSlot(_ADMIN_SLOT).value; + } + + /** + * @dev Stores a new address in the EIP1967 admin slot. + */ + function _setAdmin(address newAdmin) private { + require(newAdmin != address(0), "ERC1967: new admin is the zero address"); + StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin; + } + + /** + * @dev Changes the admin of the proxy. + * + * Emits an {AdminChanged} event. + */ + function _changeAdmin(address newAdmin) internal { + emit AdminChanged(_getAdmin(), newAdmin); + _setAdmin(newAdmin); + } + + /** + * @dev The storage slot of the UpgradeableBeacon contract which defines the implementation for this proxy. + * This is bytes32(uint256(keccak256('eip1967.proxy.beacon')) - 1)) and is validated in the constructor. + */ + bytes32 internal constant _BEACON_SLOT = 0xa3f0ad74e5423aebfd80d3ef4346578335a9a72aeaee59ff6cb3582b35133d50; + + /** + * @dev Emitted when the beacon is upgraded. + */ + event BeaconUpgraded(address indexed beacon); + + /** + * @dev Returns the current beacon. + */ + function _getBeacon() internal view returns (address) { + return StorageSlot.getAddressSlot(_BEACON_SLOT).value; + } + + /** + * @dev Stores a new beacon in the EIP1967 beacon slot. + */ + function _setBeacon(address newBeacon) private { + require(Address.isContract(newBeacon), "ERC1967: new beacon is not a contract"); + require( + Address.isContract(IBeacon(newBeacon).implementation()), + "ERC1967: beacon implementation is not a contract" + ); + StorageSlot.getAddressSlot(_BEACON_SLOT).value = newBeacon; + } + + /** + * @dev Perform beacon upgrade with additional setup call. Note: This upgrades the address of the beacon, it does + * not upgrade the implementation contained in the beacon (see {UpgradeableBeacon-_setImplementation} for that). + * + * Emits a {BeaconUpgraded} event. + */ + function _upgradeBeaconToAndCall( + address newBeacon, + bytes memory data, + bool forceCall + ) internal { + _setBeacon(newBeacon); + emit BeaconUpgraded(newBeacon); + if (data.length > 0 || forceCall) { + Address.functionDelegateCall(IBeacon(newBeacon).implementation(), data); + } + } +} + +/** + * @dev This abstract contract provides a fallback function that delegates all calls to another contract using the EVM + * instruction `delegatecall`. We refer to the second contract as the _implementation_ behind the proxy, and it has to + * be specified by overriding the virtual {_implementation} function. + * + * Additionally, delegation to the implementation can be triggered manually through the {_fallback} function, or to a + * different contract through the {_delegate} function. + * + * The success and return data of the delegated call will be returned back to the caller of the proxy. + */ +abstract contract Proxy { + /** + * @dev Delegates the current call to `implementation`. + * + * This function does not return to its internal call site, it will return directly to the external caller. + */ + function _delegate(address implementation) internal virtual { + assembly { + // Copy msg.data. We take full control of memory in this inline assembly + // block because it will not return to Solidity code. We overwrite the + // Solidity scratch pad at memory position 0. + calldatacopy(0, 0, calldatasize()) + + // Call the implementation. + // out and outsize are 0 because we don't know the size yet. + let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0) + + // Copy the returned data. + returndatacopy(0, 0, returndatasize()) + + switch result + // delegatecall returns 0 on error. + case 0 { + revert(0, returndatasize()) + } + default { + return(0, returndatasize()) + } + } + } + + /** + * @dev This is a virtual function that should be overridden so it returns the address to which the fallback function + * and {_fallback} should delegate. + */ + function _implementation() internal view virtual returns (address); + + /** + * @dev Delegates the current call to the address returned by `_implementation()`. + * + * This function does not return to its internal call site, it will return directly to the external caller. + */ + function _fallback() internal virtual { + _beforeFallback(); + _delegate(_implementation()); + } + + /** + * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if no other + * function in the contract matches the call data. + */ + fallback() external payable virtual { + _fallback(); + } + + /** + * @dev Fallback function that delegates calls to the address returned by `_implementation()`. Will run if call data + * is empty. + */ + receive() external payable virtual { + _fallback(); + } + + /** + * @dev Hook that is called before falling back to the implementation. Can happen as part of a manual `_fallback` + * call, or as part of the Solidity `fallback` or `receive` functions. + * + * If overridden should call `super._beforeFallback()`. + */ + function _beforeFallback() internal virtual {} +} ``` -Beacon based proxy contracts do not use the logic contract slot. Instead, they use the beacon contract slot to store the address of the beacon they are attached to. In order to know the logic contract used by a beacon proxy, one should: +## Security Considerations -- Read the address of the beacon for the beacon logic storage slot; -- Call the `implementation()` function on the beacon contract. +This ERC relies on the fact that the chosen storage slots are **not** to be allocated by the solidity compiler. This guarantees that an implementation contract will not accidentally overwrite any of the information required for the proxy to operate. As such, locations with a high slot number were chosen to avoid clashes with the slots allocated by the compiler. Also, locations with no known preimage were picked, to ensure that a write to mapping with a maliciously crafted key could not overwrite it. -The result of the `implementation()` function on the beacon contract SHOULD NOT depend on the caller (`msg.sender`). - -## Implementation -Sample proxy implementations that follow this standard can be found in the [ZeppelinOS repository](https://github.com/zeppelinos/zos/blob/dc9e4ed/packages/lib/contracts/upgradeability/BaseUpgradeabilityProxy.sol), albeit with a different set of slots. +Logic contracts that intend to modify proxy-specific information must do so deliberately (as is the case with UUPS) by writing to the specific storage slot. ## Copyright + Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-1973.md b/EIPS/eip-1973.md index 1f64ae0f35888..d3c94b9bf0850 100644 --- a/EIPS/eip-1973.md +++ b/EIPS/eip-1973.md @@ -4,7 +4,7 @@ title: Scalable Rewards author: Lee Raj (@lerajk), Qin Jian (@qinjian) type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2019-04-01 --- diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index f3f713ff81c7c..3436077dc45ed 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -3,7 +3,7 @@ eip: 1985 title: Sane limits for certain EVM parameters author: Alex Beregszaszi (@axic), Paweł Bylica (@chfast) discussions-to: https://ethereum-magicians.org/t/eip-1985-sane-limits-for-certain-evm-parameters/3224 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-08-01 diff --git a/EIPS/eip-1996.md b/EIPS/eip-1996.md index 8043fa5c816e3..c5fcfffbed9b7 100644 --- a/EIPS/eip-1996.md +++ b/EIPS/eip-1996.md @@ -3,7 +3,7 @@ eip: 1996 title: Holdable Token author: Julio Faura , Fernando Paris , Daniel Lehrner discussions-to: https://github.com/ethereum/EIPs/issues/2103 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-04-10 diff --git a/EIPS/eip-2003.md b/EIPS/eip-2003.md index d8b81488ee0ac..63128713215ca 100644 --- a/EIPS/eip-2003.md +++ b/EIPS/eip-2003.md @@ -3,7 +3,7 @@ eip: 2003 title: EVMC modules for implementations of precompiled contracts author: Paweł Bylica (@chfast), Alex Beregszaszi (@axic) discussions-to: https://github.com/ethereum/evmc/issues/259 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2019-05-09 diff --git a/EIPS/eip-2009.md b/EIPS/eip-2009.md index 31ddc0a2fdd02..304d13320122f 100644 --- a/EIPS/eip-2009.md +++ b/EIPS/eip-2009.md @@ -3,7 +3,7 @@ eip: 2009 title: Compliance Service author: Daniel Lehrner discussions-to: https://github.com/ethereum/EIPs/issues/2022 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-05-09 diff --git a/EIPS/eip-2014.md b/EIPS/eip-2014.md index ee8df44a72a14..16ec192c2511a 100644 --- a/EIPS/eip-2014.md +++ b/EIPS/eip-2014.md @@ -3,7 +3,7 @@ eip: 2014 title: Extended State Oracle author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2014-extended-state-oracle/3301 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-10 diff --git a/EIPS/eip-2015.md b/EIPS/eip-2015.md index e57fc49ffbf74..49060b7884d25 100644 --- a/EIPS/eip-2015.md +++ b/EIPS/eip-2015.md @@ -3,7 +3,7 @@ eip: 2015 title: Wallet Update Ethereum Chain RPC Method (`wallet_updateEthereumChain`) author: Pedro Gomes (@pedrouid), Erik Marks (@rekmarks) discussions-to: https://ethereum-magicians.org/t/eip-2015-wallet-update-chain-json-rpc-method-wallet-updatechain/3274 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2019-05-12 diff --git a/EIPS/eip-2018.md b/EIPS/eip-2018.md index ec98a67609848..f6fe567cbc9aa 100644 --- a/EIPS/eip-2018.md +++ b/EIPS/eip-2018.md @@ -3,7 +3,7 @@ eip: 2018 title: Clearable Token author: Julio Faura , Fernando Paris , Daniel Lehrner discussions-to: https://github.com/ethereum/EIPs/issues/2104 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-04-30 diff --git a/EIPS/eip-2019.md b/EIPS/eip-2019.md index 152bec120528e..ab76cf3e503b3 100644 --- a/EIPS/eip-2019.md +++ b/EIPS/eip-2019.md @@ -3,7 +3,7 @@ eip: 2019 title: Fundable Token author: Fernando Paris , Julio Faura , Daniel Lehrner discussions-to: https://github.com/ethereum/EIPs/issues/2105 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-05-10 diff --git a/EIPS/eip-2020.md b/EIPS/eip-2020.md index 24dbf6bcf5961..5bccb336ed914 100644 --- a/EIPS/eip-2020.md +++ b/EIPS/eip-2020.md @@ -3,7 +3,7 @@ eip: 2020 title: E-Money Standard Token author: Julio Faura , Fernando Paris , Daniel Lehrner discussions-to: https://github.com/ethereum/EIPs/issues/2407 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-05-10 diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index f8e43fcc424f4..62e097b9f7091 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -3,7 +3,7 @@ eip: 2021 title: Payoutable Token author: Fernando Paris , Julio Faura , Daniel Lehrner discussions-to: https://github.com/ethereum/EIPs/issues/2106 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-05-10 diff --git a/EIPS/eip-2026.md b/EIPS/eip-2026.md index cc26677dc46dc..0be5fc7fe74d0 100644 --- a/EIPS/eip-2026.md +++ b/EIPS/eip-2026.md @@ -3,7 +3,7 @@ eip: 2026 title: State Rent H - Fixed Prepayment for accounts author: Alexey Akhunov (@AlexeyAkhunov) discussions-to: https://ethereum-magicians.org/t/eip-2026-fixed-rent-prepayment-for-all-accounts-change-h-from-state-rent-v3-proposal/3273 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-14 diff --git a/EIPS/eip-2027.md b/EIPS/eip-2027.md index e09f93cf7b0ad..f77488138a317 100644 --- a/EIPS/eip-2027.md +++ b/EIPS/eip-2027.md @@ -3,7 +3,7 @@ eip: 2027 title: State Rent C - Net contract size accounting author: Alexey Akhunov (@AlexeyAkhunov) discussions-to: https://ethereum-magicians.org/t/eip-2027-net-contract-size-accounting-change-c-from-state-rent-v3-proposal/3275 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-14 diff --git a/EIPS/eip-2029.md b/EIPS/eip-2029.md index b6da59d61756d..92d855829df69 100644 --- a/EIPS/eip-2029.md +++ b/EIPS/eip-2029.md @@ -3,7 +3,7 @@ eip: 2029 title: State Rent A - State counters contract author: Alexey Akhunov (@AlexeyAkhunov) discussions-to: https://ethereum-magicians.org/t/eip-2029-state-counters-contract-change-a-from-state-rent-v3-proposal/3279 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-15 diff --git a/EIPS/eip-2031.md b/EIPS/eip-2031.md index 40de135a8f550..2f313e678b743 100644 --- a/EIPS/eip-2031.md +++ b/EIPS/eip-2031.md @@ -3,7 +3,7 @@ eip: 2031 title: State Rent B - Net transaction counter author: Alexey Akhunov (@AlexeyAkhunov) discussions-to: https://ethereum-magicians.org/t/eip-2031-net-transaction-counter-change-b-from-state-rent-v3-proposal/3283 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-15 diff --git a/EIPS/eip-2035.md b/EIPS/eip-2035.md index 81e469ad61f69..2678631109fe8 100644 --- a/EIPS/eip-2035.md +++ b/EIPS/eip-2035.md @@ -3,7 +3,7 @@ eip: 2035 title: Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs author: Alexey Akhunov (@AlexeyAkhunov) discussions-to: https://ethereum-magicians.org/t/eip-2035-stateless-clients-repricing-sload-and-sstore-to-pay-for-block-proofs/3284 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-16 diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index 1b907af472bf6..9f16a42e935dc 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -3,7 +3,7 @@ eip: 2045 title: Particle gas costs for EVM opcodes author: Casey Detrio (@cdetrio), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2045-fractional-gas-costs/3311 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-17 diff --git a/EIPS/eip-2046.md b/EIPS/eip-2046.md index 00d3644ca58b4..72ec7675cbcfa 100644 --- a/EIPS/eip-2046.md +++ b/EIPS/eip-2046.md @@ -3,7 +3,7 @@ eip: 2046 title: Reduced gas cost for static calls made to precompiles author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2046-reduced-gas-cost-for-static-calls-made-to-precompiles/3291 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-05-17 diff --git a/EIPS/eip-205.md b/EIPS/eip-205.md index e4753a3ef6504..c622171e33109 100644 --- a/EIPS/eip-205.md +++ b/EIPS/eip-205.md @@ -4,7 +4,7 @@ title: ENS support for contract ABIs author: Nick Johnson type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2017-02-06 requires: 137, 181 --- diff --git a/EIPS/eip-2069.md b/EIPS/eip-2069.md index c8e53d48cb5bc..3075f63cd628b 100644 --- a/EIPS/eip-2069.md +++ b/EIPS/eip-2069.md @@ -3,7 +3,7 @@ eip: 2069 title: Recommendation for using YAML ABI in ERCs/EIPs author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2069-recommendation-for-using-yaml-abi-in-specifications/3347 -status: Draft +status: Stagnant type: Informational created: 2017-02-11 --- diff --git a/EIPS/eip-2070.md b/EIPS/eip-2070.md index 66bcbb7da95fd..b0eff5cdb0cb9 100644 --- a/EIPS/eip-2070.md +++ b/EIPS/eip-2070.md @@ -4,7 +4,7 @@ title: "Hardfork Meta: Berlin" author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/hardfork-meta-eip-2070-berlin-discussion/3561 type: Meta -status: Draft +status: Stagnant created: 2019-05-20 requires: 1679 --- diff --git a/EIPS/eip-210.md b/EIPS/eip-210.md index abba50af202e5..ecb4e37fd6e7d 100644 --- a/EIPS/eip-210.md +++ b/EIPS/eip-210.md @@ -4,7 +4,7 @@ title: Blockhash refactoring author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core -status: Draft +status: Stagnant created: 2017-02-10 --- diff --git a/EIPS/eip-211.md b/EIPS/eip-211.md index 6e05501759231..5f8dc4b37d968 100644 --- a/EIPS/eip-211.md +++ b/EIPS/eip-211.md @@ -6,7 +6,6 @@ type: Standards Track category: Core status: Final created: 2017-02-13 -replaces: 5 --- ## Simple Summary diff --git a/EIPS/eip-2135.md b/EIPS/eip-2135.md index 970cae1b198ae..2ee95be9db0b4 100644 --- a/EIPS/eip-2135.md +++ b/EIPS/eip-2135.md @@ -26,14 +26,15 @@ The standard will mainly contain the following interface. ### The required interface ```solidity -pragma solidity ^0.5.8; +pragma solidity >=0.7.0 <0.9.0; + +interface EIP2135 { -contract EIP2135 { // The main consume function - function consume(uint256 assetId) public returns(bool success); + function consume(uint256 _assetId) external returns(bool _success); // The interface to check whether an asset is consumable. - function isConsumable(uint256 assetId) public view returns (bool consumable); + function isConsumable(uint256 _assetId) external view returns (bool _consumable); // The interface to check whether an asset is consumable. event OnConsumption(uint256 indexed assetId); diff --git a/EIPS/eip-2157.md b/EIPS/eip-2157.md index 699c34ba95617..13b1e6db3dae5 100644 --- a/EIPS/eip-2157.md +++ b/EIPS/eip-2157.md @@ -3,7 +3,7 @@ eip: 2157 title: dType Storage Extension - Decentralized Type System for EVM author: Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu) discussions-to: https://github.com/ethereum/EIPs/issues/2157 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-06-28 diff --git a/EIPS/eip-2193.md b/EIPS/eip-2193.md index 1d65946b60670..d809d759b30a3 100644 --- a/EIPS/eip-2193.md +++ b/EIPS/eip-2193.md @@ -3,7 +3,7 @@ eip: 2193 title: dType Alias Extension - Decentralized Type System author: Loredana Cirstea (@loredanacirstea), Christian Tzurcanu (@ctzurcanu) discussions-to: https://github.com/ethereum/EIPs/issues/2192 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-07-16 diff --git a/EIPS/eip-2242.md b/EIPS/eip-2242.md index 4be7be2946e0e..cd4666e4afb3f 100644 --- a/EIPS/eip-2242.md +++ b/EIPS/eip-2242.md @@ -3,7 +3,7 @@ eip: 2242 title: Transaction Postdata author: John Adler (@adlerjohn) discussions-to: https://ethereum-magicians.org/t/eip-2242-transaction-postdata/3557 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-08-16 diff --git a/EIPS/eip-2256.md b/EIPS/eip-2256.md index fcdeb3da52ad7..3ffb54a97441b 100644 --- a/EIPS/eip-2256.md +++ b/EIPS/eip-2256.md @@ -3,7 +3,7 @@ eip: 2256 title: wallet_getOwnedAssets JSON-RPC Method author: Loredana Cirstea (@loredanacirstea) discussions-to: https://ethereum-magicians.org/t/eip-2256-add-wallet-getownedassets-json-rpc-method/3600 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2019-08-29 diff --git a/EIPS/eip-2266.md b/EIPS/eip-2266.md index 0371bfbab5c3e..d2d9702bc25e8 100644 --- a/EIPS/eip-2266.md +++ b/EIPS/eip-2266.md @@ -7,7 +7,7 @@ status: Last Call type: Standards Track category: ERC created: 2019-08-17 -review-period-end: 2020-12-31 +last-call-deadline: 2020-12-31 --- ## Simple Summary diff --git a/EIPS/eip-2304.md b/EIPS/eip-2304.md index 53b98763d4e71..e43ede69e3115 100644 --- a/EIPS/eip-2304.md +++ b/EIPS/eip-2304.md @@ -4,7 +4,7 @@ title: Multichain address resolution for ENS author: Nick Johnson type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2019-09-09 discussions-to: https://discuss.ens.domains/t/new-standard-proposal-ens-multicoin-support/1148 requires: 137 diff --git a/EIPS/eip-2309.md b/EIPS/eip-2309.md index 8cccb4af9447a..7ff00538ed508 100644 --- a/EIPS/eip-2309.md +++ b/EIPS/eip-2309.md @@ -20,7 +20,7 @@ The optional ERC-721 Consecutive Transfer Extension provides a standardized even ## Motivation -This extension provides even more scalibility of the [ERC-721 specification](./eip-721.md). It is possible to create, transfer, and burn 2^255 non-fungible tokens in one transaction. However, it is not possible to emit that many `Transfer` events in one transaction. The `Transfer` event is part of the original specification which states: +This extension provides even more scalibility of the [ERC-721 specification](./eip-721.md). It is possible to create, transfer, and burn 2^256 non-fungible tokens in one transaction. However, it is not possible to emit that many `Transfer` events in one transaction. The `Transfer` event is part of the original specification which states: > This emits when ownership of any NFT changes by any mechanism. > This event emits when NFTs are created (`from` == 0) and destroyed @@ -84,7 +84,7 @@ The `ConsecutiveTransfer` event can be used for a single token as well as many t ## Rationale -Standardizing the `ConsecutiveTransfer` event gives decentralized platforms a standard way of determining ownership of large quantities of non-fungible tokens without the need to support a new token standard. There are many ways in which the batch creation and transfer of NFTs can be implemented. The Consecutive Transfer Extension allows contract creators to implement batch creation, transfer, and burn methods however they see fit, but provides a standardized event in which all implementations can use. By specifying a range of consecutive token identifiers we can easily cover the transfer, or creation of 2^(255) tokens and decentralized platforms can react accordingly. +Standardizing the `ConsecutiveTransfer` event gives decentralized platforms a standard way of determining ownership of large quantities of non-fungible tokens without the need to support a new token standard. There are many ways in which the batch creation and transfer of NFTs can be implemented. The Consecutive Transfer Extension allows contract creators to implement batch creation, transfer, and burn methods however they see fit, but provides a standardized event in which all implementations can use. By specifying a range of consecutive token identifiers we can easily cover the transfer, or creation of 2^(256) tokens and decentralized platforms can react accordingly. Take this example. I sell magical fruit and have a farm with 10,000 magical fruit trees each with different fruit and 1,000 new trees every few years. I want to turn each tree into a non-fungible token that people can own. Each person that owns one of my non-fungible tree tokens will receive a quarterly percentage of each harvest from that tree. The problem is that I would need to create and transfer each of these tokens individually - which will cost me a lot of time and money and frankly would keep me from doing this. diff --git a/EIPS/eip-2315.md b/EIPS/eip-2315.md index 993ff477f1f80..1724bb377486a 100644 --- a/EIPS/eip-2315.md +++ b/EIPS/eip-2315.md @@ -4,22 +4,25 @@ title: Simple Subroutines for the EVM status: Draft type: Standards Track category: Core -author: Greg Colvin , Martin Holst Swende (@holiman) +author: Greg Colvin , Martin Holst Swende (@holiman), Brooklyn Zelenka (@expede) discussions-to: https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm/3941 created: 2019-10-17 +requires: 3540, 3670 --- ## Abstract -This proposal introduces five opcodes to better support simple subroutines and relative jumps: `BEGINSUB`, `JUMPSUB` `RETURNSUB`, `JUMPR` and `JUMPRI`. +This proposal introduces five opcodes to support simple subroutines and relative jumps: `JUMPSUB`, `RETURNSUB`, `RJUMP`, `RJUMPI`, and `RJUMPV`. -This change supports substantial reductions in the gas costs of calling and optimizing simple subroutines – from %33 to as much as 54%. +These provide a safe, complete, static control-flow facility that supports substantial reductions in the complexity and the gas costs of calling and optimizing simple subroutines – from %33 to as much as 52% savings in gas. + +Valid contracts will not halt with an exception unless they run out of gas or overflow stack while making a recursive subroutine call. ## Motivation -The EVM does not provide subroutines as a primitive. Instead, calls can be synthesized by fetching and pushing the current program counter on the data stack and jumping to the subroutine address; returns can be synthesized by getting the return address to the top of the stack and jumping back to it. These conventions are more costly than necessary. +The EVM does not provide subroutines as a primitive. Instead, calls can be synthesized by fetching and pushing the current program counter on the data stack and jumping to the subroutine address; returns can be synthesized by getting the return address to the top of the stack and jumping back to it. These conventions create unnecessary cost and complexity that is borne by the humans and programs writing, reading, and analyzing EVM code, -Facilities to directly support subroutines are provided by all but one of the real and virtual machines programmed by the lead author, including the Burroughs 5000, CDC 7600, IBM 360, DEC PDP 11 and VAX, Motorola 68000, a few generations of Intel silicon, Sun SPARC, UCSD p-Machine, Sun JVM, Wasm, and the sole exception the EVM. In whatever form, these operations provide for +Facilities to directly support subroutines are provided by all but one of the real and virtual machines programmed by the lead author, including the Burroughs 5000, CDC 7600, IBM 360, DEC PDP 11 and VAX, Motorola 68000, a few generations of Intel silicon, Sun SPARC, UCSD p-Machine, Sun JVM, Wasm, and the sole exception -- the EVM. In whatever form, these operations provide for * capturing the current context of execution, * transferring control to a new context, and * returning to the original context @@ -31,7 +34,147 @@ The concept goes back to [Turing, 1946](http://www.alanturing.net/turing_archive > ... > When we wish to start on a subsidiary operation we need only make a note of where we left off the major operation and then apply the first instruction of the subsidiary. When the subsidiary is over we look up the note and continue with the major operation. Each subsidiary operation can end with instructions for this recovery of the note. How is the burying and disinterring of the note to be done? There are of course many ways. One is to keep a list of these notes in one or more standard size delay lines, (1024) with the most recent last. The position of the most recent of these will be kept in a fixed TS, and this reference will be modified every time a subsidiary is started or finished... -We propose to follow Turing's simple concept in our subroutine design, as specified below. Note that this specification is entirely semantic. It constrains only stack usage and control flow and imposes no syntax on code beyond being a sequence of bytes to be executed. +We propose to follow Turing's simple concept in our subroutine design, as specified below. And we propose to validate the safe use of facility, so that valid contracts will not halt with an exception unless they run out of gas or overflow stack while making a recursive subroutine call. + +### Gas Cost Analysis + +We show here how these opcodes can be used to reduce the gas costs of both ordinary subroutine calls and low-level optimizations. The savings reported here will of course be less relevant to programs that use a few large subroutines rather than being a factored than into smaller ones. The choices of gas costs for the new opcodes below do not make a large difference in this analysis, as much of the improvement is due to PUSH and SWAP operations that are no longer needed. Even if `JUMPSUB` cost the same as `JUMP` – 8 gas rather than 5 - a simple subroutine call would still be 48% less costly versus 52%. + +#### **Simple Subroutine Call** + +Consider this example of calling a fairly minimal subroutine +using `JUMPSUB` + +Subroutine call, using `JUMPSUB` +``` +TEST_SQUARE: + jumpdest ; 1 gas + 0x02 ; 3 gas + jumpsub SQUARE ; 5 gas + returnsub ; 3 gas + +SQUARE: + jumpdest ; 1 gas + dup1 ; 3 gas + mul ; 5 gas + returnsub ; 3 gas + +Total 24 gas. +``` +Subroutine call, using `JUMP` +``` +TEST_SQUARE: + jumpdest ; 1 gas + RTN_SQUARE ; 3 gas + 0x02 ; 3 gas + SQUARE ; 3 gas + jump ; 8 gas +RTN_SQUARE: + jumpdest ; 1 gas + swap1 ; 3 gas + jump ; 8 gas + +SQUARE: + jumpdest ; 1 gas + dup1 ; 3 gas + mul ; 5 gas + swap1 ; 3 gas + jump ; 8 gas + +Total: 50 gas +``` +Using `JUMPSUB` saves *50 - 24 = 26* gas versus using `JUMP` -- a *52%* performance improvement. + +#### **Tail Call Optimization** + +Of course in cases like this one we can optimize the tail call, so that the return from `SQUARE` actually returns from TEST_SQUARE. + +Tail call optimization, using `RJUMP` and `RETURNSUB`. +``` +TEST_SQUARE: + jumpdest ; 1 gas + 0x02 ; 3 gas + rjump SQUARE ; 3 gas + +SQUARE: + jumpdest ; 1 gas + dup1 ; 3 gas + mul ; 5 gas + returnsub ; 3 gas + +Total: 19 gas +``` +Tail call optimization, using `JUMP` +``` +TEST_SQUARE: + jumpdest ; 1 gas + 0x02 ; 3 gas + SQUARE ; 3 gas + jump ; 8 gas + +SQUARE: + jumpdest ; 1 gas + dup1 ; 3 gas + mul ; 5 gas + swap1 ; 3 gas + jump ; 8 gas + +Total: 33 gas +``` +Using `JUMPSUB` versus `JUMP` saves *33 - 19 = 14* gas -- a *42%* performance improvement. + +So we can see that these instructions provide a simpler and more efficient subroutine mechanism than dynamic jumps. + +#### **Tail Call Elimination** + +We can even take advantage of `SQUARE` just happening to directly follow `TEST_SQUARE` and just fall through rather than jump at all. + +Tail call `elimination`, using JUMPSUB. +``` +TEST_SQUARE: + jumpdest ; 1 gas + 0x02 ; 3 gas +SQUARE: + jumpdest ; 1 gas + dup1 ; 3 gas + mul ; 5 gas + returnsub ; 3 gas + +Total 16 gas. +``` +Tail call elimination, using JUMP. +``` +TEST_SQUARE: + jumpdest ; 1 gas + 0x02 ; 3 gas +SQUARE: + jumpdest ; 1 gas + dup1 ; 3 gas + mul ; 5 gas + swap1 ; 3 gas + jump ; 8 gas + +Total: 24 gas +``` +Using `RETURNSUB` versus `JUMP` saves _24 - 16 = 8_ gas -- a *33%* performance improvement. + +We can also consider the alternative subroutine call, using a version of `JUMPSUB` that pushes its return address on the stack. +``` +TEST_SQUARE: + jumpdest ; 1 gas + 0x02 ; 3 gas + jumpsub SQUARE ; 5 gas + swap1 ; 3 gas + returnsub ; 3 gas + +SQUARE: + jumpdest ; 1 gas + dup1 ; 3 gas + mul ; 5 gas + swap1 ; 3 gas + returnsub ; 3 gas +``` +Total *31* gas, compared to *24* gas for the return stack version. ## Specification @@ -39,226 +182,113 @@ We introduce one more stack into the EVM in addition to the existing `data stack ### Instructions -#### `BEGINSUB( 0x5c)` - -> Marks an entry point to a subroutine. Execution of a `BEGINSUB` is a no-op. The cost is _jumpdest_. - -#### `JUMPSUB (0x5d) location` +#### `JUMPSUB (0x5e) location` > Transfers control to a subroutine. > > 1. Decode the `location` from the immediate data. The data is encoded as three bytes, MSB-first. -> 2. If the opcode at `location` is not a `BEGINSUB` _`abort`_. -> 3. If the `return stack` already has `1024` items _`abort`_. -> 4. Push the current `PC + 1` to the `return stack`. -> 5. Set `PC` to `location`. +> 2. Set `PC` to `location`. > > The cost is _low_. > > * _pops one item off the `data stack`_ > * _pushes one item on the `return stack`_ -#### `RETURNSUB (0x5e)` +#### `RETURNSUB (0x5f)` > Returns control to the caller of a subroutine. > -> 1. If the `return stack` is empty _`abort`_. -> 2. Pop `PC` off the `return stack`. +> 1. Pop `PC` off the `return stack`. > > The cost is _verylow_. > > * _pops one item off the `return stack`_ -To take full advantage of the performance benefits of simple subroutines we also provide two new static, relative jump functions that take their arguments as immediate data rather then off the stack. +To provide a complete set of control structures, and to take full advantage of the performance benefits of simple subroutines we also provide two static, relative jump functions that take their arguments as immediate data rather then off the stack. -#### `JUMPR (0x??) offset` +#### `RJUMP (0x5c) offset` -> Transfers control to the address `PC + offset`, where offset is a three-byte, MSB first, twos-complement integer. +> Transfers control to the address `PC + offset`, where `offset` is a two-byte, MSB first, twos-complement integer. > -> 1. Decode the `offset` from the immediate data. The data is encoded as three bytes, MSB first, twos-complement. -> 2. If the opcode at `location` is not a `JUMDEST` then _`abort`_. -> 5. Set `PC` to `location`. +> 1. Decode the `offset` from the immediate data. The data is encoded as a two-byte, MSB first, twos-complement integer. +> 2. Set `PC` to `location`. > > The cost is _low_. -#### `JUMPRI (0x??) offset` +#### `RJUMPI (0x5d) offset` -> Conditionally transfers control to the address `PC + offset`, where offset is a three-byte, MSB first, twos-complement integer. -> 1. Decode the `offset` from the immediate data. The data is encoded as three bytes, MSB first, twos-complement. +> Conditionally transfers control to the address `PC + offset`, where offset is a two byte, MSB first, twos-complement integer. +> 1. Decode the `offset` from the immediate data. The data is encoded as a two-byte, MSB first, twos-complement integer. > 2. Pop the `condition` from the stack. > 3. If the condition is true then continue -> 4. If the opcode at `PC + offset` is not a `JUMDEST` _`abort`_. -> Set `PC` to `PC + offset`. +> 4. Set `PC` to `PC + offset`. > > The cost is _mid_. +#### `RJUMPV (0x5e) n offset ...` + +> Transfers control to the address at `SP[0] + PC + 2 + offset`; or else to the default address, where `n` and `offset` are two-byte, MSB first, twos-complement integers. +> 2. Pop `n` from the stack. +> 1. Decode the `count` from the immediate data. The data is encoded as two-byte, MSB first, twos-complement. +> 4. `if (n < count) PC = PC[2 + 2*n] else PC = PC[2 + 2*count]`. +> +> The cost is `high`. + _Notes:_ * _If a resulting `PC` to be executed is beyond the last instruction then the opcode is implicitly a `STOP`, which is not an error._ -* _Values popped off the `return stack` do not need to be validated, since they are alterable only by `JUMPSUB` and `RETURNSUB`._ -* _The description above lays out the semantics of this feature in terms of a `return stack`. But the actual state of the `return stack` is not observable by EVM code or consensus-critical to the protocol. (For example, a node implementor may code `JUMPSUB` to unobservably push `PC` on the `return stack` rather than `PC + 1`, which is allowed so long as `RETURNSUB` observably returns control to the `PC + 1` location.)_ +* _Values popped off the `return stack` do not need to be validated, since they are alterable only by `JUMPSUB` and `RETURNSUB`._ +* _The description above lays out the semantics of this feature in terms of a `return stack`. But the actual state of the `return stack` is not observable by EVM code or consensus-critical to the protocol. (For example, a node implementer may code `JUMPSUB` to unobservably push `PC` on the `return stack` rather than `PC + 1`, which is allowed so long as `RETURNSUB` observably returns control to the `PC + 1` location.)_ * _The `return stack` is the functional equivalent of Turing's "delay line"._ -### Dependencies - -We need [EIP-3540: EVM Object Format (EOF)](./eip-3540.md) to allow for immediate arguments without special encoding. +`JUMP` and `JUMPI` are assigned _mid_ and _high_ gas fees, and they require operations on 256-bit stack items and checking for valid destinations Whereas none of these operations require checking, and only `RJUMPI` requires 256-bit arithmetic. The _low_ cost of `JUMPSUB` versus is justified by needing only to push the return address on the return stack and decode the immediate two byte destination to the `PC`, and the _verylow_ cost of `RETURNSUB` is justified by needing only to pop the return stack into the `PC`. The _low_ cost of `RJUMP` is justified by needing even less work than `JUMPSUB`, and the cost of `RJUMPI` is `mid` because of the extra work to test the conditional. `RJUMPV` is at least as costly as `RJUMPI`, with extra work for each `offset`. Benchmarking will be needed to tell if the costs are well-balanced. -## Rationale - -We modeled this design on Moore's 1970 [Forth virtual machine](http://www.ultratechnology.com/4th_1970.pdf). It is a two-stack design – the data stack is supplemented with a return stack to support jumping into and returning from subroutines, as specified above. The return address (Turing's "note") is pushed onto the return stack (Turing's "delay line") when calling, and the stack is popped into the `PC` when returning. - -The alternative design is to push the return address and the destination address on the data stack before jumping, and to pop the data stack and jump back to the popped `PC` to return. We prefer the separate return stack because it ensures that the return address cannot be overwritten or mislaid, uses fewer data stack slots, and obviates any need to swap the return address past the arguments or return values on the stack. Crucially, a dynamic jump is not needed to implement subroutine returns`. - -The _low_ cost of `JUMPSUB` is justified by needing only about six Go operations to push the return address on the return stack, and decode the immediate two byte destination to the `PC`. The _verylow_ cost of `RETURNSUB` is justified by needing only about three Go operations to pop the return stack into the `PC`. No 256-bit arithmetic or checking for valid destinations is needed. Also, `JUMP` is assigned _mid_, and `JUMPSUB` and JUMPR should be more efficient, as decoding immediate bytes should be cheaper than than converting 32-byte stack items, and the destination address will not need to be checked for either `JUMPSUB` or `RETURNSUB`. Benchmarking will be needed to tell if the costs are well-balanced. - -### Gas Cost Analysis - -These opcodes reduce the gas costs of both ordinary subroutine calls and low-level optimizations. The savings reported here will of course be less relevant to programs that use a few large subroutines rather than being a factored than in to smaller ones. The choice of gas costs for the new opcodes above does not make a large difference in this analysis, as much of the improvement is due to PUSH and SWAP operations that are no longer needed. Even if `JUMPSUB` cost the same as `JUMP` – 8 gas rather than 5 - a simple subroutine call would still be 52% less costly versus 54%. - -**_Note**: the **JUMP** versions of the examples below are all **valid code**._ - -#### **Simple Subroutine Call** - -Consider this example of calling a minimal subroutine -using `JUMPSUB` -``` -ADD: - beginsub ; 1 gas - 0x02 ; 3 gas - 0x03 ; 3 gas - jumpsub ADDITION ; 5 gas - returnsub ; 3 gas - -ADDITION: - beginsub ; 1 gas - add ; 3 gas - returnsub ; 3 gas - -Total 22 gas. -``` -The same code, using `JUMP`. -``` -TEST_ADD: - jumpdest ; 1 gas - RTN_ADD ; 3 gas - 0x02 ; 3 gas - 0x03 ; 3 gas - ADDITION ; 3 gas - jump ; 8 gas -RTN_ADD: - jumpdest ; 1 gas - swap1 ; 3 gas - jump ; 8 gas - -ADDITION: - jumpdest ; 1 gas - add ; 3 gas - swap1 ; 3 gas - jump ; 8 gas - -Total: 48 gas -``` -Using `JUMPSUB` saves **_48 - 22 = 26_** gas versus using `JUMP` – a 54% performance improvement. +### Validity -The advantages of JUMPR can be seen in, e.g., the tail simple subroutine call. +We define safety here as avoiding exceptional halting states: +* Valid contracts will not halt with an exception unless they + * run out of gas or + * overflow stack while making a recursive subroutine call. -#### **Tail Call Optimization** +Attempts to create contracts that cannot be proven to be valid will fail. -Of course in cases like this one we can optimize the tail call, so that the final `RETURNSUB` in `ADDITION` actually returns from TEST_ADD. -``` -TEST_ADD: - beginsub ; 1 gas - 0x02 ; 3 gas - 0x03 ; 3 gas - jumpsub ADDITION ; 3 gas - -ADDITION: - beginsub ; 1 gas - add ; 3 gas - returnsub ; 3 gas - -Total: 20 gas -``` -Or the same code, using `JUMP` -``` -TEST_ADD: - jumpdest ; 1 gas - 0x02 ; 3 gas - 0x03 ; 3 gas - ADDITION ; 3 gas - jump ; 8 gas - -ADDITION: - jumpdest ; 1 gas - add ; 3 gas - swap1 ; 3 gas - jump ; 8 gas +#### Exceptional Halting States -Total: 33 gas -``` -Using `JUMPSUB` saves **_33 - 20 = 13_** gas versus using `JUMP` – a 39% performance improvement. +_Execution_ is as defined in the [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) a sequence of changes to the EVM state. The conditions on valid _code_ are preserved by state changes. At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state. The Yellow Paper defines five such states. +1. Insufficient gas +2. More than 1024 stack items +3. Insufficient stack items +4. Invalid jump destination +5. Invalid instruction -#### **Tail Call Elimination** +We would like to consider EVM _code_ valid iff no execution of the program can lead to an exceptional halting state, but we must be able to validate _code_ in linear time to avoid denial of service attacks. So in practice, we can only partially meet these requirements. Our validation rules do not consider the _code's_ data and computations, only its control flow and stack use. This means we will reject programs with any invalid _code_ paths, even if those paths are not reachable at runtime. -We can even take advantage of `ADDITION` just happening to directly follow `TEST_ADD` and just fall through rather than jump at all. -``` -TEST_ADD: - beginsub ; 1 gas - 0x02 ; 3 gas - 0x03 ; 3 gas -ADDITION: - beginsub ; 1 gas - add ; 3 gas - returnsub ; 3 gas +### Validation Rules -Total 16 gas. -``` -The same code, using JUMP. -``` -TEST_ADD: - jumpdest ; 1 gas - 0x02 ; 3 gas - 0x03 ; 3 gas -ADDITION: - jumpdest ; 1 gas - add ; 3 gas - swap1 ; 3 gas - jump ; 8 gas +> This section extends the contact creation validation rules (as defined in EIP-3540 and EIP-3670.) +0. Deprecate or restrict `JUMP` and `JUMPI`. +1. Every `RJUMP`, `RJUMPI`, and `RJUMPV` addresses only valid `JUMPDEST`s. +2. The `stack depth` is + * always positive and + * the same on every path through an opcode. +3. The number of items on the `data stack` and on the `return stack` is at most 1024. -Total: 24 gas -``` -Using `JUMPSUB` saves **_22 - 14 = 8_** gas versus using `JUMP` – a 36% performance improvement. +The Yellow Paper has the `stack pointer` (`SP`) pointing just past the top item on the `data stack`. We define the `stack base` (`BP`)as the element that the `SP` addressed at the entry to the current _basic block_, or `0` on program entry, and the `stack depth` as the number of stack elements between the current `SP` and the current `BP`. -Finally, we can take a look at using `JUMPR` instead of `JUMP` +Taken together, these rules allow for code to be validated by traversing the control-flow graph, following each edge only once. -#### **Tail Calls with JUMPR** -``` -TEST_ADD: - jumpdest ; 1 gas - 0x02 ; 3 gas - jumpr ADDITION - ; 3 gas - -ADDITION: - jumpdest ; 1 gas - add ; 3 gas - swap1 ; 3 gas - jump ; 8 gas - -Total: 22 gas. -``` -Using `JUMPR` saves **_33 - 22_ = 11_** gas – a 33% performance improvement. +_Note that this specification is entirely semantic. It constrains only data usage and control flow and imposes no syntax on code beyond being a sequence of bytes to be executed._ -## Backwards and Forwards Compatibility +## Rationale -These changes do not affect the semantics of existing EVM code. +This is a simple two-stack design – the data stack is supplemented with a return stack to support jumping to and returning from subroutines, as specified above, and as conceptualized by Turing. The return address (Turing's "note") is pushed onto the return stack (Turing's "delay line") when calling, and the '`PC`' is popped off of the `PC` when returning. -These changes are compatible with using [EIP-3337](https://eips.ethereum.org/EIPS/eip-3337) to provide stack frames, by associating a frame with each subroutine. +The alternative design is to push the return address and the destination address on the data stack before jumping to the subroutine, and to later jump back to the return address on the stack in order to return. This is the current approach. It could be streamlined to some extent by having JUMPSUB push the return address for RETURNSUB to pop. -## Security Considerations +We prefer the separate return stack because it maintains a clear separation between data and flow of control. This ensures that the return address cannot be overwritten or mislaid. It also reduces costs by using fewer data stack slots and moving less data. -These changes do introduce new flow control instructions, so any software which does static/dynamic analysis of EVM code needs to be modified accordingly. The `JUMPSUB` semantics are similar to `JUMP` (but jumping to a `BEGINSUB`), whereas the `RETURNSUB` instruction is different, since it can 'land' on any opcode (but the possible destinations can be statically inferred). +## Backwards Compatibility -If [`EIP-`3779](./eip-3779.md) – Safe Control Flow for the EVM – advances then the requirement on `JUMPSUB` to `abort` if the opcode at `location` is not a `BEGINSUB` will need to be enforced at creation time rather than runtime. +These changes affect the semantics of existing EVM code. These changes are compatible with the restricted forms of `JUMP` and `JUMPI` specified by [EIP-3779](./eip-3779.md) -- contracts following all of the rules given there and here will be valid. ## Test Cases @@ -266,7 +296,7 @@ If [`EIP-`3779](./eip-3779.md) – Safe Control Flow for the EVM – advances th This should jump into a subroutine, back out and stop. -Bytecode: `0x60045e005c5d` (`PUSH1 0x04, JUMPSUB, STOP, BEGINSUB, RETURNSUB`) +Bytecode: `0x60045e005b5d` (`PUSH1 0x04, JUMPSUB, STOP, JUMPDEST, RETURNSUB`) | Pc | Op | Cost | Stack | RStack | |-------|-------------|------|-----------|-----------| @@ -281,7 +311,7 @@ Consumed gas: `10` This should execute fine, going into one two depths of subroutines -Bytecode: `0x6800000000000000000c5e005c60115e5d5c5d` (`PUSH9 0x00000000000000000c, JUMPSUB, STOP, BEGINSUB, PUSH1 0x11, JUMPSUB, RETURNSUB, BEGINSUB, RETURNSUB`) +Bytecode: `0x6800000000000000000c5e005b60115e5d5b5d` (`PUSH9 0x00000000000000000c, JUMPSUB, STOP, JUMPDEST, PUSH1 0x11, JUMPSUB, RETURNSUB, JUMPDEST, RETURNSUB`) | Pc | Op | Cost | Stack | RStack | |-------|-------------|------|-----------|-----------| @@ -298,7 +328,7 @@ Consumed gas: `20` This should fail, since the given location is outside of the code-range. The code is the same as previous example, except that the pushed location is `0x01000000000000000c` instead of `0x0c`. -Bytecode: (`PUSH9 0x01000000000000000c, JUMPSUB, `0x6801000000000000000c5e005c60115e5d5c5d`, STOP, BEGINSUB, PUSH1 0x11, JUMPSUB, RETURNSUB, BEGINSUB, RETURNSUB`) +Bytecode: (`PUSH9 0x01000000000000000c, JUMPSUB, `0x6801000000000000000c5e005b60115e5d5b5d`, STOP, JUMPDEST, PUSH1 0x11, JUMPSUB, RETURNSUB, JUMPDEST, RETURNSUB`) | Pc | Op | Cost | Stack | RStack | |-------|-------------|------|-----------|-----------| @@ -326,7 +356,7 @@ Error: at pc=0, op=RETURNSUB: invalid retsub In this example. the JUMPSUB is on the last byte of code. When the subroutine returns, it should hit the 'virtual stop' _after_ the bytecode, and not exit with error -Bytecode: `0x6005565c5d5b60035e` (`PUSH1 0x05, JUMP, BEGINSUB, RETURNSUB, JUMPDEST, PUSH1 0x03, JUMPSUB`) +Bytecode: `0x6005565b5d5b60035e` (`PUSH1 0x05, JUMP, JUMPDEST, RETURNSUB, JUMPDEST, PUSH1 0x03, JUMPSUB`) | Pc | Op | Cost | Stack | RStack | |-------|-------------|------|-----------|-----------| @@ -338,3 +368,113 @@ Bytecode: `0x6005565c5d5b60035e` (`PUSH1 0x05, JUMP, BEGINSUB, RETURNSUB, JUMPDE | 7 | STOP | 0 | [] | [] | Consumed gas: `30` + +## Reference Implementation + +### Validation Algorithm +> This section specifies an algorithm for checking the above the rules. Equivalent code must be run at creation time. We assume that the validation defined in EIP-3540 and EIP-3670 has already run, although in practice the algorithms can be merged. + +The following is a pseudo-Go implementation of an algorithm for enforcing adherence to the above rules. This algorithm is a symbolic execution of the program that recursively traverses the bytecode, following its control flow and stack use and checking for violations of the rules above. It uses a stack to track the slots that hold `PUSHed` constants, from which it pops the destinations to validate during the analysis. + +This algorithm runs in time equal to `O(vertices + edges)` in the program's control-flow graph, where edges represent control flow and the vertices represent _basic blocks_ – thus the algorithm takes time proportional to the size of the bytecode. + +For simplicity's sake we assume a few helper functions. +* `advance_pc()` advances the `PC`, skipping any immediate data. +* `imm_data()` returns immediate data for an instruction.`J +* `valid_jumpdest()` checks that a jump destination is not in immediate data. +* `remove_items()` returns the number of items removed from the `stack` by an instruction +* `add_items() returns the number of items added to the `stack`. Items are added as 0xFFFFFFFF. + The `PC`, `PUSH…`, `SWAP…`, `DUP…`, `JUMP`, and `JUMPI` instructions are handled separately. +``` +var code [code_len]byte +var depth [code_len]unsigned +var sp := 1023 +var bp := 1023 + +func validate(pc := 0, depth := 0) boolean { + + for ; pc < code_len; pc = advance_pc(pc) { + + // successful termination + switch instruction { + case STOP { return true } + case RETURN { return true } + case SUICIDE { return true } + } + + // check for stack underflow and overflow + depth := bp - sp + if depth < 0 || sp < 0 || 1024 < sp { + return false + } + + // if stack depth for `pc` is non-zero we have been here before + // so return to break cycle in control flow graph + if depth[pc] != 0 { + if depth[pc] != depth { + return false + } + return true + } + depth[pc] = depth + + if (instruction == RJUMP) { + + // check for valid destination + jumpdest = pc + imm_data(pc) + if !valid_jumpdest(jumpdest) { + return false + } + + // will enter basic block at destination + bp = sp + + // reset pc to destination of jump + pc = jumpdest + continue + } + if (instruction == RJUMPV { + + // check for valid destination + n = imm_data(pc += 2) + for i := 0; i < n; n-- { + jumpdest = pc + n + imm_data(pc) + if !valid_jumpdest(jumpdest) { + return false + } + // recurse to jump to code to validate + if !validate(jumpdest) { + return false + } + } + // false side of conditional + + // enter basic block + bp = sp + continue + } + if (instruction == JUMPDEST) { + + // enter basic block + bp = sp + continue + } + + // apply other instructions to stack + sp += remove_items(pc) + sp -= add_items(pc) + } + + // successful termination + return true +} +``` + +## Security Considerations + +These changes do introduce new flow control instructions, so any software which does static/dynamic analysis of EVM code needs to be modified accordingly. The `JUMPSUB` semantics are similar to `JUMP` whereas the `RETURNSUB` instruction is different, since it can 'land' on any opcode (but the possible destinations can be statically inferred). + +The validation algorithm must run in time and space near-linear in the size of its input so that a it can be charged appropriate gas to avoid DoS attack. `RJUMPV` takes its arguments inline so that attempts to attack the validation algorithm will fail by reducing the space available to attack it in. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-2327.md b/EIPS/eip-2327.md index 3546458110da6..ff85fb1d47661 100644 --- a/EIPS/eip-2327.md +++ b/EIPS/eip-2327.md @@ -3,7 +3,7 @@ eip: 2327 title: BEGINDATA opcode author: Martin Lundfall (@MrChico) discussions-to: https://ethereum-magicians.org/t/new-opcode-begindata/3727 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-10-28 diff --git a/EIPS/eip-233.md b/EIPS/eip-233.md index c70c6b49c7ab5..66a23f8a37f71 100644 --- a/EIPS/eip-233.md +++ b/EIPS/eip-233.md @@ -4,7 +4,7 @@ title: Formal process of hard forks author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-233-formal-process-of-hard-forks/1387 type: Meta -status: Draft +status: Stagnant created: 2017-03-23 --- diff --git a/EIPS/eip-2335.md b/EIPS/eip-2335.md index 4bad77e287bf1..55550ac958b0d 100644 --- a/EIPS/eip-2335.md +++ b/EIPS/eip-2335.md @@ -3,7 +3,7 @@ eip: 2335 title: BLS12-381 Keystore author: Carl Beekhuizen discussions-to: https://github.com/ethereum/EIPs/issues/2339 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-09-30 diff --git a/EIPS/eip-2364.md b/EIPS/eip-2364.md index dde5598e4eb9c..43421057dd261 100644 --- a/EIPS/eip-2364.md +++ b/EIPS/eip-2364.md @@ -1,9 +1,11 @@ --- eip: 2364 title: "eth/64: forkid-extended protocol handshake" -author: Péter Szilágyi +description: Introduces validation of the `forkid` when handshaking with peers. +author: Péter Szilágyi , Péter Szilágyi (@karalabe), Tim Beiko (@timbeiko) discussions-to: https://github.com/ethereum/EIPs/issues/2365 -status: Draft +status: Last Call +last-call-deadline: 2021-11-19 type: Standards Track category: Networking created: 2019-11-08 @@ -12,22 +14,22 @@ requires: 2124 ## Abstract +This EIP specifies the inclusion of the `forkid`, originally defined in [(EIP-2124)](./eip-2124.md), as a new field in the Ethereum wire protocol (`eth`) handshake. This change is implemented as a new version of the wire protocol, `eth/64`. + +## Motivation + The [`forkid` (EIP-2124)](./eip-2124.md) was designed to permit two Ethereum nodes to quickly and cheaply decide if they are compatible or not, not only at a genesis/networking level, but also from the perspective of the currently passed network updates (i.e. forks). [EIP-2124](./eip-2124.md) only defines how the `forkid` is calculated and validated, but does not specify how the `forkid` should be exchanged between peers. This EIP specifies the inclusion of the `forkid` as a new field in the Ethereum wire protocol (`eth`) handshake (releasing a new version, `eth/64`). By cross-validating `forkid` during the handshake, incompatible nodes can disconnect before expensive block exchanges and validations take place (PoW check, EVM execution, state reconstruction). This further prevents peer slots from being taken up by nodes that are incompatible, but have not yet been detected as such. -## Motivation - From a micro perspective, cutting off incompatible nodes from one another ensures that a node only spends its resources on tasks that are genuinely useful to it. The sooner we can decide the remote peer is useless, the less time and processing we expend in vain. From a macro perspective, keeping incompatible nodes partitioned from one another ensures that disjoint clusters retain more resources for maintaining their own chain, thus raising the quality of service for all networks globally. ## Specification -The specification is tiny since most parts are already specified in EIP-2124. `eth/63` is not specified as an EIP, but is maintained [here](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). - - Implement `forkid` generation and validation per [EIP-2124](./eip-2124.md). - Advertise a new `eth` protocol capability (version) at `eth/64`. - The old `eth/63` protocol should still be kept alive side-by-side, until `eth/64` is sufficiently adopted by implementors. @@ -40,7 +42,9 @@ Whenever two peers connect using the `eth/64` protocol, the updated `Status` mes ## Rationale -##### EIP-2124 mentions advertising the `forkid` in the discovery protocol too. How does that compare to advertising in the `eth` protocol? Why is the redundancy needed? +The specification is tiny since most parts are already specified in EIP-2124. `eth/63` is not specified as an EIP, but is maintained in the [ethereum/devp2p](https://github.com/ethereum/devp2p) Github repository. + +### EIP-2124 mentions advertising the `forkid` in the discovery protocol too. How does that compare to advertising in the `eth` protocol? Why is the redundancy needed? Advertising and validating the `forkid` in the discovery protocol is a more optimal solution, as it can help avoid the cost of setting up the TCP connection and cryptographic RLPx stream, only to be torn down if `eth/64` rejects it. @@ -48,7 +52,7 @@ Compared to the `eth` protocol however, discovery is a bit fuzzy. The goal there Additionally, `forkid` validation via the discovery protocol requires ENR implementation ([EIP-778](./eip-778.md)) and ENR extension support ([EIP-868](./eip-868.md)), which is not mandated by the Ethereum network currently. Lastly, the discovery protocol is just one way to find peers, but systems that cannot use UDP or that rely on other mechanism (e.g. DNS discovery ([EIP-1459](./eip-1459.md))) still need a way to filter connections. -##### The `forkid` implicitly contains the genesis hash checksummed into the `FORK_HASH` field. Why doesn't this proposal remove the `genesisHash` field from the `eth` handshake? +### The `forkid` implicitly contains the genesis hash checksummed into the `FORK_HASH` field. Why doesn't this proposal remove the `genesisHash` field from the `eth` handshake? Originally this EIP did remove it as redundant data, since filtering based on the `forkid` is a superset of filtering based on genesis hash. The reason for backing out of that decision was that the genesis hash may be useful for other things too, not just connection filtering (network crawlers use it currently to split nodes across networks). @@ -64,11 +68,9 @@ This EIP does not change the consensus engine, thus does _not_ require a hard fo For calculating and validating fork IDs, see test cases in [EIP-2124](./eip-2124.md). -Testing proper advertising and validation at the networking level will require a [hive](https://github.com/ethereum/hive) test. - -## Implementation +## Security Considerations -Geth: https://github.com/ethereum/go-ethereum/pull/20140 +None. ## Copyright diff --git a/EIPS/eip-2378.md b/EIPS/eip-2378.md index 6740a74f80913..2e2a18d3c653c 100644 --- a/EIPS/eip-2378.md +++ b/EIPS/eip-2378.md @@ -3,7 +3,7 @@ eip: 2378 title: EIPs Eligible for Inclusion author: James Hancock (@MadeofTin) discussions-to: https://gitter.im/ethereum/EIPs -status: Draft +status: Stagnant type: Meta created: 2019-11-13 --- diff --git a/EIPS/eip-2386.md b/EIPS/eip-2386.md index 0d3381e65bae4..2fd9811384d7a 100644 --- a/EIPS/eip-2386.md +++ b/EIPS/eip-2386.md @@ -3,7 +3,7 @@ eip: 2386 title: Ethereum 2 Hierarchical Deterministic Walletstore author: Jim McDonald discussions-to: https://ethereum-magicians.org/t/eip-2386-walletstore/3792 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-11-21 diff --git a/EIPS/eip-2390.md b/EIPS/eip-2390.md index 832efb82c8a5f..724d094e3b48d 100644 --- a/EIPS/eip-2390.md +++ b/EIPS/eip-2390.md @@ -3,7 +3,7 @@ eip: 2390 title: Geo-ENS author: James Choncholas (@james-choncholas) discussions-to: https://github.com/ethereum/EIPs/issues/2959 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2019-11-15 diff --git a/EIPS/eip-2400.md b/EIPS/eip-2400.md index 9cc754e2a48b1..eb3733a857a65 100644 --- a/EIPS/eip-2400.md +++ b/EIPS/eip-2400.md @@ -5,7 +5,7 @@ author: Ricardo Guilherme Schmidt (@3esmit), Eric Dvorsak (@yenda) discussions-to: https://ethereum-magicians.org/t/eip-2400-transaction-receipt-uri/ type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2019-11-05 requires: 155, 831 --- diff --git a/EIPS/eip-2464.md b/EIPS/eip-2464.md index dea697f81a888..0da571b6cf049 100644 --- a/EIPS/eip-2464.md +++ b/EIPS/eip-2464.md @@ -1,9 +1,11 @@ --- eip: 2464 title: "eth/65: transaction announcements and retrievals" -author: Péter Szilágyi , Gary Rong +description: Introduces `NewPooledTransactionHashes`, `GetPooledTransactions`, and `PooledTransactions`. +author: Péter Szilágyi , Péter Szilágyi (@karalabe), Gary Rong , Tim Beiko (@timbeiko) discussions-to: https://github.com/ethereum/EIPs/issues/2465 -status: Draft +status: Last Call +last-call-deadline: 2021-11-19 type: Standards Track category: Networking created: 2020-01-13 @@ -12,7 +14,11 @@ requires: 2364 ## Abstract -The `eth` network protocol has two ways to propagate a newly mined block: it can be broadcast to a peer in its entirety (via `NewBlock (0x07)` [in `eth/64` and prior](https://github.com/ethereum/devp2p/blob/master/caps/eth.md)) or it can be announced only (via `NewBlockHashes (0x01)`). This duality allows nodes to do the high-bandwidth broadcasting (10s-100s KB) for a square root number of peers; and the low-bandwidth announcing (10s-100s B) for the remaining linear number of peers. The square root broadcast is enough to reach all well connected nodes, but the linear announce is needed to get across degenerate topologies. This works well. +This EIP introduces three additional message types into the `eth` protocol (releasing a new version, `eth/65`): `NewPooledTransactionHashes (0x08)` to announce a set of transactions without their content; `GetPooledTransactions (0x09)` to request a batch of transactions by their announced hash; and `PooledTransactions (0x0a)` to reply to a transaction request. This permits reducing the bandwidth used for transaction propagation from linear complexity in the number of peers to square root; and also reducing the initial transaction exchange from 10s-100s MB to `len(pool) * 32B ~= 128KB`. + +## Motivation + +The `eth` network protocol has two ways to propagate a newly mined block: it can be broadcast to a peer in its entirety (via `NewBlock (0x07)` in `eth/64` and prior or it can be announced only (via `NewBlockHashes (0x01)`). This duality allows nodes to do the high-bandwidth broadcasting (10s-100s KB) for a square root number of peers; and the low-bandwidth announcing (10s-100s B) for the remaining linear number of peers. The square root broadcast is enough to reach all well connected nodes, but the linear announce is needed to get across degenerate topologies. This works well. The `eth` protocol, however, does not have a similar dual mechanism for propagating transactions, so nodes need to rely on broadcasting (via `Transactions (0x02)`). To cater for degenerate topologies, transactions cannot be broadcast square rooted, rather they need to be transferred linearly to all peers. With N peers, each node will transfer the same transaction N times (counting both directions), whereas 1 would be enough in a perfect world. This is a significant waste. @@ -20,8 +26,6 @@ A similar issue arises when a new network connection is made between two nodes, This EIP introduces three additional message types into the `eth` protocol (releasing a new version, `eth/65`): `NewPooledTransactionHashes (0x08)` to announce a set of transactions without their content; `GetPooledTransactions (0x09)` to request a batch of transactions by their announced hash; and `PooledTransactions (0x0a)` to reply to a transaction request. This permits reducing the bandwidth used for transaction propagation from linear complexity in the number of peers to square root; and also reducing the initial transaction exchange from 10s-100s MB to `len(pool) * 32B ~= 128KB`. -## Motivation - With transaction throughput (and size) picking up in Ethereum, transaction propagation is the current dominant component of the used network resources. Most of these resources are however wasted, as the `eth` protocol does not have a mechanism to deduplicate transactions remotely, so the same data is transferred over and over again across all network connections. This EIP proposes a tiny extension to the `eth` protocol, which permits nodes to agree on the set of transactions that need to be transferred across a network connection, before doing the costly exchange. This should help reduce the global (operational) bandwidth usage of the Ethereum network by at least an order of magnitude. @@ -69,13 +73,9 @@ This EIP extends the `eth` protocol in a backwards incompatible way and requires This EIP does not change the consensus engine, thus does _not_ require a hard fork. -## Test Cases - -TODO - -## Implementation +## Security Considerations -Geth: https://github.com/ethereum/go-ethereum/pull/20234 +None. ## Copyright diff --git a/EIPS/eip-2470.md b/EIPS/eip-2470.md index 811385f030b4c..1c7e12ab37ce7 100644 --- a/EIPS/eip-2470.md +++ b/EIPS/eip-2470.md @@ -3,7 +3,7 @@ eip: 2470 title: Singleton Factory author: Ricardo Guilherme Schmidt (@3esmit) discussions-to: https://ethereum-magicians.org/t/erc-2470-singleton-factory/3933 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-01-15 diff --git a/EIPS/eip-2474.md b/EIPS/eip-2474.md index df5983cda6385..82d4cd2a3c796 100644 --- a/EIPS/eip-2474.md +++ b/EIPS/eip-2474.md @@ -3,7 +3,7 @@ eip: 2474 title: Coinbase calls author: Ricardo Guilherme Schmidt (@3esmit) discussions-to: https://ethresear.ch/t/gas-abstraction-non-signed-block-validator-only-procedures/4388/2 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-01-19 diff --git a/EIPS/eip-2477.md b/EIPS/eip-2477.md index 7ce473676740d..a29362e0c44a6 100644 --- a/EIPS/eip-2477.md +++ b/EIPS/eip-2477.md @@ -5,7 +5,7 @@ author: Kristijan Sedlak (@xpepermint), William Entriken , discussions-to: https://github.com/ethereum/EIPs/issues/2483 type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2020-01-02 requires: 165, 721, 1155 --- @@ -103,26 +103,24 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL **Smart contracts implementing the ERC-2477 standard MUST implement the `ERC2477` interface.** ```solidity -pragma solidity ^0.6.0; +// SPDX-License-Identifier: CC0-1.0 + +pragma solidity ^0.8.7; /// @title ERC-2477 Token Metadata Integrity /// @dev See https://eips.ethereum.org/EIPS/eip-2477 -/// @dev The ERC-165 identifier for this interface is 0x#######. //TODO: FIX THIS +/// @dev The ERC-165 identifier for this interface is 0x832a7e0e interface ERC2477 /* is ERC165 */ { - /** - * @notice Get the cryptographic hash of the specified tokenID's metadata - * @param tokenId Identifier for a specific token - * @return digest Bytes returned from the hash algorithm, or "" if not available - * @return hashAlgorithm The name of the cryptographic hash algorithm, or "" if not available - */ + /// @notice Get the cryptographic hash of the specified tokenID's metadata + /// @param tokenId Identifier for a specific token + /// @return digest Bytes returned from the hash algorithm, or "" if not available + /// @return hashAlgorithm The name of the cryptographic hash algorithm, or "" if not available function tokenURIIntegrity(uint256 tokenId) external view returns(bytes memory digest, string memory hashAlgorithm); - - /** - * @notice Get the cryptographic hash for the specified tokenID's metadata schema - * @param tokenId Id of the Xcert. - * @return digest Bytes returned from the hash algorithm, or "" if not available - * @return hashAlgorithm The name of the cryptographic hash algorithm, or "" if not available - */ + + /// @notice Get the cryptographic hash for the specified tokenID's metadata schema + /// @param tokenId Identifier for a specific token + /// @return digest Bytes returned from the hash algorithm, or "" if not available + /// @return hashAlgorithm The name of the cryptographic hash algorithm, or "" if not available function tokenURISchemaIntegrity(uint256 tokenId) external view returns(bytes memory digest, string memory hashAlgorithm); } ``` @@ -141,37 +139,31 @@ Smart contracts implementing the ERC-2477 standard MAY use any mechanism to prov ### Metadata -A metadata document MAY use this schema to provide referential integrity to its schema document. +A metadata document MAY conform to this schema to provide referential integrity to its schema document. ```json { - "title": "EIP-2477 JSON Object With Refererential Integrity to Schema", - "type": "object", - "properties": { - "$schema": { - "type": "string", - "format": "uri" + "title": "EIP-2477 JSON Object With Refererential Integrity to Schema", + "type": "object", + "properties": { + "$schema": { + "type": "string", + "format": "uri" + }, + "$schemaIntegrity": { + "type": "object", + "properties": { + "digest": { + "type": "string" }, - "$schemaIntegrity": { - "type": "object", - "properties": { - "digest": { - "type": "string" - }, - "hashAlgorithm": { - "type": "string" - } - }, - "required": [ - "digest", - "hashAlgorithm" - ] + "hashAlgorithm": { + "type": "string" } - }, - "required": [ - "$schema", - "$schemaIntegrity" - ] + }, + "required": ["digest", "hashAlgorithm"] + } + }, + "required": ["$schema", "$schemaIntegrity"] } ``` @@ -201,8 +193,6 @@ The digest return value is first, this is an optimization because we expect on-c The digest is a byte array and supports various hash lengths. This is consistent with SRI. Whereas SRI uses base64 encoding to target an HTML document, we use a byte array because Ethereum already allows this encoding. -:warning: TODO: WE NEED TO SPECIFY ENDIANNESS ABOVE AND PROVIDE TEST CASES BELOW. AND JUSTIFY THAT HERE. - The hash function name is a string. Currently there is no universal taxonomy of hash function names. SRI recognizes the names `sha256`, `sha384` and `sha512` with case-insensitive matching. We are aware of two authorities which provide taxonomies and canonical names for hash functions: ETSI Object Identifiers and NIST Computer Security Objects Register. However, SRI's approach is easier to follow and we have adopted this here. **Function return type — hash length** @@ -223,9 +213,9 @@ One possible way to achieve strong content integrity with the existing token sta Other supplementary reasons are: -* For on-chain consumers of data, it is easier to parse a direct hash field than to perform string operations +* For on-chain consumers of data, it is easier to parse a direct hash field than to perform string operations. -* Maybe there are some URIs which are not amenable to being modified in that way, therefore limiting the generalizability of that approach +* Maybe there are some URIs which are not amenable to being modified in that way, therefore limiting the generalizability of that approach. This design justification also applies to `tokenURISchemaIntegrity`. The current JSON-LD specification allows a JSON document to link to a schema document. But it does not provide integrity. Rather than changing how JSON-LD works, or changing JSON Schemas, we have the `tokenURISchemaIntegrity` property to just provide the integrity. @@ -245,10 +235,10 @@ Following is a token metadata document which is simultaneously compatible with E ```json { - "$schema": "https://URL_TO_SCHEMA_DOCUMENT", - "name": "Asset Name", - "description": "Lorem ipsum...", - "image": "https:\/\/s3.amazonaws.com\/your-bucket\/images\/{id}.png", + "$schema": "https://URL_TO_SCHEMA_DOCUMENT", + "name": "Asset Name", + "description": "Lorem ipsum...", + "image": "https://s3.amazonaws.com/your-bucket/images/{id}.png" } ``` @@ -258,21 +248,21 @@ Following is a corresponding schema document which is accessible using the URI ` ```json { - "type": "object", - "properties": { - "name": { - "type": "string", - "description": "Identifies the asset to which this NFT represents" - }, - "description": { - "type": "string", - "description": "Describes the asset to which this NFT represents" - }, - "image": { - "type": "string", - "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." - } + "type": "object", + "properties": { + "name": { + "type": "string", + "description": "Identifies the asset to which this NFT represents" + }, + "description": { + "type": "string", + "description": "Describes the asset to which this NFT represents" + }, + "image": { + "type": "string", + "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." } + } } ``` @@ -289,7 +279,7 @@ To avoid doubt: the previous paragraph specifies "MAY" have that output because ## Implementation -TODO: ADD IMPLEMENTATIONS WITH 0XCERT ENJIN, NIKE, AZURE/MICROSOFT +0xcert Framework supports ERC-2477. ## Reference @@ -319,15 +309,17 @@ Discussion Other -1. [Shattered] The first collision for full SHA-1. https://shattered.io/static/shattered.pdf -2. [320 byte file] The second SHA Collision. https://privacylog.blogspot.com/2019/12/the-second-sha-collision.html -3. [Chosen prefix] https://sha-mbles.github.io -4. Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. (Rev. 1. Superseded.) https://csrc.nist.gov/publications/detail/sp/800-131a/rev-1/archive/2015-11-06 -5. Commercial National Security Algorithm (CNSA) Suite Factsheet. https://apps.nsa.gov/iaarchive/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/commercial-national-security-algorithm-suite-factsheet.cfm -6. ETSI Assigned ASN.1 Object Identifiers. https://portal.etsi.org/pnns/oidlist -7. Computer Security Objects Register. https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration -8. The Sandbox implementation. https://github.com/pixowl/sandbox-smart-contracts/blob/7022ce38f81363b8b75a64e6457f6923d91960d6/src/Asset/ERC1155ERC721.sol +1. [0xcert Framework supports ERC-2477]. https://github.com/0xcert/framework/pull/717 +2. [Shattered] The first collision for full SHA-1. https://shattered.io/static/shattered.pdf +3. [320 byte file] The second SHA Collision. https://privacylog.blogspot.com/2019/12/the-second-sha-collision.html +4. [Chosen prefix] https://sha-mbles.github.io +5. Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. (Rev. 1. Superseded.) https://csrc.nist.gov/publications/detail/sp/800-131a/rev-1/archive/2015-11-06 +6. Commercial National Security Algorithm (CNSA) Suite Factsheet. https://apps.nsa.gov/iaarchive/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/commercial-national-security-algorithm-suite-factsheet.cfm +7. ETSI Assigned ASN.1 Object Identifiers. https://portal.etsi.org/pnns/oidlist +8. Computer Security Objects Register. https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration +9. The Sandbox implementation. https://github.com/pixowl/sandbox-smart-contracts/blob/7022ce38f81363b8b75a64e6457f6923d91960d6/src/Asset/ERC1155ERC721.sol ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + diff --git a/EIPS/eip-2481.md b/EIPS/eip-2481.md index 2bd705f2bd768..1393a48a798c4 100644 --- a/EIPS/eip-2481.md +++ b/EIPS/eip-2481.md @@ -4,7 +4,7 @@ title: "eth/66: request identifier" author: Christoph Burgdorf (@cburgdorf) discussions-to: https://github.com/ethereum/EIPs/issues/2482 status: Last Call -review-period-end: 2021-08-11 +last-call-deadline: 2021-08-11 type: Standards Track category: Networking created: 2020-01-17 diff --git a/EIPS/eip-2488.md b/EIPS/eip-2488.md index 35e548a31bc14..bb6236af75dfd 100644 --- a/EIPS/eip-2488.md +++ b/EIPS/eip-2488.md @@ -3,7 +3,7 @@ eip: 2488 title: Deprecate the CALLCODE opcode author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2488-deprecate-the-callcode-opcode/3957 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2019-12-20 diff --git a/EIPS/eip-2494.md b/EIPS/eip-2494.md index b8672e79bbcd7..1f6c2600ae073 100644 --- a/EIPS/eip-2494.md +++ b/EIPS/eip-2494.md @@ -3,7 +3,7 @@ eip: 2494 title: Baby Jubjub Elliptic Curve author: Barry WhiteHat (@barryWhiteHat), Marta Bellés (@bellesmarta), Jordi Baylina (@jbaylina) discussions-to: https://ethereum-magicians.org/t/eip-2494-baby-jubjub-elliptic-curve/3968 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-01-29 diff --git a/EIPS/eip-2515.md b/EIPS/eip-2515.md index 1c53b19beceb6..0b336481bd995 100644 --- a/EIPS/eip-2515.md +++ b/EIPS/eip-2515.md @@ -3,7 +3,7 @@ eip: 2515 title: Implement Difficulty Freeze author: James Hancock (@madeoftin) discussions-to: https://ethereum-magicians.org/t/eip-2515-replace-the-difficulty-bomb-with-a-difficulty-freeze/3995 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-02-10 diff --git a/EIPS/eip-2520.md b/EIPS/eip-2520.md index 5546ee247ec7d..dcf776b88f657 100644 --- a/EIPS/eip-2520.md +++ b/EIPS/eip-2520.md @@ -3,7 +3,7 @@ eip: 2520 title: Multiple contenthash records for ENS author: Filip Štamcar (@filips123) discussions-to: https://github.com/ethereum/EIPs/issues/2393 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-02-18 diff --git a/EIPS/eip-2525.md b/EIPS/eip-2525.md index 4153668eb3cd3..71a285511154e 100644 --- a/EIPS/eip-2525.md +++ b/EIPS/eip-2525.md @@ -3,7 +3,7 @@ eip: 2525 title: ENSLogin author: Hadrien Croubois (@amxx) discussions-to: https://ethereum-magicians.org/t/discussion-ens-login/3569 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-02-19 diff --git a/EIPS/eip-2535.md b/EIPS/eip-2535.md index 134865ae6d10d..db2e898ce1408 100644 --- a/EIPS/eip-2535.md +++ b/EIPS/eip-2535.md @@ -4,7 +4,7 @@ title: Diamonds, Multi-Facet Proxy author: Nick Mudge (@mudgen) discussions-to: https://github.com/ethereum/EIPs/issues/2535 status: Last Call -review-period-end: 2020-08-15 +last-call-deadline: 2020-08-15 type: Standards Track category: ERC created: 2020-02-22 @@ -14,7 +14,7 @@ created: 2020-02-22 ## Simple Summary -Standard for building modular smart contract systems that can be extended in production. +Standard for creating modular smart contract systems that can be extended after deployment. Enables people to write smart contracts with virtually no size limit. @@ -142,7 +142,7 @@ library LibA { // ds is short for DiamondStorage function diamondStorage() internal pure returns(DiamondStorage storage ds) { // Specifies a random position in contract storage - // This can be done with a kaccak256 hash of a unique string as is + // This can be done with a keccak256 hash of a unique string as is // done here or other schemes can be used such as this: // bytes32 storagePosition = keccak256(abi.encodePacked(ERC1155.interfaceId, ERC1155.name, address(this))); bytes32 storagePosition = keccak256("diamond.storage.LibA"); diff --git a/EIPS/eip-2537.md b/EIPS/eip-2537.md index df7d5bdbdc289..febee229f426c 100644 --- a/EIPS/eip-2537.md +++ b/EIPS/eip-2537.md @@ -3,7 +3,7 @@ eip: 2537 title: Precompile for BLS12-381 curve operations author: Alex Vlasov (@shamatar), Kelly Olson (@ineffectualproperty) discussions-to: https://ethereum-magicians.org/t/eip2537-bls12-precompile-discussion-thread/4187 -status: Review +status: Stagnant type: Standards Track category: Core created: 2020-02-21 diff --git a/EIPS/eip-2539.md b/EIPS/eip-2539.md index 8977521b907d8..850a44c876fef 100644 --- a/EIPS/eip-2539.md +++ b/EIPS/eip-2539.md @@ -3,7 +3,7 @@ eip: 2539 title: BLS12-377 curve operations author: Alex Vlasov (@shamatar) discussions-to: https://ethereum-magicians.org/t/eip-2539-bls12-377-precompile-discussion-thread/4659 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-02-26 diff --git a/EIPS/eip-2542.md b/EIPS/eip-2542.md index 833546ab8d54e..6b8c3187c8e6e 100644 --- a/EIPS/eip-2542.md +++ b/EIPS/eip-2542.md @@ -3,7 +3,7 @@ eip: 2542 title: New opcodes TXGASLIMIT and CALLGASLIMIT author: Alex Forshtat discussions-to: https://ethereum-magicians.org/t/eip-2542-add-txgaslimit-callgaslimit-txgasrefund-opcodes -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-02-29 diff --git a/EIPS/eip-2544.md b/EIPS/eip-2544.md index 46d971fc6f3c0..e0f2622e0759c 100644 --- a/EIPS/eip-2544.md +++ b/EIPS/eip-2544.md @@ -1,6 +1,7 @@ --- eip: 2544 title: ENS Wildcard Resolution +description: Adds support for "wildcard" resolution of subdomains in ENS. author: Nick Johnson (@arachnid), 0age (@0age) discussions-to: https://ethereum-magicians.org/t/eip-2544-ens-wildcard-resolution status: Draft @@ -10,15 +11,13 @@ created: 2020-02-28 requires: 137 --- -## Simple Summary - -EIP-2544 extends ENS client behavior to support "wildcard" resolution of subdomains. This is accomplished by using a parent domain's resolver if none is set on a given subdomain. - ## Abstract -The Ethereum Name Service Specification (EIP-137) establishes a two-step name resolution process. First, an ENS client takes a provided name, performs the namehash algorithm to determine the associated "node", and supplies that node to the ENS Registry contract to determine the resolver. Then, if a resolver has been set on the Registry, the client supplies that same node to the resolver contract, which will return the associated address or other record. +The Ethereum Name Service Specification (EIP-137) establishes a two-step name resolution process. First, an ENS client performs the namehash algorithm on the name to determine the associated "node", and supplies that node to the ENS Registry contract to determine the resolver. Then, if a resolver has been set on the Registry, the client supplies that same node to the resolver contract, which will return the associated address or other record. -As currently specified, this process terminates if a resolver is not set on the ENS Registry for a given node. This EIP extends the existing name resolution process by adding an additional step if a resolver is not set for subdomain. This step strips out the leftmost label from the name, derives the node of the new fragment, and supplies that node to the ENS Registry. If a resolver is located for that node, the client supplies the original, complete node to that resolver contract to derive the relevant records. +As currently specified, this process terminates if a resolver is not set on the ENS Registry for a given node. This EIP changes the name resolution process by adding an additional step if a resolver is not set for a domain. This step strips out the leftmost label from the name, derives the node of the new fragment, and supplies that node to the ENS Registry. If a resolver is located for that node, the client supplies the original, complete node to that resolver contract to derive the relevant records. This step is repeated until a node with a resolver is found. + +Further, this specification defines a new way for resolvers to resolve names, using a unified `resolve()` method that permits more flexible handling of name resolution. ## Motivation @@ -28,61 +27,76 @@ Furthermore, users cannot immediately utilize these subdomains upon account crea Enabling wildcard support allows for the design of more advanced resolvers that deterministically generate addresses and other records for unassigned subdomains. The generated addresses could map to counterfactual contract deployment addresses (i.e. `CREATE2` addresses), to designated "fallback" addresses, or other schemes. Additionally, individual resolvers would still be assignable to any given subdomain, which would supersede the wildcard resolution using the parent resolver. -Another critical motivation with EIP-2544 is to enable wildcard resolution in a backwards-compatible fashion. It does not require modifying the current ENS Registry contract or any assigned resolvers, and continues to support existing ENS records — legacy ENS clients would simply fail to resolve wildcard records. +Another critical motivation with EIP-2544 is to enable wildcard resolution in a backwards-compatible fashion. It does not require modifying the current ENS Registry contract or any existing resolvers, and continues to support existing ENS records — legacy ENS clients would simply fail to resolve wildcard records. ## Specification The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. -EIP-2544-compliant ENS clients MUST perform the following sequence when determining the resolver for a given name: +Let: + - `namehash` be the algorithm defined in EIP 137. + - `dnsencode` be the process for encoding DNS names specified in section 3.1 of RFC1035, with the exception that there is no limit on the total length of the encoded name. The empty string is encoded identically to the name '.', as a single 0-octet. + - `parent` be a function that removes the first label from a name (eg, `parent('foo.eth') = 'eth'`). `parent('tld')` is defined as the empty string ''. + - `ens` is the ENS registry contract for the current network. + +EIP-2544-compliant ENS resolvers MAY implement the following function interface: + +``` +interface ExtendedResolver { + function resolve(bytes calldata name, bytes calldata data) external view returns(bytes); +} +``` + +If a resolver implements this function, it MUST return true when `supportsInterface()` is called on it with the interface's ID, 0xTBD. -1. Apply the namehash algorithm to the supplied name as specified in EIP-137 to derive the `node`. -2. Call the ENS Registry contract, supplying the node as the argument to `function resolver(bytes32 node) constant returns (address)`. -3. If an address other than the null address is returned, the client MUST use the returned address as the resolver. -4. If the null address is returned, the client MUST strip the leftmost label from the name to derive a new name. -5. If the only remaining label is a top-level domain, or if no labels remain, the client MUST refuse to interact with the resolver. -6. Apply the namehash algorithm to the new name as specified in EIP-137 to derive the `parentNode`. -7. Call the ENS Registry contract, supplying the parent node as the argument to `function resolver(bytes32 node) constant returns (address)` to determine the resolver. -8. If the null address is returned from this second request, the client MUST refuse to interact with the resolver. +ENS clients will call `resolve` with the DNS-encoded name to resolve and the encoded calldata for a resolver function (as specified in EIP-137 and elsewhere); the function MUST either return valid return data for that function, or revert if it is not supported. -In the event that a non-null resolver is located via this process, the client MUST supply the full, original `node` to the resolver to derive the address or other records. As with EIP-137, clients attempting to resolve an address via `function addr(bytes32 node) constant returns (address)` MUST refuse to interact with the returned address when the null address is returned. +EIP-2544-compliant ENS clients MUST perform the following procedure when determining the resolver for a given name: + +1. Set `currentname = name` +2. Set `resolver = ens.resolver(namehash(currentname))` +3. If `resolver` is not the zero address, halt and return `resolver`. +4. If `name` is the empty name ('' or '.'), halt and return null. +5. Otherwise, set `currentname = parent(currentname)` and go to 2. + +If the procedure above returns null, name resolution MUST terminate unsuccessfully. Otherwise, EIP-2544-compliant ENS clients MUST perform the following procedure when resolving a record: + +1. Set `calldata` to the ABI-encoded call data for the resolution function required - for example, the ABI encoding of `addr(namehash(name))` when resolving the `addr` record. +2. Set `supports2544 = resolver.supportsInterface(0xTBD)`. +3. If `supports2544` is true, set `result = resolver.resolve(dnsencode(name), calldata)` +4. Otherwise, set `result` to the result of calling `resolver` with `calldata`. +5. Return `result` after decoding it using the return data ABI of the corresponding resolution function (eg, for `addr()`, ABI-decode the result of `resolver.resolve()` as an `address`). + +Note that in all cases the resolution function (`addr()` etc) and the `resolve` function are supplied the original `name`, *not* the `currentname` found in the first stage of resolution. ### Pseudocode ``` -function getNodeAndResolver(name) { - // 1. Apply the namehash algorithm to supplied name to determine the node. - const node = namehash(name); - - // 2. Attempt to retrieve a resolver from the ENS Registry using the node. - let resolver = ENS_REGISTRY.methods.resolver(node).call(); - - // 3. Use the resolver if a non-null result is returned from the registry. - if (resolver != "0x0000000000000000000000000000000000000000") { - return (node, resolver); +function getResolver(name) { + for(let currentname = name; currentname !== ''; currentname = parent(currentname)) { + const node = namehash(currentname); + const resolver = ens.resolver(node); + if(resolver != '0x0000000000000000000000000000000000000000') { + return resolver; + } } - - // 4. Remove the leftmost label from the name. - const labelsWithoutLeftmost = name.split(".").slice(1); - - // 5. Do not continue if only the top-level domain (or no domain) remains. - if (labelsWithoutLeftmost.length < 2) { - throw new Error("ENS resolver not found."); + return null; +} + +function resolve(name, func, ...args) { + const resolver = getResolver(name); + if(resolver === null) { + return null; } - - // 6. Apply the namehash algorithm to new name to determine the parent node. - const parentNode = namehash(labelsWithoutLeftmost.join(".")); - - // 7. Attempt to retrieve a resolver from registry using the parent node. - resolver = ENS_REGISTRY.methods.resolver(parentNode).call(); - - // 8. Do not continue if a null result is returned from the registry. - if (resolver == "0x0000000000000000000000000000000000000000") { - throw new Error("ENS resolver not found."); + const supports2544 = resolver.supportsInterface('0xTBD'); + let result; + if(supports2544) { + const calldata = resolver[func].encodeFunctionCall(namehash(name), ...args); + result = resolver.resolve(dnsencode(name), calldata); + return resolver[func].decodeReturnData(result); + } else { + return resolver[func](...args); } - - // Return the located resolver along with the original node. - return (node, resolver); -}; +} ``` ## Rationale @@ -91,11 +105,13 @@ The proposed implementation supports wildcard resolution in a manner that minimi It also recognizes an existing consensus concerning the desirability of wildcard resolution for ENS, enabling more widespread adoption of the original specification by solving for a key scalability obstacle. -By not recursively applying the namehash operation after removing successive leftmost subdomains, round-trip requests are reduced and edge cases around overriding ownership of nested subdomains are adequately handled. ENS clients may optimize further for reduced latency by utilizing a helper contract that performs the logic necessary to support wildcard resolution. +While introducing an optional `resolve` function for resolvers, taking the unhashed name and calldata for a resolution function increases implementation complexity, it provides a means for resolvers to obtain plaintext labels and act accordingly, which enables many wildcard-related use-cases that would otherwise not be possible - for example, a wildcard resolver could resolve `id.nifty.eth` to the owner of the NFT with id `id` in some collection. With only namehashes to work with, this is not possible. Resolvers with simpler requirements can continue to simply implement resolution functions directly and omit support for the `resolve` function entirely. + +The DNS wire format is used for encoding names as it permits quick and gas-efficient hashing of names, as well as other common operations such as fetching or removing individual labels; in contrast, dot-separated names require iterating over every character in the name to find the delimiter. ## Backwards Compatibility -There are no backwards compatibility concerns — existing ENS clients that are compliant with EIP-137 will fail to resolve wildcard records and refuse to interact with them, while those compliant with EIP-2544 will continue to correctly resolve, or reject, existing ENS records. +Existing ENS clients that are compliant with EIP-137 will fail to resolve wildcard records and refuse to interact with them, while those compliant with EIP-2544 will continue to correctly resolve, or reject, existing ENS records. Resolvers wishing to implement the new `resolve` function for non-wildcard use-cases (eg, where the resolver is set directly on the name being resolved) should consider what to return to legacy clients that call the individual resolution functions for maximum compatibility. ## Security Considerations @@ -107,4 +123,4 @@ There is also the possibility that some applications might require that no resol ## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-2566.md b/EIPS/eip-2566.md index 00a1cb6fb3dda..3bc36a0f0ccb0 100644 --- a/EIPS/eip-2566.md +++ b/EIPS/eip-2566.md @@ -3,7 +3,7 @@ eip: 2566 title: Human Readable Parameters for Contract Function Execution author: Joseph Stockermans (@jstoxrocky) discussions-to: https://ethereum-magicians.org/t/human-readable-parameters-for-contract-function-execution/4154 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-03-23 diff --git a/EIPS/eip-2569.md b/EIPS/eip-2569.md index 482e769765726..97ec6bb386cdb 100644 --- a/EIPS/eip-2569.md +++ b/EIPS/eip-2569.md @@ -3,7 +3,7 @@ eip: 2569 title: Saving and Displaying Image Onchain for Universal Tokens author: Hua Zhang (@dgczhh), Yuefei Tan (@whtyfhas), Derek Zhou (@zhous) discussions-to: https://ethereum-magicians.org/t/erc-2569-saving-and-displaying-image-onchain-for-universal-tokens/4167 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-03-28 diff --git a/EIPS/eip-2583.md b/EIPS/eip-2583.md index 6514d9c9b92a3..20034a0b313ea 100644 --- a/EIPS/eip-2583.md +++ b/EIPS/eip-2583.md @@ -3,7 +3,7 @@ eip: 2583 title: Penalty for account trie misses author: Martin Holst Swende (@holiman) discussions-to: https://ethereum-magicians.org/t/eip-2583-penalties-for-trie-misses/4190 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-02-21 diff --git a/EIPS/eip-2584.md b/EIPS/eip-2584.md index 1e7b6e9978e8b..8f37752715d74 100644 --- a/EIPS/eip-2584.md +++ b/EIPS/eip-2584.md @@ -3,7 +3,7 @@ eip: 2584 title: Trie format transition with overlay trees author: Guillaume Ballet (@gballet) discussions-to: https://ethresear.ch/t/overlay-method-for-hex-bin-tree-conversion/7104 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-04-03 diff --git a/EIPS/eip-2593.md b/EIPS/eip-2593.md index 4fb7f0da7a96d..485b8e3712837 100644 --- a/EIPS/eip-2593.md +++ b/EIPS/eip-2593.md @@ -3,7 +3,7 @@ eip: 2593 title: Escalator fee market change for ETH 1.0 chain author: Dan Finlay discussions-to: https://ethresear.ch/t/another-simple-gas-fee-model-the-escalator-algorithm-from-the-agoric-papers/6399 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-03-13 diff --git a/EIPS/eip-2612.md b/EIPS/eip-2612.md index d23fa0931778a..a157bcffe914f 100644 --- a/EIPS/eip-2612.md +++ b/EIPS/eip-2612.md @@ -3,7 +3,7 @@ eip: 2612 title: permit – 712-signed approvals author: Martin Lundfall (@Mrchico) discussions-to: https://github.com/ethereum/EIPs/issues/2613 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-04-13 diff --git a/EIPS/eip-2615.md b/EIPS/eip-2615.md index 8f24badb67310..b1cbb1a70dec5 100644 --- a/EIPS/eip-2615.md +++ b/EIPS/eip-2615.md @@ -3,7 +3,7 @@ eip: 2615 title: Non-Fungible Token with mortgage and rental functions author: Kohshi Shiba discussions-to: https://github.com/ethereum/EIPs/issues/2616 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-04-25 diff --git a/EIPS/eip-2645.md b/EIPS/eip-2645.md index bdbe0349a6e92..1fba2e0decb2d 100644 --- a/EIPS/eip-2645.md +++ b/EIPS/eip-2645.md @@ -3,7 +3,7 @@ eip: 2645 title: Hierarchical Deterministic Wallet for Layer-2 author: Tom Brand , Louis Guthmann discussions-to: https://ethereum-magicians.org/t/hierarchical-deterministic-wallet-for-computation-integrity-proof-cip-layer-2/4286 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-05-13 diff --git a/EIPS/eip-2657.md b/EIPS/eip-2657.md index 182380482ce11..b32c5d65d7525 100644 --- a/EIPS/eip-2657.md +++ b/EIPS/eip-2657.md @@ -3,7 +3,7 @@ eip: 2657 title: Ephemeral Testnet Yolo author: James Hancock (@madeoftin) discussions-to: https://gitter.im/ethereum/AllCoreDevs -status: Draft +status: Stagnant type: Meta created: 2020-04-19 --- diff --git a/EIPS/eip-2666.md b/EIPS/eip-2666.md index 1c2de46647404..cde09112fabc3 100644 --- a/EIPS/eip-2666.md +++ b/EIPS/eip-2666.md @@ -3,7 +3,7 @@ eip: 2666 title: Repricing of precompiles and Keccak256 function author: Alex Vlasov (@shamatar) discussions-to: https://ethereum-magicians.org/t/eip2666-global-precompiles-repricing-and-many-more-discussion-thread/4332 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-05-22 diff --git a/EIPS/eip-2677.md b/EIPS/eip-2677.md index 749464a9ec793..959fdc1385e13 100644 --- a/EIPS/eip-2677.md +++ b/EIPS/eip-2677.md @@ -1,7 +1,7 @@ --- eip: 2677 title: Limit size of `initcode` -author: Martin Holst Swende (@holiman), Pawel Bylica (@chfast), Alex Beregszazi (@axic) +author: Martin Holst Swende (@holiman), Paweł Bylica (@chfast), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2677-limit-size-of-initcode/4550 status: Draft type: Standards Track diff --git a/EIPS/eip-2678.md b/EIPS/eip-2678.md index 9d183b0fd115e..22ba3f2ac3e13 100644 --- a/EIPS/eip-2678.md +++ b/EIPS/eip-2678.md @@ -4,7 +4,6 @@ title: Revised Ethereum Smart Contract Packaging Standard (EthPM v3) author: g. nicholas d’andrea (@gnidan), Piper Merriam (@pipermerriam), Nick Gheorghita (@njgheorghita), Christian Reitwiessner (@chriseth), Ben Hauser (@iamdefinitelyahuman), Bryant Eisenbach (@fubuloubu) discussions-to: https://ethereum-magicians.org/t/ethpm-v3-specification-working-group/4086 status: Final -review-period-end: 2021-04-14 type: Standards Track category: ERC created: 2020-05-26 diff --git a/EIPS/eip-2680.md b/EIPS/eip-2680.md index 50e9d9b59466b..f5b30ef1561f4 100644 --- a/EIPS/eip-2680.md +++ b/EIPS/eip-2680.md @@ -3,7 +3,7 @@ eip: 2680 title: Ethereum 2 wallet layout author: Jim McDonald discussions-to: https://ethereum-magicians.org/t/eip-2680-ethereum-2-wallet-layout/4323 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-05-29 diff --git a/EIPS/eip-2681.md b/EIPS/eip-2681.md index 983e01f3aac88..08cd67dbffe00 100644 --- a/EIPS/eip-2681.md +++ b/EIPS/eip-2681.md @@ -25,7 +25,7 @@ Lastly, this facilitates a minor optimisation in clients, because the nonce no l Introduce two new restrictions retroactively from genesis: -1. Consider any transaction invalid, where the nonce exceeds `2^64-1`. +1. Consider any transaction invalid, where the nonce exceeds or equals to `2^64-1`. 2. The `CREATE` and `CREATE2` instructions to abort with an exceptional halt, where the account nonce is `2^64-1`. ## Rationale @@ -37,13 +37,15 @@ This mode of replay protection is out of fashion since [EIP-155](./eip-155.md) i 3. Most clients already consider the nonce field to be 64-bit, such as go-ethereum. +4. The reason a transaction with nonce `2^64-1` is invalid, because otherwise after inclusion the sender account's nonce would exceed `2^64-1`. + ## Backwards Compatibility While this is a breaking change, no actual effect should be visible: 1. There is no account in the state currently which would have a nonce exceeding that value. As of November 2020, the account `0xea674fdde714fd979de3edf0f56aa9716b898ec8` is responsible for the highest account nonce at approximately 29 million. -2. go-ethereum already has this restriction in place (`state.Account.Nonce` and `types.txdata.AccountNonce` it as a 64-bit number). +2. go-ethereum already has this restriction partially in place (`state.Account.Nonce` and `types.txdata.AccountNonce` it as a 64-bit number). ## Security Considerations diff --git a/EIPS/eip-2711.md b/EIPS/eip-2711.md index 5d7e16a4014c1..592b056b3184b 100644 --- a/EIPS/eip-2711.md +++ b/EIPS/eip-2711.md @@ -3,7 +3,7 @@ eip: 2711 title: Sponsored, expiring and batch transactions. author: Micah Zoltu (@MicahZoltu) discussions-to: https://ethereum-magicians.org/t/eip-2711-separate-gas-payer-from-msg-sender/4353 -status: Draft +status: Withdrawn type: Standards Track category: Core created: 2020-06-11 diff --git a/EIPS/eip-2718.md b/EIPS/eip-2718.md index 5fa82766e14b9..a4723b1269294 100644 --- a/EIPS/eip-2718.md +++ b/EIPS/eip-2718.md @@ -19,7 +19,7 @@ This was seen in [EIP-155](./eip-155.md) where the new value was bit-packed into There are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides `msg.sender` to pay for gas, and proposals related to layer 1 multi-sig transactions. These all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type. -By introducing an envolope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between `TransactionType`s. +By introducing an envelope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between `TransactionType`s. ## Specification ### Definitions diff --git a/EIPS/eip-2733.md b/EIPS/eip-2733.md index 57d6d0a749a22..45e261ca2af6c 100644 --- a/EIPS/eip-2733.md +++ b/EIPS/eip-2733.md @@ -3,11 +3,12 @@ eip: 2733 title: Transaction Package author: Matt Garnett (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-transaction-package/4365 -status: Draft +status: Withdrawn type: Standards Track category: Core created: 2020-06-16 requires: 2718 +withdrawal-reason: I have decided to pursue EIP-3074 as the preferred solution to transaction packages. --- ## Simple Summary diff --git a/EIPS/eip-2746.md b/EIPS/eip-2746.md index fc006be63b073..bb8d5273e13bc 100644 --- a/EIPS/eip-2746.md +++ b/EIPS/eip-2746.md @@ -3,7 +3,7 @@ eip: 2746 title: Rules Engine Standard author: Aaron Kendall (@jaerith), Juan Blanco (@juanfranblanco) discussions-to: https://ethereum-magicians.org/t/eip-2746-rules-engine-interface/4435 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-06-20 diff --git a/EIPS/eip-2767.md b/EIPS/eip-2767.md index bec3ccc440b14..20ca6725df7fd 100644 --- a/EIPS/eip-2767.md +++ b/EIPS/eip-2767.md @@ -3,7 +3,7 @@ eip: 2767 title: Contract Ownership Governance author: Soham Zemse (@zemse), Nick Mudge (@mudgen) discussions-to: https://github.com/ethereum/EIPs/issues/2766 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-07-04 diff --git a/EIPS/eip-2770.md b/EIPS/eip-2770.md index c8ba49abf93df..d82ae1a82da68 100644 --- a/EIPS/eip-2770.md +++ b/EIPS/eip-2770.md @@ -3,7 +3,7 @@ eip: 2770 title: Meta-Transactions Forwarder Contract author: Alex Forshtat (@forshtat), Dror Tirosh (@drortirosh) discussions-to: https://ethereum-magicians.org/t/erc-2770-meta-transactions-forwarder-contract/5391 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-07-01 diff --git a/EIPS/eip-2786.md b/EIPS/eip-2786.md index f192d335bef35..c553a0fad8f5a 100644 --- a/EIPS/eip-2786.md +++ b/EIPS/eip-2786.md @@ -4,7 +4,6 @@ title: Ethereum Provider Connect/Disconnect Events author: Micah Zoltu (@MicahZoltu), Erik Marks (@rekmarks) discussions-to: https://github.com/ethereum/EIPs/issues/2787 status: Withdrawn -review-period-end: 2020-07-31 type: Standards Track category: Interface created: 2020-07-15 diff --git a/EIPS/eip-2803.md b/EIPS/eip-2803.md index 0f1dc7ccbd170..792945c0f8ce0 100644 --- a/EIPS/eip-2803.md +++ b/EIPS/eip-2803.md @@ -1,26 +1,24 @@ --- eip: 2803 title: Rich Transactions +description: Support 'rich transactions' by allowing transactions from externally owned accounts to execute bytecode directly. author: Micah Zoltu (@MicahZoltu) discussions-to: https://ethereum-magicians.org/t/rich-transactions-via-evm-bytecode-execution-from-externally-owned-accounts/4025 -status: Draft +status: Review type: Standards Track category: Core created: 2020-07-18 --- -## Simple Summary -Support 'rich transactions' by allowing transactions from externally owned accounts to execute bytecode directly. - ## Abstract -If a transaction has a `to` of address `x`, then the `data` of the transaction will be treated as EVM bytecode and executed from the context of the `CALLER` of the transaction (aka: the transaction signer at the moment). +If a transaction has a `to` of address `x`, then the `data` of the transaction will be treated as EVM bytecode and it will be executed from the context of the `CALLER` of the transaction (aka: the transaction signer). ## Motivation Many Ethereum DApps presently require users to approve multiple transactions in order to produce one effect - for example, the common pattern of first approving a contract to spend a token, then calling that contract. This results in a poor user-experience, and complicates the experience of interacting with DApps. Making it possible for externally owned accounts to execute EVM bytecode directly allows a single transaction to execute multiple contract calls, allowing DApps to provide a streamlined experience, where every interaction results in at most one transaction. -While this is in principle possible today using contract wallets, other UX issues, such as the need to fund a sending account with gas money, lack of support for contract wallets in browser integrations, and lack of a consistent API for contract wallets has led to poor adoption of these. We propose this EIP as a way of enhancing the utility of existing EOAs, in the spirit of "don't let the perfect be the enemy of the good". +While this is in principle possible today using contract wallets, other UX issues, such as the need to fund a sending account with gas money, lack of support for contract wallets in browser integrations, and lack of a consistent API for contract wallets has led to poor adoption of these.This EIP is a way of enhancing the utility of existing EOAs, in the spirit of "don't let the perfect be the enemy of the good". ## Specification A new reserved address is specified at `x`, in the range used for precompiles. When a transaction is sent to this address from an externally owned account, the payload of the transaction is treated as EVM bytecode, and executed with the signer of the transaction as the current account. For clarity: @@ -30,10 +28,10 @@ A new reserved address is specified at `x`, in the range used for precompiles. W - `CALL` will set the `CALLER` to the EOA (not `x`). - `DELEGATECALL` preserves the EOA as the owning account. - The `CALLER` and `ORIGIN` opcodes both return the address of the EOA that signed the transaction. - - There is no code associated with the precompile address. `CODE*` and `EXTCODE*` opcodes do not return the transaction payload. + - There is no code associated with the precompile address. `CODE*` and `EXTCODE*` opcodes behave the same as they do for any empty address. - `CALLDATA*` opcodes operate on the transaction payload as expected. - `SLOAD` and `SSTORE` operate on the storage of the EOA. As a result, an EOA can have data in storage, that persists between transactions. - - The `SELFDESTRUCT` opcode transfers the balance of the EOA to the specified address, and at the end of the transaction zeroes out the account's state storage, but does not zero the account's nonce. No refund is applied for the `SELFDESTRUCT` at the end of the transaction. + - The `SELFDESTRUCT` opcode does nothing. - All other opcodes behave as expected for a call to a contract address. - The transaction is invalid if there is any value attached. - A call to the precompile address from a contract has no special effect and is equivalent to a call to a nonexistent precompile or an empty address. @@ -48,11 +46,5 @@ This EIP introduces a new feature that will need to be implemented in a future h Contracts or DApps that assume that an EOA cannot atomically perform multiple operations may be affected by this change, as this now makes it possible for EOAs to execute multiple atomic operations together. The authors do not believe this is a significant use-case, as this 'protection' is already trivially defeated by miners. -## Test Cases -TBD. - -## Implementation -None yet. - ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-2831.md b/EIPS/eip-2831.md index 04208503a94f8..353232a671468 100644 --- a/EIPS/eip-2831.md +++ b/EIPS/eip-2831.md @@ -3,7 +3,7 @@ eip: 2831 title: Transaction Replacement Message Type author: Gregory Markou (@GregTheGreek) discussions-to: https://ethereum-magicians.org/t/eip-2831-transaction-replacement-message-type/4448 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-07-26 diff --git a/EIPS/eip-2844.md b/EIPS/eip-2844.md index 9edc9c64eed58..58d182115ab16 100644 --- a/EIPS/eip-2844.md +++ b/EIPS/eip-2844.md @@ -3,7 +3,7 @@ eip: 2844 title: Add DID related methods to the JSON-RPC author: Joel Thorstensson (@oed) discussions-to: https://github.com/ethereum/EIPs/issues/2845 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-08-01 diff --git a/EIPS/eip-2876.md b/EIPS/eip-2876.md index 3db042e096ed9..27a1512aff954 100644 --- a/EIPS/eip-2876.md +++ b/EIPS/eip-2876.md @@ -3,7 +3,7 @@ eip: 2876 title: Deposit contract and address standard author: Jonathan Underwood (@junderw) discussions-to: https://github.com/junderw/deposit-contract-poc/issues/1 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-08-13 diff --git a/EIPS/eip-2917.md b/EIPS/eip-2917.md index 84e9b4d33e9f7..235e9c7e1afe1 100644 --- a/EIPS/eip-2917.md +++ b/EIPS/eip-2917.md @@ -3,7 +3,7 @@ eip: 2917 title: Staking Reward Calculation author: Tony Carson , Mehmet Sabir Kiraz , Süleyman Kardaş discussions-to: https://github.com/ethereum/EIPs/issues/2925 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-08-28 diff --git a/EIPS/eip-2926.md b/EIPS/eip-2926.md index 70aa5b1e3f4b1..5f8a9698ffda7 100644 --- a/EIPS/eip-2926.md +++ b/EIPS/eip-2926.md @@ -3,7 +3,7 @@ eip: 2926 title: Chunk-Based Code Merkleization author: Sina Mahmoodi (@s1na), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2926-chunk-based-code-merkleization/4555 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-08-25 diff --git a/EIPS/eip-2935.md b/EIPS/eip-2935.md index 22383207384d5..31ae2ead8bef7 100644 --- a/EIPS/eip-2935.md +++ b/EIPS/eip-2935.md @@ -3,7 +3,7 @@ eip: 2935 title: Save historical block hashes in state author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak) discussions-to: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565 -status: Review +status: Stagnant type: Standards Track category: Core created: 2020-09-03 diff --git a/EIPS/eip-2936.md b/EIPS/eip-2936.md index 92f5e18ccf117..92bcbffa8a059 100644 --- a/EIPS/eip-2936.md +++ b/EIPS/eip-2936.md @@ -3,7 +3,7 @@ eip: 2936 title: EXTCLEAR Opcode For SELFDESTRUCTed contracts author: William Morriss (@wjmelements) discussions-to: https://ethereum-magicians.org/t/eip-2936-extclear-for-selfdestruct/4569 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-09-03 diff --git a/EIPS/eip-2937.md b/EIPS/eip-2937.md index 17e79f2f540a4..d176e36d93ce4 100644 --- a/EIPS/eip-2937.md +++ b/EIPS/eip-2937.md @@ -3,7 +3,7 @@ eip: 2937 title: SET_INDESTRUCTIBLE opcode author: Vitalik Buterin (@vbuterin) discussions-to: https://ethereum-magicians.org/t/eip-2937-set-indestructible/4571 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-09-04 diff --git a/EIPS/eip-2942.md b/EIPS/eip-2942.md index 3a3df32b728f4..6bd5d5e982d04 100644 --- a/EIPS/eip-2942.md +++ b/EIPS/eip-2942.md @@ -3,7 +3,7 @@ eip: 2942 title: EthPM URI Specification author: Nick Gheorghita (@njgheorghita), Piper Merriam (@pipermerriam), g. nicholas d'andrea (@gnidan), Benjamin Hauser (@iamdefinitelyahuman) discussions-to: https://ethereum-magicians.org/t/ethpm-v3-specification-working-group/4086/7 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-09-04 diff --git a/EIPS/eip-2970.md b/EIPS/eip-2970.md index 92f2463f79193..95bd62139929c 100644 --- a/EIPS/eip-2970.md +++ b/EIPS/eip-2970.md @@ -3,7 +3,7 @@ eip: 2970 title: IS_STATIC opcode author: Vitalik Buterin (@vbuterin) discussions-to: https://ethereum-magicians.org/t/is-static-opcode-useful-for-aa/4609 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-09-13 diff --git a/EIPS/eip-2976.md b/EIPS/eip-2976.md index 04ad6dae9117c..d92cb8799a429 100644 --- a/EIPS/eip-2976.md +++ b/EIPS/eip-2976.md @@ -3,10 +3,11 @@ eip: 2976 title: 'Typed Transactions over Gossip' author: Micah Zoltu (@MicahZoltu) discussions-to: https://ethereum-magicians.org/t/eip-2976-eth-typed-transactions-over-gossip/4610 -status: Review +status: Last Call type: Standards Track category: Networking created: 2020-09-13 +last-call-deadline: 2021-10-06 requires: 2718 --- diff --git a/EIPS/eip-2980.md b/EIPS/eip-2980.md index 459c34858e6f1..831e549a3415a 100644 --- a/EIPS/eip-2980.md +++ b/EIPS/eip-2980.md @@ -3,7 +3,7 @@ eip: 2980 title: Swiss Compliant Asset Token author: Gianluca Perletti (@Perlets9), Alan Scarpellini (@alanscarpellini), Roberto Gorini (@robertogorini), Manuel Olivi (@manvel79) discussions-to: https://github.com/ethereum/EIPs/issues/2983 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-09-08 diff --git a/EIPS/eip-2997.md b/EIPS/eip-2997.md index 13197c2f4e0d9..3c88aae74f770 100644 --- a/EIPS/eip-2997.md +++ b/EIPS/eip-2997.md @@ -5,7 +5,7 @@ author: Sergio Demian Lerner (@SergioDemianLerner) discussions-to: https://ethresear.ch/t/impersonatecall-opcode/8020 category: Core type: Standards Track -status: Draft +status: Stagnant created: 2020-09-24 --- diff --git a/EIPS/eip-3000.md b/EIPS/eip-3000.md index 9f3f17c579972..62a630f553bf6 100644 --- a/EIPS/eip-3000.md +++ b/EIPS/eip-3000.md @@ -3,7 +3,7 @@ eip: 3000 title: Optimistic enactment governance standard author: Jorge Izquierdo (@izqui), Fabien Marino (@bonustrack) discussions-to: https://github.com/ethereum/EIPs/issues/3042 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-09-24 diff --git a/EIPS/eip-3005.md b/EIPS/eip-3005.md index 58c8b85e9f63e..69732e81c53f7 100644 --- a/EIPS/eip-3005.md +++ b/EIPS/eip-3005.md @@ -3,7 +3,7 @@ eip: 3005 title: Batched meta transactions author: Matt (@defifuture) discussions-to: https://ethereum-magicians.org/t/eip-3005-the-economic-viability-of-batched-meta-transactions/4673 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-09-25 diff --git a/EIPS/eip-3009.md b/EIPS/eip-3009.md index 588a4a3bb257f..8292eaf33672d 100644 --- a/EIPS/eip-3009.md +++ b/EIPS/eip-3009.md @@ -3,7 +3,7 @@ eip: 3009 title: Transfer With Authorization author: Peter Jihoon Kim (@petejkim), Kevin Britz (@kbrizzle), David Knott (@DavidLKnott) discussions-to: https://github.com/ethereum/EIPs/issues/3010 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-09-28 diff --git a/EIPS/eip-3026.md b/EIPS/eip-3026.md index 6af4f5d59df72..470ff192262c8 100644 --- a/EIPS/eip-3026.md +++ b/EIPS/eip-3026.md @@ -3,7 +3,7 @@ eip: 3026 title: BW6-761 curve operations author: Youssef El Housni (@yelhousni), Michael Connor (@iAmMichaelConnor), Aurore Guillevic discussions-to: https://ethereum-magicians.org/t/eip-3026-bw6-761-curve-operations/4790 -status: Draft +status: Stagnant type: Standards Track category: Core requires: 2539 diff --git a/EIPS/eip-3030.md b/EIPS/eip-3030.md index 25da7195c9be2..8e07e64e9f4bf 100644 --- a/EIPS/eip-3030.md +++ b/EIPS/eip-3030.md @@ -3,7 +3,7 @@ eip: 3030 title: BLS Remote Signer HTTP API author: Herman Junge (@hermanjunge) discussions-to: https://ethereum-magicians.org/t/eip-3030-bls-remote-signer-http-api-standard/4810 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-09-30 diff --git a/EIPS/eip-3041.md b/EIPS/eip-3041.md index 20fb247014f38..7a4c24fe5e185 100644 --- a/EIPS/eip-3041.md +++ b/EIPS/eip-3041.md @@ -3,7 +3,7 @@ eip: 3041 title: Adds `baseFee` to `eth_getBlockByHash` author: Abdelhamid Bakhta (@abdelhamidbakhta) discussions-to: https://ethereum-magicians.org/t/eip-3041-add-basefee-in-eth-getblockbyhash-response/4825 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-10-13 diff --git a/EIPS/eip-3044.md b/EIPS/eip-3044.md index 9dcd9870214c6..a3b18ad43d180 100644 --- a/EIPS/eip-3044.md +++ b/EIPS/eip-3044.md @@ -3,7 +3,7 @@ eip: 3044 title: Adds `baseFee` to `eth_getBlockByNumber` author: Abdelhamid Bakhta (@abdelhamidbakhta) discussions-to: https://ethereum-magicians.org/t/eip-3044-add-basefee-to-eth-getblockbynumber/4828 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-10-14 diff --git a/EIPS/eip-3045.md b/EIPS/eip-3045.md index 07f0c4ab9945f..20837b3123637 100644 --- a/EIPS/eip-3045.md +++ b/EIPS/eip-3045.md @@ -3,7 +3,7 @@ eip: 3045 title: Adds `baseFee` to `eth_getUncleByBlockHashAndIndex` author: Abdelhamid Bakhta (@abdelhamidbakhta) discussions-to: https://ethereum-magicians.org/t/add-basefee-to-eth-getunclebyblockhashandindex/4829 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-10-14 diff --git a/EIPS/eip-3046.md b/EIPS/eip-3046.md index 0804a25defda1..9e77d2b0b4df6 100644 --- a/EIPS/eip-3046.md +++ b/EIPS/eip-3046.md @@ -3,7 +3,7 @@ eip: 3046 title: Adds `baseFee` to `eth_getUncleByBlockNumberAndIndex` author: Abdelhamid Bakhta (@abdelhamidbakhta) discussions-to: https://ethereum-magicians.org/t/add-basefee-to-eth-getunclebyblocknumberandindex/4830 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-10-14 diff --git a/EIPS/eip-3068.md b/EIPS/eip-3068.md index 6a27b8bbf416d..ed388e2214150 100644 --- a/EIPS/eip-3068.md +++ b/EIPS/eip-3068.md @@ -3,7 +3,7 @@ eip: 3068 title: Precompile for BN256 HashToCurve Algorithms author: Dr. Christopher Gorman (@chgormanMH) discussions-to: https://ethereum-magicians.org/t/pre-compile-for-bls/3973 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-10-23 diff --git a/EIPS/eip-3074.md b/EIPS/eip-3074.md index 2a794039c63a7..9a10313a81148 100644 --- a/EIPS/eip-3074.md +++ b/EIPS/eip-3074.md @@ -265,7 +265,9 @@ Sending non-zero value with `CALL` increases its cost by 9,000. Of that, 6,700 c ## Backwards Compatibility -No known issues. +Although this EIP poses no issues for backwards compatibility, there are concerns that it limits future changes to accounts by further enshrining ECDSA signatures. For example, it might be desirable to erradicate the concept of EOAs altogether, and replace them with smart contract wallets that emulate the same behavior. This is fully compatible with the EIP as written, however, it gets tricky if users can then elect to "upgrade" their smart contract wallets to use other methods of authentication -- e.g. convert into a multisig. Without any changes, `AUTH` would not respect this new logic and continue allowing the old private key to perform actions on behalf of the account. + +A solution to this would be at the same time that EOAs are removed, to modify the logic of `AUTH` to actually call into the account with some standard message and allow the account to determine if the signature / witness is valid. Further research should be done to understand how invokers would need to change in this situation and how best to write them in a future-compatible manner. ## Security Considerations diff --git a/EIPS/eip-3076.md b/EIPS/eip-3076.md index c55c8ae9dbbd0..0891db4067a04 100644 --- a/EIPS/eip-3076.md +++ b/EIPS/eip-3076.md @@ -1,19 +1,16 @@ --- eip: 3076 title: Slashing Protection Interchange Format +description: A JSON interchange format for proof of stake validators to migrate slashing protection data between clients. author: Michael Sproul (@michaelsproul), Sacha Saint-Leger (@sachayves), Danny Ryan (@djrtwo) discussions-to: https://ethereum-magicians.org/t/eip-3076-validator-client-interchange-format-slashing-protection/ -status: Review +status: Last Call type: Standards Track -category: Core +category: Interface created: 2020-10-27 -updated: 2021-02-08 +last-call-deadline: 2021-11-03 --- -## Simple Summary - -A JSON interchange format for proof of stake validators to migrate slashing protection data between clients. - ## Abstract A standard format for transferring a key's signing history allows validators to easily switch between clients without the risk of signing conflicting messages. While a [common keystore format](https://eips.ethereum.org/EIPS/eip-2335) provides part of the solution, it does not contain any information about a key's signing history. For a validator moving their keys from client A to client B, this could lead to scenarios in which client B inadvertently signs a message that conflicts with an earlier message signed with client A. The interchange format described here provides a solution to this problem. diff --git a/EIPS/eip-3085.md b/EIPS/eip-3085.md index 964d3697a95aa..81f354e630774 100644 --- a/EIPS/eip-3085.md +++ b/EIPS/eip-3085.md @@ -3,7 +3,7 @@ eip: 3085 title: Wallet Add Ethereum Chain RPC Method (`wallet_addEthereumChain`) author: Erik Marks (@rekmarks), Pedro Gomes (@pedrouid) discussions-to: https://ethereum-magicians.org/t/eip-3085-wallet-addethereumchain/5469 -status: Review +status: Stagnant type: Standards Track category: Interface created: 2020-11-01 diff --git a/EIPS/eip-3091.md b/EIPS/eip-3091.md index c6d06834eb357..b7d30e71a1e00 100644 --- a/EIPS/eip-3091.md +++ b/EIPS/eip-3091.md @@ -3,7 +3,7 @@ eip: 3091 title: Block Explorer API Routes author: Pedro Gomes (@pedrouid) discussions-to: https://ethereum-magicians.org/t/eip-3091-block-explorer-api-routes/4907 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-11-02 diff --git a/EIPS/eip-3135.md b/EIPS/eip-3135.md index 5dbe26b3773e4..ebef6a7461d19 100644 --- a/EIPS/eip-3135.md +++ b/EIPS/eip-3135.md @@ -3,7 +3,7 @@ eip: 3135 title: Exclusive Claimable Token author: Zhenyu Sun (@Ungigdu) discussions-to: https://github.com/ethereum/EIPs/issues/3132 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2020-08-10 diff --git a/EIPS/eip-3143.md b/EIPS/eip-3143.md index af60a8a77d5b7..65d0749e57ae0 100644 --- a/EIPS/eip-3143.md +++ b/EIPS/eip-3143.md @@ -3,7 +3,7 @@ eip: 3143 title: Increase block rewards to 5 ETH author: Ben Tinner (@Terra854) discussions-to: https://ethereum-magicians.org/t/eip-3143-increase-block-rewards-to-5-eth/5061 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-12-01 diff --git a/EIPS/eip-3155.md b/EIPS/eip-3155.md index 5bf68b5d03a14..d6fb8c27545ec 100644 --- a/EIPS/eip-3155.md +++ b/EIPS/eip-3155.md @@ -3,7 +3,7 @@ eip: 3155 title: EVM trace specification author: Martin Holst Swende (@holiman), Marius van der Wijden (@MariusVanDerWijden) discussions-to: https://ethereum-magicians.org/t/eip-3155-create-evm-trace-specification/5007 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2020-12-07 diff --git a/EIPS/eip-3220.md b/EIPS/eip-3220.md index 8aef74d1759ea..5acd91e1b164c 100644 --- a/EIPS/eip-3220.md +++ b/EIPS/eip-3220.md @@ -3,7 +3,7 @@ eip: 3220 title: Crosschain Identifier Specification author: Weijia Zhang (@weijia31415), Peter Robinson (@drinkcoffee) discussions-to: https://ethereum-magicians.org/t/eip-3220-crosschain-id-specification/5446 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-10-21 diff --git a/EIPS/eip-3224.md b/EIPS/eip-3224.md index 94b48a572b15f..5179092089074 100644 --- a/EIPS/eip-3224.md +++ b/EIPS/eip-3224.md @@ -1,6 +1,7 @@ --- eip: 3224 -title: Described Data and Described Transactions +title: Described Data +description: Contract method to compute human-readable descriptions for signable data. author: Richard Moore (@ricmoo), Nick Johnson (@arachnid) discussions-to: https://github.com/ethereum/EIPs/issues/3225 status: Draft @@ -10,12 +11,6 @@ created: 2021-01-23 requires: 191 --- -## Simple Summary - -A technique for contract authors to enable wallets to provide -a human-readable description of what a given contract -interaction (via a transaction or signed message) will perform. - ## Abstract @@ -266,8 +261,8 @@ there should be no concerns with backwards compatibility. All test cases operate against the published and verified contracts: -- [Formatter](https://ropsten.etherscan.io/address/0x7a89c0521604008c93c97aa76950198bca73d933#code) -- [TestFormatter](https://ropsten.etherscan.io/address/0xab3045aa85cbcabb06ed3f3fe968fa5457727270#code) +- Formatter: Ropsten @ 0x7a89c0521604008c93c97aa76950198bca73d933 +- TestFormatter: Ropsten @ 0xab3045aa85cbcabb06ed3f3fe968fa5457727270 The private key used for signing messages and transactions is: @@ -402,12 +397,12 @@ Wallets must be careful when displaying text provided by contracts and proper efforts must be taken to sanitize it, for example, be sure to consider: -- HTML could be enbedded to attempt to trick web-based wallets into [executing code](https://en.wikipedia.org/wiki/Code_injection) using the script tag (possibly uploading any private keys to a server) +- HTML could be embedded to attempt to trick web-based wallets into executing code using the script tag (possibly uploading any private keys to a server) - In general, extreme care must be used when rendering HTML; consider the ENS names `not-ricmoo.eth` or ` ricmoo.eth`, which if rendered without care would appear as `ricmoo.eth`, which it is not -- Other marks which require escaping could be included, such as quotes (`"`), formatting (`\n` (new line), `\f` (form feed), `\t` (tab), any of many [non-standard whitespaces](https://en.wikipedia.org/wiki/Whitespace_character#Spaces_in_Unicode)), back-slassh (`\`) -- UTF-8 has had bugs in the past which could allow arbitrary code execution and [crashing renderers](https://osxdaily.com/2015/05/27/bug-crashes-messages-app-ios-workaround/); consider using the UTF-8 replacement character (or *something*) for code-points outside common planes or common sub-sets within planes -- [Homoglyphs attacks](https://en.wikipedia.org/wiki/IDN_homograph_attack) -- [Right-to-left](https://en.wikipedia.org/wiki/Right-to-left_mark) mark may affect rendering +- Other marks which require escaping could be included, such as quotes (`"`), formatting (`\n` (new line), `\f` (form feed), `\t` (tab), any of many non-standard whitespaces), back-slassh (`\`) +- UTF-8 has had bugs in the past which could allow arbitrary code execution and crashing renderers; consider using the UTF-8 replacement character (or *something*) for code-points outside common planes or common sub-sets within planes +- Homoglyphs attacks +- Right-to-left marks may affect rendering - Many other things, deplnding on your environment ### Distinguished Signed Data diff --git a/EIPS/eip-3234.md b/EIPS/eip-3234.md index cc8d88a883a3f..9163cd28e3bc7 100644 --- a/EIPS/eip-3234.md +++ b/EIPS/eip-3234.md @@ -3,7 +3,7 @@ eip: 3234 title: Batch Flash Loans author: Alberto Cuesta Cañada (@albertocuestacanada), Fiona Kobayashi (@fifikobayashi), fubuloubu (@fubuloubu), Austin Williams (@onewayfunction) discussions-to: https://ethereum-magicians.org/t/erc-3234-batch-flash-loans/5271 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2021-01-31 diff --git a/EIPS/eip-3238.md b/EIPS/eip-3238.md index 4ed573cce5ec4..69a146c866a2d 100644 --- a/EIPS/eip-3238.md +++ b/EIPS/eip-3238.md @@ -5,7 +5,7 @@ author: Afri Schoedon (@q9f) discussions-to: https://github.com/ethereum/EIPs/issues/3239 type: Standards Track category: Core -status: Draft +status: Stagnant created: 2021-01-25 --- diff --git a/EIPS/eip-3267.md b/EIPS/eip-3267.md index fc489da16a499..bd015b55a216c 100644 --- a/EIPS/eip-3267.md +++ b/EIPS/eip-3267.md @@ -3,7 +3,7 @@ eip: 3267 title: Giving Ethereum fees to Future Salaries author: Victor Porton (@vporton), Victor Porton discussions-to: https://ethereum-magicians.org/t/discussion-of-eip-3267/5343 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-02-13 diff --git a/EIPS/eip-3298.md b/EIPS/eip-3298.md index fa32af840a2ee..981b50d296309 100644 --- a/EIPS/eip-3298.md +++ b/EIPS/eip-3298.md @@ -3,7 +3,7 @@ eip: 3298 title: Removal of refunds author: Vitalik Buterin (@vbuterin), Martin Swende (@holiman) discussions-to: https://ethereum-magicians.org/t/eip-3298-removal-of-refunds/5430 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-02-26 diff --git a/EIPS/eip-3300.md b/EIPS/eip-3300.md index 8ca17c5ee7770..e4750d8a04851 100644 --- a/EIPS/eip-3300.md +++ b/EIPS/eip-3300.md @@ -3,7 +3,7 @@ eip: 3300 title: Phase out refunds author: William Morriss (@wjmelements) discussions-to: https://ethereum-magicians.org/t/eip-3300-phase-out-refunds/5434 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-02-26 diff --git a/EIPS/eip-3322.md b/EIPS/eip-3322.md index 19d358f2402cc..53c70017e1217 100644 --- a/EIPS/eip-3322.md +++ b/EIPS/eip-3322.md @@ -3,7 +3,7 @@ eip: 3322 title: Account gas storage opcodes author: William Morriss (@wjmelements) discussions-to: https://ethereum-magicians.org/t/eip-3322-efficient-gas-storage/5470 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2020-03-04 diff --git a/EIPS/eip-3336.md b/EIPS/eip-3336.md index abc79a0725f35..3a798ac57918d 100644 --- a/EIPS/eip-3336.md +++ b/EIPS/eip-3336.md @@ -3,7 +3,7 @@ eip: 3336 title: Paged memory allocation for the EVM author: Nick Johnson (@arachnid) discussions-to: https://ethereum-magicians.org/t/eips-3336-and-3337-improving-the-evms-memory-model/5482 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-03-06 diff --git a/EIPS/eip-3337.md b/EIPS/eip-3337.md index 6a93ee2bd7281..cc7e2b87715a8 100644 --- a/EIPS/eip-3337.md +++ b/EIPS/eip-3337.md @@ -3,7 +3,7 @@ eip: 3337 title: Frame pointer support for memory load and store operations author: Nick Johnson (@arachnid) discussions-to: https://ethereum-magicians.org/t/eips-3336-and-3337-improving-the-evms-memory-model/5482 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-03-06 diff --git a/EIPS/eip-3338.md b/EIPS/eip-3338.md index a114ff8439c35..4a6bffbca27c3 100644 --- a/EIPS/eip-3338.md +++ b/EIPS/eip-3338.md @@ -4,6 +4,7 @@ title: Limit account nonce to 2^52 author: Micah Zoltu (@MicahZoltu), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2681-limit-account-nonce-to-2-64-1/4324 status: Withdrawn +withdrawal-reason: Withdrawn in favor of [EIP-2681](./eip-2681.md) type: Standards Track category: Core created: 2021-03-07 diff --git a/EIPS/eip-3368.md b/EIPS/eip-3368.md index bf5e49f4a2905..d3f9785105a3f 100644 --- a/EIPS/eip-3368.md +++ b/EIPS/eip-3368.md @@ -3,7 +3,7 @@ eip: 3368 title: Increase block rewards to 3 ETH, with 2 Year Decay to 1 ETH Scheduled author: Michael D. Carter (@BitsBeTrippin) discussions-to: https://ethereum-magicians.org/t/eip-3368-block-reward-increase-w-decay-for-next-two-years/5550 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-03-12 diff --git a/EIPS/eip-3372.md b/EIPS/eip-3372.md index 173bb49421374..190de71e09446 100644 --- a/EIPS/eip-3372.md +++ b/EIPS/eip-3372.md @@ -1,7 +1,7 @@ --- eip: 3372 title: 5 FNV primes for ethash -status: Draft +status: Stagnant type: Standards Track category: Core author: mineruniter969 (@mineruniter969), mineruniter969 diff --git a/EIPS/eip-3382.md b/EIPS/eip-3382.md index e39e28c76feef..f1cd4a3ee69e1 100644 --- a/EIPS/eip-3382.md +++ b/EIPS/eip-3382.md @@ -4,6 +4,7 @@ title: Hardcoded Block Gas Limit author: Philippe Castonguay (@PhABC) discussions-to: https://ethereum-magicians.org/t/eip-3382-hardcoded-gas-limit status: Withdrawn +withdrawal-reason: The author prefers [EIP-3756](./eip-3756.md) type: Standards Track category: Core created: 2021-03-13 diff --git a/EIPS/eip-3403.md b/EIPS/eip-3403.md index 8684051733bf0..73f01e63fbb89 100644 --- a/EIPS/eip-3403.md +++ b/EIPS/eip-3403.md @@ -3,7 +3,7 @@ eip: 3403 title: Partial removal of refunds author: Vitalik Buterin (@vbuterin), Martin Swende (@holiman) discussions-to: https://ethereum-magicians.org/t/eip-3298-removal-of-refunds/5430 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-03-16 diff --git a/EIPS/eip-3416.md b/EIPS/eip-3416.md index 7c9ab1e1de41b..a7c6e038adb7d 100644 --- a/EIPS/eip-3416.md +++ b/EIPS/eip-3416.md @@ -3,7 +3,7 @@ eip: 3416 title: Median Gas Premium author: HexZorro (@hexzorro), Mojtaba Tefagh (@mtefagh) discussions-to: https://ethereum-magicians.org/t/eip-3416-median-gas-premium/5755 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-03-18 diff --git a/EIPS/eip-3436.md b/EIPS/eip-3436.md index 3e94cb07ffea8..fbbe405139ab8 100644 --- a/EIPS/eip-3436.md +++ b/EIPS/eip-3436.md @@ -5,7 +5,7 @@ author: Danno Ferrin (@shemnon) discussions-to: https://ethereum-magicians.org/t/eip-3436-expanded-clique-block-choice-rule/5809 status: Review type: Standards Track -category: Networking +category: Core created: 2021-03-25 requires: 225 --- diff --git a/EIPS/eip-3450.md b/EIPS/eip-3450.md index b6c13f50f9334..5477ce40e1e33 100644 --- a/EIPS/eip-3450.md +++ b/EIPS/eip-3450.md @@ -3,7 +3,7 @@ eip: 3450 title: Standardized Shamir Secret Sharing Scheme for BIP-39 Mnemonics author: Daniel Streit (@danielstreit) discussions-to: https://ethereum-magicians.org/t/erc-3450-standard-for-applying-shamirs-to-bip-39-mnemonics/5844 -status: Draft +status: Stagnant type: Standards Track category: ERC created: 2021-03-29 diff --git a/EIPS/eip-3508.md b/EIPS/eip-3508.md index 76c3439d489bf..c75498cca1209 100644 --- a/EIPS/eip-3508.md +++ b/EIPS/eip-3508.md @@ -3,7 +3,7 @@ eip: 3508 title: Transaction Data Opcodes author: Alex Papageorgiou (@alex-ppg) discussions-to: https://ethereum-magicians.org/t/eip-draft-transaction-data-opcodes/6017 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-04-16 diff --git a/EIPS/eip-3520.md b/EIPS/eip-3520.md index eaccf5257d629..dd84686a38813 100644 --- a/EIPS/eip-3520.md +++ b/EIPS/eip-3520.md @@ -3,7 +3,7 @@ eip: 3520 title: Transaction Destination Opcode author: Alex Papageorgiou (@alex-ppg) discussions-to: https://ethereum-magicians.org/t/eip-3520-transaction-destination-opcode/6058 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-04-16 diff --git a/EIPS/eip-3521.md b/EIPS/eip-3521.md index 0fb6028c046ec..9e210fdf9af58 100644 --- a/EIPS/eip-3521.md +++ b/EIPS/eip-3521.md @@ -3,7 +3,7 @@ eip: 3521 title: Reduce access list cost author: Matt Garnett (@lightclient) discussions-to: https://ethereum-magicians.org/t/eip-3521-reduce-access-list-cost/6072 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2021-04-15 diff --git a/EIPS/eip-3525.md b/EIPS/eip-3525.md new file mode 100644 index 0000000000000..f0295cf6b25fe --- /dev/null +++ b/EIPS/eip-3525.md @@ -0,0 +1,425 @@ +--- +eip: 3525 +title: Fractionalized NFT Standard +author: Will Wang (@will-edge), Mike Meng , TsaiYee , Ryan Chow , Zhongxin Wu , AlvisDu +discussions-to: https://github.com/ethereum/EIPs/issues/3641 +status: Draft +type: Standards Track +category: ERC +created: 2020-12-01 +requires: 165, 721 +--- + +## Simple Summary + +This is a standard for semi-fungible tokens. The set of smart contract interfaces described in this document defines an ERC-721 extension, which enhances ERC-721 by adding a 'units' property to represent the quantitative nature of a token and enabling some quantitative operations for the token, most notably splitting and merging. + +## Abstract + +VNFT is ERC-721 compatible, which means, as an ERC-721 token, each VNFT contains an ID property to identify itself as a universally unique entity. What empowers a VNFT is that it contains a 'units' property, representing the quantitative nature of the token. Thus, this VNFT can be split into several different VNFTs, with certain properties maintained unchanged but the sum of the units of all split-out VNFTs equals that of the original one. Nevertheless, each VNFT has a 'SLOT' attribute, which labels its logical category. Several VNFTs can be merged into one VNFT if their SLOT attributes indicate that they are of the same category. + +## Motivation + +Tokenization of assets is one of the most important applications in crypto. Normally there are two options when tokenizing assets: fungible and non-fungible. The first one generally uses the ERC-20 standard, in the case that every unit of assets is identical to each other, ERC-20 standard provides a flexible and efficient way to manipulate fungible tokens. The second one predominately uses the ERC-721 token standard, for that each asset needs to be described by one or more customized properties. For example, when a decentralized exchange that supports the Automatic Market-Making model allows its liquidity providers to specify their positions at different price ranges, an LP token can be implemented in ERC-721, since this token standard has the capability to identify each position as an entity, with different attributes for each entity. + +Both options have significant drawbacks. In the fungible way, one needs to create a separate ERC-20 contract for each different value or combination of customizable properties, which can easily require an unacceptable number of ERC-20 contracts in practice. On the other hand, there is no quantitative feature in an ERC-721, hence significantly reducing the computability, liquidity, and manageability. For example, when we want to stake part of the position LP in some smart contract, the liquidity has to be withdrawn from the LP to create a new one, causes inconvenience and temporary decrease of liquidity. + +An intuitive and direct way to solve the problem is to add a property to represent the quantitative nature directly to an ERC-721 token, making it best for both property customization and semi-fungibility. Furthermore, the ERC-721 compatibility would help the new standard easily utilize existing infrastructures and gain fast adoption. + +For further design motivations, see papers and documents below: + +**Articles & Discussions** + +- [How vnft can improve position management in uniswap-v3](https://solvprotocol.medium.com/how-vnft-can-improve-position-management-in-uniswap-v3-221ab49a8cb2) +- [What are digital assets](https://unizon.pro/en/7632.html) +- [Vnft tokens vs.erc-20 vs. erc-721](https://medium.com/solv-blog/vnft-tokens-vs-erc-20-vs-erc-721-e75843053786) + + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + + +**Related Standards** +- [ERC-721 Non-Fungible Token Standard](./eip-721.md) +- [ERC-165 Standard Interface Detection](./eip-165.md) +- [JSON Schema](https://json-schema.org/) +- [RFC 2119 Key words for use in RFCs to Indicate Requirement Levels](https://www.ietf.org/rfc/rfc2119.txt) + + +**Every contract implementing the VNFT standard MUST implement the `VNFT` interfaces as follows:** + +```solidity +pragma solidity 0.7.6; + +/** + * @title VNFT Versatile Non-Fungible Token Standard + * @dev See https://eips.ethereum.org/EIPS/eip-VNFT + * Note: the ERC-165 identifier for this interface is 0x1487d183. + */ +interface VNFT /* is ERC-721 */{ + + /** + * @dev This emits when partial units of a token are transferred to another. + * @param _from The address of the owner of `_tokenId` + * @param _to The address of the owner of `_targetTokenId` + * @param _tokenId The token to partially transfer + * @param _targetTokenId The token to receive the units transferred + @ @param _transferUnits The amount of units to transfer + */ + event PartialTransfer(address indexed _from, address indexed _to, uint256 indexed _tokenId, uint256 _targetTokenId, uint256 _transferUnits); + + /** + * @dev This emits when a token is split into two. + * @param _owner The address of the owner of both `_tokenId` and `_newTokenId` + * @param _tokenId The token to be split + * @param _newTokenId The new token created after split + @ @param _splitUnits The amount of units to be split from `_tokenId` to `_newTokenId` + */ + event Split(address indexed _owner, uint256 indexed _tokenId, uint256 _newTokenId, uint256 _splitUnits); + + /** + * @dev This emits when a token is merged into another. + * @param _owner The address of the owner of both `_tokenId` and `_targetTokenId` + * @param _tokenId The token to be merged into `_targetTokenId` + * @param _targetTokenId The token to receive all units of `_tokenId` + @ @param _mergeUnits The amount of units to be merged from `_tokenId` to `_targetTokenId` + */ + event Merge(address indexed _owner, uint256 indexed _tokenId, uint256 indexed _targetTokenId, uint256 _mergeUnits); + + /** + * @dev This emits when the approved units of the approved address for a token is set or changed. + * @param _owner The address of the owner of the token + * @param _approved The address of the approved operator + * @param _tokenId The token to approve + @ @param _approvalUnits The amount of approved units for the operator + */ + event ApprovalUnits(address indexed _owner, address indexed _approved, uint256 indexed _tokenId, uint256 _approvalUnits); + + /** + * @dev Find the slot of a token. + * @param _tokenId The identifier for a token + * @return The slot of the token + */ + function slotOf(uint256 _tokenId) external view returns(uint256); + + /** + * @dev Count all tokens holding the same slot. + * @param _slot The slot of which to count tokens + * @return The number of tokens of the specified slot + */ + function supplyOfSlot(uint256 _slot) external view returns (uint256); + + /** + * @dev Find the number of decimals a token uses for units - e.g. 6, means the user representation of the units of a token can be calculated by dividing it by 1,000,000. + * @return The number of decimals for units of a token + */ + function decimals() external view return (uint8); + /** + * @dev Enumerate all tokens of a slot. + * @param _slot The slot of which to enumerate tokens + * @param _index The index in the token list of the slot + * @return The id for the `_index`th token in the token list of the slot + */ + function tokenOfSlotByIndex(uint256 _slot, uint256 _index) external view returns (uint256); + + /** + * @dev Find the amount of units of a token. + * @param _tokenId The token to query units + * @return The amount of units of `_tokenId` + */ + function unitsInToken(uint256 _tokenId) external view returns (uint256); + + /** + * @dev Set or change the approved units of an operator for a token. + * @param _to The address of the operator to be approved + * @param _tokenId The token to approve + * @param _units The amount of approved units for the operator + */ + function approve(address _to, uint256 _tokenId, uint256 _units) external; + + /** + * @dev Find the approved units of an operator for a token. + * @param _tokenId The token to find the operator for + * @param _spender The address of an operator + * @return The approved units of `_spender` for `_tokenId` + */ + function allowance(uint256 _tokenId, address _spender) external view returns (uint256); + + /** + * @dev Split a token into several by separating its units and assigning each portion to a new created token. + * @param _tokenId The token to split + * @param _units The amounts to split, i.e., the units of the new tokens created after split + * @return The ids of the new tokens created after split + */ + function split(uint256 _tokenId, uint256[] calldata _units) external returns (uint256[] memory); + + /** + * @dev Merge several tokens into one by merging their units into a target token before burning them. + * @param _tokenIds The tokens to merge + * @param _targetTokenId The token to receive all units of the merged tokens + */ + function merge(uint256[] calldata _tokenIds, uint256 _targetTokenId) external; + + /** + * @dev Transfer partial units of a token to a newly created token. When transferring to a smart contract, the caller SHOULD check if the recipient is capable of receiving VNFTs. + * @param _from The address of the owner of the token to transfer + * @param _to The address of the owner the newly created token + * @param _tokenId The token to partially transfer + * @param _units The amount of units to transfer + * @return The token created after transfer containing the transferred units + */ + function transferFrom(address _from, address _to, uint256 _tokenId, uint256 _units) external returns (uint256); + + /** + * @dev Transfer partial units of a token to a newly created token. If `_to` is a smart contract, this function MUST call `onVNFTReceived` on `_to` after transferring and then verify the return value. + * @param _from The address of the owner of the token to transfer + * @param _to The address of the owner the newly created token + * @param _tokenId The token to partially transfer + * @param _units The amount of units to transfer + * @param _data + * @return The token created after transfer containing the transferred units + */ + function safeTransferFrom(address _from, address _to, uint256 _tokenId, uint256 _units, bytes calldata _data) external returns (uint256); + + /** + * @dev Transfer partial units of a token to an existing token. When transferring to a smart contract, the caller SHOULD check if the recipient is capable of receiving VNFTs. + * @param _from The address of the owner of the token to transfer + * @param _to The address of the owner the token to receive units + * @param _tokenId The token to partially transfer + * @param _targetTokenId The token to receive units + * @param _units The amount of units to transfer + */ + function transferFrom(address _from, address _to, uint256 _tokenId, uint256 _targetTokenId, uint256 _units) external; + + /** + * @dev Transfer partial units of a token to an existing token. If `_to` is a smart contract, this function MUST call `onVNFTReceived` on `_to` after transferring and then verify the return value. + * @param _from The address of the owner of the token to transfer + * @param _to The address of the owner the token to receive units + * @param _tokenId The token to partially transfer + * @param _targetTokenId The token to receive units + * @param _units The amount of units to transfer + * @param _data + */ + function safeTransferFrom(address _from, address _to, uint256 _tokenId, uint256 _targetTokenId, uint256 _units, bytes calldata _data) external; +} +``` + +### VNFT Token Receiver + +Smart contracts MUST implement all of the functions in the IVNFTReceiver interface to accept transfers. See “Safe Transfer Rules” for further detail. + +```javascript + /** + @notice Handle the receipt of a VNFT token type. + @dev A VNFT-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeTransferFrom` after the balance has been updated. + This function MUST return `bytes4(keccak256("onVNFTReceived(address,address,uint256,uint256,bytes)"))` (i.e. 0xb382cdcd) if it accepts the transfer. + This function MUST revert if it rejects the transfer. + Return of any other value than the prescribed keccak256 generated value MUST result in the transaction being reverted by the caller. + @param operator The address which initiated the transfer (i.e. msg.sender) + @param from The address which previously owned the token + @param id The ID of the token being transferred + @param units The units of tokenId being transferred + @param data Additional data with no specified format + @return `bytes4(keccak256("onVNFTReceived(address,address,uint256,uint256,bytes)"))` + Note: the ERC-165 identifier for this interface is 0xb382cdcd. + */ +interface IVNFTReceiver { + function onVNFTReceived(address operator, address from, uint256 tokenId, + uint256 units, bytes calldata data) external returns (bytes4); +} +``` + + +### Token Manipulation + + +#### Scenarios + +**_Transfer:_** + +Since a VNFT token is ERC-721 compatible, it has ID level transfer and units level transfer. + +The ID level transfer SHOULD obey ERC-721 transfer rules with neither extra restrictions nor special treatments. + +The units level transfer has two types of interfaces, and both have safe and unsafe versions: + +```solidity + +1. function transferFrom(address from, address to, uint256 tokenId, uint256 targetTokenId, uint256 units) external; + function safeTransferFrom(address from, address to, uint256 tokenId, uint256 targetTokenId, uint256 units, + bytes calldata data) external; + +2. function transferFrom(address from, address to, uint256 tokenId, uint256 units) external returns (uint256 newTokenId); + function safeTransferFrom(address from, address to, uint256 tokenId, uint256 units, bytes calldata data) + external returns (uint256 newTokenId); + +``` +The main difference between the two kinds of interface is whether the application or the contract is responsible for determining/generating the target token ID in the transfer. + +Since partial transfer of a token will possibly result in new token id creation, it's important to give the implementing contract the ability to do that. On the other hand, since part of a token can be transferred to a token with the same slot, we want to keep the flexibility for dapps to determine whether to use this ability, resulting in less contract complexity and less gas consumption. + + +**_Merge:_** + +Several tokes with the same SLOT can be merged together using `merge(uint256[] calldata tokenIds, uint256 targetTokenId);`. `targetTokenId` should already exist, and cannot be one of `tokenIds`. After merging, `targetTokenId` owns all the units from the merged tokens, and the merged tokens will be burned. + + +**_Split:_** + +One token can be split into several tokens, using`split(uint256 tokenId, uint256[] calldata units) returns (uint256[] memory newTokenIds);`. This will result in several newly generated tokens containing units equal to the parameter `units`. + + + +#### Rules + +**_approving rules:_** + +- For being compatible with ERC721, there are three kinds of approving operations, which SHOULD be used to indicate different levels of approval. +- `setApprovalForAll` SHOULD indicate the top level of approval, the authorized operators are capable of handling all tokens, including their units, owned by the owner. +- The ID level `approve` SHOULD indicate that the `_tokenId` is approved to the operator, but not the units of that token. +- The units level `approve` with the `_units` parameter SHOULD indicate that only the specified amount of units are approved to the operator, but not the whole token. +- Any `approve` MUST revert if `msg.sender` is equal to `_to` or `_operator`. +- The units level `approve` MUST revert if `msg.sender` is not the owner of `_tokenId` nor set approval for all tokens. +- The units level `approve` MUST emit the `ApprovalUnits` event. + +**_splitting rules:_** + +- MUST revert if `_tokenId` is not a valid token. +- MUST revert if `msg.sender` is neither the owner of `_tokenId` nor set approval for all. +- MUST revert if the sum of all `_units` exceeds the actual amount of units in `_tokenId`. +- MUST return an array containing the ids of the generated tokens after splitting. +- MUST emit the `Split` event. + +**_merging rules:_** + +- MUST revert if `_targetTokenId` or any of `_tokenIds` is not a valid token. +- MUST revert if the owner of `tokenId` is not the owner of `_targetTokenId`. +- MUST revert if `msg.sender` is neither the owner of all `_tokenIds` and `targetTokenId` nor having been set approval for all. +- MUST revert if any of `_tokenIds` is equal to `_targetTokenId`. +- Each of `_tokenIds` MUST be burnt after being merged. +- MUST emit the `Merge` event. + +**_transferFrom rules:_** + +- The ERC721 level `transferFrom` without the `_units` and the `_targetTokenId` parameters SHOULD indicate transferring a whole token, including all of its units. + - MUST revert unless `msg.sender` is the owner of `_tokenId`, or the ERC721 level approved address, or having been set approval for all tokens. + - MUST revert if `_tokenId` is not a valid token + - MUST revert if `_from` is not the current owner of `_tokenId` + - MUST revert if `_to` is the zero address + - MUST emit the ERC721 level `Transfer` event + +- The VNFT level `transferFrom` without the `_targetTokenId` parameter SHOULD indicate transferring partial units to a new token of the recipient. + - MUST revert unless `msg.sender` is the owner of `_tokenId`, or having been set approval for all tokens, or having been VNFT approved a certain number units of `_tokenId`. + - MUST revert if `_tokenId` is not a valid token. + - MUST revert if `_from` is not the current owner of `_tokenId`. + - MUST revert if `_to` is the zero address. + - MUST revert if the transfer amount exceeds the actual amount of units in `_tokenId`. + - MUST revert if the transfer amount exceeds the VNFT approved units limit. + - MUST return the newly created token of the recipient containing the transferred units. + - MUST emit the VNFT level `PartialTransfer` event. + +- The VNFT level `transferFrom` with both the `_units` and the `_targetTokenId` parameters SHOULD indicate transferring partial units to an existing token of the recipient. + - MUST revert unless `msg.sender` is the owner of `_tokenId`, or having been set approval for all tokens, or the transfer amount is within the VNFT approved units limit. + - MUST revert if either `_tokenId` or `_targetTokenId` is not a valid token. + - MUST revert if `_from` is not the current owner of `_tokenId`. + - MUST revert if `_to` is not the current owner of `_targetTokenId`. + - MUST revert if `_to` is the zero address. + - MUST revert if the transfer amount exceeds the actual amount of units in `_tokenId`. + - MUST revert if the transfer amount exceeds the VNFT approved units limit. + - MUST emit the VNFT level `PartialTransfer` event. + +**_safeTransferFrom rules:_** + +- `safeTransferFrom` SHOULD be used to implement the same function as `transferFrom`, with an extra step to check if the recipient is capable of receiving VNFTs by implementing the `onVNFTReceived` interface. +- MUST obey the above rules set for `transferFrom`. +- MUST check if `_to` is a smart contract (code size > 0). If so, `safeTransferFrom` MUST call `onVNFTReceived` on `_to` and MUST revert if the return value does not match `bytes4(keccak256("onVNFTReceived(address,address,uint256,uint256,bytes)"))` + + + + +### Metadata + + +#### Metadata Extensions + +VNFT metadata extensions are compatible ERC-721 metadata extensions. + + +#### VNFT Metadata URI JSON Schema + +This is the "VNFT Metadata JSON Schema" referenced above. + +```json +{ + "title": "Asset Metadata", + "type": "object", + "properties": { + "name": { + "type": "string", + "description": "Identifies the asset to which this NFT represents" + }, + "description": { + "type": "string", + "description": "Describes the asset to which this NFT represents" + }, + "image": { + "type": "string", + "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." + }, + "decimals": { + "type": "integer", + "description": "The number of decimal places that the token amount should display - e.g. 18, means to divide the token amount by 1000000000000000000 to get its user representation." + }, + "properties": { + "type": "object", + "description": "Arbitrary properties. Values may be strings, numbers, object or arrays." + } + } +} +``` + +### Approval + +VNFT adds a new approval model, that is, one can approve operators to partial transfer units from a token with certain ID, the new interface is: +```function approve(address to, uint256 tokenId, uint256 units); ``` + + + +## Rationale + +### Metadata generation + +Since VNFT is designed for representing underlying assets, rather than artifacts for gaming or arts, the implementation should give out the metadata directly from contract code, rather than give a URL of a server for returning metadata. + + +### Design decision: Keep unsafe transfer + +There are mainly two reasons we keep the unsafe transfer interfaces: + +1. Since VNFT is ERC-721 compatible, we must keep compatibility for all wallets and contracts that are still calling unsafe transfer interfaces for ERC-721 tokens. +2. We want to keep the ability that dapps can trigger business logic on contracts by simply transferring VNFT tokens to them, that is, a contract can put business logic in `onVNFTReceived` function so that it can be called whenever a token is transferred using `safeTransferFrom`. However, in this situation, an approved contract with customized transfer functions like deposit etc. SHOULD never call `safeTransferFrom` since it will result in confusion that whether `onVNFTReceived` is called by itself or other dapps that safe transfer a token to it. + + +### Approval + +For maximum semantical compatibility with ERC-721, as well as simplifying the approval model, we decided to make the relationship between two levels of approval like that: + +1. Approval of an id does not result in the ability to partial transfer units from this id by the approved operator; +2. Approval of all units in a token does not result in the ability to transfer the token entity by the approved operator; +3. `setApprovalForAll` will result in the ability to transfer any tokens from the owner, as well as the ability to partial transfer units from any token. +3. `setApprovalForAll` will result in the ability to approve any tokens of the owner to third parties, as well as the ability to approve partial transfer units of any token to third parties. + + +## Backwards Compatibility + +As mentioned at the very beginning, a VNFT contract is basically an ERC721 contract, hence it is 100% compatible with ERC-721. + + +## Reference Implementation + +- [SOLV Vouchers - VNFT-core](https://github.com/solv-finance/solv-v2-voucher/tree/main/packages/solv-vnft-core/contracts) + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-3540.md b/EIPS/eip-3540.md index 81cf42cf8fce2..19a2d4861ad73 100644 --- a/EIPS/eip-3540.md +++ b/EIPS/eip-3540.md @@ -70,12 +70,12 @@ The container starts with the header: | description | length | value | | |-------------|---------|-------|-| | format | 1-byte | 0xEF | | -| magic | 2-byte | 0xCA 0xFE | Subject to change, may be removed. | -| version | 1-byte | 0x01 | means EOF1 | +| magic | 1-byte | 0x00 | | +| version | 1-byte | 0x01 | means EOF1 | This is followed by one or more section headers: -| description | length | | +| description | length | | |--------------|---------|-| | section_kind | 1-byte | Encoded as a 8-bit unsigned number. | | section_size | 2-bytes | Encoded as a 16-bit unsigned big-endian number. | @@ -125,7 +125,7 @@ For clarity, the *container* refers to the complete account code, while *code* r ### Changes to contract creation semantics -For clarity, the *EOF prefix* together with a version number *n* is denoted as the *EOFn prefix*, e.g. *EOF1 prefix*. +For clarity, the *EOF prefix* together with a version number *n* is denoted as the *EOFn prefix*, e.g. *EOF1 prefix*. 1. If _initcode's container_ has EOF1 prefix it must be valid EOF1 code. 2. If _code's container_ has EOF1 prefix it must be valid EOF1 code. @@ -170,6 +170,16 @@ Finally, create transaction must be allowed to contain legacy _initcode_ and dep The `0xEF` byte was chosen because it is reserved for this purpose by [EIP-3541](./eip-3541.md). +### The MAGIC byte + +1. The `0x00` byte was chosen to avoid clashes with three contracts which were deployed on **Mainnet**: + - `EFF09f918bf09f9fa9` [0xca7bf67ab492b49806e24b6e2e4ec105183caa01](https://etherscan.io/address/0xca7bf67ab492b49806e24b6e2e4ec105183caa01) + - `EF` [0x897da0f23ccc5e939ec7a53032c5e80fd1a947ec](https://etherscan.io/address/0x897da0f23ccc5e939ec7a53032c5e80fd1a947ec) + - `EF` [0x6e51d4d9be52b623a3d3a2fa8d3c5e3e01175cd0](https://etherscan.io/address/0x6e51d4d9be52b623a3d3a2fa8d3c5e3e01175cd0) + +2. No contracts starting with `0xEF` bytes exist on public testnets: Goerli, Ropsten, Rinkeby, Kovan and Sepolia at their London fork block. + + ### Section structure We have considered different questions for the sections: @@ -198,8 +208,6 @@ The choice of *magic* guarantees that none of the contracts existing on the chai #### Invalid cases -*These cases use `00` as magic.* - |Bytecode| Validation error | |-------------|---------| | `EF` | No magic | @@ -236,15 +244,15 @@ The choice of *magic* guarantees that none of the contracts existing on the chai All cases should be checked for creation transaction, `CREATE` and `CREATE2`. - Legacy init code - - Returns legacy code - - Returns valid EOF1 code - - Returns invalid EOF1 code - - Returns 0xEF not followed by EOF1 code + - Returns legacy code + - Returns valid EOF1 code + - Returns invalid EOF1 code + - Returns 0xEF not followed by EOF1 code - Valid EOF1 init code - - Returns legacy code - - Returns valid EOF1 code - - Returns invalid EOF1 code - - Returns 0xEF not followed by EOF1 code + - Returns legacy code + - Returns valid EOF1 code + - Returns invalid EOF1 code + - Returns 0xEF not followed by EOF1 code - Invalid EOF1 init code ### Contract execution @@ -253,24 +261,24 @@ All cases should be checked for creation transaction, `CREATE` and `CREATE2`. - `JUMP`/`JUMPI` to `5B` (`JUMPDEST`) byte outside of code section - exceptional abort - EOF code containing `PC` opcode - offset inside code section is returned - `PUSH*` instructions - - Complete push data - no changes expected - - Truncated push data without data section - execution ends with exceptional abort - - Truncated push data with data section - execution ends with exceptional abort + - Complete push data - no changes expected + - Truncated push data without data section - execution ends with exceptional abort + - Truncated push data with data section - execution ends with exceptional abort - Execution flows out of code section bounds (i.e. PC gets to `code_section_size`) - exceptional abort - EOF code containing `CODECOPY/CODESIZE` - works as in legacy code - - `CODESIZE` returns the size of entire container - - `CODECOPY` can copy from code section - - `CODECOPY` can copy from data section - - `CODECOPY` can copy from the EOF header - - `CODECOPY` can copy entire container + - `CODESIZE` returns the size of entire container + - `CODECOPY` can copy from code section + - `CODECOPY` can copy from data section + - `CODECOPY` can copy from the EOF header + - `CODECOPY` can copy entire container - `EXTCODECOPY/EXTCODESIZE/EXTCODEHASH` with the EOF *target* contract - works as with legacy target contract - - `EXTCODESIZE` returns the size of entire target container - - `EXTCODEHASH` returns the hash of entire target container - - `EXTCODECOPY` can copy from target's code section - - `EXTCODECOPY` can copy from target's data section - - `EXTCODECOPY` can copy from target's EOF header - - `EXTCODECOPY` can copy entire target container - - Results don't differ when executed inside legacy or EOF contract + - `EXTCODESIZE` returns the size of entire target container + - `EXTCODEHASH` returns the hash of entire target container + - `EXTCODECOPY` can copy from target's code section + - `EXTCODECOPY` can copy from target's data section + - `EXTCODECOPY` can copy from target's EOF header + - `EXTCODECOPY` can copy entire target container + - Results don't differ when executed inside legacy or EOF contract ## Reference Implementation @@ -278,7 +286,7 @@ All cases should be checked for creation transaction, `CREATE` and `CREATE2`. ```python FORMAT = 0xEF -MAGIC = 0x00 # To be defined +MAGIC = 0x00 VERSION = 0x01 S_TERMINATOR = 0x00 S_CODE = 0x01 @@ -286,7 +294,7 @@ S_DATA = 0x02 def validate_eof(code: bytes): # Old-style contracts are still allowed - if len(code) == 0 or code[1] != FORMAT: + if len(code) == 0 or code[0] != FORMAT: return # Validate format and magic @@ -333,7 +341,7 @@ Given the rigid rules of EOF1 it is possible to implement support for the contai ```python FORMAT = 0xEF -MAGIC = 0x00 # To be defined +MAGIC = 0x00 VERSION = 0x01 S_TERMINATOR = 0x00 S_CODE = 0x01 @@ -348,7 +356,7 @@ def validate_eof(code: bytes): else: assert(len(code) == 0 or code[0] != FORMAT) - assert(total_size == len(code)) + assert(len(code) == total_size) ``` However, future versions may introduce more sections or loosen up restrictions, requiring clients to actually parse sections instead of pattern matching. diff --git a/EIPS/eip-3569.md b/EIPS/eip-3569.md index ae24a9b9147bf..0e47132160a3f 100644 --- a/EIPS/eip-3569.md +++ b/EIPS/eip-3569.md @@ -2,7 +2,7 @@ eip: 3569 title: Sealed NFT Metadata Standard author: Sean Papanikolas (@pizzarob) -discussions-to: https://github.com/ethereum/EIPs/pull/3569 +discussions-to: https://ethereum-magicians.org/t/eip-3569-sealed-nft-metadata-standard/7130 status: Draft type: Standards Track category: ERC diff --git a/EIPS/eip-3607.md b/EIPS/eip-3607.md index 2e3f8ef626eec..c4119a86b942a 100644 --- a/EIPS/eip-3607.md +++ b/EIPS/eip-3607.md @@ -1,18 +1,15 @@ --- eip: 3607 title: Reject transactions from senders with deployed code +description: Do not allow transactions for which `tx.sender` has any code deployed. author: Dankrad Feist (@dankrad), Dmitry Khovratovich (@khovratovich), Marius van der Wijden (@MariusVanDerWijden) discussions-to: https://github.com/ethereum/EIPs/issues/3608 -status: Draft +status: Review type: Standards Track category: Core created: 2021-06-10 --- -## Simple Summary - -Do not allow transactions for which `tx.sender` has any code deployed, i.e. `tx.sender` has a `CODEHASH != EMPTYCODEHASH` - ## Abstract Ethereum addresses are currently only 160 bits long. This means it is possible to create a collision between a contract account and an Externally Owned Account (EOA) using an estimated `2**80` computing operations, which is feasible now given a large budget (ca. 10 billion USD). The fix in this EIP prevents the worst possible attack, where a safe looking contract (e.g. a token wrapper or an AMM-type contract) is deployed to attract user funds, which can then be spent using the EOA key for the same address. The fix is to never allow to use an address that already has code deployed as an EOA address. @@ -40,6 +37,8 @@ This EIP is to specify this behaviour to always forbid such transactions. This f Any transaction where `tx.sender` has a `CODEHASH != EMPTYCODEHASH` MUST be rejected as invalid. With `EMPTYCODEHASH = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`. +The invalid transaction MUST be rejected by the client and not be included in a block. +A block containing such a transaction MUST be considered invalid. ## Rationale @@ -58,6 +57,8 @@ It is unlikely that an attack like this has already occurred on the Ethereum mai Private networks may have deployed contracts which also work as EOAs at genesis and should check that this upgrade does not impact their workflows. +Clients might choose to disable this rule for RPC calls like `eth_call` and `eth_estimateGas` as some Multi-Sig contracts use these calls to create transactions as if they originated from the multisig contract itself. + ## Test Cases Given a genesis allocation of @@ -67,14 +68,14 @@ Balance: 1000000000000000000 // 1 ether Nonce: 0, Code: 0xB0B0FACE", ``` -Every transaction send by the private key corresponding to `0x715656...` ( -`b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291`) fails. - -A set of test cases can be found [here](https://github.com/ethereum/tests/pull/879) +Every transaction sent by the private key corresponding to `0x715656...` ( +`b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291`) should be rejected. +These transaction must be rejected and not included in a block. ## Reference Implementation The following check must be added to the state transition checks after checking that the nonce of the sender is correct. +The sender is the address recovered from the signature of the transaction. ``` // Make sure the sender is an EOA Set ch to the CodeHash of the sender account @@ -83,7 +84,7 @@ if cs is not equal to EmptyCodeHash then end if ``` -An diff to implement EIP-3607 in go-ethereum can be found [here](../assets/eip-3607/geth.diff) +A diff to implement EIP-3607 in go-ethereum can be found [here](../assets/eip-3607/geth.diff) ## Security Considerations diff --git a/EIPS/eip-3668.md b/EIPS/eip-3668.md index d2751c02a4176..70d958c0abe9e 100644 --- a/EIPS/eip-3668.md +++ b/EIPS/eip-3668.md @@ -48,10 +48,12 @@ In step 3, the client calls the original contract with the exact data provided b A Durin-enabled contract must revert with the following error whenever a function that requires offchain data is called: ``` -error OffchainLookup(string url, bytes prefix) +error OffchainLookup(string url, bytes data, bytes prefix) ``` -`url` specifies the URL to a service (known as the gateway) that implements the Durin protocol and can formulate an answer to the original query. `url` can be the empty string `''`, in which case a client-specific default should be used. +`url` specifies the URL to a service (known as the gateway) that implements the Durin protocol and can formulate an answer to the query. `url` can be the empty string `''`, in which case a client-specific default should be used. + +`data` specifies the data to call that service with; for simple cases this can be the same as the original call data. `prefix` specifies a prefix that the data returned by the gateway at `url` must have. Clients will check this value is a prefix of the data returned by the gateway, and cause the call to fail if it does not match. @@ -77,7 +79,7 @@ One example of a valid implementation of `balanceOf` would thus be: ``` function balanceOf(address addr) public view returns(uint balance) { - revert OffchainLookup(url, abi.encodeWithSelector(Contract.balanceOfWithProof.selector, addr)); + revert OffchainLookup(url, msg.data, abi.encodeWithSelector(Contract.balanceOfWithProof.selector, addr)); } ``` @@ -93,7 +95,7 @@ Accepts calldata for a smart contract call, and returns a message (encoded as a ##### Parameters 1. Object - The call object - to: DATA, 20 Bytes - The address of the contract being called. - - data: DATA - The call data for the contract invocation - this must be the same as the data originally sent to the contract function that reverted with `OffchainData`. + - data: DATA - The call data for the contract invocation - this must be the value of the `data` field from the `OffchainLookup` error. - abi: DATA - A JSON format ABI for the function being invoked, as specified in the [Solidity ABI encoding specification](https://docs.soliditylang.org/en/latest/abi-spec.html#json). ##### Returns @@ -122,8 +124,8 @@ def durin_call(address, abi, args, default_gateway): try: return address.call(calldata) except OffchainLookup as e: - url, prefix = e.url, e.prefix - response = json_rpc_call(url or default_gateway, 'durin_call', {'to': address, 'data': calldata, 'abi': abi}) + url, data, prefix = e.url, e.data, e.prefix + response = json_rpc_call(url or default_gateway, 'durin_call', {'to': address, 'data': data, 'abi': abi}) if not response.result.startswith(prefix): throw Error("Invalid response prefix") return address.call(response.result) diff --git a/EIPS/eip-3675.md b/EIPS/eip-3675.md index e4842ba53c5d8..2c4cb87b3d88e 100644 --- a/EIPS/eip-3675.md +++ b/EIPS/eip-3675.md @@ -17,7 +17,7 @@ Specification of the consensus mechanism upgrade on Ethereum Mainnet that introd ## Abstract -This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](./eip-2982.md). Full specification of the beacon chain can be found in the [eth2.0-specs](https://github.com/ethereum/eth2.0-specs/) repository. +This EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in [EIP-2982](./eip-2982.md). Full specification of the beacon chain can be found in the [consensus-specs](https://github.com/ethereum/consensus-specs/) repository. This document specifies the set of changes to the block structure, block processing, fork choice rule and network interface introduced by the consensus upgrade. @@ -41,7 +41,6 @@ There can be more than one terminal PoW block in the network, e.g. multiple chil * **`TERMINAL_TOTAL_DIFFICULTY`** The amount of total difficulty reached by the network that triggers the consensus upgrade. * **`TRANSITION_BLOCK`** The earliest PoS block of the canonical chain, i.e. the PoS block with the lowest block height. `TRANSITION_BLOCK` **MUST** be a child of a terminal PoW block. -* **`POS_CONSENSUS_VALIDATED`** An event occurring when the PoS block is validated with respect to the proof-of-stake consensus rules. * **`POS_FORKCHOICE_UPDATED`** An event occurring when the state of the proof-of-stake fork choice is updated. #### PoS events @@ -50,17 +49,26 @@ Events having the `POS_` prefix in the name (PoS events) are emitted by the new The details provided below must be taken into account when reading those parts of the specification that refer to the PoS events: * Reference to a block that is contained by PoS events is provided in a form of a block hash unless another is explicitly specified. -* A `POS_CONSENSUS_VALIDATED` event contains a reference to a block that this event is related to. All ancestors of a referenced block are as well deemed valid with respect to the proof-of-stake consensus rules. * A `POS_FORKCHOICE_UPDATED` event contains references to the head of the canonical chain and to the most recent finalized block. Before the first finalized block occurs in the system the finalized block hash provided by this event is stubbed with `0x0000000000000000000000000000000000000000000000000000000000000000`. -* Any block that is designated by a `POS_FORKCHOICE_UPDATED` event as the head of the canonical chain and all ancestors of this block are deemed valid with respect to the proof-of-stake consensus rules. * **`FIRST_FINALIZED_BLOCK`** The first finalized block that is designated by `POS_FORKCHOICE_UPDATED` event and has the hash that differs from the stub. +### Terminal total difficulty + +The `TERMINAL_TOTAL_DIFFICULTY` parameter is a part of client software configuration and **MUST** be included into its binary distribution. + + ### PoW block processing PoW blocks that are descendants of any terminal PoW block **MUST NOT** be imported. This implies that a terminal PoW block will be the last PoW block in the canonical chain. +### Constants + +| Name | Value | +|-|-| +| **`MAX_EXTRA_DATA_BYTES`** | `32` | + ### Block structure Beginning with `TRANSITION_BLOCK`, a number of previously dynamic block fields are deprecated by enforcing these values to instead be constants. Each block field listed in the table below **MUST** be replaced with the corresponding constant value. @@ -69,11 +77,12 @@ Beginning with `TRANSITION_BLOCK`, a number of previously dynamic block fields a |-|-|-| | **`ommersHash`** | `0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347` | `= Keccak256(RLP([]))` | | **`difficulty`** | `0` | | -| **`extraData`** | `b''` | `RLP(b'') = 0x80` | | **`mixHash`** | `0x0000000000000000000000000000000000000000000000000000000000000000` | | | **`nonce`** | `0x0000000000000000` | | | **`ommers`** | `[]` | `RLP([]) = 0xc0` | +Beginning with `TRANSITION_BLOCK`, the validation of the block's **`extraData`** field changes: The length of the block's **`extraData`** **MUST** be less than or equal to **`MAX_EXTRA_DATA_BYTES`** bytes. + *Note*: Logic and validity conditions of block fields that are *not* specified here **MUST** remain unchanged. Additionally, the overall block format **MUST** remain unchanged. @@ -83,10 +92,7 @@ Beginning with `TRANSITION_BLOCK`, the block validity conditions **MUST** be alt * Remove verification of the block's **`difficulty`** value with respect to the difficulty formula. * Remove verification of the block's **`nonce`** and **`mixHash`** values with respect to the Ethash function. * Remove all validation rules that are evaluated over the list of ommers and each member of this list. -* Add verification of the fields noted in [block structure](#block-structure) as their specified constant value. -* Add verification of block validity with respect to the PoS consensus rules, i.e. assert that there **MUST** be a corresponding event for the block to consider it valid. Such events are limited to the following: - * A `POS_CONSENSUS_VALIDATED` event considering the block or any of its descendants as valid. - * A `POS_FORKCHOICE_UPDATED` event designating the block or any of its descendants as the head of the canonical chain. +* Add verification of the fields noted in the [block structure](#block-structure) section. *Note*: If one of the new rules fails then the block **MUST** be invalidated. @@ -116,9 +122,19 @@ The new PoS LMD-GHOST fork choice rule is specified as follows. On each occurren Changes to the block tree store that are related to the above actions **MUST** be applied atomically. +*Note*: This rule **MUST** be strictly enforced. "Optimistic" updates to the head **MUST NOT** be made. That is -- if a new block is processed on top of the current head block, this new block becomes the new head if and only if an accompanying `POS_FORKCHOICE_UPDATED` event occurs. ### Network +#### EIP-2124 fork identifier + +For the purposes of the [EIP-2124 fork identifier](./eip-2124.md), nodes implementing this EIP **MUST** keep values of `FORK_NEXT` and `FORK_HASH` unaffected before `TRANSITION_POS_BLOCK`, i.e. `FORK_NEXT` is set to `0` and `FORK_HASH` retains the same value. + +Starting with `TRANSITION_POS_BLOCK` that has block number `N`, nodes **MUST** update `FORK_HASH` by appending `uint64(N)` to the sequence of hashes used to calculate `FORK_HASH` as per EIP-2124. +`FORK_NEXT` can remain `0` after the transition. + +#### devp2p + The networking stack **SHOULD NOT** send the following messages if they advertise the descendant of any terminal PoW block: * [`NewBlockHashes (0x01)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblockhashes-0x01) * [`NewBlock (0x07)`](https://github.com/ethereum/devp2p/blob/master/caps/eth.md#newblock-0x07) @@ -162,10 +178,6 @@ This change introduces an additional validity rule that enforces the replacement After deprecating the proof-of-work the notion of difficulty no longer exists and replacing the block header **`difficulty`** field with `0` constant is semantically sound. -### Deprecating `extraData` - -The **`extraData`** field is deprecated in favour of the corresponding **`graffiti`** field of the beacon block. - ### Changing block validity rules The rule set enforcing the PoW seal validity is replaced with the corresponding PoS rules along with the consensus upgrade as the rationale behind this change. @@ -180,12 +192,29 @@ Existing rewards for producing and sealing blocks are deprecated along with the The fork choice rule of the PoW mechanism becomes completely irrelevant after the upgrade and is replaced with the corresponding rule of the new PoS consensus mechanism. +### Remove of `POS_CONSENSUS_VALIDATED` + +In prior draft versions of this EIP, an additional POS event -- `POS_CONSENSUS_VALIDATED` -- was required as a validation condition for blocks. This event gave the signal to either fully incorporate or prune the block from the block tree. + +This event was removed for two reasons: +1. This event was an unnecessary optimization to allow for pruning of "bad" blocks from the block tree. This optimization was unnecessary because the PoS consensus would never send `POS_FORKCHOICE_UPDATED` for any such bad blocks or their descendants, and eventually any such blocks would be able to be pruned after a PoS finality event of an alternative branch in the block tree. +2. This event was dangerous in some scenarios because a block could be referenced by two *different* and conflicting PoS branches. Thus for the same block in some scenarios, both a `POS_CONSENSUS_VALIDATED == TRUE` and `POS_CONSENSUS_VALIDATED == FALSE` event could sent, entirely negating the ability to safely perform the optimization in (1). + +### EIP-2124 fork identifier + +The value of `FORK_NEXT` in EIP-2124 refers to the block number of the next fork a given node knows about and `0` otherwise. +The block number of `TRANSITION_POS_BLOCK` cannot be known ahead of time given the dynamic nature of the transition trigger condition. As the block will not be known a priori, nodes have no value to use for `FORK_NEXT` and in light of this fact will use the default `0`. +Using a value of `0` does imply extra networking overhead that EIP-2124 intends to eliminate, but given the mechanics of the transition process this decision seems the most pragmatic. + ### Removing block gossip After the upgrade of the consensus mechanism only the beacon chain network will have enough information to validate a block. Thus, block gossip provided by the `eth` network protocol will become unsafe and is deprecated in favour of the block gossip existing in the beacon chain network. It is recommended for the client software to not propagate descendants of any terminal PoW block to reduce the load on processing the P2P component and stop operating in the environment with unknown security properties. +### Restricting the length of `extraData` + +The `extraData` field is defined as a maximum of `32` bytes in the yellow paper. Thus mainnet and most PoW testnets cap the value at `32` bytes. `extraData` fields of greater length are used by clique testnets and other networks to carry special signature/consensus schemes. This EIP restricts the length of `extraData` to `32` bytes because any network that is transitioning from another consensus mechanism to a beacon chain PoS consensus mechanism no longer needs extended or unbounded `extraData`. ## Backwards Compatibility @@ -215,7 +244,6 @@ Pseudo-random numbers obtained as the output of `BLOCKHASH` operation become mor See Security Considerations section of [EIP-2982](./eip-2982.md#security-considerations). - ### Transition process The transition process used to take this specification into effect is a more sophisticated version of a hardfork -- the regular procedure of applying backwards incompatible changes in the Ethereum network. This process has multiple successive steps instead of the normal block-height point condition of simpler hardforks. @@ -244,6 +272,14 @@ Suppose the part of the client software that is connected to the beacon chain ne Not importing PoW blocks that are beyond the terminal PoW block prevents these adverse effects on safety/re-orgs in the event of software or configuration failures *in favor* of a liveness failure. +### Ancient blocks are no longer a requisite for a network security + +Keeping historical blocks starting from genesis is essential in the PoW network. A header of every block that belongs to a particular chain is required to justify the validity of this chain with respect to the PoW seal. + +Validating the entire history of the chain is not required by the new PoS mechanism. Instead, the sync process in the PoS network relies on weak subjectivity checkpoints, which are historical snapshots shared by peers on the network. This means historical blocks beyond weak subjectivity checkpoint are no longer a requisite for determining the canonical blockchain. + +Specification of weak subjectivity checkpoints can be found in the [consensus-specs](https://github.com/ethereum/consensus-specs/) repository. + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-3709.md b/EIPS/eip-3709.md new file mode 100644 index 0000000000000..fdf895209e958 --- /dev/null +++ b/EIPS/eip-3709.md @@ -0,0 +1,45 @@ +--- +eip: 3709 +title: Remove Support for Type 1 Transactions +author: Gregory Markou (@GregTheGreek) +discussions-to: https://ethereum-magicians.org/t/eip-3709-deprecate-type-1-transactions/6810 +status: Draft +type: Standards Track +category: Interface +created: 2021-08-07 +requires: 1559 +--- + +## Simple Summary + +Deprecates usage of [EIP-2718](./eip-2718.md) `TransactionType` 1 in wallets and providers, upgrading all type 1 transactions to a type 2 transaction. + +## Abstract + +Since both `TransactionType` 1 and 2 contain `access_list`, we propose the removal of offering `TransactionType` 1 from wallets and providers, instead the transaction will be converted to `TransactionType` 2 to make use of the new gas properties introduced by [EIP-1559](./eip-1559.md). + +## Motivation + +[EIP-2930](./eip-2930.md) was introduced as the first `TransactionType`, type 1, with the intention of adding `access_list` to the `TransactionPayload`. [EIP-1559](./eip-1559.md) introduced the second `TransactionType` 2, which is represented as `rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])`. The intention behind EIP-1559 was to enhance the user experience surrounding gas fees, and as we move forward we expect that the majority of the network will begin to using `TransactionType` 2 instead of the legacy style transactions. `TransactionType` 1 is a legacy transaction with the addition of `access_list` meaning that users will not benefit from enhancements made by EIP-1559. `TransactionType` 2 contains `access_list`, thus there is no reason to further support `TransactionType` 1 if the end goal is to push users towards using `TransactionType` 2 anyway. + + +## Specification + +For wallets and providers, if a user submits a transaction for signing with where `TransactionType == 0x1`, the developer should upgrade the transaction to meet the criteria of transaction of type 2. + +The following fields need to be changed, or amended: +- `access_list`: Nothing changes and it should remain in the transaction. +- `type`: Should change from `0x1` to `0x2`. +- `gas_price`: Should be removed in favour of `max_fee_per_gas` & `max_priority_fee_per_gas` (see [EIP-1559](./eip-1559.md) for proper usage). + +## Rationale + +Improve the user experience for submitting transactions, and move away from legacy style transactions. + +## Security Considerations + +There are no known security considerations at this time. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-3722.md b/EIPS/eip-3722.md new file mode 100644 index 0000000000000..7e0c5509a58ab --- /dev/null +++ b/EIPS/eip-3722.md @@ -0,0 +1,186 @@ +--- +eip: 3722 +title: Poster +description: A ridiculously simple general purpose social media smart contract. +author: Auryn Macmillan (@auryn-macmillan) +discussions-to: https://ethereum-magicians.org/t/eip-poster-a-ridiculously-simple-general-purpose-social-media-smart-contract/6751 +status: Draft +type: Standards Track +category: ERC +created: 2021-07-31 +--- + +# Poster + +## Abstract +A ridiculously simple general purpose social media smart contract. +It takes a string as a parameter and emits that string, along with `msg.sender`, as an event. That's it. +The EIP also includes a proposed standard json format for a Twitter-like application, where each `post()` call can include multiple posts and/or operations. The assumption being that application state will be constructed off-chain via some indexer. + +## Motivation +Poster is intended to be used as a base layer for decentralized social media. It can be deployed to the same address (via the singleton factory) on just about any EVM compatible network. Any Ethereum account can make posts to the deployment of Poster on its local network. + +## Specification + +### Contract + +```solidity +contract Poster { + event NewPost(address indexed account, string content); + + function post(string calldata content) public { + emit NewPost(msg.send, content); + } +} +``` + +### ABI +```json +[ + { + "anonymous": false, + "inputs": [ + { + "indexed": true, + "internalType": "address", + "name": "user", + "type": "address" + }, + { + "indexed": false, + "internalType": "string", + "name": "content", + "type": "string" + } + ], + "name": "NewPost", + "type": "event" + }, + { + "inputs": [ + { + "internalType": "string", + "name": "content", + "type": "string" + } + ], + "name": "post", + "outputs": [], + "stateMutability": "nonpayable", + "type": "function" + } +] +``` + +### Standard json format for Twitter-like posts + +```json +{ + "content": [ + { + "type": "microblog", + "text": "this is the first post in a thread" + }, + { + "type": "microblog", + "text": "this is the second post in a thread", + "replyTo": "this[0]" + }, + { + "type": "microblog", + "text": "this is a reply to some other post", + "replyTo": "some_post_id" + }, + { + "type": "microblog", + "text": "this is a post with an image", + "image": "ipfs://ipfs_hash" + }, + { + "type": "microblog", + "text": "this post replaces a previously posted post", + "edit": "some_post_id" + }, + { + "type": "delete", + "target": "some_post_id" + }, + { + "type": "like", + "target": "some_post_id" + }, + { + "type": "repost", + "target": "some_post_id" + }, + { + "type": "follow", + "target": "some_account" + }, + { + "type": "unfollow", + "target": "some_account" + }, + { + "type": "block", + "target": "some_account" + }, + { + "type": "report", + "target": "some_account or some_post_id" + }, + { + "type": "permissions", + "account": "", + "permissions": { + "post": true, + "delete": true, + "like": true, + "follow": true, + "block": true, + "report": true, + "permissions": true + } + }, + { + "type": "microblog", + "text": "This is a post from an account with permissions to post on behalf of another account.", + "from": "" + } + ] +} + +``` + +## Rationale +There was some discussion around whether or not an post ID should also be emitted, whether the content should be a string or bytes, and whether or not anything at all should actually be emitted. + +We decided not to emit an ID, since it meant adding state or complexity to the contract and there is a fairly common pattern of assigning IDs on the indexer layer based on transactionHash + logIndex. + +We decided to emit a string, rather than bytes, simply because that would make content human readable on many existing interfaces, like Etherscan for example. This did, unfortunately, eliminate some of the benefit that we might have gotten from a more compact encoding scheme like CBOR, rather than JSON. But this also would not have satisfied the human readable criteria. + +While there would have been some gas savings if we decided against emitting anything at all, it would have redically increased the node requirements to index posts. As such, we decided it was worth the extra gas to actually emit the content. + +## Reference Implementation + +Poster has been deployed at `0x0000000000A84Fe7f5d858c8A22121c975Ff0b42` on multiple networks using the [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470). If it is not yet deployed on your chosen network, you can use the Singleton Factory to deploy an instance of Poster at the same address on just about any EVM compatible network using these parameters: + +> **initCode:** `0x608060405234801561001057600080fd5b50610189806100206000396000f3fe608060405234801561001057600080fd5b506004361061002b5760003560e01c80638ee93cf314610030575b600080fd5b61004361003e366004610099565b610045565b005b3373ffffffffffffffffffffffffffffffffffffffff167f6babe127d1599cad37c523a2dd29c5d02acd7132a883e378a2d9b42ec75a1fa9838360405161008d929190610106565b60405180910390a25050565b600080602083850312156100ab578182fd5b823567ffffffffffffffff808211156100c2578384fd5b818501915085601f8301126100d5578384fd5b8135818111156100e3578485fd5b8660208285010111156100f4578485fd5b60209290920196919550909350505050565b60006020825282602083015282846040840137818301604090810191909152601f9092017fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe016010191905056fea264697066735822122091369fb6f397ae303a741fb470a163a0384d9152cd15b5887f5f0b68e5a3c8e964736f6c63430008000033` +> +> +> +> **salt:** `0x51a9566bdb2664f8cb31cd79d50e2c10ea34f765e27bc8e3ff3c60175ad4cb6c` + +The source code is available in the [Poster contract repo](https://github.com/ETHPoster/contract/blob/master/contracts/Poster.sol). + +When verifying on the source code on a block explorer, make sure to set the optimizer to `yes` and the runs to `10000000`. + +## Security Considerations +Given the ridiculously simple implementation of Poster, there does not appear to be any real security concerns at the contract level. + +At the application level, clients should confirm that posts including a `"from"` field that differs from `msg.sender` have been authorized by the `"from"` address via a `"permissions"` post, otherwise they should be considerred invalid or a post from `msg.sender`. + +Clients should also be sure to sanitize post data. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-3754.md b/EIPS/eip-3754.md new file mode 100644 index 0000000000000..f06595b3b9ab1 --- /dev/null +++ b/EIPS/eip-3754.md @@ -0,0 +1,74 @@ +--- +eip: 3754 +title: A Vanilla Non-Fungible Token Standard +description: NFTs for representing abstract ownership +author: Simon Tian (@simontianx) +discussions-to: https://github.com/ethereum/EIPs/issues/3753 +status: Draft +type: Standards Track +category: ERC +created: 2021-08-21 +--- + +## Abstract +In this standard, a non-fungible token stands as atomic existence and encourages +layers of abstraction built on top of it. Ideal for representing concepts like +rights, a form of abstract ownership. Such right can take the form of NFT options, +oracle membership, virtual coupons, etc., and can then be made liquid because of +this tokenization. + +## Motivation +Non-fungible tokens are popularized by the [ERC-721](./eip-721.md) NFT standard +for representing "ownership over digital or physical assets". Over the course of +development, reputable NFT projects are about crypto-assets, digital collectibles, +etc. The proposed standard aims to single out a special type of NFTs that are +ideal for representing abstract ownership such as rights. Examples include the +right of making a function call to a smart contract, an NFT option that gives +the owner the right, but not obligation, to purchase an ERC-721 NFT, and the prepaid +membership (time-dependent right) of accessing to data feeds provided by oracles +without having to pay the required token fees. An on-chain subscription business +model can then be made available by this standard. The conceptual clarity of an +NFT is hence improved by this standard. + +## Specification +``` +interface IERC3754 { + event Transfer(address indexed from, address indexed to, uint256 indexed tokenId); + event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId); + event ApprovalForAll(address indexed owner, address indexed operator, bool approved); + + function balanceOf(address owner) external view returns (uint256); + function ownerOf(uint256 tokenId) external view returns (address); + function approve(address to, uint256 tokenId) external; + function getApproved(uint256 tokenId) external view returns (address); + function setApprovalForAll(address operator, bool approved) external; + function isApprovedForAll(address owner, address operator) external view returns (bool); + function transferFrom(address from, address to, uint256 tokenId) external; + function safeTransferFrom(address from, address to, uint256 tokenId) external; + function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) external; +} +``` + +## Rationale +The NFTs defined in the [ERC-721](./eip-721.md) standard are already largely +accepted and known as representing ownership of digital assets, and the NFTs by +this standard aim to be accepted and known as representing abstract ownership. +This is achieved by allowing and encouraging layers of abstract utilities built +on top of them. Ownership of such NFTs is equivalent with having the rights to +perform functions assigned to such tokens. Transfer of such rights is also made +easier because of this tokenization. To further distinguish this standard +from [ERC-721](./eip-721.md), data fields and functions related to `URI` are +excluded. + +## Backwards Compatibility +There is no further backwards compatibility required. + +## Reference Implementation +https://github.com/simontianx/ERC3754 + +## Security Considerations +The security is enhanced from ERC721, given tokens are minted without having to +provide `URI`s. Errors in dealing with `URI`s can be avoided. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-3770.md b/EIPS/eip-3770.md new file mode 100644 index 0000000000000..cddd8a526ecf1 --- /dev/null +++ b/EIPS/eip-3770.md @@ -0,0 +1,54 @@ +--- +eip: 3770 +title: Chain-specific addresses +description: A standard for displaying CAIP-10 account identifiers in a human readable format +author: Lukas Schor (@lukasschor), Richard Meissner (@rmeissner), Pedro Gomes (@pedrouid), ligi +discussions-to: https://ethereum-magicians.org/t/chain-specific-addresses/6449 +status: Draft +type: Standards Track +category: ERC +created: 2021-08-26 +--- + +## Abstract +This EIP introduced a new address standard to be adapted by wallets and dApps to display chain-specific addresses by mapping human-readable names to [CAIP-3](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-3.md) blockchain IDs. + +## Motivation +The need for this EIP emerges from the increasing adoption of non-Ethereum Mainnet chains that use the Ethereum Virtual Machine (EVM). In this context, addresses become ambiguous, as the same address may refer to an EOA on chain X or a smart contract on chain Y. This will eventually lead to Ethereum users losing funds due to human error. For example, users sending funds to a smart contract wallet address which was not deployed on a particular chain. + +[CAIP-10](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md) introduces an account identifier that encodes a [CAIP-2](https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-2.md) blockchain ID as part of the address. For EVM-based chains, these blockchain IDs are defined in CAIP-3 and leverage [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md) chainIDs. However, CAIP-10 targets developers, not end-users. These account identifiers are not meant to be displayed to users in dApps or wallets, and they were optimized for developer interoperability, rather than human readability. + +To solve the initial problem of user-facing addresses being ambiguous in a multichain context, we need to extend CAIP-10 with a user-facing format of displaying these account identifiers. + +## Specification +This EIP extends CAIP-10 with a standard for mapping EVM-based blockchain IDs (CAIP-3) to a human-readable blockchain short name, as defined in [ethereum-lists/chains](https://github.com/ethereum-lists/chains). + +### Syntax +A chain-specific address is prefixed with a chain shortName, separated with a colon sign (:). + +Chain-specific address = "`shortName`" "`:`" "`address`" +- `shortName` = STRING +- `address` = STRING + +### Semantics +`shortName` is mandatory and MUST be a valid short name from [ethereum-lists/chains](https://github.com/ethereum-lists/chains) + +`address` is mandatory and MUST be a EIP-55 compatible hexadecimal address + +### Examples +![Chain-specific addresses](../assets/eip-3770/EIP-3770-examples.png "Examples of chain-specific addresses") + +### Resolution Method +Chain-specific addresses are resolved to CAIP-10 account identifiers using [ethereum-lists/chains](https://github.com/ethereum-lists/chains): + +| EIP-3770 chain-specific address | CAIP-10 account identifier | +| ------------- |:-------------:| +| eth:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe | eip155:1:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe| +| ovm:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe | eip155:10:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe | +| poly:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe | eip155:137:0x0DA0C3e52C977Ed3cBc641fF02DD271c3ED55aFe | + +## Rationale +CAIP-10 account identifiers are not suitable for user-facing addresses that are chain-specific as they are non-human-readable. However, CAIP-10 identifiers are still the preferred option for development purposes, as they are ecosystem-agnostic and work best with chain-splits. As a result, this EIP aims to bridge the benefits of human-readable chain identifiers with the benefits of CAIP-10. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-3772.md b/EIPS/eip-3772.md new file mode 100644 index 0000000000000..cf7d6c4b72de8 --- /dev/null +++ b/EIPS/eip-3772.md @@ -0,0 +1,278 @@ +--- +eip: 3772 +title: Compressed Integers +description: Using lossy compression on uint256 to improve gas costs, ideally by a factor up to 4x. +author: Soham Zemse (@zemse) +discussions-to: https://github.com/ethereum/EIPs/issues/3772 +status: Draft +type: Standards Track +category: ERC +created: 2021-08-27 +--- + +## Abstract + +This document specifies compression of `uint256` to smaller data structures like `uint64`, `uint96`, `uint128`, for optimizing costs for storage. The smaller data structure (represented as `cintx`) is divided into two parts, in the first one we store `significant` bits and in the other number of left `shift`s needed on the significant bits to decompress. This document also includes two specifications for decompression due to the nature of compression being lossy, i.e. it causes underflow. + +## Motivation + +- Storage is costly, each storage slot costs almost $0.8 to initialize and $0.2 to update (20 gwei, 2000 ETHUSD). +- Usually, we store money amounts in `uint256` which takes up one entire slot. +- If it's DAI value, the range we work with most is 0.001 DAI to 1T DAI (or 1012). If it's ETH value, the range we work with most is 0.000001 ETH to 1B ETH. Similarly, any token of any scale has a reasonable range of 1015 amounts that we care/work with. +- However, uint256 type allows us to represent $10-18 to $1058, and most of it is a waste. In technical terms, we have the probability distribution for values larger than $1015 and smaller than $10-3 as negligible (i.e. P[val > 1015] ≈ 0 and P[val < 10-3] ≈ 0). +- Number of bits required to represent 1015 values = log2(1015) = 50 bits. So just 50 bits (instead of 256) are reasonably enough to represent a practical range of money, causing a very negligible difference. + +## Specification + +In this specification, the structure for representing a compressed value is represented using `cintx`, where x is the number of bits taken by the entire compressed value. On the implementation level, an `uintx` can be used for storing a `cintx` value. + +### Compression + +#### uint256 into cint64 (up to cint120) + +The rightmost, or least significant, 8 bits in `cintx` are reserved for storing the shift and the rest available bits are used to store the significant bits starting from the first `1` bit in `uintx`. + +```solidity +struct cint64 { uint56 significant; uint8 shift; } + +// ... + +struct cint120 { uint112 significant; uint8 shift; } +``` + +#### uint256 into cint128 (up to cint248) + +The rightmost, or least significant, 7 bits in `cintx` are reserved for storing the shift and the rest available bits are used to store the significant bits starting from the first one bit in `uintx`. + +> In the following code example, `uint7` is used just for representation purposes only, but it should be noted that uints in Solidity are in multiples of 8. + +```solidity +struct cint128 { uint121 significant; uint7 shift; } + +// ... + +struct cint248 { uint241 significant; uint7 shift; } +``` + +Examples: + +``` +Example: +uint256 value: 2**100, binary repr: 1000000...(hundred zeros) +cint64 { significant: 10000000...(55 zeros), shift: 00101101 (45 in decimal)} + +Example: +uint256 value: 2**100-1, binary repr: 111111...(hundred ones) +cint64 { significant: 11111111...(56 ones), shift: 00101100 (44 in decimal) } +``` + +### Decompression + +Two decompression methods are defined: a normal `decompress` and a `decompressRoundingUp`. + +```solidity +library CInt64 { + // packs the uint256 amount into a cint64 + function compress(uint256) internal returns (cint64) {} + + // unpacks cint64, by shifting the significant bits left by shift + function decompress(cint64) internal returns (uint256) {} + + // unpacks cint64, by shifting the significant bits left by shift + // and having 1s in the shift bits + function decompressRoundingUp(cint64) internal returns (uint256) {} +} +``` + +#### Normal Decompression + +The `significant` bits in the `cintx` are moved to a `uint256` space and shifted left by `shift`. + +> NOTE: In the following example, cint16 is used for visual demonstration purposes. But it should be noted that it is definitely not safe for storing money amounts because its significant bits capacity is 8, while at least 50 bits are required for storing money amounts. + +``` +Example: +cint16{significant:11010111, shift:00000011} +decompressed uint256: 11010111000 // shifted left by 3 + +Example: +cint64 { significant: 11111111...(56 ones), shift: 00101100 (44 in decimal) } +decompressed uint256: 1111...(56 ones)0000...(44 zeros) +``` + +#### Decompression along with rounding up + +The `significant` bits in the `cintx` are moved to a `uint256` space and shifted left by `shift` and the least significant `shift` bits are `1`s. + +``` +Example: +cint16{significant:11011110, shift:00000011} +decompressed rounded up value: 11011110111 // shifted left by 3 and 1s instead of 0s + +Example: +cint64 { significant: 11111111...(56 ones), shift: 00101100 (44 in decimal) } +decompressed uint256: 1111...(100 ones) +``` + +This specification is to be used by a new smart contract for managing its internal state so that any state mutating calls to it can be cheaper. These compressed values on a smart contract's state are something that should not be exposed to the external world (other smart contracts or clients). A smart contract should expose a decompressed value if needed. + +## Rationale + +- The `significant` bits are stored in the most significant part of `cintx` while `shift` bits in the least significant part, to help prevent obvious dev mistakes. For e.g. a number smaller than 256-1 its compressed `cint64` value would be itself if the arrangement were to be opposite than specified. If a developer forgets to uncompress a value before using it, this case would still pass if the compressed value is the same as decompressed value. +- It should be noted that using `cint64` doesn't render gas savings automatically. The solidity compiler needs to pack more data into the same storage slot. +- Also the packing and unpacking adds some small cost too. +- Though this design can also be seen as a binary floating point representation, however using floating point numbers on EVM is not in the scope of this ERC. The primary goal of floating point numbers is to be able to represent a wider range in an available number of bits, while the goal of compression in this ERC is to keep as much precision as possible. Hence, it specifies for the use of minimum exponent/shift bits (i.e 8 up to `uint120` and 7 up to `uint248`). + +```solidity +// uses 3 slots +struct UserData1 { + uint64 amountCompressed; + bytes32 hash; + address beneficiary; +} + +// uses 2 slots +struct UserData2 { + uint64 amountCompressed; + address beneficiary; + bytes32 hash; +} +``` + +## Backwards Compatibility + +There are no known backward-incompatible issues. + +## Reference Implementation + +On the implementation level `uint64` may be used directly, or with custom types introduced in 0.8.9. + +```soldity +function compress(uint256 full) public pure returns (uint64 cint) { + uint8 bits = mostSignificantBitPosition(full); + if (bits <= 55) { + cint = uint64(full) << 8; + } else { + bits -= 55; + cint = (uint64(full >> bits) << 8) + bits; + } +} + +function decompress(uint64 cint) public pure returns (uint256 full) { + uint8 bits = uint8(cint % (1 << 9)); + full = uint256(cint >> 8) << bits; +} + +function decompressRoundingUp(uint64 cint) public pure returns (uint256 full) { + uint8 bits = uint8(cint % (1 << 9)); + full = uint256(cint >> 8) << bits + ((1 << bits) - 1); +} +``` + +The above gist has `library CInt64` that contains demonstrative logic for compression, decompression, and arithmetic for `cint64`. The gist also has an example contract that uses the library for demonstration purposes. + +The CInt64 format is intended only for storage, while dev should convert it to uint256 form using suitable logic (decompress or decompressRoundingUp) to perform any arithmetic on it. + +## Security Considerations + +The following security considerations are discussed: + +1. Effects due to lossy compression + - Error estimation for `cint64` + - Handling the error +2. Losing precision due to incorrect use of `cintx` +3. Compressing something other than money `uint256`s. + +### 1. Effects due to lossy compression + +When a value is compressed, it causes underflow, i.e. some less significant bits are sacrificed. This results in a `cintx` value whose decompressed value is less than or equal to the actual `uint256` value. + +```solidity +uint a = 2**100 - 1; // 100 # of 1s in binary format +uint c = a.compress().decompress(); + +a > c; // true +a - (2**(100 - 56) - 1) == c; // true + +// Visual example: +// before: 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 +// after: 1111111111111111111111111111111111111111111111111111111100000000000000000000000000000000000000000000 +``` + +#### Error estimation for cint64 + +Let's consider we have a `value` of the order 2m (less than 2m and greater than or equal to 2m-1). + +For all values such that 2m - 1 - (2m-56 - 1) <= `value` <= 2m - 1, the compressed value `cvalue` is 2m - 1 - (2m-56 - 1). + +The maximum error is 2m-56 - 1, approximating it to decimal: 10n-17 (log2(56) is 17). Here `n` is number of decimal digits + 1. + +For e.g. compressing a value of the order $1,000,000,000,000 (or 1T or 1012) to `cint64`, the maximum error turns out to be 1012+1-17 = $10-4 = $0.0001. This means the precision after 4 decimal places is lost, or we can say that the uncompressed value is at maximum $0.0001 smaller. Similarly, if someone is storing $1,000,000 into `cint64`, the uncompressed value would be at maximum $0.0000000001 smaller. In comparison, the storage costs are almost $0.8 to initialize and $0.2 to update (20 gwei, 2000 ETHUSD). + +#### Handling the error + +Note that compression makes the value slightly smaller (underflow). But we also have another operation that also does that. In integer math, the division is a lossy operation (causing underflow). For instance, + +```solidity +10000001 / 2 == 5000000 // true +``` + +The result of the division operation is not always exact, but it's smaller than the actual value, in some cases as in the above example. Though, most engineers try to reduce this effect by doing all the divisions at the end. + +``` +1001 / 2 * 301 == 150500 // true +1001 * 301 / 2 == 150650 // true +``` + +The division operation has been in use in the wild, and plenty of lossy integer divisions have taken place, causing DeFi users to get very very slightly less withdrawal amounts, which they don't even notice. If been careful, then the risk is very negligible. Compression is similar, in the sense that it is also a division by 2shift. If been careful with this too, the effects are minimized. + +In general, one should follow the rule: + +1. When a smart contract has to transfer a compressed amount to a user, they should use a rounded down value (by using `amount.decompress()`). +2. When a smart contract has to transferFrom a compressed amount from a user to itself, i.e charging for some bill, they should use a rounded up value (by using `amount.decompressUp()`). + +The above ensures that smart contract does not loose money due to the compression, it is the user who receives less funds or pays more funds. The extent of rounding is something that is negligible enough for the user. Also just to mention, this rounding up and down pattern is observed in many projects including UniswapV3. + +### 2. Losing precision due to incorrect use of `cintx` + +This is an example where dev errors while using compression can be a problem. + +Usual user amounts mostly have an max entropy of 50, i.e. 1015 (or 250) values in use, that is the reason why we find uint56 enough for storing significant bits. However, let's see an example: + +```solidity +uint64 sharesC = // reading compressed value from storage; +uint64 price = // CALL; +uint64 amountC = sharesC.cmuldiv(price, PRICE_UNIT); +user.transfer(amountC.uncompress()); +``` + +The above code results in a serious precision loss. `sharesC` has an entropy of 50, as well as `priceC` also has an entropy of 50. When we multiply them, we get a value that contains entropies of both, and hence, an entropy of 100. After multiplication is done, `cmul` compresses the value, which drops the entropy of `amountC` to 56 (as we have uint56 there to store significant bits). + +To prevent entropy/precision from dropping, we get out from compression. + +```solidity +uint64 sharesC = shares.compress(); +uint64 priceC = price.compress(); +uint256 amount = sharesC.uncompress() * price / PRICE_UNIT; +user.transfer(amount); +``` + +Compression is only useful when writing to storage while doing arithmetic with them should be done very carefully. + +### 3. Compressing something other than money `uint256`s. + +Compressed Integers is intended to only compress money amount. Technically there are about 1077 values that a `uint256` can store but most of those values have a flat distribution i.e. the probability is 0 or extremely negligible. (What is a probability that a user would be depositing 1000T DAI or 1T ETH to a contract? In normal circumstances it doesn't happen, unless someone has full access to the mint function). Only the amounts that people work with have a non-zero distribution ($0.001 DAI to $1T or 1015 to 1030 in uint256). 50 bits are enough to represent this information, just to round it we use 56 bits for precision. + +Using the same method for compressing something else which have a completely different probability distribution will likely result in a problem. It's best to just not compress if you're not sure about the distribution of values your `uint256` is going to take. And also, for things you think you are sure about using compression for, it's better to give more thought if compression can result in edge cases (e.g. in previous multiplication example). + +### 4. Compressing Stable vs Volatile money amounts + +Since we have a dynamic `uint8 shift` value that can move around. So even if you wanted to represent 1 Million SHIBA INU tokens or 0.0002 WBTC (both $10 as of this writing), cint64 will pick its top 56 significant bits which will take care of the value representation. + +It can be a problem for volatile tokens if the coin is extremely volatile wrt user's native currency. Imagine a very unlikely case where a coin goes 256x up (price went up by 1016 lol). In such cases `uint56` might not be enough as even its least significant bit is very valuable. If such insanely volatile tokens are to be stored, you should store more significant bits, i.e. using `cint96` or `cint128`. + +`cint64` has 56 bits for storing significant, when only 50 were required. Hence there are 6 extra bits, which means that it is fine if the $ value of the cryptocurrency stored in cint64 increases by 26 or 64x. If the value goes down it's not a problem. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-3779.md b/EIPS/eip-3779.md index 454f08e86318e..8250691e74e92 100644 --- a/EIPS/eip-3779.md +++ b/EIPS/eip-3779.md @@ -8,7 +8,7 @@ category: Core author: Greg Colvin (@gcolvin), Greg Colvin , Brooklyn Zelenka (@expede) discussions-to: https://ethereum-magicians.org/t/eip-3779-safe-control-flow-for-the-evm/6975 created: 2021-08-30 -requires: 3540 +requires: 3540, 3670 --- ## Abstract @@ -21,7 +21,7 @@ This EIP specifies validation rules for some important safety properties, includ Valid contracts will not halt with an exception unless they either run out of gas or overflow stack during a recursive subroutine call. -Code must be validated at contract creation time – not runtime – by the provided algorithm or its equivalent. Therefore, a table of valid dynamic jumps is specified in an EOF container _section_. This allows for a one-pass algorithm that is (and must be) linear in the size of the _code_ plus the _section_, so as not to be a DoS vulnerability. +Code must be validated at contract creation time – not runtime – by the provided algorithm or its equivalent. Therefore, tables of valid dynamic jumps are specified in an EOF container _section_. This allows for a one-pass algorithm that is (and must be) linear in the size of the _code_ plus the _section_, so as not to be a DoS vulnerability. ## Motivation @@ -30,7 +30,7 @@ Validating safe control flow at creation time has a few important advantages. * Jump destination validity does not always need to be checked for at runtime, improving performance. * Stack underflow does not ever need to be checked for at runtime, improving performance. -Dynamic jumps, where the destination of a JUMP or JUMPI is not known until runtime, can be an obstacle to statically proving this sort of safety, but have also been seen as necessary to implement the return jump from a subroutine. But consider this example of calling a minimal subroutine +Dynamic jumps, where the destination of a JUMP or JUMPI is not known until runtime, can be an obstacle to statically proving this sort of safety in linear time, but have also been seen as necessary to implement the return jump from a subroutine. But consider this example of calling a minimal subroutine ``` ADD: RTN_ADD @@ -49,26 +49,22 @@ ADDITION: swap1 jump ``` -Note that the return address and the destination address are pushed on the stack as constants, so the `JUMP` instructions are in fact static, not dynamic – they jump to the same `PC` on every run. We do not need (nor typically use) dynamic jumps to implement subroutines. +Note that the return address and the destination address are pushed on the stack as constants -- the `JUMP` instructions are in fact static, not dynamic, in the sense that they jump to the same `PC` on every run. So we do not need (nor typically use) dynamic jumps to implement subroutines. Since many of the jumps we need in practice are static we can validate their safety with a static analysis of the _code_. And since can, we should. -Still, providing for the safe use of dynamic jumps makes for concise and efficient implementations of language constructs like switches and virtual functions. Dynamic jumps can be an obstacle to linear-time validation of EVM bytecode. But even where jumps are dynamic it is possible to tabulate valid destinations in advance, and the Ethereum Object Format gives us a place to store such tables. +Even where jumps are dynamic it is possible to tabulate valid destinations in advance, and the Ethereum Object Format gives us a place to store such tables. Providing for the safe use of dynamic jumps makes for concise and efficient implementations of language constructs like switches and virtual functions. So again, since we can validate the safety of tabulated dynamic jumps with a static analysis of the code, we should. ## Specification -### Dependencies - -We need [EIP-3540: EVM Object Format (EOF)](./eip-3540.md) to support container sections. - ### EOF container changes -1. A new EOF section called `vjumptable` (`section_kind = 4`) is introduced. It contains a sequence of *n* tuples *(jumpsrc, jumpdesti*, sorted in ascending lexicographic order. Each tuple represents a valid jump from one location in the _code_ to another. -2. A new EOF section called `vtraptable` (`section_kind = 5`) is introduced. It contains a sequence of *n* tuples *(jumpsrc, jumpdsti*, sorted in ascending lexicographic order. Each tuple represents a valid jump from one location in the _code_ to another. +1. A new EOF section called `vjumptable` (`section_kind = 4`) is introduced. It contains a sequence of _n_ tuples _(jumpsrc, jumpdesti__, sorted in ascending lexicographic order. Each tuple represents a valid jump from one location in the _code_ to another. +2. A new EOF section called `vtraptable` (`section_kind = 5`) is introduced. It contains a sequence of _n_ tuples _(jumpsrc, jumpdsti_, sorted in ascending lexicographic order. Each tuple represents a valid jump from one location in the _code_ to another. There is one and only one trap table entry for each _jumpsrc_. -At runtime, a dynamic jump cause a search for a match in the `vjumptable.` if found, the jump proceeds to the _jumpdest_. If not, the jump proceeds to the matching _jumpdest_ in the _vtraptable_. In this way dynamic jumps always succeed. +At runtime, a dynamic jump cause a search for a matching _jumpsrc_ and _jumpdst_ in the `vjumptable.` if found, the jump proceeds to the _jumpdest_. If not, the jump proceeds to the _jumpdest_ for the matching _jumpsrc_ in the _vtraptable_. In this way dynamic jumps always succeed, but it is left to the programmer to implement a default case for the trap table. ### Validity @@ -88,33 +84,46 @@ _Execution_ is as defined in the [Yellow Paper](https://ethereum.github.io/yello 4. Invalid jump destination 5. Invalid instruction -We would like to consider EVM _code_ valid iff no execution of the program can lead to an exceptional halting state, but we must be able to validate _code_ in linear time to avoid denial of service attacks. So in practice, we can only partially meet these requirements. Our validation algorithm does not consider the codes data and computations, only its control flow and stack use. This means we will reject programs with any invalid _code_ paths, even if those paths are not reachable at runtime. +We would like to consider EVM _code_ valid iff no execution of the program can lead to an exceptional halting state, but we must be able to validate _code_ in linear time to avoid denial of service attacks. So in practice, we can only partially meet these requirements. Our validation rules do not consider the _code's_ data and computations, only its control flow and stack use. This means we will reject programs with any invalid _code_ paths, even if those paths are not reachable at runtime. -### The Rules +### Validation Rules > This section extends the contact creation validation rules (as defined in EIP-3540.) -0. All instructions are valid. 1. Every `JUMP` and `JUMPI` either * matches at least one tuple in the `vjumptable` or the `vtraptable`, or * is _static_ 2. The stack depth is * always positive and * the same on every path through an opcode. -3. The `stack pointer` is always positive and at most 1024. +3. The number of items on the `data stack` and on the `return stack` is at most 1024. + +A _JUMP_ or _JUMPI_ instruction matches a tuple in a table if the first, `jumpsrc` element equals that instruction's offset in the _code_. -A _JUMP_ or _JUMPI_ instruction matches a tuple in a table if the first, `jumpsrc` element equals that instructions offset in the _code_. +We consider a _JUMP_ or _JUMPI_ instruction to be _static_ if its `jumpsrc` argument was first placed on the stack as a valid `JUMPDEST` (e.g. via a `PUSH…`), and its value has not changed since, other than by a `DUP…` or `SWAP…`. + +The Yellow Paper has the `stack pointer` (`SP`) pointing just past the top item on the `data stack`. We define the `stack base` (`BP`) as the element that the `SP` addressed at the entry to the current _basic block_, or `0` on program entry, and the `stack depth` as the number of stack elements between the current `SP` and the current `BP`. + +Taken together, these rules allow for code to be validated by traversing the control-flow graph, following each edge only once. -We consider a _JUMP_ or _JUMPI_ instruction to be _static_ if its `jumpsrc` argument was first place on the stack as a constant via `PC` or a `PUSH…`, and its value has not changed since, other than by a `DUP…` or `SWAP…`. +## Rationale -We need to define `stack depth`. The Yellow Paper has the `stack pointer` (`SP`) pointing just past the top item on the `data stack`. We define the `stack base` (`BP`)as the element that the `SP` addressed at the entry to the current _basic block_, or `0` on program entry. So we can define the `stack depth` as the number of stack elements between the current `SP` and the current `BP`. +The alternative to checking validity at creation time is checking it at runtime. This hurts performance and is a denial of service vulnerability. Thus the above rules and accompanying one-pass validation algorithm. -#### An Algorithm +_Rule 1_ – requiring static or previously tabulated destinations for `JUMP` and `JUMPI` – simplifies static jumps and constrains dynamic jumps. +* Jump destinations are currently checked at runtime, but static jumps can be validated at creation time. +* Requiring the possible destinations of dynamic jumps to be tabulated in advance allows for tractable bytecode traversal for creation-time validation: a jump table takes up space proportional to the number of jump destinations, so attempting to attack the validation algorithm with large numbers of jump destinations will also reduce the available space for _code_ to be validated. -> This section specifies an algorithm for checking the above the rules. Equivalent code must be run at creation time (as defined in EIP-3540.) +_Rule 2_ – requiring positive, consistent stack depth – ensures sufficient stack. Exceptions can be caused by some irreducible paths like jumping into loops and subroutines, and by calling subroutines with insufficient numbers of arguments. -The following is a pseudo-Go implementation of an algorithm for enforcing program validity. This algorithm is a symbolic execution of the program that recursively traverses the bytecode, following its control flow and stack use and checking for violations of the rules above. It uses a stack to track the slots that hold `PUSHed` constants, from which it pops the destinations to validate during the analysis. +_Rule 3_ – bounding the `stack pointer` – catches all stack overflows that occur without recursion. -This algorithm runs in time equal to `O(vertices + edges)` in the program's control-flow graph, where vertices represent control-flow instructions and the edges represent basic blocks – thus the algorithm takes time proportional to the size of the bytecode. +## Validation Algorithm + +> This section specifies an algorithm for checking the above the rules. Equivalent code must be run at creation time. We assume that the validation defined in EIP-3540 and EIP-3670 has already run to check _Rule 0_, although in practice the algorithms can be merged. + +The following is a pseudo-Go implementation of an algorithm for enforcing program validity. This algorithm is a symbolic execution of the program that recursively traverses the bytecode, following its control flow and stack use and checking for violations of the rules above. It uses a stack to track the slots that hold `PUSHed` constants, from which it pops the destinations to validate during the analysis. + +This algorithm runs in time equal to `O(vertices + edges)` in the program's control-flow graph, where edges represent control flow and the vertices represent _basic blocks_ – thus the algorithm takes time proportional to the size of the bytecode. For simplicity's sake we assume a few helper functions. * `advance_pc()` advances the `PC`, skipping any immediate data. @@ -123,25 +132,19 @@ For simplicity's sake we assume a few helper functions. * dynamic jumps match a valid (_jumpsrc_, _jumpdest_) in the `vjumptable` or `vtraptable` * all jump destinations are `JUMPDEST` bytes and not in immediate data. * `remove_items()` returns the number of items removed from the `stack` by an instruction -* `add_items() returns the number of items added to the `stack`. Items are added as 0xFFFFFFFF. +* `add_items()` returns the number of items added to the `stack`. Items are added as `0xFFFFFFFF`. The `PC`, `PUSH…`, `SWAP…`, `DUP…`, `JUMP`, and `JUMPI` instructions are handled separately. -``` +```go var code [code_len]byte var depth [code_len]unsigned -var stack [1024]uint256 = { -1 } // stack grows down -var sp := 1023 +var stack [1024]int = { -1 } // -1 marks non-constant +var sp := 1023 // stack grows down var bp := 1023 func validate(pc := 0, depth := 0) boolean { for ; pc < code_len; pc = advance_pc(pc) { - // valid instructions only - instruction := bytecode[pc] - if !valid_instruction(instruction) { - return false; - } - // successful termination switch instruction { case STOP return true @@ -158,6 +161,9 @@ func validate(pc := 0, depth := 0) boolean { // if stack depth for `pc` is non-zero we have been here before // so return to break cycle in control flow graph if depth[pc] != 0 { + if depth[pc] != depth { + return false + } return true } depth[pc] = depth @@ -192,7 +198,7 @@ func validate(pc := 0, depth := 0) boolean { return false } - // will enter block at destination + // will enter basic block at destination bp = sp // reset pc to destination of jump @@ -206,24 +212,21 @@ func validate(pc := 0, depth := 0) boolean { if !valid_jumpdest(dest) { return false } - cond := stack[sp++] - - // will enter block at destination or next instruction - bp = sp - - // false side of conditional -- continue to next instruction - if cond == 0 { - pc++ - continue - } - - // reset pc to destination of jump - pc = jumpdest // recurse to jump to code to validate - if !validate(pc) { + if !validate(jumpdest) { return false } + // false side of conditional + + // enter basic block + bp = sp + continue + } + if (instruction == JUMPDEST) { + + // enter basic block + bp = sp continue } @@ -235,24 +238,13 @@ func validate(pc := 0, depth := 0) boolean { // successful termination return true } - -## Rationale - -The alternative to checking validity at creation time is checking it at runtime. This hurts performance and is a denial of service vulnerability. Thus the above rules and accompanying one-pass validation algorithm. - -_Rule 1_ – requiring static or previously tabulated destinations for `JUMP` and `JUMPI` – simplifies static jumps and constrains dynamic jumps. -* Jump destinations are currently checked at runtime, but static jumps can be validated at creation time. -* Requiring the possible destinations of dynamic jumps to be tabulated in advance allows for tractable bytecode traversal for creation-time validation: a jump table takes up space proportional to the number of jump destinations, so attempting to attack the validation algorithm with large numbers of jump destinations will also reduce the available space for _code_ to be validated. - -_Rule 2_ – requiring positive, consistent stack depth – ensures sufficient stack. Exceptions can be caused by irreducible paths like jumping into loops and subroutines, and by calling subroutines with insufficient numbers of arguments. - -_Rule 3_ – bounding the `stack pointer` – catches all stack overflows that occur without recursion. - -Taken together, these rules allow for code to be validated by traversing the control-flow graph, following each edge only once. +``` ## Backwards Compatibility -These changes affect the semantics of existing EVM code – the use of JUMP, JUMPI, and the stack are restricted, such that some _code_ that would always run correctly will nonetheless be invalid EVM _code_. +These changes affect the semantics of EVM code – the use of `JUMP`, `JUMPI`, and the stack are restricted, such that some _code_ that would otherwise run correctly will nonetheless be invalid EVM _code_. + +These changes and associated security guarantees are compatible with the valid use of the control-flow operations introduced by [EIP-2315: Simple Subroutines for the EVM](./eip-2315.md). ## Security Considerations diff --git a/EIPS/eip-3855.md b/EIPS/eip-3855.md index 61cf25dc0d2bc..e86efc6e1316f 100644 --- a/EIPS/eip-3855.md +++ b/EIPS/eip-3855.md @@ -4,7 +4,7 @@ title: PUSH0 instruction description: Introduce a new instruction which pushes the constant value 0 onto the stack author: Alex Beregszaszi (@axic), Hugo De la cruz (@hugo-dc), Paweł Bylica (@chfast) discussions-to: https://ethereum-magicians.org/t/eip-3855-push0-instruction/7014 -status: Draft +status: Review type: Standards Track category: Core created: 2021-02-19 @@ -20,7 +20,7 @@ Many instructions expect offsets as inputs, which in a number of cases are zero. Because of the overall cost many try to use various other instructions to achieve the same effect. Common examples include `PC`, `MSIZE`, `CALLDATASIZE`, `RETURNDATASIZE`, `CODESIZE`, `CALLVALUE`, and `SELFBALANCE`. Some of these cost only 2 gas and are a single byte long, but their value can depend on the context. -We have conducted an analysis on Mainnet (block ranges 8,567,259…8,582,058 and 12,205,970…12,817,405), and ~11.5% of all the `PUSH*` instructions executed push of the value zero. +We have conducted an analysis on Mainnet (block ranges 8,567,259…8,582,058 and 12,205,970…12,817,405), and ~11.5% of all the `PUSH*` instructions executed push a value of zero. The main motivations for this change include: 1. Reducing contract code size. @@ -57,7 +57,7 @@ This EIP introduces a new opcode which did not exists previously. Already deploy ## Security Considerations -The authors are not aware of any impact on security. Note that jumpdest-analysis is unaffected, as `PUSH0` has no payload. +The authors are not aware of any impact on security. Note that jumpdest-analysis is unaffected, as `PUSH0` has no immediate data bytes. ## Copyright diff --git a/EIPS/eip-3860.md b/EIPS/eip-3860.md index ed50f40f729ba..d073fc1c4453f 100644 --- a/EIPS/eip-3860.md +++ b/EIPS/eip-3860.md @@ -4,7 +4,7 @@ title: Limit and meter initcode description: Limit the maximum size of initcode to 49152 and apply extra gas cost of 2 for every 32-byte chunk of initcode author: Martin Holst Swende (@holiman), Paweł Bylica (@chfast), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-3860-limit-and-meter-initcode/7018 -status: Draft +status: Review type: Standards Track category: Core requires: 170 @@ -52,7 +52,7 @@ We define `initcode_cost(initcode)` to equal `INITCODE_WORD_COST * ceil(len(init ### Rules -1. If length of transaction data (`initcode`) in a create transaction (recipient T~t~ being empty) exceeds `MAX_INITCODE_SIZE`, execution results in an exceptional abort. Such a transaction is valid and may be included in a block. +1. If length of transaction data (`initcode`) in a create transaction exceeds `MAX_INITCODE_SIZE`, execution results in an exceptional abort. Such a transaction is valid and may be included in a block. 2. For a create transaction, extend the transaction data cost formula to include `initcode_cost(initcode)`. 3. If length of `initcode` to `CREATE` or `CREATE2` instructions exceeds `MAX_INITCODE_SIZE`, execution results in an exceptional abort. 4. For the `CREATE` and `CREATE2` instructions charge an extra gas cost equaling to `initcode_cost(initcode)`. This cost is deducted before the calculation of the resulting contract address and the execution of `initcode`. (Note that this means before or at the same time as the hashing cost is applied in `CREATE2`.) diff --git a/EIPS/eip-3978.md b/EIPS/eip-3978.md new file mode 100644 index 0000000000000..560db15bdc492 --- /dev/null +++ b/EIPS/eip-3978.md @@ -0,0 +1,49 @@ +--- +eip: 3978 +title: Gas refunds on reverts +description: Do not erase gas refunds on transaction subcall reverts, due users pay a lot of gas for storage non-modification. +author: Anton Bukov (@k06a), Mikhail Melnik (@ZumZoom) +discussions-to: https://ethereum-magicians.org/t/eip-3978-gas-refunds-on-reverts/7071/ +status: Draft +type: Standards Track +category: Core +created: 2021-09-16 +--- + +## Abstract + + Since [EIP-3298](./eip-3298.md) gas refunds works for storage restores only inside the same transaction. For example [ERC-20](./eip-20.md) `approve` + `transferFrom` flow between 2 smart contracts according to [EIP-2200](./eip-2200.md) and [EIP-2929](./eip-2929.md) will cost nearly to `21600` gas with gas refund counter `20000`. But in case of reverting this subcall (containing both `approve` and `transferForm`) gas refund will be erased, while smart contract storage will remain unmodified. I think it should keep storage access costs, but still refund modification costs. + +## Motivation + +Сurrent full cancelling of gas refunds on internal reverts is too unfair. Users pay for non-modification same cost as for modification. + +## Specification + +Let's count all SSTORE gas costs within every subcall, excluding access costs. And on reverting any subcall let's not erase refund counter, but: +``` +tx.gas_refund_counter = tx.gas_refund_counter - call.gas_refund_counter + MIN(call.gas_refund_counter, call.all_sstores_gas_cost) +``` + +## Rationale + +TBD + +## Backwards Compatibility + +No known backward incompatibilities. + +## Test Cases + +TBD + +## Reference Implementation + +TBD + +## Security Considerations + +TBD + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-4.md b/EIPS/eip-4.md index 7ee67e529f41a..2973e03a8d8bc 100644 --- a/EIPS/eip-4.md +++ b/EIPS/eip-4.md @@ -5,7 +5,6 @@ author: Joseph Chow (@ethers) status: Final type: Meta created: 2015-11-17 -superseded-by: 1 --- # Abstract diff --git a/EIPS/eip-4200.md b/EIPS/eip-4200.md new file mode 100644 index 0000000000000..7a0899f5fe09e --- /dev/null +++ b/EIPS/eip-4200.md @@ -0,0 +1,113 @@ +--- +eip: 4200 +title: Static relative jumps +description: RJUMP and RJUMPI instructions with a signed immediate encoding the jump destination +author: Alex Beregszaszi (@axic), Andrei Maiboroda (@gumb0), Paweł Bylica (@chfast) +discussions-to: https://ethereum-magicians.org/t/eip-3920-static-relative-jumps/7108 +status: Draft +type: Standards Track +category: Core +created: 2021-07-16 +requires: 3540, 3670 +--- + +## Abstract + +Two new EVM jump instructions are introduced (`RJUMP` and `RJUMPI`) which encode the destination as a signed immediate value. These can be useful in the majority of (but not all) use cases and offer a cost reduction. + +## Motivation + +A recurring discussion topic is that EVM only has a mechanism for dynamic jumps. They provide a very flexible architecture with only 2 (!) instructions. This flexibility comes at a cost however: it makes analysis of code more complicated and it also (partially) resulted in the need to have the `JUMPDEST` marker. + +In a great many cases control flow is actually static and there is no need for any dynamic behaviour, though not every use case can be solved by static jumps. + +There are various ways to reduce the need for dynamic jumps, some examples: +1. With native support for functions / subroutines +2. A "return to caller" instruction +3. A "switch-case" table with dynamic indexing + +This change does not attempt to solve these, but instead introduces a minimal feature set to allow compilers to decide which is the most adequate option for a given use case. It is expected that compilers will use `RJUMP`/`RJUMPI` almost exclusively, with the exception of returning to the caller continuing to use `JUMP`. + +This functionality does not preclude the EVM from introducing other forms of control flow later on. `RJUMP`/`RJUMPI` can efficiently co-exists with a higher-level declaration of functions, where static relative jumps should be used for intra-function control flow. + +The main benefit of these instruction is reduced gas cost (both at deploy and execution time) and better analysis properties. + +## Specification + +We introduce two new instructions on the same block number [EIP-3540](./eip-3540.md) is activated on: +1. `RJUMP` (0x5c) +2. `RJUMPI` (0x5d) + +If the code is legacy bytecode, both of these instructions result in an *exceptional halt*. (*Note: This means no change to behaviour.*) + +If the code is valid EOF1: +1. `RJUMP relative_offset` (0x5c), sets the `PC` to `PC_post_instruction + relative_offset`. +2. `RJUMPI relative_offset` (0x5d), pops a value (`condition`) from the stack, and sets the `PC` to `PC_post_instruction + ((condition == 0) ? 0 : relative_offset)`. + +The immediate argument `relative_offset` is encoded as a 16-bit **signed** (two's-complement) big-endian value. Under `PC_post_instruction` we mean the `PC` position after the entire immediate value. + +We also extend the validation algorithm of [EIP-3670](./eip-3670.md) to verify that each `RJUMP`/`RJUMPI` has a `relative_offset` pointing to an instruction. This means it cannot point to an immediate data of `PUSHn`/`RJUMP`/`RJUMPI`. It cannot point outside of code bounds. It is allowed to point to a `JUMPDEST`, but is not required to. + +Because the destinations are validated upfront, the cost of these instructions are less than their dynamic counterparts: `RJUMP` should cost 5, and `RJUMPI` should cost 7. This is a reduction of 2 gas, compared to `JUMP` and `JUMPI`. + +## Rationale + +### Relative addressing + +We chose relative addressing in order to support code which is moveable. This also means it can be injected. A technique seen used prior to this EIP to achieve this same goal was to inject code like `PUSHn PC ADD JUMPI`. + +We do not see any significant downside to relative addressing, but it also allows the deprecation of the `PC` instruction. + +*Note: EIP-3670 should reject `PC`.* + +### Immediate size + +The signed 16-bit immediate means that the largest jump distance possible is 32767. In the case the bytecode at `PC=0` starts with an `RJUMP`, it will be possible to jump as far as `PC=32770`. + +Given `MAX_CODE_SIZE = 24576` (in [EIP-170](./eip-170.md)) and `MAX_INITCODE_SIZE = 49152` (in [EIP-3860](./eip-3860.md)), we think the 16-bit immediate is large enough. + +A version with an 8-bit immediate would only allow moving `PC` backward by 125 or forward by 127 bytes. While that seems to be a good enough distance for many for-loops, it is likely not good enough for cross-function jumps, and since the 16-bit immediate is the same size as what a dynamic jump would take in such cases (3 bytes: `JUMP PUSH1 n`), we think having less instructions is better. + +Should there be a need to have immediate encodings of other size (such as 8-bits, 24-bits or 32-bits), it would be possible to introduce new opcodes, similarly to how multiple `PUSH` instructions exist. + +### `PUSHn JUMP` sequences + +If we chose absolute addressing, then `RJUMP` could be viewed similar to the sequence `PUSHn JUMP` (and `RJUMPI` similar to `PUSHn RJUMPI`). In that case one could argue that instead of introducing a new instruction, such sequences should get a discount, because EVMs could optimise them. + +We think this is a bad direction to go: +1. It further complicates the already complex rules of gas calculation. +1. And it either requires a consensus defined internal representation for EVM code, or forces EVM implementations to do optimisations on their own. + +Both of these are risky. Furthermore we think that EVM implementations should be free to chose what optimisations they apply, and the savings do not need to be passed down at all cost. + +Additionally it requires a potentially significant change to the current implementations which depend on a streaming one-by-one execution without a lookahead. + +### Relation to dynamic jumps + +The goal was not to completely replace the current control flow system of the EVM, but to augment it. There are many cases where dynamic jumps are useful, such as returning to the caller. + +It is possible to introduce a new mechanism for having a pre-defined table of valid jump destinations, and dynamically supplying the index within this table to accomplish some form of dynamic jumps. This is very useful for efficiently encoding a form of "switch-cases" statements. It could also be used for "return to caller" cases, however it is likely inefficient or awkward. + +### Lack of `JUMPDEST` + +`JUMPDEST` serves two purposes: +1. To efficiently partition code -- this can be useful for pre-calculating total gas usage for a given *block* (i.e. instructions between `JUMPDEST`s), and for JIT/AOT translation. +2. To explicitly show valid locations (otherwise any non-data location would be valid). + +This functionality is not needed for static jumps, as the analysers can easily tell destinations from the static jump immediates during jumpdest-analysis. + +There are two benefits here: +1. Not wasting a byte for a `JUMPDEST` also means a saving of 200 gas during deployment, for each jump destination. +2. Saving an extra 1 gas per jump during execution, given `JUMPDEST` itself cost 1 gas and is "executed" during jumping. + +## Backwards Compatibility + +This change poses no risk to backwards compatibility, as it is introduced at the same time EIP-3540 is. The new instructions are not introduced for legacy bytecode (code which is not EOF formatted). + +## Security Considerations + +TBA + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-4337.md b/EIPS/eip-4337.md new file mode 100644 index 0000000000000..8adc0ff6b7ee6 --- /dev/null +++ b/EIPS/eip-4337.md @@ -0,0 +1,331 @@ +--- +eip: 4337 +title: Account Abstraction via Entry Point Contract specification +description: An account abstraction proposal which completely avoids consensus-layer protocol changes, instead relying on higher-layer infrastructure. +author: Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Kristof Gazso (@kristofgazso), Namra Patel (@namrapatel), Dror Tirosh (@drortirosh) +discussions-to: https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160 +type: Standards Track +category: ERC +status: Draft +created: 2021-09-29 +--- + +## Abstract + +An account abstraction proposal which completely avoids the need for consensus-layer protocol changes. Instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a `UserOperation`. Users send `UserOperation` objects into a separate mempool. A special class of actor called bundlers (either miners, or users that can send transactions to miners through a bundle marketplace) package up a set of these objects into a transaction making a `handleOps` call to a special contract, and that transaction then gets included in a block. + +## Motivation + +See also ["Implementing Account Abstraction as Part of Eth 1.x"](https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020) and the links therein for historical work and motivation, and [EIP-2938](./eip-2938.md) for a consensus layer proposal for implementing the same goal. + +This proposal takes a different approach, avoiding any adjustments to the consensus layer. It seeks to achieve the following goals: + +* **Achieve the key goal of account abstraction**: allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs (as status quo SC wallets and EIP-3074 both require) +* **Decentralization** + * Allow any bundler (think: miner) to participate in the process of including account-abstracted user operations + * Work with all activity happening over a public mempool; users do not need to know the direct communication addresses (eg. IP, onion) of any specific actors + * Avoid trust assumptions on bundlers +* **Do not require any Ethereum consensus changes**: Ethereum consensus layer development is focusing on the merge and later on scalability-oriented features, and there may not be any opportunity for further protocol changes for a long time. Hence, to increase the chance of faster adoption, this proposal avoids Ethereum consensus changes. +* **Try to support other use cases** + * Privacy-preserving applications + * Atomic multi-operations (similar goal to EIP-3074) + * Pay tx fees with ERC-20 tokens, allow developers to pay fees for their users, and [EIP-3074](./eip-3074.md)-like **sponsored transaction** use cases more generally + +## Specification + +To avoid Ethereum consensus changes, we do not attempt to create new transaction types for account-abstracted transactions. Instead, users package up the action they want their wallet to take in an ABI-encoded struct called a `UserOperation`: + +| Field | Type | Description +| - | - | - | +| `sender` | `Address` | The wallet making the operation | +| `nonce` | `uint256` | Anti-replay parameter; also used as the salt for first-time wallet creation | +| `initCode` | `bytes` | The initCode of the wallet (only needed if the wallet is not yet on-chain and needs to be created) | +| `callData` | `bytes` | The data to pass to the `sender` during the main execution call | +| `callGas` | `uint256` | The amount of gas to allocate the main execution call | +| `verificationGas` | `uint256` | The amount of gas to allocate for the verification step | +| `preVerificationGas` | `uint256` | The amount of gas to pay for to compensate the bundler for for pre-verification execution and calldata | +| `maxFeePerGas` | `uint256` | Maximum fee per gas (similar to EIP 1559 `max_fee_per_gas`) | +| `maxPriorityFeePerGas` | `uint256` | Maximum priority fee per gas (similar to EIP 1559 `max_priority_fee_per_gas`) | +| `paymaster` | `address` | Address sponsoring the transaction (or zero for regular self-sponsored transactions) | +| `paymasterData` | `bytes` | Extra data to send to the paymaster | +| `signature` | `bytes` | Data passed into the wallet along with the nonce during the verification step | + +Users send `UserOperation` objects to a dedicated user operation mempool. A specialized class of actors called **bundlers** (either miners running special-purpose code, or users that can relay transactions to miners eg. through a bundle marketplace such as Flashbots that can guarantee next-block-or-never inclusion) listen in on the user operation mempool, and create **bundle transactions**. A bundle transaction packages up multiple `UserOperation` objects into a single `handleOps` call to a pre-published global **entry point contract**. + +The core interface of the entry point contract is as follows: + +```c++ +function handleOps + (UserOperation[] calldata ops, address payable redeemer) + external; + +function simulateWalletValidation + (UserOperation calldata userOp) + external returns (uint gasUsedByPayForSelfOp); + +function simulatePaymasterValidation + (UserOperation calldata userOp, uint gasUsedByPayForSelfOp) + external view returns (bytes memory context, uint gasUsedByPayForOp); +``` + +The core interface required for a wallet to have is: + +```c++ +function validateUserOp + (UserOperation calldata userOp, uint requiredPrefund) + external; +``` + +### Required entry point contract functionality + +The entry point's `handleOps` function must perform the following steps (we first describe the simpler non-paymaster case). It must make two loops, the **verification loop** and the **execution loop**. In the verification loop, the `handleOps` call must perform the following steps for each `UserOperation`: + +* **Create the wallet if it does not yet exist**, using the initcode provided in the `UserOperation` (if the wallet does not exist _and_ the initcode is empty, the call must fail) +* **Call `validateUserOp` on the wallet**, passing in the `UserOperation` and the required fee. The wallet should verify the operation's signature, and pay the fee if the wallet considers the operation valid. If any `validateUserOp` call fails, `handleOps` must skip execution of at least that operation, and may revert entirely. + +In the execution loop, the `handleOps` call must perform the following steps for each `UserOperation`: + +* **Call the wallet with the `UserOperation`'s calldata**. It's up to the wallet to choose how to parse the calldata; an expected worlflow is for the wallet to have an `execute` function that parses the remaining calldata as a series of one or more calls that the wallet should make. +* **Refund unused gas fees** to the wallet + +![](../assets/eip-4337/image1.png) + +Before accepting a `UserOperation`, bundlers must use an RPC method to locally simulate calling the `simulateWalletValidation` function of the entry point, to verify that the signature is correct and the operation actually pays fees; see the [Simulation section below](#simulation) for details. + +### Extension: paymasters + +We extend the entry point logic to support **paymasters** that can sponsor transactions for other users. This feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with ERC-20 tokens and many other use cases. When the paymaster is not equal to the zero address, the entry point implements a different flow: + +![](../assets/eip-4337/image2.png) + +During the verification loop, in addition to calling `validateUserOp`, the `handleOps` execution also must check that the paymaster has enough ETH staked with the entry point to pay for the operation, and then call `validatePaymasterUserOp` on the paymaster to verify that the paymaster is willing to pay for the operation. Additionally, the `validateUserOp` must be called with a `requiredPrefund` of 0 to reflect that it's the paymaster, and not the wallet, that's paying the fees. + +During the execution loop, the `handleOps` execution must call `postOp` on the paymaster after making the main execution call. It must guarantee the execution of `postOp`, by making the main execution inside an inner call context, and if the inner call context reverts attempting to call `postOp` again in an outer call context. + +Maliciously crafted paymasters _can_ DoS the system. To prevent this, we use a paymaster reputation system; see the [reputation, throttling and banning section](#reputation-scoring-and-throttlingbanning-for-paymasters) for details. + +The paymaster interface is as follows: + +```c++ +function validatePaymasterUserOp + (UserOperation calldata userOp, uint maxcost) + external view returns (bytes memory context); + +function postOp + (PostOpMode mode, bytes calldata context, uint actualGasCost) + external; + +enum PostOpMode { + opSucceeded, // user op succeeded + opReverted, // user op reverted. still has to pay for gas. + postOpReverted // user op succeeded, but caused postOp to revert +} +``` + +To prevent attacks involving malicious `UserOperation` objects listing other users' wallets as their paymasters, the entry point contract must require a paymaster to call the entry point to lock their stake and thereby consent to being a paymaster. Unlocking stake must have a delay. The extended interface for the entry point, adding functions for paymasters to add and withdraw stake, is: + +```c++ +function addStake() external payable +function lockStake() external +function unlockStake(address paymaster) external +function withdrawStake(address payable withdrawAddress) external +``` + +### Client behavior upon receiving a UserOperation + +When a client receives a `UserOperation`, it must first run some basic sanity checks, namely that: + +- Either the `sender` is an existing contract, or the `initCode` is not empty (but not both) +- The `verificationGas` is sufficiently low (`<= MAX_VERIFICATION_GAS`) and the `preVerificationGas` is sufficiently high (enough to pay for the calldata gas cost of serializing the `UserOperation` plus `PRE_VERIFICATION_OVERHEAD_GAS`) +- The paymaster is either the zero address or is a contract which (i) currently has nonempty code on chain, (ii) has registered and has sufficient stake, and (iii) has not been banned +- The callgas is at least the cost of a `CALL` with non-zero value. +- The `maxFeePerGas` and `maxPriorityFeePerGas` are above a configurable minimum value that the client is willing to accept +- The `UserOperation` object is not already present in the pool (or it replaces an existing entry with the same sender, nonce with a higher priority) + +If the `UserOperation` object passes these sanity checks, the client must next simulate the op, and if the simulation succeeds, the client must add the op to the pool. Simulation must also happen during bundling to make sure that the storage accessed is the same as the `accessList` that was saved during the initial simulation. + +### Simulation + +To simulate a `UserOperation` `op`, the client makes an `eth_call` with the following params: + +```python +{ + "from": 0x0000000000000000000000000000000000000000, + "to": [entry point address], + "input": [simulateWalletValidation header] + serialize(op), + "gas": op.verificationGas, +} +``` + +If the call returns an error, the client rejects the `op`. If it succeeds, the output is interpreted as an integer `gasUsedByPayForSelfOp`. If `op.paymaster != ZERO_ADDRESS`, the client must then make an `eth_call` with the following params: + +```python +{ + "from": 0x0000000000000000000000000000000000000000, + "to": [entry point address], + "input": [simulatePaymasterValidation header] + + abi_encode(serialize(op), gasUsedByPayForSelfOp), + "gas": op.verificationGas - gasUsedByPayForSelfOp, +} +``` + +While simulating, the client should make sure that: + +1. Neither call's execution trace invokes any **forbidden opcodes** +2. The first call does not access _mutable state_ of any contract except the wallet itself +3. The second call does not access _mutable state_ of any contract except the paymaster itself + +If a contract (i) does not contain the `SELFDESTRUCT` or `DELEGATECALL` opcode [except perhaps inside pushdata] and (ii) has nonempty code, _mutable state_ of that contract is defined as storage slots (accessed with SLOAD or SSTORE). If a contract does not satisfy either of the above conditions, mutable state of that contract includes code and storage. Note that balance can not be read in any case because of the forbidden opcode restriction. _Writing_ balance (via value-bearing calls) to any address is not restricted. + +In practice, restrictions (2) and (3) basically mean that the only external accesses that the wallet and the paymaster can make are reading code of other contracts if their code is guaranteed to be immutable (eg. this is useful for calling or delegatecalling to libraries). + +If any of the three conditions is violated, the client should reject the `op`. If both calls succeed (or, if `op.paymaster == ZERO_ADDRESS` and the first call succeeds) without violating the three conditions, the client should accept the op. On a bundler node, the storage keys accessed by both calls must be saved as the `accessList` of the `UserOperation` + +#### Forbidden opcodes + +The forbidden opcodes are to be forbidden when `depth > 2` (i.e. when it is the wallet, paymaster, or other contracts called by them that are being executed). They are: `GASPRICE`, `GASLIMIT`, `DIFFICULTY`, `TIMESTAMP`, `BASEFEE`, `BLOCKHASH`, `NUMBER`, `SELFBALANCE`, `BALANCE`, `ORIGIN`, `GAS`. They should only be forbidden during verification, not execution. These opcodes are forbidden because their outputs may differ between simulation and execution, so simulation of calls using these opcodes does not reliably tell what would happen if these calls are later done on-chain. + +### Reputation scoring and throttling/banning for paymasters + +Clients maintain two mappings with a value for each paymaster: + +* `opsSeen: Map[Address, int]` +* `opsIncluded: Map[Address, int]` + +When the client learns of a new `paymaster`, it sets `opsSeen[paymaster] = 0` and `opsIncluded[paymaster] = 0` . + +The client sets `opsSeen[paymaster] +=1` each time it adds an op with that `paymaster` to the `UserOperationPool`, and the client sets `opsIncluded[paymaster] += 1` each time an op that was in the `UserOperationPool` is included on-chain. + +Every hour, the client sets `opsSeen[paymaster] -= opsSeen[paymaster] // 24` and `opsIncluded[paymaster] -= opsIncluded[paymaster] // 24` for all paymasters (so both values are 24-hour exponential moving averages). + +We define the **status** of a paymaster as follows: + +```python +OK, THROTTLED, BANNED = 0, 1, 2 + +def status(paymaster: Address, + opsSeen: Map[Address, int], + opsIncluded: Map[Address, int]): + if paymaster not in opsSeen: + return OK + min_expected_included = opsSeen[paymaster] // MIN_INCLUSION_RATE_DENOMINATOR + if min_expected_included + THROTTLING_SLACK >= opsIncluded[paymaster]: + return OK + elif min_expected_included + BAN_SLACK >= opsIncluded[paymaster]: + return THROTTLED + else: + return BANNED +``` + +Stated in simpler terms, we expect at least `1 / MIN_INCLUSION_RATE_DENOMINATOR` of all ops seen on the network to get included. If a paymaster falls too far behind this minimum, the paymaster gets **throttled** (meaning, the client does not accept ops from that paymaster if there is already an op from that paymaster, and an op only stays in the pool for 10 blocks), If the paymaster falls even further behind, it gets **banned**. Throttling and banning naturally reverse over time because of the exponential-moving-average rule. + +**Non-bundling clients and bundlers should use different settings for the above params**: + +| Param | Client setting | Bundler setting | +| - | - | - | +| `MIN_INCLUSION_RATE_DENOMINATOR` | 100 | 10 | +| `THROTTLING_SLACK` | 10 | 10 | +| `BAN_SLACK` | 50 | 50 | + +To help make sense of these params, note that a malicious paymaster can at most cause the network (only the p2p network, not the blockchain) to process `BAN_SLACK * MIN_INCLUSION_RATE_DENOMINATOR / 24` non-paying ops per hour. + +### RPC methods + +`eth_sendUserOperation` + +```json= +{ + "jsonrpc": "2.0", + "id": 1, + "method": "eth_sendUserOperation", + "params": [ + { + sender, // Address + nonce, // uint256 + initCode, // bytes + callData, //bytes + callGas, // uint256 + verificationGas, // uint256 + maxFeePerGas, // uint256 + maxPriorityFeePerGas, // uint256 + paymaster, // address + paymasterData, // bytes + signature // bytes + } + ] +} +``` + +`eth_callUserOperation` + +```json= +{ + "jsonrpc": "2.0", + "id": 1, + "method": "eth_callUserOperation", + "params": [ + { + sender, // Address + nonce, // uint256 + initCode, // bytes + callData, //bytes + callGas, // uint256 + verificationGas, // uint256 + maxFeePerGas, // uint256 + maxPriorityFeePerGas, // uint256 + paymaster, // address + paymasterData, // bytes + signature, // bytes + blockNumber, // hex-encoded uint256 + } + ] +} +``` + +## Rationale + +The main challenge with a purely smart contract wallet based account abstraction system is DoS safety: how can a miner including an operation make sure that will actually pay fees, without having to first execute the entire operation? Requiring the miner to execute the entire operation opens a DoS attack vector, as an attacker could easily send many operations that pretend to pay a fee but then revert at the last moment after a long execution. Similarly, to prevent attackers from cheaply clogging the mempool, nodes in the P2P network need to check if a operation will pay a fee before they are willing to forward it. + +In this proposal, we expect wallets to have a `validateUserOp` method that takes as input a `UserOperation`, and verify the signature and pay the fee. This method is required to be almost-pure: it is only allowed to access the storage of the wallet itself, cannot use environment opcodes (eg. `TIMESTAMP`), and can only edit the storage of the wallet, and can also send out ETH (needed to pay the entry point). The method is gas-limited by the `verificationGas` of the `UserOperation`; nodes can choose to reject operations whose `verificationGas` is too high. These restrictions allow miners and network nodes to simulate the verification step locally, and be confident that the result will match the result when the operation actually gets included into a block. + +The entry point-based approach allows for a clean separation between verification and execution, and keeps wallets' logic simple. The alternative would be to require wallets to follow a template where they first self-call to verify and then self-call to execute (so that the execution is sandboxed and cannot cause the fee payment to revert); template-based approaches were rejected due to being harder to implement, as existing code compilation and verification tooling is not designed around template verification. + +### Paymasters + +Paymasters facilitate transaction sponsorship, allowing third-party-designed mechanisms to pay for transactions. Many of these mechanisms _could_ be done by having the paymaster wrap a `UserOperation` with their own, but there are some important fundamental limitations to that approach: + +* No possibility for "passive" paymasters (eg. that accept fees in some ERC-20 token at an exchange rate pulled from an on-chain DEX) +* Paymasters run the risk of getting griefed, as users could send ops that appear to pay the paymaster but then change their behavior after a block + +The paymaster scheme allows a contract to passively pay on users' behalf under arbitrary conditions. It even allows ERC-20 token paymasters to secure a guarantee that they would only need to pay if the user pays them: the paymaster contract can check that there is sufficient approved ERC-20 balance in the `validatePaymasterUserOp` method, and then extract it with `transferFrom` in the `postOp` call; if the op itself transfers out or de-approves too much of the ERC-20s, the inner `postOp` will fail and revert the execution and the outer `postOp` can extract payment (note that because of storage access restrictions the ERC-20 would need to be a wrapper defined within the paymaster itself). + +### First-time wallet creation + +It is an important design goal of this proposal to replicate the key property of EOAs that users do not need to perform some custom action or rely on an existing user to create their wallet; they can simply generate an address locally and immediately start accepting funds. + +This is accomplished by having the entry point itself create wallets using CREATE2. The `UserOperation` struct has an `initCode` field; this field would be empty for all operations by a given wallet after the first, but the first operation would fill in the `initCode`. The entry point uses [EIP-2470](./eip-2470.md) deployer contract to create the wallet, and then performs the operation. The user can compute the address of their wallet by locally running the [EIP 1014](./eip-1014.md) CREATE2 address formula. The salt used is the `nonce` of the `UserOperation`. +(The entry point contract has a utility method `getSenderAddress()` for that purpose) + +### Entry point upgrading + +Wallets are encouraged to be DELEGATECALL forwarding contracts for gas efficiency and to allow wallet upgradability. The wallet code is expected to hard-code the entry point into their code for gas efficiency. If a new entry point is introduced, whether to add new functionality, improve gas efficiency, or fix a critical security bug, users can self-call to replace their wallet's code address with a new code address containing code that points to a new entry point. During an upgrade process, it's expected that two mempools will run in parallel. + +## Backwards Compatibility + +This ERC does not change the consensus layer, so there are no backwards compatibility issues for Ethereum as a whole. Unfortunately it is not easily compatible with pre-ERC-4337 wallets, because those wallets do not have a `validateUserOp` function. If the wallet has a function for authorizing a trusted op submitter, then this could be fixed by creating an ERC-4337-compatible wallet that re-implements the verification logic as a wrapper and setting it to be the original wallet's trusted op submitter. + +## Reference Implementation + +See https://github.com/opengsn/account-abstraction/tree/main/contracts + +## Security considerations + +The entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for _all_ ERC 4337 wallets. In total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual _wallets_ have to do becomes much smaller (they need only verify the `validateUserOp` function and its "check signature, increment nonce and pay fees" logic) and check that other functions are `msg.sender == ENTRY_POINT` gated (perhaps also allowing `msg.sender == self`), but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust. + +Verification would need to cover two primary claims (not including claims needed to protect paymasters, and claims needed to establish p2p-level DoS resistance): + +* **Safety against arbitrary hijacking**: The entry point only calls a wallet generically if `validateUserOp` to that specific wallet has passed (and with `op.calldata` equal to the generic call's calldata) +* **Safety against fee draining**: If the entry point calls `validateUserOp` and passes, it also must make the generic call with calldata equal to `op.calldata` + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-4345.md b/EIPS/eip-4345.md new file mode 100644 index 0000000000000..fa835f603622d --- /dev/null +++ b/EIPS/eip-4345.md @@ -0,0 +1,60 @@ +--- +eip: 4345 +title: Difficulty Bomb Delay to June 2022 +description: Delays the difficulty bomb to be noticeable in June 2022. +author: Tim Beiko (@timbeiko), James Hancock (@MadeOfTin), Thomas Jay Rush (@tjayrush) +discussions-to: https://ethereum-magicians.org/t/eip-4345-difficulty-bomb-delay-to-may-2022/7209 +status: Review +type: Standards Track +category: Core +created: 2021-10-05 +--- + +## Abstract +Starting with `FORK_BLOCK_NUMBER` the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 10,700,000 blocks later than the actual block number. + +## Motivation +Targeting for The Merge to occur before June 2022. If it is not ready by then, the bomb can be delayed further. + +## Specification +#### Relax Difficulty with Fake Block Number +For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: +```py + fake_block_number = max(0, block.number - 10_700_000) if block.number >= FORK_BLOCK_NUMBER else block.number +``` +## Rationale + +The following script predicts a ~0.1 second delay to block time by June 2022 and a ~0.5 second delay by July 2022. This gives reason to address because the effect will be seen, but not so much urgency we don't have space to work around if needed. + +```python +def predict_diff_bomb_effect(current_blknum, current_difficulty, block_adjustment, months): + ''' + Predicts the effect on block time (as a ratio) in a specified amount of months in the future. + Vars used for predictions: + current_blknum = 13423376 # Oct 15, 2021 + current_difficulty = 9545154427582720 + block adjustment = 10700000 + months = 7.5 # June 2022 + months = 8.5 # July 2022 + ''' + blocks_per_month = (86400 * 30) // 13.3 + future_blknum = current_blknum + blocks_per_month * months + diff_adjustment = 2 ** ((future_blknum - block_adjustment) // 100000 - 2) + diff_adjust_coeff = diff_adjustment / current_difficulty * 2048 + return diff_adjust_coeff + + +diff_adjust_coeff = predict_diff_bomb_effect(13423376,9545154427582720,10700000,7.5) +diff_adjust_coeff = predict_diff_bomb_effect(13423376,9545154427582720,10700000,8.5) +``` + +## Backwards Compatibility +No known backward compatibility issues. + +## Security Considerations +Misjudging the effects of the difficulty can mean longer blocktimes than anticipated until a hardfork is released. Wild shifts in difficulty can affect this number severely. Also, gradual changes in blocktimes due to longer-term adjustments in difficulty can affect the timing of difficulty bomb epochs. This affects the usability of the network but unlikely to have security ramifications. + +In this specific instance, it is possible that the network hashrate drops considerably before The Merge, which could accelerate the timeline by which the bomb is felt in block times. The offset value chosen aimed to take this into account. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-4396.md b/EIPS/eip-4396.md new file mode 100644 index 0000000000000..1e348947efe3e --- /dev/null +++ b/EIPS/eip-4396.md @@ -0,0 +1,158 @@ +--- +eip: 4396 +title: Time-Aware Base Fee Calculation +description: Accounts for block time in the base fee calculation to target a stable throughput by time instead of by block. +author: Ansgar Dietrichs (@adietrichs) +discussions-to: https://ethereum-magicians.org/t/eip-4396-time-aware-base-fee-calculation/7363 +status: Draft +type: Standards Track +category: Core +created: 2021-10-28 +--- + +## Abstract +This EIP proposes accounting for time between blocks in the base fee calculation to target a stable throughput by time, instead of by block. Aiming to minimize changes to the calculation, it only introduces a variable block gas target proportional to the block time. The EIP can, in principle, be applied to either a Proof-of-Work or a Proof-of-Stake chain, however the security implications for the Proof-of-Work case remain unexplored. + +## Motivation + +The current base fee calculation chooses the gas usage of a block as the signal to determine whether demand for block space is too low (indicating that the base fee should be lowered) or too high (indicating that the base fee should be increased). While simple, this choice of signal has drawbacks: it does not take the block time into account. Assuming a relatively constant demand, a proposer constructing a block after 20 seconds will have transactions available with twice the gas of a proposer constructing a block after 10 seconds. Using the same gas target for both is accordingly sub-optimal. In practice, there are several undesirable consequences of this flawed signal: + +### Base Fee Volatility Under Proof-of-Work + +Under Proof-of-Work (PoW), block times are stochastic, and for that reason there exists large block time variability. This variability contributes to the base fee volatility, where the base fee can be expected to oscillate around the equilibrium value even under perfectly stable demand. + +### Missed Slots + +Under Proof-of-Stake (PoS), block times are ideally uniform (always 12s), but missed slots lead to individual blocks with increased block time (24s, 36s, ...). Such missed slots will result in the next block being overfull, and with the current update rule, signal a fake demand spike and thus cause a small unwarranted base fee spike. + +More importantly, these missed slots directly reduce the overall throughput of the execution chain by the gas target of one block. While the next block can be expected to include the "delayed" transactions of the missed slot, the resulting base fee spike then results in some number of under-full blocks. In the end the block space of the missed slot is lost for the chain. + +This is particularly problematic because a Denial-of-Service (DoS) attack on block proposers can cause them to miss slots, and compromises the overall chain performance. + +### Throughput Degradation During Consensus Issues + +A more severe version of individual missed slots can be caused by consensus issues that prevent a significant portion of block proposers from continuing to create blocks. This can be due to block proposers forking off (and creating blocks on their own fork), being unable to keep up with the current chain head for another reason, or simply being unable to create valid blocks. + +In all these situations, average block times go up significantly, causing chain throughput to fall by the same fraction. While this effect is already present under PoW, the self-healing mechanism of difficulty adjustments is relatively quick to kick in and restore normal block times. On the other hand, under PoS the automatic self-healing mechanism can be extremely slow: potentially several months to return to normal with up to a third of slots missed, or several weeks if more than a third of slots are missed. + +For all these reasons, it would be desirable to target a stable throughput per time instead of per block, by taking block time into account during the base fee calculation. + +To maximize the chance of this EIP being included in the merge fork, the adjustments are kept to a minimum, with more involved changes discussed in the rationale section. + +## Specification +Using the pseudocode language of [EIP-1559](./eip-1559.md), the updated base fee calculation becomes: + +```python +... + +BASE_FEE_MAX_CHANGE_DENOMINATOR = 8 +BLOCK_TIME_TARGET = 12 +MAX_GAS_TARGET_PERCENT = 95 + +class World(ABC): + def validate_block(self, block: Block) -> None: + parent_gas_limit = self.parent(block).gas_limit + parent_block_time = self.parent(block).timestamp - self.parent(self.parent(block)).timestamp + parent_base_gas_target = parent_gas_limit // ELASTICITY_MULTIPLIER + parent_adjusted_gas_target = min(parent_base_gas_target * parent_block_time // BLOCK_TIME_TARGET, parent_gas_limit * MAX_GAS_TARGET_PERCENT // 100) + parent_base_fee_per_gas = self.parent(block).base_fee_per_gas + parent_gas_used = self.parent(block).gas_used + + ... + + if parent_gas_used == parent_adjusted_gas_target: + expected_base_fee_per_gas = parent_base_fee_per_gas + elif parent_gas_used > parent_adjusted_gas_target: + gas_used_delta = parent_gas_used - parent_adjusted_gas_target + base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_base_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR, 1) + expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta + else: + gas_used_delta = parent_adjusted_gas_target - parent_gas_used + base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_base_gas_target // BASE_FEE_MAX_CHANGE_DENOMINATOR + expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta + + ... + + ... +``` + +## Rationale + +### Mechanism + +The proposed new base fee calculation only adjusts the block gas target by scaling it with the block time, capped at a maximum percent of the overall block gas limit: + +#### Current Base Fee Calculation + +![](../assets/eip-4396/old_formula.png) + +#### Proposed Base Fee Calculation + +![](../assets/eip-4396/new_formula.png) + +This new calculation thus targets a stable throughput per time instead of per block. + +### Limitations + +Under PoS, block time increases always come in multiples of full blocks (e.g. a single missed slot = 24s instead of 12s block time). Accounting for this already requires doubling the block gas target, even for a single missed slot. However, with the block elasticity currently set to 2, this target would be equal to the block gas limit. Having the new target equal to the block gas limit is less than ideal, and thus is reduced slightly, according to the `MAX_GAS_TARGET_PERCENT` parameter. The reason for the existence of this parameter is twofold: + +- Ensure that the signal remains meaningful: A target equal to or greater than the gas limit could never be reached, so the base fee would always be reduced after a missed slot. +- Ensure that the base fee can still react to genuine demand increases: During times of many offline block proposers (and thus many missed slots), genuine demand increases still need a way to eventually result in a base fee increase, to avoid a fallback to a first-price priority fee auction. + +However, this means that even a single missed slot cannot be fully compensated. Even worse, any second or further sequential missed slot cannot be compensated for at all, as the gas target is already at its max. This effect becomes more pronounced as the share of offline validators increases: + +![](../assets/eip-4396/degradation.png) + +As can be observed, while this EIP does indeed increase the robustness of the network throughput in cases of offline validators, it does so imperfectly. Furthermore, there is a tradeoff effected by the `MAX_GAS_TARGET_PERCENT` parameter, with a higher value resulting in a higher network robustness, but a more impaired base fee adjustment mechanism during times of frequent missed slots. + +### Possible Extensions + +These limitations directly result from the design goal of a minimal change, to maximize chances of being included in the merge. There are natural ways of extending the EIP design to more effectively handle offline validators, at the expense of somewhat more extensive changes: + +#### Persistent Multi-Slot Buffer + +To be able to compensate multiple consecutive missed slots, a gas buffer could be introduced, that would allow the gas beyond the block elasticity to be carried forward to future blocks. To avoid long-run buffer accumulation that would delay a return to normal operations once block proposers are back online, a cap on the buffer would be added. Even for a relatively small buffer cap, the throughput robustness is significantly improved: + +![](../assets/eip-4396/degradation_buffers.png) + +With an elasticity still at 2, there is no way of avoiding the eventual breakdown for more than 50% offline block proposers. + +The main implementation complexity for this approach comes from the introduction of the buffer as a new persistent field. To retain the ability for calculating base fees only based on headers, it would have to be added to the block header. + +#### Increased Block Elasticity + +In addition to the introduction of a buffer, increasing the block elasticity is another tool for increasing throughput robustness. The following diagram shows the effect of different elasticity levels, both in the presence and absence of a persistent buffer: + +![](../assets/eip-4396/degradation_elasticity.png) + +Again, a clear positive effect can be observed. + +The main additional complexity here would come from the increased peak load (networking, compute & disk access) of multiple sequential overfull blocks. Note though that PoS with its minimum block time of 12s significantly reduces worst case peak stress as compared to PoW. + +## Backwards Compatibility + +The EIP has minimal impact on backwards compatibility, only requiring updates to existing base fee calculation tooling. + +## Test Cases +tbd + +## Reference Implementation +tbd + +## Security Considerations + +### Timestamp Manipulation + +Under PoW, miners are in control over the timestamp field of their blocks. While there are some enforced limits to valid timestamps, implications regarding potential timestamp manipulation are nontrivial and remain unexplored for this EIP. + +Under PoS, each slot has a [fixed assigned timestamp](https://github.com/ethereum/consensus-specs/blob/v1.1.3/specs/merge/beacon-chain.md#process_execution_payload), rendering any timestamp manipulation by block proposers impossible. + +### Suppressing Base Fee Increases +As discussed in the rationale, a high value for `MAX_GAS_TARGET_PERCENT` during times of many offline block proposers results in a small remaining signal space for genuine demand increases that should result in base fee increases. This in turn decreases the cost for block proposers for suppresing these base fee increases, instead forcing the fallback to a first-price priority fee auction. + +While the arguments of incentive incompatibility for base fee suppression of the the base EIP-1559 case still apply here, with a decreasing cost of this individually irrational behavior the risk for overriding psychological factors becomes more significant. + +Even in such a case the system degradation would however be graceful, as it would only temporarily suspend the base fee burn. As soon as the missing block proposers would come back online, the system would return to its ordinary EIP-1559 equilibrium. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-4399.md b/EIPS/eip-4399.md new file mode 100644 index 0000000000000..642bf01644372 --- /dev/null +++ b/EIPS/eip-4399.md @@ -0,0 +1,126 @@ +--- +eip: 4399 +title: Supplant DIFFICULTY opcode with RANDOM +author: Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo) +discussions-to: https://ethereum-magicians.org/t/eip-4399-supplant-difficulty-opcode-with-random/7368 +status: Draft +type: Standards Track +category: Core +created: 2021-10-30 +requires: 3675 +--- + +## Abstract + +This EIP supplants the semantics of the return value of existing `DIFFICULTY` opcode and renames the opcode to `RANDOM`. + +The return value of the `DIFFICULTY` opcode after this change is the output of the randomness beacon provided by the beacon chain. + + +## Motivation + +Applications may benefit from using the randomness accumulated by the beacon chain. Thus, randomness outputs produced by the beacon chain should be accessible in the EVM. + +At the point of `TRANSITION_POS_BLOCK` of the Proof-of-Stake (PoS) upgrade described in [EIP-3675](./eip-3675.md), the `difficulty` block field **MUST** be `0` thereafter because there is no longer any Proof-of-Work (PoW) seal on the block. This means that the `DIFFICULTY` opcode no longer has it's previous semantic meaning, nor a clear "correct" value to return. + +Given prior analysis on the usage of `DIFFICULTY`, the value returned by the opcode mixed with other values is a common pattern used by smart contracts to obtain randomness. The instruction with the same number as the `DIFFICULTY` opcode returning the output of the beacon chain randomness makes the upgrade to PoS backwards compatible for existing smart contracts obtaining randomness from the `DIFFICULTY` opcode. + +Additionally, changes proposed by this EIP allow for smart contracts to determine whether the upgrade to the PoS has already happened. This can be done by analyzing the return value of the `DIFFICULTY` opcode. A value greater than `2**64` indicates that the transaction is being executed in the PoS block. + + +## Specification + +### Definitions + +* **`TRANSITION_POS_BLOCK`** The definition of this block can be found in the Definitions section of [EIP-3675](./eip-3675.md#definitions). + +### Block structure + +Beginning with `TRANSITION_POS_BLOCK`, client software **MUST** set the value of the `mixHash`, i.e. the field with the number `13` (0-indexed) in a block header, to the output of the randomness beacon provided by the beacon chain. + +### EVM + +Beginning with `TRANSITION_POS_BLOCK`, the `DIFFICULTY` opcode, i.e. the EVM instruction with the number `0x44`, **MUST** return the value of the `mixHash` field. + +*Note*: The gas cost of the `DIFFICULTY` opcode remains unchanged. + +### Renaming + +The `mixHash` field **SHOULD** further be renamed to `random`. + +The `DIFFICULTY` opcode **SHOULD** further be renamed to `RANDOM`. + + +## Rationale + +### Including randomness output in the block header + +Including the randomness output in the block header provides a straightforward method of accessing it from inside of the EVM as block header data is already available in the EVM context. + +Additionally, this ensures that the execution layer can be fully executed with the block alone rather than requiring extra inputs from the PoS consensus layer. + +Mixing the randomness into a block header may contribute to uniqueness of the block hash in the case when values of other fields of the block header match the corresponding values of the header of another block. + +### Using `mixHash` field instead of `difficulty` + +The `mixHash` header field is used instead of `difficulty` to avoid a class of hidden forkchoice bugs after the PoS upgrade. + +Client software implementing pre-EIP-3675 logic heavily depends on the `difficulty` value as total difficulty computation is the basis of the PoW fork choice rule. Setting the `difficulty` field to `0` at the PoS upgrade aims to reduce the surface of bugs related to the total difficulty value growing after the upgrade. + +Additionally, any latent total difficulty computation after the PoS upgrade would become overflow prone if the randomness output supplanted the value of the `difficulty` field. + +### Reusing existing field instead of appending a new one + +The `mixHash` field is deprecated at the PoS upgrade and set to zero bytes array thereafter. Reusing an existing field as a place for the randomness output saves 32 bytes per block and effectively removes the deprecation of one of the fields induced by the upgrade. + +### Reusing the `DIFFICULTY` opcode instead of introducing a new one + +See the [Motivation](#motivation). + +### Renaming the field and the opcode + +The renaming should be done to make the field and the opcode names semantically sound. + +### Using `TRANSITION_POS_BLOCK` rather than a block or slot number + +By utilizing `TRANSITION_POS_BLOCK` to trigger the change in logic defined in this EIP rather than a block or slot number, this EIP is tightly coupled to the PoS upgrade defined by [EIP-3675](./eip-3675.md). + +By tightly coupling to the PoS upgrade, we ensure that there is no discontinuity for the usecase of this opcode for randomness -- the primary [motivation](#motivation) for re-using `DIFFICULTY` rather than creating a new opcode. + +### Using `2**64` threshold to determine PoS blocks + +The probability of randomness output to fall into the range between `0` and `2**64` and, thus, to be mixed with PoW difficulty values, is drastically low. Though, proposed threshold might seem to have insufficient distance from difficulty values on Ethereum Mainnet (they are currently around `2**54`), it requires a thousand times increase of the hashrate to make this threshold insecure. Such an increase is considered impossible to occur before the upcoming consensus upgrade. + + +## Backwards Compatibility + +This EIP introduces backward incompatible changes to the execution and validation of EVM state transitions. As written, this EIP utilizes `TRANSITION_POS_BLOCK` and is thus tightly coupled with the PoS upgrade introduced in [EIP-3675](./eip-3675.md). If this EIP is to be adopted, it **MUST** be scheduled at the same time as EIP-3675. + +Additionally, the changes proposed might be backward incompatible for the following categories of applications: +* Applications that use the value returned by the `DIFFICULTY` opcode as the PoW `difficulty` parameter +* Applications with logic that depends on the `DIFFICULTY` opcode returning a relatively small number with respect to the full 256-bit size of the field. + +The first category is already affected by switching the consensus mechanism to PoS and no additional breaking changes are introduced by this specification. + +The second category is comprised of applications that use the return value of the `DIFFICULTY` opcode in operations that might cause either overflow or underflow errors. While it is theoretically possible to author an application where a change in the range of possible values this opcode may return could lead to a security vulnerability, the chances of that are negligible. + + +## Test Cases + +Testing this functionality goes beyond this document and should be done in a form of integration testing. + + +## Reference Implementation + +*TBD* + + +## Security Considerations + +The `RANDOM` opcode in the PoS network should be considered as a source of randomness output of a higher strength than the output provided by either the `BLOCKHASH` or the `DIFFICULTY` opcode in the PoW network. + +However, the randomness output returned by the `RANDOM` opcode is revealed to the network within the parent block. + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-4444.md b/EIPS/eip-4444.md new file mode 100644 index 0000000000000..15a13c147f9c5 --- /dev/null +++ b/EIPS/eip-4444.md @@ -0,0 +1,105 @@ +--- +eip: 4444 +title: Bound Historical Data in Execution Clients +description: Prune historical data in clients older than one year +author: George Kadianakis (@asn-d6), lightclient (@lightclient), Alex Stokes (@ralexstokes) +discussions-to: https://ethereum-magicians.org/t/eip-4444-bound-historical-data-in-execution-clients/7450 +status: Draft +type: Standards Track +category: Networking +created: 2021-11-02 +--- + +## Abstract + +Clients must stop serving historical headers, bodies, and receipts older than one year on the p2p layer. Clients may locally prune this historical data. + +## Motivation + +Historical blocks and receipts currently occupy more than 400GB of disk space (and growing!). Therefore, to validate the chain, users must typically have a 1TB disk. + +Historical data is not necessary for validating new blocks, so once a client has synced the tip of the chain, historical data is only retrieved when requested explicitly over the JSON-RPC or when a peer attempts to sync the chain. By pruning the history, this proposal reduces the disk requirements for users. Pruning history also allows clients to remove code that processes historical blocks. This means that execution clients don't need to maintain code paths that deal with each upgrade's compounding changes. + +Finally, this change will result in less bandwidth usage on the network as clients adopt more lightweight sync strategies based on the PoS weak subjectivity assumption. + +## Specification + +| Parameter | Value | Description | +| - | - | - | +| `HISTORY_PRUNE_EPOCHS` | 82125 | A year in beacon chain epochs | + +Clients SHOULD NOT serve headers, block bodies, and receipts that are older than `HISTORY_PRUNE_EPOCHS` epochs on the p2p network. + +Clients MAY locally prune headers, block bodies, and receipts that is older than `HISTORY_PRUNE_EPOCHS` epochs. + +#### Bootstrapping and syncing + +This EIP impacts the way clients bootstrap and sync. Clients will not be able to full sync using devp2p since historical data will no longer be served. + +Clients MUST use a valid Weak Subjectivity Checkpoint to bootstrap from a more recent view of the chain. For the purpose of syncing, clients treat weak subjectivity checkpoints as the genesis block. We call this method "checkpoint sync". + +For the purposes of this proposal, we assume clients always start with a configured and valid weak subjectivity checkpoint. The way this is achieved is out-of-scope for this proposal. + +## Rationale + +This proposal forces clients to stop serving old historical data over p2p. We make this explicit to force clients to seek historical data from other sources, instead of relying on the optional behavior of some clients which would result in quality degradation. + +### Why a year? + +This proposal sets `HISTORY_PRUNE_EPOCHS` to 82125 epochs (one earth year). This constant is large enough to provide sufficient room for the Weak Subjectivity Period to grow, and it's also small enough so as to not occupy too much disk space. + +## Backwards Compatibility + +### Preserving historical data + +This proposal impacts nodes that make use of historical data (e.g. web3 applications that display history of blocks, transactions or accounts). Preserving the history of Ethereum is fundamental and we believe there are various out-of-band ways to achieve this. + +Historical data can be packaged and shared via torrent magnet links or over networks like IPFS. Furthermore, systems like the Portal Network or The Graph can be used to acquire historical data. + +Clients should allow importing and exporting of historical data. Clients can provide scripts that fetch/verify data and automatically import them. + +### Full syncing from genesis + +Full syncing will no longer be possible over the p2p network. However, we do want to allow interested parties to do so on their own. + +We suggest that a specialized "full sync" client is built. The client is a shim that pieces together different releases of execution engines and can import historical blocks to validate the entire Ethereum chain from genesis and generate all other historical data. + +It's important to also note that although archive nodes with "state sync" functionality are in development, full sync is currently the only reliable way to bootstrap them. Clients that wish to continue providing archive support would need the ability to import historical blocks retrieved out-of-band and retain support for each historical upgrade of the network. + +### User experience + +This proposal impacts the UX for setting up applications that use historical data. Hence we suggest that clients introduce this change in two phases: + +In the first phase, clients don't prune historical data by default. They introduce a command line option similar to geth's `--txlookuplimit` that users can use if they want to prune historical data. + +In the second phase, history is pruned by default and the command line option is removed. Clients assume that users will find and import data in an out-of-band way. + +### JSON-RPC changes + +After this proposal is implemented, certain JSON-RPC endpoints (e.g. like `getBlockByHash`) won't be able to tell whether a given hash is invalid or just too old. Other endpoints like `getLogs` will simply no longer have the data the user is requesting. The way this regression should be handled by applications or clients is out-of-scope for this proposal. + +## Security Considerations + +### Relying on weak subjectivity + +With the move to PoS, it's essential for security to use valid weak subjectivity checkpoints because of long-range attacks. + +This proposal relies on the weak subjectivity assumption and assumes that clients will not bootstrap with an invalid or old WS checkpoint. + +This proposal also assumes that the weak subjectivity period will never be longer than `HISTORY_PRUNE_EPOCHS`. If that were to happen, clients with an old weak subjectivity checkpoint would never be able to "checkpoint sync" since the p2p network would not be able to provide the required data. + +### Centralization/censorship risk + +There are censorship/availability risks if there is a lack of incentives to keep historical data. + +It's important that Ethereum historical data are preserved and seeded by independent organizations, and their availability should be checked frequently. We consider these mechanisms as out-of-scope for this proposal. + +Furthermore, there is a risk that more dapps will rely on centralized services for acquiring historical data because it will be harder to setup a full node. + +### Confusion with other proposals + +Because there are a number of alternative proposals for reducing the execution client's footprint on disk, we've decided to enforce a specific pronouncination of the EIP. When pronouncing the EIP number, it **MUST** be pronounced EIP "four fours". All other pronounciations are incorrect. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + diff --git a/EIPS/eip-5.md b/EIPS/eip-5.md index f7c3c47dfbdc9..5c875111d0e9b 100644 --- a/EIPS/eip-5.md +++ b/EIPS/eip-5.md @@ -6,7 +6,6 @@ status: Final type: Standards Track category: Core created: 2015-11-22 -superseded-by: 211 --- ### Abstract diff --git a/EIPS/eip-615.md b/EIPS/eip-615.md index 71d4231448c65..2834ecb4cd2d7 100644 --- a/EIPS/eip-615.md +++ b/EIPS/eip-615.md @@ -1,7 +1,7 @@ --- eip: 615 title: Subroutines and Static Jumps for the EVM -status: Draft +status: Stagnant type: Standards Track category: Core author: Greg Colvin , Brooklyn Zelenka (@expede), Paweł Bylica (@chfast), Christian Reitwiessner (@chriseth) diff --git a/EIPS/eip-616.md b/EIPS/eip-616.md index 91ac3073019bd..22398459c932e 100644 --- a/EIPS/eip-616.md +++ b/EIPS/eip-616.md @@ -4,7 +4,7 @@ title: SIMD Operations for the EVM author: Greg Colvin type: Standards Track category: Core -status: Draft +status: Stagnant created: 2017-04-25 --- diff --git a/EIPS/eip-634.md b/EIPS/eip-634.md index 6a03009113b0f..b34a6e93d506a 100644 --- a/EIPS/eip-634.md +++ b/EIPS/eip-634.md @@ -5,7 +5,7 @@ author: Richard Moore (@ricmoo) type: Standards Track discussions-to: https://github.com/ethereum/EIPs/issues/2439 category: ERC -status: Draft +status: Stagnant created: 2017-05-17 --- diff --git a/EIPS/eip-663.md b/EIPS/eip-663.md index 5617a8ac37921..0bb04205b36b1 100644 --- a/EIPS/eip-663.md +++ b/EIPS/eip-663.md @@ -5,7 +5,7 @@ author: Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-663-unlimited-swap-and-dup-instructions/3346 type: Standards Track category: Core -status: Draft +status: Stagnant created: 2017-07-03 --- diff --git a/EIPS/eip-665.md b/EIPS/eip-665.md index a6dbcd716296c..79a79224c1c36 100644 --- a/EIPS/eip-665.md +++ b/EIPS/eip-665.md @@ -2,7 +2,7 @@ eip: 665 title: Add precompiled contract for Ed25519 signature verification author: Tobias Oberstein -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-03-25 diff --git a/EIPS/eip-689.md b/EIPS/eip-689.md index a5859cd02e0f5..093a32c09ce2a 100644 --- a/EIPS/eip-689.md +++ b/EIPS/eip-689.md @@ -4,7 +4,7 @@ title: Address Collision of Contract Address Causes Exceptional Halt author: Yoichi Hirai type: Standards Track category: Core -status: Draft +status: Stagnant created: 2017-08-15 --- diff --git a/EIPS/eip-698.md b/EIPS/eip-698.md index 6386f8048b02b..c27e36b6f1793 100644 --- a/EIPS/eip-698.md +++ b/EIPS/eip-698.md @@ -3,7 +3,7 @@ eip: 698 title: OPCODE 0x46 BLOCKREWARD author: Cody Burns discussions-to: https://github.com/ethereum/EIPs/issues/698 -status: Draft +status: Stagnant type: Standards Track category: Core created: 2017-08-28 diff --git a/EIPS/eip-712.md b/EIPS/eip-712.md index d8909f2c90f07..486359a356c77 100644 --- a/EIPS/eip-712.md +++ b/EIPS/eip-712.md @@ -414,13 +414,39 @@ To be done before this EIP can be considered accepted: * [x] Finalize specification of structure hashing * [x] Domain separators * [x] Add test vectors -* [ ] Review specification +* [x] Review specification To be done before this EIP can be considered "Final": -* [ ] Implement `eth_signTypedData` in major RPC providers. -* [ ] Implement `web3.eth.signTypedData` in Web3 providers. -* [ ] Implement `keccak256` struct hashing in Solidity. +* [x] Implement `eth_signTypedData` in major RPC providers. +* [x] Implement `web3.eth.signTypedData` in Web3 providers. +* [x] Implement `keccak256` struct hashing in Solidity. + +**Rationale for marking goals as done:** +* `eth_signTypedData` + +MetaMask has had a series of `eth_signTypedData` since 2017 ([article](https://medium.com/metamask/scaling-web3-with-signtypeddata-91d6efc8b290)), and is an accepted standard in the wallet ecosystem. + +* `web3.eth.signTypedData` + +While this api does **not** exist in the web3.js library as of this writing, it is included as an experimental feature in the Ethers library [here](https://medium.com/metamask/scaling-web3-with-signtypeddata-91d6efc8b290). It can also be called from the Web3.js library by using the `sendAsync` method: + +```javascript +web3.currentProvider.sendAsync({ + method: 'eth_signTypedData', + params: [msgParams, from] +``` +In addition, the `signTypedData` function is of limited utility in web3 convenience libraries, as it is generally relevant to the interface that stores the private keys used for signing, and with the excepetionof burner wallets, this is almost always done in practice within a wallet. + +* `keccak256` struct hashing + +While the `keccak256` function in Solidity cannot be invoked directly on structs, the introduction of `abi.encode` gives a sufficient and well-accepted avenue to hashing structs. + +* review of specification + +In the time since EIP-712 has been proposed, it has enjoyed wide ecosystem adoption, and has become the foundation for a number of other EIPs building on top of it. (For example, ERC20 token Permits (transaction-less token approvals) in [EIP-2612](./eip-2612.md).) MetaMask uses EIP-712 for more readable output to present users, and other wallets have followed suit. The widespread traction and use of this EIP over the course of years justify regarding as sufficiently reviewed. + + ## Copyright diff --git a/EIPS/eip-721.md b/EIPS/eip-721.md index 097abddaf3a9b..1551397ef5bc4 100644 --- a/EIPS/eip-721.md +++ b/EIPS/eip-721.md @@ -1,7 +1,7 @@ --- eip: 721 title: Non-Fungible Token Standard -author: William Entriken , Dieter Shirley , Jacob Evans , Nastassia Sachs +author: William Entriken (@fulldecent), Dieter Shirley , Jacob Evans , Nastassia Sachs discussions-to: https://github.com/ethereum/eips/issues/721 type: Standards Track category: ERC @@ -270,7 +270,7 @@ There are many proposed uses of Ethereum smart contracts that depend on tracking **NFT Identifiers** -Every NFT is identified by a unique `uint256` ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair `(contract address, uint256 tokenId)` will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a "black box". Also note that a NFTs MAY become invalid (be destroyed). Please see the enumerations functions for a supported enumeration interface. +Every NFT is identified by a unique `uint256` ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair `(contract address, uint256 tokenId)` will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a "black box". Also note that NFTs MAY become invalid (be destroyed). Please see the enumeration functions for a supported enumeration interface. The choice of `uint256` allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to `uint256`. @@ -287,14 +287,14 @@ Additionally, an authorized operator may set the approved address for an NFT. Th The transfer and accept functions' documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results: - **Disallow transfers if the contract is paused** — prior art, CryptoKitties deployed contract, line 611 -- **Blacklist certain address from receiving NFTs** — prior art, CryptoKitties deployed contract, lines 565, 566 +- **Blocklist certain address from receiving NFTs** — prior art, CryptoKitties deployed contract, lines 565, 566 - **Disallow unsafe transfers** — `transferFrom` throws unless `_to` equals `msg.sender` or `countOf(_to)` is non-zero or was non-zero previously (because such cases are safe) - **Charge a fee to both parties of a transaction** — require payment when calling `approve` with a non-zero `_approved` if it was previously the zero address, refund payment if calling `approve` with the zero address if it was previously a non-zero address, require payment when calling any transfer function, require transfer parameter `_to` to equal `msg.sender`, require transfer parameter `_to` to be the approved address for the NFT - **Read only NFT registry** — always throw from `unsafeTransfer`, `transferFrom`, `approve` and `setApprovalForAll` Failed transactions will throw, a best practice identified in ERC-223, ERC-677, ERC-827 and OpenZeppelin's implementation of SafeERC20.sol. ERC-20 defined an `allowance` feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue \#438. In ERC-721, there is no allowance because every NFT is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20's original design without problems that have been later discovered. -Creating of NFTs ("minting") and destruction NFTs ("burning") is not included in the specification. Your contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying NFTs. +Creation of NFTs ("minting") and destruction of NFTs ("burning") is not included in the specification. Your contract may implement these by other means. Please see the `event` documentation for your responsibilities when creating or destroying NFTs. We questioned if the `operator` parameter on `onERC721Received` was necessary. In all cases we could imagine, if the operator was important then that operator could transfer the token to themself and then send it -- then they would be the `from` address. This seems contrived because we consider the operator to be a temporary owner of the token (and transferring to themself is redundant). When the operator sends the token, it is the operator acting on their own accord, NOT the operator acting on behalf of the token holder. This is why the operator and the previous token owner are both significant to the token recipient. diff --git a/EIPS/eip-725.md b/EIPS/eip-725.md index 1962f0220affe..af0ce7c9214f3 100644 --- a/EIPS/eip-725.md +++ b/EIPS/eip-725.md @@ -1,6 +1,6 @@ --- eip: 725 -title: ERC-725 Smart Contract Based Account +title: General key-value store and execution standard author: Fabian Vogelsteller (@frozeman), Tyler Yasaka (@tyleryasaka) discussions-to: https://github.com/ethereum/EIPs/issues/725 status: Draft @@ -22,7 +22,7 @@ groups, organisations, objects and machines. The standard is divided into two sub standards: `ERC725X`: -Can execute arbitrary smart contracts using and deploy other smart contracts. +Can execute arbitrary smart contracts and deploy other smart contracts. `ERC725Y`: Can hold arbitrary data through a generic key/value store. @@ -48,18 +48,27 @@ ERC165 identifier: `0x44c028fe` #### execute +```solidity +function execute(uint256 operationType, address to, uint256 value, bytes calldata data) public payable returns(bytes memory) +``` + Executes a call on any other smart contracts, transfers the blockchains native token, or deploys a new smart contract. MUST only be called by the current owner of the contract. -```solidity -function execute(uint256 operationType, address to, uint256 value, bytes data) public -``` +_Parameters:_ +- `operationType`: the operation to execute. +- `to`: the smart contract or address to interact with. `to` will be unused if a contract is created (operation 1 and 2). +- `value`: the value of ETH to transfer. +- `data`: the call data, or the contract data to deploy. + +_Returns:_ `bytes` , the returned data of the called function, or the address of the contract created (operation 1 and 2). The `operationType` can execute the following operations: - `0` for `call` -- `1` for `delegatecall` +- `1` for `create` - `2` for `create2` -- `3` for `create` +- `3` for `staticcall` +- `4` for `delegatecall` Others may be added in the future. @@ -69,19 +78,18 @@ Others may be added in the future. #### Executed -MUST be triggered when `execute` creates a new call using any `operationType`. - ```solidity event Executed(uint256 indexed _operation, address indexed _to, uint256 indexed _value, bytes _data); ``` +MUST be triggered when `execute` creates a new call using the `operationType` `0`, `3`, `4`. -#### ContractCreated -MUST be triggered when `execute` creates a new contract using the `operationType` `2`, `3`. +#### ContractCreated ```solidity -event ContractCreated(address indexed contractAddress) +event ContractCreated(uint256 indexed _operation, address indexed _contractAddress, uint256 indexed _value); ``` +MUST be triggered when `execute` creates a new contract using the `operationType` `1`, `2`. ### ERC725Y @@ -89,32 +97,36 @@ ERC165 identifier: `0x5a988c0f` #### getData -Returns array of data at multiple keys. - ```solidity -function getData(bytes32[] calldata _keys) public view returns(bytes[] memory) +function getData(bytes32[] memory _keys) public view returns(bytes[] memory) ``` +Gets array of data at multiple given key. +_Parameters:_ +- `_keys`: the keys which values to retrieve. + +_Returns:_ `bytes[]` , array of the values for the requested keys. #### setData +```solidity +function setData(bytes32[] memory _keys, bytes[] memory _values) public +``` Sets array of data at multiple keys. MUST only be called by the current owner of the contract. -**Triggers Event:** [DataChanged](#datachanged) +_Parameters:_ +- `_keys`: the keys which values to retrieve. +- `_values`: the array of bytes to set. -```solidity -function setData(bytes32[] calldata _keys, bytes[] calldata _values) public -``` +**Triggers Event:** [DataChanged](#datachanged) ### Events #### DataChanged -MUST be triggered when `setData` was successfully called. - ```solidity event DataChanged(bytes32 indexed key, bytes value) ``` - +MUST be triggered when `setData` was successfully called. ### Ownership @@ -122,8 +134,10 @@ This contract is controlled by an owner. The owner can be a smart contract or an This standard requires [ERC173](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-173.md) and should implement the functions: - `owner() view` -- `transferOwnership(address newOwner)` -- and the Event `event OwnershipTransferred(address indexed previousOwner, address indexed newOwner)` +- `transferOwnership(address newOwner)`
+ +The event: +- `OwnershipTransferred(address indexed previousOwner, address indexed newOwner)` ### Data keys @@ -142,18 +156,9 @@ ERC725 key standards need to be defined within new standards, we suggest the fol | SupportedStandards:XYZ | Allows to determine standards supported by this contract | `0xeafec4d89fa9619884b6b89135626455000000000000000000000000xxxxxxxx`, where `xxxxxxxx` is the 4 bytes identifier of the standard supported | Value can be defined by the standard, by default it should be the 4 bytes identifier e.g. `0x7a30e6fc` | | SupportedStandards:ERC725Account | Allows to determine standards supported by this contract | `0xeafec4d89fa9619884b6b89135626455000000000000000000000000afdeb5d6`, where `afdeb5d6` is the 4 bytes part of the hash of `keccak256('ERC725Account')` | Value is the 4 bytes identifier `0xafdeb5d6` | -##### ERC725Account - -An `SupportedStandards` > `ERC725Account` (See key > value above) is an ERC725 smart contract based account/profile for storing of assets and execution of other smart contracts. - -- `ERC173` to be controllable by an owner, that could be am external account, or smart contract -- `ERC725X` to interact with other smart contracts -- `ERC725Y` to attach data to the account for future extensibility -- COULD have [ERC1271](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1271.md) to be able to verify signatures by the owner (or owner contracts keys). -- Should fire the `event ValueReceived(address indexed sender, uint256 indexed value)` if ETH is received. - -A full implementation of an `ERC725Account` can be found [found here](https://github.com/ERC725Alliance/ERC725/tree/master/implementations/contracts). +#### ERC725Account +The specification of an ERC725Account can be found in [LSP0-ERC725Account](https://github.com/lukso-network/LIPs/blob/master/LSPs/LSP-0-ERC725Account.md). ## Rationale The purpose of an smart contract account is to allow an entity to exist as a first-class citizen with the ability to execute arbitrary contract calls. @@ -170,27 +175,24 @@ pragma solidity >=0.5.0 <0.7.0; //ERC165 identifier: `0x44c028fe` interface IERC725X /* is ERC165, ERC173 */ { - event ContractCreated(address indexed contractAddress); + event ContractCreated(uint256 indexed operation, address indexed contractAddress, uint256 indexed value); event Executed(uint256 indexed operation, address indexed to, uint256 indexed value, bytes data); - function execute(uint256 operationType, address to, uint256 value, bytes memory data) public; + function execute(uint256 operationType, address to, uint256 value, bytes calldata data) external payable returns(bytes memory); } //ERC165 identifier: `0x5a988c0f` interface IERC725Y /* is ERC165, ERC173 */ { event DataChanged(bytes32 indexed key, bytes value); - function getData(bytes32[] calldata _keys) public view returns(bytes[] memory); - function setData(bytes32[] calldata _keys, bytes[] calldata _values) public ; + function getData(bytes32[] memory _keys) external view returns(bytes[] memory); + function setData(bytes32[] memory _keys, bytes[] memory _values) external; } interface IERC725 /* is IERC725X, IERC725Y */ { } -interface IERC725Account /* is IERC725, IERC725Y, IERC1271 */ { - event ValueReceived(address indexed sender, uint256 indexed value); -} ``` ## Flow chart diff --git a/EIPS/eip-747.md b/EIPS/eip-747.md index 75f90bf28e59a..cbd6e6e330be5 100644 --- a/EIPS/eip-747.md +++ b/EIPS/eip-747.md @@ -3,7 +3,7 @@ eip: 747 title: Add wallet_watchAsset to Provider author: Dan Finlay (@danfinlay), Esteban Mino (@estebanmino) discussions-to: https://ethereum-magicians.org/t/eip-747-eth-watchtoken/1048 -status: Draft +status: Stagnant type: Standards Track category: Interface created: 2018-08-13 diff --git a/EIPS/eip-758.md b/EIPS/eip-758.md index 30a6f3481e70d..e7e4c7611004c 100644 --- a/EIPS/eip-758.md +++ b/EIPS/eip-758.md @@ -4,7 +4,7 @@ title: Subscriptions and filters for completed transactions author: Jack Peterson type: Standards Track category: Interface -status: Draft +status: Stagnant created: 2017-11-09 requires: 1474 --- diff --git a/EIPS/eip-820.md b/EIPS/eip-820.md index 15c0c5a3895c8..f3edc8306b5ec 100644 --- a/EIPS/eip-820.md +++ b/EIPS/eip-820.md @@ -8,7 +8,6 @@ type: Standards Track category: ERC requires: 165, 214 created: 2018-01-05 -superseded-by: 1820 --- > :information_source: **[ERC-1820] has superseded [ERC-820].** :information_source: diff --git a/EIPS/eip-823.md b/EIPS/eip-823.md index 33731c41cd432..b38d4cb12e18e 100644 --- a/EIPS/eip-823.md +++ b/EIPS/eip-823.md @@ -4,7 +4,7 @@ title: Token Exchange Standard author: Kashish Khullar type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-01-06 requires: 20 --- diff --git a/EIPS/eip-831.md b/EIPS/eip-831.md index 12f00ef58df4b..c97b5aac9ed10 100644 --- a/EIPS/eip-831.md +++ b/EIPS/eip-831.md @@ -4,7 +4,7 @@ title: URI Format for Ethereum author: ligi type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-01-15 --- diff --git a/EIPS/eip-858.md b/EIPS/eip-858.md index 47a495caad8af..144609d997d9f 100644 --- a/EIPS/eip-858.md +++ b/EIPS/eip-858.md @@ -4,7 +4,7 @@ title: Reduce block reward and delay difficulty bomb author: Carl Larson type: Standards Track category: Core -status: Draft +status: Stagnant created: 2018-01-29 --- diff --git a/EIPS/eip-86.md b/EIPS/eip-86.md index a76ccbc33464a..a01a844b3f9bf 100644 --- a/EIPS/eip-86.md +++ b/EIPS/eip-86.md @@ -4,7 +4,7 @@ title: Abstraction of transaction origin and signature author: Vitalik Buterin (@vbuterin) type: Standards Track category: Core -status: Draft +status: Stagnant created: 2017-02-10 --- diff --git a/EIPS/eip-867.md b/EIPS/eip-867.md index 8fd4edb125fb1..cd34ab86d75ae 100644 --- a/EIPS/eip-867.md +++ b/EIPS/eip-867.md @@ -4,7 +4,7 @@ title: Standardized Ethereum Recovery Proposals author: Dan Phifer , James Levy , Reuben Youngblom discussions-to: https://ethereum-magicians.org/t/eip-867-standardized-ethereum-recovery-proposals-erps/139 type: Meta -status: Draft +status: Stagnant created: 2018-02-02 --- diff --git a/EIPS/eip-875.md b/EIPS/eip-875.md index 4673c5584607d..5e99675a588a6 100644 --- a/EIPS/eip-875.md +++ b/EIPS/eip-875.md @@ -4,7 +4,6 @@ title: Simpler NFT standard with batching and native atomic swaps author: Weiwu Zhang , James Sangalli discussions-to: https://github.com/ethereum/EIPs/issues/875 status: Withdrawn -review-period-end: 2019-07-29 type: Standards Track category: ERC created: 2018-02-08 diff --git a/EIPS/eip-884.md b/EIPS/eip-884.md index 9ce29af2cebdc..892566ef8aca6 100644 --- a/EIPS/eip-884.md +++ b/EIPS/eip-884.md @@ -4,7 +4,7 @@ title: DGCL Token author: Dave Sag type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-02-14 --- diff --git a/EIPS/eip-900.md b/EIPS/eip-900.md index a46d5d9b166e3..7718615460c20 100644 --- a/EIPS/eip-900.md +++ b/EIPS/eip-900.md @@ -4,7 +4,7 @@ title: Simple Staking Interface author: Dean Eigenmann , Jorge Izquierdo type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-02-22 discussions-to: https://github.com/ethereum/EIPs/issues/900 --- diff --git a/EIPS/eip-902.md b/EIPS/eip-902.md index 648f82981978c..72c61236807ef 100644 --- a/EIPS/eip-902.md +++ b/EIPS/eip-902.md @@ -5,7 +5,7 @@ author: Brooklyn Zelenka (@expede), Tom Carchrae (@carchrae), Gleb Naumenko (@na discussions-to: https://ethereum-magicians.org/t/update-on-erc902-validated-token/1639 type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-02-14 requires: 1066 --- diff --git a/EIPS/eip-918.md b/EIPS/eip-918.md index b3e54f2ef1cf2..f111d88d93d6a 100644 --- a/EIPS/eip-918.md +++ b/EIPS/eip-918.md @@ -4,7 +4,7 @@ title: Mineable Token Standard author: Jay Logelin , Infernal_toast , Michael Seiler , Brandon Grill type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-03-07 --- diff --git a/EIPS/eip-926.md b/EIPS/eip-926.md index 172f11d845210..5b613fb01b722 100644 --- a/EIPS/eip-926.md +++ b/EIPS/eip-926.md @@ -4,7 +4,7 @@ title: Address metadata registry author: Nick Johnson type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-03-12 requires: 165 --- diff --git a/EIPS/eip-927.md b/EIPS/eip-927.md index d24610b9f59df..e072bcc94011e 100644 --- a/EIPS/eip-927.md +++ b/EIPS/eip-927.md @@ -4,7 +4,7 @@ title: Generalised authorisations author: Nick Johnson type: Standards Track category: ERC -status: Draft +status: Stagnant created: 2018-03-12 requires: 926 --- diff --git a/EIPS/eip-969.md b/EIPS/eip-969.md index 8b6301e621988..5261e3cf5033e 100644 --- a/EIPS/eip-969.md +++ b/EIPS/eip-969.md @@ -3,7 +3,7 @@ eip: 969 title: Modifications to ethash to invalidate existing dedicated hardware implementations author: David Stanfill discussions-to: https://gitter.im/ethereum/topics/topic/5ac4d974109bb043328911ce/eip-969-discussion -status: Draft +status: Stagnant type: Standards Track category: Core created: 2018-04-03 diff --git a/README.md b/README.md index 5c1da17d7dc21..1b32df5737f43 100644 --- a/README.md +++ b/README.md @@ -2,22 +2,9 @@ [![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/ethereum/EIPs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge) -Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. +Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. **Browse all current and draft EIPs on [the official EIP site](https://eips.ethereum.org/).** -**Before you initiate a pull request**, please read the [EIP-1](https://eips.ethereum.org/EIPS/eip-1) process document. Ideas should be thoroughly discussed prior to opening a pull request, such as on the [Ethereum Magicians forums](https://ethereum-magicians.org) or in a GitHub issue in this repository. - -This repository tracks the ongoing status of EIPs. It contains: - -- [Draft](https://eips.ethereum.org/all#draft) proposals where the author(s) are still making changes and is not ready for review. -- [Review ](https://eips.ethereum.org/all#review) for proposals ready for EIP review process and the author(s) are ready for improvement suggestions. -- [Last Call](https://eips.ethereum.org/all#last-call) for proposals that may become final (see also [RSS feed](https://eips.ethereum.org/last-call.xml)). -- [Accepted](https://eips.ethereum.org/all#accepted) proposals which are awaiting implementation or deployment by Ethereum client developers. -- [Final](https://eips.ethereum.org/all#final) and [Living](https://eips.ethereum.org/all#living) proposals that have solidified into a standard. -- The [EIP process](./EIPS/eip-1.md#eip-work-flow) that governs the EIP repository. - -Achieving "Final" status in this repository only represents that a proposal has been reviewed for technical accuracy. It is solely the responsibility of the reader to decide whether a proposal will be useful to them. - -Browse all current and draft EIPs on [the official EIP site](https://eips.ethereum.org/). +**Before you initiate a pull request**, please read the [EIP-1](https://eips.ethereum.org/EIPS/eip-1) process document. Once your first PR is merged, we have a bot that helps out by automatically merging PRs to draft EIPs. For this to work, it has to be able to tell that you own the draft being edited. Make sure that the 'author' line of your EIP contains either your GitHub username or your email address inside \. If you use your email address, that address must be the one publicly shown on [your GitHub profile](https://github.com/settings/profile). @@ -35,12 +22,12 @@ And please consider anything published at https://eips.ethereum.org/ with a stat # Validation -EIPs must pass some validation tests. The EIP repository ensures this by running tests using [html-proofer](https://rubygems.org/gems/html-proofer) and [eip_validator](https://rubygems.org/gems/eip_validator). +EIPs must pass some validation tests. The EIP repository ensures this by running tests using [html-proofer](https://rubygems.org/gems/html-proofer) and [eipv](https://github.com/lightclient/eipv). It is possible to run the EIP validator locally: ```sh -gem install eip_validator -eip_validator +cargo install eipv +eipv ``` # Automerger diff --git a/_includes/eiptable.html b/_includes/eiptable.html index 135a4e24e0b91..e2e2a78257c36 100644 --- a/_includes/eiptable.html +++ b/_includes/eiptable.html @@ -24,8 +24,8 @@

{{status}}

{% for page in eips %} {{page.eip|xml_escape}} - {% if status == "Last Call" and page.review-period-end != undefined %} - {{ page.review-period-end | xml_escape }} + {% if status == "Last Call" and page.last-call-deadline != undefined %} + {{ page.last-call-deadline | xml_escape }} {% endif %} {{page.title|xml_escape}} {% include authorlist.html authors=page.author %} diff --git a/_layouts/eip.html b/_layouts/eip.html index aaa41ae540a51..b680aa6e82a7c 100644 --- a/_layouts/eip.html +++ b/_layouts/eip.html @@ -36,8 +36,8 @@

{{ page.description | xml_escape }}

Discussions-To{{ page["discussions-to"] | xml_escape }} {% endif %} Status{{ page.status | xml_escape }} - {% if page.review-period-end != undefined %} - Review period ends{{ page.review-period-end | xml_escape }} + {% if page.last-call-deadline != undefined %} + Last Call Deadline{{ page.last-call-deadline | xml_escape }} {% endif %} Type{{ page.type | xml_escape }} @@ -51,14 +51,8 @@

{{ page.description | xml_escape }}

{% if page.requires != undefined %} Requires{% include eipnums.html eips=page.requires %} {% endif %} - {% if page.replaces != undefined %} - Replaces{% include eipnums.html eips=page.replaces %} - {% endif %} - {% if page["superseded-by"] != undefined %} - Superseded by{% include eipnums.html eips=page.superseded-by %} - {% endif %} - {% if page.resolution != undefined %} - Resolution{{ page.resolution | xml_escape }} + {% if page["withdrawal-reason"] != undefined %} + Withdrawal reason{{ page["withdrawal-reason"] | xml_escape }} {% endif %} diff --git a/assets/css/style.scss b/assets/css/style.scss index 7467811834584..cad4fa8645a27 100644 --- a/assets/css/style.scss +++ b/assets/css/style.scss @@ -4,6 +4,14 @@ @import 'minima'; +.site-header { + .wrapper { + display: flex; + flex-direction: column; + align-items: center; + } +} + .page-content { a.anchor-link { width: 16px; diff --git a/assets/eip-1/EIP-process-update.jpg b/assets/eip-1/EIP-process-update.jpg new file mode 100644 index 0000000000000..6bc35d31c08f0 Binary files /dev/null and b/assets/eip-1/EIP-process-update.jpg differ diff --git a/assets/eip-3770/EIP-3770-examples.png b/assets/eip-3770/EIP-3770-examples.png new file mode 100644 index 0000000000000..0793b6be0cfc3 Binary files /dev/null and b/assets/eip-3770/EIP-3770-examples.png differ diff --git a/assets/eip-4337/image1.png b/assets/eip-4337/image1.png new file mode 100644 index 0000000000000..ced8ea57d3ebb Binary files /dev/null and b/assets/eip-4337/image1.png differ diff --git a/assets/eip-4337/image2.png b/assets/eip-4337/image2.png new file mode 100644 index 0000000000000..6d0c6f71a4dcc Binary files /dev/null and b/assets/eip-4337/image2.png differ diff --git a/assets/eip-4396/degradation.png b/assets/eip-4396/degradation.png new file mode 100644 index 0000000000000..cc2262a7c8d85 Binary files /dev/null and b/assets/eip-4396/degradation.png differ diff --git a/assets/eip-4396/degradation_buffers.png b/assets/eip-4396/degradation_buffers.png new file mode 100644 index 0000000000000..fd87694598e41 Binary files /dev/null and b/assets/eip-4396/degradation_buffers.png differ diff --git a/assets/eip-4396/degradation_elasticity.png b/assets/eip-4396/degradation_elasticity.png new file mode 100644 index 0000000000000..29c95dd524dc0 Binary files /dev/null and b/assets/eip-4396/degradation_elasticity.png differ diff --git a/assets/eip-4396/new_formula.png b/assets/eip-4396/new_formula.png new file mode 100644 index 0000000000000..46934d36ce573 Binary files /dev/null and b/assets/eip-4396/new_formula.png differ diff --git a/assets/eip-4396/old_formula.png b/assets/eip-4396/old_formula.png new file mode 100644 index 0000000000000..27f07ab7422d0 Binary files /dev/null and b/assets/eip-4396/old_formula.png differ diff --git a/eip-template.md b/eip-template.md index 2051775f0d27b..1cfcce764d65a 100644 --- a/eip-template.md +++ b/eip-template.md @@ -2,14 +2,13 @@ eip: title: description: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> +author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> discussions-to: status: Draft type: category (*only required for Standards Track): created: requires (*optional): -replaces (*optional): --- This is the suggested template for new EIPs. @@ -25,6 +24,8 @@ Abstract is a multi-sentence (short paragraph) technical summary. This should be The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address? ## Specification +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + 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 (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). ## Rationale diff --git a/index.html b/index.html index 06517f107c00e..13220c17c8946 100644 --- a/index.html +++ b/index.html @@ -14,11 +14,14 @@

Contributing

EIP status terms

    -
  • Draft - an EIP that is open for consideration and is undergoing rapid iteration and changes.
    • -
  • Last Call - an EIP that is done with its initial iteration and ready for review by a wide audience.
    • -
  • Accepted - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP will move to final.
    • -
  • Final (non-Core) - an EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
    • -
  • Final (Core) - an EIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork.
    • +
  • Idea - An idea that is pre-draft. This is not tracked within the EIP Repository. +
  • Draft - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
    • +
  • Review - An EIP Author marks an EIP as ready for and requesting Peer Review.
    • +
  • Last Call - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.
    • +
  • Final - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
    • +
  • Stagnant - Any EIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft.
    • +
  • Withdrawn - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.
    • +
  • Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.

EIP Types

@@ -26,7 +29,7 @@

EIP Types

EIPs are separated into a number of types, and each has its own list of EIPs.

Standard Track ({{site.pages|where:"type","Standards Track"|size}})

-

Describes any change that affects most or all Ethereum implementations, such as a change to the 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. Furthermore Standard EIPs can be broken down into the following categories.

+

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. Furthermore Standard EIPs can be broken down into the following categories.

Core ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})

Improvements requiring a consensus fork (e.g. EIP-5, EIP-101), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the miner/node strategy changes 2, 3, and 4 of EIP-86).