mirror of https://github.com/status-im/EIPs.git
Run spelling checks on CI (#2040)
This commit is contained in:
Alex Beregszaszi
Nick Savers
parent
433a6ce998
commit
af982f1470
|
|
@ -0,0 +1,7 @@
|
|||
uint
|
||||
ith
|
||||
mitre
|
||||
readded
|
||||
crate
|
||||
developper
|
||||
ist
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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?
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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 256<sup>4</sup> (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 256<sup>4</sup> (4.3 billion) permutations.
|
||||
|
||||
### Multiple Returns
|
||||
|
||||
|
|
|
|||
|
|
@ -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 matchign the request>,
|
||||
id:<id matching the request>,
|
||||
result:<rpc result as is>,
|
||||
error:<error object>
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ By standardizing on a known minimal bytecode redirect implementation, this stand
|
|||
|
||||
## Motivation
|
||||
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
|
||||
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
|
||||
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
{
|
||||
|
|
|
|||
|
|
@ -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**
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ A standard interface for Human Capital Accounting tokens.
|
|||
|
||||
## Abstract
|
||||
<!--A short (~200 word) description of the technical issue being addressed.-->
|
||||
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
|
||||
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
|
||||
|
|
@ -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 */
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
|
||||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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(
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
|
||||
|
|
@ -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?
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
**/
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ title: Home
|
|||
<ul>
|
||||
<li><strong>Draft</strong> - an EIP that is open for consideration and is undergoing rapid iteration and changes.</li>
|
||||
<li><strong>Last Call</strong> - an EIP that is done with its initial iteration and ready for review by a wide audience.</li>
|
||||
<li><strong>Accepted</strong> - 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. </li>
|
||||
<li><strong>Accepted</strong> - 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. </li>
|
||||
<li><strong>Final (non-Core)</strong> - 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.</li>
|
||||
<li><strong>Final (Core)</strong> - 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.</li>
|
||||
<li><strong>Deferred</strong> an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.</li>
|
||||
|
|
|
|||
Loading…
Reference in New Issue