mirror of https://github.com/status-im/EIPs.git
Update HTTP->HTTPS when both URLs work (#1714)
This commit is contained in:
William Entriken
Nick Savers
parent
5d81cc0062
commit
035a021168
|
|
@ -56,7 +56,7 @@ Each status change is requested by the EIP author and reviewed by the EIP editor
|
|||
* **Draft** -- Once the first draft has been merged, you may submit follow-up pull requests with further changes to your draft until such point as you believe the EIP to be mature and ready to proceed to the next status. An EIP in draft status must be implemented to be considered for promotion to the next status (ignore this requirement for core EIPs).
|
||||
* :arrow_right: Last Call -- If agreeable, the EIP editor will assign Last Call status and set a review end date (`review-period-end`), normally 14 days later.
|
||||
* :x: Last Call -- A request for Last Call status will be denied if material changes are still expected to be made to the draft. We hope that EIPs only enter Last Call once, so as to avoid unnecessary noise on the RSS feed.
|
||||
* **Last Call** -- This EIP will listed prominently on the http://eips.ethereum.org/ website (subscribe via RSS at [last-call.xml](/last-call.xml)).
|
||||
* **Last Call** -- This EIP will listed prominently on the https://eips.ethereum.org/ website (subscribe via RSS at [last-call.xml](/last-call.xml)).
|
||||
* :x: -- A Last Call which results in material changes or substantial unaddressed technical complaints will cause the EIP to revert to Draft.
|
||||
* :arrow_right: Accepted (Core EIPs only) -- A successful Last Call without material changes or unaddressed technical complaints will become Accepted.
|
||||
* :arrow_right: Final (Not core EIPs) -- A successful Last Call without material changes or unaddressed technical complaints will become Final.
|
||||
|
|
@ -235,7 +235,7 @@ December 7, 2015: EIP 1 has been improved and will be placed as a PR.
|
|||
|
||||
February 1, 2016: EIP 1 has added editors, made draft improvements to process, and has merged with Master stream.
|
||||
|
||||
March 21, 2018: Minor edits to accommodate the new automatically-generated EIP directory on [eips.ethereum.org](http://eips.ethereum.org/).
|
||||
March 21, 2018: Minor edits to accommodate the new automatically-generated EIP directory on [eips.ethereum.org](https://eips.ethereum.org/).
|
||||
|
||||
May 29, 2018: A last call process was added.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,16 +28,16 @@ Moving to PoS has been on the roadmap since day 0 for ethereum, along with a red
|
|||
|
||||
#### Asics and advantadges of PoW
|
||||
|
||||
[EIP 960](http://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
|
||||
[EIP 960](https://eips.ethereum.org/EIPS/eip-969) proposes a change in algorithm to avoid mining being dominated by ASICS. Counter arguments by Phil Daian argue among others than [resisting economies of scale is futile and there might be specific security advantadges to specialized hardware](https://pdaian.com/blog/anti-asic-forks-considered-harmful/). One of the main arguments for PoW mining, even when it doesn't provide security, it is useful as a fair distribution mechanism, that **PoW allows any person with a computer, internet access and electricity to obtain currency without having to deal with government imposed currency controls**.
|
||||
|
||||
#### Recovery Forks
|
||||
|
||||
After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](http://eips.ethereum.org/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers.
|
||||
After the Parity Multisig library self destruction, three different strategies have been attempted to recover the funds: [a general protocol improvement to allow reviving self destructed contracts](https://gist.github.com/5chdn/a9bb8617cc8523a030126a3d1c60baf3) (which was considered dangerous), a [general process to recover funds](https://github.com/ethereum/EIPs/pull/867) and a [specific recovery of the multisig library](https://eips.ethereum.org/EIPS/eip-999). The latter two are finding a lot of resistance from the community, but it's unlikely that these issues are going away soon. The affected parties have a large incentive (fluctuating at almost half a billion dollars) to keep trying, and it's an issue that is likely to occur again in the future. If they get reimbursed, [there are many other special cases of ether provably burnt or stuck](https://github.com/ethereum/EIPs/issues/156) that might deserve the same treatment. If they get shut down, they have an incentive to move forward a fork implementation: even if they are a minority chain, it's likely they'll recover an amount larger than 0, which is what they would otherwise, and it means the main ethereum community might lose a valuable team of developers.
|
||||
|
||||
|
||||
#### Other Public Goods
|
||||
|
||||
There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](http://eips.ethereum.org/EIPS/eip-908), fair distribution of tokens etc.
|
||||
There are many other types of public goods that could be funded by issuance. By *Public Good*, I'm using a strict definition of something that brings value to everyone, both those who funded it and free-loaders, making it hard to fund it exclusively by traditional private incentives. They can be research, whole network security, [incentivize full clients and networking](https://eips.ethereum.org/EIPS/eip-908), fair distribution of tokens etc.
|
||||
|
||||
## Proposed Solution
|
||||
### Issuance Contract
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ At time of writing, other than stepping through EVM execution and inspecting mem
|
|||
|
||||
Having a fixed set of codes also makes it possible to write common helper functions to react in common ways to certain signals. This can live off- or on-chain library, lowering the overhead in building smart contracts, and helping raise code quality with trusted shared components.
|
||||
|
||||
We also see a desire for this [in transactions](http://eips.ethereum.org/EIPS/eip-658), and there's no reason that these status codes couldn't be used by the EVM itself.
|
||||
We also see a desire for this [in transactions](https://eips.ethereum.org/EIPS/eip-658), and there's no reason that these status codes couldn't be used by the EVM itself.
|
||||
|
||||
### Smart Contract Autonomy
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ contracts.
|
|||
> **Note**
|
||||
>
|
||||
> A [hosted
|
||||
> version](http://ethpm.github.io/ethpm-spec) of this
|
||||
> version](https://ethpm.github.io/ethpm-spec) of this
|
||||
> specification is available via GitHub Pages. This EIP and the hosted
|
||||
> HTML document were both autogenerated from the same documentation
|
||||
> source.
|
||||
|
|
@ -174,7 +174,7 @@ name collisions with future versions of the specification.
|
|||
<tbody>
|
||||
<tr class="odd">
|
||||
<td><p>See Also</p></td>
|
||||
<td><p>Formalized (<a href="http://json-schema.org">JSON-Schema</a>) version of this specification: <a href="https://github.com/ethpm/ethpm-spec/tree/v2.0.0/spec/package.spec.json">package.spec.json</a></p></td>
|
||||
<td><p>Formalized (<a href="https://json-schema.org">JSON-Schema</a>) version of this specification: <a href="https://github.com/ethpm/ethpm-spec/tree/v2.0.0/spec/package.spec.json">package.spec.json</a></p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td><p>Jump To</p></td>
|
||||
|
|
@ -286,7 +286,7 @@ be included in all Packages.
|
|||
|
||||
The `version` field declares the version number of this release. This
|
||||
value **must** be included in all Packages. This value **should**
|
||||
conform to the [semver](http://semver.org/) version
|
||||
conform to the [semver](https://semver.org/) version
|
||||
numbering specification.
|
||||
|
||||
<table>
|
||||
|
|
@ -1404,7 +1404,7 @@ The `name` field defines which compiler was used in compilation.
|
|||
The `version` field defines the version of the compiler. The field
|
||||
**should** be OS agnostic (OS not included in the string) and take the
|
||||
form of either the stable version in
|
||||
[semver](http://semver.org/) format or if built on a
|
||||
[semver](https://semver.org/) format or if built on a
|
||||
nightly should be denoted in the form of `<semver>-<commit-hash>` ex:
|
||||
`0.4.8-commit.60cc1668`.
|
||||
|
||||
|
|
@ -1435,7 +1435,7 @@ nightly should be denoted in the form of `<semver>-<commit-hash>` ex:
|
|||
The `settings` field defines any settings or configuration that was used
|
||||
in compilation. For the `"solc"` compiler, this **should** conform to
|
||||
the [Compiler Input and Output
|
||||
Description](http://solidity.readthedocs.io/en/latest/using-the-compiler.html#compiler-input-and-output-json-description).
|
||||
Description](https://solidity.readthedocs.io/en/latest/using-the-compiler.html#compiler-input-and-output-json-description).
|
||||
|
||||
<table>
|
||||
<colgroup>
|
||||
|
|
@ -1848,7 +1848,7 @@ a supporting implementation.
|
|||
|
||||
- [Truffle](http://trufflesuite.com/)
|
||||
|
||||
- [Populus](http://populus.readthedocs.io/en/latest/)
|
||||
- [Populus](https://populus.readthedocs.io/en/latest/)
|
||||
|
||||
- [Embark](https://embark.status.im/)
|
||||
|
||||
|
|
|
|||
|
|
@ -486,7 +486,7 @@ balanceOf(baseToken + index, msg.sender); // Get balance of the Non-Fungible tok
|
|||
- [ERC-721 Non-Fungible Token Standard](https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-721.md)
|
||||
- [ERC-165 Standard Interface Detection](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md)
|
||||
- [ERC-1538 Transparent Contract Standard](https://github.com/ethereum/EIPs/issues/1538)
|
||||
- [JSON Schema](http://json-schema.org/)
|
||||
- [JSON Schema](https://json-schema.org/)
|
||||
- [RFC 2119 Key words for use in RFCs to Indicate Requirement Levels](https://www.ietf.org/rfc/rfc2119.txt)
|
||||
|
||||
**Implementations**
|
||||
|
|
|
|||
|
|
@ -365,7 +365,7 @@ Membership Verification Token ERC1261 -- a reference implementation
|
|||
1. ERC-165 Standard Interface Detection. https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md
|
||||
1. ERC-725/735 Claim Registry https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md
|
||||
1. ERC-173 Owned Standard. https://github.com/ethereum/EIPs/issues/173
|
||||
1. JSON Schema. http://json-schema.org/
|
||||
1. JSON Schema. https://json-schema.org/
|
||||
1. Multiaddr. https://github.com/multiformats/multiaddr
|
||||
1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt
|
||||
|
||||
|
|
|
|||
|
|
@ -70,10 +70,10 @@ Because the `namehash` procedure depends only on the name itself, this can be pr
|
|||
ENS names must conform to the following syntax:
|
||||
|
||||
<pre><domain> ::= <label> | <domain> "." <label>
|
||||
<label> ::= any valid string label per [UTS46](http://unicode.org/reports/tr46/)
|
||||
<label> ::= any valid string label per [UTS46](https://unicode.org/reports/tr46/)
|
||||
</pre>
|
||||
|
||||
In short, names consist of a series of dot-separated labels. Each label must be a valid normalised label as described in [UTS46](http://unicode.org/reports/tr46/) with the options `transitional=false` and `useSTD3AsciiRules=true`. For Javascript implementations, a [library](https://www.npmjs.com/package/idna-uts46) is available that normalises and checks names.
|
||||
In short, names consist of a series of dot-separated labels. Each label must be a valid normalised label as described in [UTS46](https://unicode.org/reports/tr46/) with the options `transitional=false` and `useSTD3AsciiRules=true`. For Javascript implementations, a [library](https://www.npmjs.com/package/idna-uts46) is available that normalises and checks names.
|
||||
|
||||
Note that while upper and lower case letters are allowed in names, the UTS46 normalisation process case-folds labels before hashing them, so two names with different case but identical spelling will produce the same namehash.
|
||||
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ function textFor(bytes32 _code) external view returns (bool _wasFound, string _t
|
|||
|
||||
### String Format
|
||||
|
||||
All strings MUST be encoded as [UTF-8](http://www.ietf.org/rfc/rfc3629.txt).
|
||||
All strings MUST be encoded as [UTF-8](https://www.ietf.org/rfc/rfc3629.txt).
|
||||
|
||||
```solidity
|
||||
"Špeĉiäl chârãçtérs are permitted"
|
||||
|
|
@ -117,7 +117,7 @@ All strings MUST be encoded as [UTF-8](http://www.ietf.org/rfc/rfc3629.txt).
|
|||
|
||||
### Templates
|
||||
|
||||
Template strings are allowed, and MUST follow the [ANSI C `printf`](http://pubs.opengroup.org/onlinepubs/009696799/utilities/printf.html) conventions.
|
||||
Template strings are allowed, and MUST follow the [ANSI C `printf`](https://pubs.opengroup.org/onlinepubs/009696799/utilities/printf.html) conventions.
|
||||
|
||||
```solidity
|
||||
"Satoshi's true identity is %s"
|
||||
|
|
@ -155,7 +155,7 @@ A very viable alternative is to store text off chain, with a pointer to the tran
|
|||
|
||||
UTF-8 is the most widely used encoding at time of writing. It contains a direct embedding of ASCII, while providing characters for most natural languages, emoji, and special characters.
|
||||
|
||||
Please see the [UTF-8 Everywhere Manifesto](http://utf8everywhere.org/) for more information.
|
||||
Please see the [UTF-8 Everywhere Manifesto](https://utf8everywhere.org/) for more information.
|
||||
|
||||
### When No Text is Found
|
||||
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ Glossary of terms used in the processes below:
|
|||
* `Sender` - an external address with a valid keypair but no ETH to pay for gas.
|
||||
* `Relay` - a node holding ETH in an external address, listed in RelayHub and relaying transactions from Senders to RelayHub for a fee.
|
||||
|
||||
|
||||
|
||||
|
||||
The process of registering/refreshing a `Relay`:
|
||||
|
||||
|
|
|
|||
|
|
@ -226,7 +226,7 @@ A slower release allows for extra time to identify, and address any issues which
|
|||
|
||||
Choosing a single TLD helps to maximize network effects by focusing on one namespace.
|
||||
|
||||
A three letter TLD is a pattern made familiar by it's common usage in internet domain names. This familiarity significantly increases the potential of the ENS to be integrated into pre-existing DNS systems, and reserved as a [special-use domain name](http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain). A recent precedent for this is the [reservation of the `.onion` domain](https://tools.ietf.org/html/rfc7686).
|
||||
A three letter TLD is a pattern made familiar by it's common usage in internet domain names. This familiarity significantly increases the potential of the ENS to be integrated into pre-existing DNS systems, and reserved as a [special-use domain name](https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain). A recent precedent for this is the [reservation of the `.onion` domain](https://tools.ietf.org/html/rfc7686).
|
||||
|
||||
### Holding ether as collateral
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ For some "standard interfaces" like [the ERC-20 token interface](https://github.
|
|||
|
||||
### How Interfaces are Identified
|
||||
|
||||
For this standard, an *interface* is a set of [function selectors as defined by the Ethereum ABI](http://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector). This a subset of [Solidity's concept of interfaces](http://solidity.readthedocs.io/en/develop/abi-spec.html) and the `interface` keyword definition which also defines return types, mutability and events.
|
||||
For this standard, an *interface* is a set of [function selectors as defined by the Ethereum ABI](https://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector). This a subset of [Solidity's concept of interfaces](https://solidity.readthedocs.io/en/develop/abi-spec.html) and the `interface` keyword definition which also defines return types, mutability and events.
|
||||
|
||||
We define the interface identifier as the XOR of all function selectors in the interface. This code example shows how to calculate an interface identifier:
|
||||
|
||||
|
|
|
|||
|
|
@ -88,9 +88,9 @@ Allows for packages which exclude source code or other elements which would be n
|
|||
|
||||
Support for ERC190 is either implemented or in progress for the following:
|
||||
|
||||
* [Truffle](http://truffleframework.com/)
|
||||
* [Populus](http://populus.readthedocs.io/en/latest/)
|
||||
* [Dapple](http://dapple.readthedocs.io/en/master/)
|
||||
* [Truffle](https://truffleframework.com/)
|
||||
* [Populus](https://populus.readthedocs.io/en/latest/)
|
||||
* [Dapple](https://dapple.readthedocs.io/en/master/)
|
||||
* [Eris PM](https://github.com/eris-ltd/eris-cli)
|
||||
* [Embark](https://github.com/iurimatias/embark-framework)
|
||||
* [Browser Solidity](https://github.com/ethereum/remix-ide/issues/386)
|
||||
|
|
|
|||
|
|
@ -16,12 +16,12 @@ A proposal to provide Single Instruction Multiple Data types and operations for
|
|||
|
||||
Most all modern CPUs include SIMD hardware that operates on wide registers of data, applying a Single Instruction to Multiple Data lanes in parallel, where lanes divide a register into a vector of scalar elements of equal size. This model is an excellent fit for the wide stack items of the EVM, offering substantial performance boosts for operations that can be expressed as parallel operations on vectors of scalars. For some examples, a brief literature search finds SIMD speedups of
|
||||
* up to 7X for [SHA-512](http://keccak.noekeon.org/sw_performance.html)
|
||||
* 4X for [elliptic curve scalar multiplication](http://link.springer.com/chapter/10.1007/3-540-45439-X_16)
|
||||
* 3X to 4X for [BLAKE2b](http://github.com/minio/blake2b-simd)
|
||||
* 4X for [elliptic curve scalar multiplication](https://link.springer.com/chapter/10.1007/3-540-45439-X_16)
|
||||
* 3X to 4X for [BLAKE2b](https://github.com/minio/blake2b-simd)
|
||||
* up to 3X for [OpenSSL](https://software.intel.com/en-us/articles/improving-openssl-performance)
|
||||
* 2X to 3X for [elliptic curve modular multiplication](http://ieee-hpec.org/2013/index_htm_files/24-Simd-acceleration-Pabbuleti-2886999.pdf)
|
||||
* 1.7X to 1.9X for [SHA-256](https://github.com/minio/sha256-simd)
|
||||
* 1.3X for [RSA encryption](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.738.1218&rep=rep1&type=pdf)
|
||||
* 1.3X for [RSA encryption](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.738.1218&rep=rep1&type=pdf)
|
||||
|
||||
## SPECIFICATION
|
||||
|
||||
|
|
@ -118,7 +118,7 @@ For most modern languages (including Rust, Python, Go, Java, and C++) compilers
|
|||
|
||||
One motivation for these operations, besides taking full advantage of the hardware, is assigning lower gas costs for operations on smaller scalars.
|
||||
|
||||
On a machine with 64-bit registers the standard algorithms from Knuth's [Art of Computer Programming](http://library.aceondo.net/ebooks/Computer_Science/algorithm-the_art_of_computer_programming-knuth.pdf) require 32-bit digits, using the upper half of a register for overflows, so for 256-bit values N=8 digits are needed, and for 64-bit values N=2 digits are needed. The cycle counts for these algorithms are:
|
||||
On a machine with 64-bit registers the standard algorithms from Knuth's [Art of Computer Programming](https://library.aceondo.net/ebooks/Computer_Science/algorithm-the_art_of_computer_programming-knuth.pdf) require 32-bit digits, using the upper half of a register for overflows, so for 256-bit values N=8 digits are needed, and for 64-bit values N=2 digits are needed. The cycle counts for these algorithms are:
|
||||
|
||||
operation | cycles | N = 2 | N = 4 | N = 8
|
||||
-|-|-|-|-
|
||||
|
|
|
|||
|
|
@ -130,8 +130,8 @@ Implementations of this proposal are here:
|
|||
* Test vectors for Ed25519: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-6
|
||||
* NaCl regression tests: https://ed25519.cr.yp.to/python/sign.py and https://ed25519.cr.yp.to/python/sign.input
|
||||
* On the recoverability of public keys from signature+message (alone): https://crypto.stackexchange.com/questions/9936/what-signature-schemes-allow-recovering-the-public-key-from-a-signature
|
||||
* Bernstein, D., "Curve25519: new Diffie-Hellman speed records", DOI 10.1007/11745853_14, February 2006, http://cr.yp.to/ecdh.html
|
||||
* Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", June 2015, http://eprint.iacr.org/2015/625>
|
||||
* Bernstein, D., "Curve25519: new Diffie-Hellman speed records", DOI 10.1007/11745853_14, February 2006, https://cr.yp.to/ecdh.html
|
||||
* Hamburg, M., "Ed448-Goldilocks, a new elliptic curve", June 2015, https://eprint.iacr.org/2015/625>
|
||||
* RFC8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC (https://tools.ietf.org/html/rfc8080)
|
||||
|
||||
## Copyright
|
||||
|
|
|
|||
|
|
@ -207,7 +207,7 @@ By adding a prefix to the message makes the calculated signature recognisable as
|
|||
|
||||
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.
|
||||
|
||||
[jsons]: http://json-schema.org/
|
||||
[jsons]: https://json-schema.org/
|
||||
|
||||
```JavaScript
|
||||
{
|
||||
|
|
@ -274,7 +274,7 @@ There also should be a corresponding `personal_signTypedData` method which accep
|
|||
|
||||
Two methods are added to [Web 3 version 1][web3-1] that parallel the `web3.eth.sign` and `web3.eth.personal.sign` methods.
|
||||
|
||||
[web3-1]: http://web3js.readthedocs.io/en/1.0/index.html
|
||||
[web3-1]: https://web3js.readthedocs.io/en/1.0/index.html
|
||||
|
||||
#### web3.eth.signTypedData
|
||||
|
||||
|
|
|
|||
|
|
@ -398,7 +398,7 @@ XXXXERC721, by William Entriken -- a scalable example implementation
|
|||
1. ERC-827 Token Standard. https://eips.ethereum.org/EIPS/eip-827
|
||||
1. Ethereum Name Service (ENS). https://ens.domains
|
||||
1. Instagram -- What's the Image Resolution? https://help.instagram.com/1631821640426723
|
||||
1. JSON Schema. http://json-schema.org/
|
||||
1. JSON Schema. https://json-schema.org/
|
||||
1. Multiaddr. https://github.com/multiformats/multiaddr
|
||||
1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt
|
||||
|
||||
|
|
@ -412,7 +412,7 @@ XXXXERC721, by William Entriken -- a scalable example implementation
|
|||
1. Solidity Issue \#3544 -- Cannot Calculate Selector of Function Named `transfer`. https://github.com/ethereum/solidity/issues/3544
|
||||
1. CryptoKitties Bounty Issue \#4 -- Listing all Kitties Owned by a User is `O(n^2)`. https://github.com/axiomzen/cryptokitties-bounty/issues/4
|
||||
1. OpenZeppelin Issue \#438 -- Implementation of `approve` method violates ERC20 standard. https://github.com/OpenZeppelin/zeppelin-solidity/issues/438
|
||||
1. Solidity DelegateCallReturnValue Bug. http://solidity.readthedocs.io/en/develop/bugs.html#DelegateCallReturnValue
|
||||
1. Solidity DelegateCallReturnValue Bug. https://solidity.readthedocs.io/en/develop/bugs.html#DelegateCallReturnValue
|
||||
|
||||
**Discussions**
|
||||
|
||||
|
|
|
|||
|
|
@ -294,9 +294,9 @@ contract ERC725 {
|
|||
|
||||
- [Slides of the ERC Identity presentation](https://www.slideshare.net/FabianVogelsteller/erc-725-identity)
|
||||
- [In-contract claim VS claim registry](https://github.com/ethereum/wiki/wiki/ERC-735:-Claim-Holder-Registry-vs.-in-contract)
|
||||
- [Identity related reports](http://www.weboftrust.info/specs.html)
|
||||
- [Identity related reports](https://www.weboftrust.info/specs.html)
|
||||
- [W3C Verifiable Claims Use Cases](https://w3c.github.io/vc-use-cases/)
|
||||
- [Decentralised Identity Foundation](http://identity.foundation)
|
||||
- [Decentralised Identity Foundation](https://identity.foundation)
|
||||
- [Sovrin Foundation Self Sovereign Identity](https://sovrin.org/wp-content/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf)
|
||||
|
||||
## Copyright
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ The proposed changes address forward compatibility by applying Postel's Law (als
|
|||
the Robustness Principle) throughout the protocol stack. The merit and applicability of
|
||||
this approach has been studied repeatedly since its original application in RFC 761. For a
|
||||
recent perspective, see
|
||||
["The Robustness Principle Reconsidered" (Eric Allman, 2011)](http://queue.acm.org/detail.cfm?id=1999945).
|
||||
["The Robustness Principle Reconsidered" (Eric Allman, 2011)](https://queue.acm.org/detail.cfm?id=1999945).
|
||||
|
||||
#### Changes to the devp2p Wire Protocol
|
||||
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -10,7 +10,7 @@ created: 2018-02-14
|
|||
|
||||
# Delaware General Corporations Law (DGCL) compatible share token
|
||||
|
||||
Ref: [proposing-an-eip-for-DGCL-tokens](http://forum.ethereum.org/discussion/17200/proposing-an-eip-for-regulation-a-Tokens)
|
||||
Ref: [proposing-an-eip-for-DGCL-tokens](https://forum.ethereum.org/discussion/17200/proposing-an-eip-for-regulation-a-Tokens)
|
||||
|
||||
## Simple Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The tragedy of the commons is a phenomenon that is well known in many sectors, m
|
|||
Reward mechanisms that are external to being built in to the protocol are beyond the scope of this EIP. Such extra-protocol reward methods include state channel payments for extra services such as light client servers providing faster information such as receipts; state channel payments for buying state reads from full nodes; archival services (which is only applicable to future proposed versions of Ethereum with stateless clients); and tokens for the client and running full nodes.
|
||||
|
||||
## Motivation
|
||||
Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake with [Casper FFG](http://eips.ethereum.org/EIPS/eip-1011), then full PoS with [CBC Casper](https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.pdf).
|
||||
Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake with [Casper FFG](https://eips.ethereum.org/EIPS/eip-1011), then full PoS with [CBC Casper](https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.pdf).
|
||||
|
||||
Additionally, providing a reward for clients gives a revenue stream that is independent of state channels or other layer 2 mechanisms, which are less secure, although this insecurity can be offset by mechanisms such as insurance, bonded payments and time locks. Rationalising that investors may invest in a client because it is an enabler for the Ethereum ecosystem (and thus opening up investment opportunities) may not scale very well, and it seems that it is more sustainable to monetize the client as part of the service(s) that it provides.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ Implementing this as a layer 2 solution may not ensure the sustainability of the
|
|||
|
||||
Not providing incentives for clients is an issue now as there is less incentive to build a client that aligns with the needs of users, funds need to be raised externally to the protocol to fund client development, which is not as decentralized. If only a smaller subset is able to fund client development, such as VCs, angel investors and institutional investors, that may not align well with the interests of all current and potential stakeholders of Ethereum (which includes future stakeholders). Ostensibly, one of the goals of Ethereum is to decentralize everything, including wealth, or in other words, to improve wealth equality. Not providing incentives for full nodes validating transactions may not seem like as much of an issue now, but not doing so could hinder the growth of the protocol. Of course, incentives aren't enough, it also needs to be technically decentralized so that it is ideally possible for a low-end mainstream computer or perhaps even a mobile or embedded IoT device to be a verifying full node, or at least to be able to help with securing the network if it is deemed impractical for them to be a full node.
|
||||
|
||||
Note that with a supply cap (as in [EIP 960](https://github.com/ethereum/EIPs/issues/960), the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per [EIP 1015](http://eips.ethereum.org/EIPS/eip-1015), an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders.
|
||||
Note that with a supply cap (as in [EIP 960](https://github.com/ethereum/EIPs/issues/960), the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per [EIP 1015](https://eips.ethereum.org/EIPS/eip-1015), an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders.
|
||||
|
||||
## Specification
|
||||
Add a new field to each block called `PrevBlockVerifications`, which is an arbitrary, unlimited size byte array. When a client verifies that a previous block is [valid](https://ethereum.github.io/yellowpaper/paper.pdf#subsubsection.4.3.2), the client appends a user agent to PrevBlockVerifications via an opcode in a transaction, PREV_BLOCK_VERIF. The user agent is a vector with the immutable fields: the blockhash of the block that is validated, and the index of a client address in an access list (details are below). A miner validates a transaction before including it in a block, however they are not able to change these fields of the vector because they're immutable.
|
||||
|
|
@ -55,9 +55,9 @@ A miner could create a client and fill their block with transactions that only c
|
|||
|
||||
### More details on the access list
|
||||
|
||||
The access list prevents anyone inserting any address to the first element of the vector, where there may be a way to prevent censorship and centralization of authority of who decides to register new addresses in the list, e.g. on-chain governance with signalling (possibly similar to [EIP 1015](http://eips.ethereum.org/EIPS/eip-1015), which also specifies an alternative way of sending funds) or a layer 2 proof of authority network where new addresses can be added via a smart contract. Note that there may be serious drawbacks to implementing either of these listed examples. There is a refutation of [on-chain governance](https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca) as well as of [plutocracy](https://vitalik.ca/general/2018/03/28/plutocracy.html). [Proof of Authority](https://en.wikipedia.org/wiki/Proof-of-authority) isn't suitable for a public network since it doesn't distribute trust well. However, using signalling in layer 2 contracts is more acceptable, but Vlad Zamfir argues that using that to influence outcomes in the protocol can disenfranchise miners from being necessary participants in the governance process. Thus, in light of these counterpoints, having an access list may not be suitable until a decentralized, trustless way of maintaining it is implemented and ideally accepted by the majority of a random sample that represents the population of Ethereum users.
|
||||
The access list prevents anyone inserting any address to the first element of the vector, where there may be a way to prevent censorship and centralization of authority of who decides to register new addresses in the list, e.g. on-chain governance with signalling (possibly similar to [EIP 1015](https://eips.ethereum.org/EIPS/eip-1015), which also specifies an alternative way of sending funds) or a layer 2 proof of authority network where new addresses can be added via a smart contract. Note that there may be serious drawbacks to implementing either of these listed examples. There is a refutation of [on-chain governance](https://medium.com/@Vlad_Zamfir/against-on-chain-governance-a4ceacd040ca) as well as of [plutocracy](https://vitalik.ca/general/2018/03/28/plutocracy.html). [Proof of Authority](https://en.wikipedia.org/wiki/Proof-of-authority) isn't suitable for a public network since it doesn't distribute trust well. However, using signalling in layer 2 contracts is more acceptable, but Vlad Zamfir argues that using that to influence outcomes in the protocol can disenfranchise miners from being necessary participants in the governance process. Thus, in light of these counterpoints, having an access list may not be suitable until a decentralized, trustless way of maintaining it is implemented and ideally accepted by the majority of a random sample that represents the population of Ethereum users.
|
||||
|
||||
However, another alternative to managing the access list would be to have decentralized verification that the address produced from querying an index in the access list does correspond to that of a "legitimate" client. Part of this verification would involve checking that there is a client that claims that this address is owned by them, that they are happy to receive funds in this manner and agree or arranged to putting the address in the access list, and that the client passes all tests in the [Ethereum test suite](https://github.com/ethereum/tests). However, this last proviso would then preclude new clients being funded from the start of development, although such would-be clients would not be able to receive funds in-protocol until they implement the client anyway (as an aside, they could raise funds in various ways—a DAII, pronounced die-yee, is recommended, while a platform for DAIIs is under development by [Dogezer](http://dogezer.com/)). All of this could be done off-chain, and if anyone found that some address in the access list was not legitimate, then they could challenge that address with a proof of illegitimacy, and the participant that submitted the address to the access list could be slashed (while they must hold a deposit in order to register and keep an address in the access list).
|
||||
However, another alternative to managing the access list would be to have decentralized verification that the address produced from querying an index in the access list does correspond to that of a "legitimate" client. Part of this verification would involve checking that there is a client that claims that this address is owned by them, that they are happy to receive funds in this manner and agree or arranged to putting the address in the access list, and that the client passes all tests in the [Ethereum test suite](https://github.com/ethereum/tests). However, this last proviso would then preclude new clients being funded from the start of development, although such would-be clients would not be able to receive funds in-protocol until they implement the client anyway (as an aside, they could raise funds in various ways—a DAII, pronounced die-yee, is recommended, while a platform for DAIIs is under development by [Dogezer](https://dogezer.com/)). All of this could be done off-chain, and if anyone found that some address in the access list was not legitimate, then they could challenge that address with a proof of illegitimacy, and the participant that submitted the address to the access list could be slashed (while they must hold a deposit in order to register and keep an address in the access list).
|
||||
|
||||
Additionally, it should help with being only able to read the client's address from the client, and the whole transaction could revert if the address is not in the access list. You could provide the index of the address in the access list, and then you could `assert` that the address found at that index matches that which can be read by the client (where the latter would be a read-only address).
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ An analysis can be done regarding the dispersion of these constants as compared
|
|||
`0x01000193`, using the following snippet.
|
||||
|
||||
``` c
|
||||
// http://eips.ethereum.org/EIPS/eip-969
|
||||
// https://eips.ethereum.org/EIPS/eip-969
|
||||
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# EIPs [](https://gitter.im/ethereum/EIPs?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
|
||||
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.
|
||||
|
||||
A browsable version of all current and draft EIPs can be found on [the official EIP site](http://eips.ethereum.org/).
|
||||
A browsable version of all current and draft EIPs can be found on [the official EIP site](https://eips.ethereum.org/).
|
||||
|
||||
# Contributing
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ layout: default
|
|||
<div class="home">
|
||||
<h1 class="page-heading">
|
||||
EIP {{ page.eip | xml_escape }}: {{ page.title | xml_escape }}
|
||||
<a href="{{site.github.repository_url}}/blob/master/{{page.path}}"><svg role="img" aria-label="Source" xmlns="http://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><title>Source</title><path fill-rule="evenodd" d="M9.5 3L8 4.5 11.5 8 8 11.5 9.5 13 14 8 9.5 3zm-5 0L0 8l4.5 5L6 11.5 2.5 8 6 4.5 4.5 3z"/></svg></a>
|
||||
<a href="{{site.github.repository_url}}/blob/master/{{page.path}}"><svg role="img" aria-label="Source" xmlns="https://www.w3.org/2000/svg" width="14" height="16" viewBox="0 0 14 16"><title>Source</title><path fill-rule="evenodd" d="M9.5 3L8 4.5 11.5 8 8 11.5 9.5 13 14 8 9.5 3zm-5 0L0 8l4.5 5L6 11.5 2.5 8 6 4.5 4.5 3z"/></svg></a>
|
||||
</h1>
|
||||
<table>
|
||||
<tr><th>Author</th><td>{% include authorlist.html authors=page.author %}</td></tr>
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
| Variable | Symbol | Value | Unit | Source |
|
||||
| -------------------|--------------|---------------|---------------|--------|
|
||||
| Network Hashrate |H<sub>N</sub> | 296000 | GH/s | https://etherscan.io/chart/hashrate |
|
||||
| GPU Hashrate |H<sub>M</sub> | 31.2 | MH/s | http://www.legitreviews.com/geforce-gtx-1070-ethereum-mining-small-tweaks-great-hashrate-low-power_195451 |
|
||||
| GPU Hashrate |H<sub>M</sub> | 31.2 | MH/s | https://www.legitreviews.com/geforce-gtx-1070-ethereum-mining-small-tweaks-great-hashrate-low-power_195451 |
|
||||
| GPU Power |P<sub>M</sub> | 110.6 | W | https://www.reddit.com/r/ethereum/comments/7vewys/10000_tons_co2_per_day_and_climbing_eip_858/dtrswyz/ |
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue