diff --git a/.codespell-whitelist b/.codespell-whitelist new file mode 100644 index 00000000000000..21c9c7e4ce907a --- /dev/null +++ b/.codespell-whitelist @@ -0,0 +1,7 @@ +uint +ith +mitre +readded +crate +developper +ist diff --git a/.travis-ci.sh b/.travis-ci.sh index f907ac4dbfc6aa..98b6f81471edd4 100755 --- a/.travis-ci.sh +++ b/.travis-ci.sh @@ -24,4 +24,6 @@ elif [[ $TASK = 'eip-validator' ]]; then FILES="$(ls EIPS/*.md | egrep "eip-[0-9]+.md")" bundle exec eip_validator $FILES +elif [[ $TASK = 'codespell' ]]; then + codespell -q4 -I .codespell-whitelist eip-X.md EIPS/ fi diff --git a/.travis.yml b/.travis.yml index a4e1fb8857cc1c..70b2fd191a57fe 100644 --- a/.travis.yml +++ b/.travis.yml @@ -10,7 +10,7 @@ cache: - bundler - directories: - $TRAVIS_BUILD_DIR/tmp/.htmlproofer #https://github.com/gjtorikian/html-proofer/issues/381 - + - /usr/local/lib/python3.3/dist-packages/pip/ # Assume bundler is being used, therefore # the `install` step will run `bundle install` by default. @@ -29,6 +29,9 @@ matrix: env: TASK='htmlproofer-external' - rvm: 2.2.5 env: TASK='eip-validator' + - python: 3.3 + env: TASK='codespell' + before_script: "sudo pip install urllib3[secure] && sudo pip install codespell" allow_failures: - rvm: 2.2.5 env: TASK='htmlproofer-external' diff --git a/EIPS/eip-1011.md b/EIPS/eip-1011.md index 58b9264b878279..a35c0a7b6de81b 100644 --- a/EIPS/eip-1011.md +++ b/EIPS/eip-1011.md @@ -183,7 +183,7 @@ def check_and_finalize_new_checkpoint(new_block): db.last_finalized_block = finalized_hash ``` -The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (`NON_REVERT_MIN_DEPOSITS`). The `10**40` multiplier ensures that the justified epoch takes precendence over block mining difficulty. `total_difficulty` only serves as a tie breaker if the two blocks in question have an equivalent `highest_justified_epoch`. +The new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client's minimum deposit requirement (`NON_REVERT_MIN_DEPOSITS`). The `10**40` multiplier ensures that the justified epoch takes precedence over block mining difficulty. `total_difficulty` only serves as a tie breaker if the two blocks in question have an equivalent `highest_justified_epoch`. _Note_: If the client has no justified checkpoints, the contract returns `highest_justified_epoch` as `0` essentially reverting the fork choice rule to pure PoW. @@ -379,7 +379,7 @@ Any call to this method fails prior to the end of the `WARM_UP_PERIOD`. Thus the #### Issuance A fixed amount of 1.25M ETH was chosen as `CASPER_BALANCE` to fund the casper contract. This gives the contract enough runway to operate for approximately 2 years (assuming ~10M ETH in validator deposits). Acting similarly to the "difficulty bomb", this "funding crunch" forces the network to hardfork in the relative near future to further fund the contract. This future hardfork is an opportunity to upgrade the contract and transition to full PoS. -The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG. +The PoW block reward is reduced from 3.0 to 0.6 ETH/block over the course of approximately one year because the security of the chain is greatly shifted from PoW difficulty to PoS finality and because rewards are now issued to both validators and miners. Rewards are stepped down by 0.6 ETH/block every 3 months (`REWARD_STEPDOWN_BLOCK_COUNT`) to provide for a conservative transition period from full PoW to hybrid PoS/PoW. This gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforeseen issues. If any major issues do arise, the Ethereum network will still have substantial PoW security to rely upon while decisions are made and/or patches are deployed. See [here](https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a) for further analysis of the current PoW security and of the effect of PoW block reward reduction in the context of Hybrid Casper FFG. In addition to block rewards, miners now receive an issuance reward for including successful `vote` transactions into the block on time. This reward is equal to 1/8th that of the reward the validator receives for a successful `vote` transaction. Under optimal FFG conditions after group validator reward adjustments are made, miners receive approximately 1/5th of the total ETH issued by the Casper contract. diff --git a/EIPS/eip-1015.md b/EIPS/eip-1015.md index 4aecc15a1896e5..0d690fa6ccc18d 100644 --- a/EIPS/eip-1015.md +++ b/EIPS/eip-1015.md @@ -12,7 +12,7 @@ created: 2018-04-20 ## Simple Summary -This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be mantained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance. +This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be maintained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would **not be a generic governance solution**, which is a much broader and harder topic, would **not** affect technical upgrade decisions or other hard forks, but seen as *a forum to attempt to prevent contentious hard forks* that can be solved with the issuance. ## Summary ### Thesis: many controversial issues boil down to resources @@ -24,7 +24,7 @@ Moving to PoS has been on the roadmap since day 0 for ethereum, along with a red #### Issuance Cap at 120 Million -[EIP 960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweight other actions. Burning ether is also a valid issuance decision. +[EIP 960](https://github.com/ethereum/EIPs/issues/960), Vitalik's not so jokey april's fool has been taken seriously. It proposes the issuance to be slowly reduced until it reaches 120 million ether. One of the main counterpoints by Vlad can be simplified by [we don't know enough to know what that ether can be used for](https://medium.com/@Vlad_Zamfir/against-vitaliks-fixed-supply-eip-eip-960-18e182a7e5bd) and Vitalik's counterpoint is that [reducing emissions can be a way to reduce future abuse of these funds by finding a schelling point at 0](https://medium.com/@VitalikButerin/to-be-clear-im-not-necessarily-wedded-to-a-finite-supply-cap-a7aa48ab880c). Issuance has already been reduced once, from 5 ether to the current 3 ether per block. The main point of a hard cap is that a lot of people consider *not issuing* as having a positive contribution, that can outweigh other actions. Burning ether is also a valid issuance decision. #### Asics and advantadges of PoW @@ -52,7 +52,7 @@ It's not meant to be a general governance contract. The contract **should NOT be ##### It cannot only decrease issuance, and once decreased it cannot be increased again -In order to reduce future abuse and uncertainity, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is agressively to reduce issuance to zero, it would take a known number of years. +In order to reduce future abuse and uncertainty, **once issuance is reduced, it cannot be increased**. To prevent a single action reducing it to 0, the reduction is limited up to a percentage per time, so if the **decision assembly** is aggressively to reduce issuance to zero, it would take a known number of years. ##### Results are locked for six months @@ -109,7 +109,7 @@ A lot of things are suggested in this EIP, so I would like to propose these ques 1. Do we want to have dynamically changing block rewards, instead of having them be hard coded in the protocol? 2. If the answer above is yes, then what would be the best governance process to decide it, and what sorts of limits would we want that governance contract to have? -3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the proccess to add and remove them? +3. If the answer is a multi-signalling contract, then what sorts of signals would we want, what sort of relative weight should they have and what would be the process to add and remove them? diff --git a/EIPS/eip-1057.md b/EIPS/eip-1057.md index b3b897b9e7d910..5ffc0b9f7d313a 100644 --- a/EIPS/eip-1057.md +++ b/EIPS/eip-1057.md @@ -15,7 +15,7 @@ A new Proof-of-Work algorithm to replace Ethash that utilizes almost all parts o ## Abstract -ProgPoW is a proof-of-work algorithm designed to close the efficency gap available to specialized ASICs. It utilizes almost all parts of commodity hardware (GPUs), and comes pre-tuned for the most common hardware utilized in the Ethereum network. +ProgPoW is a proof-of-work algorithm designed to close the efficiency gap available to specialized ASICs. It utilizes almost all parts of commodity hardware (GPUs), and comes pre-tuned for the most common hardware utilized in the Ethereum network. ## Motivation @@ -53,7 +53,7 @@ With the growth of large mining pools, the control of hashing power has been del While the goal of “ASIC resistance” is valuable, the entire concept of “ASIC resistance” is a bit of a fallacy. CPUs and GPUs are themselves ASICs. Any algorithm that can run on a commodity ASIC (a CPU or GPU) by definition can have a customized ASIC created for it with slightly less functionality. Some algorithms are intentionally made to be “ASIC friendly” - where an ASIC implementation is drastically more efficient than the same algorithm running on general purpose hardware. The protection that this offers when the coin is unknown also makes it an attractive target for a dedicate mining ASIC company as soon as it becomes useful. -Therefore, ASIC resistance is: the efficiency difference of specilized hardware versus hardware that has a wider adoption and applicability. A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms. Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated. If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack. +Therefore, ASIC resistance is: the efficiency difference of specialized hardware versus hardware that has a wider adoption and applicability. A smaller efficiency difference between custom vs general hardware mean higher resistance and a better algorithm. This efficiency difference is the proper metric to use when comparing the quality of PoW algorithms. Efficiency could mean absolute performance, performance per watt, or performance per dollar - they are all highly correlated. If a single entity creates and controls an ASIC that is drastically more efficient, they can gain 51% of the network hashrate and possibly stage an attack. ### Review of Existing PoW Algorithms @@ -134,7 +134,7 @@ The random program changes every `PROGPOW_PERIOD` blocks to ensure the hardware Sample code is written in C++, this should be kept in mind when evaluating the code in the specification. -All numerics are computed using unsinged 32 bit integers. Any overflows are trimmed off before proceeding to the next computation. Languages that use numerics not fixed to bit lenghts (such as Python and JavaScript) or that only use signed integers (such as Java) will need to keep their languages' quirks in mind. The extensive use of 32 bit data values aligns with modern GPUs internal data architectures. +All numerics are computed using unsigned 32 bit integers. Any overflows are trimmed off before proceeding to the next computation. Languages that use numerics not fixed to bit lengths (such as Python and JavaScript) or that only use signed integers (such as Java) will need to keep their languages' quirks in mind. The extensive use of 32 bit data values aligns with modern GPUs internal data architectures. ProgPoW uses a 32-bit variant of **FNV1a** for merging data. The existing Ethash uses a similar vaiant of FNV1 for merging, but FNV1a provides better distribution properties. diff --git a/EIPS/eip-1066.md b/EIPS/eip-1066.md index bfb15d1d2ac902..c8755a5b52d75a 100644 --- a/EIPS/eip-1066.md +++ b/EIPS/eip-1066.md @@ -104,10 +104,10 @@ General codes. These double as bare "reasons", since `0x01 == 1`. | `0x02` | Awaiting Others | | `0x03` | Accepted | | `0x04` | Lower Limit or Insufficient | -| `0x05` | Reciever Action Requested | +| `0x05` | Receiver Action Requested | | `0x06` | Upper Limit | | `0x07` | [reserved] | -| `0x08` | Duplicate, Unnessesary, or Inapplicable | +| `0x08` | Duplicate, Unnecessary, or Inapplicable | | `0x09` | [reserved] | | `0x0A` | [reserved] | | `0x0B` | [reserved] | @@ -130,7 +130,7 @@ Also used for common state machine actions (ex. "stoplight" actions). | `0x15` | Needs Your Permission or Request for Continuation | | `0x16` | Revoked or Banned | | `0x17` | [reserved] | -| `0x18` | Not Applicatable to Current State | +| `0x18` | Not Applicable to Current State | | `0x19` | [reserved] | | `0x1A` | [reserved] | | `0x1B` | [reserved] | @@ -286,7 +286,7 @@ Currently unspecified. (Full range reserved) Actions around signatures, cryptography, signing, and application-level authentication. -The meta code `0xEF` is often used to signal a payload descibing the algorithm or process used. +The meta code `0xEF` is often used to signal a payload describing the algorithm or process used. | Code | Description | |--------|-------------------------------------| @@ -344,7 +344,7 @@ Among other things, the meta code `0xFF` may be used to describe what the off-ch | `0x*5` | `0x05` Receiver Action Required | `0x15` Needs Your Permission or Request for Continuation | `0x25` Request for Match | `0x35` Receiver's Ratification Requested | `0x45` Awaiting Your Availability | `0x55` Funds Requested | `0x65` [reserved] | `0x75` [reserved] | `0x85` [reserved] | `0x95` [reserved] | `0xA5` App-Specific Receiver Action Requested | `0xB5` [reserved] | `0xC5` [reserved] | `0xD5` [reserved] | `0xE5` Signature Required | `0xF5` Off-Chain Action Required | | `0x*6` | `0x06` Upper Limit | `0x16` Revoked or Banned | `0x26` Above Range or Overflow | `0x36` Offer or Vote Limit Reached | `0x46` Expired | `0x56` Transfer Volume Exceeded | `0x66` [reserved] | `0x76` [reserved] | `0x86` [reserved] | `0x96` [reserved] | `0xA6` App-Specific Expiry or Limit | `0xB6` [reserved] | `0xC6` [reserved] | `0xD6` [reserved] | `0xE6` Known to be Compromised | `0xF6` Off-Chain Expiry or Limit Reached | | `0x*7` | `0x07` [reserved] | `0x17` [reserved] | `0x27` [reserved] | `0x37` [reserved] | `0x47` [reserved] | `0x57` [reserved] | `0x67` [reserved] | `0x77` [reserved] | `0x87` [reserved] | `0x97` [reserved] | `0xA7` [reserved] | `0xB7` [reserved] | `0xC7` [reserved] | `0xD7` [reserved] | `0xE7` [reserved] | `0xF7` [reserved] | -| `0x*8` | `0x08` Duplicate, Unnessesary, or Inapplicable | `0x18` Not Applicatable to Current State | `0x28` Duplicate, Conflict, or Collision | `0x38` Already Voted | `0x48` Already Done | `0x58` Funds Not Required | `0x68` [reserved] | `0x78` [reserved] | `0x88` [reserved] | `0x98` [reserved] | `0xA8` App-Specific Inapplicable Condition | `0xB8` [reserved] | `0xC8` [reserved] | `0xD8` [reserved] | `0xE8` Already Signed or Not Encrypted | `0xF8` Duplicate Off-Chain Request | +| `0x*8` | `0x08` Duplicate, Unnecessary, or Inapplicable | `0x18` Not Applicable to Current State | `0x28` Duplicate, Conflict, or Collision | `0x38` Already Voted | `0x48` Already Done | `0x58` Funds Not Required | `0x68` [reserved] | `0x78` [reserved] | `0x88` [reserved] | `0x98` [reserved] | `0xA8` App-Specific Inapplicable Condition | `0xB8` [reserved] | `0xC8` [reserved] | `0xD8` [reserved] | `0xE8` Already Signed or Not Encrypted | `0xF8` Duplicate Off-Chain Request | | `0x*9` | `0x09` [reserved] | `0x19` [reserved] | `0x29` [reserved] | `0x39` [reserved] | `0x49` [reserved] | `0x59` [reserved] | `0x69` [reserved] | `0x79` [reserved] | `0x89` [reserved] | `0x99` [reserved] | `0xA9` [reserved] | `0xB9` [reserved] | `0xC9` [reserved] | `0xD9` [reserved] | `0xE9` [reserved] | `0xF9` [reserved] | | `0x*A` | `0x0A` [reserved] | `0x1A` [reserved] | `0x2A` [reserved] | `0x3A` [reserved] | `0x4A` [reserved] | `0x5A` [reserved] | `0x6A` [reserved] | `0x7A` [reserved] | `0x8A` [reserved] | `0x9A` [reserved] | `0xAA` [reserved] | `0xBA` [reserved] | `0xCA` [reserved] | `0xDA` [reserved] | `0xEA` [reserved] | `0xFA` [reserved] | | `0x*B` | `0x0B` [reserved] | `0x1B` [reserved] | `0x2B` [reserved] | `0x3B` [reserved] | `0x4B` [reserved] | `0x5B` [reserved] | `0x6B` [reserved] | `0x7B` [reserved] | `0x8B` [reserved] | `0x9B` [reserved] | `0xAB` [reserved] | `0xBB` [reserved] | `0xCB` [reserved] | `0xDB` [reserved] | `0xEB` [reserved] | `0xFB` [reserved] | @@ -491,7 +491,7 @@ Alternate schemes include `bytes32` and `uint8`. While these work reasonably wel `uint8` feels even more similar to HTTP status codes, and enums don't require as much casting. However does not break as evenly as a square table (256 doesn't look as nice in base 10). -Packing multiple codes into a single `bytes32` is nice in theory, but poses additional challenges. Unused space may be interpeted as `0x00 Failure`, you can only efficiently pack four codes at once, and there is a challenge in ensuring that code combinations are sensible. Forcing four codes into a packed representation encourages multiple status codes to be returned, which is often more information than strictly necessarily. This can lead to paradoxical results (ex `0x00` and `0x01` together), or greater resorces allocated to interpreting 2564 (4.3 billion) permutations. +Packing multiple codes into a single `bytes32` is nice in theory, but poses additional challenges. Unused space may be interpreted as `0x00 Failure`, you can only efficiently pack four codes at once, and there is a challenge in ensuring that code combinations are sensible. Forcing four codes into a packed representation encourages multiple status codes to be returned, which is often more information than strictly necessarily. This can lead to paradoxical results (ex `0x00` and `0x01` together), or greater resources allocated to interpreting 2564 (4.3 billion) permutations. ### Multiple Returns diff --git a/EIPS/eip-107.md b/EIPS/eip-107.md index 48b13a0390b60f..897feb804b6f96 100644 --- a/EIPS/eip-107.md +++ b/EIPS/eip-107.md @@ -16,7 +16,7 @@ Every read only rpc call the dapp wants to perform is redirected to an invisible Motivation ========== -Currently, if a user navigates to a dapp running on a website using her/his everyday browser, the dapp will by default have no access to the rpc api for security reasons. The user will have to enable CORS for the website's domain in order for the dapp to work. Unfortunately if the user does so, the dapp will be able to send transactions from any unlocked account without the need for any user consent. In other words, not only does the user need to change the node's default setting, but the user is also forced to trust the dapp in order to use it. This is of course not acceptable and forces existing dapps to rely on the use of workarrounds like: +Currently, if a user navigates to a dapp running on a website using her/his everyday browser, the dapp will by default have no access to the rpc api for security reasons. The user will have to enable CORS for the website's domain in order for the dapp to work. Unfortunately if the user does so, the dapp will be able to send transactions from any unlocked account without the need for any user consent. In other words, not only does the user need to change the node's default setting, but the user is also forced to trust the dapp in order to use it. This is of course not acceptable and forces existing dapps to rely on the use of workarounds like: - if the transaction is a plain ether transfer, the user is asked to enter it in a dedicated trusted wallet like "Mist" - For more complex case, the user is asked to enter the transaction manually via the node command line interface. @@ -50,12 +50,12 @@ In order for the mechanism to work, the node needs to serve an html file via htt This file will then be used by the dapp in 2 different modes (invisible iframe and popup window). -The invisible iframe will be embeded in the dapp to allow the dapp to send its read-only rpc call without having to enable CORS for the dapp's website domain. This is done by sending message to the iframe (via javascript ```window.postMessage```) which in turn execute the rpc call. This works since the iframe and the node share the same domain/port. +The invisible iframe will be embedded in the dapp to allow the dapp to send its read-only rpc call without having to enable CORS for the dapp's website domain. This is done by sending message to the iframe (via javascript ```window.postMessage```) which in turn execute the rpc call. This works since the iframe and the node share the same domain/port. In the iframe mode, the html file's javascript code will ensure that no call requiring an unlocked key can be made. This is to prevent dapps from embedding the invisible iframe and tricking the user into clicking the confirm button. If the dapp requires an ```eth_sendTransaction``` call, the dapp will instead open a new window using the same url. -In this popup window mode, the html file's javascript code will alow ```eth_sendTransaction``` (but not ```eth_sign```, as there is no way to display to the user the meaningful content of the transaction to sign in a safe way) to be called. But instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses, as well as the amount being transfered along with the potential gas cost. Upon the user approving, the request will be sent and the result returned to the dapp. An error will be returned in case the user cancel the request. +In this popup window mode, the html file's javascript code will allow ```eth_sendTransaction``` (but not ```eth_sign```, as there is no way to display to the user the meaningful content of the transaction to sign in a safe way) to be called. But instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses, as well as the amount being transferred along with the potential gas cost. Upon the user approving, the request will be sent and the result returned to the dapp. An error will be returned in case the user cancel the request. The html page also checks for the availability of the "personal" api and if so, will ask the user to unlock the account if necessary. The unlocking is temporary (3s) so the password will be asked again if a transaction is attempted before the end of this short time. @@ -75,7 +75,7 @@ Upon receiving such message, the iframe will perform the actual rpc call to the In all the cases, the iframe/window will send a message back to the dapp using the following object: ``` { - id:, + id:, result:, error: } diff --git a/EIPS/eip-1077.md b/EIPS/eip-1077.md index 81ff8f8b432753..4e7e08fdd36c21 100644 --- a/EIPS/eip-1077.md +++ b/EIPS/eip-1077.md @@ -84,7 +84,7 @@ Regardless of which fields you use, in your contract you **must** accept an extr #### Multiple signatures -If multiple signatures are required, then all signed messageHashes should then be *ordered by account* and sent to the receiveing contract which then will execute the following actions: +If multiple signatures are required, then all signed messageHashes should then be *ordered by account* and sent to the receiving contract which then will execute the following actions: #### keep track of nonces: @@ -166,7 +166,7 @@ A function which returns the amount of signatures that are required for a given `event ExecutedSigned(bytes32 signHash, uint nonce, bool success);` -Whenever a new transaction is executed it **must** emit an event with the signHash, nonce and either the transaction was sucessfully executed or not. Apps that are waiting for a transaction to be executed should subscribe to the identity and watch this event to see if their transaction was sucessful. If a different signHash is executed with an equal or higher nonce, it means that your transaction has been replaced. +Whenever a new transaction is executed it **must** emit an event with the signHash, nonce and either the transaction was successfully executed or not. Apps that are waiting for a transaction to be executed should subscribe to the identity and watch this event to see if their transaction was successful. If a different signHash is executed with an equal or higher nonce, it means that your transaction has been replaced. ## Implementation One initial implementation of such a contract can be found at [the Identity Gas Relay at the Status repository](https://github.com/status-im/contracts/blob/73-economic-abstraction/contracts/identity/IdentityGasRelay.sol) diff --git a/EIPS/eip-1078.md b/EIPS/eip-1078.md index f004566667cc64..990d446f833ced 100644 --- a/EIPS/eip-1078.md +++ b/EIPS/eip-1078.md @@ -71,7 +71,7 @@ Here's an example of a EIP681 compatible address to add a public key generated l `ethereum:bob.example.eth?function=addKey(address='0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef',uint=1)` -If adding the new key requires multiple signatures, or if the app receiving that request exclusiveky deals with executeable signed messages and has no ether on itself, then it should follow the steps in the next section on how to request transactions. +If adding the new key requires multiple signatures, or if the app receiving that request exclusiveky deals with executable signed messages and has no ether on itself, then it should follow the steps in the next section on how to request transactions. As before, the user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app the shows the progress and then allow the user to interact with your app normally. diff --git a/EIPS/eip-1080.md b/EIPS/eip-1080.md index e5f7a467177726..18277e8fcba4a4 100644 --- a/EIPS/eip-1080.md +++ b/EIPS/eip-1080.md @@ -172,7 +172,7 @@ event AccountFrozen(address indexed reported) ## Rationale -* A recoverable token standard can provide configurable saftey for users or contracts who desire this saftey. +* A recoverable token standard can provide configurable safety for users or contracts who desire this safety. * Implementations of this standard will give users the ability to select a dispute resolution process on an opt-in basis and benefit the community by decreasing the necessity of consideration of token recovery actions. diff --git a/EIPS/eip-1081.md b/EIPS/eip-1081.md index d5a7556c86db4a..835ecac7edefd2 100644 --- a/EIPS/eip-1081.md +++ b/EIPS/eip-1081.md @@ -42,7 +42,7 @@ Optional Functions: - `acceptAndFulfill(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: During the course of the development of this standard, we discovered the desire for fulfillers to avoid paying gas fees on their own, entrusting the bounty's `issuer` to make the submission for them, and at the same time accept it. This is useful since it still immutably stores the exchange of tokens for completed work, but avoids the need for new bounty fulfillers to have any ETH to pay for gas costs in advance of their earnings. - `changeMasterCopy(StandardBounty _masterCopy)`: For `issuer`s to be able to change the masterCopy which their proxy contract relies on, if the proxy design pattern is being employed. - `refundableContribute(uint[] _amounts, StandardToken[] _tokens)`: While non-refundable contributions may be sent to a bounty simply by transferring those tokens to the address where it resides, one may also desire to contribute to a bounty with the option to refund their contribution, should the bounty never receive a correct submission which is paid out. -`refundContribution(uint _contributionId)`: If a bounty hasn't yet paid out to any correct submissions and is past it's deadline, those individuals who employed the `refundableContribute` function may retreive their funds from the contract. +`refundContribution(uint _contributionId)`: If a bounty hasn't yet paid out to any correct submissions and is past it's deadline, those individuals who employed the `refundableContribute` function may retrieve their funds from the contract. **Schemas** Persona Schema: diff --git a/EIPS/eip-1108.md b/EIPS/eip-1108.md index b77e50df270aba..792cc9085c0166 100644 --- a/EIPS/eip-1108.md +++ b/EIPS/eip-1108.md @@ -75,7 +75,7 @@ Fast elliptic curve cryptography is a keystone of a growing number of protocols * [The AZTEC protocol](https://github.com/AztecProtocol/AZTEC) utilizes the elliptic curve precompiles to construct private tokens, with zero-knowledge transaction logic, via the [ERC1723](https://github.com/ethereum/EIPs/issues/1723) and [ERC1724](https://github.com/ethereum/EIPs/issues/1724) standard. * [Matter Labs](https://github.com/matter-labs/matter-network) utilizes the precompiles to implement Ignis, a scaling solution with a throughput of 500txns per second -* [Rollup](https://github.com/rollup/rollup) utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is gauranteed by main-net, without an additional consensus layer +* [Rollup](https://github.com/rollup/rollup) utilizes the precompiles to create L2 scaling solutions, where the correctness of transactions is guaranteed by main-net, without an additional consensus layer * [ZEther](https://crypto.stanford.edu/~buenz/papers/zether.pdf) uses precompiles `ECADD` and `ECMUL` to construct confidential transactions These are all technologies that have been, or are in the process of being, deployed to main-net. There protocols would all benefit from reducing the gas cost of the precompiles. diff --git a/EIPS/eip-1109.md b/EIPS/eip-1109.md index 1d80f9101dc9bb..647796a77479f7 100644 --- a/EIPS/eip-1109.md +++ b/EIPS/eip-1109.md @@ -37,7 +37,7 @@ The input stack values are: mu_s[0] = The address of the precompiled smart contract that is called. mu_s[1] = Pointer to memory for the input parameters. -mu_s[2] = Length of the input parametes in bytes. +mu_s[2] = Length of the input parameters in bytes. mu_s[3] = Pointer to memory where the output is stored mu_s[4] = Length of the output buffer. @@ -75,7 +75,7 @@ Old contracts that call precompiled smart contracts with the CALL method, will c - Call to a regular contract - Call to a regular account - Call to 0x0 smart contract (Does not exists). -- Call with large values for the offste pointers and lenghts +- Call with large values for the offste pointers and lengths - Call with the exact gas remaining needed to call smart contract. - Call with the exact gas remaining minus one needed to call smart contract. diff --git a/EIPS/eip-1123.md b/EIPS/eip-1123.md index 11605fcfebe02b..aa0cf3170c52a4 100644 --- a/EIPS/eip-1123.md +++ b/EIPS/eip-1123.md @@ -89,7 +89,7 @@ Guiding Principles This specification makes the following assumptions about the document lifecycle. -1. Package manifests are intended to be generated programatically by +1. Package manifests are intended to be generated programmatically by package management software as part of the release process. 2. Package manifests will be consumed by package managers during tasks diff --git a/EIPS/eip-1154.md b/EIPS/eip-1154.md index a9fedf4d2e206a..4e8dc483fdd133 100644 --- a/EIPS/eip-1154.md +++ b/EIPS/eip-1154.md @@ -100,7 +100,7 @@ Transaction-wise, both systems are roughly equivalent in efficiency in this scen #### Result Immutability In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical consumers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the consumer enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the consumer would also have to handle result immutability. -For data which mutates over time, the `id` field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millenia). +For data which mutates over time, the `id` field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millennia). ## Implementation diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index 322738e3741b13..bfd1539c98bc6a 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -1,7 +1,7 @@ --- eip: 1155 title: ERC-1155 Multi Token Standard -author: Witek Radomski , Andrew Cooke , Philippe Castonguay , James Therien , Eric Binet +author: Witek Radomski , Andrew Cooke , Philippe Castonguay , James Therien , Eric Binet , Ronan Sandford type: Standards Track category: ERC status: Draft @@ -13,7 +13,7 @@ requires: 165 ## Simple Summary -A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens, or other configurations (for example, semi-fungible tokens). +A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens, or other configurations (e.g. semi-fungible tokens). ## Abstract @@ -67,7 +67,7 @@ interface ERC1155 /* is ERC165 */ { event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values); /** - @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absense of an event assumes disabled). + @dev MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absence of an event assumes disabled). */ event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); @@ -84,13 +84,13 @@ interface ERC1155 /* is ERC165 */ { MUST revert if `_to` is the zero address. MUST revert if balance of holder for token `_id` is lower than the `_value` sent. MUST revert on any other error. - After the above conditions are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). - MUST emit `TransferSingle` event on transfer success (see "Safe Transfer Rules" section of the standard). + MUST emit the `TransferSingle` event to reflect the balance change (see "Safe Transfer Rules" section of the standard). + After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). @param _from Source address @param _to Target address @param _id ID of the token type @param _value Transfer amount - @param _data Additional data with no specified format, MUST be sent in call to `onERC1155Received` on `_to` + @param _data Additional data with no specified format, MUST be sent unaltered in call to `onERC1155Received` on `_to` */ function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external; @@ -100,15 +100,15 @@ interface ERC1155 /* is ERC165 */ { MUST revert if `_to` is the zero address. MUST revert if length of `_ids` is not the same as length of `_values`. MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient. - MUST revert on any other error. - Transfers and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc). - After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). - MUST emit `TransferSingle` or `TransferBatch` event(s) on transfer success (see "Safe Transfer Rules" section of the standard). + MUST revert on any other error. + MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "Safe Transfer Rules" section of the standard). + Balance changes and events MUST follow the ordering of the arrays (_ids[0]/_values[0] before _ids[1]/_values[1], etc). + After the above conditions for the transfer(s) in the batch are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call the relevant `ERC1155TokenReceiver` hook(s) on `_to` and act appropriately (see "Safe Transfer Rules" section of the standard). @param _from Source address @param _to Target address @param _ids IDs of each token type (order and length must match _values array) @param _values Transfer amounts per token type (order and length must match _ids array) - @param _data Additional data with no specified format, MUST be sent in call to the `ERC1155TokenReceiver` hook(s) on `_to` + @param _data Additional data with no specified format, MUST be sent unaltered in call to the `ERC1155TokenReceiver` hook(s) on `_to` */ function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external; @@ -193,13 +193,13 @@ interface ERC1155TokenReceiver { This function MUST NOT consume more than 5,000 gas. @return `bytes4(keccak256("isERC1155TokenReceiver()"))` */ - function isERC1155TokenReceiver() external pure returns (bytes4); + function isERC1155TokenReceiver() external view returns (bytes4); } ``` ### Safe Transfer Rules -To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST operate with respect to the `ERC1155TokenReceiver`, a list of scenarios and rules follows. +To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST operate with respect to the `ERC1155TokenReceiver` hook functions, a list of scenarios and rules follows. #### Scenarios @@ -219,22 +219,30 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op **_Scenario#5 :_** The receiver implements the necessary `ERC1155TokenReceiver` interface function(s) but throws an error. * The transfer MUST be reverted. -**_Scenario#6 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of one and only one balance change (eg. safeTransferFrom called). +**_Scenario#6 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of one and only one balance change (e.g. safeTransferFrom called). * All the balances in the transfer MUST have been updated to match the senders intent before any hook is called on a recipient. +* All the transfer events for the transfer MUST have been emitted to reflect the balance changes before any hook is called on a recipient. * One of `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient. * The `onERC1155Received` hook SHOULD be called on the recipient contract and its rules followed. - See "onERC1155Received rules" for further rules that MUST be followed. * The `onERC1155BatchReceived` hook MAY be called on the recipient contract and its rules followed. - See "onERC1155BatchReceived rules" for further rules that MUST be followed. -**_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (eg. safeBatchTransferFrom called). +**_Scenario#7 :_** The receiver implements the `ERC1155TokenReceiver` interface and is the recipient of more than one balance change (e.g. safeBatchTransferFrom called). * All the balances in the transfer MUST have been updated to match the senders intent before any hook is called on a recipient. +* All the transfer events for the transfer MUST have been emitted to reflect the balance changes before any hook is called on a recipient. * `onERC1155Received` or `onERC1155BatchReceived` MUST be called on the recipient as many times as necessary such that every balance change for the recipient in the scenario is accounted for. - The return magic value for every hook call MUST be checked and acted upon as per "onERC1155Received rules" and "onERC1155BatchReceived rules". * The `onERC1155BatchReceived` hook SHOULD be called on the recipient contract and its rules followed. - See "onERC1155BatchReceived rules" for further rules that MUST be followed. * The `onERC1155Received` hook MAY be called on the recipient contract and its rules followed. - See "onERC1155Received rules" for further rules that MUST be followed. + +**_Scenario#8 :_** You are the creator of a contract that implements the `ERC1155TokenReceiver` interface and you forward the token(s) onto another address in one or both of `onERC1155Received` and `onERC1155BatchReceived`. +* Forwarding should be considered acceptance and then initiating a new `safeTransferFrom` or `safeBatchTransferFrom` in a new context. + - The prescribed keccak256 acceptance value magic for the receiver hook being called MUST be returned after forwarding is successful. +* The `_data` argument MAY be re-purposed for the new context. +* If forwarding unexpectedly fails the transaction MUST be reverted. #### Rules @@ -243,8 +251,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * MUST revert if `_to` is the zero address. * MUST revert if balance of holder for token `_id` is lower than the `_value` sent to the recipient. * MUST revert on any other error. -* After the above conditions are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "onERC1155Received rules" section). -* MUST emit `TransferSingle` event on transfer success (see "TransferSingle and TransferBatch event rules" section). +* MUST emit the `TransferSingle` event to reflect the balance change (see "TransferSingle and TransferBatch event rules" section). +* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` on `_to` and act appropriately (see "onERC1155Received rules" section). **_safeBatchTransferFrom rules:_** * Caller must be approved to manage all the tokens being transferred out of the `_from` account (see "Approval" section). @@ -252,9 +260,9 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op * MUST revert if length of `_ids` is not the same as length of `_values`. * MUST revert if any of the balance(s) of the holder(s) for token(s) in `_ids` is lower than the respective amount(s) in `_values` sent to the recipient. * MUST revert on any other error. -* After the above conditions are met, this function MUST check if `_to` is a smart contract (eg. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "`onERC1155Received` and onERC1155BatchReceived rules" section). -* MUST emit `TransferSingle` or `TransferBatch` event(s) on transfer success (see "TransferSingle and TransferBatch event rules" section). -* Transfers and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc). +* MUST emit `TransferSingle` or `TransferBatch` event(s) such that all the balance changes are reflected (see "TransferSingle and TransferBatch event rules" section). +* The balance changes and events MUST occur in the array order they were submitted (_ids[0]/_values[0] before _ids[1]/_values[1], etc). +* After the above conditions are met, this function MUST check if `_to` is a smart contract (e.g. code size > 0). If so, it MUST call `onERC1155Received` or `onERC1155BatchReceived` on `_to` and act appropriately (see "`onERC1155Received` and onERC1155BatchReceived rules" section). **_TransferSingle and TransferBatch event rules:_** * `TransferSingle` SHOULD be used to indicate a single balance transfer has occurred between a `_from` and `_to` pair. @@ -278,6 +286,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - When burning/destroying tokens, the `_to` argument MUST be set to `0x0` (i.e. zero address). * The total value transferred from address 0x0 minus the total value transferred to 0x0 MAY be used by clients and exchanges to be added to the "circulating supply" for a given token ID. * To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the `TransferSingle` event from `0x0` to `0x0`, with the token creator as `_operator`, and a `_value` of 0. +* All `TransferSingle` and `TransferBatch` events MUST be emitted to reflect all the balance changes that have occurred before any call(s) to `onERC1155Received` or `onERC1155BatchReceived`. + - To make sure event order is correct in the case of valid re-entry (e.g. if a receiver contract forwards tokens on receipt) state balance and events balance MUST match before calling an external contract. **_onERC1155Received rules:_** * The `_operator` argument MUST be the address of the account/contract that initiated the transfer (i.e. msg.sender). @@ -285,7 +295,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - `_from` MUST be 0x0 for a mint. * The `_id` argument MUST be the token type being transferred. * The `_value` argument MUST be the number of tokens the holder balance is decreased by and match what the recipient balance is increased by. -* The `_data` argument MUST contain the extra information provided by the sender for the transfer. +* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer. + - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_erc1155_tokens()"))` - If the return value is `bytes4(keccak256("accept_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. @@ -301,7 +312,8 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op - `_from` MUST be 0x0 for a mint. * The `_ids` argument MUST be the list of tokens being transferred. * The `_values` argument MUST be the list of number of tokens (matching the list and order of tokens specified in `_ids`) the holder balance is decreased by and match what the recipient balance is increased by. -* The `_data` argument MUST contain the information provided by the sender for a transfer. +* The `_data` argument MUST contain the unaltered information provided by the sender for the transfer. + - i.e. it MUST pass on the unaltered `_data` argument sent via the `safeTransferFrom` or `safeBatchTransferFrom` call for this transfer. * The recipient contract MAY accept an increase of its balance by returning the acceptance magic value `bytes4(keccak256("accept_batch_erc1155_tokens()"))` - If the return value is `bytes4(keccak256("accept_batch_erc1155_tokens()"))` the transfer MUST be completed or MUST revert if any other conditions are not met for success. * The recipient contract MAY reject an increase of its balance by calling revert. @@ -314,7 +326,7 @@ To be more explicit about how safeTransferFrom and safeBatchTransferFrom MUST op **_isERC1155TokenReceiver rules:_** * The implementation of `isERC1155TokenReceiver` function SHOULD be as follows: ``` - function isERC1155TokenReceiver() external pure returns (bytes4) { + function isERC1155TokenReceiver() external view returns (bytes4) { return 0x0d912442; // bytes4(keccak256("isERC1155TokenReceiver()")) } ``` diff --git a/EIPS/eip-1167.md b/EIPS/eip-1167.md index 4b35d0462aee2d..30154b6ad146df 100644 --- a/EIPS/eip-1167.md +++ b/EIPS/eip-1167.md @@ -22,7 +22,7 @@ By standardizing on a known minimal bytecode redirect implementation, this stand ## Motivation -This standard supports use-cases wherein it is desireable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies. +This standard supports use-cases wherein it is desirable to clone exact contract functionality with a minimum of side effects (e.g. memory slot stomping) and with low gas cost deployment of duplicate proxies. ## Specification diff --git a/EIPS/eip-1186.md b/EIPS/eip-1186.md index 3398e5b5819bf2..84f7442d016222 100644 --- a/EIPS/eip-1186.md +++ b/EIPS/eip-1186.md @@ -124,7 +124,7 @@ This one Method actually returns 3 different important data points: Combining these in one Method allows the client to work very efficient since the required data are already fetched from the db. -### Proofs for non existant values +### Proofs for non existent values In case an address or storage-value does not exist, the proof needs to provide enough data to verify this fact. This means the client needs to follow the path from the root node and deliver until the last matching node. If the last matching node is a branch, the proof value in the node must be an empty one. In case of leaf-type, it must be pointing to a different relative-path in order to proof that the requested path does not exist. diff --git a/EIPS/eip-1193.md b/EIPS/eip-1193.md index 26fd23fbf3b5f5..7398f75db8804c 100644 --- a/EIPS/eip-1193.md +++ b/EIPS/eip-1193.md @@ -47,7 +47,7 @@ All subscriptions from the node emit on "subscription type" (e.g. `eth_subscript ethereum.on('eth_subscription', listener: (result: any) => void): this; ``` -To create a subscription, call `ethereum.send('eth_subscribe')` or `ethereum.send('shh_subscribe')`. The subscription object will emit through the specifc subscription type. +To create a subscription, call `ethereum.send('eth_subscribe')` or `ethereum.send('shh_subscribe')`. The subscription object will emit through the specific subscription type. The result object will look as follows: diff --git a/EIPS/eip-1202.md b/EIPS/eip-1202.md index a114f2e2c09b5f..a6de062f8f4a79 100644 --- a/EIPS/eip-1202.md +++ b/EIPS/eip-1202.md @@ -23,7 +23,7 @@ following category: - [Telegram Channel t.me/erc1202](https://t.me/erc1202) for real-time and related random chat. 3. We are actively working on updating this draft as many feedbacks have come in since it merged into official EIP repo. -If you are viewing a snapshot of this draft, please be adviced the latest dev version of ERC 1202 can be found [here](https://github.com/xinbenlv/eip-1202-draft/blob/master/EIP-1202.md) +If you are viewing a snapshot of this draft, please be advised the latest dev version of ERC 1202 can be found [here](https://github.com/xinbenlv/eip-1202-draft/blob/master/EIP-1202.md) ## Simple Summary Propose a standard interface for voting. diff --git a/EIPS/eip-1261.md b/EIPS/eip-1261.md index 5645d025a99fd0..75dd50da28c7fb 100644 --- a/EIPS/eip-1261.md +++ b/EIPS/eip-1261.md @@ -106,9 +106,9 @@ interface IERC1261 {/* is ERC173, ERC165 */ /// @notice Requests membership from any address. /// @dev Throws if the `msg.sender` already has the token. - /// The individual `msg.sender` can request for a membership if some exisiting criteria are satisfied. + /// The individual `msg.sender` can request for a membership if some existing criteria are satisfied. /// When a membership is requested, this function emits the RequestedMembership event. - /// dev can store the membership request and use `approveRequest` to assign memebership later + /// dev can store the membership request and use `approveRequest` to assign membership later /// dev can also oraclize the request to assign membership later /// @param _attributeIndexes the attribute data associated with the member. /// This is an array which contains indexes of attributes. diff --git a/EIPS/eip-1271.md b/EIPS/eip-1271.md index 94b8551e61b93c..a76c905d608968 100644 --- a/EIPS/eip-1271.md +++ b/EIPS/eip-1271.md @@ -61,7 +61,7 @@ contract ERC1271 { } ``` -`isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependant (e.g. signers authorization level within smart wallet), signature scheme Dependant (e.g. ECDSA, multisig, BLS), etc. +`isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc. diff --git a/EIPS/eip-1283.md b/EIPS/eip-1283.md index 7361bdd89eaf83..38df50bc111a02 100644 --- a/EIPS/eip-1283.md +++ b/EIPS/eip-1283.md @@ -286,7 +286,7 @@ When *original value* is not 0, we want to prove that: charge `200 * N` gases, because no disk write is needed. * **Case II**: If the *final value* ends up being zero, we want to charge `5000 - 15000 + 200 * (N-1)` gas. Note that `15000` is the - refund in actual defintion. + refund in actual definition. * **Case III**: If the *final value* ends up being a changed non-zero value, we want to charge `5000 + 200 * (N-1)` gas. diff --git a/EIPS/eip-1380.md b/EIPS/eip-1380.md index 87a29aadeda43a..f8476e1f4673b6 100644 --- a/EIPS/eip-1380.md +++ b/EIPS/eip-1380.md @@ -25,7 +25,7 @@ Using `JUMP` comes at a considerable cost in complexity to the implementation of 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 them through `JUMP` requires a bigger effort from the compiler as opposed to being able to use `CALL`s. -Using call-to-self provides the guarentee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both +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 contract writers and contract consumers against potentially undetetected edge cases were memory could poison the context of the internal function. 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 diff --git a/EIPS/eip-1388.md b/EIPS/eip-1388.md index 84c2f296702b81..6bf1ca4ec8bee5 100644 --- a/EIPS/eip-1388.md +++ b/EIPS/eip-1388.md @@ -23,7 +23,7 @@ This ERC provides a smart contract interface for anyone to manage a list of atte ### Draft implementation ``` /* The purpose of this contract is to manage the list of attestation - * issuer contracts and their capacity to fulfil requirements + * issuer contracts and their capacity to fulfill requirements */ contract ManagedListERC { diff --git a/EIPS/eip-1417.md b/EIPS/eip-1417.md index 81f11a79e6cd34..f30735effc242a 100644 --- a/EIPS/eip-1417.md +++ b/EIPS/eip-1417.md @@ -26,7 +26,7 @@ The following standard allows for the implementation of a standard API for polls We considered the usage of polls with MVTs because MVTs serve as a permissioning mechanism. The manual permissioning of polls allows for vote weightage functions to take up several shapes and forms. Hence the voterbase function applies several logical checks on the vote sender to confirm that they are member(see EIP 1261) of a certain entity or combination of entities. For the specification of the nature of voting, we define the vote weight function. The vote weight function decides how much of vote share each voter will receive and this can be based on several criteria, some of which are listed below in this article. There are certain kinds of polls that enforce certain consequences on the voter, for example a poll may require a voter to lock in a certain amount of tokens, or require the voter to pay a small fee. These on-chain consequences can be coded into the consequence module of the poll standard. Finally, the last module is where the votes are added. A ballot for each candidate is updated whenever relevant, depending on the vote value, and the corresponding NoV count(number of voters). This module is common for most polls, and is the most straightforward. Polls may be time bound, ie. having a finish time, after which no votes are recorded, or be unbound, such that there is no finish time. The following are some examples of specific polls which leverage the flexibility of the poll standard, and it is possible to come up with several others: - Plurality Voting: The simplest form of voting is when you want all eligible voters to have one vote per person. This is the simplest to code, as the vote weight is 1, and there is no vote consequence. The only relevant module here is the voterbase, which can be categorized by one or more MVT contracts. -- Token proportional voting: This kind of a poll is actually possible without the use of a voterbase function, because the vote weight function having token proportionality automatically rules out addresses which dont hold the appropriate ERC - 20/ ERC - 777 token. However the voterbase function may be leveraged to further permission the system and give voting rights only to a fixed subset of token holders. +- Token proportional voting: This kind of a poll is actually possible without the use of a voterbase function, because the vote weight function having token proportionality automatically rules out addresses which don't hold the appropriate ERC - 20/ ERC - 777 token. However the voterbase function may be leveraged to further permission the system and give voting rights only to a fixed subset of token holders. - Capped Token Proportional Voting: This is a modified version of the previous example, where each voter is given proportional vote share only until a certain limit of token ownership. After exceeding that limit, holding more coins does not add more vote share. This format leverages the voterbase module effectively, disallowing people from spreading their coins across multiple addresses by allowing the admin to control which addresses can vote. - Delegated Voting: Certain polls may allow voters to delegate their votes to other voters. This is known as delegated voting or liquid democracy. For such a poll, a complicated vote weight function is needed, and a data structure concerning the voterbase is also required. A consequence of voting here would be that a user cannot delegate, and a consequence of delegating is that a user cannot vote. Sample implementation of polls contains an example of this vote scheme. - Karma Based Voting: A certain form of poll may be based on weightage from digital respect. This digital respect would be like a simple upvote from one member of voterbase to another. A mapping of mappings along with an appropriate vote weight function can serve this purpose. Sample implementation has an example. @@ -46,7 +46,7 @@ This realization happened while conducting market research on DAICOs. The first 2. Permissioning: Permissioning is an important aspect of polls, and is missing in most poll proposals so far, on the blockchain. For some reason, most blockchain based polls seem to consider token holding as the only way to permission a poll. However this hampers flexibility, and hence our poll standard is leveraging EIP 1261 in order to clear the permissioning hurdle. Not only does it allow for more creative poll structures in terms of vote weightage, but even improves the flexibility in permissioning by allowing developers to combine several entities and read attributes from entities. -3. Flexibilty: The vote weight module of the poll standard can be used effectively to design various kinds of poll contracts which function differently and are suited to different environments. Some examples are quadratic voting, karma voting, delegated voting, token based voting, and one person one vote systems. These schemes are possible due to the separation of voterbase creation and vote weight calculation. +3. Flexibility: The vote weight module of the poll standard can be used effectively to design various kinds of poll contracts which function differently and are suited to different environments. Some examples are quadratic voting, karma voting, delegated voting, token based voting, and one person one vote systems. These schemes are possible due to the separation of voterbase creation and vote weight calculation. 4. NoV Counts: Several weighted polls have struggled to provide proper transparency because they only show the final result without enough granularity. This is because they do not store the number of voters that have voted for each proposal, and only store the total accrued vote for each option. EIP 1417 solves this by additionally recording number of voters(NoV) in each proposal. This NoV count is redundant in the case of one person one vote, but elsewhere, it is helpful in figuring out concentration of power. This ensures that malicious parties can be traced to a larger extent. @@ -59,13 +59,13 @@ All that being said, we are very excited to share our proposal with the communit ### Benefits 1. Building applications (pollscan.io) on top of a standardized voting interface enables transparency and encourage more DAO/DAICO's to act responsibly in terms of governance -2. Create Action contracts which take actions programatically based on the result of a poll +2. Create Action contracts which take actions programmatically based on the result of a poll 3. Allow the compatibility with token standard such as [ERC-20](https://eips.ethereum.org/EIPS/eip-20) or (https://eips.ethereum.org/EIPS/eip-777)) and membership standard such as [EIP-1261](https://eips.ethereum.org/EIPS/eip-1261) 4. Flexibility allows for various voting schemes including but not limited to modern schemes such as PLCR Voting ### Use-cases: -Polls are useful in any context of collective decision making, which include but arent limited to: +Polls are useful in any context of collective decision making, which include but aren't limited to: 1. Governing public resources, like ponds, playgrounds, streets etc 2. Maintaining fiscal policy in a transparent consensus driven manner @@ -177,7 +177,7 @@ interface IPoll { /// @return end time as Unix Standard Time function getEndTime() external view returns (uint); - /// @notice retuns the list of entity addresses (eip-1261) used for perimissioning purposes. + /// @notice returns the list of entity addresses (eip-1261) used for perimissioning purposes. /// @dev addresses list can be used along with IERC1261 interface to define the logic inside `canVote()` function /// @return the list of addresses of entities function getProtocolAddresses() external view returns (address[]); @@ -231,7 +231,7 @@ Having explained our rationale, we are looking forward to hearing from the commu **Gas and Complexity** (regarding the enumeration for proposal count) -This specification contemplates implementations that contain a sample of 32 proposals (max upto blockgaslimit). If your application is able to grow and needs more than 32 proposals, then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound +This specification contemplates implementations that contain a sample of 32 proposals (max up to blockgaslimit). If your application is able to grow and needs more than 32 proposals, then avoid using for/while loops in your code. These indicate your contract may be unable to scale and gas costs will rise over time without bound **Privacy** diff --git a/EIPS/eip-145.md b/EIPS/eip-145.md index e3cc659122ac53..d0b38cf76c7cd8 100644 --- a/EIPS/eip-145.md +++ b/EIPS/eip-145.md @@ -18,7 +18,7 @@ Native bitwise shifting instructions are introduced, which are more efficient pr ## Motivation -EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing `SHL` and `SHR` using arithmetics cost each 35 gas, while the proposed instructions take 3 gas. +EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing `SHL` and `SHR` using arithmetic cost each 35 gas, while the proposed instructions take 3 gas. ## Specification diff --git a/EIPS/eip-1450.md b/EIPS/eip-1450.md index 1eeb19903971a3..ddbb8ba157f4a3 100644 --- a/EIPS/eip-1450.md +++ b/EIPS/eip-1450.md @@ -301,7 +301,7 @@ Investors may “lose” their credentials for a number of reasons: they simply If an Investor (or, say, the Investor’s heir) loses their credentials, the Investor must go through a notarized process to notify the RTA of the situation and supply a new Investor address. From there, the RTA can `mint` the “lost” securities to the new Investor address and `burnFrom` the old Investor address (because the RTA knows all Investors’ addresses). ## Rationale -The are currently no token standards that faciliate compliance with SEC regulations. The closest token is [ERC-884 (Delaware General Corporations Law (DGCL) compatible share token)](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-884.md) which states that SEC requirements are out of scope. [EIP-1404 (Simple Restricted Token Standard)](https://github.com/ethereum/EIPs/issues/1404) does not go far enough to address SEC requirements around re-issuing securities to Investors. +The are currently no token standards that facilitate compliance with SEC regulations. The closest token is [ERC-884 (Delaware General Corporations Law (DGCL) compatible share token)](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-884.md) which states that SEC requirements are out of scope. [EIP-1404 (Simple Restricted Token Standard)](https://github.com/ethereum/EIPs/issues/1404) does not go far enough to address SEC requirements around re-issuing securities to Investors. ## Backwards Compatibility `ERC-1450` maintains compatibility with ERC-20 tokens with the following stipulations: diff --git a/EIPS/eip-1462.md b/EIPS/eip-1462.md index f2004d0adc106c..59713317ba9d98 100644 --- a/EIPS/eip-1462.md +++ b/EIPS/eip-1462.md @@ -83,7 +83,7 @@ Each function must return a status code from the common set of Ethereum status c For both cases, * It is required for guaranteed compatibility with ERC-20 and ERC-777 wallets that each checking function returns `0x11` (Allowed) if not overridden with the issuer's custom logic. -* It is required that all overriden checking functions must revert if the action is not allowed or an error occured, according to the returned status code. +* It is required that all overridden checking functions must revert if the action is not allowed or an error occurred, according to the returned status code. Inside checker functions the logic is allowed to use any feature available on-chain: perform calls to registry contracts with whitelists/blacklists, use built-in checking logic that is defined on the same contract, or even run off-chain queries through an oracle. diff --git a/EIPS/eip-1470.md b/EIPS/eip-1470.md index bda13e61495b6f..d6f9dffc24f455 100644 --- a/EIPS/eip-1470.md +++ b/EIPS/eip-1470.md @@ -54,7 +54,7 @@ The SWC in its most basic form links a numeric identifier to a weakness variant. **SWC definition** -A SWC definition is formated in markdown to allow good readability and tools to process them easily. It consists of the following attributes. +A SWC definition is formatted in markdown to allow good readability and tools to process them easily. It consists of the following attributes. - Title: A name for the weakness that points to the technical root cause. - Relationships: Links a CWE _Base_ or _Class_ type to its CWE variant. The _Integer Overflow and Underflow_ variant for example is linked to [CWE-682 - Incorrect Calculation](https://cwe.mitre.org/data/definitions/682.html). diff --git a/EIPS/eip-1484.md b/EIPS/eip-1484.md index 87d4340040b207..ebe60637774e65 100644 --- a/EIPS/eip-1484.md +++ b/EIPS/eip-1484.md @@ -179,7 +179,7 @@ Triggers event: [IdentityCreated](#identitycreated) #### createIdentityDelegated -Preforms the same logic as `createIdentity`, but can be called by any address. This function requires a signature from the `associatedAddress` to ensure their consent. +Performs the same logic as `createIdentity`, but can be called by any address. This function requires a signature from the `associatedAddress` to ensure their consent. ```solidity function createIdentityDelegated( @@ -252,7 +252,7 @@ Triggers event: [ProviderAdded](#provideradded) #### addProvidersFor -Preforms the same logic as `addProviders`, but must be called by a `Provider`. +Performs the same logic as `addProviders`, but must be called by a `Provider`. ```solidity function addProvidersFor(uint ein, address[] memory providers) public; @@ -273,7 +273,7 @@ Triggers event: [ProviderRemoved](#providerremoved) #### removeProvidersFor -Preforms the same logic as `removeProviders`, but is called by a `Provider`. +Performs the same logic as `removeProviders`, but is called by a `Provider`. ```solidity function removeProvidersFor(uint ein, address[] memory providers) public; @@ -294,7 +294,7 @@ Triggers event: [ResolverAdded](#resolveradded) #### addResolversFor -Preforms the same logic as `addResolvers`, but must be called by a `Provider`. +Performs the same logic as `addResolvers`, but must be called by a `Provider`. ```solidity function addResolversFor(uint ein, address[] memory resolvers) public; @@ -314,7 +314,7 @@ Triggers event: [ResolverRemoved](#resolverremoved) #### removeResolversFor -Preforms the same logic as `removeResolvers`, but must be called by a `Provider`. +Performs the same logic as `removeResolvers`, but must be called by a `Provider`. ```solidity function removeResolversFor(uint ein, address[] memory resolvers) public; diff --git a/EIPS/eip-1485.md b/EIPS/eip-1485.md index 716455caf8eca6..12040c4afdb76e 100644 --- a/EIPS/eip-1485.md +++ b/EIPS/eip-1485.md @@ -97,7 +97,7 @@ In TETHashV1, Adapts fully follow the FNV1A implementation. - TETHASHV1 FNV1A implementation -Followings are reference implementation of FNV1A adapted in TETHashV1. +Following are reference implementation of FNV1A adapted in TETHashV1. ```cpp // Reference Pseudo c/cpp implementation @@ -177,7 +177,7 @@ F(00,10)::VEC(0, 10, ffffffff, 0):: FNV :00000010, DF=0000001f(05) DS(00000 In case of ethash algorithm, it can't prevent ASIC forever. -And, current ethash algorithm's FNV function is depricated. +And, current ethash algorithm's FNV function is deprecated. So, It needs to be upgraded and it will make current ethash based ASICs obsolete. @@ -187,7 +187,7 @@ Another propose of big differencing the Ethash algorithm need to crypto analysis **Verification and Optimization timeline Examples** -orignal ethminer (2015) -> claymore optimized miner (2016) [1year] +original ethminer (2015) -> claymore optimized miner (2016) [1year] genoil ethminer (2015) -> ethereum-mining/ethminer (2017) [2year] diff --git a/EIPS/eip-1491.md b/EIPS/eip-1491.md index 3b9c9a645755c7..66502ef07748b6 100644 --- a/EIPS/eip-1491.md +++ b/EIPS/eip-1491.md @@ -18,7 +18,7 @@ A standard interface for Human Capital Accounting tokens. ## Abstract -The following standard allows for the implementation of a standard API for HUCAP tokens within smart contracts. This standard provides basic functionality to discover, track and transfer the motivational hierarchy of human resources. While blockchain architecture has suceeded in the financialisation of integrity by way of transparency; correspondingly real world outcomes will be proportional to the degree of individualisation of capital by way of knowledge. +The following standard allows for the implementation of a standard API for HUCAP tokens within smart contracts. This standard provides basic functionality to discover, track and transfer the motivational hierarchy of human resources. While blockchain architecture has succeeded in the financialisation of integrity by way of transparency; correspondingly real world outcomes will be proportional to the degree of individualisation of capital by way of knowledge. ## Motivation @@ -425,21 +425,21 @@ interface IERC_HUCAP_KEYSIGNING_EXTENSION { /** /// @notice Cycle through state transition of an Agent in the ecosystem. /// @param _address toggle on/off a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract */ function flipTo(address _address) external onlyOwner returns (IS); /** /// @notice Turn Agent in the ecosystem to on/off. /// @param _address toggle on/off a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract */ function toggle(address _address) external onlyOwner returns (bool); /** /// @notice Set the trust level of an Agent in the ecosystem. /// @param _level toggle on/off a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract */ function trust(Trust _level) returns (bytes32 Trust); @@ -457,66 +457,66 @@ pragma experimental ABIEncoderV2; interface IERC_HUCAP_TRACKUSERS_EXTENSION { - /// @notice Instatiate an Agent in the ecosystem with default data. + /// @notice Instantiate an Agent in the ecosystem with default data. /// @param _address initialise a doer agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function initAgent(Doers _address) external onlyControlled returns (bool); /// @notice Get the data by uuid of an Agent in the ecosystem. /// @param _uuid Get the address of a unique uid - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function getAgent(bytes32 _uuid) view external returns (address); /// @notice Get the data of all Talents in the ecosystem. /// @param _address Query if address belongs to an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function iam(address _address) view public returns (bool); /// @notice Get the data of all Talents in the ecosystem. /// @param _address Query if address belongs to a doer - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function isDoer(address _address) view public returns (IS); /// @notice Get the number of doers that can be spawned by a Creators. /// The query condition of the contract - // @dev `anybody` can retrive the count data in the contract + // @dev `anybody` can retrieve the count data in the contract function getAgent(address _address) view public returns (bytes32 keyid_, IS state_, bool active_, uint myDoers_); /// @notice Get the data of all Talents in the ecosystem. /// @param _talent The talent whose frequency is being queried - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function getTalents(bytes32 _talent) view external returns (uint talentK_, uint talentI_, uint talentR_, uint talentF_); /// @notice Increment a kind of talent in the ecosystem. /// @param The talent whose frequency is being queried - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function incTalent() payable public onlyDoer returns (bool); /// @notice Decrement a kind of talent in the ecosystem.. /// @param The talent whose frequency is being queried - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function decTalent() payable public onlyDoer returns (bool); /// @notice Set the Public-Key Id of an Agent in the ecosystem. /// @param _address Set the Public-key Id of an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, bytes32 _keyId) external onlyControlled returns (bytes32); /// @notice Transition the states of an Agent in the ecosystem. /// @param _address Set the stance of an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, IS _state) external onlyControlled returns (IS); /// @notice Set the active status of an Agent in the ecosystem. /// @param _address Toggle the true/false status of an agent - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAgent(address _address, bool _active) external onlyControlled returns (bool); /// @notice Set the data of all Intentions of Agents in the ecosystem. /// @param _serviceId Track number of offers available - // @dev `anybody` can retrive the talent data in the contract + // @dev `anybody` can retrieve the talent data in the contract function setAllPromises(bytes32 _serviceId) external onlyControlled; /* End of interface IERC_HUCAP_TRACKUSERS_EXTENSION */ diff --git a/EIPS/eip-1523.md b/EIPS/eip-1523.md new file mode 100644 index 00000000000000..31c2fef02c11b5 --- /dev/null +++ b/EIPS/eip-1523.md @@ -0,0 +1,129 @@ +--- +eip: 1523 +title: Standard for Insurance Policies as ERC-721 Non Fungible Tokens +author: Christoph Mussenbrock (@christoph2806) +discussions-to: https://github.com/ethereum/EIPs/issues/1523 +status: Draft +type: Standards Track +category: ERC +created: 2018-10-10 +requires: 721 +--- + +## Simple Summary + +A standard interface for insurance policies, based on ERC 721. + +## Abstract + +The following standard allows for the implementation of a standard API for insurance policies within smart contracts. +Insurance policies are financial assets which are unique in some aspects, as they are connected to a customer, a specific risk, or have other unique properties like premium, period, carrier, underwriter etc. +Nevertheless, there are many potential applications where insurance policies can be traded, transferred or otherwise treated as an asset. +The ERC 721 standard already provides the standard and technical means to handle policies as a specific class of non fungible tokens. +insurance In this proposal, we define a minimum metadata structure with properties which are common to the greatest possible class of policies. + +## Motivation + +For a decentralized insurance protocol, a standard for insurance policies is crucial for interoperability of the involved services and application. +It allows policies to be bundled, securitized, traded in a uniform and flexible way by many independent actors like syndicates, brokers, and insurance companies. + +## Specification + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +An ERC-1523 compliant insurance policy is a non-fungible token which **MUST adhere to the ERC-721 token standard** and **MUST implement theERC721Metadata and the ERC721Enumerable interface**: + +```solidity +/// @title ERC-1523 Insurance Policy Standard +/// Note: the ERC-165 identifier for this interface is 0x5a04be32 +interface ERC1523 /* is ERC721, ERC721Metadata, ERC721Enumerable */ { + +} +``` + +The implementor MAY choose values for the ```name``` and ```symbol```. + +The **policy metadata extension** is **RECOMMENDED** for ERC-1523 smart contracts. +This allows your smart contract to be interrogated for policy metadata. + +```solidity +/// @title ERC-1523 Insurance Policy Standard, optional policy metadata extension +/// @dev See ... +/// Note: the ERC-165 identifier for this interface is 0x5a04be32 +interface ERC1523PolicyMetadata /* is ERC1523 */ { + + /// @notice Metadata string for a given property. + /// Properties are identified via hash of their property path. + /// e.g. the property "name" in the ERC721 Metadata JSON Schema has the path /properties/name + /// and the property path hash is the keccak256() of this property path. + /// this allows for efficient addressing of arbitrary properties, as the set of properties is potentially unlimited. + /// @dev Throws if `_propertyPathHash` is not a valid property path hash. + function policyMetadata(uint256 _tokenId, bytes32 _propertyPathHash) external view returns (string _property); + +} +``` + +In analogy to the “ERC721 Metadata JSON Schema”, the tokenURI **MUST** point to a JSON file with the following properties: +```json +{ + "title": "Asset Metadata", + "type": "object", + "properties": { + "name": { + "type": "string", + "description": "Identifies the asset to which this NFT represents", + }, + "description": { + "type": "string", + "description": "Describes the asset to which this NFT represents", + }, + "carrier": { + "type": "string", + "description": "Describes the carrier which takes the primary risk", + }, + "risk": { + "type": "string", + "description": "Describes the risk", + }, + "parameters": { + "type": "string", + "description": "Describes further parameters characterizing the risk", + }, + "status": { + "type": "string", + "description": "Defines the status of the policy, e.g. Applied, Underwritten, Claimed, Paid out, etc." + } + } +} +``` + +## Rationale + +Insurance policies form an important class of financial assets, and it is natural to express those assets as a class of non-fungible tokens which adhere to the established ERC-721 standard. +We propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy. +While policies can have a multitude of possible properties, it is common that policies are issued by some entity, which is basically the entity responsible for paying out claims. +Second, an insurance policy is typically related to a specific risk. Some risks are unique, but there are cases where many policies share the same risk +(e.g. all flight delay policies for the same flight). +In general, the relation of policies to risks is a many-to-one relation with the special case of a one-to-one relation. +Third, most policies need more parameters to characterize the risk and other features, like premium, period etc. +Forth, a policy has a lifecycle of different statuses. +We believe that those four properties are necessary to describe a policy. For many applications, those properties may be even sufficient. +However, any implementation **MAY** chose to implement more properties. + +### On-chain vs. off-chain metadata +For some applications it will be sufficient to store the metadata in an off-chain repository or database which can be addressed by the tokenURI resource locator. +For more advanced applications, it can be desirable to have metadata available on-chain. +Therefore, we require that the ```tokenURI``` **MUST** point to a JSON with the above structure, while the implementation of the ```policyMetadata``` function is **OPTIONAL**. + + +## Backwards Compatibility + + +## Test Cases + + +## Implementation + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-1571.md b/EIPS/eip-1571.md index fedc29b994b487..942d0e359bbcc4 100644 --- a/EIPS/eip-1571.md +++ b/EIPS/eip-1571.md @@ -80,7 +80,7 @@ The JSON representation of `request` object is made of these parts: The JSON representation of `response` object is made of these parts: - mandatory `id` member of type Integer : the identifier of the request this response corresponds to - optional `error` member : whether an error occurred during the parsing of the method or during it's execution this member **MUST** be present and valued. If no errors occurred this member **MUST NOT** be present. For a detailed structure of the `error` member see below. -- optional `result` member : This has to be set, if the corresponding request requires a result from the user. If no errors occurred by invoking the corresponding function, this member **MUST** be present even if one or more informations are null. The type can be of Object or single type Array or Primitive string/number. If no data is meant back for the issuer (the method is void on the receiver) or an error occurred this member **MUST NOT** be present. +- optional `result` member : This has to be set, if the corresponding request requires a result from the user. If no errors occurred by invoking the corresponding function, this member **MUST** be present even if one or more information are null. The type can be of Object or single type Array or Primitive string/number. If no data is meant back for the issuer (the method is void on the receiver) or an error occurred this member **MUST NOT** be present. You'll notice here some differences with standard JSON-RPC-2.0. Namely the result member is not always required. Basically a response like this : ```json @@ -141,13 +141,13 @@ Using proper error codes pools may properly inform miners of the condition of th - Error codes 5xx : server could not process the request due to internal errors ### Notifications -A notification message has the very same representation of a `request` with the only difference the `id` member **MUST NOT** be present. This means the issuer is not interested nor expects any reponse to this message. It's up to the receiver to take actions accordingly. For instance the receiver **MAY** decide to execute the method, or, in case of errors or methods not allowed, drop the connection thus closing the session. +A notification message has the very same representation of a `request` with the only difference the `id` member **MUST NOT** be present. This means the issuer is not interested nor expects any response to this message. It's up to the receiver to take actions accordingly. For instance the receiver **MAY** decide to execute the method, or, in case of errors or methods not allowed, drop the connection thus closing the session. #### Error member As seen above a `response` **MAY** contain an `error` member. When present this member **MUST** be an Object with: - mandatory member `code` : a Number which identifies the error occurred - mandatory member `message` : a short human readable sentence describing the error occurred -- optional member `data` : a Structured or Primitive value that contains additional informations about the error. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.). +- optional member `data` : a Structured or Primitive value that contains additional information about the error. The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.). ## Protocol Flow - Client starts session by opening a TCP socket to the server @@ -373,7 +373,7 @@ At the beginning of each `session` the server **MUST** send this notification be Whenever the server detects that one, or two, or three or four values change within the session, the server will issue a notification with one, or two or three or four members in the `param` object. For this reason on each **new** session the server **MUST** pass all four members. As a consequence the miner is instructed to adapt those values on **next** job which gets notified. The new `algo` member is defined to be prepared for possible presence of algorithm variants to ethash, namely ethash1a or ProgPow. Pools providing multicoin switching will take care to send a new `mining.set` to miners before pushing any job after a switch. -The client wich can't support the data provided in the `mining.set` notification **MAY** close connection or stay idle till new values satisfy it's configuration (see `mining.noop`). +The client which can't support the data provided in the `mining.set` notification **MAY** close connection or stay idle till new values satisfy it's configuration (see `mining.noop`). All client's implementations **MUST** be prepared to accept new extranonces during the session: unlike in EthereumStratum/1.0.0 the optional client advertisement `mining.extranonce.subscribe` is now implicit and mandatory. The miner receiving the `extranonce` **MUST** initialize the search segment for next job resizing the extranonce to a hex of 16 bytes thus appending as many zeroes as needed. @@ -462,7 +462,7 @@ When a miner finds a solution for a job he is mining on it sends a `mining.submi ] } ``` -First element of `params` array is the jobId this solution refers to (as sent in the `mining.notify` message from the server). Second element is the `miner nonce` as hex. Third element is the token given to the worker previous `mining.authorize` request. Any `mining.submit` request bound to a worker which was not succesfully authorized - i.e. the token does not exist in the session - **MUST** be rejected. +First element of `params` array is the jobId this solution refers to (as sent in the `mining.notify` message from the server). Second element is the `miner nonce` as hex. Third element is the token given to the worker previous `mining.authorize` request. Any `mining.submit` request bound to a worker which was not successfully authorized - i.e. the token does not exist in the session - **MUST** be rejected. You'll notice in the sample above the `miner nonce` is only 12 bytes wide (should be 16). Why ? That's because in the previous `mining.set` the server has set an `extranonce` of `af4c`. This means the full nonce is `af4c68765fccd712` @@ -488,7 +488,7 @@ or, in case of any error or condition with a detailed error object Client **should** treat errors as "soft" errors (stales) or "hard" (bad nonce computation, job not found etc.). Errors in 5xx range are server errors and suggest the miner to abandon the connection and switch to a failover. ### Hashrate -Most pools offer statistic informations, in form of graphs or by API calls, about the calculated hashrate expressed by the miner while miners like to compare this data with the hashrate they read on their devices. Communication about parties of these informations have never been coded in Stratum and most pools adopt the method from getWork named `eth_submitHashrate`. +Most pools offer statistic information, in form of graphs or by API calls, about the calculated hashrate expressed by the miner while miners like to compare this data with the hashrate they read on their devices. Communication about parties of these information have never been coded in Stratum and most pools adopt the method from getWork named `eth_submitHashrate`. In this document we propose an official implementation of the `mining.hashrate` request. This method behaves differently when issued from client or from server. #### Client communicates it's hashrate to server. @@ -540,7 +540,7 @@ Optionally the server can **notify** client about it's overall performance (acco } } ``` -Where `params` is an object which holds theese members for values of the **whole session**: +Where `params` is an object which holds these members for values of the **whole session**: - `interval` (number) the width, in minutes, of the observation window. "_in the last x minutes we calculated ..._" - `hr` (hex) representation of the hashrate the pool has calculated for the miner - `accepted` is an array of two number elements : the first is the overall count of accepted shares and the second is the number of stale shares. The array must be interpreted as "total accepted of which x are stale" diff --git a/EIPS/eip-1613.md b/EIPS/eip-1613.md index 7ed7b64c2a6dbb..973e040f1ef96d 100644 --- a/EIPS/eip-1613.md +++ b/EIPS/eip-1613.md @@ -225,7 +225,7 @@ Scaling such attack would be prohibitively expensive, and actually quite profita ##### Attack: Relay attempts to censor a transaction by signing it, but using a nonce higher than it's current nonce. In this attack, the Relay did create and return a perfectly valid transaction, but it will not be mined until this Relay fills the gap in the nonce with 'missing' transactions. -This may delay the relaying of some transactions indefinately. In order to mitigate that, the sender includes a `max_nonce` parameter with it's signing request. +This may delay the relaying of some transactions indefinitely. In order to mitigate that, the sender includes a `max_nonce` parameter with it's signing request. It is suggested to be higher by 2-3 from current nonce, to allow the relay process several transactions. When the sender receives a transaction signed by a Relay he validates that the nonce used is valid, and if it is not, the client will ignore the given relay and use other relays to relay given transaction. Therefore, there will be no actual delay introduced by such attack. diff --git a/EIPS/eip-1616.md b/EIPS/eip-1616.md index c709dd104ccb20..c22cdec233d9ab 100644 --- a/EIPS/eip-1616.md +++ b/EIPS/eip-1616.md @@ -25,7 +25,7 @@ This EIP contains the following core ideas: Potential advanced uses of attribute registries include: * Encoding complex boolean expressions which combine multiple attributes into a single uint256 key, which is then parsed and evaluated by the registry logic. * Using values associated with an attribute to query additional on-chain or off-chain metadata. -* Resolving attribute values by calling into seperate attribute registries or other contracts, delegating authority without changing the interface of the registry. +* Resolving attribute values by calling into separate attribute registries or other contracts, delegating authority without changing the interface of the registry. ## Motivation @@ -213,7 +213,7 @@ contract AttributeRegistry is AttributeRegistryInterface { mapping(address => mapping(uint256 => uint256)) private _issuedAttributeValues; /** - * @notice The constructor function, defines the two attribute types avaiable + * @notice The constructor function, defines the two attribute types available * on this particular registry. */ constructor() public { diff --git a/EIPS/eip-162.md b/EIPS/eip-162.md index 60cec465991f91..d1936bd63b0df2 100644 --- a/EIPS/eip-162.md +++ b/EIPS/eip-162.md @@ -135,7 +135,7 @@ The following table outlines what portion of the balance held in a deed contract ### Deployment and Upgrade process -The Initial Registrar requires the ENS's address as a contructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar's address as owner of the `eth` node. +The Initial Registrar requires the ENS's address as a constructor, and should be deployed after the ENS. The multisig account owning the root node in the ENS should then set the Initial Registrar's address as owner of the `eth` node. The Initial Registrar is expected to be replaced by a Permanent Registrar approximately 2 years after deployment. The following process should be used for the upgrade: 1. The Permanent Registrar contract will be deployed. diff --git a/EIPS/eip-165.md b/EIPS/eip-165.md index 5d333aab4f91e7..e71e96e02a462b 100644 --- a/EIPS/eip-165.md +++ b/EIPS/eip-165.md @@ -144,7 +144,7 @@ contract ERC165Query { assembly { let x := mload(0x40) // Find empty storage location using "free memory pointer" - mstore(x, erc165ID) // Place signature at begining of empty storage + mstore(x, erc165ID) // Place signature at beginning of empty storage mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature success := staticcall( diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 866cf7807e59ee..6c6d2187f82143 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -41,11 +41,13 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [EIP-1352](https://eips.ethereum.org/EIPS/eip-1352): Specify restricted address range for precompiles/system contracts - [EIP-1380](https://eips.ethereum.org/EIPS/eip-1380): Reduced gas cost for call to self - [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559): Fee market change for ETH 1.0 chain +- [EIP-1965](https://eips.ethereum.org/EIPS/eip-1965): Method to check if a chainID is valid at a specific block Number - [EIP-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme - [EIP-1706](https://eips.ethereum.org/EIPS/eip-1706): Disable SSTORE with gasleft lower than call stipend - [EIP-1803](https://eips.ethereum.org/EIPS/eip-1803): Rename opcodes for clarity - [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes +- [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available. - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction ## Timeline diff --git a/EIPS/eip-1681.md b/EIPS/eip-1681.md index 2e557f28cbf73a..28c6b2fca4a720 100644 --- a/EIPS/eip-1681.md +++ b/EIPS/eip-1681.md @@ -51,7 +51,7 @@ For the dust-account clearing usecase, - Other schemas which uses the `nonce` can have unintended side-effects, - such as inability to create contracts at certain addresses. - more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine. - - More intricate schemes like `highest-nonce` are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requireing one more journalled field. + - More intricate schemes like `highest-nonce` are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requiring one more journalled field. ### Rationale for walltime diff --git a/EIPS/eip-1702.md b/EIPS/eip-1702.md index 1dc088d2a76f97..e6096ee500971a 100644 --- a/EIPS/eip-1702.md +++ b/EIPS/eip-1702.md @@ -171,7 +171,7 @@ change how current contracts are executed. ### Performance Currently nearly all full node implementations uses config parameters -to decide which virtual machine version to use. Switching vitual +to decide which virtual machine version to use. Switching virtual machine version is simply an operation that changes a pointer using a different set of config parameters. As a result, this scheme has nearly zero impact to performance. diff --git a/EIPS/eip-1710.md b/EIPS/eip-1710.md new file mode 100644 index 00000000000000..876910ae7be2d1 --- /dev/null +++ b/EIPS/eip-1710.md @@ -0,0 +1,66 @@ +--- +eip: 1710 +title: URL Format for Web3 Browsers +author: Bruno Barbieri (@brunobar79) +discussions-to: https://ethereum-magicians.org/t/standarize-url-format-for-web3-browsers/2422 +status: Draft +type: Standards Track +category: ERC +created: 2019-01-13 +requires: 155 +--- + + + +## Simple Summary + +A standard way of representing web3 browser URLs for decentralized applications. + +## Abstract + + +Since most normal web browsers (specifically on mobile devices) can not run decentralized applications correctly because of the lack of web3 support, it is necessary to differentiate them from normal urls, so they can be opened in web3 browsers if available. + +## Motivation + + +Lots of dApps that are trying to improve their mobile experience are currently (deep)linking to specific mobile web3 browsers which are currently using their own url scheme. + +In order to make the experience more seamless, dApps should still be able to recommend a specific mobile web3 browser via [deferred deeplinking](https://en.wikipedia.org/wiki/Deferred_deep_linking) but by having a standard url format, if the user already has a web3 browser installed that implements this standard, it will be automatically linked to it. + +There is also a compatibility problem with the current `ethereum:` url scheme described in [EIP-831](https://eips.ethereum.org/EIPS/eip-831) where any ethereum related app (wallets, identity management, etc) already registered it and because of iOS unpredictable behavior for multiple apps handling a single url scheme, users can end up opening an `ethereum:` link in an app that doesn not include a web3 browser and will not be able to handle the deeplink correctly. + +## Specification + + + +### Syntax + +Web3 browser URLs contain "dapp" in their schema (protocol) part and are constructed as follows: + + request = "dapp" ":" [chain_id "@"] dapp_url + chain_id = 1*DIGIT + dapp_url = URI + +### Semantics + +`chain_id` is optional and it is a parameter for the browser to automatically select the corresponding chain ID as specified in [EIP-155](https://eips.ethereum.org/EIPS/eip-155) before opening the dApp. + +`dapp_url` is a valid [RFC3986](https://www.ietf.org/rfc/rfc3986.txt) URI + +This a complete example url: + +`dapp:1@peepeth.com/brunobar79?utm_source=github` + +which will open the web3 browser, select `mainnet` (chain_id = 1) and then navigate to: + +`https://peepeth.com/brunobar79?utm_source=github` + +## Rationale + + +The proposed format attempts to solve the problem of vendor specific protocols for web3 browsers, avoiding conflicts with the existing 'ethereum:' URL scheme while also adding an extra feature: `chain_id` which will help dApps to be accessed with the right network preselected, optionally extracting away that complexity from end users. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 1c623887562991..8aa747219a2302 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -16,7 +16,7 @@ requires: 137 Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. -This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus potentially increasing privacy. They also allow to give more control to the applications developpers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. +This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus potentially increasing privacy. They also allow to give more control to the applications developers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. This new accounts type can allow to significantly improve UX and permit new designs for applications of the crypto permissionned web. @@ -26,7 +26,7 @@ In a wallet, an user often holds most of her funds in her main accounts. These a We introduce here a new account type, app keys, which permits signing delegation and accounts isolation across applications for privacy and security. -In this EIP, we provide a proposal on how to uniquely identify and authenticate each application, how to derive the accounts along an Hierachical Deterministic (HD) path restricted for the domain and we finally define an API for applications to derive and use these app keys. This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each application. +In this EIP, we provide a proposal on how to uniquely identify and authenticate each application, how to derive the accounts along an Hierarchical Deterministic (HD) path restricted for the domain and we finally define an API for applications to derive and use these app keys. This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each application. ## Motivation @@ -86,7 +86,7 @@ However, there may be benefits to use only one depth instead of 3. We could use ### Personas -We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interaction with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. +We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interaction with a given app across personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. We use a string following BIP32 format (can be hardened) to define personas. The indexes should be hex under 0x80000000, 31 bits. @@ -105,7 +105,7 @@ There are a few restrictions however on the characters used and normalisation, e In addition there must be a maximum size to the domain string that we need to determine such that the mapping from strings to nodes remains injective, to avoid collision. -We recommend this standard to be following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convinience and reference. +We recommend this standard to be following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convenience and reference. ``` Normalising and validating names @@ -239,9 +239,9 @@ and converted to uints ``` -* Second approach favors an homogenous decomposition: +* Second approach favors an homogeneous decomposition: -Equal lenght indexes would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: +Equal length indexes would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 || x9 || x10 || x11 || x12 || x13 || x14 || x15 @@ -270,7 +270,7 @@ Finally, the last part of the hd path is under the application's control. This w We consider that a given child on the HD tree should be called an `account` and not an `address` since it is composed of a private key, a public key and an address. Similarly to the persona path, this sub path must follow bip32, with hex under 0x80000000, 31 bits. -It can be hardened depending on each application's needs and can be writen as hex or unsigned integers. +It can be hardened depending on each application's needs and can be written as hex or unsigned integers. It can include a large number of indexes. Q [Should we set a limit on the persona and application customsable hd path number of indexes?] @@ -299,7 +299,7 @@ We propose to introduce new RPC methods but they should be restricted and wrappe * `wallet.appkey.enable(options)` This method allows to enable app keys (getting user permission to use and allow him to select the persona she would like to use). -[TBD] Could return the account public key from the HD path before `the app's custom subPath`. Hence from this app's root account, one could derive all non hardened childs public keys of the app's keys. +[TBD] Could return the account public key from the HD path before `the app's custom subPath`. Hence from this app's root account, one could derive all non hardened children public keys of the app's keys. [TBD] where `options` is a javascript object containing the permissions requested for these app keys. Options could also include a challenge to be signed by the app's root account (would serve as authentication of the users from the app's perspective). The signature should then be also returned. @@ -390,7 +390,7 @@ If there is a strong demand, we could add a method that exposes the private keys We indeed think that writing applications that don't need to manipulate the user private keys is a better pattern. For instance, if one needs the user to sign data while being offline, one should for instance rather implement a delegation method to an external application's controlled account rather than storing the user private key on a server that stays online. -### Persona isolation accross applications for privacy +### Persona isolation across applications for privacy The persona path is set by the user-wallet interaction and known only by them. There is thus a strict isolation between 2 different persona subpaths as if they were generated by different mnemonics. @@ -417,13 +417,13 @@ For the persona specification this may not be possible, unless we impose some st ### Hardened and non-hardened indexes: privacy and functionality -Hardening allows to increase privacy. If the extended public key of a parent level in the HD tree is known, public keys of its childs can not be computed if they are hardened. On the contrary if the child indexes are not hardened one can enumerate the child public keys and use that for the application design or to easily restore a wallet and it increases functionality. +Hardening allows to increase privacy. If the extended public key of a parent level in the HD tree is known, public keys of its children can not be computed if they are hardened. On the contrary if the child indexes are not hardened one can enumerate the child public keys and use that for the application design or to easily restore a wallet and it increases functionality. For the first parts of the HD tree, we need isolation and privacy. Thus we use hardened indexes for the persona and application paths in case some extended public key leaks at some previous level of the tree, it would protect the sub trees (of course this has no impact if private keys leak). For instance if we don't harden the application path, in case a persona public key is known and the application subpath does not use hardening either, one could get all `app keys` public keys for every application for this persona. -However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). +However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction across 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). ### Alternatives for the HD derivation path @@ -478,7 +478,7 @@ We think our approach while also being more englobing benefits from not requirin #### Shortening the Hash node -Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to hashes. +Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the length while retaining an injective mapping from strings to hashes. #### Alternative application identification specification @@ -509,18 +509,18 @@ Another alternative could be to use the plain website url and get rid of ens alt For authentication we use DNS and ENS resolution, and browsing to a given url resolved. A few comments on this: A few comments in case of ENS resolution: -* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata paramater such as `author address` for a blockchain less authentication of the application (e.g. application server signs a challenge message with the author address resolved in the ENS metadata). +* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata parameter such as `author address` for a blockchain less authentication of the application (e.g. application server signs a challenge message with the author address resolved in the ENS metadata). * The url the name resolves to through ENS can change without the user knowing and then a different application/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. * Homoglyph attacks are not a bigger problem for `app keys` than it is for ENS since it will not grant access to `app keys` from the real domain (they would be derived along a different path). However homoglyph applications may lure the user to send funds from her main account to an `app key` of a malicious homoglyphic domain. Other metadata resolution through ENS that can be used alongside: -* `author address`: already mentionned above +* `author address`: already mentioned above * `contract address`: For app keys that would be designed to interact with a given ethereum contract (for instance app keys for a given token, if one desires to do so), other metadata fields could be used such as contract addresses. * [TBD] -In relation to the SLIP13 proposal mentionned above, one could think of alternative specifications that would use some certificate for authentication similar to https. +In relation to the SLIP13 proposal mentioned above, one could think of alternative specifications that would use some certificate for authentication similar to https. ### An Account gap limit standard for application controlled hd sub-path? diff --git a/EIPS/eip-1895.md b/EIPS/eip-1895.md index 4067b3a5f84a82..5c097b75c41159 100644 --- a/EIPS/eip-1895.md +++ b/EIPS/eip-1895.md @@ -132,7 +132,7 @@ In the EVM the compressed form allows us to represents curve points with 2 uint2 ## Rationale -The curve has 80 bits of security (whereas MNT6 has 120 bits) which might not be considered enough for critical security level, (for instance transfering several billions), but enough for others. If it turns out this is not enough security for adoption, there is another option : another cycle is being used by Coda but is defined over a 753 bits sized field which might also be prohibitively low (no reference to this curve from Coda's publications found). +The curve has 80 bits of security (whereas MNT6 has 120 bits) which might not be considered enough for critical security level, (for instance transferring several billions), but enough for others. If it turns out this is not enough security for adoption, there is another option : another cycle is being used by Coda but is defined over a 753 bits sized field which might also be prohibitively low (no reference to this curve from Coda's publications found). Independently of the cycle chosen, the groups and field elements are represented with integers larger than 256 bits (even for the 80 bits of security), therefore it might be necessary to also add support for larger field size operations. diff --git a/EIPS/eip-1922.md b/EIPS/eip-1922.md index 9742dd364f9392..e0f9d76ae6150f 100644 --- a/EIPS/eip-1922.md +++ b/EIPS/eip-1922.md @@ -89,7 +89,7 @@ interface ERC165 { ⚠️ TODO: Add a specific reference to libsnark here, explaining the choice of variable names. -:warning: TODO: Explain how _C_ may not necessarilly be a satisfiable arithmetic circuit of logical statements. As current, this is a limitation to certain kinds of SNARKS. Whereas the source references also mention polynomials, and other applications. +:warning: TODO: Explain how _C_ may not necessarily be a satisfiable arithmetic circuit of logical statements. As current, this is a limitation to certain kinds of SNARKS. Whereas the source references also mention polynomials, and other applications. _C_ — A satisfiable arithmetic circuit abstraction of logical statements. diff --git a/EIPS/eip-1930.md b/EIPS/eip-1930.md index 7452c7fff0b8ca..abf1456cb9b15b 100644 --- a/EIPS/eip-1930.md +++ b/EIPS/eip-1930.md @@ -54,20 +54,20 @@ if !callCost.IsUint64() || gas < callCost.Uint64() { ### Rationale -Currenlty the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. +Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. This is an issue for contracts that require external call to only fails if they would fails with enough gas. This requirement is present in smart contract wallet and meta transaction in general, where the one executing the transaction is not the signer of the execution data. Because in such case, the contract needs to ensure the call is executed exactly as the signing user intended. But this is also true for simple use case, like checking if a contract implement an interface via EIP-165. Indeed as specified by such EIP, the ```supporstInterface``` method is bounded to use 30,000 gas so that it is theorically possible to ensure that the throw is not a result of a lack of gas. Unfortunately due to how the different CALL opcodes behave contracts can't simply rely on the gas value specified. They have to ensure by other means that there is enough gas for the call. -Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interace), and the parent call will be given up to 476 gas to continue. This would result in the caller interepreting wrongly that the callee is not implementing the interface in question. +Indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. This would result in the caller interepreting wrongly that the callee is not implementing the interface in question. While such requirement can be enforced by checking the gas left according to EIP-150 and the precise gas required before the call (see solution presented in that [bug report](https://web.solidified.io/contract/5b4769b1e6c0d80014f3ea4e/bug/5c83d86ac2dd6600116381f9) or after the call (see the native meta transaction implementation [here](https://github.com/pixowl/thesandbox-contracts/blob/623f4d4ca10644dcee145bcbd9296579a1543d3d/src/Sand/erc20/ERC20MetaTxExtension.sol#L176), it would be much better if the EVM allowed us to strictly specify how much gas is to be given to the CALL so contract implementations do not need to follow [EIP-150](http://eips.ethereum.org/EIPS/eip-150) behavior and the current gas pricing so closely. This would also allow the behaviour of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) to be changed without having to affect contract that require this strict gas behaviour. As mentioned, such strict gas behaviour is important for smart contract wallet and meta transaction in general. -The issue is actually already a problem in the wild as can be seen in the case of Gnosis safe which did not consider the behavior of EIP-150 and thus fails to check the gas properly, requiring the safe owners to add otherwise unecessary extra gas to their signed message to avoid the possibility of losing funds. See https://github.com/gnosis/safe-contracts/issues/100 +The issue is actually already a problem in the wild as can be seen in the case of Gnosis safe which did not consider the behavior of EIP-150 and thus fails to check the gas properly, requiring the safe owners to add otherwise unnecessary extra gas to their signed message to avoid the possibility of losing funds. See https://github.com/gnosis/safe-contracts/issues/100 As for EIP-165, the issue already exists in the example implementation presented in the EIP. Please see the details of the issue [here](https://github.com/ethereum/EIPs/pull/881#issuecomment-491677748) @@ -85,7 +85,7 @@ uint256 gasAvailable = gasleft() - E; require(gasAvailable - gasAvailable / 64 >= `txGas`, "not enough gas provided") to.call.gas(txGas)(data); // CALL ``` -where E is the gas required for the operation beteen the call to ```gasleft()``` and the actual call PLUS the gas cost of the call itself. +where E is the gas required for the operation between the call to ```gasleft()``` and the actual call PLUS the gas cost of the call itself. While it is possible to simply over estimate ```E``` to prevent call to be executed if not enough gas is provided to the current call it would be better to have the EVM do the precise work itself. As gas pricing continue to evolve, this is important to have a mechanism to ensure a specific amount of gas is passed to the call so such mechanism can be used without having to relies on a specific gas pricing. diff --git a/EIPS/eip-1962.md b/EIPS/eip-1962.md new file mode 100644 index 00000000000000..93a6937c8af9a9 --- /dev/null +++ b/EIPS/eip-1962.md @@ -0,0 +1,225 @@ +--- +eip: 1962 +title: EC arithmetic and pairings with runtime definitions +author: Alex Vlasov (@shamatar) +discussions-to: https://ethereum-magicians.org/t/generalised-precompile-for-elliptic-curve-arithmetics-and-pairings-working-group/3208/2 +type: Standards Track +category: Core +status: Draft +created: 2019-04-22 +requires: 1109 +--- + +# Simple summary + +This proposal is an extension and formalization of [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) with an inclusion of pairings. [EIP1109](https://eips.ethereum.org/EIPS/eip-1109) is required due to low cost of some operations compared to the `STATICCALL` opcode (more information in the corresponding section below). + +## Abstract + +This EIP proposes a new precompile to bring cryptographic functionality desired for privacy and scaling solutions. Functionality of such precompile will require the following: + +- Implementation the following operations over elliptic curves in the Weierstrass form with curve parameters such as base field, A, B coefficients defined in runtime: + - Point addition + - Multiplication of a single point over a scalar + - Multiexponentiation +- Implementation pairing operation over elliptic curves from the following "families" with parameters such as base field, extension tower structure, coefficients defined in runtime: + - BLS12 + - BN + - MNT4/6 +- Implementation pairing operation over elliptic curves found by Cocks-Pinch method. Limit k <= 8. + +Full functionality of the precompile is described below in `Specification` section. + +## Motivation + +- There is a pending proposal to implement base elliptic curve arithmetic is covered by [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) and will allow to implement various privacy-preserving protocols with a reasonable gas costs per operation. +- Pairings are an important extension for basic arithmetic and so this new precompile is proposed with the following benefits: + - Extended set of curves will be available to allow Ethereum users to choose their security parameters and required functionality. + - Generic approach of this precompile will allow Ethereum users to experiment with newly found curves of their choice and new constructions constructions without waiting for new forks. + - EC arithmetic is indeed re-implemented in this precompile, but it's strictly required. Most of the pairing-based protocols still need to perform standard EC multiplications or additions and thus such operations must be available on generic set of curves. +- Gas costs - this EIP is designed to estimate gas-cost of performed operation as early as possible during the call and base if solely on specified parameters and operation type. This is a strict requirement for any precompile to allow Ethereum nodes to efficiently reject transactions and operations as early as possible. + +Functionality of this newly proposed precompile is different from [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) in the following aspects: +- Operation on arbitrary-length modulus (up to some upper-limit) for a base field and scalar field of the curve +- Pairing operations are introduced +- Different ABI due to variable parameter length + +## Specification + +If `block.number >= XXXXX`, define a new precompile with an address `0x..` and the following functionality. + +This specification will not yet provide concrete numbers for every operation, but will first introduce interfaces and gas calculation approaches. + +In every call to the precompile the first byte specifies an operation that should be performed: +- `0x01`: Point addition +- `0x02`: Single point multiplication +- `0x03`: Multiexponentiation +- `0x04`: Pairing + +For parameter encoding there is no dense bit packing. All the parameters (sizes, scalars, field elements, etc.) are Big Endian (BE) encoded unsigned integers. + +Points are always encoded in affine coordinates as `(x, y)`. Extension field elements are always encoded as `(c0, c1, c2, ...)` where the element itself is interpreted as `c0 + c1 * u + c2 * u^2 + ...`. + +During the execution all the parameters that should be interpreted as "points" are first checked that those are "on curve", otherwise error is thrown. + +Maximum proposed field bit size is 1023 bits. + +### Binary interface for non-pairing operations + +Every operation of such kind should specify curve parameters right after the "operation" byte: +- 1 byte that encodes byte size of the modulus for a base field. Will be referred as "field element length". +- BE encoded modulus. Field modulo this parameter is referred as the "base field". +- BE encoded parameter `A` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- BE encoded parameter `B` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- 1 byte that encodes byte size of the main group on the curve (over which arithmetic should happen). Will be referred as "scalar element length". +- BE encoded size of the main group. Will be referred as "scalar field size". + +While "scalar field size" is not used anywhere in principal operations (point additions, multiplications, multiexponentiations) do not depend on it, this parameter is required to calculate a gas cost for this operation (that's not true for point addition, but interface should be kept universal). E.g. for a naive "double and add" point multiplication approach the worst case scenario is when "add" operation is performed as many times a possible, it can be estimated as if the scalar had the same bit length as a size of the main group, but consisted of only `1` in it's bit decomposition. + +#### Point addition + +After the curve parameters (from above) two points must be specified to perform an addition. Output is a point in affine coordinates. + +#### Point multiplication + +After the curve parameters (from above) one point and one scalar must be specified to perform a multiplication. Output is a point in affine coordinates. Scalar must be less than the size of the group, otherwise error is thrown. + +#### Multiexponentiation + +After the curve parameters (from above) a list of `N` pairs `(point, scalar)` must be specified to perform a multiexponentiation. Output is a point in affine coordinates. Scalars must be less than the size of the group, otherwise error is thrown. For efficiency reasons this operations should use Peppinger algorithm with huge performance benefits. + +#### Gas calculation for non-pairing operations + +For all the operations above arithmetic is performed in a field specified by modulus. Number of operations for point addition is known beforehand, so the bit length (or byte length, more likely) of the modulus clearly must be one of the parameters. Second parameter is length of the bit (or byte) length of the scalar field. Third parameter is number of `(point, scalar)` pairs for multiexponentiation. + +Let's denote field element byte length as `fe_length`, +scalar length as `scalar_length` and number of points as `N`. Concrete coefficients that are to be determined will be labeled as `C_*`. Notation `quadratic` is to indicate a function that is quadratic over it's parameter. + +Quadratic dependency over field element byte length is due to multiplication. + +Proposed formulas: +- Point addition: `C_0*quadratic(fe_length)` +- Point multiplication: `C_1 * quadratic(fe_length) * scalar_length` +- Multiexponentiation: `C_2 * N * quadratic(fe_length) * scalar_length` + +Multiexponentiation formula is different due to use of the specialized algorithm. + +### Binary interface for pairing operations + +Pairing operations have other parameters required to estimate gas costs, so common part of the interface is different from non-pairing operations + +- 1 byte that encodes byte size of the modulus for a base field. Will be referred as "field element length". +- BE encoded modulus. Field modulo this parameter is referred as the "base field". +- BE encoded parameter `A` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- BE encoded parameter `B` for a curve in the Weierstrass form. May be zero but still must take the whole field element length. Must be less than modulus, no reduction should be performed by the precompile. +- 1 byte that encodes curve "family" + - `0x01` BLS12 + - `0x02` BN + - `0x03` MNT4 + - `0x04` MNT6 + - `0x05` Cocks-Pinch (Tate pairing) + +Parameters for a pairing are encoded as a list of `N` pairs `(p1, p2)` with `p1` being point from `G1` (curve over base field) in affine coordinates, and `p2` being point from `G2` (over the extension). + +Pairing operation consists of two major contributors: +- Miller loop. This part does depend from the number of pairs `N` and has number of steps that is specific for every curve family. For example, BLS12 family is generated by a single scalar `x` (standard notation) that determines number of steps in this loop. Any such parameters must be provided in the binary interface for gas costs estimation. +- Final exponentiation. This part does not depend from the number of pairs. Length of the loop for this operation is different for different families and can either be calculated in from other parameters or specified in the interface. In any case, gas costs can be estimated upfront. + +Below there will be proposed interface for BLS12 family of curves with other interfaces being built in a similar manner. + +#### BLS12 family pairing operation interface + +- 1 byte, length of the `x` parameter. +- BE encoding of parameter `x` (unsigned). +- 1 byte, sign of parameter `x`. `0x00` is `+`, `0x01` is `-`. +- 1 byte, specifies type of the pairing. Either `0x01` or `0x02`. This type depends of the curve and does not affect the gas cost. +- structure of the extension tower: + - non-residue for Fp2 extension in BE encoding. This is just a single element in the base field and must be less than modulus. + - non-residue for Fp6 extension (that is "3 over 2"). This is an element in Fp2 and encoded using the rules from the beginning of this EIP. +- Encoding of the "A" parameter in Fp2 for the curve over the extension (Fp2). +- Encoding of the "B" parameter in Fp2 for the curve over the extension (Fp2). + +For BLS12 family `x` parameter is enough for gas costs estimation. It's Hamming weight and bit length determines complexity of the Miller loop. Final exponentiation depends of the base field size. + +Proposed gas cost formula: `C_0 * quadratic(fe_length) + N * C_1 * fe_length * Hamming_and_bit_length(x)` + +#### Pairing operation interface for other families + +Complexity for BN family is also determined by the single scalar parameter, so interface will be similar to BLS12. For MNT4/6 and Cocks-Pinch curves there would be required to specify number of steps in the Miller loop explicitly in the interface. + +### Possible simplifications + +Due to high complexity of the proposed operations in the aspects of implementation, debugging and evaluation of the factors for gas costs it may be appropriate to either limit the set of curves at the moment of acceptance to some list and then extend it. Another approach (if it's technically possible) would be to have the "whilelist" contract that can be updated without consensus changes (w/o fork). + +In the case of limited set of curve the following set is proposed as a minimal: +- BN254 curve from the current version of Ethereum +- BN curve from DIZK with 2^32 roots of unity +- BLS12-381 +- BLS12-377 from ZEXE with large number of roots of unity +- MNT4/6 cycle from the original [paper](https://eprint.iacr.org/2014/595.pdf). It's not too secure, but may give some freedom for experiments. +- MNT4/6 cycle from Coda if performance allows +- Set of CP generated curves that would allow embedding of BLS12-377 and may be some BN curve that would have large power of two divisor for both base field and scalar field modulus (example of CP curve for BLS12-377 can be found in ZEXE). + +## Rationale + +Only the largest design decisions will be covered: +- While there is no arithmetic over the scalar field (which is modulo size of the main group) of the curve, it's required for gas estimation purposes. +- One may separate interfaces for additions, multiplications and multiexponentiations and estimate gas costs differently for every operation, but it would bring confusion for users and will make it harder to use a precompile from the smart-contract. +- Multiexponentiation is a separate operation due to large cost saving +- There are no point decompressions due to impossibility to get universal gas estimation of square root operation. For a limited number of "good" cases prices would be too different, so specifying the "worst case" is expensive and inefficient, while introduction of another level if complexity into already complicated gas costs formula is not worth is. + +### This precompile and EIP 1109 + +While there is no strict requirement of EIP 1109 for functionality, here is an example why it would be desired: +- BLS12-381 curve, 381 bit modulus, 255 bit scalar field, no native arithmetic is available in EVM for this +- Point addition would take 5000ns (quite overestimated) +- Point multiplication would take roughly 150000ns +- Crude gas schedule 15 Mgas/second from ECRecover precompile +- Point addition would cost 75 gas, with `STATICCALL` adding another 700 +- Point multiplication would cost 2250 gas +- One should also add the cost of memory allocation that is at least `1 + 1 + 48 + 48 + 48 + 1 + 32 + 2*48 + 2*48 = 371 byte` that is around 12 native Ethereum "words" and will require extra 36 gas (with negligible price for memory extension) + +Based on these quite crude estimations one can see that `STATICCALL` price will dominate the total cost (in case of addition) or bring significant overhead (in case of multiplication operation) in case of calls to this precompile. + + +## Backwards Compatibility + +This change is not backwards compatible and requires hard fork to be activated. + +Functionality of the new precompile itself does not affect any existing functionality of Ethereum or EVM. + +This precompile may serve as a complete replacement of the current set of `ECADD`, `ECMUL` and pairing check precompiles (`0x06`, `0x07`, `0x08`) + +## Test Cases +Test cases are the part of the implementation with a link below. + +## Implementation +There is an ongoing implementation effort [here](https://github.com/matter-labs/eip1829). Right now: +- Non-pairing operations are implemented and tested. +- BLS12 family is completed and tested for BLS12-381 and BLS12-377 curves. +- BN family is completed and tested with BN254 curve. +- Cocks-Pinch method curve is tested for k=6 curve from ZEXE. + +## Preliminary benchmarks + +cp6 in benchmarks is a Cocks-Pinch method curve that embeds BLS12-377. Machine: Core i7, 2.9 GHz. + +Multiexponentiation benchmarks take 100 pairs `(generator, random scalar)` as input. Due to the same "base" it may be not too representative benchmark and will be updated. + +``` +test pairings::bls12::tests::bench_bls12_381_pairing ... bench: 2,348,317 ns/iter (+/- 605,340) +test pairings::cp::tests::bench_cp6_pairing ... bench: 86,328,825 ns/iter (+/- 11,802,073) +test tests::bench_addition_bn254 ... bench: 388 ns/iter (+/- 73) +test tests::bench_doubling_bn254 ... bench: 187 ns/iter (+/- 4) +test tests::bench_field_inverse ... bench: 2,478 ns/iter (+/- 167) +test tests::bench_field_mont_inverse ... bench: 2,356 ns/iter (+/- 51) +test tests::bench_multiplication_bn254 ... bench: 81,744 ns/iter (+/- 6,984) +test tests::bench_multiplication_bn254_into_affine ... bench: 81,925 ns/iter (+/- 3,323) +test tests::bench_multiplication_bn254_into_affine_wnaf ... bench: 74,716 ns/iter (+/- 4,076) +test tests::bench_naive_multiexp_bn254 ... bench: 10,659,911 ns/iter (+/- 559,790) +test tests::bench_peppinger_bn254 ... bench: 2,678,743 ns/iter (+/- 148,914) +test tests::bench_wnaf_multiexp_bn254 ... bench: 9,161,281 ns/iter (+/- 456,137) +``` + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file diff --git a/EIPS/eip-1965.md b/EIPS/eip-1965.md new file mode 100644 index 00000000000000..aad5ea94dd499a --- /dev/null +++ b/EIPS/eip-1965.md @@ -0,0 +1,63 @@ +--- +eip: 1965 +title: Method to check if a chainID is valid at a specific block Number +author: Ronan Sandford (@wighawag) +category: Core +type: Standards Track +discussions-to: https://ethereum-magicians.org/t/eip-1965-valid-chainid-for-specific-blocknumber-protect-all-forks/3181 +status: Draft +created: 2019-04-20 +requires: 155 +--- + +## Abstract +This EIP adds a precompile that returns whether a specific chainID (EIP-155 unique identifier) is valid at a specific blockNumber. ChainID are assumed to be valid up to the blockNumber at which they get replaced by a new chainID. + +## Motivation +[EIP-155](https://eips.ethereum.org/EIPS/eip-155) proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using [EIP-712](https://eips.ethereum.org/EIPS/eip-712). + +[EIP-1344](http://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced. + +[EIP-1959](https://github.com/ethereum/EIPs/pull/1959) solves the issue of EIP-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it remove some freedom to fork. We consider that all fork should be given equal oportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.** + +## Specification +Adds a new precompile which uses 2 argument : a 32 bytes value that represent the chainID to test and a 32 bytes value representing the blockNumber at which the chainID is tested. It return 0x1 if the chainID is valid at the specific blockNumber, 0x0 otherwise. Note that chainID are considered valid up to the blockNumber at which they are replaced. So they are valid for every blockNumber past their replacement. + +The operation will costs no more than `G_blockhash` + `G_verylow` to execute. This could be lower as chainID are only introduced during hardfork. + +The cost of the operation might need to be adjusted later as the number of chainID in the history of the chain grows. + +Note though that the alternative to keep track of old chainID is to implement a smart contract based caching solution as EIP-1344 proposes comes with an overall higher gas cost and exhibit issues for minority-led hardfork (see Rationale section below). As such the gas cost is simply a necessary cost for the feature. + +## Rationale + +The rationale at EIP-1959 applies here as well too : + +- An opcode is better than a caching system for past chainID, It is cheaper, safer and do not include gaps. +- Direct access to the latest chainID is dangerous since it make it easy for contract to use it as a replay protection mechanism while preventing otherwise valid old messages to be valid after a fork that change the chainID. This can have disastrous consequences on users. +- all off-chain messaged signed before a fork should be valid across all side of the fork. + +The only difference is that this current proposal propose a solution to protect hardfork led by a minority. + +To summarize there is 2 possible fork scenario : + +1) The majority decide to make an hardfork but a minority disagree with it (ETC is such example). The fork is planned for block X. If the majority is not taking any action to automate the process of assigning a different chainID for both, the minority has plenty of time to plan for a chainID upgrade to happen at that same block X. Now if they do not do it, their users will face the problem that their messages will be replayable on the majority chain (Note that this is not true the other way around as we assume the majority decided to change the chainID). As such there is no reason that they’ll leave it that way. + +2) A minority decide to create an hardfork that the majority disagree with (or simply ignore). Now, the same as above can happen but since we are talking about a minority there is a chance that the majority do not care about the minority. In that case, there would be no incentive for the majority to upgrade the chainID. This means that user of both side of the fork will have the messages meant for the majority chain replayable on the minority-chain (even if this one changed its chainID) unless extra precaution is taken. + +The solution is to add the blockNumber representing the time at which the message was signed and use it as an argument to the opcode proposed here. This way, when the minority forks with a new chainID, the previous chainID become invalid from that time onward. So new messages destinated to the majority chain can't be replayed on the minority fork. + + +## Backwards Compatibility + +EIP-712 is still in draft but would need to be updated to include the blockNumber as part of the values that wallets need to verify for the protection of their users. + +Since chainID and blockNumber will vary, they should not be part of the domain separator (meant to be generated once) but another part of the message. + +While the pair could be optional for contract that do not care about replays or have other ways to prevent them, if chainID is present, the blockNumber must be present too. And if any of them is present, wallet need to ensure that the chainID is indeed the latest one of the chain being used, while the blockNumber is the latest one at the point of signing. During fork transition, the wallet can use the blockNumber to know which chainID to use. + +## References +This was previously suggested as part of [EIP1959 discussion](https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170). + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file diff --git a/EIPS/eip-1973.md b/EIPS/eip-1973.md index ed108da14eb20f..64c7a9cf15cb61 100644 --- a/EIPS/eip-1973.md +++ b/EIPS/eip-1973.md @@ -29,7 +29,7 @@ A pull system is required to keep the application completely decentralized and t `token amount per participant in the ecosytem or TPP (token per participant)`: TPP = (token amount to mint / total active participants) - `roundMask`: the cummulative snapshot of TPP over time for the token contract. E.g. transactionOne = 10 tokens are minted with 100 available participants (TPP = 10 / 100) , transactionTwo = 12 tokens are minted with 95 participants (TPP = 12 / 95 ) + `roundMask`: the cumulative snapshot of TPP over time for the token contract. E.g. transactionOne = 10 tokens are minted with 100 available participants (TPP = 10 / 100) , transactionTwo = 12 tokens are minted with 95 participants (TPP = 12 / 95 ) roundMask = (10/100) + (12/95) @@ -39,7 +39,7 @@ A pull system is required to keep the application completely decentralized and t `rewards for msg.sender`: roundMask - participantMask - E.g. Let's assume a total of 6 transactions (smart contract triggers or functions calls) are in place with 10 exising participants (denominator) and 20 tokens (numerator) are minted per transaction. At 2nd transaction, the 11th participant joins the network and exits before 5th transaction, the 11th participant's balance is as follows: + E.g. Let's assume a total of 6 transactions (smart contract triggers or functions calls) are in place with 10 existing participants (denominator) and 20 tokens (numerator) are minted per transaction. At 2nd transaction, the 11th participant joins the network and exits before 5th transaction, the 11th participant's balance is as follows: ``` t1 roundMask = (20/10) @@ -52,7 +52,7 @@ A pull system is required to keep the application completely decentralized and t Total tokens released in 6 transactions = 60 tokens - As the participant joins at t2 and leaves before t5, the participant deserves the rewards between t2 and t4. When the participant joins at t2, the 'participantMask = (20/10)', when the participant leaves before t5, the cummulative deserved reward tokens are : + As the participant joins at t2 and leaves before t5, the participant deserves the rewards between t2 and t4. When the participant joins at t2, the 'participantMask = (20/10)', when the participant leaves before t5, the cumulative deserved reward tokens are : rewards for msg.sender: `[t4 roundMask = (20/10) + (20/11)+ (20/11) + (20/11)] - [participantMask = (20/10)] = [rewards = (20/11)+ (20/11) + (20/11)]` @@ -89,7 +89,7 @@ address public tokencontractAddress = address(this); mapping(address => uint256) public participantMask; /** - * @dev constructor, initilizes variables. + * @dev constructor, initializes variables. * @param _tokensPerBlock The amount of token that will be released per block, entered in wei format (E.g. 1000000000000000000) * @param _blockFreezeInterval The amount of blocks that need to pass (E.g. 1, 10, 100) before more tokens are brought into the ecosystem. */ diff --git a/EIPS/eip-2028.md b/EIPS/eip-2028.md index e5fbb8a28af0c2..65d535b9e36288 100644 --- a/EIPS/eip-2028.md +++ b/EIPS/eip-2028.md @@ -1,7 +1,7 @@ --- eip: 2028 title: Calldata gas cost reduction -author: Alexey Akhunov(@AlexeyAkhunov), Eli Ben Sasson (eli@starkware.co), Tom Brand (tom@starkware.co), Avihu Levy (avihu@starkware.co) +author: Alexey Akhunov (@AlexeyAkhunov), Eli Ben Sasson , Tom Brand , Avihu Levy discussions-to: https://ethereum-magicians.org/t/eip-2028-calldata-gas-cost-reduction/3280 status: Draft type: Standards Track diff --git a/EIPS/eip-210.md b/EIPS/eip-210.md index 859991c1f026d8..abba50af202e53 100644 --- a/EIPS/eip-210.md +++ b/EIPS/eip-210.md @@ -83,4 +83,4 @@ The EVM bytecode that the contract code should be set to is: ### Rationale -This removes the need for implementaitons to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols. +This removes the need for implementations to have an explicit way to look into historical block hashes, simplifying the protocol definition and removing a large component of the "implied state" (information that is technically state but is not part of the state tree) and thereby making the protocol more "pure". Additionally, it allows blocks to directly point to blocks far behind them, which enables extremely efficient and secure light client protocols. diff --git a/EIPS/eip-3.md b/EIPS/eip-3.md index 63378516635401..621b143554d6b0 100644 --- a/EIPS/eip-3.md +++ b/EIPS/eip-3.md @@ -16,11 +16,11 @@ This is a proposal to add a new opcode, `CALLDEPTH`. The `CALLDEPTH` opcode woul 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. -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 successfull, the consequences could be damaging. +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. Example: -1. Contract `A` want's to be invoked regularly, and pays Ether to the invoker in every block. +1. Contract `A` wants to be invoked regularly, and pays Ether to the invoker in every block. 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. 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. diff --git a/EIPS/eip-5.md b/EIPS/eip-5.md index dfde87b3f110b0..bb47fbe6d93009 100644 --- a/EIPS/eip-5.md +++ b/EIPS/eip-5.md @@ -108,7 +108,7 @@ The change in semantics affects existing contracts in two ways: all be written in a way, though, such that objects in memory are _relocatable_, i.e. their absolute position in memory and their relative position to other objects does not matter. This is of course not the case for arrays, but they - are allocated in a single allocation and not with an intermidiate `CALL`. + are allocated in a single allocation and not with an intermediate `CALL`. ### Implementation diff --git a/EIPS/eip-615.md b/EIPS/eip-615.md index b584498d8a0250..d9d2b203f3ec7d 100644 --- a/EIPS/eip-615.md +++ b/EIPS/eip-615.md @@ -390,7 +390,7 @@ Note that code like this is already run by EVMs to check dynamic jumps, includin #### Subroutine Validation -This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertexes and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is `O(|E|+|V|)`: The sum of the number of edges and number of verticies in the graph. +This function can be seen as a symbolic execution of a subroutine in the EVM code, where only the effect of the instructions on the state being validated is computed. Thus the structure of this function is very similar to an EVM interpreter. This function can also be seen as an acyclic traversal of the directed graph formed by taking instructions as vertices and sequential and branching connections as edges, checking conditions along the way. The traversal is accomplished via recursion, and cycles are broken by returning when a vertex which has already been visited is reached. The time complexity of this traversal is `O(|E|+|V|)`: The sum of the number of edges and number of vertices in the graph. The basic approach is to call `validate_subroutine(i, 0, 0)`, for `i` equal to the first instruction in the EVM code through each `BEGINDATA` offset. `validate_subroutine()` traverses instructions sequentially, recursing when `JUMP` and `JUMPI` instructions are encountered. When a destination is reached that has been visited before it returns, thus breaking cycles. It returns true if the subroutine is valid, false otherwise. diff --git a/EIPS/eip-627.md b/EIPS/eip-627.md index 0fe174eaf75840..00f0133baa569e 100644 --- a/EIPS/eip-627.md +++ b/EIPS/eip-627.md @@ -66,7 +66,7 @@ This packet is used for sending the standard Whisper envelopes. This packet contains two objects: integer message code (0x02) followed by a single floating point value of PoW. This value is the IEEE 754 binary representation of 64-bit floating point number. Values of qNAN, sNAN, INF and -INF are not allowed. Negative values are also not allowed. -This packet is used by Whisper nodes for dynamic adjustment of their individual PoW requirements. Receipient of this message should no longer deliver the sender messages with PoW lower than specified in this message. +This packet is used by Whisper nodes for dynamic adjustment of their individual PoW requirements. Recipient of this message should no longer deliver the sender messages with PoW lower than specified in this message. PoW is defined as average number of iterations, required to find the current BestBit (the number of leading zero bits in the hash), divided by message size and TTL: @@ -165,7 +165,7 @@ Symmetric encryption uses AES GCM algorithm with random 96-bit nonce. Packet codes 0x00 and 0x01 are already used in all Whisper versions. -Packet code 0x02 will be necessary for the future developement of Whisper. It will provide possiblitity to adjust the PoW requirement in real time. It is better to allow the network to govern itself, rather than hardcode any specific value for minimal PoW requirement. +Packet code 0x02 will be necessary for the future development of Whisper. It will provide possiblitity to adjust the PoW requirement in real time. It is better to allow the network to govern itself, rather than hardcode any specific value for minimal PoW requirement. Packet code 0x03 will be necessary for scalability of the network. In case of too much traffic, the nodes will be able to request and receive only the messages they are interested in. diff --git a/EIPS/eip-706.md b/EIPS/eip-706.md index e1f601250f0ea9..4211c23b75a42c 100644 --- a/EIPS/eip-706.md +++ b/EIPS/eip-706.md @@ -16,7 +16,7 @@ This EIP proposes a tiny extension to the DEVp2p protocol to enable [Snappy comp ## Motivation Synchronizing the Ethereum main network (block 4,248,000) in Geth using fast sync currently consumes 1.01GB upload and 33.59GB download bandwidth. On the Rinkeby test network (block 852,000) it's 55.89MB upload and 2.51GB download. -However, most of this data (blocks, transactions) are heavily compressable. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network. +However, most of this data (blocks, transactions) are heavily compressible. By enabling compression at the message payload level, we can reduce the previous numbers to 1.01GB upload / 13.46GB download on the main network, and 46.21MB upload / 463.65MB download on the test network. The motivation behind doing this at the DEVp2p level (opposed to eth for example) is that it would enable compression for all sub-protocols (eth, les, bzz) seamlessly, reducing any complexity those protocols might incur in trying to individually optimize for data traffic. @@ -46,7 +46,7 @@ Important caveats: ### Avoiding DOS attacks -Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindy decompress messages, since they may get significantly larger than 16MB. +Currently a DEVp2p message length is limited to 24 bits, amounting to a maximum size of 16MB. With the introduction of Snappy compression, care must be taken not to blindly decompress messages, since they may get significantly larger than 16MB. However, Snappy is capable of calculating the decompressed size of an input message without inflating it in memory (*[the stream starts with the uncompressed length up to a maximum of `2^32 - 1` stored as a little-endian varint](https://github.com/google/snappy/blob/master/format_description.txt#L20)*). This can be used to discard any messages which decompress above some threshold. **The proposal is to use the same limit (16MB) as the threshold for decompressed messages.** This retains the same guarantees that the current DEVp2p protocol does, so there won't be surprises in application level protocols. diff --git a/EIPS/eip-712.md b/EIPS/eip-712.md index f7e8f893fc12f6..14fa4c37ad8e8c 100644 --- a/EIPS/eip-712.md +++ b/EIPS/eip-712.md @@ -157,7 +157,7 @@ If the struct type references other struct types (and these in turn reference ev ### Definition of `encodeData` -The encoding of a struct instance is `enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ)`, i.e. the concatenation of the encoded member values in the order that they apear in the type. Each encoded member value is exactly 32-byte long. +The encoding of a struct instance is `enc(value₁) ‖ enc(value₂) ‖ … ‖ enc(valueₙ)`, i.e. the concatenation of the encoded member values in the order that they appear in the type. Each encoded member value is exactly 32-byte long. The atomic values are encoded as follows: Boolean `false` and `true` are encoded as `uint256` values `0` and `1` respectively. Addresses are encoded as `uint160`. Integer values are sign-extended to 256-bit and encoded in big endian order. `bytes1` to `bytes31` are arrays with a beginning (index `0`) and an end (index `length - 1`), they are zero-padded at the end to `bytes32` and encoded in beginning to end order. This corresponds to their encoding in ABI v1 and v2. @@ -205,7 +205,7 @@ By adding a prefix to the message makes the calculated signature recognisable as 1. `Address` - 20 Bytes - Address of the account that will sign the messages. 2. `TypedData` - Typed structured data to be signed. -Typed data is a JSON object containing type information, domain seprator parameters and the message object. Below is the [json-schema][jsons] definition for `TypedData` param. +Typed data is a JSON object containing type information, domain separator parameters and the message object. Below is the [json-schema][jsons] definition for `TypedData` param. [jsons]: https://json-schema.org/ diff --git a/EIPS/eip-725.md b/EIPS/eip-725.md index c69731a5b90b48..8688e9cc86975f 100644 --- a/EIPS/eip-725.md +++ b/EIPS/eip-725.md @@ -19,7 +19,7 @@ The following describes standard functions for a unique identifiable proxy accou ## Motivation Standardizing a minimal interface for an proxy account allows third parties to interact with various proxy accounts contracts in a consistent manner. -the benefit is a persistent account that is independed from single keys and can attach an arbitrary amount of information to verifiy, or enhance the accounts purpose. +the benefit is a persistent account that is independent from single keys and can attach an arbitrary amount of information to verifiy, or enhance the accounts purpose. ## Specification diff --git a/EIPS/eip-758.md b/EIPS/eip-758.md index 8d7df949ce8902..89a5bffa1be28d 100644 --- a/EIPS/eip-758.md +++ b/EIPS/eip-758.md @@ -46,7 +46,7 @@ Or to be notified of any transactions submitted by this rpc client when they com filter = {} ``` -After the request is recieved, the Ethereum node responds with a subscription ID: +After the request is received, the Ethereum node responds with a subscription ID: ```json {"jsonrpc": "2.0", "id": 1, "result": "0x00000000000000000000000000000b0b"} @@ -106,7 +106,7 @@ The node responds with an array of transaction hashes and their corresponding re } ``` -All transactions that were sealed _after_ the initial `eth_newCompletedTransactionFilter` request are included in this array. Again, if the `filter` param is a non-empty dictinary (contains either `from`, `to`, or `hasReturnData`) then only transactions matching the filter criteria generate notifications. Note that in the polling case, there is no way for the Ethereum node to be sure that an RPC client which submits a transaction was the same as the one who created the filter, so there is no restriction based on where the transaction was submitted. +All transactions that were sealed _after_ the initial `eth_newCompletedTransactionFilter` request are included in this array. Again, if the `filter` param is a non-empty dictionary (contains either `from`, `to`, or `hasReturnData`) then only transactions matching the filter criteria generate notifications. Note that in the polling case, there is no way for the Ethereum node to be sure that an RPC client which submits a transaction was the same as the one who created the filter, so there is no restriction based on where the transaction was submitted. ## Rationale diff --git a/EIPS/eip-823.md b/EIPS/eip-823.md index 727af0cf04e4f9..f9eb4149be1638 100644 --- a/EIPS/eip-823.md +++ b/EIPS/eip-823.md @@ -184,7 +184,7 @@ This event logs any new exchange that have taken place and have been spent immed event ExchangeAndSpent ( address _from, address _by, uint _value ,address _target ,address _to) ``` -### Diagramatic Explaination +### Diagramatic Explanation #### Exchanging Tokens ![token-exchange-standard-visual-representation-1](https://raw.githubusercontent.com/kashishkhullar/EIPs/master/assets/eip-823/eip-823-token-exchange-standard-visual-representation-1.PNG) diff --git a/EIPS/eip-918.md b/EIPS/eip-918.md index 1dc296e56d3ddf..10047046b5e4bb 100644 --- a/EIPS/eip-918.md +++ b/EIPS/eip-918.md @@ -66,7 +66,7 @@ bytes32 public adjustmentInterval; ``` #### challengeNumber -The current challenge number. It is expected tha a new challenge number is generated after a new reward is minted. +The current challenge number. It is expected that a new challenge number is generated after a new reward is minted. ``` solidity bytes32 public challengeNumber; @@ -145,7 +145,7 @@ contract AbstractERC918 is EIP918Interface { epochCount = _epoch(); - //every so often, readjust difficulty. Dont readjust when deploying + //every so often, readjust difficulty. Don't readjust when deploying if(epochCount % blocksPerReadjustment == 0){ _adjustDifficulty(); } @@ -273,7 +273,7 @@ contract ERC918Merged is AbstractERC918 { } /* - * @notice Externally facing merge function kept for backwards compatability with previous definition + * @notice Externally facing merge function kept for backwards compatibility with previous definition * * @param _nonce the solution nonce * @param _challenge_digest the keccak256 encoded challenge number + message sender + solution nonce @@ -442,7 +442,7 @@ Earlier versions of this standard incorporated a redundant 'challenge_digest' pa contract ERC918BackwardsCompatible is AbstractERC918 { /* - * @notice Externally facing mint function kept for backwards compatability with previous mint() definition + * @notice Externally facing mint function kept for backwards compatibility with previous mint() definition * @param _nonce the solution nonce * @param _challenge_digest the keccak256 encoded challenge number + message sender + solution nonce **/ diff --git a/EIPS/eip-998.md b/EIPS/eip-998.md index 88f0b9205245f4..bc87b8b1fb20a1 100644 --- a/EIPS/eip-998.md +++ b/EIPS/eip-998.md @@ -856,7 +856,7 @@ interface ERC998ERC721BottomUp { /// @return rootOwner The root owner at the top of tree of tokens and ERC998 magic value. function rootOwnerOf(uint256 _tokenId) external view returns (bytes32 rootOwner); - /// @notice Get the owner addess and parent token (if there is one) of a token + /// @notice Get the owner address and parent token (if there is one) of a token /// @param _tokenId The tokenId to query. /// @return tokenOwner The owner address of the token /// @return parentTokenId The parent owner of the token and ERC998 magic value @@ -947,7 +947,7 @@ Here is an example of a value returned by `rootOwnerOf`. #### tokenOwnerOf ```solidity -/// @notice Get the owner addess and parent token (if there is one) of a token +/// @notice Get the owner address and parent token (if there is one) of a token /// @param _tokenId The tokenId to query. /// @return tokenOwner The owner address of the token and ERC998 magic value. /// @return parentTokenId The parent owner of the token diff --git a/README.md b/README.md index 03278d567ae9d0..3d0d63066ec1b2 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ When you believe your EIP is mature and ready to progress past the draft phase, * **Draft** - an EIP that is undergoing rapid iteration and changes. * **Last Call** - an EIP that is done with its initial iteration and ready for review by a wide audience. -* **Accepted** - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP wil move to final. +* **Accepted** - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP will move to final. * **Final (non-Core)** - an EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. * **Final (Core)** - an EIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork. * **Deferred** - an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork. diff --git a/assets/eip-1057/test-vectors.md b/assets/eip-1057/test-vectors.md index 991e2509acb496..5fcec000ab513d 100644 --- a/assets/eip-1057/test-vectors.md +++ b/assets/eip-1057/test-vectors.md @@ -1,6 +1,6 @@ # Test Vectors for EIP-1057 - ProgPow -Many of these vectors are dervived from [chfast/ethash](https://github.com/chfast/ethash) +Many of these vectors are derived from [chfast/ethash](https://github.com/chfast/ethash) ## fnv1a @@ -121,7 +121,7 @@ Kiss 99 state: For the first loop iteration of block 30,000 the seed to use for `fill_mix` would be `0xEE304846DDD0A47B`. A two dimensional `mix` array should be created -passing the rows into `fill_mix` witht he column number as the loop argument. +passing the rows into `fill_mix` with the column number as the loop argument. The state of the mix array after the call to `progPowLoop` for block 30,000, loop 1 are as follows. diff --git a/index.html b/index.html index c79bd888d21d07..507775cb35acf7 100644 --- a/index.html +++ b/index.html @@ -16,7 +16,7 @@

EIP status terms

  • Draft - an EIP that is open for consideration and is undergoing rapid iteration and changes.
  • Last Call - an EIP that is done with its initial iteration and ready for review by a wide audience.
    • -
  • Accepted - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP wil move to final.
    • +
  • Accepted - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP will move to final.
  • Final (non-Core) - an EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
  • Final (Core) - an EIP that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork.
  • Deferred an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.