├── .codespell-whitelist ├── .gitattributes ├── .github └── workflows │ ├── auto-merge-bot.yml │ ├── auto-stagnate-bot.yml │ ├── greetings.yml │ ├── manual-bot-rerun.yml │ ├── rerun-bot-pull-request-review.yml │ ├── rerun-bot-workflow-run.yml │ └── stale.yml ├── .gitignore ├── .travis-ci.sh ├── .travis.yml ├── 404.html ├── CNAME ├── EIPS ├── eip-1.md ├── eip-100.md ├── eip-101.md ├── eip-1010.md ├── eip-1011.md ├── eip-1013.md ├── eip-1014.md ├── eip-1015.md ├── eip-1046.md ├── eip-1051.md ├── eip-1052.md ├── eip-1056.md ├── eip-1057.md ├── eip-1062.md ├── eip-1066.md ├── eip-107.md ├── eip-1077.md ├── eip-1078.md ├── eip-1080.md ├── eip-1081.md ├── eip-1087.md ├── eip-1102.md ├── eip-1108.md ├── eip-1109.md ├── eip-1123.md ├── eip-1129.md ├── eip-1132.md ├── eip-1153.md ├── eip-1154.md ├── eip-1155.md ├── eip-1167.md ├── eip-1175.md ├── eip-1178.md ├── eip-1185.md ├── eip-1186.md ├── eip-1191.md ├── eip-1193.md ├── eip-1202.md ├── eip-1203.md ├── eip-1207.md ├── eip-1227.md ├── eip-1234.md ├── eip-1240.md ├── eip-1261.md ├── eip-1271.md ├── eip-1276.md ├── eip-1283.md ├── eip-1285.md ├── eip-1295.md ├── eip-1319.md ├── eip-1328.md ├── eip-1337.md ├── eip-1344.md ├── eip-1352.md ├── eip-1355.md ├── eip-1363.md ├── eip-137.md ├── eip-1380.md ├── eip-1386.md ├── eip-1387.md ├── eip-1388.md ├── eip-140.md ├── eip-141.md ├── eip-1417.md ├── eip-1418.md ├── eip-1438.md ├── eip-1444.md ├── eip-145.md ├── eip-1450.md ├── eip-1459.md ├── eip-1462.md ├── eip-1470.md ├── eip-1474.md ├── eip-1482.md ├── eip-1484.md ├── eip-1485.md ├── eip-1491.md ├── eip-150.md ├── eip-1504.md ├── eip-152.md ├── eip-1523.md ├── eip-1538.md ├── eip-155.md ├── eip-1559.md ├── eip-1571.md ├── eip-1577.md ├── eip-158.md ├── eip-1581.md ├── eip-1588.md ├── eip-1592.md ├── eip-160.md ├── eip-161.md ├── eip-1613.md ├── eip-1616.md ├── eip-162.md ├── eip-1620.md ├── eip-1633.md ├── eip-165.md ├── eip-1679.md ├── eip-1681.md ├── eip-1682.md ├── eip-170.md ├── eip-1702.md ├── eip-1706.md ├── eip-1710.md ├── eip-1716.md ├── eip-173.md ├── eip-1753.md ├── eip-1761.md ├── eip-1767.md ├── eip-1775.md ├── eip-1803.md ├── eip-181.md ├── eip-1812.md ├── eip-1820.md ├── eip-1822.md ├── eip-1829.md ├── eip-1844.md ├── eip-1872.md ├── eip-1884.md ├── eip-1890.md ├── eip-1895.md ├── eip-1898.md ├── eip-190.md ├── eip-1900.md ├── eip-1901.md ├── eip-191.md ├── eip-1921.md ├── eip-1922.md ├── eip-1923.md ├── eip-1930.md ├── eip-1948.md ├── eip-1959.md ├── eip-196.md ├── eip-1962.md ├── eip-1965.md ├── eip-1967.md ├── eip-197.md ├── eip-1973.md ├── eip-198.md ├── eip-1985.md ├── eip-1996.md ├── eip-2.md ├── eip-20-token-standard.md ├── eip-20.md ├── eip-2003.md ├── eip-2009.md ├── eip-2014.md ├── eip-2015.md ├── eip-2018.md ├── eip-2019.md ├── eip-2020.md ├── eip-2021.md ├── eip-2025.md ├── eip-2026.md ├── eip-2027.md ├── eip-2028.md ├── eip-2029.md ├── eip-2031.md ├── eip-2035.md ├── eip-2045.md ├── eip-2046.md ├── eip-205.md ├── eip-2069.md ├── eip-2070.md ├── eip-2098.md ├── eip-210.md ├── eip-211.md ├── eip-2124.md ├── eip-2135.md ├── eip-214.md ├── eip-2157.md ├── eip-2159.md ├── eip-2193.md ├── eip-2200.md ├── eip-2228.md ├── eip-2242.md ├── eip-225.md ├── eip-2255.md ├── eip-2256.md ├── eip-2266.md ├── eip-2304.md ├── eip-2309.md ├── eip-2315.md ├── eip-2327.md ├── eip-233.md ├── eip-2330.md ├── eip-2333.md ├── eip-2334.md ├── eip-2335.md ├── eip-234.md ├── eip-2364.md ├── eip-2378.md ├── eip-2384.md ├── eip-2386.md ├── eip-2387.md ├── eip-2390.md ├── eip-2400.md ├── eip-2458.md ├── eip-2464.md ├── eip-2470.md ├── eip-2474.md ├── eip-2477.md ├── eip-2481.md ├── eip-2488.md ├── eip-2494.md ├── eip-2515.md ├── eip-2520.md ├── eip-2525.md ├── eip-2535.md ├── eip-2537.md ├── eip-2539.md ├── eip-2542.md ├── eip-2544.md ├── eip-2565.md ├── eip-2566.md ├── eip-2569.md ├── eip-2583.md ├── eip-2584.md ├── eip-2593.md ├── eip-2612.md ├── eip-2615.md ├── eip-2645.md ├── eip-2657.md ├── eip-2666.md ├── eip-2677.md ├── eip-2678.md ├── eip-2680.md ├── eip-2681.md ├── eip-2696.md ├── eip-2700.md ├── eip-2711.md ├── eip-2718.md ├── eip-2733.md ├── eip-2746.md ├── eip-2767.md ├── eip-2770.md ├── eip-2771.md ├── eip-2780.md ├── eip-2786.md ├── eip-2803.md ├── eip-2831.md ├── eip-2844.md ├── eip-2848.md ├── eip-2876.md ├── eip-2917.md ├── eip-2926.md ├── eip-2929.md ├── eip-2930.md ├── eip-2935.md ├── eip-2936.md ├── eip-2937.md ├── eip-2938.md ├── eip-2942.md ├── eip-2970.md ├── eip-2972.md ├── eip-2976.md ├── eip-2980.md ├── eip-2981.md ├── eip-2982.md ├── eip-2997.md ├── eip-3.md ├── eip-3000.md ├── eip-3005.md ├── eip-3009.md ├── eip-3014.md ├── eip-3026.md ├── eip-3030.md ├── eip-3041.md ├── eip-3044.md ├── eip-3045.md ├── eip-3046.md ├── eip-3068.md ├── eip-3074.md ├── eip-3076.md ├── eip-3085.md ├── eip-3091.md ├── eip-3102.md ├── eip-3135.md ├── eip-3143.md ├── eip-3155.md ├── eip-3156.md ├── eip-3198.md ├── eip-3220.md ├── eip-3224.md ├── eip-3234.md ├── eip-3238.md ├── eip-3267.md ├── eip-3298.md ├── eip-3300.md ├── eip-3322.md ├── eip-3326.md ├── eip-3332.md ├── eip-3336.md ├── eip-3337.md ├── eip-3338.md ├── eip-3368.md ├── eip-3372.md ├── eip-3374.md ├── eip-3382.md ├── eip-3386.md ├── eip-3403.md ├── eip-3416.md ├── eip-3436.md ├── eip-3440.md ├── eip-3448.md ├── eip-3450.md ├── eip-3475.md ├── eip-3508.md ├── eip-3520.md ├── eip-3521.md ├── eip-3525.md ├── eip-3529.md ├── eip-3534.md ├── eip-3540.md ├── eip-3541.md ├── eip-3554.md ├── eip-3561.md ├── eip-3569.md ├── eip-3584.md ├── eip-3589.md ├── eip-3607.md ├── eip-3643.md ├── eip-3651.md ├── eip-3668.md ├── eip-3670.md ├── eip-3675.md ├── eip-3690.md ├── eip-3709.md ├── eip-3722.md ├── eip-3754.md ├── eip-3756.md ├── eip-3770.md ├── eip-3772.md ├── eip-3779.md ├── eip-3788.md ├── eip-3855.md ├── eip-3860.md ├── eip-3978.md ├── eip-4.md ├── eip-4200.md ├── eip-4337.md ├── eip-4341.md ├── eip-4345.md ├── eip-4361.md ├── eip-4393.md ├── eip-4396.md ├── eip-4399.md ├── eip-4400.md ├── eip-4444.md ├── eip-4488.md ├── eip-4494.md ├── eip-4520.md ├── eip-4521.md ├── eip-4524.md ├── eip-4546.md ├── eip-4573.md ├── eip-4626.md ├── eip-5.md ├── eip-55.md ├── eip-6.md ├── eip-600.md ├── eip-601.md ├── eip-606.md ├── eip-607.md ├── eip-608.md ├── eip-609.md ├── eip-615.md ├── eip-616.md ├── eip-627.md ├── eip-634.md ├── eip-649.md ├── eip-658.md ├── eip-663.md ├── eip-665.md ├── eip-681.md ├── eip-689.md ├── eip-695.md ├── eip-698.md ├── eip-7.md ├── eip-706.md ├── eip-712.md ├── eip-721.md ├── eip-725.md ├── eip-747.md ├── eip-758.md ├── eip-777.md ├── eip-778.md ├── eip-779.md ├── eip-8.md ├── eip-801.md ├── eip-820.md ├── eip-823.md ├── eip-831.md ├── eip-858.md ├── eip-86.md ├── eip-867.md ├── eip-868.md ├── eip-875.md ├── eip-884.md ├── eip-897.md ├── eip-900.md ├── eip-902.md ├── eip-908.md ├── eip-918.md ├── eip-926.md ├── eip-927.md ├── eip-969.md ├── eip-998.md └── eip-999.md ├── Gemfile ├── Gemfile.lock ├── ISSUE_TEMPLATE.md ├── PULL_REQUEST_TEMPLATE.md ├── README.md ├── _config.yml ├── _data └── statuses.yaml ├── _includes ├── anchor_headings.html ├── authorlist.html ├── eipnums.html ├── eiptable.html ├── head.html ├── social.html └── toc.html ├── _layouts └── eip.html ├── all.html ├── assets ├── css │ └── style.scss ├── eip-1 │ ├── EIP-process-update.jpg │ ├── EIP-process.png │ └── process.png ├── eip-1057 │ ├── test-vectors-0.9.2.json │ ├── test-vectors-0.9.3.json │ └── test-vectors.md ├── eip-107 │ ├── authorization-locked.png │ ├── authorization-password.png │ └── authorization.png ├── eip-1175 │ ├── wallet.png │ └── workflow.png ├── eip-1207 │ └── rationale.png ├── eip-1283 │ └── state.png ├── eip-1438 │ ├── avatar.png │ ├── intro.png │ └── wallet.png ├── eip-1613 │ └── sequence.png ├── eip-1822 │ └── proxy-diagram.png ├── eip-1884 │ ├── BALANCE-run3.png │ ├── SLOAD-run3.png │ ├── geth_processing.png │ ├── run3.total-bars-5.png │ └── run3.total-bars-6.png ├── eip-1901 │ ├── OpenRPC_structure.png │ ├── eth-generated-client-openrpc.gif │ ├── eth-playground-openrpc.gif │ ├── inspector-mock-server-openrpc.png │ └── multi-geth-use-case.png ├── eip-2025 │ ├── block_rewards_distribution.png │ └── loan_state.png ├── eip-2255 │ ├── facebook_permissions.png │ ├── log_in_with_apple.jpeg │ ├── permissions.png │ └── permissions_adventure.gif ├── eip-2266 │ └── Example.sol ├── eip-2535 │ ├── DiamondDiagram.png │ ├── diamond.svg │ ├── diamondstorage1.png │ └── facetreuse.png ├── eip-2537 │ ├── bench_vectors.md │ └── field_to_curve.md ├── eip-2565 │ ├── Complexity_Regression.png │ └── GQuad_Change.png ├── eip-2615 │ ├── concept.png │ ├── mortgage-sequential.jpg │ └── rental-sequential.jpg ├── eip-2678 │ └── package.spec.json ├── eip-2680 │ └── sha256-384-512.pdf ├── eip-2771 │ └── example-flow.png ├── eip-2848 │ └── presentation.pdf ├── eip-2917 │ └── erc-reward-formula.png ├── eip-2980 │ ├── Finma-ICO-Guidelines.pdf │ ├── Swiss-Confederation-AMLA.pdf │ ├── Swiss-Confederation-BA.pdf │ ├── Swiss-Confederation-CISA.pdf │ ├── Swiss-Confederation-FINIA.pdf │ ├── Swiss-Confederation-FINSA.pdf │ ├── Swiss-Confederation-FMIA.pdf │ └── Swiss-Confederation-SESTA.pdf ├── eip-3005 │ └── meta-txs-directly-to-token-smart-contract.png ├── eip-3068 │ ├── 2012-685_Square_Root_Even_Ext.pdf │ ├── 2015-1027_exTNFS.pdf │ ├── 2016-1102_Assessing_NFS_Advances.pdf │ ├── 2017-334.pdf │ ├── 2019-403_BLS12_H2C.pdf │ ├── latincrypt12.pdf │ ├── madnet.pdf │ └── weilsigs.pdf ├── eip-3074 │ ├── auth-msg-multi-call.png │ └── auth-msg.png ├── eip-3102 │ └── sibling.svg ├── eip-3267 │ ├── contracts │ │ ├── BaseBidOnAddresses.sol │ │ ├── BaseLock.sol │ │ ├── BaseRestorableSalary.sol │ │ ├── BaseSalary.sol │ │ ├── BidOnAddresses.sol │ │ ├── DAOInterface.sol │ │ ├── DefaultDAOInterface.sol │ │ ├── ERC1155 │ │ │ ├── ERC1155.sol │ │ │ ├── ERC1155TokenReceiver.sol │ │ │ ├── ERC1155WithTotals.sol │ │ │ ├── IERC1155.sol │ │ │ ├── IERC1155TokenReceiver.sol │ │ │ └── README.md │ │ ├── README.md │ │ ├── Salary.sol │ │ └── SalaryWithDAO.sol │ └── science-salaries.pdf ├── eip-3448 │ ├── MetaProxyFactory.sol │ └── MetaProxyTest.sol ├── eip-3450 │ ├── lagrange.gif │ └── wordlist.txt ├── eip-3607 │ └── geth.diff ├── eip-3770 │ └── EIP-3770-examples.png ├── eip-4337 │ ├── image1.png │ └── image2.png ├── eip-4396 │ ├── degradation.png │ ├── degradation_buffers.png │ ├── degradation_elasticity.png │ ├── new_formula.png │ └── old_formula.png ├── eip-4488 │ └── gas_and_calldata_sample.csv ├── eip-712 │ ├── Example.js │ ├── Example.sol │ ├── eth_sign.png │ └── eth_signTypedData.png ├── eip-747 │ ├── add-token-prompt.gif │ └── add-token-prompt2.gif ├── eip-777 │ └── logo │ │ ├── png │ │ ├── ERC-777-logo-beige-1024px.png │ │ ├── ERC-777-logo-beige-192px.png │ │ ├── ERC-777-logo-beige-2048px.png │ │ ├── ERC-777-logo-beige-48px.png │ │ ├── ERC-777-logo-beige-600px.png │ │ ├── ERC-777-logo-black-1024px.png │ │ ├── ERC-777-logo-black-192px.png │ │ ├── ERC-777-logo-black-2048px.png │ │ ├── ERC-777-logo-black-48px.png │ │ ├── ERC-777-logo-black-600px.png │ │ ├── ERC-777-logo-dark_grey-1024px.png │ │ ├── ERC-777-logo-dark_grey-192px.png │ │ ├── ERC-777-logo-dark_grey-2048px.png │ │ ├── ERC-777-logo-dark_grey-48px.png │ │ ├── ERC-777-logo-dark_grey-600px.png │ │ ├── ERC-777-logo-light_grey-1024px.png │ │ ├── ERC-777-logo-light_grey-192px.png │ │ ├── ERC-777-logo-light_grey-2048px.png │ │ ├── ERC-777-logo-light_grey-48px.png │ │ ├── ERC-777-logo-light_grey-600px.png │ │ ├── ERC-777-logo-white-1024px.png │ │ ├── ERC-777-logo-white-192px.png │ │ ├── ERC-777-logo-white-2048px.png │ │ ├── ERC-777-logo-white-48px.png │ │ └── ERC-777-logo-white-600px.png │ │ └── svg │ │ ├── ERC-777-logo-beige.svg │ │ ├── ERC-777-logo-black.svg │ │ ├── ERC-777-logo-dark_grey.svg │ │ ├── ERC-777-logo-light_grey.svg │ │ └── ERC-777-logo-white.svg ├── eip-823 │ ├── eip-823-token-exchange-standard-visual-representation-1.png │ └── eip-823-token-exchange-standard-visual-representation-2.png └── eip-858 │ └── calculations.md ├── core.html ├── eip-template.md ├── erc.html ├── index.html ├── informational.html ├── interface.html ├── last-call.xml ├── meta.html └── networking.html /.codespell-whitelist: -------------------------------------------------------------------------------- 1 | uint 2 | ith 3 | nd 4 | mitre 5 | readded 6 | crate 7 | developper 8 | ist 9 | iam 10 | espace 11 | acn 12 | ende 13 | sting 14 | -------------------------------------------------------------------------------- /.gitattributes: -------------------------------------------------------------------------------- 1 | # GitHub highlighting for Solidity files 2 | # See https://github.com/github/linguist/pull/3973#issuecomment-357507741 3 | *.sol linguist-language=Solidity 4 | -------------------------------------------------------------------------------- /.github/workflows/auto-merge-bot.yml: -------------------------------------------------------------------------------- 1 | on: [pull_request_target] 2 | name: Auto-Merge Bot 3 | jobs: 4 | auto_merge_bot: 5 | runs-on: ubuntu-latest 6 | name: EIP Auto-Merge Bot 7 | if: github.event.pull_request.draft == false && github.repository == 'ethereum/eips' 8 | steps: 9 | - name: Checkout 10 | uses: actions/checkout@v2 11 | - name: Setup Node.js Environment 12 | uses: actions/setup-node@v2 13 | with: 14 | node-version: '14' 15 | - name: auto-merge-bot 16 | uses: ethereum/EIP-Bot@de16cffd4324ee1596aaf9623b00c50ecaa84076 # master 17 | id: auto-merge-bot 18 | with: 19 | GITHUB-TOKEN: ${{ secrets.TOKEN }} 20 | MERGE_ENABLED: false 21 | CORE_EDITORS: "@MicahZoltu,@lightclient,@axic,@gcolvin" 22 | ERC_EDITORS: "@lightclient,@axic" 23 | NETWORKING_EDITORS: "@MicahZoltu,@lightclient,@axic" 24 | INTERFACE_EDITORS: "@lightclient,@axic" 25 | META_EDITORS: "@lightclient,@axic,@gcolvin" 26 | INFORMATIONAL_EDITORS: "@lightclient,@axic,@gcolvin" 27 | enable-auto-merge: 28 | if: github.repository == 'ethereum/eips' 29 | runs-on: ubuntu-latest 30 | needs: ["auto_merge_bot"] 31 | steps: 32 | - uses: alexwilson/enable-github-automerge-action@1.0.0 33 | with: 34 | github-token: ${{ secrets.TOKEN }} 35 | -------------------------------------------------------------------------------- /.github/workflows/auto-stagnate-bot.yml: -------------------------------------------------------------------------------- 1 | on: 2 | schedule: 3 | # A job that runs every sunday at 00:00 4 | - cron: '0 0 * * 0' 5 | 6 | name: Auto Stagnant Bot 7 | jobs: 8 | auto_merge_bot: 9 | if: github.repository == 'ethereum/eips' 10 | runs-on: ubuntu-latest 11 | name: Auto Stagnant Bot 12 | steps: 13 | - name: Checkout 14 | uses: actions/checkout@v2 15 | - name: Setup Node.js Environment 16 | uses: actions/setup-node@v2 17 | with: 18 | node-version: '14' 19 | - name: auto-stagnant-bot 20 | uses: ethereum/EIP-Bot@b3ac0ba3600aea27157fc68d1e36c08cc5a6db77 # mark-eips-stale 21 | id: auto-stagnant-bot 22 | with: 23 | GITHUB-TOKEN: ${{ secrets.TOKEN }} 24 | -------------------------------------------------------------------------------- /.github/workflows/greetings.yml: -------------------------------------------------------------------------------- 1 | name: Greetings 2 | 3 | on: [pull_request, issues] 4 | 5 | jobs: 6 | greeting: 7 | if: github.repository == 'ethereum/eips' 8 | runs-on: ubuntu-latest 9 | steps: 10 | - uses: actions/first-interaction@v1 11 | with: 12 | repo-token: ${{ secrets.GITHUB_TOKEN }} 13 | issue-message: | 14 | Since this is your first issue, we kindly remind you to check out [EIP-1](https://eips.ethereum.org/EIPS/eip-1) for guidance. 15 | 16 | If 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/). 17 | pr-message: | 18 | 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. 19 | 20 | If 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/). 21 | -------------------------------------------------------------------------------- /.github/workflows/manual-bot-rerun.yml: -------------------------------------------------------------------------------- 1 | name: Manual Bot Rerun 2 | on: 3 | workflow_dispatch: 4 | inputs: 5 | pullRequestNumber: 6 | description: "PR number (with the run you'd like to re-run)" 7 | required: true 8 | eventType: 9 | description: "event type (of the run you want to re-run)" 10 | required: true 11 | default: "pull_request_target" 12 | idOfBotWorkflow: 13 | description: "id of the bot workflow (just leave as default if you don't know)" 14 | required: true 15 | default: "6519716" 16 | 17 | jobs: 18 | rerun-bot: 19 | if: github.repository == 'ethereum/eips' 20 | runs-on: ubuntu-latest 21 | name: Manual Bot Rerun 22 | steps: 23 | - name: Checkout 24 | uses: actions/checkout@v2 25 | - name: Setup Node.js Environment 26 | uses: actions/setup-node@v2 27 | with: 28 | node-version: '14' 29 | - name: rerun-workflow 30 | uses: ethereum/EIP-Bot@90d0591e71314dc1430c6cde91bb787e185e0b4b # manual-bot-rerun 31 | id: rerun-workflow 32 | with: 33 | GITHUB-TOKEN: ${{ secrets.TOKEN }} 34 | PULL-NUMBER: ${{github.event.inputs.pullRequestNumber }} 35 | ID-TO-RERUN: ${{ github.event.inputs.idOfBotWorkflow }} 36 | EVENT-TYPE: ${{ github.event.inputs.eventType }} 37 | -------------------------------------------------------------------------------- /.github/workflows/rerun-bot-pull-request-review.yml: -------------------------------------------------------------------------------- 1 | on: 2 | pull_request_review: 3 | types: [submitted] 4 | name: Rerun Bot 5 | jobs: 6 | rerun_bot_on_review: 7 | if: github.repository == 'ethereum/eips' 8 | runs-on: ubuntu-latest 9 | name: Trigger Bot Rerun workflow_run 10 | steps: 11 | - name: Explanation 12 | run: echo "this bot is used to trigger another workflow using the workflow_run github event; this is necessary because without it forked PRs do not have access to repo secret; normally this is circumvented using the pull_request_target event but because github actions.. a hack is required to allow the same behavior on pull_request_review; this work-around will no longer be necessary if github ever implements a pull_request_review_target or something similar" -------------------------------------------------------------------------------- /.github/workflows/rerun-bot-workflow-run.yml: -------------------------------------------------------------------------------- 1 | name: Workflow run re-run auto-merge-bot on review 2 | on: 3 | workflow_run: 4 | workflows: 5 | - Rerun Bot 6 | types: 7 | - requested 8 | 9 | jobs: 10 | rerun-bot: 11 | if: github.repository == 'ethereum/eips' 12 | runs-on: ubuntu-latest 13 | name: Rerun Bot (workflow_run) 14 | steps: 15 | - name: Checkout 16 | uses: actions/checkout@v2 17 | - name: Setup Node.js Environment 18 | uses: actions/setup-node@v2 19 | with: 20 | node-version: '14' 21 | - name: auto-merge-bot 22 | uses: ethereum/EIP-Bot@1f05ace5691062379bd910aa27402eecb8f295ac # rerun-pull-request-target-on-review 23 | id: rerun-auto-merge-bot 24 | with: 25 | GITHUB-TOKEN: ${{ secrets.TOKEN }} 26 | WORKFLOW-ID: ${{github.event.workflow_run.id}} 27 | ID-TO-RERUN: "6519716" 28 | RUN-EVENT-TYPE: "pull_request_target" 29 | -------------------------------------------------------------------------------- /.github/workflows/stale.yml: -------------------------------------------------------------------------------- 1 | name: "Mark stale PRs & Issues" 2 | 3 | on: 4 | schedule: 5 | # Run this every hour, so we are not spammed with changes at once. Later we could consider changing this to once a day. 6 | - cron: "0 * * * *" 7 | 8 | jobs: 9 | stale-pr: 10 | if: github.repository == 'ethereum/eips' 11 | runs-on: ubuntu-latest 12 | name: "Mark stale PRs" 13 | steps: 14 | - uses: actions/stale@v3 15 | with: 16 | repo-token: ${{ secrets.GITHUB_TOKEN }} 17 | days-before-stale: 60 18 | days-before-close: 7 19 | stale-pr-label: 'stale' 20 | 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.' 21 | 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.' 22 | stale-issue: 23 | if: github.repository == 'ethereum/eips' 24 | runs-on: ubuntu-latest 25 | name: "Mark stale issues" 26 | steps: 27 | - uses: actions/stale@v3 28 | with: 29 | repo-token: ${{ secrets.GITHUB_TOKEN }} 30 | days-before-stale: 180 31 | days-before-close: 14 32 | exempt-issue-labels: 'discussions-to' 33 | stale-issue-label: 'stale' 34 | 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.' 35 | 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.' 36 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | _site 2 | .sass-cache 3 | .jekyll-metadata 4 | vendor 5 | -------------------------------------------------------------------------------- /.travis-ci.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | set -e # halt script on error 3 | 4 | HTMLPROOFER_OPTIONS="./_site --internal-domains=eips.ethereum.org --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --url-ignore=/EIPS/eip-1,EIPS/eip-1,/EIPS/eip-107,/EIPS/eip-858" 5 | 6 | if [[ $TASK = 'htmlproofer' ]]; then 7 | bundle exec jekyll doctor 8 | bundle exec jekyll build 9 | bundle exec htmlproofer $HTMLPROOFER_OPTIONS --disable-external 10 | 11 | # Validate GH Pages DNS setup 12 | bundle exec github-pages health-check 13 | elif [[ $TASK = 'htmlproofer-external' ]]; then 14 | bundle exec jekyll doctor 15 | bundle exec jekyll build 16 | bundle exec htmlproofer $HTMLPROOFER_OPTIONS --external_only 17 | elif [[ $TASK = 'eip-validator' ]]; then 18 | if [[ $(find . -maxdepth 1 -name 'eip-*' | wc -l) -ne 1 ]]; then 19 | echo "only 'eip-template.md' should be in the root" 20 | exit 1 21 | fi 22 | eipv EIPS/ --ignore=title_max_length,missing_discussions_to --skip=eip-20-token-standard.md 23 | elif [[ $TASK = 'codespell' ]]; then 24 | codespell -q4 -I .codespell-whitelist -S ".git,Gemfile.lock,**/*.png,**/*.gif,**/*.jpg,**/*.svg,.codespell-whitelist,vendor,_site,_config.yml,style.css" 25 | fi 26 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | sudo: false 2 | 3 | language: ruby 4 | 5 | before_install: 6 | - gem install bundler -v '< 2' 7 | 8 | cache: 9 | # Cache Ruby bundles 10 | - bundler 11 | - directories: 12 | - $TRAVIS_BUILD_DIR/tmp/.htmlproofer #https://github.com/gjtorikian/html-proofer/issues/381 13 | - /usr/local/lib/python3.3/dist-packages/pip/ 14 | 15 | # Assume bundler is being used, therefore 16 | # the `install` step will run `bundle install` by default. 17 | script: "bash -ex .travis-ci.sh" 18 | 19 | env: 20 | global: 21 | - NOKOGIRI_USE_SYSTEM_LIBRARIES=true # speeds up installation of html-proofer 22 | 23 | matrix: 24 | fast_finish: true 25 | include: 26 | - rvm: 2.6.0 27 | env: TASK='htmlproofer' 28 | - rvm: 2.6.0 29 | env: TASK='htmlproofer-external' 30 | - language: rust 31 | cache: cargo 32 | before_script: 33 | - cargo install eipv --version=0.4.0 34 | env: TASK='eip-validator' 35 | - python: 3.3 36 | env: TASK='codespell' 37 | before_script: "sudo pip install urllib3[secure] && sudo pip install codespell" 38 | allow_failures: 39 | - rvm: 2.6.0 40 | env: TASK='htmlproofer-external' 41 | 42 | addons: 43 | apt: 44 | packages: 45 | "libcurl4-openssl-dev" # https://github.com/gjtorikian/html-proofer/issues/376#issuecomment-332767999 46 | -------------------------------------------------------------------------------- /404.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 | 18 | 19 |
20 |

404

21 | 22 |

Page not found :(

23 |

The requested page could not be found.

24 |
25 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | eips.ethereum.org -------------------------------------------------------------------------------- /EIPS/eip-100.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 100 3 | title: Change difficulty adjustment to target mean block time including uncles 4 | author: Vitalik Buterin (@vbuterin) 5 | type: Standards Track 6 | category: Core 7 | status: Final 8 | created: 2016-04-28 9 | --- 10 | 11 | ### Specification 12 | 13 | Currently, the formula to compute the difficulty of a block includes the following logic: 14 | 15 | ``` python 16 | adj_factor = max(1 - ((timestamp - parent.timestamp) // 10), -99) 17 | child_diff = int(max(parent.difficulty + (parent.difficulty // BLOCK_DIFF_FACTOR) * adj_factor, min(parent.difficulty, MIN_DIFF))) 18 | ... 19 | ``` 20 | 21 | If `block.number >= BYZANTIUM_FORK_BLKNUM`, we change the first line to the following: 22 | 23 | ``` python 24 | adj_factor = max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99) 25 | ``` 26 | ### Rationale 27 | 28 | This new formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. A formula that accounts for the exact number of included uncles: 29 | ``` python 30 | adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99) 31 | ``` 32 | can be fairly easily seen to be (to within a tolerance of ~3/4194304) mathematically equivalent to assuming that a block with `k` uncles is equivalent to a sequence of `k+1` blocks that all appear with the exact same timestamp, and this is likely the simplest possible way to accomplish the desired effect. But since the exact formula depends on the full block and not just the header, we are instead using an approximate formula that accomplishes almost the same effect but has the benefit that it depends only on the block header (as you can check the uncle hash against the blank hash). 33 | 34 | Changing the denominator from 10 to 9 ensures that the block time remains roughly the same (in fact, it should decrease by ~3% given the current uncle rate of 7%). 35 | 36 | ### References 37 | 38 | 1. EIP 100 issue and discussion: https://github.com/ethereum/EIPs/issues/100 39 | 2. https://bitslog.wordpress.com/2016/04/28/uncle-mining-an-ethereum-consensus-protocol-flaw/ 40 | -------------------------------------------------------------------------------- /EIPS/eip-1013.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1013 3 | title: "Hardfork Meta: Constantinople" 4 | author: Nick Savers (@nicksavers) 5 | type: Meta 6 | status: Final 7 | created: 2018-04-20 8 | requires: 145, 609, 1014, 1052, 1234, 1283 9 | --- 10 | 11 | ## Abstract 12 | 13 | This meta-EIP specifies the changes included in the Ethereum hardfork named Constantinople. 14 | 15 | ## Specification 16 | 17 | - Codename: Constantinople 18 | - Aliases: Metropolis/Constantinople, Metropolis part 2 19 | - Activation: 20 | - `Block >= 7_280_000` on the Ethereum mainnet 21 | - `Block >= 4,230,000` on the Ropsten testnet 22 | - `Block >= 9_200_000` on the Kovan testnet 23 | - `Block >= 3_660_663` on the Rinkeby testnet 24 | - Included EIPs: 25 | - [EIP-145](./eip-145.md): Bitwise shifting instructions in EVM 26 | - [EIP-1014](./eip-1014.md): Skinny CREATE2 27 | - [EIP-1052](./eip-1052.md): EXTCODEHASH Opcode 28 | - [EIP-1234](./eip-1234.md): Delay difficulty bomb, adjust block reward 29 | - [EIP-1283](./eip-1283.md): Net gas metering for SSTORE without dirty maps 30 | 31 | ## References 32 | 33 | 1. The list above includes the EIPs discussed as candidates for Constantinople at the All Core Dev [Constantinople Session #1](https://github.com/ethereum/pm/issues/55). See also [Constantinople Progress Tracker](https://github.com/ethereum/pm/wiki/Constantinople-Progress-Tracker). 34 | 2. https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/ 35 | 36 | ## Copyright 37 | 38 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 39 | -------------------------------------------------------------------------------- /EIPS/eip-1240.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1240 3 | title: Remove Difficulty Bomb 4 | author: Micah Zoltu (@MicahZoltu) 5 | discussions-to: https://ethereum-magicians.org/t/difficulty-bomb-removal/832 6 | type: Standards Track 7 | category: Core 8 | status: Withdrawn 9 | created: 2018-07-21 10 | --- 11 | 12 | ## Simple Summary 13 | The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to remove the difficulty increase over time and replace it with a fixed difficulty targeting 15 second blocks. 14 | 15 | ## Abstract 16 | Starting with `FORK_BLOCK_NUMBER` the client will calculate the difficulty without considering the current block number. 17 | 18 | ## Motivation 19 | The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. Another way to put this is that miners will follow economic participants, not the other way around. 20 | 21 | ## Specification 22 | #### Remove Difficulty 23 | For the purposes of `calc_difficulty`, if `block.number >= FORK_BLOCK_NUMBER` then change the epsilon component to `0` rather than having it be a function of block number. 24 | 25 | ## Rationale 26 | With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not. If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today. This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users. 27 | 28 | Author Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults. 29 | 30 | ## Backwards Compatibility 31 | This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number. 32 | 33 | ## Test Cases 34 | Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. 35 | 36 | ## Implementations 37 | The yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710 38 | 39 | ## Copyright 40 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 41 | -------------------------------------------------------------------------------- /EIPS/eip-1328.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1328 3 | title: WalletConnect Standard URI Format 4 | author: ligi , Pedro Gomes 5 | type: Standards Track 6 | category: ERC 7 | status: Stagnant 8 | created: 2018-08-15 9 | discussions-to: https://ethereum-magicians.org/t/wallet-connect-eip/850 10 | --- 11 | 12 | ## Simple Summary 13 | 14 | A standard to create WalletConnect URIs to initiate connections between applications and wallets. 15 | 16 | ## Abstract 17 | 18 | This standard defines how the data to connect some application and a wallet can be encoded with a URI. This URI can then be shown either as a QR code or for mobile to mobile as a link. 19 | 20 | ## Specification 21 | 22 | ### Syntax 23 | 24 | WalletConnect request URI with the following parameters: 25 | 26 | request = "wc" ":" topic [ "@" version ][ "?" parameters ] 27 | topic = STRING 28 | version = 1*DIGIT 29 | parameters = parameter *( "&" parameter ) 30 | parameter = key "=" value 31 | key = "bridge" / "key" 32 | value = STRING 33 | 34 | ### Semantics 35 | 36 | Required parameters are dependent on the Walletconnect protocol version which currently includes the `key`, hex string of symmetric key, and `bridge`, encoded url of the bridge used for establishing the connection. 37 | 38 | ### Example 39 | 40 | ``` 41 | wc:8a5e5bdc-a0e4-4702-ba63-8f1a5655744f@1?bridge=https%3A%2F%2Fbridge.walletconnect.org&key=41791102999c339c844880b23950704cc43aa840f3739e365323cda4dfa89e7a 42 | ``` 43 | 44 | ## Rationale 45 | 46 | The need for this ERC stems from the discussion to move away from JSON format used in the alpha version of the WalletConnect protocol which makes for very inneficient parsing of the intent of the QR code, making it easier to create better QR code parsers APIs for Wallets to implement. Also by using a URI instead of a JSON inside the QR-Code the Android Intent system can be leveraged. 47 | 48 | ## References 49 | 50 | 1. WalletConnect Technical Specification, https://docs.walletconnect.org/tech-spec 51 | 52 | ## Copyright 53 | 54 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 55 | -------------------------------------------------------------------------------- /EIPS/eip-1352.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1352 3 | title: Specify restricted address range for precompiles/system contracts 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-1352-specify-restricted-address-range-for-precompiles-system-contracts/1151 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2018-07-27 10 | --- 11 | 12 | ## Simple Summary 13 | Specify an Ethereum address range occupied by precompiles and future system contracts. Regular accounts and contracts cannot obtain such an address. 14 | 15 | ## Abstract 16 | The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts. 17 | 18 | ## Motivation 19 | This will simplify certain future features where unless this is implemented, several exceptions must be specified. 20 | 21 | ## Specification 22 | The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts. 23 | 24 | Due to the extremely low probability (and lack of adequate testing possibilities) no explicit checks should be added to ensure that external transaction signing or 25 | the invoking of the `CREATE` instruction can result in a precompile address. 26 | 27 | ## Rationale 28 | N/A 29 | 30 | ## Backwards Compatibility 31 | No contracts on the main network have been created at the specified addresses. As a result it should pose no backwards compatibility problems. 32 | 33 | ## Test Cases 34 | N/A 35 | 36 | ## Implementation 37 | N/A 38 | 39 | ## Copyright 40 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 41 | -------------------------------------------------------------------------------- /EIPS/eip-1355.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1355 3 | title: Ethash 1a 4 | author: Paweł Bylica (@chfast), Jean M. Cyr (@jean-m-cyr) 5 | discussions-to: https://ethereum-magicians.org/t/eip-1355-ethash-1a/1167 6 | status: Withdrawn 7 | type: Standards Track 8 | category: Core 9 | created: 2018-08-26 10 | --- 11 | 12 | ## Motivation 13 | 14 | Provide minimal set of changes to Ethash algorithm to hinder and delay the adoption of ASIC based mining. 15 | 16 | ## Specification 17 | 18 | 1. Define hash function `fnv1a()` as 19 | ```python 20 | def fnv1a(v1, v2): 21 | return ((v1 ^ v2) * FNV1A_PRIME) % 2**32 22 | ``` 23 | where `FNV1A_PRIME` is 16777499 or 16777639. 24 | 2. Change the hash function that determines the DAG item index in Ethash algorithm from `fnv()` to new `fnv1a()`. 25 | In [Main Loop](https://github.com/ethereum/wiki/wiki/Ethash#main-loop) change 26 | ```python 27 | p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes 28 | ``` 29 | to 30 | ```python 31 | p = fnv1a(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes 32 | ``` 33 | 34 | ## Rationale 35 | 36 | The usual argument for decentralization and network security. 37 | 38 | Unless programmable, an ASIC is hardwired to perform sequential operations in a given order. fnv1a changes the order in which an exclusive-or and a multiply are applied, effectively disabling the current wave of ASICS. A second objective is minimize ethash changes to be the least disruptive, to facilitate rapid development, and to lower the analysis and test requirements. Minimizing changes to ethash reduces risk associated with updating all affected network components, and also reduces the risk of detuning existing GPUs. It's expected that this specific change would have no effect on existing GPU performance. 39 | 40 | Changing fnv to fnv1a has no cryptographic implications. It is merely an efficient hash function with good dispersion characteristics used to scramble DAG indexing. We remain focused on risk mitigation by reducing the need for rigorous cryptographic analysis. 41 | 42 | 43 | ### FNV Primes 44 | 45 | The 16777639 satisfies all requirements from [Wikipedia](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function#FNV_prime). 46 | 47 | The 16777499 is preferred by FNV authors but not used in the reference FNV implementation because of historical reasons. 48 | See [A few remarks on FNV primes](http://www.isthe.com/chongo/tech/comp/fnv/index.html#fnv-prime). 49 | 50 | ## Copyright 51 | 52 | This work is licensed under a [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License](https://creativecommons.org/licenses/by-nc-sa/4.0/). 53 | -------------------------------------------------------------------------------- /EIPS/eip-1387.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1387 3 | title: Merkle Tree Attestations with Privacy enabled 4 | author: Weiwu Zhang , James Sangalli 5 | discussions-to: https://github.com/ethereum/EIPs/issues/1387 6 | status: Stagnant 7 | type: Standards Track 8 | category: ERC 9 | created: 2018-09-08 10 | --- 11 | 12 | ### Introduction 13 | 14 | It's often needed that an Ethereum smart contract must verify a claim (I live in Australia) attested by a valid attester. 15 | 16 | For example, an ICO contract might require that the participant, Alice, lives in Australia before she participates. Alice's claim of residency could come from a local Justice of the Peace who could attest that "Alice is a resident of Australia in NSW". 17 | 18 | Unlike previous attempts, we assume that the attestation is signed and issued off the blockchain in a Merkle Tree format. Only a part of the Merkle tree is revealed by Alice at each use. Therefore we avoid the privacy problem often associated with issuing attestations on chain. We also assume that Alice has multiple signed Merkle Trees for the same factual claim to avoid her transactions being linkable. 19 | 20 | ## Purpose 21 | This ERC provides an interface and reference implementation for smart contracts that need users to provide an attestation and validate it. 22 | 23 | ### Draft implementation 24 | ```solidity 25 | contract MerkleTreeAttestationInterface { 26 | struct Attestation 27 | { 28 | bytes32[] merklePath; 29 | bool valid; 30 | uint8 v; 31 | bytes32 r; 32 | bytes32 s; 33 | address attester; 34 | address recipient; 35 | bytes32 salt; 36 | bytes32 key; 37 | bytes32 val; 38 | } 39 | 40 | function validate(Attestation attestation) public returns(bool); 41 | } 42 | 43 | ``` 44 | ### Relevant implementation examples 45 | [Here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/lib/MerkleTreeAttestation.sol) is an example implementation of the MerkleTreeAttestationInterface 46 | [Here](https://github.com/alpha-wallet/blockchain-attestation/blob/master/ethereum/example-james-squire/james-squire.sol) is an example service which would use such a merkle tree attestation 47 | 48 | ### Related ERC's 49 | #1388 #1386 50 | -------------------------------------------------------------------------------- /EIPS/eip-141.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 141 3 | title: Designated invalid EVM instruction 4 | author: Alex Beregszaszi (@axic) 5 | type: Standards Track 6 | category: Core 7 | status: Final 8 | created: 2017-02-09 9 | --- 10 | 11 | ## Abstract 12 | 13 | An instruction is designated to remain as an invalid instruction. 14 | 15 | ## Motivation 16 | 17 | The invalid instruction can be used as a distinct reason to abort execution. 18 | 19 | ## Specification 20 | 21 | The opcode `0xfe` is the `INVALID` instruction. It can be used to abort the execution (i.e. duplicates as an `ABORT` instruction). 22 | 23 | ## Backwards Compatibility 24 | 25 | This instruction was never used and therefore has no effect on past contracts. 26 | 27 | ## Copyright 28 | 29 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 30 | -------------------------------------------------------------------------------- /EIPS/eip-1482.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1482 3 | title: Define a maximum block timestamp drift 4 | author: Maurelian (@Maurelian) 5 | discussions-to: https://ethereum-magicians.org/t/define-a-maximum-block-timestamp-drift/1556 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2018-10-09 10 | --- 11 | 12 | ## Simple Summary 13 | 14 | Include an explicit definition of the acceptable timestamp drift in the protocol specification. 15 | 16 | ## Abstract 17 | 18 | On the basis that both Geth and Parity implement the same timestamp validation requirements, this should be written into the reference specification. 19 | 20 | ## Motivation 21 | 22 | There is a lack of clarity about how accurate timestamps in the block header must be. The yellow paper describes the timestamp as 23 | 24 | > A scalar value equal to the reasonable output of Unix’s time() at this block’s inception 25 | 26 | This causes [confusion](https://ethereum.stackexchange.com/questions/5924/how-do-ethereum-mining-nodes-maintain-a-time-consistent-with-the-network/5926#5926) about the safe use of the `TIMESTAMP` opcode (solidity's `block.timestamp` or `now`) in smart contract development. 27 | 28 | Differing interpretations of 'reasonable' may create a risk of consenus failures. 29 | 30 | 31 | ## Specification 32 | 33 | The yellow paper should define a timestamp as: 34 | 35 | > A scalar value equal to the output of Unix’s time() at this block’s inception. For the purpose of block validation, it must be greater than the previous block's timestamp, and no more than 15 seconds greater than system time. 36 | 37 | 38 | ## Rationale 39 | 40 | Both [Geth](https://github.com/ethereum/go-ethereum/blob/4e474c74dc2ac1d26b339c32064d0bac98775e77/consensus/ethash/consensus.go#L45) and [Parity](https://github.com/paritytech/parity-ethereum/blob/73db5dda8c0109bb6bc1392624875078f973be14/ethcore/src/verification/verification.rs#L296-L307) reject blocks with timestamp more than 15 seconds in the future. This establishes a defacto standard, which should be made explicit in the reference specification. 41 | 42 | 43 | ## Backwards Compatibility 44 | 45 | It may be necessary to relax this requirement for blocks which were mined early in the main chain's history, if they would be considered invalid. 46 | 47 | ## Test Cases 48 | 49 | These would be important to have. 50 | 51 | 52 | 53 | 54 | ## Implementation 55 | _The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. 56 | _ 57 | ## Copyright 58 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 59 | -------------------------------------------------------------------------------- /EIPS/eip-1588.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1588 3 | title: "Hardfork Meta: Ethereum ProgPoW" 4 | author: Ikmyeong Na (@naikmyeong) 5 | status: Stagnant 6 | type: Meta 7 | created: 2018-11-16 8 | requires: 1057 9 | --- 10 | 11 | ## Abstract 12 | 13 | This meta-EIP specifies the changes included in the alternative Ethereum hardfork named Ethereum ProgPoW. 14 | 15 | ## Specification 16 | 17 | - Codename: Ethereum ProgPoW 18 | - Aliases: N/A 19 | - Activation: 20 | - `Block >= 7280000` on the Ethereum mainnet 21 | - Included EIPs: 22 | - [EIP-1057](./eip-1057.md): ProgPoW, a Programmatic Proof-of-Work 23 | 24 | ## Copyright 25 | 26 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 27 | -------------------------------------------------------------------------------- /EIPS/eip-160.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 160 3 | title: EXP cost increase 4 | author: Vitalik Buterin (@vbuterin) 5 | type: Standards Track 6 | category: Core 7 | status: Final 8 | created: 2016-10-20 9 | --- 10 | 11 | ### Hard fork 12 | [Spurious Dragon](./eip-607.md) 13 | 14 | ### Parameters 15 | - `FORK_BLKNUM`: 2,675,000 16 | - `CHAIN_ID`: 1 17 | 18 | ### Specification 19 | 20 | If `block.number >= FORK_BLKNUM`, increase the gas cost of EXP from 10 + 10 per byte in the exponent to 10 + 50 per byte in the exponent. 21 | 22 | ### Rationale 23 | 24 | Benchmarks suggest that EXP is currently underpriced by a factor of about 4–8. 25 | 26 | ### References 27 | 28 | 1. EIP-160 issue and discussion: https://github.com/ethereum/EIPs/issues/160 29 | -------------------------------------------------------------------------------- /EIPS/eip-1679.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1679 3 | title: "Hardfork Meta: Istanbul" 4 | author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn) 5 | discussions-to: https://ethereum-magicians.org/t/hardfork-meta-istanbul-discussion/3207 6 | type: Meta 7 | status: Final 8 | created: 2019-01-04 9 | requires: 152, 1108, 1344, 1716, 1884, 2028, 2200 10 | --- 11 | 12 | ## Abstract 13 | 14 | This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul. 15 | 16 | ## Specification 17 | 18 | - Codename: Istanbul 19 | 20 | ### Activation 21 | - `Block >= 9,069,000` on the Ethereum Mainnet 22 | - `Block >= 6,485,846` on the Ropsten testnet 23 | - `Block >= 14,111,141` on the Kovan testnet 24 | - `Block >= 5,435,345` on the Rinkeby testnet 25 | - `Block >= 1,561,651` on the Görli testnet 26 | 27 | ### Included EIPs 28 | - [EIP-152](./eip-152.md): Add Blake2 compression function `F` precompile 29 | - [EIP-1108](./eip-1108.md): Reduce alt_bn128 precompile gas costs 30 | - [EIP-1344](./eip-1344.md): Add ChainID opcode 31 | - [EIP-1884](./eip-1884.md): Repricing for trie-size-dependent opcodes 32 | - [EIP-2028](./eip-2028.md): Calldata gas cost reduction 33 | - [EIP-2200](./eip-2200.md): Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change 34 | 35 | ## References 36 | 37 | 1. Included EIPs were finalized in [All Core Devs Call #68](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2068.md) 38 | 2. https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df 39 | 40 | ## Copyright 41 | 42 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 43 | -------------------------------------------------------------------------------- /EIPS/eip-170.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 170 3 | title: Contract code size limit 4 | author: Vitalik Buterin (@vbuterin) 5 | type: Standards Track 6 | category: Core 7 | status: Final 8 | created: 2016-11-04 9 | --- 10 | 11 | ### Hard fork 12 | [Spurious Dragon](./eip-607.md) 13 | 14 | ### Parameters 15 | - `MAX_CODE_SIZE`: `0x6000` (`2**14 + 2**13`) 16 | - `FORK_BLKNUM`: 2,675,000 17 | - `CHAIN_ID`: 1 (Mainnet) 18 | 19 | ### Specification 20 | 21 | If `block.number >= FORK_BLKNUM`, then if contract creation initialization returns data with length of **more than** `MAX_CODE_SIZE` bytes, contract creation fails with an out of gas error. 22 | 23 | ### Rationale 24 | 25 | Currently, there remains one slight quadratic vulnerability in Ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern—not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits. 26 | 27 | ### References 28 | 29 | 1. EIP-170 issue and discussion: https://github.com/ethereum/EIPs/issues/170 30 | 2. pyethereum implementation: https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397 31 | -------------------------------------------------------------------------------- /EIPS/eip-1710.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1710 3 | title: URL Format for Web3 Browsers 4 | author: Bruno Barbieri (@brunobar79) 5 | discussions-to: https://ethereum-magicians.org/t/standarize-url-format-for-web3-browsers/2422 6 | status: Stagnant 7 | type: Standards Track 8 | category: ERC 9 | created: 2019-01-13 10 | requires: 155 11 | --- 12 | 13 | ## Simple Summary 14 | 15 | A standard way of representing web3 browser URLs for decentralized applications. 16 | 17 | ## Abstract 18 | 19 | Since most normal web browsers (specifically on mobile devices) can not run decentralized applications correctly because of the lack of web3 support, it is necessary to differentiate them from normal urls, so they can be opened in web3 browsers if available. 20 | 21 | ## Motivation 22 | 23 | Lots of dApps that are trying to improve their mobile experience are currently (deep)linking to specific mobile web3 browsers which are currently using their own url scheme. 24 | 25 | In order to make the experience more seamless, dApps should still be able to recommend a specific mobile web3 browser via [deferred deeplinking](https://en.wikipedia.org/wiki/Deferred_deep_linking) but by having a standard url format, if the user already has a web3 browser installed that implements this standard, it will be automatically linked to it. 26 | 27 | There is also a compatibility problem with the current `ethereum:` url scheme described in [EIP-831](./eip-831.md) where any ethereum related app (wallets, identity management, etc) already registered it and because of iOS unpredictable behavior for multiple apps handling a single url scheme, users can end up opening an `ethereum:` link in an app that doesn not include a web3 browser and will not be able to handle the deeplink correctly. 28 | 29 | ## Specification 30 | 31 | ### Syntax 32 | 33 | Web3 browser URLs contain "dapp" in their schema (protocol) part and are constructed as follows: 34 | 35 | request = "dapp" ":" [chain_id "@"] dapp_url 36 | chain_id = 1*DIGIT 37 | dapp_url = URI 38 | 39 | ### Semantics 40 | 41 | `chain_id` is optional and it is a parameter for the browser to automatically select the corresponding chain ID as specified in [EIP-155](./eip-155.md) before opening the dApp. 42 | 43 | `dapp_url` is a valid [RFC3986](https://www.ietf.org/rfc/rfc3986.txt) URI 44 | 45 | This a complete example url: 46 | 47 | `dapp:1@peepeth.com/brunobar79?utm_source=github` 48 | 49 | which will open the web3 browser, select `mainnet` (chain_id = 1) and then navigate to: 50 | 51 | `https://peepeth.com/brunobar79?utm_source=github` 52 | 53 | ## Rationale 54 | 55 | The proposed format attempts to solve the problem of vendor specific protocols for web3 browsers, avoiding conflicts with the existing 'ethereum:' URL scheme while also adding an extra feature: `chain_id` which will help dApps to be accessed with the right network preselected, optionally extracting away that complexity from end users. 56 | 57 | ## Copyright 58 | 59 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 60 | -------------------------------------------------------------------------------- /EIPS/eip-1716.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1716 3 | title: "Hardfork Meta: Petersburg" 4 | author: Afri Schoedon (@5chdn), Marius van der Wijden (@MariusVanDerWijden) 5 | type: Meta 6 | status: Final 7 | created: 2019-01-21 8 | requires: 1013, 1283 9 | --- 10 | 11 | ## Abstract 12 | 13 | This meta-EIP specifies the changes included in the Ethereum hardfork that removes [EIP-1283](./eip-1283.md) from [Constantinople](./eip-1013.md). 14 | 15 | ## Specification 16 | 17 | - Codename: Petersburg 18 | - Aliases: St. Petersfork, Peter's Fork, Constantinople Fix 19 | - Activation: 20 | - `Block >= 7_280_000` on the Ethereum Mainnet 21 | - `Block >= 4_939_394` on the Ropsten testnet 22 | - `Block >= 10_255_201` on the Kovan testnet 23 | - `Block >= 4_321_234` on the Rinkeby testnet 24 | - `Block >= 0` on the Görli testnet 25 | - Removed EIPs: 26 | - [EIP-1283](./eip-1283.md): Net gas metering for SSTORE without dirty maps 27 | 28 | If `Petersburg` and `Constantinople` are applied at the same block, `Petersburg` takes precedence: with the net effect of EIP-1283 being _disabled_. 29 | 30 | If `Petersburg` is defined with an earlier block number than `Constantinople`, then there is _no immediate effect_ from the `Petersburg` fork. However, when `Constantinople` is later activated, EIP-1283 should be _disabled_. 31 | 32 | ## References 33 | 34 | 1. The list above includes the EIPs that had to be removed from Constantinople due to a [potential reentrancy attack vector](https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9). Removing this was agreed upon at the [All-Core-Devs call #53 in January 2019](https://github.com/ethereum/pm/issues/70). 35 | 2. https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/ 36 | 37 | ## Copyright 38 | 39 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 40 | -------------------------------------------------------------------------------- /EIPS/eip-1803.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1803 3 | title: Rename opcodes for clarity 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-1803-rename-opcodes-for-clarity/3345 6 | type: Standards Track 7 | category: Interface 8 | status: Stagnant 9 | created: 2017-07-28 10 | requires: 141 11 | --- 12 | 13 | ## Abstract 14 | 15 | Rename the `BALANCE`, `SHA3`, `NUMBER`, `GASLIMIT`, `GAS` and `INVALID` opcodes to reflect their true meaning. 16 | 17 | ## Specification 18 | 19 | Rename the opcodes as follows: 20 | - `BALANCE` (`0x31`) to `EXTBALANCE` to be in line with `EXTCODESIZE`, `EXTCODECOPY` and `EXTCODEHASH` 21 | - `SHA3` (`0x20`) to `KECCAK256` 22 | - `NUMBER` (`0x43`) to `BLOCKNUMBER` 23 | - `GASLIMIT` (`0x45`) to `BLOCKGASLIMIT` to avoid confusion with the gas limit of the transaction 24 | - `GAS` (`0x5a`) to `GASLEFT` to be clear what it refers to 25 | - `INVALID` (`0xfe`) to `ABORT` to clearly articulate when someone refers this opcode as opposed to "any invalid opcode" 26 | 27 | ## Backwards Compatibility 28 | 29 | This has no effect on any code. It can influence what mnemonics assemblers will use. 30 | 31 | ## Implementation 32 | 33 | Not applicable. 34 | 35 | ## References 36 | 37 | [EIP-6](./eip-6.md) previously renamed `SUICIDE` (`0xff`) to `SELFDESTRUCT`. 38 | Renaming `SHA3` was previously proposed by [EIP-59](https://github.com/ethereum/EIPs/issues/59). 39 | 40 | ## Copyright 41 | 42 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 43 | -------------------------------------------------------------------------------- /EIPS/eip-1890.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1890 3 | title: Commitment to Sustainable Ecosystem Funding 4 | author: Gregory Markou , Kevin Owocki , Lane Rettig 5 | discussions-to: https://t.me/joinchat/DwEd_xahL5hHvzNYH2RnQA 6 | status: Withdrawn 7 | type: Standards Track 8 | category: Core 9 | created: 2019-03-31 10 | --- 11 | 12 | # Commitment to Sustainable Ecosystem Funding 13 | 14 | ## Simple Summary 15 | 16 | Ethereum currently provides a block reward to proof of work miners every block, but it does not capture any block rewards for ecosystem funding. This EIP adds a simple mechanism for capturing a portion of block rewards for ecosystem funding as a credible commitment to doing so in future, but it does not actually capture any such rewards. 17 | 18 | ## Abstract 19 | 20 | A mechanism that allows specification of two parameters, a beneficiary address and a per-block reward denominated in wei, that allows a portion of block rewards to be captured for the purpose of ecosystem funding. Both values are set to zero. 21 | 22 | ## Motivation 23 | 24 | In order for Ethereum to succeed, it needs talented, motivated researchers and developers to continue to develop and maintain the platform. Those talented researchers and developers deserve to be paid fairly for their work. At present there is no mechanism in the Ethereum ecosystem that rewards R&D teams fairly for their work on the platform. 25 | 26 | We recognize that, while technically trivial, the real challenge in inflation-based funding is social: how to fairly capture, govern, and distribute block rewards. It will take time to work out the answer to these questions. For this reason, this EIP only seeks to make a credible commitment on the part of core developers to securing the funding they need to keep Ethereum alive and healthy by adding a mechanism to do so, but the actual amount of rewards captured remains at zero, i.e., there is no change at present to Ethereum’s economics. Raising the amount captured above zero would require a future EIP. 27 | 28 | ## Specification 29 | 30 | Two new constants are introduced: BENEFICIARY_ADDRESS, an Address, and DEVFUND_BLOCK_REWARD, an amount denominated in wei. Both are set to zero. 31 | 32 | Beginning with block ISTANBUL_BLOCK_HEIGHT, DEVFUND_BLOCK_REWARD wei is added to the balance of BENEFICIARY_ADDRESS at each block. 33 | 34 | We may optionally add another constant, DECAY_FACTOR, which specifies a linear or exponenential decay factor that reduces the reward at every block > ISTANBUL_BLOCK_HEIGHT until it decays to zero. For simplicity, it has been omitted from this proposal. 35 | 36 | ## Rationale 37 | 38 | We believe that the technical design of this EIP is straightforward. The social rationale is explained in [this article](https://medium.com/gitcoin/funding-open-source-in-the-blockchain-era-8ded753bf05f). 39 | 40 | ## Backwards Compatibility 41 | 42 | This EIP has no impact on backwards compatibility. 43 | 44 | ## Test Cases 45 | 46 | This EIP makes no changes to existing state transitions. Existing consensus tests should be sufficient. 47 | 48 | ## Implementation 49 | 50 | Reference implementations are included for the Trinity, go-ethereum, and parity clients. 51 | 52 | ## Copyright 53 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 54 | -------------------------------------------------------------------------------- /EIPS/eip-20-token-standard.md: -------------------------------------------------------------------------------- 1 | Moved to [EIP-20](./eip-20.md). 2 | -------------------------------------------------------------------------------- /EIPS/eip-2046.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2046 3 | title: Reduced gas cost for static calls made to precompiles 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2046-reduced-gas-cost-for-static-calls-made-to-precompiles/3291 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2019-05-17 10 | requires: 214, 1352 11 | --- 12 | 13 | ## Simple Summary 14 | 15 | This change reduces the gas cost of using precompiled contracts. 16 | 17 | ## Abstract 18 | 19 | Reduce the base gas cost of calling precompiles using `STATICCALL` from 700 to 40. This should allow more efficient use of precompiles as well as precompiles with a total cost below 700. 20 | 21 | ## Motivation 22 | 23 | The Spurious Dragon hard fork increased the cost of calls significantly to account for loading contract code from the state without making an exception for precompiles, whose "code" is always loaded. 24 | 25 | This made use of certain precompiles impractical. 26 | 27 | FIXME: extend this with recent reasoning about ECC repricings. 28 | 29 | ## Specification 30 | 31 | After block `HF` the `STATICCALL` (`0xfa`) instruction charges different basic gas cost (Gcall in [Yellow Paper]'s notation) depending on the destination address provided: 32 | - for precompiles (address range as per [EIP-1352]) the cost is `40` 33 | - for every other address the cost remains unchanged (`700`) 34 | 35 | ## Rationale 36 | 37 | Only the `STATICCALL` instruction was changed to reduce the impact of the change. This should not be a limiting factor, given precompiles (currently) do not have a state and cannot change the state. 38 | However, contracts created and deployed before Byzantium likely will not use `STATICCALL` and as a result this change will not reduce their costs. 39 | 40 | Contrary to EIP-1109 gas reduction to `0` is not proposed. The cost `40` is kept as a cost representing the context switching needed. 41 | 42 | ## Backwards Compatibility 43 | 44 | This EIP should be backwards compatible. The only effect is that the cost is reduced. Since the cost is not reduced to zero, it should not be possible for a malicious proxy contract, when deployed before 45 | the `HF`, to do any state changing operation. 46 | 47 | ## Test Cases 48 | 49 | TBA 50 | 51 | ## Implementation 52 | 53 | TBA 54 | 55 | ## References 56 | 57 | This has been previously suggested as part of [EIP-1109](./eip-1109.md) and [EIP-1231](https://github.com/ethereum/EIPs/pull/1231). 58 | However EIP-1109 was later changed to a very different approach. The author [has suggested to change EIP-1109](https://ethereum-magicians.org/t/eip-1109-remove-call-costs-for-precompiled-contracts/447/7). 59 | 60 | ## Acknowledgements 61 | 62 | Jordi Baylina (@jbaylina) and Matthew Di Ferrante (@mattdf) who have proposed this before. 63 | 64 | ## Copyright 65 | 66 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 67 | 68 | [Yellow Paper]: https://github.com/ethereum/yellowpaper 69 | [EIP-1352]: ./eip-1352.md 70 | -------------------------------------------------------------------------------- /EIPS/eip-2070.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2070 3 | title: "Hardfork Meta: Berlin" 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/hardfork-meta-eip-2070-berlin-discussion/3561 6 | type: Meta 7 | status: Stagnant 8 | created: 2019-05-20 9 | requires: 1679 10 | --- 11 | 12 | ## Abstract 13 | 14 | This meta-EIP specifies the changes included in the Ethereum hardfork named Berlin. 15 | 16 | ## Specification 17 | 18 | - Codename: Berlin 19 | 20 | In the current stage of coordination, the changes are tracked and discussed in the [eth1.0-specs](https://github.com/ethereum/eth1.0-specs) repository. 21 | For an accurate status please refer to the [`berlin.md`](https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md) file. 22 | 23 | ## Copyright 24 | 25 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 26 | -------------------------------------------------------------------------------- /EIPS/eip-2384.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2384 3 | title: Muir Glacier Difficulty Bomb Delay 4 | author: Eric Conner (@econoar) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2384-difficulty-bomb-delay 6 | type: Standards Track 7 | category: Core 8 | status: Final 9 | created: 2019-11-20 10 | --- 11 | 12 | ## Simple Summary 13 | The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") and slowly accelerating. This EIP proposes to delay the difficulty bomb for another 4,000,000 blocks (~611 days). 14 | 15 | ## Abstract 16 | Starting with `MUIR_GLACIER_FORK_BLKNUM` the client will calculate the difficulty based on a fake block number suggesting to the client that the difficulty bomb is adjusting 9 million blocks later than the Homestead fork, which is also 7 million blocks later than the Byzantium fork and 4 million blocks later than the Constantinople fork. 17 | 18 | ## Motivation 19 | The difficulty bomb started to become noticeable again on October 5th 2019 at block 8,600,000. Block times have been around 13.1s on average and now as of block 8,900,000 are around 14.3s. This will start to accelerate exponentially every 100,000 blocks. Estimating the added impact from the difficulty bomb on block times shows that we will see 20s block times near the end of December 2019 and 30s+ block times starting February 2020. This will start making the chain bloated and more costly to use. It's best to delay the difficulty bomb again to around the time of expected launch of the Eth2 finality gadget. 20 | 21 | ## Specification 22 | #### Relax Difficulty with Fake Block Number 23 | For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: 24 | 25 | fake_block_number = max(0, block.number - 9_000_000) if block.number >= MUIR_GLACIER_FORK_BLKNUM else block.number 26 | 27 | ## Rationale 28 | This will delay the ice age by 52 million seconds (approximately 611 days), so the chain would be back at 20 second block times around July 2021. It's important to note this pushes the ice age 4,000,000 blocks from ~block 8,800,000 NOT from when this EIP is activated in a fork. 29 | 30 | ## Backwards Compatibility 31 | This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP shortly after the Istanbul fork. 32 | 33 | ## Test Cases 34 | Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. 35 | 36 | ## Implementation 37 | The implementation in it's logic does not differ from [EIP-649](./eip-649.md) or [EIP-1234](./eip-1234.md); an implementation for Parity-Ethereum is available in [parity-ethereum#9187](https://github.com/paritytech/parity-ethereum/pull/9187). 38 | 39 | ## Copyright 40 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 41 | -------------------------------------------------------------------------------- /EIPS/eip-2474.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2474 3 | title: Coinbase calls 4 | author: Ricardo Guilherme Schmidt (@3esmit) 5 | discussions-to: https://ethresear.ch/t/gas-abstraction-non-signed-block-validator-only-procedures/4388/2 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2020-01-19 10 | --- 11 | 12 | ## Simple Summary 13 | 14 | Allow contracts to be called directly by `block.coinbase` (block validator), without a transaction. 15 | 16 | ## Abstract 17 | 18 | _In proof-of-work blockchains, validators are known as miners._ 19 | 20 | The validator might want to execute functions directly, without having to sign a transaction. Some examples might be presenting a proof in a contract for an change which also benefits the validator. 21 | 22 | A notable example would be when a validator want to act as an [EIP-1077](./eip-1077.md) Gas Relayer, incentivized to pick up fees from meta transactions. 23 | Without this change, they can do so by signing from any address a `gasPrice = 0` transaction with the gas relayed call. 24 | However this brings an overhead of a signed transaction by validator that does nothing, as `msg.sender` is never used, and there is no gas cost to EVM charge. 25 | 26 | This proposal makes possible to remove this unused ecrecover. 27 | 28 | ## Motivation 29 | 30 | In order to reduce the overhead of calls that don't use `msg.sender` and are being called by validator with `tx.gasPrice = 0`. 31 | 32 | ## Specification 33 | 34 | The calls to be executed by `block.coinbase` would be included first at block, and would consume normally the gas of block, however they won't pay/cost gas, instead the call logic would pay the validator in other form. 35 | 36 | Would be valid to execute any calls without a transaction by the block coinbase, except when the validator call tries to read `msg.sender`, which would throw an invalid jump. 37 | 38 | Calls included by the validator would have `tx.origin = block.coinbase` and `gas.price = 0` for the rest of call stack, the rest follows as normal calls. 39 | 40 | ## Rationale 41 | 42 | TBD 43 | 44 | ## Backwards Compatibility 45 | 46 | `tx.origin = block.coinbase` could cause some issues on bad designed contracts, such as using `tx.origin` to validate a signature, an analysis on how contracts use tx.origin might be useful to decide if this is a good choice. 47 | 48 | ## Test Cases 49 | 50 | TBD 51 | 52 | ## Implementation 53 | 54 | TBD 55 | 56 | ## Security Considerations 57 | 58 | TBD 59 | 60 | ## Copyright 61 | 62 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 63 | -------------------------------------------------------------------------------- /EIPS/eip-2488.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2488 3 | title: Deprecate the CALLCODE opcode 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2488-deprecate-the-callcode-opcode/3957 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2019-12-20 10 | requires: 7 11 | --- 12 | 13 | ## Abstract 14 | 15 | Deprecate `CALLCODE` in a *somewhat* backwards compatible way, by making it always return failure. 16 | 17 | ## Motivation 18 | 19 | `CALLCODE` was part of the Frontier release of Ethereum. In the first few weeks/months it became clear 20 | that it cannot accomplish its intended design goal. This was rectified with introducing `DELEGATECALL` 21 | ([EIP-7](./eip-7.md)) in the Homestead update (early 2016). 22 | 23 | `CALLCODE` became never utilized, but it still puts a burden on EVM implementations. 24 | 25 | Disabling it will not improve the situation for any client whose goal is to sync from genesis, but would 26 | help light clients or clients planning to sync from a later point in time. 27 | 28 | ## Specification 29 | 30 | If `block.number >= FORK_BLOCK`, the `CALLCODE` (`0xf2`) instruction always returns `0`, which signals failure. 31 | 32 | ## Rationale 33 | 34 | It would be possible just to remove the opcode and exceptionally abort if it is encountered. 35 | However, by returning failure, the contract has a chance to act on it and potentially recover. 36 | 37 | ## Backwards Compatibility 38 | 39 | This is a breaking change and has a potential to break contracts. The author expects no contracts of any value 40 | should be affected. 41 | 42 | TODO: validate this claim. 43 | 44 | ## Security Considerations 45 | 46 | TBA 47 | 48 | ## Test Cases 49 | 50 | TBA 51 | 52 | ## Implementation 53 | 54 | TBA 55 | 56 | ## Copyright 57 | 58 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 59 | -------------------------------------------------------------------------------- /EIPS/eip-2657.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2657 3 | title: Ephemeral Testnet Yolo 4 | author: James Hancock (@madeoftin) 5 | discussions-to: https://gitter.im/ethereum/AllCoreDevs 6 | status: Stagnant 7 | type: Meta 8 | created: 2020-04-19 9 | --- 10 | 11 | **Disclaimer: This is for testing basic infrastructure. It will be nuked. It is not for deploying dapps, nor does it define what will go into mainnet. For information on network upgrades, please follow the relevant meta EIPs and ongoing discussion on Ethereum/pm.** 12 | 13 | ## Abstract 14 | 15 | The specification for Ephemeral Testnet Yolo. Clients who wish to sync need to implement the following features into their client. It is for testing basic infrastructure and will be nuked. 16 | 17 | ## Specification 18 | 19 | Name: Yolo 20 | ID: `YOLO-v1` 21 | 22 | - [x] EIP 2537 Commit Hash - [5edff4ae6ff62c7e0bbfad624fc3d0ba7dc84392](https://github.com/ethereum/EIPs/commit/5edff4ae6ff62c7e0bbfad624fc3d0ba7dc84392) 23 | - [x] EIP 2315 Commit Hash - [e8accf22cdc5562d6982c560080c6cd6b7f94867](https://github.com/ethereum/EIPs/commit/e8accf22cdc5562d6982c560080c6cd6b7f94867) 24 | 25 | *[ ] Proposed - [x] Consensus to include.* 26 | ## Timeline 27 | 28 | - Deployed: June 3rd 2020 29 | 30 | ## Client Consensus -> Implementation 31 | 32 | YOLO-v1 33 | | **Client** | Signal | Spec | Merged | Syncing | 34 | |--------------|--------|------|--------|---------| 35 | | Besu | x | x | | | 36 | | EthereumJS | x | | | | 37 | | Geth | x | x | x | x | 38 | | Nethermind | x | x | | | 39 | | OpenEthereum | x | x | | | 40 | | Trinity | | | | | 41 | 42 | **Signal** - 43 | Client intends to participate. *(You are on the bus)* 44 | 45 | **Spec** - 46 | Client is satisfied with the proposed specification. *(You agree with the direction)* 47 | 48 | **Merge** - 49 | Changes are implemented in the client and configurable for YOLO. *(You are ready to hit the gas and go)* 50 | 51 | **Syncing** 52 | Client syncs with the network 53 | 54 | 55 | ## Syncing Instructions 56 | 57 | **Geth** 58 | - Yolo V1 testnet is up and running https://yolonet.xyz/ 59 | - Support is baked into Geth master branch via --yolov1 60 | - Genesis config json is at https://yolonet.xyz/yolo.json 61 | - EF bootnode at enode://9e1096aa59862a6f164994cb5cb16f5124d6c992cdbf4535ff7dea43ea1512afe5448dca9df1b7ab0726129603f1a3336b631e4d7a1a44c94daddd03241587f9@35.178.210.161:30303 62 | - Stats page secret is YOLOv1, with geth you can --ethstats='yournode:YOLOv1@stats.yolonet.xyz' 63 | - Faucet is unauthenticated, you can reach it from the dashboard 64 | 65 | ## Copyright 66 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 67 | -------------------------------------------------------------------------------- /EIPS/eip-2681.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2681 3 | title: Limit account nonce to 2^64-1 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2681-limit-account-nonce-to-2-64-1/4324 6 | status: Final 7 | type: Standards Track 8 | category: Core 9 | created: 2020-04-25 10 | --- 11 | 12 | ## Abstract 13 | 14 | Limit account nonce to be between `0` and `2^64-1`. 15 | 16 | ## Motivation 17 | 18 | Account nonces are currently specified to be arbitrarily long unsigned integers. Dealing with arbitrary length data in the state witnesses is not optimal, therefore this EIP will allow proofs to represent the nonce in a more optimized way. 19 | 20 | Additionally it could prove beneficial to transaction formats, where some improvements are potentially sought by at least three other proposals. 21 | 22 | Lastly, this facilitates a minor optimisation in clients, because the nonce no longer needs to be kept as a 256-bit number. 23 | 24 | ## Specification 25 | 26 | Introduce two new restrictions retroactively from genesis: 27 | 28 | 1. Consider any transaction invalid, where the nonce exceeds or equals to `2^64-1`. 29 | 2. The `CREATE` and `CREATE2` instructions to abort with an exceptional halt, where the account nonce is `2^64-1`. 30 | 31 | ## Rationale 32 | 33 | 1. It is unlikely for any nonce to reach or exceed the proposed limit. If one would want to reach that limit via external transactions, it would cost at least `21000 * (2^64-1) = 387_381_625_547_900_583_915_000` gas. 34 | 35 | 2. It must be noted that in the past, in the Morden testnet, each new account had a starting nonce of `2^20` in order to differentiate transactions from mainnet transactions. 36 | This mode of replay protection is out of fashion since [EIP-155](./eip-155.md) introduced a more elegant way using chain identifiers. 37 | 38 | 3. Most clients already consider the nonce field to be 64-bit, such as go-ethereum. 39 | 40 | 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`. 41 | 42 | ## Backwards Compatibility 43 | 44 | While this is a breaking change, no actual effect should be visible: 45 | 46 | 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. 47 | 48 | 2. go-ethereum already has this restriction partially in place (`state.Account.Nonce` and `types.txdata.AccountNonce` it as a 64-bit number). 49 | 50 | ## Security Considerations 51 | 52 | None. 53 | 54 | ## Copyright 55 | 56 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 57 | -------------------------------------------------------------------------------- /EIPS/eip-2786.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2786 3 | title: Ethereum Provider Connect/Disconnect Events 4 | author: Micah Zoltu (@MicahZoltu), Erik Marks (@rekmarks) 5 | discussions-to: https://github.com/ethereum/EIPs/issues/2787 6 | status: Withdrawn 7 | type: Standards Track 8 | category: Interface 9 | created: 2020-07-15 10 | requires: 2700 11 | --- 12 | 13 | ## Simple Summary 14 | 15 | When an Ethereum Provider becomes connected or disconnected, it will emit a `connect`/`disconnect` event. 16 | 17 | ## Abstract 18 | 19 | The Provider is said to be “connected” when it can service RPC requests to at least one chain. 20 | The Provider is said to be “disconnected” when it cannot service RPC requests to any chain at all. 21 | When the Provider switches from a "connected" state to a "disconnected" state, it will emit a `connect` event. 22 | When the Provider switches from a "disconnected" state to a "connected" state, it will emit a `disconnect` event. 23 | 24 | ## Motivation 25 | 26 | When an application is hooked up to an Ethereum provider, there is value in having the application be alerted of connect/disconnect events that may occur so the application can appropriately inform the user of the situation. 27 | It is left up to the application to decide whether to listen in on these events, and how to handle them. 28 | 29 | ## Specification 30 | 31 | ### Definitions 32 | 33 | #### Connected 34 | 35 | The Provider is considered `connected` when it is able to service RPC requests to at least one chain. 36 | 37 | #### Disconnected 38 | 39 | The Provider is considered `disconnected` when it is unable to service RPC requests to any chain. 40 | 41 | ### Events 42 | 43 | #### `connect` 44 | 45 | The Provider **MUST** emit a `connect` event to all attached [EIP-2700](./eip-2700.md) listeners if it transitions from a `disconnected` state to a `connected` state. 46 | All attached listeners **MUST** be called with the parameter `{ chainId }`. 47 | `chainId` **MUST** specify the integer ID of the connected chain encoded as a hexadecimal string. 48 | If the Provider supports the `eth_chainId` JSON-RPC method or a derivation of it, then the `chainId` **MUST** match the return value of `eth_chainId`. 49 | The Provider **MAY** call the attached listeners in any order. 50 | 51 | ## Rationale 52 | 53 | This EIP is mostly a retrospective EIP meaning it codifies an already existing specification so there isn’t a lot of room for improving things such as by having a connect/disconnect event per chain. 54 | 55 | ## Security Considerations 56 | 57 | The relationship between Ethereum Provider and client is a trusted one, where it is assumed that the user implicitly trusts the Ethereum Provider which is how it managed to get injected into the client, or the client expressly pulled in a connection to it. 58 | 59 | ## Copyright 60 | 61 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 62 | 63 | ## Appendix I: Examples 64 | 65 | ```javascript 66 | // connect 67 | provider.on('connect', ({ chainId }) => { 68 | console.log(`Provider connected to: ${chainId}`); 69 | }); 70 | ``` 71 | -------------------------------------------------------------------------------- /EIPS/eip-2936.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2936 3 | title: EXTCLEAR Opcode For SELFDESTRUCTed contracts 4 | author: William Morriss (@wjmelements) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2936-extclear-for-selfdestruct/4569 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2020-09-03 10 | --- 11 | 12 | ## Simple Summary 13 | Enable new opcode to clear storage for `SELFDESTRUCTED`ed contracts. 14 | 15 | ## Abstract 16 | Changes `SELFDESTRUCT` (`0xff`) to not clear any storage and adds a new `EXTCLEAR` (`0x5c`) opcode that will clear a specific storage slot for a contract that has previously been self destructed. 17 | 18 | ## Motivation 19 | `SELFDESTRUCT` (`0xFF`) is unnecessarily complex because it clears an unbounded amount of contract storage. 20 | It is computationally expensive for nodes to track all of the storage used in every contract in case the contract `SELFDESTRUCT`s. 21 | Further, contracts can be re-initialized using `CREATE2` (`0xF5`), and then `SLOAD` (`0x54`) prior storage. 22 | Therefore, several ethereum clients do not clear storage at all, and just check if the contract was initiated since `SSTORE` (`0x55`) during `SLOAD`. 23 | `CREATE2` was not intended to complicate `SLOAD`, and this change reverts that complexity. 24 | Also, bugs in this implementation could split the network. 25 | 26 | Instead this defers the time of storage cleanup, and leaves the storage in-place, which reduces the complexity of `SLOAD` and `SELFDESTRUCT`. 27 | 28 | This empowers the `CREATE2` reincarnation proxy pattern by retaining storage during upgrade, which would otherwise have to be reset again. 29 | An atomic reincarnation upgrade could clear a subset of storage during the upgrade, while the contract is destroyed, before reinstating it. 30 | 31 | ## Specification 32 | 33 | After `FORK_BLOCK_NUM`, a new opcode, `EXTCLEAR`, is enabled at `0x5C` to clear storage for `SELFDESTRUCT`ed contracts. 34 | `EXTCLEAR`: 35 | * does not push any words onto the stack 36 | * pops two words off the stack: the destroyed contract address and a storage address 37 | * if the contract exists, charge the same gas cost as `EXTCODEHASH` (`0x3F`) 38 | * otherwise, if the storage is zero, charge the same gas as `EXTCODEHASH` plus `SLOAD` 39 | * otherwise, the destroyed contract's slot is reset to 0, charging the same gas as `EXTCODEHASH` and `SSTORE` when resetting storage, while also refunding the amount specified in `SSTORE`. 40 | 41 | `SELFDESTRUCT` is modified to not clear contract storage. 42 | This change also works retroactively: all prior destroyed contracts can be cleaned up. 43 | 44 | ## Rationale 45 | `0x5C` is available in the same range as `SSTORE` and `SLOAD`. 46 | 47 | ## Backwards Compatibility 48 | A reincarnation upgrade mechanism that expects all internal storage to be cleared might break, but such an upgrade mechanism would allow adaptation to this new behavior. 49 | 50 | ## Test Cases 51 | TODO 52 | 53 | ## Implementation 54 | Implementation is required on all major clients to add the opcode. 55 | 56 | ## Security Considerations 57 | A reincarnated contract that does not expect its state to be cleared by malicious actors SHOULD reinitialize itself to avoid antagonistic `EXTCLEAR`. 58 | 59 | ## Copyright 60 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 61 | -------------------------------------------------------------------------------- /EIPS/eip-2937.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2937 3 | title: SET_INDESTRUCTIBLE opcode 4 | author: Vitalik Buterin (@vbuterin) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2937-set-indestructible/4571 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2020-09-04 10 | --- 11 | 12 | ## Simple Summary 13 | 14 | Add a `SET_INDESTRUCTIBLE (0xA8)` opcode that prevents the contract from calling `SELFDESTRUCT (0xFF)`. 15 | 16 | ## Abstract 17 | 18 | ## Motivation 19 | 20 | The intended use case would be for contracts to make their first byte of code be the `SET_INDESTRUCTIBLE` opcode if they wish to serve as libraries that guarantee to users that their code will exist unmodified forever. This is useful in account abstraction as well as other contexts. 21 | 22 | Unlike EIPs that disable the `SELFDESTRUCT` opcode entirely, this EIP does not modify behavior of any existing contracts. 23 | 24 | ## Specification 25 | 26 | Add a transaction-wide global variable `globals.indestructible: Set[Address]` (i.e. a variable that operates the same way as the selfdestructs set), initialized to the empty set. 27 | 28 | Add a `SET_INDESTRUCTIBLE` opcode at `0xA8`, with gas cost `G_base`, that adds the current `callee` to the `globals.indestructible` set. If in the current execution context the `callee` is in `globals.indestructible`, the `SELFDESTRUCT` opcode throws an exception. 29 | 30 | ## Rationale 31 | 32 | Alternative proposals to this include: 33 | 34 | * Simply banning `SELFDESTRUCT` outright. This would be ideal, but has larger backwards compatibility issues. 35 | * Using a local variable instead of a global variable. This is problematic because it would be broken by `DELEGATECALL`. 36 | 37 | ## Backwards Compatibility 38 | 39 | TBD 40 | 41 | ## Security Considerations 42 | 43 | This breaks forward compatibility with _some_ forms of state rent, which would simply delete contracts that get too old without paying some maintenance fee. However, this is not the case with all state size control schemes; for example this is not an issue if we use [ReGenesis](https://ledgerwatch.github.io/regenesis_plan.html). 44 | 45 | If `SELFDESTRUCT` is ever removed in the future, this EIP would simply become a no-op. 46 | 47 | ## Copyright 48 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 49 | -------------------------------------------------------------------------------- /EIPS/eip-2970.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2970 3 | title: IS_STATIC opcode 4 | author: Vitalik Buterin (@vbuterin) 5 | discussions-to: https://ethereum-magicians.org/t/is-static-opcode-useful-for-aa/4609 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2020-09-13 10 | --- 11 | 12 | ## Simple Summary 13 | 14 | Add a `IS_STATIC (0x4A)` opcode that pushes `1` if the current context is static (ie. the execution is in a `STATICCALL` or a descendant thereof, so state-changing operations are not possible), and `0` if it is not. 15 | 16 | ## Abstract 17 | 18 | ## Motivation 19 | 20 | The main intended use case is to allow account abstraction (EIP 2938) to be extended so that accounts can allow static calls from the outside (which are harmless to AA's security model) but not state-changing calls. 21 | 22 | ## Specification 23 | 24 | Add a `IS_STATIC (0x4A)` opcode that pushes `1` if the current context is static (ie. the execution is in a `STATICCALL` or a descendant thereof, so state-changing operations are not possible), and `0` if it is not. 25 | 26 | ## Rationale 27 | 28 | Determining staticness is already possibly using the following hacky technique: make a `CALL` with limited gas, and inside that `CALL` issue one `LOG` and exit. If the context is static, the `CALL` would fail and leave a 0 on the stack; if the context is non-static, the `CALL` would succeed. However, this technique is fragile against changes to gas costs, and is needlessly wasteful. Hence, the status quo neither allows a reasonably effective way of determining whether or not the context is static, nor provides any kind of invariant that executions that do not fail outright will execute the same way in a static and non-static context. This EIP provides a cleaner way of determining staticness. 29 | 30 | ## Backwards Compatibility 31 | 32 | TBD 33 | 34 | ## Security Considerations 35 | 36 | TBD 37 | 38 | ## Copyright 39 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 40 | -------------------------------------------------------------------------------- /EIPS/eip-3.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3 3 | title: Addition of CALLDEPTH opcode 4 | author: Martin Holst Swende 5 | status: Withdrawn 6 | type: Standards Track 7 | category: Core 8 | created: 2015-11-19 9 | --- 10 | 11 | # Abstract 12 | 13 | This is a proposal to add a new opcode, `CALLDEPTH`. The `CALLDEPTH` opcode would return the remaining available call stack depth. 14 | 15 | # Motivation 16 | 17 | There is a limit specifying how deep contracts can call other contracts; the call stack. The limit is currently `256`. If a contract invokes another contract (either via `CALL` or `CALLCODE`), the operation will fail if the call stack depth limit has been reached. 18 | 19 | This behaviour makes it possible to subject a contract to a "call stack attack" [1]. In such an attack, an attacker first creates a suitable depth of the stack, e.g. by recursive calls. After this step, the attacker invokes the targeted contract. If the targeted calls another contract, that call will fail. If the return value is not properly checked to see if the call was successful, the consequences could be damaging. 20 | 21 | Example: 22 | 23 | 1. Contract `A` wants to be invoked regularly, and pays Ether to the invoker in every block. 24 | 2. When contract `A` is invoked, it calls contracts `B` and `C`, which consumes a lot of gas. After invocation, contract `A` pays Ether to the caller. 25 | 3. Malicious user `X` ensures that the stack depth is shallow before invoking A. Both calls to `B` and `C` fail, but `X` can still collect the reward. 26 | 27 | It is possible to defend against this in two ways: 28 | 29 | 1. Check return value after invocation. 30 | 2. Check call stack depth experimentally. A library [2] by Piper Merriam exists for this purpose. This method is quite costly in gas. 31 | 32 | 33 | [1] a.k.a "shallow stack attack" and "stack attack". However, to be precise, the word ''stack'' has a different meaning within the EVM, and is not to be confused with the ''call stack''. 34 | 35 | [2] https://github.com/pipermerriam/ethereum-stack-depth-lib 36 | 37 | # Specification 38 | 39 | The opcode `CALLDEPTH` should return the remaining call stack depth. A value of `0` means that the call stack is exhausted, and no further calls can be made. 40 | 41 | # Rationale 42 | 43 | The actual call stack depth, as well as the call stack depth limit, are present in the EVM during execution, but just not available within the EVM. The implementation should be fairly simple and would provide a cheap and way to protect against call stack attacks. 44 | 45 | # Implementation 46 | 47 | Not implemented. 48 | -------------------------------------------------------------------------------- /EIPS/eip-3014.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3014 3 | title: eth_symbol JSON-RPC method 4 | author: Peter Grassberger (@PeterTheOne) 5 | discussions-to: https://github.com/ethereum/EIPs/issues/3012 6 | status: Draft 7 | type: Standards Track 8 | category: Interface 9 | created: 2020-09-30 10 | --- 11 | 12 | ## Simple Summary 13 | Add `eth_symbol` method to the JSON-RPC that returns the symbol of the native coin of the network. 14 | 15 | ## Abstract 16 | The new method `eth_symbol` (`eth_`-namespaced) has no parameters and returns a string of the native coin of the network. For the Ethereum mainnet this will be `ETH`, other networks will have other symbols. 17 | 18 | ## Motivation 19 | Wallets that deal with multiple networks need some basic information for every blockchain that they connect to. One of those things is the symbol of the native coin of the network. Instead of requiring the user to research and manually add the symbol it could be provided to the wallet via this proposed JSON-RPC endpoint and used automatically. There are lists of networks with symbols like https://github.com/ethereum-lists/chains where a user can manually look up the correct values. But this information could easily come from the network itself. 20 | 21 | ## Specification 22 | Method: `eth_symbol`. 23 | 24 | Params: none. 25 | 26 | Returns: `result` - the native coin symbol, string 27 | 28 | Example: 29 | 30 | ```js 31 | curl -X POST --data '{"jsonrpc":"2.0","method":"eth_symbol","params":[],"id":1}' 32 | 33 | // Result 34 | { 35 | "id": 1, 36 | "jsonrpc": "2.0", 37 | "result": "ETH" 38 | } 39 | ``` 40 | 41 | ## Rationale 42 | This endpoint is similar to [EIP-695](./eip-695.md) but it provides the symbol instead of `chainId`. It provides functionality that is already there for [ERC-20](./eip-20.md) tokens, but not yet for the native coin of the network. Alternative naming of `eth_nativeCurrencySymbol` was considered, but the context and the fact that it just returns one value makes it clear that that it returns the symbol for the native coin of the network. 43 | 44 | ## Security Considerations 45 | It is a read only endpoint. The information is only as trusted as the JSON-RPC node itself, it could supply wrong information and thereby trick the user in believing he/she is dealing with another native coin. 46 | 47 | ## Copyright 48 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 49 | -------------------------------------------------------------------------------- /EIPS/eip-3091.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3091 3 | title: Block Explorer API Routes 4 | author: Pedro Gomes (@pedrouid) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3091-block-explorer-api-routes/4907 6 | status: Stagnant 7 | type: Standards Track 8 | category: Interface 9 | created: 2020-11-02 10 | --- 11 | 12 | ## Simple Summary 13 | Standard API Routes for Blockchain explorers 14 | 15 | ## Abstract 16 | This proposal brings standardization between block explorers API routes when linking transactions, blocks, accounts and tokens. 17 | 18 | ## Motivation 19 | Currently wallets will link transactions and accounts to block explorers web pages but as chain diversity and layer two solutions grow it becomes harder to maintain a consistent user experience. Adding new chains or layer two solutions becomes harder given these endpoints are inconsistent. Standardizing the API routes to these links improves interoperability between wallets and block explorers. This EIP makes RPC endpoints like [EIP-2015](./eip-2015.md) more feasible. 20 | 21 | ## Specification 22 | Block explorers will route their webpages accordingly for the following data: 23 | 24 | ### Blocks 25 | `/block/` 26 | 27 | ### Transactions 28 | `/tx/` 29 | 30 | ### Accounts 31 | `/address/` 32 | 33 | ### ERC-20 Tokens 34 | `/token/` 35 | 36 | ## Backward Compatibility 37 | This EIP was designed with existing API routes in mind to reduce disruption. Incompatible block explorers should include either 301 redirects to their existing API routes to match this EIP. 38 | 39 | ## Security Considerations 40 | TBD 41 | 42 | ## Copyright 43 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 44 | -------------------------------------------------------------------------------- /EIPS/eip-3198.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3198 3 | title: BASEFEE opcode 4 | author: Abdelhamid Bakhta (@abdelhamidbakhta), Vitalik Buterin (@vbuterin) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3198-basefeeopcode/5162 6 | status: Final 7 | type: Standards Track 8 | category: Core 9 | created: 2021-01-13 10 | requires: 1559 11 | --- 12 | 13 | ## Simple Summary 14 | Adds an opcode that gives the EVM access to the block's base fee. 15 | 16 | ## Abstract 17 | 18 | Add a `BASEFEE (0x48)` that returns the value of the base fee of the current block it is executing in. 19 | 20 | ## Motivation 21 | The intended use case would be for contracts to get the value of the base fee. This feature would enable or improve existing use cases, such as: 22 | - Contracts that need to set bounties for anyone to "poke" them with a transaction could set the bounty to be `BASEFEE + x`, or `BASEFEE * (1 + x)`. This makes the mechanism more reliable, because they will always pay "enough" regardless of market conditions. 23 | - Gas futures can be implemented based on it. This would be more precise than gastokens. 24 | - Improve the security for state channels, plasma, optirolls and other fraud proof driven solutions. Having the `BASEFEE` as an input allows you to lengthen the challenge period automatically if you see that the `BASEFEE` is high. 25 | 26 | ## Specification 27 | Add a `BASEFEE` opcode at `(0x48)`, with gas cost `G_base`. 28 | 29 | | Op | Input | Output | Cost | 30 | |:----: |:-----: |:------: |:----: | 31 | | 0x48 | 0 | 1 | 2 | 32 | 33 | ## Rationale 34 | 35 | ### Gas cost 36 | The value of the base fee is needed to process transactions. That means it's value is already available before running the EVM code. 37 | The opcode does not add extra complexity and additional read/write operations, hence the choice of `G_base` gas cost. 38 | 39 | ## Backwards Compatibility 40 | There are no known backward compatibility issues with this opcode. 41 | 42 | ## Test Cases 43 | 44 | ### Nominal case 45 | Assuming current block base fee is `7 wei`. 46 | This should push the value `7` (left padded byte32) to the stack. 47 | 48 | Bytecode: `0x4800` (`BASEFEE, STOP`) 49 | 50 | | Pc | Op | Cost | Stack | RStack | 51 | |-------|-------------|------|-----------|-----------| 52 | | 0 | BASEFEE | 2 | [] | [] | 53 | | 1 | STOP | 0 | [7] | [] | 54 | 55 | Output: 0x 56 | Consumed gas: `2` 57 | 58 | ## Security Considerations 59 | The value of the base fee is not sensitive and is publicly accessible in the block header. There are no known security implications with this opcode. 60 | 61 | ## Copyright 62 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 63 | -------------------------------------------------------------------------------- /EIPS/eip-3238.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3238 3 | title: Difficulty Bomb Delay to Q2/2022 4 | author: Afri Schoedon (@q9f) 5 | discussions-to: https://github.com/ethereum/EIPs/issues/3239 6 | type: Standards Track 7 | category: Core 8 | status: Stagnant 9 | created: 2021-01-25 10 | --- 11 | 12 | ## Simple Summary 13 | Delays the difficulty bomb so 30 second blocks won't happen until around Q2/2022. 14 | 15 | ## Abstract 16 | 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 eleven million blocks later than the actual block number. 17 | 18 | ## Motivation 19 | Even after the Ethereum 2.0 mainnet launch, Ethash proof-of-work mining on the legacy chain should be feasible. It should allow miners sealing new blocks every 13~15 seconds on average for another ten months and allow both Ethereum 1.x and Ethereum 2.0 developers to conclude the merge. 20 | 21 | ## Specification 22 | #### Relax Difficulty with Fake Block Number 23 | For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: 24 | 25 | fake_block_number = max(0, block.number - 11_000_000) if block.number >= FORK_BLOCK_NUMBER else block.number 26 | 27 | ## Rationale 28 | This will delay the ice age by another ~26 million seconds (approximately ~9.89 months), so the chain would be back at ~30 second block times in Q2/2022. Hopefully, by then the Eth1-to-Eth2 merge will be concluded and the ice age fulfilled its task. 29 | 30 | ## Backwards Compatibility 31 | This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to consider this EIP either with or shortly after the Berlin hard-fork but not later than July 2021. 32 | 33 | Alternatively, in order to maintain stability of the system, a it can be considered to activate this EIP along with EIP-1559 fee market changes in a bundle. With the delay of the ice age, there is a desire to no further increase inflation and rather incentivize users to participate in proof-of-stake consensus instead. 34 | 35 | ## Security Considerations 36 | There are no known security issues with this proposal. 37 | 38 | ## Copyright 39 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 40 | -------------------------------------------------------------------------------- /EIPS/eip-3322.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3322 3 | title: Account gas storage opcodes 4 | author: William Morriss (@wjmelements) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3322-efficient-gas-storage/5470 6 | status: Stagnant 7 | type: Standards Track 8 | category: Core 9 | created: 2020-03-04 10 | --- 11 | 12 | ## Simple Summary 13 | Allows contract accounts to store gas that can be transferred to the refund counter. 14 | 15 | ## Abstract 16 | Contracts can persist gas for later transfer to the refund counter. 17 | Three opcodes are introduced to read, add to, and use this gas counter. 18 | 19 | ## Motivation 20 | The refund mechanism is currently being used by gas tokens to arbitrage gas price. 21 | This brings gas supply elasticity and price stability by moving gas from blocks with less demand to blocks with more demand. 22 | Unfortunately this rewards unnecessary state growth. 23 | By introducing a superior gas storage mechanism, the gas market will require less storage and computation. 24 | 25 | ## Specification 26 | Contract accounts gain an unsigned gas refund counter, initially zero. 27 | 28 | Three new opcodes are introduced to manage this state. 29 | 30 | * `SELFGAS` (`0x49`): Pushes the current account's gas refund counter onto the stack. 31 | Shares gas pricing with `SELFBALANCE`. 32 | * `USEGAS` (`0x4a`): Pops `amount` from the stack. 33 | The minimum of `amount` and the current account's gas refund counter is transferred to the execution context's refund counter. 34 | Costs `5000` gas. 35 | * `STOREGAS` (`0x4b`): Pops `amount` from the stack. 36 | Costs `5000 + amount` gas. 37 | Increases the current account's gas refund counter by `amount`. 38 | 39 | ## Rationale 40 | By reusing the execution context's refund counter we can reuse its 50% DoS protection, which limits its block elasticity contribution to 2x. 41 | 42 | The gas costs are based on similar opcodes `SELFBALANCE` and `SSTORE`. 43 | 44 | Most accounts will store no gas, so the per-account storage overhead should be minimal or even zero in the normal case. 45 | 46 | The opcode numbers chosen are in the same `0x4X` range as `SELFBALANCE` and `GASLIMIT`. 47 | 48 | ## Backwards Compatibility 49 | Because the gas is added to the refund counter, no compatibility issues are anticipated. 50 | 51 | ## Test Cases 52 | | Code | Used Gas | Refund | Original | Final | 53 | |------------------|----------|--------|----------|-------| 54 | | 0x60004900 | 5003 | 0 | 0 | 0 | 55 | | 0x60034900 | 5003 | 2 | 2 | 0 | 56 | | 0x60034900 | 5003 | 3 | 3 | 0 | 57 | | 0x60034900 | 5003 | 3 | 4 | 1 | 58 | | 0x60034960034900 | 10006 | 4 | 4 | 0 | 59 | | 0x60034960034900 | 10006 | 6 | 6 | 0 | 60 | | 0x484900 | 5010 | 100000 | 100000 | 0 | 61 | | 0x61ffff4a00 | 70538 | 0 | 0 | 65535 | 62 | 63 | 64 | ## Security Considerations 65 | DoS is already limited by the 50% refund limit. 66 | 67 | ## Copyright 68 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 69 | -------------------------------------------------------------------------------- /EIPS/eip-3338.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3338 3 | title: Limit account nonce to 2^52 4 | author: Micah Zoltu (@MicahZoltu), Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2681-limit-account-nonce-to-2-64-1/4324 6 | status: Withdrawn 7 | withdrawal-reason: Withdrawn in favor of [EIP-2681](./eip-2681.md) 8 | type: Standards Track 9 | category: Core 10 | created: 2021-03-07 11 | --- 12 | 13 | ## Abstract 14 | 15 | Limit account nonce to be between `0` and `2^52`. 16 | 17 | ## Motivation 18 | 19 | Account nonces are currently specified to be arbitrarily long unsigned integers. Dealing with arbitrary length data in the state witnesses is not optimal, therefore this EIP will allow proofs to represent the nonce in a more optimized way. 20 | 21 | Additionally it could prove beneficial to transaction formats, where some improvements are potentially sought by at least three other proposals. 22 | 23 | Lastly, this facilitates a minor optimisation in clients, because the nonce no longer needs to be kept as a 256-bit number. 24 | 25 | ## Specification 26 | 27 | If `block.number >= FORK_BLOCK` introduce two new restrictions: 28 | 29 | 1. Consider any transaction invalid, where the nonce exceeds `2^52`. 30 | 2. The `CREATE` instruction to abort with an exceptional halt, where the account nonce is `2^52`. 31 | 32 | ## Rationale 33 | 34 | 1. It is unlikely for any nonce to reach or exceed the proposed limit. If one would want to reach that limit via external transactions, it would cost at least `21000 * (2^64-1) = 387_381_625_547_900_583_915_000` gas. 35 | 36 | 2. It must be noted that in the past, in the Morden testnet, each new account had a starting nonce of `2^20` in order to differentiate transactions from mainnet transactions. 37 | This mode of replay protection is out of fashion since [EIP-155](./eip-155.md) introduced a more elegant way using chain identifiers. 38 | 39 | 3. Most clients already consider the nonce field to be 64-bit, such as go-ethereum. 40 | 41 | 4. All integer values <= 2^52 can be encoded in a 64-bit floating point without any loss of precision, making this value easy to work with in languages that only have floating point number support. 42 | 43 | ## Backwards Compatibility 44 | 45 | While this is a breaking change, no actual effect should be visible: 46 | 47 | 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. 48 | 49 | ## Security Considerations 50 | 51 | None. 52 | 53 | ## Copyright 54 | 55 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 56 | -------------------------------------------------------------------------------- /EIPS/eip-3374.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3374 3 | title: Predictable Proof-of-Work (POW) Sunsetting 4 | author: Query0x (@Query0x) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3374-predictable-proof-of-work-sunsetting 6 | status: Withdrawn 7 | type: Standards Track 8 | category: Core 9 | created: 2021-03-13 10 | --- 11 | 12 | ## Simple Summary 13 | Sets block reward to 3 and reduces it to 1 linearly over the course of about 1 year. 14 | 15 | ## Abstract 16 | Sets the block reward to 3 ETH and then incrementally decreases it every block for 2,362,000 blocks (approximately 1 year) until it reaches 1 ETH. 17 | 18 | ## Motivation 19 | Unnecessarily abrupt changes to the Ethereum ecosystem cause disruption and disharmony resulting in the disenfranchisement of community members while undermining stability and confidence. While moves from Proof-of-Work to Proof-of-Stake will undoubtedly cause friction between those community members vested in either, all benefit from a measured, predictable transition. 20 | 21 | This proposal: 22 | 23 | 1) Is issuance neutral over 1 year, and reduces issuance beyond that. 24 | 2) Sets an initial block reward of 3; 25 | 3) Introduces an ongoing, predictable reduction in future mining rewards down to 1, effectively "sunsetting" POW and codifying the move to POS; 26 | 4) Reduces economic incentives for continued development of ASICs; 27 | 5) Allows the impacts of decreasing miner rewards to be measured and monitored rather than relying on conjecture and game theory, so adjustments can be made if necessary. 28 | 29 | 30 | ## Specification 31 | ### Constants 32 | * `TRANSITION_START_BLOCK_NUMBER: TBD` 33 | * `TRANSITION_DURATION: 2_362_000` // (about one year) 34 | * `TRANSITION_END_BLOCK_NUMBER: FORK_BLOCK_NUMBER + TRANSITION_DURATION` 35 | * `STARTING_REWARD: 3_000_000_000_000_000_000` 36 | * `ENDING_REWARD: 1_000_000_000_000_000_000` 37 | * `REWARD_DELTA: STARTING_REWARD - ENDING_REWARD` 38 | ### Block Reward 39 | ```py 40 | if block.number >= TRANSITION_END_BLOCK_NUMBER: 41 | block_reward = ENDING_REWARD 42 | elif block.number == TRANSITION_START_BLOCK_NUMBER: 43 | block_reward = STARTING_REWARD 44 | elif block.number > TRANSITION_START_BLOCK_NUMBER: 45 | block_reward = STARTING_REWARD - REWARD_DELTA * TRANSITION_DURATION / (block.number - TRANSITION_START_BLOCK_NUMBER) 46 | ``` 47 | 48 | ## Rationale 49 | Picking starting and ending block reward values that are equidistant from the current block reward rate of 2 ensures the impact of this EIP will be issuance neutral over the one year time frame. Temporarily raising the block reward to 3 blunts the initial impact of a sudden miner revenue decrease and the continual reductions thereafter codify Ethereum's move to POS by increasingly disincentivizing POW. Importantly, this approach moderates the rate of change so impacts and threats can be measured and monitored. 50 | 51 | ## Backwards Compatibility 52 | There are no known backward compatibility issues with the introduction of this EIP. 53 | 54 | ## Security Considerations 55 | There are no known security issues with the introduction of this EIP. 56 | 57 | ## Copyright 58 | Copyright and related rights waived via CC0. 59 | -------------------------------------------------------------------------------- /EIPS/eip-3382.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3382 3 | title: Hardcoded Block Gas Limit 4 | author: Philippe Castonguay (@PhABC) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3382-hardcoded-gas-limit 6 | status: Withdrawn 7 | withdrawal-reason: The author prefers [EIP-3756](./eip-3756.md) 8 | type: Standards Track 9 | category: Core 10 | created: 2021-03-13 11 | --- 12 | 13 | ## Simple Summary 14 | 15 | Hardcode the block gas limit to `12,500,000` gas per block. 16 | 17 | ## Abstract 18 | 19 | Updates the block validation rules such that a block is invalid if the `gas_limit` header field is not equal to `12,500,000`. 20 | 21 | ## Motivation 22 | 23 | Both Ethereum's Proof of Work and Proof of Stake designs assume that block producers are financially rational, but does not assume block producers to be benevolent. There is one exception however, and it is when block producers choose the gas limit of a block where it is assumed that block producers care about the long term health and decentralisation of the chain. Indeed, the block gas limit is one of the only parameters in Ethereum that is not dictated by node consensus, but instead is chosen by block producers. This decision was initially made to allow urgent changes in the block gas limit if necessary. Both drastically increasing or decreasing this parameter could have serious consequences that may not be desired. It is therefore a critical parameter that should require node consensus to avoid any sudden harmful change imposed by a small number of actors on the rest of the network. 24 | 25 | ## Specification 26 | Refer to `gasLimit` as `gasTarget` post EIP-1559. 27 | 28 | ### Added Consensus Constraint 29 | 30 | As of `FORK_BLOCK_NUMBER`, the `header.gasLimit` **MUST** be equal to `BLOCK_GAS_LIMIT`, where `BLOCK_GAS_LIMIT` is a hardcoded constant set to `12,500,000`. 31 | 32 | ## Rationale 33 | 34 | ### Keeping gasLimit in Block Headers 35 | 36 | While it would be possible to remove the `gasLimit` field from block headers, it would change the data structure to be hashed, which could lead to unintended consequences. It is therefore easier to leave the gasLimit as part of block headers. 37 | 38 | ### Chosen Gas Limit 39 | 40 | The `12,500,000` value is being proposed as it's the current block gas limit as of time of writing this EIP. The actual amount could be altered with a subsequent EIP to avoid deviating from the core intent of this EIP. 41 | 42 | ## Backwards Compatibility 43 | 44 | This EIP is backward compatible. 45 | 46 | ## Security Considerations 47 | Rapid changes to the gas limit will likely be more difficult to execute, which could be problematic if an urgent situation arise that required changing the gas limit. 48 | 49 | ## Copyright 50 | 51 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 52 | -------------------------------------------------------------------------------- /EIPS/eip-3554.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3554 3 | title: Difficulty Bomb Delay to December 2021 4 | author: James Hancock (@madeoftin) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3554-ice-age-delay-targeting-december-2021/6188 6 | status: Final 7 | type: Standards Track 8 | category: Core 9 | created: 2021-05-06 10 | --- 11 | 12 | ## Simple Summary 13 | Delays the difficulty bomb to show effect the first week of December 2021. 14 | 15 | ## Abstract 16 | 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 9,700,000 blocks later than the actual block number. 17 | 18 | ## Motivation 19 | Targeting for the Shanghai upgrade and/or the Merge to occur before December 2021. Either the bomb can be readjusted at that time, or removed all together. 20 | 21 | ## Specification 22 | #### Relax Difficulty with Fake Block Number 23 | For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: 24 | ```py 25 | fake_block_number = max(0, block.number - 9_700_000) if block.number >= FORK_BLOCK_NUMBER else block.number 26 | ``` 27 | ## Rationale 28 | 29 | The following script predicts a .1 second delay to blocktime the first week of december and a 1 second delay by the end of the month. 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. 30 | 31 | ```python 32 | def predict_diff_bomb_effect(current_blknum, current_difficulty, block_adjustment, months): 33 | ''' 34 | Predicts the effect on block time (as a ratio) in a specified amount of months in the future. 35 | Vars used in last prediction: 36 | current_blknum = 12382958 37 | current_difficulty = 7393633000000000 38 | block adjustment = 9700000 39 | months = 6 40 | ''' 41 | blocks_per_month = (86400 * 30) // 13.3 42 | future_blknum = current_blknum + blocks_per_month * months 43 | diff_adjustment = 2 ** ((future_blknum - block_adjustment) // 100000 - 2) 44 | diff_adjust_coeff = diff_adjustment / current_difficulty * 2048 45 | return diff_adjust_coeff 46 | 47 | 48 | diff_adjust_coeff = predict_diff_bomb_effect(12382958,7393633000000000,9700000,6) 49 | ``` 50 | 51 | ## Backwards Compatibility 52 | No known backward compatibility issues. 53 | 54 | ## Security Considerations 55 | 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. 56 | 57 | ## Copyright 58 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 59 | -------------------------------------------------------------------------------- /EIPS/eip-3651.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3651 3 | title: Warm COINBASE 4 | author: William Morriss (@wjmelements) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3651-warm-coinbase/6640 6 | status: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2021-07-12 10 | requires: 2929 11 | --- 12 | 13 | ## Simple Summary 14 | Starts the `COINBASE` address warm 15 | 16 | ## Abstract 17 | The `COINBASE` address shall be warm at the start of transaction execution, in accordance with the actual cost of reading that account. 18 | 19 | ## Motivation 20 | Direct `COINBASE` payments are becoming increasingly popular because they allow conditional payments, which provide benefits such as implicit cancellation of transactions that would revert. 21 | But accessing `COINBASE` is overpriced; the address is initially cold under the access list framework introduced in [EIP-2929](./eip-2929). 22 | This gas cost mismatch can incentivize alternative payments besides ETH, such as ERC20, but ETH should be the primary means of paying for transactions on Ethereum. 23 | 24 | ## Specification 25 | At the start of transaction execution, `accessed_addresses` shall be initialized to also include the address returned by `COINBASE` (`0x41`). 26 | 27 | ## Rationale 28 | The addresses currently initialized warm are the addresses that should already be loaded at the start of transaction validation. 29 | The `ORIGIN` address is always loaded to check its balance against the gas limit and the gas price. 30 | The `tx.to` address is always loaded to begin execution. 31 | The `COINBASE` address should also be always be loaded because they receive the block reward as well as the transaction fees. 32 | 33 | ## Backwards Compatibility 34 | There are no known backward compatibility issues presented by this change. 35 | 36 | ## Security Considerations 37 | There are no known security considerations introduced by this change. 38 | 39 | ## Copyright 40 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 41 | -------------------------------------------------------------------------------- /EIPS/eip-3709.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3709 3 | title: Remove Support for Type 1 Transactions 4 | author: Gregory Markou (@GregTheGreek) 5 | discussions-to: https://ethereum-magicians.org/t/eip-3709-deprecate-type-1-transactions/6810 6 | status: Draft 7 | type: Standards Track 8 | category: Interface 9 | created: 2021-08-07 10 | requires: 1559 11 | --- 12 | 13 | ## Simple Summary 14 | 15 | Deprecates usage of [EIP-2718](./eip-2718.md) `TransactionType` 1 in wallets and providers, upgrading all type 1 transactions to a type 2 transaction. 16 | 17 | ## Abstract 18 | 19 | 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). 20 | 21 | ## Motivation 22 | 23 | [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. 24 | 25 | 26 | ## Specification 27 | 28 | 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. 29 | 30 | The following fields need to be changed, or amended: 31 | - `access_list`: Nothing changes and it should remain in the transaction. 32 | - `type`: Should change from `0x1` to `0x2`. 33 | - `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). 34 | 35 | ## Rationale 36 | 37 | Improve the user experience for submitting transactions, and move away from legacy style transactions. 38 | 39 | ## Security Considerations 40 | 41 | There are no known security considerations at this time. 42 | 43 | ## Copyright 44 | 45 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 46 | -------------------------------------------------------------------------------- /EIPS/eip-3756.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3756 3 | title: Gas Limit Cap 4 | description: Set an in-protocol cap for the gas limit 5 | author: lightclient (@lightclient) 6 | discussions-to: https://ethereum-magicians.org/t/eip-3756-gas-limit-cap/6921 7 | status: Draft 8 | type: Standards Track 9 | category: Core 10 | created: 2021-08-21 11 | --- 12 | 13 | ## Abstract 14 | 15 | Set an in-protocol cap for the gas limit of 30,000,000. 16 | 17 | ## Motivation 18 | 19 | A high gas limit increases pressure on the network. In the benign case, it 20 | increases the size of the state and history faster than we can sustain. In the 21 | malicious case, it amplifies the devastation of certain denial-of-service 22 | attacks. 23 | 24 | ## Specification 25 | 26 | As of the fork block `N`, consider blocks with a `gas_limit` greater than 27 | `30,000,000` invalid. 28 | 29 | ## Rationale 30 | 31 | ### Why Cap the Gas Limit 32 | 33 | The gas limit is currently under the control of block proposers. They have the 34 | ability to increase the gas limit to whatever value they desire. This allows 35 | them to bypass the EIP and All Core Devs processes in protocol decisions that 36 | may negatively affect the security and/or decentralization of the network. 37 | 38 | ### No Fixed Gas Limit 39 | 40 | A valuable property of proposers choosing the gas limit is they can scale it 41 | down quickly if the network becomes unstable or is undergoing certain types of 42 | attacks. For this reason, we maintain their ability to lower the gas limit 43 | _below_ 30,000,000. 44 | 45 | ## Backwards Compatibility 46 | No backwards compatibility issues. 47 | 48 | ## Test Cases 49 | TBD 50 | 51 | ## Security Considerations 52 | No security considerations. 53 | 54 | ## Copyright 55 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 56 | -------------------------------------------------------------------------------- /EIPS/eip-3788.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3788 3 | title: Strict enforcement of chainId 4 | description: Reject transactions that do not explicitly have the same chainId as the node's configuration. 5 | author: Gregory Markou (@GregTheGreek) 6 | discussions-to: https://ethereum-magicians.org/t/discussion-to-eip-3788-strict-enforcement-of-chainid/7001 7 | status: Draft 8 | type: Standards Track 9 | category: Core 10 | created: 2021-09-2 11 | requires: 155 12 | --- 13 | 14 | ## Abstract 15 | 16 | Reject transactions that do not explicitly have the same chainId as the node's configuration. 17 | 18 | ## Motivation 19 | 20 | Per [EIP-155](./eip-155.md) a transaction with a `chainId = 0` is considered to be a valid 21 | transaction. This was a feature to offer developers the ability to sumbit replayable transactions 22 | across different chains. With the rise of evm compatible chains, many of which use forks, or packages 23 | from popular Ethereum clients, we are putting user funds at risk. This is because most wallet 24 | interfaces do not expose the chainId to the user, meaning they typically do not have insight 25 | into what chainId they are signing. Should a malicious actor (or accidental) choose to, they 26 | can easily have users submit transactions with a `chainId = 0` on a non-mainnet network, allowing 27 | the malicious actor to replay the transaction on ethereum mainnet (or other networks for that matter) 28 | as a grief or sophisticated attack. 29 | 30 | ## Specification 31 | 32 | As of the fork block `N`, consider transactions with a `chaindId = 0` to be invalid. Such that 33 | transactions are verified based on the nodes configuration. Eg: 34 | ``` 35 | if (node.cfg.chainId != tx.chainId) { 36 | // Reject transaction 37 | } 38 | ``` 39 | 40 | ## Rationale 41 | 42 | The configuration set by the node is the main source of truth, and thus should be explicitly used 43 | when deciding how to filter out a transaction. This check should exist in two places, as a filter 44 | on the JSON-RPC (eg: `eth_sendTransaction`), and stricly enforced on the EVM during transaction 45 | validation. 46 | 47 | This ensures that users will not have transactions pending that will be guaranteed to fail, and 48 | prevents the transaction from being included in a block. 49 | 50 | ## Backwards Compatibility 51 | This breaks all applications or tooling that submit transactions with a `chainId == 0` after block number `N`. 52 | 53 | ## Test Cases 54 | TBD 55 | 56 | ## Security Considerations 57 | It should be noted this will not prevent a malicious actor from deploying a network with `chainId = 1`, or copying any other networks chainId. 58 | 59 | ## Copyright 60 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 61 | -------------------------------------------------------------------------------- /EIPS/eip-3978.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3978 3 | title: Gas refunds on reverts 4 | description: Do not erase gas refunds on transaction subcall reverts, due users pay a lot of gas for storage non-modification. 5 | author: Anton Bukov (@k06a), Mikhail Melnik (@ZumZoom) 6 | discussions-to: https://ethereum-magicians.org/t/eip-3978-gas-refunds-on-reverts/7071/ 7 | status: Draft 8 | type: Standards Track 9 | category: Core 10 | created: 2021-09-16 11 | updated: 2021-12-30 12 | --- 13 | 14 | ## Abstract 15 | 16 | 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. 17 | 18 | ## Motivation 19 | 20 | Сurrent full cancelling of gas refunds on internal reverts is too unfair. Users pay for non-modification same cost as for modification. 21 | 22 | ## Specification 23 | 24 | Let's consider all reverted SSTOREs as SLOADs (access) costs. This requires to remember (SSTORE - SLOAD) costs for each SSTORE inside every internal call excluding its subcalls and on revert let's update gas refund counter in the following manner: 25 | ``` 26 | tx.gas_refund_counter = tx.gas_refund_counter - call.gas_refund_counter + call.sstores_sloads_diff_counter; 27 | ``` 28 | 29 | ## Rationale 30 | 31 | TBD 32 | 33 | ## Backwards Compatibility 34 | 35 | No known backward incompatibilities. 36 | 37 | ## Test Cases 38 | 39 | TBD 40 | 41 | ## Reference Implementation 42 | 43 | TBD 44 | 45 | ## Security Considerations 46 | 47 | TBD 48 | 49 | ## Copyright 50 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 51 | -------------------------------------------------------------------------------- /EIPS/eip-4345.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 4345 3 | title: Difficulty Bomb Delay to June 2022 4 | description: Delays the difficulty bomb to be noticeable in June 2022. 5 | author: Tim Beiko (@timbeiko), James Hancock (@MadeOfTin), Thomas Jay Rush (@tjayrush) 6 | discussions-to: https://ethereum-magicians.org/t/eip-4345-difficulty-bomb-delay-to-may-2022/7209 7 | status: Final 8 | type: Standards Track 9 | category: Core 10 | created: 2021-10-05 11 | --- 12 | 13 | ## Abstract 14 | 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. 15 | 16 | ## Motivation 17 | Targeting for The Merge to occur before June 2022. If it is not ready by then, the bomb can be delayed further. 18 | 19 | ## Specification 20 | #### Relax Difficulty with Fake Block Number 21 | For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula: 22 | ```py 23 | fake_block_number = max(0, block.number - 10_700_000) if block.number >= FORK_BLOCK_NUMBER else block.number 24 | ``` 25 | ## Rationale 26 | 27 | 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. 28 | 29 | ```python 30 | def predict_diff_bomb_effect(current_blknum, current_difficulty, block_adjustment, months): 31 | ''' 32 | Predicts the effect on block time (as a ratio) in a specified amount of months in the future. 33 | Vars used for predictions: 34 | current_blknum = 13423376 # Oct 15, 2021 35 | current_difficulty = 9545154427582720 36 | block adjustment = 10700000 37 | months = 7.5 # June 2022 38 | months = 8.5 # July 2022 39 | ''' 40 | blocks_per_month = (86400 * 30) // 13.3 41 | future_blknum = current_blknum + blocks_per_month * months 42 | diff_adjustment = 2 ** ((future_blknum - block_adjustment) // 100000 - 2) 43 | diff_adjust_coeff = diff_adjustment / current_difficulty * 2048 44 | return diff_adjust_coeff 45 | 46 | 47 | diff_adjust_coeff = predict_diff_bomb_effect(13423376,9545154427582720,10700000,7.5) 48 | diff_adjust_coeff = predict_diff_bomb_effect(13423376,9545154427582720,10700000,8.5) 49 | ``` 50 | 51 | ## Backwards Compatibility 52 | No known backward compatibility issues. 53 | 54 | ## Security Considerations 55 | 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. 56 | 57 | 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. 58 | 59 | ## Copyright 60 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 61 | -------------------------------------------------------------------------------- /EIPS/eip-4520.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 4520 3 | title: Mult-byte opcodes prefixed by EB and EC. 4 | description: Reserve `0xEB` and `0xEC` for usage as extended opcode space. 5 | author: Brayton Goodall (@Spore-Druid-Bray), Mihir Faujdar (@uink45) 6 | discussions-to: https://ethereum-magicians.org/t/multi-byte-opcodes/7681 7 | status: Draft 8 | type: Standards Track 9 | category: Core 10 | created: 2021-12-1 11 | --- 12 | 13 | ## Abstract 14 | Reserve `0xEB` and `0xEC` for usage as extended opcode space. 15 | 16 | ## Motivation 17 | It would be convenient to introduce new opcodes that are likely to be infrequently used, whilst also being able to have greater than 256 opcodes in total. As a single byte opcode is half the size of a double byte opcode, the greatest efficiency in code sizes will be one where frequently used opcodes are single bytes. Two prefix bytes are used to accommodate up to 510 double byte opcodes. 18 | 19 | ## Specification 20 | For example, a new arithmetic opcode may be allocated to `0xEC 01`(`ADD`), and a novel opcode may be introduced at `0xEB F4`(`DELEGATECALL`). 21 | 22 | Triple byte opcodes may be doubly-prefixed by `0xEB EB`, `0xEC EC`, `0xEB EC` and `0xEC EB`. It is possible to allocate experimental opcodes to this triple-byte space initially, and if they prove safe and useful, they could later be allocated a location in double-byte or single-byte space. 23 | 24 | Only `0xEB EB`, `0xEC EC`, `0xEC EC`, and `0xEB EC` may be interpreted as further extensions of the opcode space. `0xEB` and `0xEC` do not themselves affect the stack or memory, however opcodes specified by further bytes may. If a multi-byte opcode is yet to be defined, it is to be treated as `INVALID` rather than as a `NOP`, as per usual for undefined opcodes. 25 | 26 | ## Rationale 27 | It was considered that two prefix bytes rather than one would be adequate for reservation as extension addresses. Both `0xEB` and `0xEC` were chosen to be part of the E-series of opcodes. For example, the `0xEF` byte is reserved for contracts conforming to the Ethereum Object Format. By having unassigned opcodes for extending the opcode space, there will be a lower risk of breaking the functionalities of deployed contracts compared to choosing assigned opcodes. 28 | 29 | ## Backwards Compatibility 30 | Previous usage of `0xEB` and `0xEC` may result in unexpected behaviour and broken code. 31 | 32 | ## Security Considerations 33 | There are no known security considerations. 34 | 35 | ## Copyright 36 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 37 | -------------------------------------------------------------------------------- /EIPS/eip-4521.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 4521 3 | title: 721/20-compatible transfer 4 | description: Recommends a simple extension to make NFTs compatible with apps and contracts that handle fungibles. 5 | author: Ross Campbell (@z0r0z) 6 | discussions-to: https://ethereum-magicians.org/t/eip-4521-721-20-compatible-transfer/7903 7 | status: Draft 8 | type: Standards Track 9 | category: ERC 10 | created: 2021-12-13 11 | requires: 721 12 | --- 13 | 14 | ## Abstract 15 | ERC-721, the popular standard for non-fungible tokens (NFTs), includes send functions, such as `transferFrom()` and `safeTransferFrom()`, but does not include a backwards-compatible `transfer()` found in fungible ERC-20 tokens. This standard provides references to add such a `transfer()`. 16 | 17 | ## Motivation 18 | This standard proposes a simple extension to allow NFTs to work with contracts designed to manage ERC-20s and many consumer wallets which expect to be able to execute a token `transfer()`. For example, if an NFT is inadvertently sent to a contract that typically handles ERC-20, that NFT will be locked. It should also simplify the task for contract programmers if they can rely on `transfer()` to both handle ERC-20 and NFTs. 19 | 20 | ## Specification 21 | 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. 22 | 23 | The interface for ERC-4521 `transfer()` MUST conform to ERC-20 and resulting transfers MUST fire the `Transfer` event as described in ERC-721. 24 | 25 | ```sol 26 | function transfer(address to, uint256 tokenId) external returns (bool success); 27 | ``` 28 | 29 | ## Rationale 30 | Replicating ERC-20 `transfer()` with just a minor change to accurately reflect that a unique `tokenId` rather than fungible sum is being sent is desirable for code simplicity and to make integration easier. 31 | 32 | ## Backwards Compatibility 33 | This EIP does not introduce any known backward compatibility issues. 34 | 35 | ## Reference Implementation 36 | A reference implementation of an ERC-4521 `transfer()`: 37 | 38 | ```sol 39 | function transfer(address to, uint256 tokenId) public virtual returns (bool success) { 40 | require(msg.sender == ownerOf[tokenId], "NOT_OWNER"); 41 | 42 | unchecked { 43 | balanceOf[msg.sender]--; 44 | 45 | balanceOf[to]++; 46 | } 47 | 48 | delete getApproved[tokenId]; 49 | 50 | ownerOf[tokenId] = to; 51 | 52 | emit Transfer(msg.sender, to, tokenId); 53 | 54 | success = true; 55 | } 56 | ``` 57 | 58 | ## Security Considerations 59 | Implementers must be sure to include the relevant return `bool` value for an ERC-4521 in order to conform with existing contracts that use ERC-20 interfaces, otherwise, NFTs may be locked unless a `safeTransfer` is used in such contracts. 60 | 61 | ## Copyright 62 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 63 | -------------------------------------------------------------------------------- /EIPS/eip-6.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 6 3 | title: Renaming SUICIDE opcode 4 | author: Hudson Jameson 5 | status: Final 6 | type: Standards Track 7 | category: Interface 8 | created: 2015-11-22 9 | --- 10 | 11 | ### Abstract 12 | The solution proposed in this EIP is to change the name of the `SUICIDE` opcode in Ethereum programming languages with `SELFDESTRUCT`. 13 | 14 | ### Motivation 15 | Mental health is a very real issue for many people and small notions can make a difference. Those dealing with loss or depression would benefit from not seeing the word suicide in our programming languages. By some estimates, 350 million people worldwide suffer from depression. The semantics of Ethereum's programming languages need to be reviewed often if we wish to grow our ecosystem to all types of developers. 16 | 17 | An Ethereum security audit commissioned by DEVolution, GmbH and [performed by Least Authority](https://github.com/LeastAuthority/ethereum-analyses/blob/master/README.md) recommended the following: 18 | > Replace the instruction name "suicide" with a less connotative word like "self-destruct", "destroy", "terminate", or "close", especially since that is a term describing the natural conclusion of a contract. 19 | 20 | The primary reason for us to change the term suicide is to show that people matter more than code and Ethereum is a mature enough of a project to recognize the need for a change. Suicide is a heavy subject and we should make every effort possible to not affect those in our development community who suffer from depression or who have recently lost someone to suicide. Ethereum is a young platform and it will cause less headaches if we implement this change early on in its life. 21 | 22 | ### Implementation 23 | `SELFDESTRUCT` is added as an alias of `SUICIDE` opcode (rather than replacing it). 24 | https://github.com/ethereum/solidity/commit/a8736b7b271dac117f15164cf4d2dfabcdd2c6fd 25 | https://github.com/ethereum/serpent/commit/1106c3bdc8f1bd9ded58a452681788ff2e03ee7c 26 | -------------------------------------------------------------------------------- /EIPS/eip-600.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 600 3 | title: Ethereum purpose allocation for Deterministic Wallets 4 | author: Nick Johnson (@arachnid), Micah Zoltu (@micahzoltu) 5 | type: Standards Track 6 | category: ERC 7 | status: Final 8 | discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 9 | created: 2017-04-13 10 | --- 11 | 12 | ## Abstract 13 | This EIP defines a logical hierarchy for deterministic wallets based on [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), the purpose scheme defined in [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) and [this proposed change to BIP43](https://github.com/bitcoin/bips/pull/523). 14 | 15 | This EIP is a particular application of BIP43. 16 | 17 | ## Motivation 18 | Because Ethereum is based on account balances rather than UTXO, the hierarchy defined by BIP44 is poorly suited. As a result, several competing derivation path strategies have sprung up for deterministic wallets, resulting in inter-client incompatibility. This BIP seeks to provide a path to standardise this in a fashion better suited to Ethereum's unique requirements. 19 | 20 | ## Specification 21 | We define the following 2 levels in BIP32 path: 22 | 23 | 
24 | m / purpose' / subpurpose' / EIP'
25 |
26 | 27 | Apostrophe in the path indicates that BIP32 hardened derivation is used. 28 | 29 | Each level has a special meaning, described in the chapters below. 30 | 31 | ### Purpose 32 | 33 | Purpose is set to 43, as documented in [this proposed change to BIP43](https://github.com/bitcoin/bips/pull/523). 34 | 35 | The purpose field indicates that this path is for a non-bitcoin cryptocurrency. 36 | 37 | Hardened derivation is used at this level. 38 | 39 | ### Subpurpose 40 | Subpurpose is set to 60, the SLIP-44 code for Ethereum. 41 | 42 | Hardened derivation is used at this level. 43 | 44 | ### EIP 45 | EIP is set to the EIP number specifying the remainder of the BIP32 derivation path. This permits new Ethereum-focused applications of deterministic wallets without needing to interface with the BIP process. 46 | 47 | Hardened derivation is used at this level. 48 | 49 | ## Rationale 50 | The existing convention is to use the 'Ethereum' coin type, leading to paths starting with `m/44'/60'/*`. Because this still assumes a UTXO-based coin, we contend that this is a poor fit, resulting in standardisation, usability, and security compromises. As a result, we are making the above proposal to define an entirely new hierarchy for Ethereum-based chains. 51 | 52 | ## Backwards Compatibility 53 | The introduction of another derivation path requires existing software to add support for this scheme in addition to any existing schemes. Given the already confused nature of wallet derivation paths in Ethereum, we anticipate this will cause relatively little additional disruption, and has the potential to improve matters significantly in the long run. 54 | 55 | ## Test Cases 56 | TBD 57 | 58 | ## Implementation 59 | None yet. 60 | 61 | ## References 62 | [This discussion on derivation paths](https://github.com/ethereum/EIPs/issues/84) 63 | 64 | ## Copyright 65 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 66 | -------------------------------------------------------------------------------- /EIPS/eip-606.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 606 3 | title: "Hardfork Meta: Homestead" 4 | author: Alex Beregszaszi (@axic) 5 | type: Meta 6 | status: Final 7 | created: 2017-04-23 8 | requires: 2, 7, 8 9 | --- 10 | 11 | ## Abstract 12 | 13 | This specifies the changes included in the hard fork named Homestead. 14 | 15 | ## Specification 16 | 17 | - Codename: Homestead 18 | - Activation: 19 | - Block >= 1,150,000 on Mainnet 20 | - Block >= 494,000 on Morden 21 | - Block >= 0 on future testnets 22 | - Included EIPs: 23 | - [EIP-2](./eip-2.md) (Homestead Hard-fork Changes) 24 | - [EIP-7](./eip-7.md) (DELEGATECALL) 25 | - [EIP-8](./eip-8.md) (Networking layer: devp2p Forward Compatibility Requirements for Homestead) 26 | 27 | ## References 28 | 29 | 1. https://blog.ethereum.org/2016/02/29/homestead-release/ 30 | 31 | ## Copyright 32 | 33 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 34 | -------------------------------------------------------------------------------- /EIPS/eip-607.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 607 3 | title: "Hardfork Meta: Spurious Dragon" 4 | author: Alex Beregszaszi (@axic) 5 | type: Meta 6 | status: Final 7 | created: 2017-04-23 8 | requires: 155, 160, 161, 170, 608 9 | --- 10 | 11 | ## Abstract 12 | 13 | This specifies the changes included in the hard fork named Spurious Dragon. 14 | 15 | ## Specification 16 | 17 | - Codename: Spurious Dragon 18 | - Aliases: State-clearing 19 | - Activation: 20 | - Block >= 2,675,000 on Mainnet 21 | - Block >= 1,885,000 on Morden 22 | - Included EIPs: 23 | - [EIP-155](./eip-155.md) (Simple replay attack protection) 24 | - [EIP-160](./eip-160.md) (EXP cost increase) 25 | - [EIP-161](./eip-161.md) (State trie clearing) 26 | - [EIP-170](./eip-170.md) (Contract code size limit) 27 | 28 | ## References 29 | 30 | 1. https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/ 31 | 32 | ## Copyright 33 | 34 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 35 | -------------------------------------------------------------------------------- /EIPS/eip-608.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 608 3 | title: "Hardfork Meta: Tangerine Whistle" 4 | author: Alex Beregszaszi (@axic) 5 | type: Meta 6 | status: Final 7 | created: 2017-04-23 8 | requires: 150, 779 9 | --- 10 | 11 | ## Abstract 12 | 13 | This specifies the changes included in the hard fork named Tangerine Whistle (EIP 150). 14 | 15 | ## Specification 16 | 17 | - Codename: Tangerine Whistle 18 | - Aliases: EIP 150, Anti-DoS 19 | - Activation: 20 | - Block >= 2,463,000 on Mainnet 21 | - Included EIPs: 22 | - [EIP-150](./eip-150.md) (Gas cost changes for IO-heavy operations) 23 | 24 | ## References 25 | 26 | 1. https://blog.ethereum.org/2016/10/13/announcement-imminent-hard-fork-eip150-gas-cost-changes/ 27 | 2. https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/ 28 | 29 | ## Copyright 30 | 31 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 32 | -------------------------------------------------------------------------------- /EIPS/eip-609.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 609 3 | title: "Hardfork Meta: Byzantium" 4 | author: Alex Beregszaszi (@axic) 5 | type: Meta 6 | status: Final 7 | created: 2017-04-23 8 | requires: 100, 140, 196, 197, 198, 211, 214, 607, 649, 658 9 | --- 10 | 11 | ## Abstract 12 | 13 | This specifies the changes included in the hard fork named Byzantium. 14 | 15 | ## Specification 16 | 17 | - Codename: Byzantium 18 | - Aliases: Metropolis/Byzantium, Metropolis part 1 19 | - Activation: 20 | - Block >= 4,370,000 on Mainnet 21 | - Block >= 1,700,000 on Ropsten testnet 22 | - Included EIPs: 23 | - [EIP-100](./eip-100.md) (Change difficulty adjustment to target mean block time including uncles) 24 | - [EIP-140](./eip-140.md) (REVERT instruction in the Ethereum Virtual Machine) 25 | - [EIP-196](./eip-196.md) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) 26 | - [EIP-197](./eip-197.md) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) 27 | - [EIP-198](./eip-198.md) (Precompiled contract for bigint modular exponentiation) 28 | - [EIP-211](./eip-211.md) (New opcodes: RETURNDATASIZE and RETURNDATACOPY) 29 | - [EIP-214](./eip-214.md) (New opcode STATICCALL) 30 | - [EIP-649](./eip-649.md) (Difficulty Bomb Delay and Block Reward Reduction) 31 | - [EIP-658](./eip-658.md) (Embedding transaction status code in receipts) 32 | 33 | ## References 34 | 35 | 1. https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/ 36 | 37 | ## Copyright 38 | 39 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 40 | -------------------------------------------------------------------------------- /EIPS/eip-658.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 658 3 | title: Embedding transaction status code in receipts 4 | author: Nick Johnson 5 | type: Standards Track 6 | category: Core 7 | status: Final 8 | created: 2017-06-30 9 | requires: 140 10 | --- 11 | 12 | ## Abstract 13 | This EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed. 14 | 15 | ## Motivation 16 | With the introduction of the REVERT opcode in EIP140, it is no longer possible for users to assume that a transaction failed iff it consumed all gas. As a result, there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied. 17 | 18 | Full nodes can provide RPCs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical. 19 | 20 | Instead, we propose to replace the intermediate state root, already obsoleted by EIP98, with the return status (1 for success, 0 for failure). This both allows callers to determine success status, and remedies the previous omission of return data from the receipt. 21 | 22 | ## Specification 23 | For blocks where block.number >= BYZANTIUM_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success. 24 | 25 | ## Rationale 26 | This constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for Metropolis. 27 | 28 | ## Copyright 29 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 30 | -------------------------------------------------------------------------------- /EIPS/eip-689.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 689 3 | title: Address Collision of Contract Address Causes Exceptional Halt 4 | author: Yoichi Hirai 5 | type: Standards Track 6 | category: Core 7 | status: Stagnant 8 | created: 2017-08-15 9 | --- 10 | 11 | ## Simple Summary 12 | 13 | This EIP proposes to make contract creation fail on an account with nonempty code or non-zero nonce. 14 | 15 | ## Abstract 16 | 17 | Some test cases in the consensus test suite try to deploy a contract at an address already with nonempty code. Although such cases can virtually never happen on the main network before the Constantinople fork block, the test cases detected discrepancies in clients' behavior. Currently, the Yellow Paper says that the contract creation starts with the empty code and the initial nonce even in the case of address collisions. To simplify the semantics, this EIP proposes that address collisions cause failures of contract creation. 18 | 19 | ## Motivation 20 | 21 | This EIP has no practical relevance to the main net history, but simplifies testing and reasoning. 22 | 23 | This EIP has no effects after Constantinople fork because [EIP-86](./eip-86.md) contains the changes proposed in this EIP. Even before the Constantinople fork, this EIP has no practical relevance because the change is visible only in case of a hash collision of keccak256. 24 | 25 | Regarding testing, this EIP relieves clients from supporting reversion of code overwriting. 26 | 27 | Regarding reasoning, this EIP establishes an invariant that non-empty code is never modified. 28 | 29 | ## Specification 30 | 31 | If `block.number >= 0`, when a contract creation is on an account with non-zero nonce or non-empty code, the creation fails as if init code execution resulted in an exceptional halt. This applies to contract creation triggered by a contract creation transaction and by CREATE instruction. 32 | 33 | ## Rationale 34 | 35 | It seems impractical to implement never-used features just for passing tests. Client implementations will be simpler with this EIP. 36 | 37 | ## Backwards Compatibility 38 | 39 | This EIP is backwards compatible on the main network. 40 | 41 | ## Test Cases 42 | 43 | At least the BlockchainTest called `createJS\_ExampleContract\_d0g0v0\_EIP158` will distinguish clients that implement this EIP. 44 | 45 | ## Implementation 46 | 47 | ## Copyright 48 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 49 | -------------------------------------------------------------------------------- /EIPS/eip-7.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 7 3 | title: DELEGATECALL 4 | author: Vitalik Buterin (@vbuterin) 5 | status: Final 6 | type: Standards Track 7 | category: Core 8 | created: 2015-11-15 9 | --- 10 | 11 | ### Hard Fork 12 | [Homestead](./eip-606.md) 13 | 14 | ### Parameters 15 | - Activation: 16 | - Block >= 1,150,000 on Mainnet 17 | - Block >= 494,000 on Morden 18 | - Block >= 0 on future testnets 19 | 20 | ### Overview 21 | 22 | Add a new opcode, `DELEGATECALL` at `0xf4`, which is similar in idea to `CALLCODE`, except that it propagates the sender and value from the parent scope to the child scope, i.e. the call created has the same sender and value as the original call. 23 | 24 | ### Specification 25 | 26 | `DELEGATECALL`: `0xf4`, takes 6 operands: 27 | - `gas`: the amount of gas the code may use in order to execute; 28 | - `to`: the destination address whose code is to be executed; 29 | - `in_offset`: the offset into memory of the input; 30 | - `in_size`: the size of the input in bytes; 31 | - `out_offset`: the offset into memory of the output; 32 | - `out_size`: the size of the scratch pad for the output. 33 | 34 | #### Notes on gas 35 | - The basic stipend is not given; `gas` is the total amount the callee receives. 36 | - Like `CALLCODE`, account creation never happens, so the upfront gas cost is always `schedule.callGas` + `gas`. 37 | - Unused gas is refunded as normal. 38 | 39 | #### Notes on sender 40 | - `CALLER` and `VALUE` behave exactly in the callee's environment as they do in the caller's environment. 41 | 42 | #### Other notes 43 | - The depth limit of 1024 is still preserved as normal. 44 | 45 | ### Rationale 46 | 47 | Propagating the sender and value from the parent scope to the child scope makes it much easier for a contract to store another address as a mutable source of code and ''pass through'' calls to it, as the child code would execute in essentially the same environment (except for reduced gas and increased callstack depth) as the parent. 48 | 49 | Use case 1: split code to get around 3m gas barrier 50 | 51 | ```python 52 | ~calldatacopy(0, 0, ~calldatasize()) 53 | if ~calldataload(0) < 2**253: 54 | ~delegate_call(msg.gas - 10000, $ADDR1, 0, ~calldatasize(), ~calldatasize(), 10000) 55 | ~return(~calldatasize(), 10000) 56 | elif ~calldataload(0) < 2**253 * 2: 57 | ~delegate_call(msg.gas - 10000, $ADDR2, 0, ~calldatasize(), ~calldatasize(), 10000) 58 | ~return(~calldatasize(), 10000) 59 | ... 60 | ``` 61 | 62 | Use case 2: mutable address for storing the code of a contract: 63 | 64 | ```python 65 | if ~calldataload(0) / 2**224 == 0x12345678 and self.owner == msg.sender: 66 | self.delegate = ~calldataload(4) 67 | else: 68 | ~delegate_call(msg.gas - 10000, self.delegate, 0, ~calldatasize(), ~calldatasize(), 10000) 69 | ~return(~calldatasize(), 10000) 70 | ``` 71 | The child functions called by these methods can now freely reference `msg.sender` and `msg.value`. 72 | 73 | ### Possible arguments against 74 | 75 | * You can replicate this functionality by just sticking the sender into the first twenty bytes of the call data. However, this would mean that code would need to be specially compiled for delegated contracts, and would not be usable in delegated and raw contexts at the same time. 76 | -------------------------------------------------------------------------------- /EIPS/eip-801.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 801 3 | title: Canary Standard 4 | author: ligi 5 | type: Standards Track 6 | category: ERC 7 | status: Draft 8 | created: 2017-12-16 9 | --- 10 | 11 | ## Simple Summary 12 | 13 | A standard interface for canary contracts. 14 | 15 | ## Abstract 16 | 17 | The following standard allows the implementation of canaries within contracts. 18 | This standard provides basic functionality to check if a canary is alive, keeping the canary alive and optionally manage feeders. 19 | 20 | ## Motivation 21 | 22 | The canary can e.g. be used as a [warrant canary](https://en.wikipedia.org/wiki/Warrant_canary). 23 | A standard interface allows other applications to easily interface with canaries on Ethereum - e.g. for visualizing the state, automated alarms, applications to feed the canary or contracts (e.g. insurance) that use the state. 24 | 25 | ## Specification 26 | 27 | ### Methods 28 | 29 | #### isAlive() 30 | 31 | Returns if the canary was fed properly to signal e.g. that no warrant was received. 32 | 33 | ``` js 34 | function isAlive() constant returns (bool alive) 35 | ``` 36 | 37 | #### getBlockOfDeath() 38 | 39 | Returns the block the canary died. 40 | Throws if the canary is alive. 41 | 42 | ``` js 43 | function getBlockOfDeath() constant returns (uint256 block) 44 | ``` 45 | 46 | #### getType() 47 | 48 | Returns the type of the canary: 49 | 50 | * `1` = Simple (just the pure interface as defined in this ERC) 51 | * `2` = Single feeder (as defined in ERC-TBD) 52 | * `3` = Single feeder with bad food (as defined in ERC-TBD) 53 | * `4` = Multiple feeders (as defined in ERC-TBD) 54 | * `5` = Multiple mandatory feeders (as defined in ERC-TBD) 55 | * `6` = IOT (as defined in ERC-TBD) 56 | 57 | `1` might also be used for a special purpose contract that does not need a special type but still wants to expose the functions and provide events as defined in this ERC. 58 | 59 | ``` js 60 | function getType() constant returns (uint8 type) 61 | ``` 62 | 63 | ### Events 64 | 65 | #### RIP 66 | 67 | MUST trigger when the contract is called the first time after the canary died. 68 | 69 | ``` js 70 | event RIP() 71 | ``` 72 | 73 | ## Implementation 74 | 75 | TODO 76 | 77 | ## Copyright 78 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 79 | -------------------------------------------------------------------------------- /EIPS/eip-831.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 831 3 | title: URI Format for Ethereum 4 | author: ligi 5 | type: Standards Track 6 | category: ERC 7 | status: Stagnant 8 | created: 2018-01-15 9 | --- 10 | 11 | ## Simple Summary 12 | 13 | A standard way of creating Ethereum URIs for various use-cases. 14 | 15 | ## Abstract 16 | 17 | URIs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URI format allows for instant invocation of the user's preferred wallet application. 18 | 19 | ## Specification 20 | 21 | ### Syntax 22 | 23 | Ethereum URIs contain "ethereum" in their schema (protocol) part and are constructed as follows: 24 | 25 | request = "ethereum" ":" [ prefix "-" ] payload 26 | prefix = STRING 27 | payload = STRING 28 | 29 | ### Semantics 30 | 31 | `prefix` is optional and defines the use-case for this URI. If no prefix is given: "pay-" is assumed to be concise and ensure backward compatibility to ERC-67. When the prefix is omitted, the payload must start with `0x`. Also prefixes must not start with `0x`. So starting with `0x` can be used as a clear signal that there is no prefix. 32 | 33 | `payload` is mandatory and the content depends on the prefix. Structuring of the content is defined in the ERC for the specific use-case and not in the scope of this document. One example is ERC-681 for the pay- prefix. 34 | 35 | 36 | ## Rationale 37 | 38 | The need for this ERC emerged when refining ERC-681. We need a container that does not carry the weight of the use-cases. ERC-67 was the first attempt on defining Ethereum-URIs. This ERC tries to keep backward compatibility and not break existing things. This means ERC-67 URIs should still be valid and readable. Only if the prefix feature is used, ERC-67 parsers might break. No way was seen to avoid this and innovate on the same time. This is also the reason this open prefix approach was chosen to being able to adopt to future use-cases and not block the whole "ethereum:" scheme for a limited set of use-cases that existed at the time of writing this. 39 | 40 | ## References 41 | 42 | 1. ERC-681, ./eip-681.md 43 | 2. ERC-67, ./eip-67.md 44 | 45 | ## Copyright 46 | 47 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 48 | -------------------------------------------------------------------------------- /EIPS/eip-858.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 858 3 | title: Reduce block reward and delay difficulty bomb 4 | author: Carl Larson 5 | type: Standards Track 6 | category: Core 7 | status: Stagnant 8 | created: 2018-01-29 9 | --- 10 | 11 | ## Simple Summary 12 | Reduce the block reward to 1 ETH and delay the difficulty bomb. 13 | 14 | ## Abstract 15 | The current public Ethereum network has a hashrate that corresponds to a tremendous level of energy consumption. As this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. At this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of ETH mining. Unchecked growth in hashrate is also counterproductive from a security standpoint. 16 | Recent research developments also now time the switch to POS as sometime in 2019 and as a result there is need to further delay the difficulty bomb so the network doesn't grind to a halt. 17 | 18 | 19 | ## Motivation 20 | The current public Ethereum network has a hashrate of 296 TH/s. This hashrate corresponds to a power usage of roughly [1 TW](../assets/eip-858/calculations.md) and yearly energy consumption of 8.8 TWh (roughly 0.04% of [total](https://en.wikipedia.org/wiki/List_of_countries_by_electricity_consumption) global electricity consumption). A future switch to full Proof of Stake will solve this issue entirely. Yet that switch remains enough in the future that action should be taken in the interim to limit excess harmful side affects of the present network. 21 | 22 | ## Specification 23 | 24 | Delay difficulty bomb by 2,000,000 blocks 25 | Adjust block, uncle, and nephew rewards to reflect a new block reward of 1 ETH. 26 | 27 | ## Rationale 28 | This will delay the difficulty bomb by roughly a year. The difficulty bomb remains a community supported mechanism to aid a future transition to POS. 29 | 30 | The network hashrate provides security by reducing the likelihood that an adversary could mount a 51% attack. A static block reward means that factors (price) may be such that participation in mining grows unchecked. This growth may be counterproductive and work to also grow and potential pool of adversaries. The means we have to arrest this growth is to reduce the appeal of mining and the most direct way to do that is to reduce the block reward. 31 | 32 | ## Backwards Compatibility 33 | This EIP is consensus incompatible with the current public Ethereum chain and would cause a hard fork when enacted. The resulting fork would allow users to chose between two chains: a chain with a block reward of 1 ETH/block and another with a block reward of 3 ETH/block. This is a good choice to allow users to make. In addition, the difficulty bomb would be delayed - ensuring the network would not grind to a halt. 34 | 35 | ## Test Cases 36 | Tests have, as yet, not been completed. 37 | 38 | ## Implementation 39 | No implementation including both block reward and difficulty adjustment is currently available. 40 | 41 | ## Copyright 42 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 43 | -------------------------------------------------------------------------------- /EIPS/eip-868.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 868 3 | title: Node Discovery v4 ENR Extension 4 | author: Felix Lange 5 | type: Standards Track 6 | category: Networking 7 | status: Final 8 | created: 2018-02-02 9 | requires: 8, 778 10 | discussions-to: https://github.com/ethereum/devp2p/issues/44 11 | --- 12 | 13 | # Abstract 14 | 15 | This EIP defines an extension to Node Discovery Protocol v4 to enable authoritative 16 | resolution of [Ethereum Node Records (ENR)](./eip-778.md). 17 | 18 | # Motivation 19 | 20 | To bridge current and future discovery networks and to aid the implementation of other 21 | relay mechanisms for ENR such as DNS, we need a way to request the most up-to-date version 22 | of a node record. This EIP provides a way to request it using the existing discovery 23 | protocol. 24 | 25 | # Specification 26 | 27 | Implementations of Node Discovery Protocol v4 should support two new packet types, a 28 | request and reply of the node record. The existing ping and pong packets are extended with 29 | a new field containing the sequence number of the ENR. 30 | 31 | ### Ping Packet (0x01) 32 | 33 | ```text 34 | packet-data = [version, from, to, expiration, enr-seq] 35 | ``` 36 | 37 | `enr-seq` is the current sequence number of the sending node's record. All other fields 38 | retain their existing meaning. 39 | 40 | ### Pong Packet (0x02) 41 | 42 | ```text 43 | packet-data = [to, ping-hash, expiration, enr-seq] 44 | ``` 45 | 46 | `enr-seq` is the current sequence number of the sending node's record. All other fields 47 | retain their existing meaning. 48 | 49 | ### ENRRequest Packet (0x05) 50 | 51 | ```text 52 | packet-data = [ expiration ] 53 | ``` 54 | 55 | When a packet of this type is received, the node should reply with an ENRResponse packet 56 | containing the current version of its record. 57 | 58 | To guard against amplification attacks, the sender of ENRRequest should have replied to a 59 | ping packet recently (just like for FindNode). The `expiration` field, a UNIX timestamp, 60 | should be handled as for all other existing packets i.e. no reply should be sent if it 61 | refers to a time in the past. 62 | 63 | ### ENRResponse Packet (0x06) 64 | 65 | ```text 66 | packet-data = [ request-hash, ENR ] 67 | ``` 68 | 69 | This packet is the response to ENRRequest. 70 | 71 | - `request-hash` is the hash of the entire ENRRequest packet being replied to. 72 | - `ENR` is the node record. 73 | 74 | The recipient of the packet should verify that the node record is signed by node who sent 75 | ENRResponse. 76 | 77 | ## Resolving Records 78 | 79 | To resolve the current record of a node public key, perform a recursive Kademlia lookup 80 | using the FindNode, Neighbors packets. When the node is found, send ENRRequest to it and 81 | return the record from the response. 82 | 83 | # Copyright 84 | 85 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 86 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | # Hello! This is where you manage which Jekyll version is used to run. 4 | # When you want to use a different version, change it below, save the 5 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so: 6 | # 7 | # bundle exec jekyll serve 8 | # 9 | 10 | # This is the default theme for new Jekyll sites. You may change this to anything you like. 11 | gem "minima", "~> 2.0" 12 | 13 | # If you have any plugins, put them here! 14 | group :jekyll_plugins do 15 | gem "jekyll-feed", "~> 0.11" 16 | gem "github-pages", "206" 17 | end 18 | 19 | # Windows does not include zoneinfo files, so bundle the tzinfo-data gem 20 | gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby] 21 | 22 | # Performance-booster for watching directories on Windows 23 | gem "wdm", "~> 0.1.0" if Gem.win_platform? 24 | 25 | gem "html-proofer", '>=3.3.1' 26 | 27 | gem "eip_validator", ">=0.8.2" 28 | -------------------------------------------------------------------------------- /ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 2 | ATTENTION! If you would like to submit an EIP and it has already been written as a draft (see the [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) for an example), please submit it as a [Pull Request](https://github.com/ethereum/EIPs/pulls). 3 | 4 | If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion. Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive. 5 | 6 | Keep in mind the following guidelines from [EIP-1](./eip-1.md): 7 | 8 | > Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this. 9 | 10 | > Vetting an idea publicly before going as far as writing a EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used. 11 | 12 | > Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft EIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft EIP to make properly formatted, of high quality, and to address initial concerns about the proposal. 13 | -------------------------------------------------------------------------------- /PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md 2 | 3 | We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met: 4 | 5 | - The PR edits only existing draft PRs. 6 | - The build passes. 7 | - Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside . 8 | - If matching on email address, the email address is the one publicly listed on your GitHub profile. 9 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Ethereum Improvement Proposals (EIPs) 2 | 3 | [![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/ethereum/EIPs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge) 4 | 5 | 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/).** 6 | 7 | **Before you initiate a pull request**, please read the [EIP-1](https://eips.ethereum.org/EIPS/eip-1) process document. 8 | 9 | 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). 10 | 11 | ## Project Goal 12 | 13 | The Ethereum Improvement Proposals repository exists as a place to share concrete proposals with potential users of the proposal and the Ethereum community at large. 14 | 15 | ## Preferred Citation Format 16 | 17 | The canonical URL for a EIP that has achieved draft status at any point is at https://eips.ethereum.org/. For example, the canonical URL for EIP-1 is https://eips.ethereum.org/EIPS/eip-1. 18 | 19 | Please consider anything which is not published on https://eips.ethereum.org/ as a working paper. 20 | 21 | And please consider anything published at https://eips.ethereum.org/ with a status of "draft" as an incomplete draft. 22 | 23 | # Validation 24 | 25 | 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). 26 | 27 | It is possible to run the EIP validator locally: 28 | ```sh 29 | cargo install eipv 30 | eipv 31 | ``` 32 | 33 | # Automerger 34 | 35 | The EIP repository contains an "auto merge" feature to ease the workload for EIP editors. If a change is made via a PR to a draft EIP, then the authors of the EIP can GitHub approve the change to have it auto-merged. This is handled by the [EIP-Bot](https://github.com/ethereum/EIP-Bot). 36 | 37 | # Local development 38 | 39 | ## Prerequisites 40 | 41 | 1. Open Terminal. 42 | 43 | 2. Check whether you have Ruby 2.1.0 or higher installed: 44 | 45 | ```sh 46 | $ ruby --version 47 | ``` 48 | 49 | 3. If you don't have Ruby installed, install Ruby 2.1.0 or higher. 50 | 51 | 4. Install Bundler: 52 | 53 | ```sh 54 | $ gem install bundler 55 | ``` 56 | 57 | 5. Install dependencies: 58 | 59 | ```sh 60 | $ bundle install 61 | ``` 62 | 63 | ## Build your local Jekyll site 64 | 65 | 1. Bundle assets and start the server: 66 | 67 | ```sh 68 | $ bundle exec jekyll serve 69 | ``` 70 | 71 | 2. Preview your local Jekyll site in your web browser at `http://localhost:4000`. 72 | 73 | More information on Jekyll and GitHub pages [here](https://help.github.com/en/enterprise/2.14/user/articles/setting-up-your-github-pages-site-locally-with-jekyll). 74 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | # Welcome to Jekyll! 2 | # 3 | # This config file is meant for settings that affect your whole blog, values 4 | # which you are expected to set up once and rarely edit after that. If you find 5 | # yourself editing this file very often, consider using Jekyll's data files 6 | # feature for the data you need to update frequently. 7 | # 8 | # For technical reasons, this file is *NOT* reloaded automatically when you use 9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process. 10 | 11 | # Site settings 12 | # These are used to personalize your new site. If you look in the HTML files, 13 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on. 14 | # You can create any custom variable you would like, and they will be accessible 15 | # in the templates via {{ site.myvariable }}. 16 | title: Ethereum Improvement Proposals 17 | description: >- 18 | Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum 19 | platform, including core protocol specifications, client APIs, and contract 20 | standards. 21 | url: "https://eips.ethereum.org" 22 | github_username: ethereum 23 | 24 | header_pages: 25 | - all.html 26 | - core.html 27 | - networking.html 28 | - interface.html 29 | - erc.html 30 | - meta.html 31 | - informational.html 32 | 33 | # Build settings 34 | highlighter: rouge 35 | markdown: kramdown 36 | theme: minima 37 | kramdown: 38 | parse_block_html: false 39 | # This is the default, but be explicit as some EIPs depend on it 40 | auto_ids: true 41 | # This is to ensure more determistic behaviour 42 | auto_id_stripping: true 43 | syntax_highlighter: rouge 44 | 45 | permalink: /:slug 46 | 47 | defaults: 48 | - 49 | scope: 50 | path: "EIPS" 51 | values: 52 | layout: "eip" 53 | 54 | exclude: 55 | - .github 56 | - Gemfile 57 | - Gemfile.lock 58 | - node_modules 59 | - vendor/bundle/ 60 | - vendor/cache/ 61 | - vendor/gems/ 62 | - vendor/ruby/ 63 | - eip-template.md 64 | - ISSUE_TEMPLATE.md 65 | - PULL_REQUEST_TEMPLATE.md 66 | - README.md 67 | -------------------------------------------------------------------------------- /_data/statuses.yaml: -------------------------------------------------------------------------------- 1 | - Living 2 | - Final 3 | - Last Call 4 | - Review 5 | - Draft 6 | - Stagnant 7 | - Withdrawn 8 | -------------------------------------------------------------------------------- /_includes/authorlist.html: -------------------------------------------------------------------------------- 1 | {%- assign authors=include.authors|split:"," -%} 2 | {%- for author in authors -%} 3 | {%- if author contains "<" -%} 4 | {%- assign authorparts=author|split:"<" -%} 5 | "}}">{{authorparts[0]|strip}} 6 | {%- elsif author contains "(@" -%} 7 | {%- assign authorparts=author|split:"(@" -%} 8 | {{authorparts[0]|strip}} 9 | {%- else -%} 10 | {{author}} 11 | {%- endif -%} 12 | {% if forloop.last == false %}, {% endif %} 13 | {%- endfor -%} 14 | -------------------------------------------------------------------------------- /_includes/eipnums.html: -------------------------------------------------------------------------------- 1 | {% assign eips=include.eips|split:"," %} 2 | {% for eipnum in eips %} 3 | {{eipnum|strip}}{% if forloop.last == false %}, {% endif %} 4 | {% endfor %} 5 | -------------------------------------------------------------------------------- /_includes/eiptable.html: -------------------------------------------------------------------------------- 1 | 10 | {% for status in site.data.statuses %} 11 | {% assign eips = include.eips|where:"status",status|sort:"eip" %} 12 | {% assign count = eips|size %} 13 | {% if count > 0 %} 14 |

{{status}}

15 | 16 | 17 | {% if status == "Last Call" %} 18 | 19 | 20 | {% else %} 21 | 22 | {% endif %} 23 | 24 | {% for page in eips %} 25 | 26 | 27 | {% if status == "Last Call" and page.last-call-deadline != undefined %} 28 | 29 | {% endif %} 30 | 31 | 32 | 33 | {% endfor %} 34 |
NumberReview endsTitleAuthor
NumberTitleAuthor
{{page.eip|xml_escape}}{{ page.last-call-deadline | xml_escape }}{{page.title|xml_escape}}{% include authorlist.html authors=page.author %}
35 | {% endif %} 36 | {% endfor %} 37 | -------------------------------------------------------------------------------- /_includes/head.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | {% if page.layout == "eip" %} 6 | EIP-{{ page.eip }}: {{ page.title | escape }} 7 | 8 | 9 | 10 | 11 | {% else %} 12 | {{ page.title | escape }} | {{site.title}} 13 | 17 | 18 | 19 | 20 | {% endif %} 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 37 | 38 | {%- feed_meta -%} 39 | 40 | 41 | -------------------------------------------------------------------------------- /all.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: All 4 | --- 5 | 6 | {% include eiptable.html eips=site.pages %} 7 | -------------------------------------------------------------------------------- /assets/css/style.scss: -------------------------------------------------------------------------------- 1 | --- 2 | # Only the main Sass file needs front matter (the dashes are enough) 3 | --- 4 | 5 | @import 'minima'; 6 | 7 | .site-header { 8 | .wrapper { 9 | display: flex; 10 | flex-direction: column; 11 | align-items: center; 12 | } 13 | } 14 | 15 | .page-content { 16 | a.anchor-link { 17 | width: 16px; 18 | height: 16px; 19 | display: inline-block; 20 | margin-left: -22px; 21 | &:hover { 22 | background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' class='anchor-link-icon' viewBox='0 0 16 16' version='1.1' width='16' height='16' aria-hidden='true'%3E%3Cpath fill-rule='evenodd' d='M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z'%3E%3C/path%3E%3C/svg%3E"); 23 | } 24 | } 25 | } 26 | 27 | main.page-content { 28 | div.wrapper { 29 | max-width: unset; 30 | } 31 | } 32 | 33 | .status { 34 | border-radius: 6px; 35 | line-height: 18px; 36 | overflow: hidden; 37 | padding: 12px; 38 | display: inline-block; 39 | margin-bottom: 15px; 40 | } 41 | 42 | .draft { 43 | @extend .status; 44 | background-color: #fffbea; 45 | border: solid 1px #f1c40f; 46 | } 47 | 48 | .review { 49 | @extend .status; 50 | background-color: #f0f7fb; 51 | border: solid 1px #3498db; 52 | } 53 | 54 | .lastcall { 55 | @extend .status; 56 | background-color: #e7f6f0; 57 | border: solid 1px #27ae60; 58 | } 59 | 60 | .stagnant { 61 | @extend .status; 62 | background-color: #ffdead; 63 | border: solid 1px #ff6700; 64 | } 65 | 66 | .withdrawn { 67 | @extend .status; 68 | background-color: #f9e7e5; 69 | border: solid 1px #c0392b; 70 | } 71 | -------------------------------------------------------------------------------- /assets/eip-1/EIP-process-update.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1/EIP-process-update.jpg -------------------------------------------------------------------------------- /assets/eip-1/EIP-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1/EIP-process.png -------------------------------------------------------------------------------- /assets/eip-1/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1/process.png -------------------------------------------------------------------------------- /assets/eip-107/authorization-locked.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-107/authorization-locked.png -------------------------------------------------------------------------------- /assets/eip-107/authorization-password.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-107/authorization-password.png -------------------------------------------------------------------------------- /assets/eip-107/authorization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-107/authorization.png -------------------------------------------------------------------------------- /assets/eip-1175/wallet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1175/wallet.png -------------------------------------------------------------------------------- /assets/eip-1175/workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1175/workflow.png -------------------------------------------------------------------------------- /assets/eip-1207/rationale.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1207/rationale.png -------------------------------------------------------------------------------- /assets/eip-1283/state.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1283/state.png -------------------------------------------------------------------------------- /assets/eip-1438/avatar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1438/avatar.png -------------------------------------------------------------------------------- /assets/eip-1438/intro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1438/intro.png -------------------------------------------------------------------------------- /assets/eip-1438/wallet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1438/wallet.png -------------------------------------------------------------------------------- /assets/eip-1613/sequence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1613/sequence.png -------------------------------------------------------------------------------- /assets/eip-1822/proxy-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1822/proxy-diagram.png -------------------------------------------------------------------------------- /assets/eip-1884/BALANCE-run3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1884/BALANCE-run3.png -------------------------------------------------------------------------------- /assets/eip-1884/SLOAD-run3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1884/SLOAD-run3.png -------------------------------------------------------------------------------- /assets/eip-1884/geth_processing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1884/geth_processing.png -------------------------------------------------------------------------------- /assets/eip-1884/run3.total-bars-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1884/run3.total-bars-5.png -------------------------------------------------------------------------------- /assets/eip-1884/run3.total-bars-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1884/run3.total-bars-6.png -------------------------------------------------------------------------------- /assets/eip-1901/OpenRPC_structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1901/OpenRPC_structure.png -------------------------------------------------------------------------------- /assets/eip-1901/eth-generated-client-openrpc.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1901/eth-generated-client-openrpc.gif -------------------------------------------------------------------------------- /assets/eip-1901/eth-playground-openrpc.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1901/eth-playground-openrpc.gif -------------------------------------------------------------------------------- /assets/eip-1901/inspector-mock-server-openrpc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1901/inspector-mock-server-openrpc.png -------------------------------------------------------------------------------- /assets/eip-1901/multi-geth-use-case.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-1901/multi-geth-use-case.png -------------------------------------------------------------------------------- /assets/eip-2025/block_rewards_distribution.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2025/block_rewards_distribution.png -------------------------------------------------------------------------------- /assets/eip-2025/loan_state.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2025/loan_state.png -------------------------------------------------------------------------------- /assets/eip-2255/facebook_permissions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2255/facebook_permissions.png -------------------------------------------------------------------------------- /assets/eip-2255/log_in_with_apple.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2255/log_in_with_apple.jpeg -------------------------------------------------------------------------------- /assets/eip-2255/permissions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2255/permissions.png -------------------------------------------------------------------------------- /assets/eip-2255/permissions_adventure.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2255/permissions_adventure.gif -------------------------------------------------------------------------------- /assets/eip-2535/DiamondDiagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2535/DiamondDiagram.png -------------------------------------------------------------------------------- /assets/eip-2535/diamondstorage1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2535/diamondstorage1.png -------------------------------------------------------------------------------- /assets/eip-2535/facetreuse.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2535/facetreuse.png -------------------------------------------------------------------------------- /assets/eip-2565/Complexity_Regression.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2565/Complexity_Regression.png -------------------------------------------------------------------------------- /assets/eip-2565/GQuad_Change.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2565/GQuad_Change.png -------------------------------------------------------------------------------- /assets/eip-2615/concept.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2615/concept.png -------------------------------------------------------------------------------- /assets/eip-2615/mortgage-sequential.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2615/mortgage-sequential.jpg -------------------------------------------------------------------------------- /assets/eip-2615/rental-sequential.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2615/rental-sequential.jpg -------------------------------------------------------------------------------- /assets/eip-2680/sha256-384-512.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2680/sha256-384-512.pdf -------------------------------------------------------------------------------- /assets/eip-2771/example-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2771/example-flow.png -------------------------------------------------------------------------------- /assets/eip-2848/presentation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2848/presentation.pdf -------------------------------------------------------------------------------- /assets/eip-2917/erc-reward-formula.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2917/erc-reward-formula.png -------------------------------------------------------------------------------- /assets/eip-2980/Finma-ICO-Guidelines.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Finma-ICO-Guidelines.pdf -------------------------------------------------------------------------------- /assets/eip-2980/Swiss-Confederation-AMLA.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Swiss-Confederation-AMLA.pdf -------------------------------------------------------------------------------- /assets/eip-2980/Swiss-Confederation-BA.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Swiss-Confederation-BA.pdf -------------------------------------------------------------------------------- /assets/eip-2980/Swiss-Confederation-CISA.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Swiss-Confederation-CISA.pdf -------------------------------------------------------------------------------- /assets/eip-2980/Swiss-Confederation-FINIA.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Swiss-Confederation-FINIA.pdf -------------------------------------------------------------------------------- /assets/eip-2980/Swiss-Confederation-FINSA.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Swiss-Confederation-FINSA.pdf -------------------------------------------------------------------------------- /assets/eip-2980/Swiss-Confederation-FMIA.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Swiss-Confederation-FMIA.pdf -------------------------------------------------------------------------------- /assets/eip-2980/Swiss-Confederation-SESTA.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-2980/Swiss-Confederation-SESTA.pdf -------------------------------------------------------------------------------- /assets/eip-3005/meta-txs-directly-to-token-smart-contract.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3005/meta-txs-directly-to-token-smart-contract.png -------------------------------------------------------------------------------- /assets/eip-3068/2012-685_Square_Root_Even_Ext.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/2012-685_Square_Root_Even_Ext.pdf -------------------------------------------------------------------------------- /assets/eip-3068/2015-1027_exTNFS.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/2015-1027_exTNFS.pdf -------------------------------------------------------------------------------- /assets/eip-3068/2016-1102_Assessing_NFS_Advances.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/2016-1102_Assessing_NFS_Advances.pdf -------------------------------------------------------------------------------- /assets/eip-3068/2017-334.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/2017-334.pdf -------------------------------------------------------------------------------- /assets/eip-3068/2019-403_BLS12_H2C.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/2019-403_BLS12_H2C.pdf -------------------------------------------------------------------------------- /assets/eip-3068/latincrypt12.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/latincrypt12.pdf -------------------------------------------------------------------------------- /assets/eip-3068/madnet.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/madnet.pdf -------------------------------------------------------------------------------- /assets/eip-3068/weilsigs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3068/weilsigs.pdf -------------------------------------------------------------------------------- /assets/eip-3074/auth-msg-multi-call.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3074/auth-msg-multi-call.png -------------------------------------------------------------------------------- /assets/eip-3074/auth-msg.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3074/auth-msg.png -------------------------------------------------------------------------------- /assets/eip-3267/contracts/DAOInterface.sol: -------------------------------------------------------------------------------- 1 | // SPDX-License-Identifier: LGPL-3.0-or-later 2 | pragma solidity ^0.7.1; 3 | 4 | /// @notice The "DAO plugin" interface. 5 | /// @author Victor Porton 6 | /// @notice Not audited, not enough tested. 7 | interface DAOInterface { 8 | /// Check if `msg.sender` is an attorney allowed to restore a given account. 9 | function checkAllowedRestoreAccount(address _oldAccount, address _newAccount) external; 10 | 11 | /// Check if `msg.sender` is an attorney allowed to unrestore a given account. 12 | function checkAllowedUnrestoreAccount(address _oldAccount, address _newAccount) external; 13 | } 14 | -------------------------------------------------------------------------------- /assets/eip-3267/contracts/DefaultDAOInterface.sol: -------------------------------------------------------------------------------- 1 | // SPDX-License-Identifier: LGPL-3.0-or-later 2 | pragma solidity ^0.7.1; 3 | import "./DAOInterface.sol"; 4 | 5 | /// @notice "Default" contract for `DAOInterface`. 6 | /// @author Victor Porton 7 | /// @notice Not audited, not enough tested. 8 | contract DefaultDAOInterface is DAOInterface { 9 | function checkAllowedRestoreAccount(address /*_oldAccount*/, address /*_newAccount*/) external pure override { 10 | revert("unimplemented"); 11 | } 12 | 13 | function checkAllowedUnrestoreAccount(address /*_oldAccount*/, address /*_newAccount*/) external pure override { 14 | revert("unimplemented"); 15 | } 16 | } 17 | -------------------------------------------------------------------------------- /assets/eip-3267/contracts/ERC1155/ERC1155TokenReceiver.sol: -------------------------------------------------------------------------------- 1 | // SPDX-License-Identifier: LGPL-3.0-or-later 2 | pragma solidity ^0.7.1; 3 | 4 | import "./IERC1155TokenReceiver.sol"; 5 | import "@openzeppelin/contracts/introspection/ERC165.sol"; 6 | 7 | abstract contract ERC1155TokenReceiver is ERC165, IERC1155TokenReceiver { 8 | constructor() { 9 | _registerInterface( 10 | ERC1155TokenReceiver(0).onERC1155Received.selector ^ 11 | ERC1155TokenReceiver(0).onERC1155BatchReceived.selector 12 | ); 13 | } 14 | } 15 | -------------------------------------------------------------------------------- /assets/eip-3267/contracts/ERC1155/IERC1155.sol: -------------------------------------------------------------------------------- 1 | // SPDX-License-Identifier: LGPL-3.0-or-later 2 | pragma solidity ^0.7.1; 3 | 4 | import "@openzeppelin/contracts/introspection/IERC165.sol"; 5 | 6 | /** 7 | @title ERC-1155 Multi Token Standard basic interface 8 | @dev See https://eips.ethereum.org/EIPS/eip-1155 9 | */ 10 | abstract contract IERC1155 is IERC165 { 11 | event TransferSingle(address indexed operator, address indexed from, address indexed to, uint256 id, uint256 value); 12 | 13 | event TransferBatch(address indexed operator, address indexed from, address indexed to, uint256[] ids, uint256[] values); 14 | 15 | event ApprovalForAll(address indexed owner, address indexed operator, bool approved); 16 | 17 | event URI(string value, uint256 indexed id); 18 | 19 | function balanceOf(address owner, uint256 id) public view virtual returns (uint256); 20 | 21 | function balanceOfBatch(address[] memory owners, uint256[] memory ids) public view virtual returns (uint256[] memory); 22 | 23 | function setApprovalForAll(address operator, bool approved) external virtual; 24 | 25 | function isApprovedForAll(address owner, address operator) external view virtual returns (bool); 26 | 27 | function safeTransferFrom(address from, address to, uint256 id, uint256 value, bytes calldata data) external virtual; 28 | 29 | function safeBatchTransferFrom(address from, address to, uint256[] calldata ids, uint256[] calldata values, bytes calldata data) external virtual; 30 | } 31 | -------------------------------------------------------------------------------- /assets/eip-3267/contracts/ERC1155/IERC1155TokenReceiver.sol: -------------------------------------------------------------------------------- 1 | // SPDX-License-Identifier: LGPL-3.0-or-later 2 | pragma solidity ^0.7.1; 3 | 4 | import "@openzeppelin/contracts/introspection/IERC165.sol"; 5 | 6 | /** 7 | @title ERC-1155 Multi Token Receiver Interface 8 | @dev See https://eips.ethereum.org/EIPS/eip-1155 9 | */ 10 | abstract contract IERC1155TokenReceiver is IERC165 { 11 | 12 | /** 13 | @dev Handles the receipt of a single ERC1155 token type. This function is 14 | called at the end of a `safeTransferFrom` after the balance has been updated. 15 | To accept the transfer, this must return 16 | `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` 17 | (i.e. 0xf23a6e61, or its own function selector). 18 | @param operator The address which initiated the transfer (i.e. msg.sender) 19 | @param from The address which previously owned the token 20 | @param id The ID of the token being transferred 21 | @param value The amount of tokens being transferred 22 | @param data Additional data with no specified format 23 | @return `bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)"))` if transfer is allowed 24 | */ 25 | function onERC1155Received( 26 | address operator, 27 | address from, 28 | uint256 id, 29 | uint256 value, 30 | bytes calldata data 31 | ) 32 | external virtual 33 | returns(bytes4); 34 | 35 | /** 36 | @dev Handles the receipt of a multiple ERC1155 token types. This function 37 | is called at the end of a `safeBatchTransferFrom` after the balances have 38 | been updated. To accept the transfer(s), this must return 39 | `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` 40 | (i.e. 0xbc197c81, or its own function selector). 41 | @param operator The address which initiated the batch transfer (i.e. msg.sender) 42 | @param from The address which previously owned the token 43 | @param ids An array containing ids of each token being transferred (order and length must match values array) 44 | @param values An array containing amounts of each token being transferred (order and length must match ids array) 45 | @param data Additional data with no specified format 46 | @return `bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))` if transfer is allowed 47 | */ 48 | function onERC1155BatchReceived( 49 | address operator, 50 | address from, 51 | uint256[] calldata ids, 52 | uint256[] calldata values, 53 | bytes calldata data 54 | ) 55 | external virtual 56 | returns(bytes4); 57 | } 58 | -------------------------------------------------------------------------------- /assets/eip-3267/contracts/ERC1155/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | sections: 3 | - title: Core 4 | contracts: 5 | - IERC1155 6 | - ERC1155 7 | - IERC1155TokenReceiver 8 | --- 9 | 10 | This set of interfaces and contracts are all related to the [ERC1155 Multi Token Standard](https://eips.ethereum.org/EIPS/eip-1155). 11 | 12 | The EIP consists of two interfaces which fulfill different roles, found here as `IERC1155` and `IERC1155TokenReceiver`. Only `IERC1155` is required for a contract to be ERC1155 compliant. The basic functionality is implemented in `ERC1155`. 13 | -------------------------------------------------------------------------------- /assets/eip-3267/contracts/README.md: -------------------------------------------------------------------------------- 1 | This directory contains contract sources for EIP 3267 draft. 2 | 3 | The audit of the contracts was paid for, now it is in progress. 4 | (There are some FIXME/TODO comments for the auditors.) 5 | 6 | The contracts are to be compiled with Solidity 0.7.6. 7 | 8 | Dependencies (Node.js packages): 9 | 10 | - @openzeppelin/contracts 3.3.0 11 | - abdk-libraries-solidity 2.4.0 12 | 13 | The contracts to be deployed are: 14 | - SalaryWithDAO 15 | - DefaultDAOInterface 16 | 17 | The sources: 18 | - [ERC1155/ERC1155.sol](./ERC1155/ERC1155.sol) 19 | - [ERC1155/ERC1155TokenReceiver.sol](./ERC1155/ERC1155TokenReceiver.sol) 20 | - [ERC1155/ERC1155WithTotals.sol](./ERC1155/ERC1155WithTotals.sol) 21 | - [ERC1155/IERC1155.sol](./ERC1155/IERC1155.sol) 22 | - [ERC1155/IERC1155TokenReceiver.sol](./ERC1155/IERC1155TokenReceiver.sol) 23 | - [BaseBidOnAddresses.sol](./BaseBidOnAddresses.sol) 24 | - [BaseLock.sol](./BaseLock.sol) 25 | - [BaseRestorableSalary.sol](./BaseRestorableSalary.sol) 26 | - [BaseSalary.sol](./BaseSalary.sol) 27 | - [BidOnAddresses.sol](./BidOnAddresses.sol) 28 | - [DAOInterface.sol](./DAOInterface.sol) 29 | - [DefaultDAOInterface.sol](./DefaultDAOInterface.sol) 30 | - [Salary.sol](./Salary.sol) 31 | - [SalaryWithDAO.sol](./SalaryWithDAO.sol) 32 | -------------------------------------------------------------------------------- /assets/eip-3267/contracts/Salary.sol: -------------------------------------------------------------------------------- 1 | // SPDX-License-Identifier: LGPL-3.0-or-later 2 | pragma solidity ^0.7.1; 3 | import "./BaseSalary.sol"; 4 | 5 | /// @title "Salary" that is paid one token per second using minted conditionals. 6 | /// @author Victor Porton 7 | /// @notice Not audited, not enough tested. 8 | contract Salary is BaseSalary { 9 | /// @param _uri The ERC-1155 token URI. 10 | constructor(string memory _uri) BaseSalary(_uri) { } 11 | 12 | /// Register a salary recipient. 13 | /// 14 | /// Can be called both before or after the oracle finish. However registering after the finish is useless. 15 | /// 16 | /// Anyone can register anyone (useful for robots registering a person). 17 | /// 18 | /// Registering another person is giving him money against his will (forcing to hire bodyguards, etc.), 19 | /// but if one does not want, he can just not associate this address with his identity in his publications. 20 | /// @param _customer The original address. 21 | /// @param _oracleId The oracle ID. 22 | /// @param _data The current data. 23 | function registerCustomer(address _customer, uint64 _oracleId, bytes calldata _data) 24 | virtual public returns (uint256) 25 | { 26 | return _registerCustomer(_customer, _oracleId, _data); 27 | } 28 | } -------------------------------------------------------------------------------- /assets/eip-3267/science-salaries.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3267/science-salaries.pdf -------------------------------------------------------------------------------- /assets/eip-3450/lagrange.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3450/lagrange.gif -------------------------------------------------------------------------------- /assets/eip-3607/geth.diff: -------------------------------------------------------------------------------- 1 | diff --git a/core/state_transition.go b/core/state_transition.go 2 | index 18777d8d4..3b25155c6 100644 3 | --- a/core/state_transition.go 4 | +++ b/core/state_transition.go 5 | @@ -219,6 +219,11 @@ func (st *StateTransition) preCheck() error { 6 | st.msg.From().Hex(), msgNonce, stNonce) 7 | } 8 | } 9 | + // Make sure the sender is an EOA 10 | + if codeHash := st.state.GetCodeHash(st.msg.From()); codeHash != emptyCodeHash { 11 | + return fmt.Errorf("%w: address %v, codehash: %s", ErrSenderNoEOA, 12 | + st.msg.From().Hex(), codeHash) 13 | + } 14 | // Make sure that transaction feeCap is greater than the baseFee (post london) 15 | if st.evm.ChainConfig().IsLondon(st.evm.Context.BlockNumber) { 16 | if l := st.feeCap.BitLen(); l > 256 { -------------------------------------------------------------------------------- /assets/eip-3770/EIP-3770-examples.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-3770/EIP-3770-examples.png -------------------------------------------------------------------------------- /assets/eip-4337/image1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-4337/image1.png -------------------------------------------------------------------------------- /assets/eip-4337/image2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-4337/image2.png -------------------------------------------------------------------------------- /assets/eip-4396/degradation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-4396/degradation.png -------------------------------------------------------------------------------- /assets/eip-4396/degradation_buffers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-4396/degradation_buffers.png -------------------------------------------------------------------------------- /assets/eip-4396/degradation_elasticity.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-4396/degradation_elasticity.png -------------------------------------------------------------------------------- /assets/eip-4396/new_formula.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-4396/new_formula.png -------------------------------------------------------------------------------- /assets/eip-4396/old_formula.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-4396/old_formula.png -------------------------------------------------------------------------------- /assets/eip-712/eth_sign.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-712/eth_sign.png -------------------------------------------------------------------------------- /assets/eip-712/eth_signTypedData.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-712/eth_signTypedData.png -------------------------------------------------------------------------------- /assets/eip-747/add-token-prompt.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-747/add-token-prompt.gif -------------------------------------------------------------------------------- /assets/eip-747/add-token-prompt2.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-747/add-token-prompt2.gif -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-beige-1024px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-beige-1024px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-beige-192px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-beige-192px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-beige-2048px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-beige-2048px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-beige-48px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-beige-48px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-beige-600px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-beige-600px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-black-1024px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-black-1024px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-black-192px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-black-192px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-black-2048px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-black-2048px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-black-48px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-black-48px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-black-600px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-black-600px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-dark_grey-1024px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-dark_grey-1024px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-dark_grey-192px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-dark_grey-192px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-dark_grey-2048px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-dark_grey-2048px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-dark_grey-48px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-dark_grey-48px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-dark_grey-600px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-dark_grey-600px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-light_grey-1024px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-light_grey-1024px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-light_grey-192px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-light_grey-192px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-light_grey-2048px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-light_grey-2048px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-light_grey-48px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-light_grey-48px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-light_grey-600px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-light_grey-600px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-white-1024px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-white-1024px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-white-192px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-white-192px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-white-2048px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-white-2048px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-white-48px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-white-48px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-white-600px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-777/logo/png/ERC-777-logo-white-600px.png -------------------------------------------------------------------------------- /assets/eip-777/logo/svg/ERC-777-logo-beige.svg: -------------------------------------------------------------------------------- 1 | 2 | 4 | 7 | 8 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /assets/eip-777/logo/svg/ERC-777-logo-black.svg: -------------------------------------------------------------------------------- 1 | 2 | 4 | 7 | 8 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /assets/eip-777/logo/svg/ERC-777-logo-dark_grey.svg: -------------------------------------------------------------------------------- 1 | 2 | 4 | 7 | 8 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /assets/eip-777/logo/svg/ERC-777-logo-light_grey.svg: -------------------------------------------------------------------------------- 1 | 2 | 4 | 7 | 8 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /assets/eip-777/logo/svg/ERC-777-logo-white.svg: -------------------------------------------------------------------------------- 1 | 2 | 4 | 7 | 8 | 20 | 21 | 22 | -------------------------------------------------------------------------------- /assets/eip-823/eip-823-token-exchange-standard-visual-representation-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-823/eip-823-token-exchange-standard-visual-representation-1.png -------------------------------------------------------------------------------- /assets/eip-823/eip-823-token-exchange-standard-visual-representation-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Pro-WebTech/ethereum-EIPS/c4d7686182e9f3d7c3a727448e4f4fe123be50eb/assets/eip-823/eip-823-token-exchange-standard-visual-representation-2.png -------------------------------------------------------------------------------- /assets/eip-858/calculations.md: -------------------------------------------------------------------------------- 1 | | Variable | Symbol | Value | Unit | Source | 2 | | -------------------|--------------|---------------|---------------|--------| 3 | | Network Hashrate |HN | 296000 | GH/s | https://etherscan.io/chart/hashrate | 4 | | GPU Hashrate |HM | 31.2 | MH/s | https://www.legitreviews.com/geforce-gtx-1070-ethereum-mining-small-tweaks-great-hashrate-low-power_195451 | 5 | | GPU Power |PM | 110.6 | W | https://www.reddit.com/r/ethereum/comments/7vewys/10000_tons_co2_per_day_and_climbing_eip_858/dtrswyz/ | 6 | 7 | 8 | ## Network Power Consumption (PN) 9 | 10 | A baseline value for network power consumption can be found by multiplying the total network hashrate with a "best case" value for the power/hashrate ratio that a miner can achieve. 11 | 12 | > PN = HN x PM / HM 13 | > 14 | > PN = 296000 (GH/s) x 110.6 (W) x 1000 (MH/GH) / ( 31.2 (MH/s) x 10^6 (W/MW) ) 15 | > 16 | > PN = 1049 MW 17 | 18 | As a side note, people often confuse power (W) and energy (power x time, eg. Wh). For instance, assuming an average daily PNd of 1049 MW we can calculate that days Energy consumption by multiplying by the number of hours in a day. 19 | 20 | > ENd = PNd x Td 21 | > 22 | > ENd = 1049 (MW) x 24 (h/d) / 1000 (GW/MW) 23 | > 24 | > ENd = 19.7 GWh 25 | -------------------------------------------------------------------------------- /core.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: Core 4 | --- 5 | 6 | {% assign eips=site.pages|where:"type","Standards Track"|where:"category","Core" %} 7 | {% include eiptable.html eips=eips %} 8 | -------------------------------------------------------------------------------- /erc.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: ERC 4 | --- 5 | 6 | {% assign eips=site.pages|where:"type","Standards Track"|where:"category","ERC" %} 7 | {% include eiptable.html eips=eips %} 8 | -------------------------------------------------------------------------------- /informational.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: Informational 4 | --- 5 | 6 | {% assign eips=site.pages|where:"type","Informational" %} 7 | {% include eiptable.html eips=eips %} 8 | -------------------------------------------------------------------------------- /interface.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: Interface 4 | --- 5 | 6 | {% assign eips=site.pages|where:"type","Standards Track"|where:"category","Interface" %} 7 | {% include eiptable.html eips=eips %} 8 | -------------------------------------------------------------------------------- /last-call.xml: -------------------------------------------------------------------------------- 1 | --- 2 | layout: null 3 | --- 4 | 5 | 6 | 7 | Ethereum EIPs - Last Call Review 8 | All EIPs which are in the two-week "last call" status, please help review these and provide your feedback! 9 | {{ site.url }} 10 | 11 | {{ site.time | date_to_rfc822 }} 12 | {% assign eips = site.pages | sort: 'eip' %} 13 | {% for eip in eips %} 14 | {% if eip.status == "Last Call" %} 15 | {% capture description %} 16 |

EIP #{{ eip.eip }} - {{eip.title }} is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.

17 | {% if eip.discussions-to %} 18 |

The author has requested that discussions happen at the following URL: {{ eip.discussions-to }}

19 | {% else %} 20 |

Please visit the [ethereum/EIPs issues to comment](https://github.com/ethereum/EIPs/issues/{{eip.eip}}).

21 | {% endif %} 22 |
23 | {{ eip.content }} 24 | {% endcapture %} 25 | 26 | {{ eip.title | xml_escape }} 27 | {{ description | xml_escape }} 28 | {{ eip.created | date_to_rfc822 }} 29 | {{ site.url }}/{{ eip.url }} 30 | {{ site.url }}/{{ eip.url }} 31 | 32 | {% endif %} 33 | {% endfor %} 34 | 35 | 36 | -------------------------------------------------------------------------------- /meta.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: Meta 4 | --- 5 | 6 | {% assign eips=site.pages|where:"type","Meta" %} 7 | {% include eiptable.html eips=eips %} 8 | -------------------------------------------------------------------------------- /networking.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: page 3 | title: Networking 4 | --- 5 | 6 | {% assign eips=site.pages|where:"type","Standards Track"|where:"category","Networking" %} 7 | {% include eiptable.html eips=eips %} 8 | --------------------------------------------------------------------------------