├── .gitattributes ├── .gitignore ├── .travis.yml ├── EIPS ├── .vuepress │ ├── config.js │ ├── override.styl │ └── theme │ │ ├── AlgoliaSearchBox.vue │ │ ├── DropdownLink.vue │ │ ├── DropdownTransition.vue │ │ ├── Footer.vue │ │ ├── Home.vue │ │ ├── Layout.vue │ │ ├── NavLink.vue │ │ ├── NavLinks.vue │ │ ├── Navbar.vue │ │ ├── NotFound.vue │ │ ├── Page.vue │ │ ├── SWUpdatePopup.vue │ │ ├── SearchBox.vue │ │ ├── Sidebar.vue │ │ ├── SidebarButton.vue │ │ ├── SidebarGroup.vue │ │ ├── SidebarLink.vue │ │ ├── search.svg │ │ ├── styles │ │ ├── arrow.styl │ │ ├── code.styl │ │ ├── config.styl │ │ ├── custom-blocks.styl │ │ ├── mobile.styl │ │ ├── nprogress.styl │ │ ├── theme.styl │ │ ├── toc.styl │ │ └── wrapper.styl │ │ └── util.js ├── all.md ├── core.md ├── 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-1047.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-1344.md ├── eip-1352.md ├── eip-1355.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-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-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-2.md ├── eip-20.md ├── eip-2003.md ├── eip-2014.md ├── eip-2015.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-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-2242.md ├── eip-225.md ├── eip-2255.md ├── eip-2256.md ├── eip-2266.md ├── eip-2304.md ├── eip-2309.md ├── eip-2327.md ├── eip-233.md ├── eip-2330.md ├── eip-234.md ├── eip-2364.md ├── eip-3.md ├── eip-4.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 ├── erc.md ├── index.md ├── informational.md ├── interface.md ├── meta.md └── networking.md ├── ISSUE_TEMPLATE.md ├── PULL_REQUEST_TEMPLATE.md ├── README.md ├── _config.yml ├── _data └── statuses.yaml ├── _includes ├── authorlist.html ├── eipnums.html ├── eiptable.html ├── head.html └── social.html ├── _layouts └── eip.html ├── assets ├── css │ └── style.scss ├── eip-1 │ └── 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-1207 │ └── rationale.png ├── eip-1283 │ └── state.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 │ └── multi-geth-use-case.png ├── eip-2255 │ └── permissions.png ├── 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 ├── eip-template.md ├── last-call.xml └── package.json /.gitattributes: -------------------------------------------------------------------------------- 1 | # GitHub highlighting for Solidity files 2 | # See https://github.com/github/linguist/pull/3973#issuecomment-357507741 3 | *.sol linguist-language=Solidity 4 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | _site 2 | .sass-cache 3 | .jekyll-metadata 4 | vendor 5 | dist/ 6 | yarn-error.log 7 | EIPS/.MWebMetaData/ 8 | node_modules/ 9 | -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | sudo: false # route your build to the container-based infrastructure for a faster build 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.3.0 27 | env: TASK='htmlproofer' 28 | - rvm: 2.3.0 29 | env: TASK='htmlproofer-external' 30 | - rvm: 2.3.0 31 | env: TASK='eip-validator' 32 | - python: 3.3 33 | env: TASK='codespell' 34 | before_script: "sudo pip install urllib3[secure] && sudo pip install codespell" 35 | allow_failures: 36 | - rvm: 2.3.0 37 | env: TASK='htmlproofer-external' 38 | 39 | notifications: 40 | webhooks: 41 | urls: 42 | - https://ethlab-183014.appspot.com/merge/ 43 | on_success: always 44 | 45 | addons: 46 | apt: 47 | packages: 48 | "libcurl4-openssl-dev" # https://github.com/gjtorikian/html-proofer/issues/376#issuecomment-332767999 49 | -------------------------------------------------------------------------------- /EIPS/.vuepress/config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | title: "以太坊改进提案 EIPs", 3 | description: "以太坊改进提案（EIPs）描述了以太坊平台的标准，包括核心协议规范，客户端API和合约标准。", 4 | ga: "", 5 | dest: "./dist/docs", 6 | base: "/docs/eips/", 7 | markdown: { 8 | lineNumbers: true 9 | }, 10 | themeConfig: { 11 | repo: "lbc-team/EIPs", 12 | editLinks: true, 13 | docsDir: "EIPS", 14 | docsBranch: "lbc", 15 | editLinkText: '帮助完善文档', 16 | lastUpdated: true, 17 | algolia: { 18 | apiKey: '', 19 | indexName: '', 20 | debug: false 21 | }, 22 | nav: [ 23 | { text: "首页", link: "https://learnblockchain.cn" }, 24 | { text: "区块链文档中心", link: "https://learnblockchain.cn/docs/" }, 25 | { text: "En", link: "https://eips.ethereum.org" }, 26 | ], 27 | footer: "© Copyright 2017-2019 深入浅出区块链", 28 | sidebar: [ 29 | { 30 | title: "EIPs", 31 | collapsable: true, 32 | children: [ 33 | "/all", 34 | ] 35 | }, 36 | { 37 | title: "核心提案", 38 | collapsable: true, 39 | children: [ 40 | "/core", 41 | "/eip-7", 42 | "/eip-2", 43 | "/eip-100", 44 | "/eip-140", 45 | "/eip-141", 46 | "/eip-145", 47 | "/eip-150", 48 | "/eip-155", 49 | "/eip-160", 50 | "/eip-161", 51 | "/eip-170", 52 | "/eip-196", 53 | "/eip-197", 54 | "/eip-198", 55 | "/eip-211", 56 | "/eip-214", 57 | "/eip-225", 58 | "/eip-649", 59 | "/eip-658", 60 | "/eip-1014", 61 | "/eip-1052", 62 | "/eip-1234", 63 | "/eip-1283", 64 | "/eip-1344", 65 | "/eip-1884" 66 | ] 67 | }, 68 | { 69 | title: "接口提案", 70 | collapsable: true, 71 | children: [ 72 | "/interface", 73 | "/eip-6.md" 74 | ] 75 | }, 76 | { 77 | title: "网络提案", 78 | collapsable: true, 79 | children: [ 80 | "/networking", 81 | "/eip-8.md", 82 | "/eip-627.md", 83 | "/eip-706.md" 84 | ] 85 | }, 86 | { 87 | title: "应用标准提案(ERC)", 88 | collapsable: true, 89 | children: [ 90 | "/erc", 91 | "/eip-20", 92 | "/eip-55", 93 | "/eip-137", 94 | "/eip-162", 95 | "/eip-165", 96 | "/eip-181", 97 | "/eip-190", 98 | "/eip-721", 99 | "/eip-777", 100 | "/eip-1155", 101 | "/eip-1167", 102 | "/eip-1820", 103 | "/eip-875.md" 104 | ] 105 | }, 106 | { 107 | title: "过程提案(Meta)", 108 | collapsable: true, 109 | children: [ 110 | "/meta", 111 | "/eip-1", 112 | "/eip-606.md", 113 | "/eip-607.md", 114 | "/eip-608.md", 115 | "/eip-609.md", 116 | "/eip-779.md", 117 | "/eip-1013.md", 118 | "/eip-1716.md", 119 | "/eip-1679.md" 120 | ] 121 | }, 122 | { 123 | title: "信息提案(Informational)", 124 | collapsable: true, 125 | children: [ 126 | "/informational", 127 | "/eip-1470.md" 128 | ] 129 | } 130 | ] 131 | } 132 | } 133 | -------------------------------------------------------------------------------- /EIPS/.vuepress/override.styl: -------------------------------------------------------------------------------- 1 | $accentColor = #304DE9 2 | $textColor = #15192C 3 | $borderColor = #eaecef 4 | $codeBgColor = #282c34 5 | 6 | 7 | blockquote p { 8 | font-size: 1.0rem; 9 | } -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/DropdownTransition.vue: -------------------------------------------------------------------------------- 1 | 11 | 12 | 28 | 29 | 34 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/Footer.vue: -------------------------------------------------------------------------------- 1 | 6 | 7 | 8 | 21 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/NavLink.vue: -------------------------------------------------------------------------------- 1 | 19 | 20 | 50 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/NotFound.vue: -------------------------------------------------------------------------------- 1 | 10 | 11 | 27 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/SWUpdatePopup.vue: -------------------------------------------------------------------------------- 1 | 12 | 13 | 60 | 61 | 86 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/Sidebar.vue: -------------------------------------------------------------------------------- 1 | 21 | 22 | 80 | 81 | 114 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/SidebarButton.vue: -------------------------------------------------------------------------------- 1 | 8 | 9 | 30 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/SidebarGroup.vue: -------------------------------------------------------------------------------- 1 | 32 | 33 | 43 | 44 | 78 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/SidebarLink.vue: -------------------------------------------------------------------------------- 1 | 60 | 61 | 92 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/search.svg: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/arrow.styl: -------------------------------------------------------------------------------- 1 | @require './config' 2 | 3 | .arrow 4 | display inline-block 5 | width 0 6 | height 0 7 | &.up 8 | border-left 4px solid transparent 9 | border-right 4px solid transparent 10 | border-bottom 6px solid $arrowBgColor 11 | &.down 12 | border-left 4px solid transparent 13 | border-right 4px solid transparent 14 | border-top 6px solid $arrowBgColor 15 | &.right 16 | border-top 4px solid transparent 17 | border-bottom 4px solid transparent 18 | border-left 6px solid $arrowBgColor 19 | &.left 20 | border-top 4px solid transparent 21 | border-bottom 4px solid transparent 22 | border-right 6px solid $arrowBgColor 23 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/code.styl: -------------------------------------------------------------------------------- 1 | @require './config' 2 | 3 | .content 4 | code 5 | color lighten($textColor, 20%) 6 | padding 0.25rem 0.5rem 7 | margin 0 8 | font-size 0.85em 9 | background-color rgba(27,31,35,0.05) 10 | border-radius 3px 11 | 12 | .content 13 | pre, pre[class*="language-"] 14 | line-height 1.4 15 | padding 1.25rem 1.5rem 16 | margin 0.85rem 0 17 | background-color $codeBgColor 18 | border-radius 6px 19 | overflow auto 20 | code 21 | color #fff 22 | padding 0 23 | background-color transparent 24 | border-radius 0 25 | 26 | div[class*="language-"] 27 | position relative 28 | background-color $codeBgColor 29 | border-radius 6px 30 | .highlight-lines 31 | user-select none 32 | padding-top 1.3rem 33 | position absolute 34 | top 0 35 | left 0 36 | width 100% 37 | line-height 1.4 38 | .highlighted 39 | background-color rgba(0, 0, 0, 66%) 40 | pre, pre[class*="language-"] 41 | background transparent 42 | position relative 43 | z-index 1 44 | &::before 45 | position absolute 46 | z-index 3 47 | top 0.8em 48 | right 1em 49 | font-size 0.75rem 50 | color rgba(255, 255, 255, 0.4) 51 | &:not(.line-numbers-mode) 52 | .line-numbers-wrapper 53 | display none 54 | &.line-numbers-mode 55 | .highlight-lines .highlighted 56 | position relative 57 | &:before 58 | content ' ' 59 | position absolute 60 | z-index 3 61 | left 0 62 | top 0 63 | display block 64 | width $lineNumbersWrapperWidth 65 | height 100% 66 | background-color rgba(0, 0, 0, 66%) 67 | pre 68 | padding-left $lineNumbersWrapperWidth + 1 rem 69 | vertical-align middle 70 | .line-numbers-wrapper 71 | position absolute 72 | top 0 73 | width $lineNumbersWrapperWidth 74 | text-align center 75 | color rgba(255, 255, 255, 0.3) 76 | padding 1.25rem 0 77 | line-height 1.4 78 | br 79 | user-select none 80 | .line-number 81 | position relative 82 | z-index 4 83 | user-select none 84 | font-size 0.85em 85 | &::after 86 | content '' 87 | position absolute 88 | z-index 2 89 | top 0 90 | left 0 91 | width $lineNumbersWrapperWidth 92 | height 100% 93 | border-radius 6px 0 0 6px 94 | border-right 1px solid rgba(0, 0, 0, 66%) 95 | background-color $codeBgColor 96 | 97 | 98 | for lang in $codeLang 99 | div{'[class~="language-' + lang + '"]'} 100 | &:before 101 | content ('' + lang) 102 | 103 | div[class~="language-javascript"] 104 | &:before 105 | content "js" 106 | 107 | div[class~="language-typescript"] 108 | &:before 109 | content "ts" 110 | 111 | div[class~="language-markup"] 112 | &:before 113 | content "html" 114 | 115 | div[class~="language-markdown"] 116 | &:before 117 | content "md" 118 | 119 | div[class~="language-json"]:before 120 | content "json" 121 | 122 | div[class~="language-ruby"]:before 123 | content "rb" 124 | 125 | div[class~="language-python"]:before 126 | content "py" 127 | 128 | div[class~="language-bash"]:before 129 | content "sh" 130 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/config.styl: -------------------------------------------------------------------------------- 1 | // colors 2 | $accentColor = #3eaf7c 3 | $textColor = #2c3e50 4 | $borderColor = #eaecef 5 | $codeBgColor = #282c34 6 | $arrowBgColor = #ccc 7 | 8 | // layout 9 | $navbarHeight = 3.6rem 10 | $sidebarWidth = 20rem 11 | $contentWidth = 740px 12 | 13 | // responsive breakpoints 14 | $MQNarrow = 959px 15 | $MQMobile = 719px 16 | $MQMobileNarrow = 419px 17 | 18 | // code 19 | $lineNumbersWrapperWidth = 3.5rem 20 | $codeLang = js ts html md vue css sass scss less stylus go java c sh yaml py 21 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/custom-blocks.styl: -------------------------------------------------------------------------------- 1 | .custom-block 2 | .custom-block-title 3 | font-weight 600 4 | margin-bottom -0.4rem 5 | &.tip, &.warning, &.danger 6 | padding .1rem 1.5rem 7 | border-left-width .5rem 8 | border-left-style solid 9 | margin 1rem 0 10 | &.tip 11 | background-color #f3f5f7 12 | border-color #42b983 13 | &.warning 14 | background-color rgba(255,229,100,.3) 15 | border-color darken(#ffe564, 35%) 16 | color darken(#ffe564, 70%) 17 | .custom-block-title 18 | color darken(#ffe564, 50%) 19 | a 20 | color $textColor 21 | &.danger 22 | background-color #ffe6e6 23 | border-color darken(red, 20%) 24 | color darken(red, 70%) 25 | .custom-block-title 26 | color darken(red, 40%) 27 | a 28 | color $textColor 29 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/mobile.styl: -------------------------------------------------------------------------------- 1 | @require './config' 2 | 3 | $mobileSidebarWidth = $sidebarWidth * 0.82 4 | 5 | // narrow desktop / iPad 6 | @media (max-width: $MQNarrow) 7 | .sidebar 8 | font-size 15px 9 | width $mobileSidebarWidth 10 | .page 11 | padding-left $mobileSidebarWidth 12 | 13 | // wide mobile 14 | @media (max-width: $MQMobile) 15 | .sidebar 16 | top 0 17 | padding-top $navbarHeight 18 | transform translateX(-100%) 19 | transition transform .2s ease 20 | .page 21 | padding-left 0 22 | .theme-container 23 | &.sidebar-open 24 | .sidebar 25 | transform translateX(0) 26 | &.no-navbar 27 | .sidebar 28 | padding-top: 0 29 | 30 | // narrow mobile 31 | @media (max-width: $MQMobileNarrow) 32 | h1 33 | font-size 1.9rem 34 | .content 35 | div[class*="language-"] 36 | margin 0.85rem -1.5rem 37 | border-radius 0 38 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/nprogress.styl: -------------------------------------------------------------------------------- 1 | #nprogress 2 | pointer-events none 3 | .bar 4 | background $accentColor 5 | position fixed 6 | z-index 1031 7 | top 0 8 | left 0 9 | width 100% 10 | height 2px 11 | .peg 12 | display block 13 | position absolute 14 | right 0px 15 | width 100px 16 | height 100% 17 | box-shadow 0 0 10px $accentColor, 0 0 5px $accentColor 18 | opacity 1.0 19 | transform rotate(3deg) translate(0px, -4px) 20 | .spinner 21 | display block 22 | position fixed 23 | z-index 1031 24 | top 15px 25 | right 15px 26 | .spinner-icon 27 | width 18px 28 | height 18px 29 | box-sizing border-box 30 | border solid 2px transparent 31 | border-top-color $accentColor 32 | border-left-color $accentColor 33 | border-radius 50% 34 | animation nprogress-spinner 400ms linear infinite 35 | 36 | .nprogress-custom-parent 37 | overflow hidden 38 | position relative 39 | 40 | .nprogress-custom-parent #nprogress .spinner, 41 | .nprogress-custom-parent #nprogress .bar 42 | position absolute 43 | 44 | @keyframes nprogress-spinner 45 | 0% 46 | transform rotate(0deg) 47 | 100% 48 | transform rotate(360deg) 49 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/toc.styl: -------------------------------------------------------------------------------- 1 | .table-of-contents 2 | .badge 3 | vertical-align middle 4 | -------------------------------------------------------------------------------- /EIPS/.vuepress/theme/styles/wrapper.styl: -------------------------------------------------------------------------------- 1 | $wrapper 2 | max-width $contentWidth 3 | margin 0 auto 4 | padding 2rem 2.5rem 5 | @media (max-width: $MQNarrow) 6 | padding 2rem 7 | @media (max-width: $MQMobileNarrow) 8 | padding 1.5rem 9 | 10 | -------------------------------------------------------------------------------- /EIPS/eip-100.md: -------------------------------------------------------------------------------- 1 | 2 | # EIP 100: 调整区块难度计算 3 | 4 | author: Vitalik Buterin (@vbuterin) 5 | type: Standards Track 6 | category: Core 7 | status: Final 8 | created: 2016-04-28 9 | 10 | 11 | ## 规范 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 | 27 | ## 原理阐述 28 | 29 | 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: 30 | ``` python 31 | adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99) 32 | ``` 33 | 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). 34 | 35 | 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%). 36 | 37 | ## 参考引用 38 | 39 | 1. EIP 100 issue and discussion: https://github.com/ethereum/EIPs/issues/100 40 | 2. https://bitslog.wordpress.com/2016/04/28/uncle-mining-an-ethereum-consensus-protocol-flaw/ 41 | -------------------------------------------------------------------------------- /EIPS/eip-1010.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1010 3 | title: Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c 4 | author: Anderson Wesley (@andywesley) 5 | discussions-to: https://github.com/andywesley/EIPs/issues/1 6 | status: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2018-04-18 10 | --- 11 | 12 | ## 简要说明 13 | 14 | This document proposes to improve the uniformity of ether distribution 15 | between wallet address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and 16 | wallet address `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` which are 17 | currently experiencing a significant non-uniformity. 18 | 19 | ## 摘要 20 | 21 | As of the date of this EIP, the difference in balance between 22 | address `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` and address 23 | `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` is far from equitable 24 | or uniform, with the former having more than 365,000 ether 25 | more than the latter. The distribution of ether between these two 26 | addresses must be improved in order to protect the Ethereum economy 27 | from centralized control. This will be accomplished by transferring 28 | 100,000 ether from the former address to the latter. This is a properly 29 | motivated improvement in keeping with the core Ethereum philosophy of 30 | decentralization. 31 | 32 | ## 动机 33 | 34 | This proposal is necessary because the Ethereum protocol does not allow 35 | the owner of an address which does not own an equitable amount of ether 36 | to claim their share of ether from an address which owns a dangerously 37 | centralized quantity. Rather than proposing an overly complicated generic 38 | mechanism for any user to claim ether to which they believe they are 39 | equitably entitled, this proposal will take the simple route of a one-time 40 | transfer of 100,000 ether from `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` 41 | to `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c`. This avoids duplicating 42 | the effort of other proposals and provides a net improvement to the 43 | Ethereum project and community. 44 | 45 | ## 规范 46 | 47 | The balance of `0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B` will be decreased 48 | by 100,000 ether. The balance of `0x15E55EF43efA8348dDaeAa455F16C43B64917e3c` 49 | will be increased by 100,000 ether. No net change in the amount of extant 50 | ether will occur unless at the time of implementation the former address does not 51 | contain sufficient ether for such a deduction. 52 | 53 | ## 原理阐述 54 | 55 | The value 100,000 was chosen after careful technically sound analysis of various economic theories 56 | developed over the past century. In spite of the fact that it is a convenient round 57 | number, it is actually the exact output of a complex statistical process iterated to 58 | determine the optimal distribution of ether between these addresses. 59 | 60 | ## 向后兼容 61 | 62 | Clients that fail to implement this change will not be aware of the correct balances 63 | for these addresses. This will create a hard fork. The implementation of this change 64 | consistently among all clients as intended by the proposal process will be sufficient 65 | to ensure that backwards compatibility is not a concern. 66 | 67 | ## 版权 68 | Copyright and related rights waived via 69 | [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 70 | -------------------------------------------------------------------------------- /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 | ## 摘要 12 | 13 | This meta-EIP specifies the changes included in the Ethereum hardfork named Constantinople. 14 | 15 | ## 规范 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.html): Bitwise shifting instructions in EVM 26 | - [EIP 1014](eip-1014.html): Skinny CREATE2 27 | - [EIP 1052](eip-1052.html): EXTCODEHASH Opcode 28 | - [EIP 1234](eip-1234.html): Delay difficulty bomb, adjust block reward 29 | - [EIP 1283](eip-1283.html): Net gas metering for SSTORE without dirty maps 30 | 31 | ## 参考引用 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 | ## 版权 37 | 38 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 39 | -------------------------------------------------------------------------------- /EIPS/eip-1047.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1047 3 | title: Token Metadata JSON Schema 4 | author: Tommy Nicholas (@tomasienrbc), Matt Russo (@mateosu), John Zettler (@JohnZettler) 5 | discussions-to: https://www.reddit.com/r/raredigitalart/comments/8hfk2a/token_metadata_json_schema_eip_1047/ 6 | status: Draft 7 | type: Standards Track 8 | category: ERC 9 | created: 2018-04-13 10 | --- 11 | 12 | ## 简要说明 13 | A standard interface for token metadata 14 | 15 | ## 摘要 16 | The ERC721 standard introduced the "tokenURI" parameter for non-fungible tokens to handle metadata such as: 17 | 18 | - thumbnail image 19 | - title 20 | - description 21 | - properties 22 | - etc. 23 | 24 | This is particularly critical for crypto-collectibles and gaming assets. 25 | 26 | This standard includes a reference to a metadata standard named "ERC721 Metadata JSON Schema". This schema is actually equally relevant to ERC20 tokens and therefore should be its own standard, separate from the ERC721 standard. 27 | 28 | ## 动机 29 | Metadata is critical for both ERC721 and ERC20 tokens representing things like crypto-collectibles, gaming assets, etc. Not all crypto-collectibles and gaming assets will be non-fungible. It is critical for fungible ERC20 tokens to have a metadata standard similar to that of ERC721 tokens. Standardization of metadata between ERC20 and ERC721 will simplify development of dApps and infrastructure that must support both fungible and non-fungible assets. 30 | 31 | It is more logical and easier to maintain one Token Metadata JSON Schema rather than multiple schemas contained in their own EIPs. 32 | 33 | This should result in no code changes to the ERC721 standard or ERC20 standard and will serve only to simplify the process of maintaining a standard JSON Schema for token metadata. 34 | 35 | ## 规范 36 | 37 | This "Token Metadata JSON Schema" mimics the structure of the ERC721 standard. Only grammatical changes are being recommended at this time. 38 | 39 | ```json 40 | { 41 | "title": "Asset Metadata", 42 | "type": "object", 43 | "properties": { 44 | "name": { 45 | "type": "string", 46 | "description": "Identifies the asset to which this token represents", 47 | }, 48 | "description": { 49 | "type": "string", 50 | "description": "Describes the asset to which this token represents", 51 | }, 52 | "image": { 53 | "type": "string", 54 | "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.", 55 | } 56 | } 57 | } 58 | ``` 59 | ## 原理阐述 60 | One JSON schema standard will allow for simpler maintenance of this critical schema. 61 | 62 | ## 向后兼容 63 | Fully backwards compatible requiring no code changes at this time 64 | 65 | ## 测试用例 66 | TO-DO 67 | 68 | ## 实现 69 | TO-DO 70 | 71 | ## 版权 72 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 73 | -------------------------------------------------------------------------------- /EIPS/eip-1051.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1051 3 | title: Overflow checking for the EVM 4 | author: Nick Johnson 5 | discussions-to: https://ethereum-magicians.org/t/eip-arithmetic-overflow-detection-for-the-evm/261 6 | status: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2018-05-02 10 | --- 11 | 12 | ## 摘要 13 | This EIP adds overflow checking for EVM arithmetic operations, and two new opcodes that check and clear the overflow flags. 14 | 15 | ## 动机 16 | The correct functioning of many contracts today is dependent on detecting and preventing overflow of arithmetic operations. Since the EVM operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation. 17 | 18 | In the interests of facilitating efficient and secure contracts, we propose new opcodes that permit efficient detection of overflows, which can be checked periodically rather than after each operation. 19 | 20 | ## 规范 21 | 22 | Two new flags are added to the EVM state: overflow (`ovf`) and signed overflow (`sovf`). 23 | 24 | The `ovf` flag is set in the following circumstances: 25 | 26 | - When an `ADD` opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1. 27 | - When a `SUB` opcode, with both inputs treated as unsigned integers, produces an ideal output less than 0. 28 | - When a 'MUL' opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 - 1. 29 | 30 | The `sovf` flag is set whenever the `ovf` flag is set, and additionally in the following circumstances: 31 | 32 | - When an `ADD` opcode with both inputs having the same MSB results in the output having a different MSB (eg, `(+a) + (+b) = (-c)` or `(-a) + (-b) = (+c)`). 33 | - When a `SUB` opcode occurs and the result has the same MSB as the subtractand (second argument) (eg, `(+a) - (-b) = (-c)` or `(-a) - (+b) = (+c)`. 34 | - When a `MUL` opcode with both inputs being positive has a negative output. 35 | - When a 'MUL' opcode with both inputs being negative has a negative output. 36 | - When a 'MUL' opcode with one negative input and one positive input has a positive output. 37 | 38 | A new opcode, `OFV` is added, with number 0x0C. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `ovf` flag is set, and `0` otherwise. It then sets the `ovf` flag to false. 39 | 40 | A new opcode, `SOVF` is added, with number 0x0D. This opcode takes 0 arguments from the stack. When executed, it pushes `1` if the `sovf` flag is set, and `0` otherwise. It then sets the `sovf` flag to false. 41 | 42 | ## 原理阐述 43 | Any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. One option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. However, this limits the manner in which overflows can be handled. 44 | 45 | Instead, we replicate functionality from real world CPUs, which typically implement 'carry' and 'overflow' flags. 46 | 47 | Separate flags for signed and unsigned overflow are necessary due to the fact that a signed overflow may not result in an unsigned overflow. 48 | 49 | ## 向后兼容 50 | This EIP introduces no backwards compatibility issues. 51 | 52 | ## 测试用例 53 | TBD 54 | 55 | ## 实现 56 | TBD 57 | 58 | ## 版权 59 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 60 | -------------------------------------------------------------------------------- /EIPS/eip-1052.md: -------------------------------------------------------------------------------- 1 | # EIP 1052: EXTCODEHASH 操作码 2 | 3 | 4 | | 作者 | 讨论 | 类型 | 分类 | 状态 | 创建时间 | 5 | | --- | --- | --- | --- | --- | --- | 6 | | Nick Johnson , Paweł Bylica | [262](https://ethereum-magicians.org/t/extcodehash-opcode/262) | Standards Track | Core | Final | 2018-05-02 | 7 | 8 | 9 | ## 摘要 10 | This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code. 11 | 12 | ## 动机 13 | Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes. 14 | 15 | Contracts can presently do this using the `EXTCODECOPY` opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, `EXTCODEHASH`, which returns the keccak256 hash of a contract's bytecode. 16 | 17 | ## 规范 18 | 19 | A new opcode, `EXTCODEHASH`, is introduced, with number 0x3F. The `EXTCODEHASH` 20 | takes one argument from the stack, zeros the first 96 bits 21 | and pushes to the stack the keccak256 hash of the code of the account 22 | at the address being the remaining 160 bits. 23 | 24 | In case the account does not exist `0` is pushed to the stack. 25 | 26 | In case the account does not have code the keccak256 hash of empty data 27 | (i.e. `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`) 28 | is pushed to the stack. 29 | 30 | The gas cost of the `EXTCODEHASH` is 400. 31 | 32 | 33 | ## 原理阐述 34 | 35 | As described in the motivation section, this opcode is widely useful, and saves 36 | on wasted gas in many cases. 37 | 38 | The gas cost is the same as the gas cost for the `BALANCE` opcode because the 39 | execution of the `EXTCODEHASH` requires the same account lookup as in `BALANCE`. 40 | 41 | Only the 20 last bytes of the argument are significant (the first 12 bytes are 42 | ignored) similarly to the semantics of the `BALANCE`, `EXTCODESIZE` and 43 | `EXTCODECOPY`. 44 | 45 | The `EXTCODEHASH` distincts accounts without code and non-existing accounts. 46 | This is consistent with the way accounts are represented in the state trie. 47 | This also allows smart contracts to check whenever an account exists. 48 | 49 | 50 | ## 向后兼容 51 | 52 | There are no backwards compatibility concerns. 53 | 54 | 55 | ## 测试用例 56 | 57 | 1. The `EXTCODEHASH` of the account without code is `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470` 58 | what is the keccack256 hash of empty data. 59 | 2. The `EXTCODEHASH` of non-existent account is `0`. 60 | 3. The `EXTCODEHASH` of an precompiled contract is either `c5d246...` or `0`. 61 | 4. If `EXTCODEHASH` of `A` is `X`, then `EXTCODEHASH` of `A + 2**160` is `X`. 62 | 5. The `EXTCODEHASH` of an account that selfdestructed in the current transaction. 63 | 6. The `EXTCODEHASH` of an account that selfdestructed and later the selfdestruct has been reverted. 64 | 7. The `EXTCODEHASH` of an account created in the current transaction. 65 | 8. The `EXTCODEHASH` of an account that has been newly create and later the creation has been reverted. 66 | 9. The `EXTCODEHASH` of an account that firstly does not exist and later is empty. 67 | 10. The `EXTCODEHASH` of an empty account that is going to be cleared by the state clearing rule. 68 | 69 | 70 | ## 实现 71 | TBD 72 | 73 | ## 版权 74 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 75 | -------------------------------------------------------------------------------- /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: Draft 9 | created: 2018-07-21 10 | --- 11 | 12 | ## 简要说明 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 | ## 摘要 16 | Starting with `FORK_BLOCK_NUMBER` the client will calculate the difficulty without considering the current block number. 17 | 18 | ## 动机 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 | ## 规范 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 | ## 原理阐述 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 | ## 向后兼容 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 | ## 测试用例 34 | Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. 35 | 36 | ## 实现s 37 | The yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710 38 | 39 | ## 版权 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: Draft 8 | created: 2018-08-15 9 | discussions-to: https://ethereum-magicians.org/t/wallet-connect-eip/850 10 | --- 11 | 12 | ## 简要说明 13 | 14 | A standard to create WalletConnect URIs to initiate connections between applications and wallets. 15 | 16 | ## 摘要 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 | ## 规范 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 | ### 示例 39 | 40 | ``` 41 | wc:8a5e5bdc-a0e4-4702-ba63-8f1a5655744f@1?bridge=https%3A%2F%2Fbridge.walletconnect.org&key=41791102999c339c844880b23950704cc43aa840f3739e365323cda4dfa89e7a 42 | ``` 43 | 44 | ## 原理阐述 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 | ## 参考引用 49 | 50 | 1. WalletConnect Technical Specification, https://docs.walletconnect.org/tech-spec 51 | 52 | ## 版权 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: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2018-07-27 10 | --- 11 | 12 | ## 简要说明 13 | Specify an Ethereum address range occupied by precompiles and future system contracts. Regular accounts and contracts cannot obtain such an address. 14 | 15 | ## 摘要 16 | The address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts. 17 | 18 | ## 动机 19 | This will simplify certain future features where unless this is implemented, several exceptions must be specified. 20 | 21 | ## 规范 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 | ## 原理阐述 28 | N/A 29 | 30 | ## 向后兼容 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 | ## 测试用例 34 | N/A 35 | 36 | ## 实现 37 | N/A 38 | 39 | ## 版权 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: Abandoned 7 | type: Standards Track 8 | category: Core 9 | created: 2018-08-26 10 | --- 11 | 12 | ## 动机 13 | 14 | Provide minimal set of changes to Ethash algorithm to hinder and delay the adoption of ASIC based mining. 15 | 16 | ## 规范 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 | ## 原理阐述 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 | ## 版权 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-1380.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1380 3 | title: Reduced gas cost for call to self 4 | author: Alex Beregszaszi (@axic), Jacques Wagener (@jacqueswww) 5 | discussions-to: https://ethereum-magicians.org/t/eip-1380-reduced-gas-cost-for-call-to-self/1242 6 | status: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2018-08-31 10 | requires: 150 11 | --- 12 | 13 | ## 摘要 14 | Reduce the gas cost for call instructions, when the goal is to run a new instance of the currently loaded contract. 15 | 16 | ## 动机 17 | The current gas cost of 700 for all call types (`CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL`) does not take into account that a call to a contract itself 18 | does not need to perform additional I/O operations, because the current contract code has already been loaded into memory. 19 | 20 | Reducing the call-to-self gas cost would greatly benefit smart contract languages, such as Solidity and Vyper, who would then be able to utilise `CALL` instead 21 | of `JUMP` opcodes for internal function calls. While languages can already utilise `CALL` for internal function calls, they are discouraged to do so due to the 22 | gas costs associated with it. 23 | 24 | Using `JUMP` comes at a considerable cost in complexity to the implementation of a smart contract language and/or compiler. The context (including stack and memory) 25 | must be swapped in and out of the calling functions context. A desired feature is having *pure* functions, which do not modify the state of memory, and realising 26 | them through `JUMP` requires a bigger effort from the compiler as opposed to being able to use `CALL`s. 27 | 28 | Using call-to-self provides the guarantee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both 29 | contract writers and contract consumers against potentially undetetected edge cases were memory could poison the context of the internal function. 30 | 31 | Because of the `JUMP` usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerbly faster, if nested 32 | function calls with many in and/or outputs are required. 33 | 34 | Reducing the gas cost, and thereby incentivising of using call-to-self instead of `JUMP`s for the internal function implementation will also benefit static 35 | analyzers and tracers. 36 | 37 | ## 规范 38 | If `block.number >= FORK_BLKNUM`, then decrease the cost of `CALL`, `DELEGATECALL`, `CALLCODE` and `STATICCALL` from 700 to 40, 39 | if and only if, the destination address of the call equals to the address of the caller. 40 | 41 | ## 原理阐述 42 | EIP150 has increased the cost of these instructions from 40 to 700 to more fairly charge for loading new contracts from disk, e.g. to reflect the I/O charge more closely. 43 | By assuming that 660 is the cost of loading a contract from disk, one can assume that the original 40 gas is a fair cost of creating a new VM instance of an already loaded contract code. 44 | 45 | ## 向后兼容 46 | This should pose no risk to backwards compatibility. Currently existing contracts should not notice the difference, just see cheaper execution. 47 | With EIP150 contract (and language) developers had a lesson that relying on strict gas costs is not feasible as costs may change. 48 | The impact of this EIP is even less that of EIP150 because the costs are changing downwards and not upwards. 49 | 50 | ## 测试用例 51 | TBA 52 | 53 | ## 实现 54 | TBA 55 | 56 | ## 版权 57 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 58 | -------------------------------------------------------------------------------- /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: Draft 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 | ``` 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-140.md: -------------------------------------------------------------------------------- 1 | # EIP 140 : REVERT（还原状态）指令 2 | 3 | | 作者 | 类型 | 分类 | 状态 | 创建时间 | 4 | | --- | --- | --- | --- | --- | 5 | | Alex Beregszaszi (@axic), Nikolai Mushegian | Standards Track | Core | Final | 2017-02-06 6 | 7 | 8 | ## 简要说明 9 | 10 | The `REVERT` instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason. 11 | 12 | ## 摘要 13 | 14 | The `REVERT` instruction will stop execution, roll back all state changes done so far and provide a pointer to a memory section, which can be interpreted as an error code or message. While doing so, it will not consume all the remaining gas. 15 | 16 | ## 动机 17 | 18 | Currently this is not possible. There are two practical ways to revert a transaction from within a contract: running out of gas or executing an invalid instruction. Both of these options will consume all remaining gas. Additionally, reverting an EVM execution means that all changes, including LOGs, are lost and there is no way to convey a reason for aborting an EVM execution. 19 | 20 | ## 规范 21 | 22 | On blocks with `block.number >= BYZANTIUM_FORK_BLKNUM`, the `REVERT` instruction is introduced at `0xfd`. It expects two stack items, the top item is the `memory_offset` followed by `memory_length`. It does not produce any stack elements because it stops execution. 23 | 24 | The semantics of `REVERT` with respect to memory and memory cost are identical to those of `RETURN`. The sequence of bytes given by `memory_offset` and `memory_length` is called "error message" in the following. 25 | 26 | The effect of `REVERT` is that execution is aborted, considered as failed, and state changes are rolled back. The error message will be available to the caller in the returndata buffer and will also be copied to the output area, i.e. it is handled in the same way as the regular return data is handled. 27 | 28 | The cost of the `REVERT` instruction equals to that of the `RETURN` instruction, i.e. the rollback itself does not consume all gas, the contract only has to pay for memory. 29 | 30 | In case there is not enough gas left to cover the cost of `REVERT` or there is a stack underflow, the effect of the `REVERT` instruction will equal to that of a regular out of gas exception, i.e. it will consume all gas. 31 | 32 | In the same way as all other failures, the calling opcode returns `0` on the stack following a `REVERT` opcode in the callee. 33 | 34 | In case `REVERT` is used in the context of a `CREATE` or `CREATE2` call, no code is deployed, `0` is put on the stack and the error message is available in the returndata buffer. 35 | 36 | The content of the optionally provided memory section is not defined by this EIP, but is a candidate for another Informational EIP. 37 | 38 | ## 向后兼容 39 | 40 | This change has no effect on contracts created in the past unless they contain `0xfd` as an instruction. 41 | 42 | ## 测试用例 43 | 44 | ``` 45 | 6c726576657274656420646174616000557f726576657274206d657373616765000000000000000000000000000000000000600052600e6000fd 46 | ``` 47 | 48 | should: 49 | - return `0x726576657274206d657373616765` as `REVERT` data, 50 | - the storage at key `0x0` should be left as unset and 51 | - use 20024 gas in total. 52 | 53 | ## 版权 54 | 55 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 56 | -------------------------------------------------------------------------------- /EIPS/eip-141.md: -------------------------------------------------------------------------------- 1 | # EIP 141 : 确定EVM无效指令 INVALID 2 | 3 | 4 | | 作者 | 类型 | 分类 | 状态 | 创建时间 | 5 | | --- | --- | --- | --- | --- | 6 | | Alex Beregszaszi (@axic) | Standards Track | Core | Final | 2017-02-09 | 7 | 8 | 9 | ## 摘要 10 | 11 | An instruction is designated to remain as an invalid instruction. 12 | 13 | ## 动机 14 | 15 | The invalid instruction can be used as a distinct reason to abort execution. 16 | 17 | ## 规范 18 | 19 | The opcode `0xfe` is the `INVALID` instruction. It can be used to abort the execution (i.e. duplicates as an `ABORT` instruction). 20 | 21 | ## 向后兼容 22 | 23 | This instruction was never used and therefore has no effect on past contracts. 24 | 25 | ## 版权 26 | 27 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 28 | -------------------------------------------------------------------------------- /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: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2018-10-09 10 | --- 11 | 12 | ## 简要说明 13 | 14 | Include an explicit definition of the acceptable timestamp drift in the protocol specification. 15 | 16 | ## 摘要 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 | ## 动机 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 | ## 规范 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 | ## 原理阐述 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 | ## 向后兼容 44 | 45 | 46 | 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. 47 | 48 | ## 测试用例 49 | 50 | 51 | These would be important to have. 52 | 53 | 54 | 55 | 56 | ## 实现 57 | 58 | _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. 59 | _ 60 | ## 版权 61 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 62 | -------------------------------------------------------------------------------- /EIPS/eip-155.md: -------------------------------------------------------------------------------- 1 | # EIP 155: 简单的重放攻击保护 2 | 3 | | 作者 | 状态 | 类型 | 分类 | 创建时间 | 4 | | --- | --- | --- | --- | --- | --- | 5 | | Vitalik Buterin (@vbuterin) | 最终 | Standards Track | Core | 2016-10-14 | 6 | 7 | 8 | ## 硬分叉 9 | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) 10 | 11 | ## 参数 12 | - `FORK_BLKNUM`: 2,675,000 13 | - `CHAIN_ID`: 1 (main net) 14 | 15 | ## 规范 16 | 17 | If `block.number >= FORK_BLKNUM` and `v = CHAIN_ID * 2 + 35` or `v = CHAIN_ID * 2 + 36`, then when computing the hash of a transaction for purposes of signing or recovering, instead of hashing only the first six elements (i.e. nonce, gasprice, startgas, to, value, data), hash nine elements, with `v` replaced by `CHAIN_ID`, `r = 0` and `s = 0`. The currently existing signature scheme using `v = 27` and `v = 28` remains valid and continues to operate under the same rules as it does now. 18 | 19 | ## 示例 20 | 21 | Consider a transaction with `nonce = 9`, `gasprice = 20 * 10**9`, `startgas = 21000`, `to = 0x3535353535353535353535353535353535353535`, `value = 10**18`, `data=''` (empty). 22 | 23 | The "signing data" becomes: 24 | 25 | ``` 26 | 0xec098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a764000080018080 27 | ``` 28 | 29 | The "signing hash" becomes: 30 | 31 | ``` 32 | 0xdaf5a779ae972f972197303d7b574746c7ef83eadac0f2791ad23db92e4c8e53 33 | ``` 34 | 35 | If the transaction is signed with the private key `0x4646464646464646464646464646464646464646464646464646464646464646`, then the v,r,s values become: 36 | 37 | ``` 38 | (37, 18515461264373351373200002665853028612451056578545711640558177340181847433846, 46948507304638947509940763649030358759909902576025900602547168820602576006531) 39 | ``` 40 | 41 | Notice the use of 37 instead of 27. The signed tx would become: 42 | 43 | ``` 44 | 0xf86c098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a76400008025a028ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276a067cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83 45 | ``` 46 | 47 | ## 原理阐述 48 | 49 | This would provide a way to send transactions that work on Ethereum without working on ETC or the Morden testnet. ETC is encouraged to adopt this EIP but replacing `CHAIN_ID` with a different value, and all future testnets, consortium chains and alt-etherea are encouraged to adopt this EIP replacing `CHAIN_ID` with a unique value. 50 | 51 | 52 | ## 各个网络的CHAIN_ID 53 | 54 | | `CHAIN_ID` | 网络名称 | 55 | | ---------------| -------------------------------------------| 56 | | 1 | Ethereum mainnet | 57 | | 2 | Morden (disused), Expanse mainnet | 58 | | 3 | Ropsten | 59 | | 4 | Rinkeby | 60 | | 5 | Goerli | 61 | | 42 | Kovan | 62 | | 1337 | Geth private chains (default) | 63 | 64 | 65 | Find more chain ID's on [chainid.network](https://chainid.network) and contribute to [ethereum-lists/chains](https://github.com/ethereum-lists/chains). 66 | -------------------------------------------------------------------------------- /EIPS/eip-1581.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1581 3 | title: Non-wallet usage of keys derived from BIP-32 trees 4 | author: Michele Balistreri (@bitgamma) 5 | discussions-to: https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817 6 | status: Draft 7 | type: Standards Track 8 | category: ERC 9 | created: 2018-11-13 10 | --- 11 | 12 | ## 简要说明 13 | This EIP describes a derivation path structure for [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) wallets to be used for non-wallet keypairs. 14 | 15 | ## 摘要 16 | BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets. 17 | 18 | ## 动机 19 | Applications interacting with the blockchain often make use of additional, non-blockchain technologies to perform the task they are designed for. For privacy and security sensitive mechanisms, sets of keys are needed. Reusing keys used for wallets can prove to be insecure, while keeping completely independent keys make backup and migration of the full set of credentials more complex. Defining a separate (from BIP44 compliant wallets) derivation branch allows combining the security of independent keys with the convenience of having a single piece of information which needs to be backup or migrated. 20 | 21 | ## 规范 22 | 23 | ### Path levels 24 | We define the following levels in BIP32 path: 25 | 26 | ```m / purpose' / coin_type' / subpurpose' / key_type' / key_index``` 27 | 28 | Apostrophe in the path indicates that BIP32 hardened derivation is used. 29 | 30 | This structure follows the [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) recommendations and its [amendments for non-Bitcoin usage](https://github.com/bitcoin/bips/pull/523/files). Each level has a special meaning, described in the chapters below. 31 | 32 | ### Purpose/Coin Type/Subpurpose 33 | This part is constant and set to ```m / 43' / 60' / 1581'```, meaning BIP 43 -> Ethereum -> This EIP. 34 | 35 | All subtrees under this prefix are the scope of this EIP. 36 | 37 | ### Key type 38 | Describes the purpose for which the key is being used. Key types should be generic. "Instant messaging" is a good example whereas "Whisper" is not. The reason is that you want to be able to use the same identity across different services. Key types are defined at: TBD 39 | 40 | Hardened derivation is used at this level. 41 | 42 | ### Key index 43 | The key index is a field of variable length identifying a specific key. In its simplest case, it is a number from 0 to 2^31-1. If a larger identifier is desired (for example representing a hash or a GUID), the value must be split 44 | across several BIP32 nesting levels, most significant bit first and left aligned, bit-padded with 0s if needed. All levels, except the last one must used hardened key derivation. The last level must use public derivation. This means that every level can carry 31-bit of the identifier to represent. 45 | 46 | As an example, let's assume we have a key with key type 4' and a key_index representing a 62-bit ID represented as hexadecimal 0x2BCDEFFEDCBAABCD the complete keypath would be ```m / 43' / 60' / 1581' / 4' / ‭1469833213‬' / ‭1555737549‬ ```. If you are using random identifiers, it might be convenient to generate a conventional GUID, for example 128-bit just fix the value of the most significant bit of each 32-bit word to 1 for all of them, except the last one which will be 0. 47 | 48 | ## 原理阐述 49 | The structure proposed above follows the BIP43 generic structure and is similar to the widely adopted BIP44 specification. 50 | 51 | ## 版权 52 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 53 | -------------------------------------------------------------------------------- /EIPS/eip-1588.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 1588 3 | title: "Hardfork Meta: Ethereum ProgPoW" 4 | author: Ikmyeong Na (@naikmyeong) 5 | status: Draft 6 | type: Meta 7 | created: 2018-11-16 8 | requires: 1057 9 | --- 10 | 11 | ## 摘要 12 | 13 | This meta-EIP specifies the changes included in the alternative Ethereum hardfork named Ethereum ProgPoW. 14 | 15 | ## 规范 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 | ## 版权 25 | 26 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 27 | -------------------------------------------------------------------------------- /EIPS/eip-160.md: -------------------------------------------------------------------------------- 1 | # EIP 160: EXP cost increase 2 | 3 | 4 | | 作者 | 状态 | 类型 | 分类 | 创建时间 | 5 | | --- | --- | --- | --- | --- | --- | 6 | | Vitalik Buterin (@vbuterin) | Final | Standards Track | Core | 2016-10-20 | 7 | 8 | 9 | ## 硬分叉 10 | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) 11 | 12 | ## 参数 13 | - `FORK_BLKNUM`: 2,675,000 14 | - `CHAIN_ID`: 1 15 | 16 | ## 规范 17 | 18 | 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. 19 | 20 | ## 原理阐述 21 | 22 | Benchmarks suggest that EXP is currently underpriced by a factor of about 4–8. 23 | 24 | ## 参考引用 25 | 26 | 1. EIP-160 issue and discussion: https://github.com/ethereum/EIPs/issues/160 27 | -------------------------------------------------------------------------------- /EIPS/eip-1679.md: -------------------------------------------------------------------------------- 1 | # EIP 1679: 伊斯坦布尔硬分叉元提案 2 | 3 | 4 | | 作者 | 状态 | 类型 | 讨论 | 创建时间 | 依赖 | 5 | | --- | --- | --- | --- | --- | --- | 6 | |Alex, Afri | Draft | Meta | [3207](https://ethereum-magicians.org/t/hardfork-meta-istanbul-discussion/3207) | 2019-01-04 | [1716](eip-1716.md) | 7 | 8 | 9 | ## 简要说明 10 | 11 | This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul. 12 | 13 | ## 规范 14 | 15 | - Codename: Istanbul 16 | 17 | ### 区块节点 18 | 19 | - `Block >= 9,069,000` on the Ethereum mainnet 20 | - `Block >= 6,485,846` on the Ropsten testnet 21 | - `Block >= 14,111,141` on the Kovan testnet 22 | - `Block >= 5,435,345` on the Rinkeby testnet 23 | - `Block >= 1,561,651` on the Görli testnet 24 | 25 | ### 包含的 EIPs 26 | - [EIP-152](eip-152.md): Add Blake2 compression function `F` precompile 27 | - [EIP-1108](eip-1108.md): Reduce alt_bn128 precompile gas costs 28 | - [EIP-1344](eip-1344.md): Add ChainID opcode 29 | - [EIP-1884](eip-1884.md): Repricing for trie-size-dependent opcodes 30 | - [EIP-2028](eip-2028.md): Calldata gas cost reduction 31 | - [EIP-2200](eip-2200.md): Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change 32 | 33 | ## 引用 34 | 35 | 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) 36 | 2. https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df 37 | 38 | ## 版权 39 | 40 | 原文版权 [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 41 | 42 | 本EIP 由深入浅出社区 Tiny熊 翻译，版权所有。 43 | 44 | 45 | -------------------------------------------------------------------------------- /EIPS/eip-170.md: -------------------------------------------------------------------------------- 1 | # EIP 170 : 合约代码大小限制 2 | 3 | | 作者 | 状态 | 类型 | 分类 | 创建时间 | 4 | | --- | --- | --- | --- | --- | --- | 5 | | Vitalik Buterin (@vbuterin) | 最终 | Standards Track | Core | 2016-11-04 | 6 | 7 | 8 | 9 | ## 硬分叉 10 | [Spurious Dragon](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-607.md) 11 | 12 | ## 参数 13 | - `FORK_BLKNUM`: 2,675,000 14 | - `CHAIN_ID`: 1 (main net) 15 | 16 | ## 规范 17 | 18 | If `block.number >= FORK_BLKNUM`, then if contract creation initialization returns data with length of **more than** `0x6000` (`2**14 + 2**13`) bytes, contract creation fails with an out of gas error. 19 | 20 | ## 原理阐述 21 | 22 | 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. 23 | 24 | ## 参考引用 25 | 26 | 1. EIP-170 issue and discussion: https://github.com/ethereum/EIPs/issues/170 27 | 2. pyethereum implementation: https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397 28 | -------------------------------------------------------------------------------- /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 | ## 摘要 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 | ## 规范 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 | ## 参考引用 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 | ## 版权 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: Draft 9 | created: 2017-07-28 10 | requires: 141 11 | --- 12 | 13 | ## 摘要 14 | 15 | Rename the `BALANCE`, `SHA3`, `NUMBER`, `GASLIMIT`, `GAS` and `INVALID` opcodes to reflect their true meaning. 16 | 17 | ## 规范 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 | ## 向后兼容 28 | 29 | This has no effect on any code. It can influence what mnemonics assemblers will use. 30 | 31 | ## 实现 32 | 33 | Not applicable. 34 | 35 | ## 参考引用 36 | 37 | [EIP-6](eip-6.html) previously renamed `SUICIDE` (`0xff`) to `SELFDESTRUCT`. 38 | Renaming `SHA3` was previously proposed by [EIP-59](https://github.com/ethereum/EIPs/issues/59). 39 | 40 | ## 版权 41 | 42 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 43 | -------------------------------------------------------------------------------- /EIPS/eip-1844.md: -------------------------------------------------------------------------------- 1 | # EIP 1844: ENS 接口发现 2 | 3 | | 作者 | 类型 | 分类 | 状态 | 创建时间 | 依赖 | 4 | | --- | --- | --- | --- | --- | --- | 5 | | Nick Johnson (@arachnid)| Standards Track | ERC | Draft | 2019-03-15 | 137, 165 | 6 | 7 | 8 | ## 简要说明 9 | Defines a method of associating contract interfaces with ENS names and addresses, and of discovering those interfaces. 10 | 11 | ## 摘要 12 | This EIP specifies a method for exposing interfaces associated with an ENS name or an address (typically a contract address) and allowing applications to discover those interfaces and interact with them. Interfaces can be implemented either by the target contract (if any) or by any other contract. 13 | 14 | ## 动机 15 | EIP 165 supports interface discovery - determining if the contract at a given address supports a requested interface. However, in many cases it's useful to be able to discover functionality associated with a name or an address that is implemented by other contracts. 16 | 17 | For example, a token contract may not itself provide any kind of 'atomic swap' functionality, but there may be associated contracts that do. With ENS interface discovery, the token contract can expose this metadata, informing applications where they can find that functionality. 18 | 19 | ## 规范 20 | A new profile for ENS resolvers is defined, consisting of the following method: 21 | 22 | ``` 23 | function interfaceImplementer(bytes32 node, bytes4 interfaceID) external view returns (address); 24 | ``` 25 | 26 | The EIP-165 interface ID of this interface is `0xb8f2bbb4`. 27 | 28 | Given an ENS name hash `node` and an EIP-165 `interfaceID`, this function returns the address of an appropriate implementer of that interface. If there is no interface matching that interface ID for that node, 0 is returned. 29 | 30 | The address returned by `interfaceImplementer` MUST refer to a smart contract. 31 | 32 | The smart contract at the returned address SHOULD implement EIP-165. 33 | 34 | Resolvers implementing this interface MAY utilise a fallback strategy: If no matching interface was explicitly provided by the user, query the contract returned by `addr()`, returning its address if the requested interface is supported by that contract, and 0 otherwise. If they do this, they MUST ensure they return 0, rather than reverting, if the target contract reverts. 35 | 36 | This field may be used with both forward resolution and reverse resolution. 37 | 38 | ## 原理阐述 39 | 40 | A naive approach to this problem would involve adding this method directly to the target contract. However, doing this has several shortcomings: 41 | 42 | 1. Each contract must maintain its own list of interface implementations. 43 | 2. Modifying this list requires access controls, which the contract may not have previously required. 44 | 3. Support for this must be designed in when the contract is written, and cannot be retrofitted afterwards. 45 | 4. Only one canonical list of interfaces can be supported. 46 | 47 | Using ENS resolvers instead mitigates these shortcomings, making it possible for anyone to associate interfaces with a name, even for contracts not previously built with this in mind. 48 | 49 | ## 向后兼容 50 | There are no backwards compatibility issues. 51 | 52 | ## 测试用例 53 | TBD 54 | 55 | ## 实现 56 | The PublicResolver in the [ensdomains/resolvers](https://github.com/ensdomains/resolvers/) repository implements this interface. 57 | 58 | ## 版权 59 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 60 | -------------------------------------------------------------------------------- /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: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2019-03-31 10 | --- 11 | 12 | # Commitment to Sustainable Ecosystem Funding 13 | 14 | ## 简要说明 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 | ## 摘要 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 | ## 动机 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 | ## 规范 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 | ## 原理阐述 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 | ## 向后兼容 41 | 42 | This EIP has no impact on backwards compatibility. 43 | 44 | ## 测试用例 45 | 46 | This EIP makes no changes to existing state transitions. Existing consensus tests should be sufficient. 47 | 48 | ## 实现 49 | 50 | Reference implementations are included for the Trinity, go-ethereum, and parity clients. 51 | 52 | ## 版权 53 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 54 | -------------------------------------------------------------------------------- /EIPS/eip-191.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 191 3 | title: Signed Data Standard 4 | author: Martin Holst Swende (@holiman), Nick Johnson 5 | status: Draft 6 | type: Standards Track 7 | category: ERC 8 | created: 2016-01-20 9 | --- 10 | 11 | # Abstract 12 | 13 | This ERC proposes a specification about how to handle signed data in Ethereum contracts. 14 | 15 | # Motivation 16 | 17 | Several multisignature wallet implementations have been created which accepts `presigned` transactions. A `presigned` transaction is a chunk of binary `signed_data`, along with signature (`r`, `s` and `v`). The interpretation of the `signed_data` has not been specified, leading to several problems: 18 | 19 | * Standard Ethereum transactions can be submitted as `signed_data`. An Ethereum transaction can be unpacked, into the following components: `RLP` (hereby called `RLPdata`), `r`, `s` and `v`. If there are no syntactical constraints on `signed_data`, this means that `RLPdata` can be used as a syntactically valid `presigned` transaction. 20 | * Multisignature wallets have also had the problem that a `presigned` transaction has not been tied to a particular `validator`, i.e a specific wallet. Example: 21 | 1. Users `A`, `B` and `C` have the `2/3`-wallet `X` 22 | 2. Users `A`, `B` and `D` have the `2/3`-wallet `Y` 23 | 3. User `A` and `B` submites `presigned` transaction to `X`. 24 | 4. Attacker can now reuse their presigned transactions to `X`, and submit to `Y`. 25 | 26 | ## 规范 27 | 28 | We propose the following format for `signed_data` 29 | 30 | ``` 31 | 0x19 <1 byte version> . 32 | ``` 33 | Version `0` has `<20 byte address>` for the version specific data, and the `address` is the intended validator. In the case of a Multisig wallet, that is the wallet's own address . 34 | 35 | The initial `0x19` byte is intended to ensure that the `signed_data` is not valid [RLP](https://github.com/ethereum/wiki/wiki/RLP) 36 | 37 | > For a single byte whose value is in the [0x00, 0x7f] range, that byte is its own RLP encoding. 38 | 39 | That means that any `signed_data` cannot be one RLP-structure, but a 1-byte `RLP` payload followed by something else. Thus, any ERC-191 `signed_data` can never be an Ethereum transaction. 40 | 41 | Additionally, `0x19` has been chosen because since ethereum/go-ethereum#2940 , the following is prepended before hashing in personal_sign: 42 | 43 | ``` 44 | "\x19Ethereum Signed Message:\n" + len(message). 45 | ``` 46 | 47 | Using `0x19` thus makes it possible to extend the scheme by defining a version `0x45` (`E`) to handle these kinds of signatures. 48 | 49 | ### Registry of version bytes 50 | 51 | | Version byte | EIP | Description 52 | | ------------ | -------------- | ----------- 53 | | `0x00` | [191][eip-191] | Data with intended validator 54 | | `0x01` | [712][eip-712] | Structured data 55 | | `0x45` | [191][eip-191] | `personal_sign` messages 56 | 57 | [eip-191]: https://learnblockchain.cn/docs/eips/eip-191.html 58 | [eip-712]: https://learnblockchain.cn/docs/eips/eip-712.html 59 | 60 | ### 示例 61 | 62 | The following snippet has been written in Solidity 0.5.0. 63 | 64 | ```solidity 65 | function submitTransactionPreSigned(address destination, uint value, bytes data, uint nonce, uint8 v, bytes32 r, bytes32 s) 66 | public 67 | returns (bytes32 transactionHash) 68 | { 69 | // Arguments when calculating hash to validate 70 | // 1: byte(0x19) - the initial 0x19 byte 71 | // 2: byte(0) - the version byte 72 | // 3: this - the validator address 73 | // 4-7 : Application specific data 74 | transactionHash = keccak256(abi.encodePacked(byte(0x19),byte(0),address(this),destination, value, data, nonce)); 75 | sender = ecrecover(transactionHash, v, r, s); 76 | // ... 77 | } 78 | ``` 79 | 80 | ## 版权 81 | 82 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 83 | -------------------------------------------------------------------------------- /EIPS/eip-2015.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2015 3 | title: Wallet Update Chain JSON-RPC Method (`wallet_updateChain`) 4 | author: Pedro Gomes (@pedrouid) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2015-wallet-update-chain-json-rpc-method-wallet-updatechain/3274 6 | status: Draft 7 | type: Standards Track 8 | category: Interface 9 | created: 2019-05-12 10 | requires: 155, 1474 11 | --- 12 | 13 | ## 简要说明 14 | Wallets can update the active chain when connected to a Dapp but not vice-versa, with `wallet_updateChain` the Dapp will be able to request this change from the Wallet. 15 | 16 | ## 摘要 17 | Dapp can request the Wallet to switch chains by providing the minimal parameters of `chainId`, `networkId`, `rpcUrl` and `nativeCurrency`. The Wallet will display a UI element to inform the user of this change. 18 | 19 | ## 动机 20 | Wallet and Dapp communication rely on the present provider that acts as middleware between the two. Using JSON-RPC methods, the Dapp is able to access not only the active accounts but also the active chain. With [EIP-1102](eip-1102.html) we introduced the ability for Dapps to request access to the active accounts and the Wallet is able to provide a simple UI to inform the user of this action however the same is not currently possible for switching chains. The current pattern is to display some UI to request the user to switch chains within the Dapp, however this could be easily improved by triggering a UI from the Wallet side that can be approved or rejected by the user instead. 21 | 22 | ## 规范 23 | The JSON RPC method will be part of `wallet_` namespaced methods which aim to improve the UX and interoperability between Dapps and Wallets. 24 | 25 | ### Required Parameters 26 | - chainId (number): the id of the chain complaint with EIP-155 27 | - networkId (number): the id of the chain's network 28 | - rpcUrl (string): the url endpoint for RPC requests for this chain 29 | - nativeCurrency (Object): includes two fields for `name` (string) and `symbol` (string) 30 | 31 | 32 | ### Best Practices 33 | - The Wallet should display a UI view similar to a [EIP-1102](eip-1102.html) informing the user that the currently connected Dapp wants to switch to the specified chain. 34 | - the Wallet should default the rpcUrl to any existing endpoints matching a chainId known previously to the wallet, otherwise it will use the provided rpcUrl as a fallback. 35 | - the Wallet should call the rpcUrl with `net_version` and `eth_chainId` to verify the provided chainId and networkId match the responses from the rpcUrl 36 | - the Wallet should change all nativeCurrency symbols to the provided parameter 37 | 38 | ### 示例 1 39 | A JSON-RPC request from a Dapp to switch the Ethereum Goerli chain would be as follows: 40 | ```json 41 | { 42 | "id":1, 43 | "jsonrpc": "2.0", 44 | "method": "wallet_updateChain", 45 | "params": [ 46 | { 47 | "chainId": 5, 48 | "networkId": 5, 49 | "rpcUrl": "https://goerli.infura.io/v3/406405f9c65348f99d0d5c27104b2213", 50 | "nativeCurrency": { 51 | "name": "Goerli ETH", 52 | "symbol": "gorETH" 53 | } 54 | } 55 | ] 56 | } 57 | ``` 58 | 59 | ### 示例 2 60 | A JSON-RPC request from a Dapp to switch the POA Network's xDAI chain would be as follows: 61 | ```json 62 | { 63 | "id":1, 64 | "jsonrpc": "2.0", 65 | "method": "wallet_updateChain", 66 | "params": [ 67 | { 68 | "chainId": 100, 69 | "networkId": 100, 70 | "rpcUrl": "https://dai.poa.network", 71 | "nativeCurrency": { 72 | "name": "xDAI", 73 | "symbol": "xDAI" 74 | } 75 | } 76 | ] 77 | } 78 | ``` 79 | 80 | ## 版权 81 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 82 | -------------------------------------------------------------------------------- /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: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2019-05-17 10 | requires: 214, 1352 11 | --- 12 | 13 | ## 简要说明 14 | 15 | This change reduces the gas cost of using precompiled contracts. 16 | 17 | ## 摘要 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 | ## 动机 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 | ## 规范 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 | ## 原理阐述 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 | ## 向后兼容 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 | ## 测试用例 48 | 49 | TBA 50 | 51 | ## 实现 52 | 53 | TBA 54 | 55 | ## 参考引用 56 | 57 | This has been previously suggested as part of [EIP-1109](https://github.com/ethereum/EIPs/pull/1109) 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 | ## 版权 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]: https://learnblockchain.cn/docs/eips/eip-1352.html 70 | -------------------------------------------------------------------------------- /EIPS/eip-2069.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2069 3 | title: Recommendation for using YAML ABI in ERCs/EIPs 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-2069-recommendation-for-using-yaml-abi-in-specifications/3347 6 | status: Draft 7 | type: Informational 8 | created: 2017-02-11 9 | --- 10 | 11 | ## Simple Summary 12 | 13 | Recommendation for including contract ABI descriptions in EIPs and ERCs as YAML. 14 | 15 | ## Motivation 16 | 17 | In the past, most ERCs/EIPs included an ABI description purely as a Solidity contract and/or interface. This has several drawbacks: 18 | - Prefers a single language over others and could hinder the development of new languages. 19 | - Locks the specification to a certain version of the Solidity language. 20 | - Allows the use of syntactical elements and features of the Solidity language, which may not be well representable in the ABI. This puts other languages at even more disadvantage. 21 | 22 | This proposal aims to solve all these issues. 23 | 24 | ## Specification 25 | 26 | The [Standard Contract ABI] is usually represented as a JSON object. This works well and several tools – including compilers and clients – support it to handle data encoding. 27 | 28 | One shortcoming of the JSON description is its inability to contain comments. To counter this, we suggest the use of YAML for providing user readable specifications. Given YAML was designed to be compatible with JSON, several tools exists to convert between the two formats. 29 | 30 | The following example contains a single function, `transfer` with one input and one output in YAML: 31 | 32 | ```yaml 33 | # The transfer function. Takes the recipient address 34 | # as an input and returns a boolean signaling the result. 35 | - name: transfer 36 | type: function 37 | payable: false 38 | constant: false 39 | stateMutability: nonpayable 40 | inputs: 41 | - name: recipient 42 | type: address 43 | - name: amount 44 | type: uint256 45 | outputs: 46 | - name: '' 47 | type: bool 48 | ``` 49 | 50 | Specifications are encouraged to include comments in the YAML ABI. 51 | 52 | For details on what fields and values are valid in the ABI, please consult the [Standard Contract ABI] specification. 53 | 54 | The same in JSON: 55 | 56 | ```json 57 | [ 58 | { 59 | "name": "transfer", 60 | "type": "function", 61 | "payable": false, 62 | "constant": false, 63 | "stateMutability": "nonpayable", 64 | "inputs": [ 65 | { 66 | "name": "recipient", 67 | "type": "address" 68 | }, 69 | { 70 | "name": "amount", 71 | "type": "uint256" 72 | } 73 | ], 74 | "outputs": [ 75 | { 76 | "name": "", 77 | "type": "bool" 78 | } 79 | ] 80 | } 81 | ] 82 | ``` 83 | 84 | ## Rationale 85 | 86 | The aim was to chose a representation which is well supported by tools and supports comments. While inventing a more concise description language seems like a good idea, it felt as an unnecessary layer of complexity. 87 | 88 | ## Backwards Compatibility 89 | 90 | This has no effect on backwards compatibility. 91 | 92 | ## Test Cases 93 | 94 | TBA 95 | 96 | ## Implementation 97 | 98 | [yamabi] is a Javascript tool to convert between the above YAML and the more widely used JSON format. 99 | 100 | ## Copyright 101 | 102 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 103 | 104 | [Standard Contract ABI]: https://solidity.readthedocs.io/en/latest/abi-spec.html 105 | [yamabi]: https://github.com/axic/yamabi/ 106 | -------------------------------------------------------------------------------- /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: Draft 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 | - Activation: TBD 20 | 21 | ### Included EIPs 22 | 23 | - TBD 24 | 25 | ### Accepted EIPs 26 | 27 | - TBD 28 | 29 | ### Tentatively Accepted EIPs 30 | 31 | - [EIP-663](https://eips.ethereum.org/EIPS/eip-663): Unlimited SWAP and DUP instructions 32 | - [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic 33 | Proof-of-Work 34 | - There is a 35 | [pending audit](https://medium.com/ethereum-cat-herders/progpow-audit-goals-expectations-75bb902a1f01), 36 | above and beyond standard security considerations, that should be evaluated 37 | prior to inclusion. 38 | - [EIP-1380](https://eips.ethereum.org/EIPS/eip-1380): Reduced gas cost for call to self 39 | - [EIP-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme 40 | - [EIP-1962](https://eips.ethereum.org/EIPS/eip-1962): EC arithmetic and pairings with runtime definitions 41 | - replaces EIP-1829 42 | - [EIP-1985](https://eips.ethereum.org/EIPS/eip-1985): Sane limits for certain EVM parameters 43 | - [EIP-2045](https://eips.ethereum.org/EIPS/eip-2045): Particle gas costs for EVM opcodes 44 | - [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles 45 | 46 | ### Proposed EIPs 47 | 48 | - TBD 49 | 50 | ## Timeline 51 | 52 | - TBD 53 | 54 | ## References 55 | 56 | - TBD 57 | 58 | ## Copyright 59 | 60 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 61 | -------------------------------------------------------------------------------- /EIPS/eip-2135.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 2135 3 | title: Consumable Interface 4 | author: Zainan Victor Zhou (@xinbenlv) 5 | discussions-to: https://github.com/ethereum/EIPs/issues/2135 6 | status: Draft 7 | type: Standards Track 8 | category: ERC 9 | created: 2019-06-23 10 | --- 11 | 12 | ## 简要说明 13 | An interface marking certain digital assets being consumable. 14 | 15 | ## 摘要 16 | The interface identifies functions and events needed for creating a contract to be able to mark a digital asset as "consumable", and react to the request of "consumption". 17 | 18 | ## 动机 19 | Being a digital assets sometimes means a consumable power. One most common seen examples would be a concert ticket. It will be "consumed" at the moment the ticket-holder uses the ticket to get access to enter a concert. 20 | 21 | By having a standard ERC interface, the Ethereum ecosystem can interoperate to provide services, clients, UI, and inter-contract functionalities on top of this very general use-case. 22 | 23 | ## 规范 24 | The standard will mainly contain the following interface. 25 | 26 | ### The required interface 27 | 28 | ```solidity 29 | pragma solidity ^0.5.8; 30 | 31 | contract EIP2135 { 32 | // The main consume function 33 | function consume(uint256 assetId) public returns(bool success); 34 | 35 | // The interface to check whether an asset is consumable. 36 | function isConsumable(uint256 assetId) public view returns (bool consumable); 37 | 38 | // The interface to check whether an asset is consumable. 39 | event OnConsumption(uint256 indexed assetId); 40 | } 41 | ``` 42 | 43 | ## 原理阐述 44 | 45 | The function `consume` performs the consume action. Being an interface standard, 46 | this EIP does not impose any assumption of 47 | 48 | - who has the power to perform such activity. 49 | - under what condition such consumption can occur. 50 | 51 | It does, however, assume the asset can be identified in a `uint256` assetId as in th parameter. A design convention and compatibility consideration is put in place to follow the ERC-721 52 | 53 | The event notifies subscribers whoever are interested to learn an asset is being consumed. The boolean function of `isConsumable` can be used to check whether an asset is still consumable. 54 | 55 | To keep it simple, this standard *intentionally* contains no functions or events related to creation of a consumable asset. This is because the creation of a consumable asset will need to make assumption of the nature of an actual use-case. If we see some common use-case of creation, we can have another follow up standard. 56 | 57 | We also left out metadata associated to the consumables from the standard. If necessary, related metadata can be created with a separate metadata extension interface like [`ERC721Metadata`](eip-721.html) 58 | 59 | ## 向后兼容 60 | 61 | This interface is designed to be compatible with ERC-721. 62 | 63 | ## 实现 64 | 65 | A reference implementation accompany with tests of **ERC-721 based ticket** contract is built and you can found it [here](https://github.com/xinbenlv/eip-2135/blob/master/impl/contracts/Ticket721.sol). 66 | 67 | See [Github/xinbenlv/eip-2135/impl](https://github.com/xinbenlv/eip-2135/tree/master/impl) 68 | 69 | ## 测试用例 70 | 71 | See [Github/xinbenlv/eip-2135/impl/test](https://github.com/xinbenlv/eip-2135/tree/master/impl/test) 72 | 73 | ## Reference 74 | 75 | ### Standards 76 | - [ERC-721](eip-721.html) 77 | 78 | ## 版权 79 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 80 | -------------------------------------------------------------------------------- /EIPS/eip-214.md: -------------------------------------------------------------------------------- 1 | # EIP 214: 操作码 STATICCALL 2 | 3 | 4 | | 作者 | 类型 | 分类 | 状态 | 创建时间 | 5 | | --- | --- | --- | --- | --- | --- | 6 | |Vitalik Buterin, Christian Reitwiessner | Standards Track | Core | 最终 | 2017-02-13 | 7 | 8 | 9 | 10 | ## 简要说明 11 | 12 | To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). 13 | 14 | ## 摘要 15 | 16 | This proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). Any opcode that attempts to perform such a modification (see below for details) will result in an exception instead of performing the modification. 17 | 18 | ## 动机 19 | 20 | Currently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. This poses certain difficulties about smart contract engineers; after a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. Furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases. 21 | 22 | This EIP adds a way to call other contracts and restrict what they can do in the simplest way. It can be safely assumed that the state of all accounts is the same before and after a static call. 23 | 24 | ## 规范 25 | 26 | Introduce a new `STATIC` flag to the virtual machine. This flag is set to `false` initially. Its value is always copied to sub-calls with an exception for the new opcode below. 27 | 28 | Opcode: `0xfa`. 29 | 30 | `STATICCALL` functions equivalently to a `CALL`, except it takes only 6 arguments (the "value" argument is not included and taken to be zero), and calls the child with the `STATIC` flag set to `true` for the execution of the child. Once this call returns, the flag is reset to its value before the call. 31 | 32 | Any attempts to make state-changing operations inside an execution instance with `STATIC` set to `true` will instead throw an exception. These operations include `CREATE`, `CREATE2`, `LOG0`, `LOG1`, `LOG2`, `LOG3`, `LOG4`, `SSTORE`, and `SELFDESTRUCT`. They also include `CALL` with a non-zero value. As an exception, `CALLCODE` is not considered state-changing, even with a non-zero value. 33 | 34 | ## 原理阐述 35 | 36 | This allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else. This may also make purely functional HLLs easier to implement. 37 | 38 | ## 向后兼容 39 | 40 | This proposal adds a new opcode but does not modify the behaviour of other opcodes and thus is backwards compatible for old contracts that do not use the new opcode and are not called via the new opcode. 41 | 42 | ## 测试用例 43 | 44 | To be written. 45 | 46 | ## 实现 47 | 48 | ## 版权 49 | 50 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 51 | -------------------------------------------------------------------------------- /EIPS/eip-3.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 3 3 | title: Addition of CALLDEPTH opcode 4 | author: Martin Holst Swende 5 | status: Draft 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-4.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 4 3 | title: EIP Classification 4 | author: Joseph Chow (@ethers) 5 | status: Superseded 6 | type: Meta 7 | created: 2015-11-17 8 | superseded-by: 1 9 | --- 10 | 11 | # Abstract 12 | 13 | This document describes a classification scheme for EIPs, adapted from [BIP 123](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki). 14 | 15 | EIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. 16 | 17 | The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards EIP belongs. 18 | 19 | # Motivation 20 | 21 | Ethereum is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them. 22 | 23 | In order to have a EIP process which more closely reflects the interoperability requirements, it is necessary to categorize EIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed. 24 | 25 | # Specification 26 | 27 | Standards EIPs are placed in one of four layers: 28 | 29 | 1. Consensus 30 | 2. Networking 31 | 3. API/RPC 32 | 4. Applications 33 | 34 | # 1. Consensus Layer 35 | 36 | The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence. 37 | 38 | The consensus layer is not concerned with how messages are propagated on a network. 39 | 40 | Disagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks. 41 | 42 | ## Soft Forks 43 | 44 | In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules. 45 | 46 | ## Hard Forks 47 | 48 | In a hard fork, structures that were invalid under the old rules become valid under the new rules. 49 | 50 | # 2. Networking Layer 51 | 52 | The networking layer specifies the Ethereum wire protocol (eth) and the Light Ethereum Subprotocol (les). RLPx is excluded and tracked in the [https://github.com/ethereum/devp2p devp2p repository]. 53 | 54 | Only a subset of subprotocols are required for basic node interoperability. Nodes can support further optional extensions. 55 | 56 | It is always possible to add new subprotocols without breaking compatibility with existing protocols, then gradually deprecate older protocols. In this manner, the entire network can be upgraded without serious risks of service disruption. 57 | 58 | 59 | # 3. API/RPC Layer 60 | 61 | The API/RPC layer specifies higher level calls accessible to applications. Support for these EIPs is not required for basic network interoperability but might be expected by some client applications. 62 | 63 | There's room at this layer to allow for competing standards without breaking basic network interoperability. 64 | 65 | # 4. Applications Layer 66 | 67 | The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data. 68 | -------------------------------------------------------------------------------- /EIPS/eip-6.md: -------------------------------------------------------------------------------- 1 | # EIP 6: 重命名 SUICIDE 操作码 2 | 3 | 4 | | 作者 | 状态 | 类型 | 分类 | 创建时间 | 5 | | --- | --- | --- | --- | --- | 6 | | Hudson Jameson | 最终 | Standards Track | Interface | 2015-11-22 | 7 | 8 | 9 | ## 摘要 10 | The solution proposed in this EIP is to change the name of the `SUICIDE` opcode in Ethereum programming languages with `SELFDESTRUCT`. 11 | 12 | ## 动机 13 | 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. 14 | 15 | 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: 16 | > 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. 17 | 18 | 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 it's life. 19 | 20 | ## 实现 21 | `SELFDESTRUCT` is added as an alias of `SUICIDE` opcode (rather than replacing it). 22 | https://github.com/ethereum/solidity/commit/a8736b7b271dac117f15164cf4d2dfabcdd2c6fd 23 | https://github.com/ethereum/serpent/commit/1106c3bdc8f1bd9ded58a452681788ff2e03ee7c 24 | -------------------------------------------------------------------------------- /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: Draft 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 | ## 摘要 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 | ## 动机 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 | ## 规范 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 | ## 原理阐述 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 | ## 向后兼容 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 | ## 测试用例 56 | TBD 57 | 58 | ## 实现 59 | None yet. 60 | 61 | ## 参考引用 62 | [This discussion on derivation paths](https://github.com/ethereum/EIPs/issues/84) 63 | 64 | ## 版权 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 | ## 摘要 12 | 13 | This specifies the changes included in the hard fork named Homestead. 14 | 15 | ## 规范 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](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2.md) (Homestead Hard-fork Changes) 24 | - [EIP 7](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7.md) (DELEGATECALL) 25 | - [EIP 8](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md) (Networking layer: devp2p Forward Compatibility Requirements for Homestead) 26 | 27 | ## 参考引用 28 | 29 | 1. https://blog.ethereum.org/2016/02/29/homestead-release/ 30 | 31 | ## 版权 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 | ## 摘要 12 | 13 | This specifies the changes included in the hard fork named Spurious Dragon. 14 | 15 | ## 规范 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.html) (Simple replay attack protection) 24 | - [EIP 160](eip-160.html) (EXP cost increase) 25 | - [EIP 161](eip-161.html) (State trie clearing) 26 | - [EIP 170](eip-170.html) (Contract code size limit) 27 | 28 | ## 参考引用 29 | 30 | 1. https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/ 31 | 32 | ## 版权 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 | ## 摘要 12 | 13 | This specifies the changes included in the hard fork named Tangerine Whistle (EIP 150). 14 | 15 | ## 规范 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](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-150.md) (Gas cost changes for IO-heavy operations) 23 | 24 | ## 参考引用 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 | ## 版权 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 | ## 摘要 12 | 13 | This specifies the changes included in the hard fork named Byzantium. 14 | 15 | ## 规范 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.html) (Change difficulty adjustment to target mean block time including uncles) 24 | - [EIP 140](eip-140.html) (REVERT instruction in the Ethereum Virtual Machine) 25 | - [EIP 196](eip-196.html) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) 26 | - [EIP 197](eip-197.html) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) 27 | - [EIP 198](eip-198.html) (Precompiled contract for bigint modular exponentiation) 28 | - [EIP 211](eip-211.html) (New opcodes: RETURNDATASIZE and RETURNDATACOPY) 29 | - [EIP 214](eip-214.html) (New opcode STATICCALL) 30 | - [EIP 649](eip-649.html) (Difficulty Bomb Delay and Block Reward Reduction) 31 | - [EIP 658](eip-658.html) (Embedding transaction status code in receipts) 32 | 33 | ## 参考引用 34 | 35 | 1. https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/ 36 | 37 | ## 版权 38 | 39 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 40 | -------------------------------------------------------------------------------- /EIPS/eip-634.md: -------------------------------------------------------------------------------- 1 | # EIP 634: ENS 文本记录的存储 2 | 3 | | 作者 | 类型 | 分类 | 状态 | 创建时间 | 4 | | --- | --- | --- | --- | --- | 5 | | Richard Moore | Standards Track | ERC | Draft | 2017-05-17 6 | 7 | 8 | ## 摘要 9 | This EIP defines a resolver profile for ENS that permits the lookup of arbitrary key-value 10 | text data. This allows ENS name holders to associate e-mail addresses, URLs and other 11 | informational data with a ENS name. 12 | 13 | 14 | ## 动机 15 | There is often a desire for human-readable metadata to be associated with otherwise 16 | machine-driven data; used for debugging, maintenance, reporting and general information. 17 | 18 | In this EIP we define a simple resolver profile for ENS that permits ENS names to 19 | associate arbitrary key-value text. 20 | 21 | 22 | ## 规范 23 | 24 | ### Resolver Profile 25 | A new resolver interface is defined, consisting of the following method: 26 | 27 | function text(bytes32 node, string key) constant returns (string text); 28 | 29 | The interface ID of this interface is 0x59d1d43c. 30 | 31 | The `text` data may be any arbitrary UTF-8 string. If the key is not present, the empty string 32 | must be returned. 33 | 34 | 35 | ### Initial Recommended Keys 36 | 37 | Keys must be made up of lowercase letters, numbers and the hyphen (-). Vendor specific 38 | services must be prefixed with `vnd.`. 39 | 40 | - **email** - an e-mail address 41 | - **url** - a URL 42 | - **avatar** - a URL to an image used as an avatar or logo 43 | - **description** - A description of the name 44 | - **notice** - A notice regarding this name; 45 | - **keywords** - A list of comma-separated keywords, ordered by most significant first; clients that interpresent this field may choose a threshold beyond which to ignore 46 | - **vnd.twitter** - a twitter username (SHOULD not be prefixed with an @ symbol) 47 | - **vnd.github** - a GitHub username (SHOULD not be prefixed with an @ symbol) 48 | 49 | 50 | ## 原理阐述 51 | 52 | ### Application-specific vs general-purpose record types 53 | Rather than define a large number of specific record types (each for generally human-readable 54 | data) such as `url` and `email`, we follow an adapted model of DNS's `TXT` records, which allow 55 | for a general keys and values, allowing future extension without adjusting the resolver, while 56 | allowing applications to use custom keys for their own purposes. 57 | 58 | ## 向后兼容 59 | Not applicable. 60 | 61 | ## 测试用例 62 | TBD 63 | 64 | ## 实现 65 | None yet. 66 | 67 | ## 版权 68 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 69 | -------------------------------------------------------------------------------- /EIPS/eip-658.md: -------------------------------------------------------------------------------- 1 | # EIP 658: 在收据中嵌入交易状态代码 2 | 3 | | 作者 | 状态 | 类型 | 分类 | 创建时间 | 依赖 | 4 | | --- | --- | --- | --- | --- | --- | --- 5 | | Nick Johnson | 最终 | Standards Track | Core | 2017-06-30 | [140](eip-140.md) | 6 | 7 | 8 | 9 | ## 摘要 10 | This EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed. 11 | 12 | ## 动机 13 | 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. 14 | 15 | 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. 16 | 17 | 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. 18 | 19 | ## 规范 20 | 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. 21 | 22 | ## 原理阐述 23 | 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. 24 | 25 | ## 版权 26 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 27 | -------------------------------------------------------------------------------- /EIPS/eip-663.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 663 3 | title: Unlimited SWAP and DUP instructions 4 | author: Alex Beregszaszi (@axic) 5 | discussions-to: https://ethereum-magicians.org/t/eip-663-unlimited-swap-and-dup-instructions/3346 6 | type: Standards Track 7 | category: Core 8 | status: Draft 9 | created: 2017-07-03 10 | --- 11 | 12 | ## 摘要 13 | 14 | Currently, `SWAP` and `DUP` instructions are limited to a stack depth of 16. Introduce two new instructions, `SWAPn` and `DUPn`, which lift this limitation and allow accessing the stack up to its full depth of 1024 items. 15 | 16 | ## 动机 17 | 18 | Implementing higher level constructs, such as functions, on top of EVM will result in a list of input and output parameters as well as an instruction offset to return to. 19 | 20 | The number of these arguments (or stack items) can easily exceed 16 and thus will require extra care from a compiler to lay them out in a way that all of them are still accessible. 21 | 22 | Introducing `SWAPn` and `DUPn` will provide an option to compilers to simplify accessing deep stack items at the price of possibly increased gas costs. 23 | 24 | ## 规范 25 | 26 | ### Option A 27 | 28 | Instructions `DUPn` (`0xb0`) and `SWAPn` (`0xb1`) are introduced, which take the top item from stack (referred to as `n`). 29 | 30 | If `n` exceeds 1024 or the current stack depth is less than `n`, then a stack underflow exception is issued. If the current stack depth is at the limit, a stack overflow exception is issued. 31 | In both of these cases the EVM stops and all gas is consumed. 32 | 33 | Otherwise 34 | - for `DUPn` the stack item at depth `n` is duplicated at the top of the stack 35 | - for `SWAPn` the top stack item is swapped with the item at depth `n` 36 | 37 | The gas cost for both instructions is set at 3. In reality the cost for such an operation is 6 including the required `PUSH`. 38 | 39 | Since both of these instructions require the top stack item to contain the position, it is still only possible to reach more than 16 stack items if there is at least one free stack slot. 40 | 41 | This option has no effect no static analyzers, given no immediate value is introduced. 42 | 43 | ### Option A+ 44 | 45 | The difference to Option A is that `DUPn` and `SWAPn` must be preceded by a `PUSHn` opcode. Encountering `DUPn` and `SWAPn` without a preceding `PUSHn` results in out of gas. 46 | 47 | ### Option B 48 | 49 | The difference to Option A is that `DUPn` and `SWAPn` do not take the value of `n` from the top stack item, but instead encode it as a 16-bit big endian immediate value following the opcode. 50 | 51 | This results in wasting a byte in the cases of only referring to the top 255 stack items. 52 | 53 | ### Option C 54 | 55 | This option extends Option B with two new instructions, `DUPSn` (`0xb2`) and `SWAPSn` (`0xb3`), where the value of `n` is encoded as an 8-bit immediate value following the opcode. 56 | 57 | The value `n` has a range of 0 to 255, but otherwise the same rules apply as in Option A. 58 | 59 | ## 原理阐述 60 | 61 | TBA 62 | 63 | ## 向后兼容 64 | 65 | This has no effect on backwards compatibility. 66 | 67 | ## 测试用例 68 | 69 | - executing `602a600160026003600460056006600760086009600a600b600c600d600e600f60106011b0` should have `42` as the top stack item 70 | - executing `602a600160026003600460056006600760086009600a600b600c600d600e600f60106011b1` should have `42` as the top stack item 71 | 72 | ## 实现 73 | 74 | TBA 75 | 76 | ## 参考引用 77 | 78 | A similar proposal was made with [EIP-174](https://github.com/ethereum/EIPs/issues/174). Read the thread for some detailed discussion. 79 | 80 | Rootstock [RSKIP26](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP26.md) also introduced `SWAPN` and `DUPN` with Option A described above. 81 | 82 | ## 版权 83 | 84 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 85 | -------------------------------------------------------------------------------- /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: Draft 8 | created: 2017-08-15 9 | --- 10 | 11 | ## 简要说明 12 | 13 | This EIP proposes to make contract creation fail on an account with nonempty code or non-zero nonce. 14 | 15 | ## 摘要 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 | ## 动机 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](https://github.com/ethereum/EIPs/pull/208) 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 | ## 规范 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 | ## 原理阐述 34 | 35 | It seems impractical to implement never-used features just for passing tests. Client implementations will be simpler with this EIP. 36 | 37 | ## 向后兼容 38 | 39 | This EIP is backwards compatible on the main network. 40 | 41 | ## 测试用例 42 | 43 | At least the BlockchainTest called `createJS\_ExampleContract\_d0g0v0\_EIP158` will distinguish clients that implement this EIP. 44 | 45 | ## 实现 46 | 47 | ## 版权 48 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 49 | -------------------------------------------------------------------------------- /EIPS/eip-695.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 695 3 | title: Create `eth_chainId` method for JSON-RPC 4 | author: Isaac Ardis , Wei Tang (@sorpaas), Fan Torchz (@tcz001) 5 | discussions-to: https://ethereum-magicians.org/t/eip-695-create-eth-chainid-method-for-json-rpc/1845 6 | type: Standards Track 7 | category: Interface 8 | status: Last Call 9 | review-period-end: 2019-07-20 10 | created: 2017-08-21 11 | requires: 155, 1474 12 | --- 13 | 14 | ## 简要说明 15 | 16 | Include `eth_chainId` method in `eth_`-namespaced JSON-RPC methods. 17 | 18 | ## 摘要 19 | 20 | The `eth_chainId` method should return a single STRING result 21 | for an integer value in hexadecimal format, describing the 22 | currently configured `CHAIN_ID` value used for signing replay-protected transactions, 23 | introduced via [EIP-155](./eip-155.md). 24 | 25 | ## 动机 26 | 27 | Currently although we can use `net_version` RPC call to get the 28 | current network ID, there's no RPC for querying the chain ID. This 29 | makes it impossible to determine the current actual blockchain using 30 | the RPC. 31 | 32 | ## 规范 33 | 34 | ### `eth_chainId` 35 | 36 | Returns the currently configured chain ID, a value used in replay-protected transaction 37 | signing as introduced by [EIP-155](./eip-155.md). 38 | 39 | #### 参数 40 | 41 | None. 42 | 43 | #### Returns 44 | 45 | `QUANTITY` - integer of the current chain ID. 46 | 47 | #### 示例 48 | 49 | ```js 50 | curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' 51 | 52 | // Result 53 | { 54 | "id": 83, 55 | "jsonrpc": "2.0", 56 | "result": "0x3d" // 61 57 | } 58 | ``` 59 | 60 | ## 原理阐述 61 | 62 | An ETH/ETC client can accidentally connect to an ETC/ETH RPC 63 | endpoint without knowing it unless it tries to sign a transaction or 64 | it fetch a transaction that is known to have signed with a chain 65 | ID. This has since caused trouble for application developers, such as 66 | MetaMask, to add multi-chain support. 67 | 68 | ## 向后兼容 69 | 70 | Not relevant. 71 | 72 | ## 实现 73 | 74 | - [Parity PR](https://github.com/paritytech/parity/pull/6329) 75 | - [Geth PR](https://github.com/ethereum/go-ethereum/pull/17617) 76 | - [Geth Classic PR](https://github.com/ethereumproject/go-ethereum/pull/336) 77 | 78 | ## Reference 79 | 80 | Return value `QUANTITY` adheres to standard JSON RPC hex value encoding, as documented here: https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding. 81 | 82 | ## 版权 83 | 84 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 85 | -------------------------------------------------------------------------------- /EIPS/eip-698.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 698 3 | title: OPCODE 0x46 BLOCKREWARD 4 | author: Cody Burns 5 | discussions-to: https://github.com/ethereum/EIPs/issues/698 6 | status: Draft 7 | type: Standards Track 8 | category: Core 9 | created: 2017-28-08 10 | --- 11 | 12 | ## 简要说明 13 | 14 | This EIP adds an additional opcode to the EVM which will return a finalized blocks reward value. 15 | 16 | ## 摘要 17 | 18 | In the EVM, the 0x40 opcodes are reserved for `Block Information`. Currently reserved opcodes are: 19 | * `0X40 BLOCKHASH` 20 | * `0X41 COINBASE` 21 | * `0X42 TIMESTAMP` 22 | * `0X43 NUMBER` 23 | * `0X44 DIFFICULTY` 24 | * `0X45 GASLIMIT` 25 | 26 | This EIP would add an additional opcode, `0x46 BLOCKREWARD`, which would return the block reward for any finalized block. The finalized block reward would include the base reward, uncle payments, and gas. 27 | 28 | ## 动机 29 | 30 | 31 | Per EIP-649 ( #669 ) periodic block reward reductions/variance are now planned in the roadmap, however, this EIP is consensus system agnostic and is most useful in decentralized pool operations and for any contract that benefits from knowing a block reward payout(i.e. Merge mined tokens) 32 | 33 | ## 规范 34 | 35 | After block `n` all clients should process opcode `0x46` as follows: 36 | 37 | * Value: `0x46` 38 | * Mnemonic: `BLOCKREWARD` 39 | * δ:` 0` nothing removed from stack 40 | * α:`1` block reward added to stack 41 | * Description: `Get the block's reward emission` 42 | * GasCost: `Gbase` 43 | 44 | Where:`µ's[0] ≡ IHR` 45 | 46 | 47 | ## 原理阐述 48 | 49 | ### Contract Mining Pools 50 | 51 | For distributed consensus systems(staking pools and mining pools) ad hoc groups combine resources in order to reduce variance in payouts. Broadly, pool operations function by allowing a collective of miners / stakers to verify their contribution to solving PoW or staking share by periodically submitting solutions which are is representative of the miners probability of finding a true block. 52 | 53 | In all these schemes `B` stands for a block reward minus pool fee and `p` is a probability of finding a block in a share attempt ( `p=1/D`, where `D` is current block difficulty). 54 | 55 | Some common methods of mining pool payout are pay-per-share, `R = B * p`, proportional [`R = B * (n/N)` where `n` is amount of a miners shares, and `N` is amount of all shares in this round.], and pay-per-last-N-shares [`R = B * (n/N)` where miner's reward is calculated on a basis of `N` last shares, instead of all shares for the last round]. All of these methods are predicated on knowing the block reward paid for a given block. In order to provide a trust minimized solution, `0x46` can be used to call a blocks reward for computing payouts. 56 | 57 | ### Merge mined tokens 58 | 59 | Contracts could create tokens which could be variably ‘minted’ as a function of block reward by calling `0x46` 60 | 61 | ## 向后兼容 62 | 63 | 64 | ### Currently deployed contracts 65 | 66 | No impact 67 | 68 | ### Current clients 69 | 70 | This EIP would be incompatible with currently deployed clients that are not able to handle `0x46` and would process all transactions and block containing the opcode as invalid. 71 | 72 | Implementation should occur as part of a coordinated hardfork. 73 | 74 | ## 实现 75 | 76 | 77 | ## Further reading 78 | 79 | [Mining Pools](https://en.wikipedia.org/wiki/Mining_pool) 80 | 81 | The Yellow Paper Appendix H. Virtual Machine Specification section H.2 82 | 83 | ## 版权 84 | 85 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 86 | -------------------------------------------------------------------------------- /EIPS/eip-7.md: -------------------------------------------------------------------------------- 1 | # EIP 7: DELEGATECALL 委托调用操作码 2 | 3 | 4 | | 作者 | 状态 | 类型 | 分类 | 创建时间 | 5 | | --- | --- | --- | --- | --- | 6 | | Vitalik Buterin | Final| Standards Track| Core|2015-11-15| 7 | 8 | 9 | ### Hard Fork 10 | [Homestead](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-606.md) 11 | 12 | ### 参数 13 | - Activation: 14 | - Block >= 1,150,000 on Mainnet 15 | - Block >= 494,000 on Morden 16 | - Block >= 0 on future testnets 17 | 18 | ### Overview 19 | 20 | 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. 21 | 22 | ### 规范 23 | 24 | `DELEGATECALL`: `0xf4`, takes 6 operands: 25 | - `gas`: the amount of gas the code may use in order to execute; 26 | - `to`: the destination address whose code is to be executed; 27 | - `in_offset`: the offset into memory of the input; 28 | - `in_size`: the size of the input in bytes; 29 | - `out_offset`: the offset into memory of the output; 30 | - `out_size`: the size of the scratch pad for the output. 31 | 32 | #### Notes on gas 33 | - The basic stipend is not given; `gas` is the total amount the callee receives. 34 | - Like `CALLCODE`, account creation never happens, so the upfront gas cost is always `schedule.callGas` + `gas`. 35 | - Unused gas is refunded as normal. 36 | 37 | #### Notes on sender 38 | - `CALLER` and `VALUE` behave exactly in the callee's environment as they do in the caller's environment. 39 | 40 | #### Other notes 41 | - The depth limit of 1024 is still preserved as normal. 42 | 43 | ### 原理阐述 44 | 45 | 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. 46 | 47 | Use case 1: split code to get around 3m gas barrier 48 | 49 | ```python 50 | ~calldatacopy(0, 0, ~calldatasize()) 51 | if ~calldataload(0) < 2**253: 52 | ~delegate_call(msg.gas - 10000, $ADDR1, 0, ~calldatasize(), ~calldatasize(), 10000) 53 | ~return(~calldatasize(), 10000) 54 | elif ~calldataload(0) < 2**253 * 2: 55 | ~delegate_call(msg.gas - 10000, $ADDR2, 0, ~calldatasize(), ~calldatasize(), 10000) 56 | ~return(~calldatasize(), 10000) 57 | ... 58 | ``` 59 | 60 | Use case 2: mutable address for storing the code of a contract: 61 | 62 | ```python 63 | if ~calldataload(0) / 2**224 == 0x12345678 and self.owner == msg.sender: 64 | self.delegate = ~calldataload(4) 65 | else: 66 | ~delegate_call(msg.gas - 10000, self.delegate, 0, ~calldatasize(), ~calldatasize(), 10000) 67 | ~return(~calldatasize(), 10000) 68 | ``` 69 | The child functions called by these methods can now freely reference `msg.sender` and `msg.value`. 70 | 71 | ### Possible arguments against 72 | 73 | * 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. 74 | -------------------------------------------------------------------------------- /EIPS/eip-779.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 779 3 | title: "Hardfork Meta: DAO Fork" 4 | author: Casey Detrio (@cdetrio) 5 | type: Meta 6 | status: Final 7 | created: 2017-11-26 8 | requires: 606 9 | --- 10 | 11 | ## 摘要 12 | 13 | This documents the changes included in the hard fork named "DAO Fork". Unlike other hard forks, the DAO Fork did not change the protocol; all EVM opcodes, transaction format, block structure, and so on remained the same. Rather, the DAO Fork was an "irregular state change" that transferred ether balances from a list of accounts ("child DAO" contracts) into a specified account (the "WithdrawDAO" contract). 14 | 15 | ## 规范 16 | 17 | - Codename: DAO Fork 18 | - Activation: 19 | - Block == 1,920,000 on Mainnet 20 | 21 | See references [1] and [2] for the original, full specification. It is summarized here for convenience. 22 | 23 | At block 1880000, the following accounts are encoded into a list `L`: 24 | * The DAO (`0xbb9bc244d798123fde783fcc1c72d3bb8c189413`) 25 | * its extraBalance (`0x807640a13483f8ac783c557fcdf27be11ea4ac7a`) 26 | * all children of the DAO creator (`0x4a574510c7014e4ae985403536074abe582adfc8`) 27 | * and the extraBalance of each child 28 | 29 | At the beginning of block 1920000, all ether throughout all accounts in `L` will be transferred to a contract deployed at `0xbf4ed7b27f1d666546e30d74d50d173d20bca754`. The contract was created from the following Solidity code (compiler version `v0.3.5-2016-07-01-48238c9`): 30 | 31 | ``` 32 | // Deployed on mainnet at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754 33 | 34 | contract DAO { 35 | function balanceOf(address addr) returns (uint); 36 | function transferFrom(address from, address to, uint balance) returns (bool); 37 | uint public totalSupply; 38 | } 39 | 40 | contract WithdrawDAO { 41 | DAO constant public mainDAO = DAO(0xbb9bc244d798123fde783fcc1c72d3bb8c189413); 42 | address public trustee = 0xda4a4626d3e16e094de3225a751aab7128e96526; 43 | 44 | function withdraw(){ 45 | uint balance = mainDAO.balanceOf(msg.sender); 46 | 47 | if (!mainDAO.transferFrom(msg.sender, this, balance) || !msg.sender.send(balance)) 48 | throw; 49 | } 50 | 51 | function trusteeWithdraw() { 52 | trustee.send((this.balance + mainDAO.balanceOf(this)) - mainDAO.totalSupply()); 53 | } 54 | } 55 | ``` 56 | 57 | ## 参考引用 58 | 59 | 1. https://blog.slock.it/hard-fork-specification-24b889e70703 60 | 2. https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork/ 61 | 62 | ## 版权 63 | 64 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 65 | -------------------------------------------------------------------------------- /EIPS/eip-801.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 801 3 | title: ERC-801 Canary Standard 4 | author: ligi 5 | type: Standards Track 6 | category: ERC 7 | status: Draft 8 | created: 2017-12-16 9 | --- 10 | 11 | ## 简要说明 12 | 13 | A standard interface for canary contracts. 14 | 15 | ## 摘要 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 | ## 动机 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 | ## 规范 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 | ## 实现 74 | 75 | TODO 76 | 77 | ## 版权 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: Draft 8 | created: 2018-01-15 9 | --- 10 | 11 | ## 简要说明 12 | 13 | A standard way of creating Ethereum URIs for various use-cases. 14 | 15 | ## 摘要 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 | ## 规范 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 | ## 原理阐述 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 | ## 参考引用 41 | 42 | 1. ERC-681, https://learnblockchain.cn/docs/eips/eip-681.html 43 | 2. ERC-67, https://github.com/ethereum/EIPs/issues/67 44 | 45 | ## 版权 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: Draft 8 | created: 2018-01-29 9 | --- 10 | 11 | ## 简要说明 12 | Reduce the block reward to 1 ETH and delay the difficulty bomb. 13 | 14 | ## 摘要 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 | ## 动机 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 | ## 规范 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 | ## 原理阐述 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 | ## 向后兼容 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 | ## 测试用例 36 | Tests have, as yet, not been completed. 37 | 38 | ## 实现 39 | No implementation including both block reward and difficulty adjustment is currently available. 40 | 41 | ## 版权 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: Draft 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). 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. 86 | -------------------------------------------------------------------------------- /EIPS/eip-897.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 897 3 | title: ERC DelegateProxy 4 | author: Jorge Izquierdo , Manuel Araoz 5 | type: Standards Track 6 | category: ERC 7 | status: Draft 8 | created: 2018-02-21 9 | discussions-to: https://github.com/ethereum/EIPs/pull/897 10 | --- 11 | 12 | ## 简要说明 13 | Proxy contracts are being increasingly used as both as an upgradeability mechanism 14 | and a way to save gas when deploying many instances of a particular contract. This 15 | standard proposes a set of interfaces for proxies to signal how they work and what 16 | their main implementation is. 17 | 18 | ## 摘要 19 | Using proxies that delegate their own logic to another contract is becoming an 20 | increasingly popular technique for both smart contract upgradeability and creating 21 | cheap clone contracts. 22 | 23 | We don't believe there is value in standardizing any particular implementation 24 | of a DelegateProxy, given its simplicity, but we believe there is a lot of value 25 | in agreeing on an interface all proxies use that allows for a standard way to 26 | operate with proxies. 27 | 28 | ## 实现s 29 | 30 | - **aragonOS**: [AppProxyUpgradeable](https://github.com/aragon/aragonOS/blob/dev/contracts/apps/AppProxyUpgradeable.sol), [AppProxyPinned](https://github.com/aragon/aragonOS/blob/dev/contracts/apps/AppProxyPinned.sol) and [KernelProxy](https://github.com/aragon/aragonOS/blob/dev/contracts/kernel/KernelProxy.sol) 31 | 32 | - **zeppelinOS**: [Proxy](https://github.com/zeppelinos/labs/blob/2da9e859db81a61f2449d188e7193788ca721c65/upgradeability_ownership/contracts/Proxy.sol) 33 | 34 | ## Standardized interface 35 | 36 | ```solidity 37 | interface ERCProxy { 38 | function proxyType() public pure returns (uint256 proxyTypeId); 39 | function implementation() public view returns (address codeAddr); 40 | } 41 | ``` 42 | 43 | ### Code address (`implementation()`) 44 | The returned code address is the address the proxy would delegate calls to at that 45 | moment in time, for that message. 46 | 47 | ### Proxy Type (`proxyType()`) 48 | 49 | Checking the proxy type is the way to check whether a contract is a proxy at all. 50 | When a contract fails to return to this method or it returns 0, it can be assumed 51 | that the contract is not a proxy. 52 | 53 | It also allows for communicating a bit more of information about how the proxy 54 | operates. It is a pure function, therefore making it effectively constant as 55 | it cannot return a different value depending on state changes. 56 | 57 | - **Forwarding proxy** (`id = 1`): The proxy will always forward to the same code 58 | address. The following invariant should always be true: once the proxy returns 59 | a non-zero code address, that code address should never change. 60 | 61 | - **Upgradeable proxy** (`id = 2`): The proxy code address can be changed depending 62 | on some arbitrary logic implemented either at the proxy level or in its forwarded 63 | logic. 64 | 65 | ## Benefits 66 | 67 | - **Source code verification**: right now when checking the code of a proxy in explorers 68 | like Etherscan, it just shows the code in the proxy itself but not the actual 69 | code of the contract. By standardizing this construct, they will be able to show 70 | both the actual ABI and code for the contract. 71 | 72 | ## 版权 73 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 74 | -------------------------------------------------------------------------------- /EIPS/eip-927.md: -------------------------------------------------------------------------------- 1 | --- 2 | eip: 927 3 | title: Generalised authorisations 4 | author: Nick Johnson 5 | type: Standards Track 6 | category: ERC 7 | status: Draft 8 | created: 2018-03-12 9 | requires: 926 10 | --- 11 | 12 | ## 摘要 13 | This EIP specifies a generic authorisation mechanism, which can be used to implement a variety of authorisation patterns, replacing approvals in ERC20, operators in ERC777, and bespoke authorisation patterns in a variety of other types of contract. 14 | 15 | ## 动机 16 | Smart contracts commonly need to provide an interface that allows a third-party caller to perform actions on behalf of a user. The most common example of this is token authorisations/operators, but other similar situations exist throughout the ecosystem, including for instance authorising operations on ENS domains. Typically each standard reinvents this system for themselves, leading to a large number of incompatible implementations of the same basic pattern. Here, we propose a generic method usable by all such contracts. 17 | 18 | The pattern implemented here is inspired by [ds-auth](https://github.com/dapphub/ds-auth) and by OAuth. 19 | 20 | ## 规范 21 | The generalised authorisation interface is implemented as a metadata provider, as specified in EIP 926. The following mandatory function is implemented: 22 | 23 | ``` 24 | function canCall(address owner, address caller, address callee, bytes4 func) view returns(bool); 25 | ``` 26 | 27 | Where: 28 | - `owner` is the owner of the resource. If approved the function call is treated as being made by this address. 29 | - `caller` is the address making the present call. 30 | - `callee` is the address of the contract being called. 31 | - `func` is the 4-byte signature of the function being called. 32 | 33 | For example, suppose Alice authorises Bob to transfer tokens on her behalf. When Bob does so, Alice is the `owner`, Bob is the `caller`, the token contract is the `callee`, and the function signature for the transfer function is `func`. 34 | 35 | As this standard uses EIP 926, the authorisation flow is as follows: 36 | 37 | 1. The callee contract fetches the provider for the `owner` address from the metadata registry contract, which resides at a well-known address. 38 | 2. The callee contract calls `canCall()` with the parameters described above. If the function returns false, the callee reverts execution. 39 | 40 | Commonly, providers will wish to supply a standardised interface for users to set and unset their own authorisations. They SHOULD implement the following interface: 41 | 42 | ``` 43 | function authoriseCaller(address owner, address caller, address callee, bytes4 func); 44 | function revokeCaller(address owner, address caller, address callee, bytes4 func); 45 | ``` 46 | 47 | Arguments have the same meaning as in `canCall`. Implementing contracts MUST ensure that `msg.sender` is authorised to call `authoriseCaller` or `revokeCaller` on behalf of `owner`; this MUST always be true if `owner == msg.sender`. Implementing contracts SHOULD use the standard specified here to determine if other callers may provide authorisations as well. 48 | 49 | Implementing contracts SHOULD treat a `func` of 0 as authorising calls to all functions on `callee`. If `authorised` is `false` and `func` is 0, contracts need only clear any blanket authorisation; individual authorisations may remain in effect. 50 | 51 | ## 向后兼容 52 | There are no backwards compatibility concerns. 53 | 54 | ## 实现 55 | Example implementation TBD. 56 | 57 | ## 版权 58 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). 59 | -------------------------------------------------------------------------------- /EIPS/index.md: -------------------------------------------------------------------------------- 1 | # EIPs 概要 2 | 3 | 以太坊改进提案（EIPs）描述了以太坊平台的标准，包括核心协议规范，客户端 API和合同标准。 4 | 任何人都可以参与以太坊的改进，参与的方式是向以太坊[EIPs GitHub库](https://github.com/ethereum/EIPs)提交改进提案的pull request，大家可以阅读[EIP-1](eip-1.md) 了解如何提交改进提案。 5 | 6 | 7 | ## EIP 状态（status terms） 8 | 9 | 一个“成功的”EIP会经过以下几个状态： 10 | 11 | ``` 12 | 草案（Draft -> 最后召集（Last Call） -> 已接受（Accepte） -> 最终（Final） 13 | ``` 14 | 15 | * **草案 Draft** - 说明此提案还在开放讨论，正在进行快速迭代和更改的EIP。 16 | * **最后召集 Last Call** - 完成了初始迭代，并准备好供更大受众查阅。 17 | * **已接受 Accepted** - 核心EIP（core EIP) 至少在 `最后召集` 状态至少两周。并且作者已解决了所要求的任何技术变更。核心开发团队决定是否将EIP作为硬分叉的一部分编码到客户端（硬分叉的过程不是EIP过程的一部分）。 如果做出这样的决定，EIP将进入最终决定。 18 | * **最终 Final (non-Core)** - EIP 至少在 `最后召集` 状态至少两周。并且作者已解决了所要求的任何技术变更。 19 | * **最终 Final (Core)** - 核心开发团队决定实现此EIP并作为将来/或已经硬分叉的一部分。 20 | 21 | ## EIP 分类（Types） 22 | 23 | EIP 分为多种类型，每种类型都有自己的EIP列表。 24 | 25 | ### 标准跟踪 Standard Track (202) 26 | 27 | 描述影响以太坊实现的任何更改，例如网络协议的更改、块或交易有效性规则的更改、应用程序标准或约定，或影响以太坊应用程序交互的任何更改或添加。标准跟踪EIP 细分为以下几类。 28 | 29 | #### [核心 Core](core.md) (84) 30 | 31 | 核心提案包含产生共识分叉的改进(如：[EIP5](eip-5.md), [EIP101](eip-101.md))，以及一些也许不是共识部分但可能与“核心开发”讨论相关的变更（例如，矿工/节点策略更改[EIP86](eip-86.md)的2,3和4））。 32 | 33 | #### [网络 Networking](networking.md) (7) 34 | 35 | 包括围绕devp2p ([EIP8](eip-8.md)) 和轻客户端子协议的改进，以及对 whisper 和 swarm 网络协议规范的改进建议。 36 | 37 | 38 | #### [接口 Interface](interface.md) (18) 39 | 40 | 包括有关客户端API/RPC规范和标准的改进，以及某些语言级别标准，如方法名([EIP6](eip-6))和合约ABI。 41 | 42 | 43 | #### [应用标准提案 ERC](erc.md) (93) 44 | 45 | ERC 是 Ethereum Request for Comment 的缩写，原本是征求大家意见的意思，主要是应用程序标准或约定，包含如：代币标准合约([ERC20](eip-20.md))，名称注册([ERC137](eip-137.md))，URI schemes ([ERC681](eip-681.md))，库/包格式 ([EIP190](eip-190.md))， 46 | 钱包格式 ([EIP85](https://github.com/ethereum/EIPs/issues/85))等。 47 | 48 | 49 | ### [元提案 Meta](meta.md) (14) 50 | 51 | 52 | 描述以太坊的改进过程（或事件），也被视为过程EIP（Process EIP）。 流程EIP类似于标准跟踪EIP，但流程EIP描述以太坊协议外的内容（而不是协议本身）。 他们可能会提出一个实现，但不会加入到以太坊的代码库; 这些提案经常需要社区共识; 与信息EIP不同，它们不仅仅是建议，用户通常也不能忽略它们。 提案包括程序，指南，决策过程的变更以及以太坊开发中使用的工具或环境的变更。 53 | 54 | 55 | 56 | ### [信息提案 Informational](informational.md) (1) 57 | 58 | 描述以太坊设计问题，或向以太坊社区提供一般指导信息，但不提出新功能。 信息提案不一定代表以太坊社区的共识或推荐，因此用户和实施者可以自由地忽略信息EIP或遵循他们的建议。 59 | -------------------------------------------------------------------------------- /EIPS/informational.md: -------------------------------------------------------------------------------- 1 | # 所有信息提案 2 | 3 | 信息提案描述以太坊设计问题，或向以太坊社区提供一般指导信息。 4 | 5 | 关于提案分类可以阅读[以太坊改进提案概要](https://learnblockchain.cn/docs/eips/)或[EIP-1:EIP 用途及指导原则](https://learnblockchain.cn/docs/eips/eip-1.html) 6 | 7 | ## 草案(Draft) 8 | 9 | | 编号 | 标题 | 作者 | 10 | | --- | --- | --- | 11 | | [1470](eip-1470.md) | Smart Contract Weakness Classification (SWC) | [Gerhard Wagner](https://github.com/thec00n) | 12 | 13 | -------------------------------------------------------------------------------- /EIPS/interface.md: -------------------------------------------------------------------------------- 1 | # 所有接口提案 2 | 3 | 接口提案包括有关客户端API/RPC规范和标准的改进，以及某些语言级别标准，如方法名([EIP6](eip-6))和合约ABI。 4 | 5 | 关于提案分类可以阅读[以太坊改进提案概要](https://learnblockchain.cn/docs/eips/)或[EIP-1:EIP 用途及指导原则](https://learnblockchain.cn/docs/eips/eip-1.html) 6 | 7 | ## 最后召集(Last Call) 8 | 9 | | 编号 | 标题 | 作者 | 10 | | --- | --- | --- | 11 | | [695](eip-695.md) | Create `eth_chainId` method for JSON-RPC | [Isaac Ardis](mailto:isaac.ardis@gmail.com), [Wei Tang](https://github.com/sorpaas), [Fan Torchz](https://github.com/tcz001) | 12 | | [2159](eip-2159.md) | Common Prometheus Metrics Names for Clients | [Adrian Sutton](https://github.com/ajsutton) | 13 | 14 | ## 草案(Draft) 15 | 16 | | 编号 | 标题 | 作者 | 17 | | --- | --- | --- | 18 | | [107](eip-107.md) | safe "eth_sendTransaction" authorization via html popup | [Ronan Sandford](https://github.com/wighawag) | 19 | | [234](eip-234.md) | Add `blockHash` to JSON-RPC filter options. | [Micah Zoltu](https://github.com/MicahZoltu) | 20 | | [712](eip-712.md) | Ethereum typed structured data hashing and signing | [Remco Bloemen](mailto:remco@wicked.ventures), [Leonid Logvinov](mailto:logvinov.leon@gmail.com), [Jacob Evans](mailto:jacob@dekz.net) | 21 | | [747](eip-747.md) | Add wallet_watchAsset to Provider | [Dan Finlay](https://github.com/danfinlay), [Esteban Mino](https://github.com/estebanmino) | 22 | | [758](eip-758.md) | Subscriptions and filters for completed transactions | [Jack Peterson](mailto:jack@tinybike.net) | 23 | | [1102](eip-1102.md) | Opt-in account exposure | [Paul Bouchon](mailto:mail@bitpshr.net) | 24 | | [1186](eip-1186.md) | RPC-Method to get Merkle Proofs - eth_getProof | [Simon Jentzsch](mailto:simon.jentzsch@slock.it), [Christoph Jentzsch](mailto:christoph.jentzsch@slock.it) | 25 | | [1193](eip-1193.md) | Ethereum Provider JavaScript API | [Fabian Vogelsteller](https://github.com/frozeman), [Ryan Ghods](https://github.com/ryanio), [Marc Garreau](https://github.com/marcgarreau), [Victor Maia](https://github.com/MaiaVictor) | 26 | | [1474](eip-1474.md) | Remote procedure call specification | [Paul Bouchon](mailto:mail@bitpshr.net) | 27 | | [1571](eip-1571.md) | EthereumStratum/2.0.0 | [Andrea Lanfranchi (@AndreaLanfranchi)](mailto:andrea.lanfranchi@gmail.com), [Pawel Bylica (@chfast)](mailto:pawel@ethereum.org), [Marius Van Der Wijden](https://github.com/MariusVanDerWijden) | 28 | | [1767](eip-1767.md) | GraphQL interface to Ethereum node data | [Nick Johnson](https://github.com/arachnid), [Raúl Kripalani](https://github.com/raulk), [Kris Shinn](https://github.com/kshinn) | 29 | | [1803](eip-1803.md) | Rename opcodes for clarity | [Alex Beregszaszi](https://github.com/axic) | 30 | | [1898](eip-1898.md) | Add `blockHash` to JSON-RPC methods which accept a default block parameter. | [Charles Cooper](https://github.com/charles-cooper) | 31 | | [1901](eip-1901.md) | Add OpenRPC Service Discovery To JSON-RPC Services | [Shane Jonas](https://github.com/shanejonas), [Zachary Belford](https://github.com/belfordz) | 32 | | [2003](eip-2003.md) | EVMC modules for implementations of precompiled contracts | [Paweł Bylica](https://github.com/chfast), [Alex Beregszaszi](https://github.com/axic) | 33 | 34 | ## 最终(Final) 35 | 36 | | 编号 | 标题 | 作者 | 37 | | --- | --- | --- | 38 | | [6](eip-6.md) | Renaming SUICIDE opcode | [Hudson Jameson](mailto:hudson@hudsonjameson.com) | 39 | 40 | 41 | -------------------------------------------------------------------------------- /EIPS/meta.md: -------------------------------------------------------------------------------- 1 | # 所有的元提案 2 | 3 | 元提案描述以太坊的改进过程（或事件），也被视为过程EIP（Process EIP）。 4 | 5 | 关于提案分类可以阅读[以太坊改进提案概要](https://learnblockchain.cn/docs/eips/)或[EIP-1:EIP 用途及指导原则](https://learnblockchain.cn/docs/eips/eip-1.html) 6 | 7 | ## 草案(Draft) 8 | 9 | | 编号 | 标题 | 作者 | 10 | | --- | --- | --- | 11 | | [233](eip-233.md) | Formal process of hard forks | [Alex Beregszaszi](https://github.com/axic) | 12 | | [867](eip-867.md) | Standardized Ethereum Recovery Proposals | [Dan Phifer](mailto:dp@musiconomi.com), [James Levy](mailto:james@taptrust.com), [Reuben Youngblom](mailto:reuben@taptrust.com) | 13 | | [1588](eip-1588.md) | Hardfork Meta: Ethereum ProgPoW | [Ikmyeong Na](https://github.com/naikmyeong) | 14 | | [1679](eip-1679) | Hardfork Meta: Istanbul | [Alex Beregszaszi](https://github.com/axic), [Afri Schoedon](https://github.com/5chdn) | 15 | | [1872](eip-1872.md) | Ethereum Network Upgrade Windows | [Danno Ferrin](https://github.com/shemnon) | 16 | 17 | ## 最终(Final) 18 | 19 | | 编号 | 标题 | 作者 | 20 | | --- | --- | --- | 21 | | [606](eip-606.md) | Hardfork Meta: Homestead | [Alex Beregszaszi](https://github.com/axic) | 22 | | [607](eip-607.md) | Hardfork Meta: Spurious Dragon | [Alex Beregszaszi](https://github.com/axic) | 23 | | [608](eip-608.md) | Hardfork Meta: Tangerine Whistle | [Alex Beregszaszi](https://github.com/axic) | 24 | | [609](eip-609.md) | Hardfork Meta: Byzantium | [Alex Beregszaszi](https://github.com/axic) | 25 | | [779](eip-779.md) | Hardfork Meta: DAO Fork | [Casey Detrio](https://github.com/cdetrio) | 26 | | [1013](eip-1013.md) | Hardfork Meta: Constantinople | [Nick Savers](https://github.com/nicksavers) | 27 | | [1716](eip-1716.md) | Hardfork Meta: Petersburg | [Afri Schoedon](https://github.com/5chdn), [Marius van der Wijden](https://github.com/MariusVanDerWijden) | 28 | 29 | ## 活跃(Active) 30 | 31 | | 编号 | 标题 | 作者 | 32 | | --- | --- | --- | 33 | | [1](eip-1.md) | EIP Purpose and Guidelines | [Martin Becze](mailto:mb@ethereum.org), [Hudson Jameson](mailto:hudson@ethereum.org), and others https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md | 34 | 35 | ## 被取代(Superseded) 36 | 37 | | 编号 | 标题 | 作者 | 38 | | --- | --- | --- | 39 | | [4](eip-4.md) | EIP Classification | [Joseph Chow](https://github.com/ethers) | 40 | 41 | -------------------------------------------------------------------------------- /EIPS/networking.md: -------------------------------------------------------------------------------- 1 | # 所有网络提案 2 | 3 | 有网络提案包括围绕devp2p ([EIP8](eip-8.md)) 和轻客户端子协议的改进，以及对 whisper 和 swarm 网络协议规范的改进建议。 4 | 5 | 关于提案分类可以阅读[以太坊改进提案概要](https://learnblockchain.cn/docs/eips/)或[EIP-1:EIP 用途及指导原则](https://learnblockchain.cn/docs/eips/eip-1.html) 6 | 7 | 8 | ## 草案(Draft) 9 | 10 | | 编号 | 标题 | 作者 | 11 | | --- | --- | --- | 12 | | [778](eip-778.md) | Ethereum Node Records (ENR) | [Felix Lange](mailto:fjl@ethereum.org) | 13 | | [868](eip-868.md) | Node Discovery v4 ENR Extension | [Felix Lange](mailto:fjl@ethereum.org) | 14 | | [1459](eip-1459.md) | Node Discovery via DNS | [Felix Lange](mailto:fjl@ethereum.org), [Péter Szilágyi](mailto:peter@ethereum.org) | 15 | | [2124](eip-2124.md) | Fork identifier for chain compatibility checks | [Péter Szilágyi](mailto:peterke@gmail.com), [Felix Lange](mailto:fjl@ethereum.org) | 16 | 17 | ## 最终(Final) 18 | 19 | | 编号 | 标题 | 作者 | 20 | | --- | --- | --- | 21 | | [8](eip-8.md) | devp2p Forward Compatibility Requirements for Homestead | [Felix Lange](mailto:felix@ethdev.com) | 22 | | [627](eip-627.md) | Whisper Specification | [Vlad Gluhovsky](mailto:gluk256@gmail.com) | 23 | | [706](eip-706.md) | DEVp2p snappy compression | [Péter Szilágyi](mailto:peter@ethereum.org) | 24 | 25 | -------------------------------------------------------------------------------- /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](https://eips.ethereum.org/EIPS/eip-1): 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 | -------------------------------------------------------------------------------- /_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 | twitter_username: ethereum 23 | github_username: ethereum 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 | twitter: 33 | card: summary 34 | username: ethereum 35 | 36 | # Build settings 37 | markdown: kramdown 38 | theme: minima 39 | kramdown: 40 | parse_block_html: false 41 | # This is the default, but be explicit as some EIPs depend on it 42 | auto_ids: true 43 | # This is to ensure more determistic behaviour 44 | auto_id_stripping: true 45 | 46 | permalink: /:slug 47 | 48 | defaults: 49 | - 50 | scope: 51 | path: "EIPS" 52 | values: 53 | layout: "eip" 54 | 55 | exclude: 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 | - Last Call 2 | - Draft 3 | - Accepted 4 | - Final 5 | - Active 6 | - Abandoned 7 | - Rejected 8 | - Superseded 9 | -------------------------------------------------------------------------------- /_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 | 18 | 19 | {% for page in eips %} 20 | 21 | 22 | 23 | 24 | 25 | {% endfor %} 26 |
NumberTitleAuthor
{{page.eip|xml_escape}}{{page.title|xml_escape}}{% include authorlist.html authors=page.author %}
27 | {% endif %} 28 | {% endfor %} 29 | -------------------------------------------------------------------------------- /_includes/head.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | {% if page.layout == "eip" %} 6 | EIP {{ page.eip }}: {{ page.title | escape }} 7 | 8 | 12 | 16 | 17 | {% else %} 18 | {{ page.title | escape }} | {{site.title}} 19 | 23 | 24 | 25 | 26 | {% endif %} 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 43 | 44 | {%- feed_meta -%} 45 | 46 | -------------------------------------------------------------------------------- /_includes/social.html: -------------------------------------------------------------------------------- 1 | 15 | -------------------------------------------------------------------------------- /_layouts/eip.html: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | --- 4 | 5 |
6 |

7 | EIP {{ page.eip | xml_escape }}: {{ page.title | xml_escape }} 8 | Source 9 |

10 | 11 | 12 | {% if page["discussions-to"] != undefined %} 13 | 14 | {% endif %} 15 | 20 | 21 | {% if page.category != undefined %} 22 | 23 | {% endif %} 24 | 25 | {% if page.updated != undefined %} 26 | 27 | {% endif %} 28 | {% if page.requires != undefined %} 29 | 30 | {% endif %} 31 | {% if page.replaces != undefined %} 32 | 33 | {% endif %} 34 | {% if page["superseded-by"] != undefined %} 35 | 36 | {% endif %} 37 | {% if page.resolution != undefined %} 38 | 39 | {% endif %} 40 |
Author{% include authorlist.html authors=page.author %}
Discussions-To{{ page["discussions-to"] | xml_escape }}
Status{{ page.status | xml_escape }} 16 | {% if page.review-period-end != undefined %} 17 | (review ends {{ page.review-period-end | xml_escape }}) 18 | {% endif %} 19 |
Type{{ page.type | xml_escape }}
Category{{ page.category | xml_escape }}
Created{{ page.created | xml_escape }}
Updated{{ page.updated | xml_escape }}
Requires{% include eipnums.html eips=page.requires %}
Replaces{% include eipnums.html eips=page.replaces %}
Superseded by{% include eipnums.html eips=page.superseded-by %}
Resolution{{ page.resolution | xml_escape }}
41 | 42 | {{ content }} 43 | 44 |
45 | -------------------------------------------------------------------------------- /assets/css/style.scss: -------------------------------------------------------------------------------- 1 | --- 2 | # Only the main Sass file needs front matter (the dashes are enough) 3 | --- 4 | 5 | @import "minima"; -------------------------------------------------------------------------------- /assets/eip-1/process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1/process.png -------------------------------------------------------------------------------- /assets/eip-107/authorization-locked.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-107/authorization-locked.png -------------------------------------------------------------------------------- /assets/eip-107/authorization-password.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-107/authorization-password.png -------------------------------------------------------------------------------- /assets/eip-107/authorization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-107/authorization.png -------------------------------------------------------------------------------- /assets/eip-1207/rationale.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1207/rationale.png -------------------------------------------------------------------------------- /assets/eip-1283/state.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1283/state.png -------------------------------------------------------------------------------- /assets/eip-1822/proxy-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1822/proxy-diagram.png -------------------------------------------------------------------------------- /assets/eip-1884/BALANCE-run3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1884/BALANCE-run3.png -------------------------------------------------------------------------------- /assets/eip-1884/SLOAD-run3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1884/SLOAD-run3.png -------------------------------------------------------------------------------- /assets/eip-1884/geth_processing.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1884/geth_processing.png -------------------------------------------------------------------------------- /assets/eip-1884/run3.total-bars-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1884/run3.total-bars-5.png -------------------------------------------------------------------------------- /assets/eip-1884/run3.total-bars-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1884/run3.total-bars-6.png -------------------------------------------------------------------------------- /assets/eip-1901/OpenRPC_structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1901/OpenRPC_structure.png -------------------------------------------------------------------------------- /assets/eip-1901/multi-geth-use-case.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-1901/multi-geth-use-case.png -------------------------------------------------------------------------------- /assets/eip-2255/permissions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-2255/permissions.png -------------------------------------------------------------------------------- /assets/eip-712/Example.sol: -------------------------------------------------------------------------------- 1 | pragma solidity ^0.4.24; 2 | 3 | contract Example { 4 | 5 | struct EIP712Domain { 6 | string name; 7 | string version; 8 | uint256 chainId; 9 | address verifyingContract; 10 | } 11 | 12 | struct Person { 13 | string name; 14 | address wallet; 15 | } 16 | 17 | struct Mail { 18 | Person from; 19 | Person to; 20 | string contents; 21 | } 22 | 23 | bytes32 constant EIP712DOMAIN_TYPEHASH = keccak256( 24 | "EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)" 25 | ); 26 | 27 | bytes32 constant PERSON_TYPEHASH = keccak256( 28 | "Person(string name,address wallet)" 29 | ); 30 | 31 | bytes32 constant MAIL_TYPEHASH = keccak256( 32 | "Mail(Person from,Person to,string contents)Person(string name,address wallet)" 33 | ); 34 | 35 | bytes32 DOMAIN_SEPARATOR; 36 | 37 | constructor () public { 38 | DOMAIN_SEPARATOR = hash(EIP712Domain({ 39 | name: "Ether Mail", 40 | version: '1', 41 | chainId: 1, 42 | // verifyingContract: this 43 | verifyingContract: 0xCcCCccccCCCCcCCCCCCcCcCccCcCCCcCcccccccC 44 | })); 45 | } 46 | 47 | function hash(EIP712Domain eip712Domain) internal pure returns (bytes32) { 48 | return keccak256(abi.encode( 49 | EIP712DOMAIN_TYPEHASH, 50 | keccak256(bytes(eip712Domain.name)), 51 | keccak256(bytes(eip712Domain.version)), 52 | eip712Domain.chainId, 53 | eip712Domain.verifyingContract 54 | )); 55 | } 56 | 57 | function hash(Person person) internal pure returns (bytes32) { 58 | return keccak256(abi.encode( 59 | PERSON_TYPEHASH, 60 | keccak256(bytes(person.name)), 61 | person.wallet 62 | )); 63 | } 64 | 65 | function hash(Mail mail) internal pure returns (bytes32) { 66 | return keccak256(abi.encode( 67 | MAIL_TYPEHASH, 68 | hash(mail.from), 69 | hash(mail.to), 70 | keccak256(bytes(mail.contents)) 71 | )); 72 | } 73 | 74 | function verify(Mail mail, uint8 v, bytes32 r, bytes32 s) internal view returns (bool) { 75 | // Note: we need to use `encodePacked` here instead of `encode`. 76 | bytes32 digest = keccak256(abi.encodePacked( 77 | "\x19\x01", 78 | DOMAIN_SEPARATOR, 79 | hash(mail) 80 | )); 81 | return ecrecover(digest, v, r, s) == mail.from.wallet; 82 | } 83 | 84 | function test() public view returns (bool) { 85 | // Example signed message 86 | Mail memory mail = Mail({ 87 | from: Person({ 88 | name: "Cow", 89 | wallet: 0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826 90 | }), 91 | to: Person({ 92 | name: "Bob", 93 | wallet: 0xbBbBBBBbbBBBbbbBbbBbbbbBBbBbbbbBbBbbBBbB 94 | }), 95 | contents: "Hello, Bob!" 96 | }); 97 | uint8 v = 28; 98 | bytes32 r = 0x4355c47d63924e8a72e509b65029052eb6c299d53a04e167c5775fd466751c9d; 99 | bytes32 s = 0x07299936d304c153f6443dfa05f40ff007d72911b6f72307f996231605b91562; 100 | 101 | assert(DOMAIN_SEPARATOR == 0xf2cee375fa42b42143804025fc449deafd50cc031ca257e0b194a650a912090f); 102 | assert(hash(mail) == 0xc52c0ee5d84264471806290a3f2c4cecfc5490626bf912d01f240d7a274b371e); 103 | assert(verify(mail, v, r, s)); 104 | return true; 105 | } 106 | } 107 | -------------------------------------------------------------------------------- /assets/eip-712/eth_sign.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-712/eth_sign.png -------------------------------------------------------------------------------- /assets/eip-712/eth_signTypedData.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-712/eth_signTypedData.png -------------------------------------------------------------------------------- /assets/eip-747/add-token-prompt.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-747/add-token-prompt.gif -------------------------------------------------------------------------------- /assets/eip-747/add-token-prompt2.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/assets/eip-747/add-token-prompt2.gif -------------------------------------------------------------------------------- /assets/eip-777/logo/png/ERC-777-logo-beige-1024px.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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/lbc-team/EIPs/599f4c16a730c32379acfe10cfde76b6e9c76dd9/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 | -------------------------------------------------------------------------------- /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 }} 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.date | date: "%a, %d %b %Y %H:%M:%S %z" }} 29 | {{ site.url }}/{{ eip.url }} 30 | {{ site.url }}/{{ eip.url }} 31 | 32 | {% endif %} 33 | {% endfor %} 34 | 35 | 36 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "scripts": { 3 | "docs:dev": "vuepress dev EIPS", 4 | "docs:build": "vuepress build EIPS" 5 | } 6 | } --------------------------------------------------------------------------------