diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index a57413acfc177..b959f8139d09b 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -23,10 +23,10 @@ For Ethereum implementers, EIPs are a convenient way to track the progress of th There are three types of EIP: - A **Standards Track EIP** describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories. Standards Track EIPs consist of three parts, a design document, implementation, and finally if warranted an update to the [formal specification]. - - **Core** - improvements requiring a consensus fork (e.g. [EIP-5], [EIP-101]), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of [EIP-86]). - - **Networking** - includes improvements around [devp2p] ([EIP-8]) and [Light Ethereum Subprotocol], as well as proposed improvements to network protocol specifications of [whisper] and [swarm]. - - **Interface** - includes improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names ([EIP-6]) and [contract ABIs]. The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository. - - **ERC** - application-level standards and conventions, including contract standards such as token standards ([ERC20]), name registries ([ERC26], [ERC137]), URI schemes ([ERC67]), library/package formats ([EIP-82]), and wallet formats ([EIP-75], [EIP-85]). + - **Core** - improvements requiring a consensus fork (e.g. [EIP-5](./eip-5.md), [EIP-101](./eip-101.md)), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, the miner/node strategy changes 2, 3, and 4 of [EIP-86](./eip-86.md)). + - **Networking** - includes improvements around [devp2p] ([EIP-8](./eip-8.md)) and [Light Ethereum Subprotocol], as well as proposed improvements to network protocol specifications of [whisper] and [swarm]. + - **Interface** - includes improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names ([EIP-6](./eip-6.md)) and [contract ABIs]. The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository. + - **ERC** - application-level standards and conventions, including contract standards such as token standards ([EIP-20](./eip-20.md)), and registries ([EIP-137](./eip-137.md)). - A **Meta EIP** describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP. - An **Informational EIP** describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice. @@ -212,6 +212,10 @@ EIPs may have a `requires` header, indicating the EIP numbers that this EIP depe EIPs may also have a `superseded-by` header indicating that an EIP has been rendered obsolete by a later document; the value is the number of the EIP that replaces the current document. The newer EIP must have a `replaces` header containing the number of the EIP that it rendered obsolete. +## Linking to other EIPs + +References to other EIPs should follow the format `EIP-N` where `N` is the EIP number you are referring to. Each EIP that is referenced in an EIP **MUST** be accompanied by a relative markdown link the first time it is referenced, and **MAY** be accompaniede by a link on subsequent references. The link **MUST** always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main EIPs site, mirrors of the main EIP site, etc. For example, you would link to this EIP with `[EIP-1](./eip-1.md)`. + ## Auxiliary Files Images, diagrams and auxiliary files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-N` (where **N** is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as `../assets/eip-1/image.png`. @@ -294,26 +298,13 @@ See [the revision history for further details](https://github.com/ethereum/EIPs/ ### Bibliography -[EIP-5]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5.md -[EIP-101]: https://github.com/ethereum/EIPs/issues/28 -[EIP-90]: https://github.com/ethereum/EIPs/issues/90 -[EIP-86]: https://github.com/ethereum/EIPs/issues/86#issue-145324865 [devp2p]: https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol -[EIP-8]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8.md [Light Ethereum Subprotocol]: https://github.com/ethereum/wiki/wiki/Light-client-protocol [whisper]: https://github.com/ethereum/go-ethereum/wiki/Whisper-Overview [swarm]: https://github.com/ethereum/go-ethereum/pull/2959 [API/RPC]: https://github.com/ethereum/wiki/wiki/JSON-RPC -[EIP-6]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6.md [contract ABIs]: https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI [interfaces repo]: https://github.com/ethereum/interfaces -[ERC-20]: https://github.com/ethereum/EIPs/issues/20 -[ERC-26]: https://github.com/ethereum/EIPs/issues/26 -[ERC-137]: https://github.com/ethereum/EIPs/issues/137 -[ERC-67]: https://github.com/ethereum/EIPs/issues/67 -[EIP-82]: https://github.com/ethereum/EIPs/issues/82 -[EIP-75]: https://github.com/ethereum/EIPs/issues/75 -[EIP-85]: https://github.com/ethereum/EIPs/issues/85 [the Ethereum subreddit]: https://www.reddit.com/r/ethereum/ [one of the Ethereum Gitter chat rooms]: https://gitter.im/ethereum/ [pull request]: https://github.com/ethereum/EIPs/pulls diff --git a/EIPS/eip-1013.md b/EIPS/eip-1013.md index e4cf68a98a753..fa42b602d68da 100644 --- a/EIPS/eip-1013.md +++ b/EIPS/eip-1013.md @@ -22,11 +22,11 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Cons - `Block >= 9_200_000` on the Kovan testnet - `Block >= 3_660_663` on the Rinkeby testnet - Included EIPs: - - [EIP 145](https://eips.ethereum.org/EIPS/eip-145): Bitwise shifting instructions in EVM - - [EIP 1014](https://eips.ethereum.org/EIPS/eip-1014): Skinny CREATE2 - - [EIP 1052](https://eips.ethereum.org/EIPS/eip-1052): EXTCODEHASH Opcode - - [EIP 1234](https://eips.ethereum.org/EIPS/eip-1234): Delay difficulty bomb, adjust block reward - - [EIP 1283](https://eips.ethereum.org/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps + - [EIP 145](./eip-145.md): Bitwise shifting instructions in EVM + - [EIP 1014](./eip-1014.md): Skinny CREATE2 + - [EIP 1052](./eip-1052.md): EXTCODEHASH Opcode + - [EIP 1234](./eip-1234.md): Delay difficulty bomb, adjust block reward + - [EIP 1283](./eip-1283.md): Net gas metering for SSTORE without dirty maps ## References diff --git a/EIPS/eip-1014.md b/EIPS/eip-1014.md index 37e2501e8c08b..79296b85704bc 100644 --- a/EIPS/eip-1014.md +++ b/EIPS/eip-1014.md @@ -48,7 +48,7 @@ This EIP makes collisions possible. The behaviour at collisions is specified by Specifically, if `nonce` or `code` is nonzero, then the create-operation fails. -With [EIP 161](https://eips.ethereum.org/EIPS/eip-161) +With [EIP 161](./eip-161.md) > Account creation transactions and the `CREATE` operation SHALL, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one diff --git a/EIPS/eip-1015.md b/EIPS/eip-1015.md index b884e84a962ea..13bc56d8bd9e5 100644 --- a/EIPS/eip-1015.md +++ b/EIPS/eip-1015.md @@ -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](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**. +[EIP 960](./eip-969.md) 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](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. +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](./eip-999.md). 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](https://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](./eip-908.md), fair distribution of tokens etc. ## Proposed Solution ### Issuance Contract diff --git a/EIPS/eip-1052.md b/EIPS/eip-1052.md index 77692c77bced5..6dc6015e16a40 100644 --- a/EIPS/eip-1052.md +++ b/EIPS/eip-1052.md @@ -25,7 +25,7 @@ takes one argument from the stack, zeros the first 96 bits and pushes to the stack the keccak256 hash of the code of the account at the address being the remaining 160 bits. -In case the account does not exist or is empty (as defined by [EIP-161](https://eips.ethereum.org/EIPS/eip-161)) `0` is pushed to the stack. +In case the account does not exist or is empty (as defined by [EIP-161](./eip-161.md)) `0` is pushed to the stack. In case the account does not have code the keccak256 hash of empty data (i.e. `c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`) diff --git a/EIPS/eip-1056.md b/EIPS/eip-1056.md index 2ed52193e506b..b7eea3563d180 100644 --- a/EIPS/eip-1056.md +++ b/EIPS/eip-1056.md @@ -19,7 +19,7 @@ This ERC describes a standard for creating and updating identities with a limite ## Motivation -As we have been developing identity systems for the last couple of years at uPort it has become apparent that the cost of identity creation is a large issue. The previous Identity proposal [ERC725](https://eips.ethereum.org/EIPS/eip-725) faces this exact issue. Our requirements when creating this ERC is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the identity. The identity system should be fit to use off-chain as well as on-chain. +As we have been developing identity systems for the last couple of years at uPort it has become apparent that the cost of identity creation is a large issue. The previous Identity proposal [ERC725](./eip-725.md) faces this exact issue. Our requirements when creating this ERC is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). However it must also be possible to rotate keys without changing the primary identifier of the identity. The identity system should be fit to use off-chain as well as on-chain. ## Definitions diff --git a/EIPS/eip-1066.md b/EIPS/eip-1066.md index 6560b608a9c1e..3287d0c7c49b8 100644 --- a/EIPS/eip-1066.md +++ b/EIPS/eip-1066.md @@ -33,7 +33,7 @@ Status codes convey a much richer set of information [than Booleans](https://exi _End users get little to no feedback, and there is no translation layer._ -Since ERC1066 status codes are finite and known in advance, we can leverage [ERC1444](https://eips.ethereum.org/EIPS/eip-1444) to provide global, human-readable sets of status messages. These may also be translated into any language, differing levels of technical detail, added as `revert` messages, natspecs, and so on. +Since ERC1066 status codes are finite and known in advance, we can leverage [ERC1444](./eip-1444.md) to provide global, human-readable sets of status messages. These may also be translated into any language, differing levels of technical detail, added as `revert` messages, natspecs, and so on. Status codes convey a much richer set of information than Booleans, and are able to be reacted to autonomously unlike arbitrary strings. @@ -45,7 +45,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](https://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](./eip-658.md), and there's no reason that these status codes couldn't be used by the EVM itself. ### Smart Contract Autonomy diff --git a/EIPS/eip-1077.md b/EIPS/eip-1077.md index a420703a57759..754e6b3acdd7d 100644 --- a/EIPS/eip-1077.md +++ b/EIPS/eip-1077.md @@ -15,11 +15,11 @@ requires: 20, 191, 1271, 1344 A standard interface for gas abstraction in top of smart contracts. -Allows users to offer [EIP-20] token for paying the gas used in a call. +Allows users to offer [EIP-20](./eip-20.md) token for paying the gas used in a call. ## Abstract -A main barrier for adoption of DApps is the requirement of multiple tokens for executing in chain actions. Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them can circumvent this problem, while ETH will always be required for ethereum transactions, it's possible for smart contract to take [EIP-191] signatures and forward a payment incentive to an untrusted party with ETH for executing the transaction. +A main barrier for adoption of DApps is the requirement of multiple tokens for executing in chain actions. Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them can circumvent this problem, while ETH will always be required for ethereum transactions, it's possible for smart contract to take [EIP-191](./eip-191.md) signatures and forward a payment incentive to an untrusted party with ETH for executing the transaction. ## Motivation @@ -48,7 +48,7 @@ function executeGasRelayMsg(uint256 _nonce, bytes memory _execData, uint256 _gas #### executeGasRelayERC191Msg -Returns the [EIP-191] of `executeGasRelayMsg` used for signing messages and for verifying the execution. +Returns the [EIP-191](./eip-191.md) of `executeGasRelayMsg` used for signing messages and for verifying the execution. ```solidity function executeGasRelayERC191Msg(uint256 _nonce, bytes memory _execData, uint256 _gasPrice, uint256 _gasLimit, address _gasToken, address _gasRelayer) public view returns (bytes memory); @@ -75,17 +75,17 @@ The signed message require the following fields: #### Signing the message -The message **MUST** be signed as [EIP-191] standard, and the called contract **MUST** also implement [EIP-1271] which must validate the signed messages. +The message **MUST** be signed as [EIP-191](./eip-191.md) standard, and the called contract **MUST** also implement [EIP-1271](./eip-1271.md) which must validate the signed messages. -Messages **MUST** be signed by the owner of the account contract executing. If the owner is a contract, it must implement [EIP-1271] interface and forward validation to it. +Messages **MUST** be signed by the owner of the account contract executing. If the owner is a contract, it must implement [EIP-1271](./eip-1271.md) interface and forward validation to it. In order to be compliant, the transaction **MUST** request to sign a "messageHash" that is a concatenation of multiple fields. The fields **MUST** be constructed as this method: -The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive reward. +The first and second fields are to make it [EIP-191](./eip-191.md) compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191](./eip-191.md). The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344](./eip-1344.md), execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive reward. -The [EIP-191] message must be constructed as following: +The [EIP-191](./eip-191.md) message must be constructed as following: ```solidity keccak256( abi.encodePacked( @@ -128,7 +128,7 @@ Using signed messages, specially combined with an account contract that holds fu More than one signed transaction with the same parameter can be executed by this function at the same time, by passing all signatures in the `messageSignatures` field. That field will split the signature in multiple 72 character individual signatures and evaluate each one. This is used for cases in which one action might require the approval of multiple parties, in a single transaction. -If multiple signatures are required, then all signatures should then be *ordered by account* and the account contract should implement signatures checks locally (`JUMP`) on [EIP-1271] interface which might forward (`STATIC_CALL`) the [EIP-1271] signature check to owner contract. +If multiple signatures are required, then all signatures should then be *ordered by account* and the account contract should implement signatures checks locally (`JUMP`) on [EIP-1271](./eip-1271.md) interface which might forward (`STATIC_CALL`) the [EIP-1271](./eip-1271.md) signature check to owner contract. ### Keep track of nonces: @@ -222,8 +222,3 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ## References * [Universal Logins talk at UX Unconf, Toronto](https://www.youtube.com/watch?v=qF2lhJzngto) - -[EIP-20]: https://eips.ethereum.org/EIPS/eip-20 -[EIP-191]: https://eips.ethereum.org/EIPS/eip-191 -[EIP-1271]: https://eips.ethereum.org/EIPS/eip-1271 -[EIP-1344]: https://eips.ethereum.org/EIPS/eip-1344 diff --git a/EIPS/eip-1078.md b/EIPS/eip-1078.md index 320c8376c6d08..9c40dd8132136 100644 --- a/EIPS/eip-1078.md +++ b/EIPS/eip-1078.md @@ -64,7 +64,7 @@ Once the desired level is known, the app must take these steps: 3. **Generate the bytecode** for a transaction calling the function `addKey(PUBLICKEY,LEVEL)`. 4. **Broadcast a transaction request on a whisper channel** or some other decentralized network of peers. Details on this step require further discussions 1. **If web3 is available** then attempt calling web3.eth.sendTransaction. This can be automatic or prompted by user action. -1. **Attempt calling a URI** if the app supports [URL format for transaction requests EIP](https://eips.ethereum.org/EIPS/eip-681) then attempt calling this. This can be automatic or prompted by user action. +1. **Attempt calling a URI** if the app supports [URL format for transaction requests EIP](./eip-681.md) then attempt calling this. This can be automatic or prompted by user action. 1. **Show a QR code**: with an EIP681 formatted URL. That QR code can be clickable to attempt to retry the other options, but it should be done last: if step 1 works, the user should receive a notification on their compatible device and won't need to use the QR code. Here's an example of a EIP681 compatible address to add a public key generated locally in the app: diff --git a/EIPS/eip-1108.md b/EIPS/eip-1108.md index 661097a724455..d66016824eee2 100644 --- a/EIPS/eip-1108.md +++ b/EIPS/eip-1108.md @@ -73,9 +73,9 @@ components because of the structure of the algorithm. Thus using a 'fair' price of 25.86 gas per microsecond, we get a gas formula of ~`35,000 * k + 45,000` gas, where `k` is the number of pairings being computed. [4] -[1]- Per [EIP-196](https://github.com/ethereum/EIPs/blob/984cf5de90bbf5fbe7e49be227b0c2f9567e661e/EIPS/eip-196.md#gas-costs). +[1]- Per [EIP-196](./eip-196.md#gas-costs). -[2]- Per [EIP-197](https://github.com/ethereum/EIPs/blob/df132cd37efb3986f9cd3ef4922b15a767d2c54a/EIPS/eip-197.md#specification). +[2]- Per [EIP-197](./eip-197.md#specification). [3]- [Parity benchmarks.](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53) @@ -115,7 +115,7 @@ If zk-SNARK verification costs are decreased, these solutions can be deployed fo ### Parity and Geth already have fast algorithms that justify reduced gas costs -This EIP does not require Parity or Geth to deploy new cryptographic libraries, as fast bn128 algorithms have already been integrated into these clients. This goal of proposing this EIP for Istanbul, is to supplement [EIP-1829](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1829.md) (arithmetic over generic elliptic curves), providing an immediate solution to the pressing problem of expensive cryptography, while more advanced solutions are developed, defined and deployed. +This EIP does not require Parity or Geth to deploy new cryptographic libraries, as fast bn128 algorithms have already been integrated into these clients. This goal of proposing this EIP for Istanbul, is to supplement [EIP-1829](./eip-1829.md) (arithmetic over generic elliptic curves), providing an immediate solution to the pressing problem of expensive cryptography, while more advanced solutions are developed, defined and deployed. ## Test Cases diff --git a/EIPS/eip-1123.md b/EIPS/eip-1123.md index 06a2b620bcf60..c34efb08178be 100644 --- a/EIPS/eip-1123.md +++ b/EIPS/eip-1123.md @@ -10,7 +10,7 @@ created: 2018-06-01 replaces: 190 --- -This ERC has been abandoned in favor of the EthPM V3 smart contract packaging standard defined in [ERC-2678](https://eips.ethereum.org/EIPS/eip-2678) +This ERC has been abandoned in favor of the EthPM V3 smart contract packaging standard defined in [ERC-2678](./eip-2678.md) Simple Summary ============== @@ -44,7 +44,7 @@ practices in mind. As version 2 of this specification, this standard seeks to address a number of areas of improvement found for the previous version (defined in -[EIP-190](https://eips.ethereum.org/EIPS/eip-190)). +[EIP-190](./eip-190.md)). This version: - Generalizes storage URIs to represent any content addressable URI @@ -1869,7 +1869,7 @@ Acknowledgements ================ The authors of this document would like to thank the original authors of -[EIP-190](https://eips.ethereum.org/EIPS/eip-190), +[EIP-190](./eip-190.md), [ETHPrize](http://ethprize.io/) for their funding support, all community [contributors](https://github.com/ethpm/ethpm-spec/graphs/contributors), diff --git a/EIPS/eip-1155.md b/EIPS/eip-1155.md index e3f411314ee14..62ded713a18ab 100644 --- a/EIPS/eip-1155.md +++ b/EIPS/eip-1155.md @@ -39,7 +39,7 @@ pragma solidity ^0.5.9; /** @title ERC-1155 Multi Token Standard - @dev See https://eips.ethereum.org/EIPS/eip-1155 + @dev See ./eip-1155.md Note: The ERC-165 identifier for this interface is 0xd9b67a26. */ interface ERC1155 /* is ERC165 */ { @@ -399,7 +399,7 @@ Example of such a URI: `https://token-cdn-domain/{id}.json` would be replaced wi #### Metadata Extensions -The optional `ERC1155Metadata_URI` extension can be identified with the (ERC-165 Standard Interface Detection)[https://eips.ethereum.org/EIPS/eip-165]. +The optional `ERC1155Metadata_URI` extension can be identified with the (ERC-165 Standard Interface Detection)[./eip-165.md]. If the optional `ERC1155Metadata_URI` extension is included: * The ERC-165 `supportsInterface` function MUST return the constant value `true` if `0x0e89341c` is passed through the `interfaceID` argument. @@ -577,7 +577,7 @@ fr.json: ### Approval -The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface](https://eips.ethereum.org/EIPS/eip-1761) is suggested. +The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. To permit approval of a subset of token IDs, an interface such as [ERC-1761 Scoped Approval Interface](./eip-1761.md) is suggested. The counterpart `isApprovedForAll` provides introspection into any status set by `setApprovalForAll`. An owner SHOULD be assumed to always be able to operate on their own tokens regardless of approval status, so should SHOULD NOT have to call `setApprovalForAll` to approve themselves as an operator before they can operate on them. @@ -592,7 +592,7 @@ The `name` function (for human-readable asset names, on-chain) was removed from ### Upgrades -The requirement to emit `TransferSingle` or `TransferBatch` on balance change implies that a valid implementation of ERC-1155 redeploying to a new contract address MUST emit events from the new contract address to replicate the deprecated contract final state. It is valid to only emit a minimal number of events to reflect only the final balance and omit all the transactions that led to that state. The event emit requirement is to ensure that the current state of the contract can always be traced only through events. To alleviate the need to emit events when changing contract address, consider using the proxy pattern, such as described in [EIP-2535](https://eips.ethereum.org/EIPS/eip-2535). This will also have the added benefit of providing a stable contract address for users. +The requirement to emit `TransferSingle` or `TransferBatch` on balance change implies that a valid implementation of ERC-1155 redeploying to a new contract address MUST emit events from the new contract address to replicate the deprecated contract final state. It is valid to only emit a minimal number of events to reflect only the final balance and omit all the transactions that led to that state. The event emit requirement is to ensure that the current state of the contract can always be traced only through events. To alleviate the need to emit events when changing contract address, consider using the proxy pattern, such as described in [EIP-2535](./eip-2535.md). This will also have the added benefit of providing a stable contract address for users. ### Design decision: Supporting non-batch @@ -610,7 +610,7 @@ As the Ethereum ecosystem continues to grow, many dapps are relying on tradition The function `setApprovalForAll` allows an operator to manage one's entire set of tokens on behalf of the approver. It enables frictionless interaction with exchange and trade contracts. -Restricting approval to a certain set of token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](https://eips.ethereum.org/EIPS/eip-1761) which is compatible with ERC-1155. +Restricting approval to a certain set of token IDs, quantities or other rules MAY be done with an additional interface or an external contract. The rationale is to keep the ERC-1155 standard as generic as possible for all use-cases without imposing a specific approval scheme on implementations that may not need it. Standard token approval interfaces can be used, such as the suggested [ERC-1761 Scoped Approval Interface](./eip-1761.md) which is compatible with ERC-1155. ## Backwards Compatibility @@ -686,9 +686,9 @@ Another simple way to represent non-fungibles is to allow a maximum value of 1 f ## References **Standards** -- [ERC-721 Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) -- [ERC-165 Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) -- [ERC-1538 Transparent Contract Standard](https://eips.ethereum.org/EIPS/eip-1538) +- [ERC-721 Non-Fungible Token Standard](./eip-721.md) +- [ERC-165 Standard Interface Detection](./eip-165.md) +- [ERC-1538 Transparent Contract Standard](./eip-1538.md) - [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) diff --git a/EIPS/eip-1193.md b/EIPS/eip-1193.md index d6be5f2c31ff2..c8bc8f538c4e7 100644 --- a/EIPS/eip-1193.md +++ b/EIPS/eip-1193.md @@ -214,7 +214,7 @@ interface ProviderConnectInfo { } ``` -`chainId` **MUST** specify the integer ID of the connected chain as a hexadecimal string, per the [`eth_chainId`](https://eips.ethereum.org/EIPS/eip-695) Ethereum RPC method. +`chainId` **MUST** specify the integer ID of the connected chain as a hexadecimal string, per the [`eth_chainId`](./eip-695.md) Ethereum RPC method. #### disconnect @@ -224,7 +224,7 @@ If the Provider becomes disconnected from all chains, the Provider **MUST** emit #### chainChanged -If the chain the Provider is connected to changes, the Provider **MUST** emit the event named `chainChanged` with value `chainId: string`, specifying the integer ID of the new chain as a hexadecimal string, per the [`eth_chainId`](https://eips.ethereum.org/EIPS/eip-695) Ethereum RPC method. +If the chain the Provider is connected to changes, the Provider **MUST** emit the event named `chainChanged` with value `chainId: string`, specifying the integer ID of the new chain as a hexadecimal string, per the [`eth_chainId`](./eip-695.md) Ethereum RPC method. #### accountsChanged @@ -295,7 +295,7 @@ It is paramount that the Provider implementer protects the user, Wallet, and Cli ### Chain Changes -Since all Ethereum operations are directed at a particular chain, it's important that the Provider accurately reflects the Client's configured chain, per the `eth_chainId` Ethereum RPC method (see [EIP-695](https://eips.ethereum.org/EIPS/eip-155)). +Since all Ethereum operations are directed at a particular chain, it's important that the Provider accurately reflects the Client's configured chain, per the `eth_chainId` Ethereum RPC method (see [EIP-695](./eip-155.md)). This includes ensuring that `eth_chainId` has the correct return value, and that the `chainChanged` event is emitted whenever that value changes. @@ -308,7 +308,7 @@ As with `eth_chainId`, it is critical that `eth_accounts` has the correct return The return value of `eth_accounts` is ultimately controlled by the Wallet or Client. In order to protect user privacy, the authors recommend not exposing any accounts by default. -Instead, Providers should support RPC methods for explicitly requesting account access, such as `eth_requestAccounts` (see [EIP-1102](https://eips.ethereum.org/EIPS/eip-1102)) or `wallet_requestPermissions` (see [EIP-2255](https://eips.ethereum.org/EIPS/eip-2255)). +Instead, Providers should support RPC methods for explicitly requesting account access, such as `eth_requestAccounts` (see [EIP-1102](./eip-1102.md)) or `wallet_requestPermissions` (see [EIP-2255](./eip-2255.md)). ## References @@ -316,10 +316,10 @@ Instead, Providers should support RPC methods for explicitly requesting account - [Deprecated Ethereum Magicians thread](https://ethereum-magicians.org/t/eip-1193-ethereum-provider-javascript-api/640) - [Continuing discussion](https://github.com/ethereum/EIPs/issues/2319) - Related EIPs - - [EIP-1102: Opt-in Account Exposure](https://eips.ethereum.org/EIPS/eip-1102) - - [EIP-1474: Remote Procedure Call Specification](https://eips.ethereum.org/EIPS/eip-1474) - - [EIP-1767: GraphQL Interface to Ethereum Node Data](https://eips.ethereum.org/EIPS/eip-1767) - - [EIP-2255: Wallet Permissions](https://eips.ethereum.org/EIPS/eip-2255) + - [EIP-1102: Opt-in Account Exposure](./eip-1102.md) + - [EIP-1474: Remote Procedure Call Specification](./eip-1474.md) + - [EIP-1767: GraphQL Interface to Ethereum Node Data](./eip-1767.md) + - [EIP-2255: Wallet Permissions](./eip-2255.md) ## Copyright @@ -349,14 +349,14 @@ Provider.request({ method: 'eth_accounts' }) ``` Consult each Ethereum RPC method's documentation for its `params` and return type. -You can find a list of common methods [here](https://eips.ethereum.org/EIPS/eip-1474). +You can find a list of common methods [here](./eip-1474.md). #### RPC Protocols Multiple RPC protocols may be available. For examples, see: -- [EIP-1474](https://eips.ethereum.org/EIPS/eip-1474), the Ethereum JSON-RPC API -- [EIP-1767](https://eips.ethereum.org/EIPS/eip-1767), the Ethereum GraphQL schema +- [EIP-1474](./eip-1474.md), the Ethereum JSON-RPC API +- [EIP-1767](./eip-1767.md), the Ethereum GraphQL schema ### Events @@ -547,7 +547,7 @@ This method is superseded by [`request`](#request). Provider.sendAsync(request: Object, callback: Function): void; ``` -Historically, the request and response object interfaces have followed the [Ethereum JSON-RPC specification](https://eips.ethereum.org/EIPS/eip-1474). +Historically, the request and response object interfaces have followed the [Ethereum JSON-RPC specification](./eip-1474.md). ### send (DEPRECATED) @@ -567,7 +567,7 @@ This event is superseded by [`disconnect`](#disconnect). The event `networkChanged` is superseded by [`chainChanged`](#chainchanged). -For details, see [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) and [EIP-695: Create eth_chainId method for JSON-RPC](https://eips.ethereum.org/EIPS/eip-695). +For details, see [EIP-155: Simple replay attack protection](./eip-155.md) and [EIP-695: Create eth_chainId method for JSON-RPC](./eip-695.md). #### notification (DEPRECATED) diff --git a/EIPS/eip-1202.md b/EIPS/eip-1202.md index aa5cd118d7084..53347d4378bc8 100644 --- a/EIPS/eip-1202.md +++ b/EIPS/eip-1202.md @@ -22,9 +22,9 @@ Voting is one of the earliest example of EVM programming, and also a key to DAO/ 1. Allow general UI and applications to be built on top of a standardized voting to allow more general user to participate, and encourage more DApp and DAO to think about their governance 2. Allow delegate voting / smart contract voting, automatic voting 3. Allow voting results to be recorded on-chain, in a standard way, and allow DAOs and DApps to honor the voting result programmatically. -4. Allow the compatibility with token standard such as [ERC-20](https://eips.ethereum.org/EIPS/eip-20) or other new standards([EIP-777](https://eips.ethereum.org/EIPS/eip-777)) and item standard such as [EIP-721](https://eips.ethereum.org/EIPS/eip-721) +4. Allow the compatibility with token standard such as [ERC-20](./eip-20.md) or other new standards([EIP-777](./eip-777.md)) and item standard such as [EIP-721](./eip-721.md) 5. Create massive potential for interoperability within Ethereum echo systems and other system. -6. Allow setting voting deadline, allow determine on single or multiple options. Allow requiring voting orders. (trade-off is interface complexity, we might need [ERC-20](https://eips.ethereum.org/EIPS/eip-20) approach and later a [EIP-777](https://eips.ethereum.org/EIPS/eip-777) for advanced voting) +6. Allow setting voting deadline, allow determine on single or multiple options. Allow requiring voting orders. (trade-off is interface complexity, we might need [ERC-20](./eip-20.md) approach and later a [EIP-777](./eip-777.md) for advanced voting) 7. Recording the voting with weights with token amount. 8. Possibly allow trust-worthy privacy-safe voting and anonymous voting (with either voter address being un-associated with the vote they cast, given a list of randomized/obfuscated voting options). 8 @@ -32,7 +32,7 @@ Voting is one of the earliest example of EVM programming, and also a key to DAO/ ### Use-cases: 1. Determine on issuing new token, issuing more token or issuing sub-token -2. Determine on creating new item under [EIP-721](https://eips.ethereum.org/EIPS/eip-721) +2. Determine on creating new item under [EIP-721](./eip-721.md) 3. Determine on election on certain person or smart contract to be delegated leader for project or subproject 4. Determine on auditing result ownership allowing migration of smart contract proxy address @@ -116,16 +116,16 @@ The fourth consideration is potential abuse. When voting is standardized and put ## Bibliography ### Related EIPs - - [EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)](https://eips.ethereum.org/EIPS/eip-20) - - [EIP-165: Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) - - [EIP-721: Non-Fungible Token Standard(a.k.a. ERC-721)](https://eips.ethereum.org/EIPS/eip-721) + - [EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)](./eip-20.md) + - [EIP-165: Standard Interface Detection](./eip-165.md) + - [EIP-721: Non-Fungible Token Standard(a.k.a. ERC-721)](./eip-721.md) - [EIP-735: ERC: Claim Holder](https://github.com/ethereum/EIPs/issues/735) - [EIP-780: ERC: Ethereum Claims Registry](https://github.com/ethereum/EIPs/issues/780) - - [EIP-777: A New Advanced Token Standard](https://eips.ethereum.org/EIPS/eip-777) - - [EIP-897: ERC DelegateProxy](https://eips.ethereum.org/EIPS/eip-897) - - [EIP-1155: Crypto Item Standard](https://eips.ethereum.org/EIPS/eip-1155) - - [EIP-1178: Multi-class Token Standard](https://eips.ethereum.org/EIPS/eip-1178) - - [EIP-1167: Minimal Proxy Contract](https://eips.ethereum.org/EIPS/eip-1167) + - [EIP-777: A New Advanced Token Standard](./eip-777.md) + - [EIP-897: ERC DelegateProxy](./eip-897.md) + - [EIP-1155: Crypto Item Standard](./eip-1155.md) + - [EIP-1178: Multi-class Token Standard](./eip-1178.md) + - [EIP-1167: Minimal Proxy Contract](./eip-1167.md) - [EIP-1203: Multi-class Token Standard(ERC-20 Extension)](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1203.md) ### Worthnoting Projects diff --git a/EIPS/eip-1234.md b/EIPS/eip-1234.md index 5cf44307ef379..c4363d36dbb59 100644 --- a/EIPS/eip-1234.md +++ b/EIPS/eip-1234.md @@ -55,7 +55,7 @@ This EIP is not forward compatible and introduces backwards incompatibilities in Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. ## Implementation -The implementation in it's logic does not differ from [EIP-649](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-649.md); an implementation for Parity-Ethereum is available in [parity-ethereum#9187](https://github.com/paritytech/parity-ethereum/pull/9187). +The implementation in it's logic does not differ from [EIP-649](./eip-649.md); an implementation for Parity-Ethereum is available in [parity-ethereum#9187](https://github.com/paritytech/parity-ethereum/pull/9187). ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-1261.md b/EIPS/eip-1261.md index 022a3ed8ee114..d8224f7763565 100644 --- a/EIPS/eip-1261.md +++ b/EIPS/eip-1261.md @@ -361,10 +361,10 @@ Membership Verification Token ERC1261 -- a reference implementation **Standards** -1. ERC-20 Token Standard. https://eips.ethereum.org/EIPS/eip-20 -1. ERC-165 Standard Interface Detection. https://eips.ethereum.org/EIPS/eip-165 -1. ERC-725/735 Claim Registry https://eips.ethereum.org/EIPS/eip-725 -1. ERC-173 Owned Standard. https://eips.ethereum.org/EIPS/eip-173 +1. ERC-20 Token Standard. ./eip-20.md +1. ERC-165 Standard Interface Detection. ./eip-165.md +1. ERC-725/735 Claim Registry ./eip-725.md +1. ERC-173 Owned Standard. ./eip-173.md 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 diff --git a/EIPS/eip-1276.md b/EIPS/eip-1276.md index 5ba312529ec09..d5bcc711b3a4c 100644 --- a/EIPS/eip-1276.md +++ b/EIPS/eip-1276.md @@ -48,7 +48,7 @@ This is the existing pre-Constantinople formula for nephew rewards, simply adjus ## Rationale This will completely remove the difficulty bomb on difficulty adjustment algorithm without delaying the difficulty bomb again, therefore it is possible to prevent network delay on the beginning of 2019. -This EIP-1276 opposes directly the intent of [EIP-1234](https://eips.ethereum.org/EIPS/eip-1234) which should be also considered in discussions. +This EIP-1276 opposes directly the intent of [EIP-1234](./eip-1234.md) which should be also considered in discussions. ## Backwards Compatibility This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. Therefore, it should be included in a scheduled hardfork at a certain block number. It's suggested to include this EIP in the second Metropolis hard-fork, _Constantinople_. diff --git a/EIPS/eip-1344.md b/EIPS/eip-1344.md index 10684a31b9239..751e4b05ffd55 100644 --- a/EIPS/eip-1344.md +++ b/EIPS/eip-1344.md @@ -14,7 +14,7 @@ requires: 155 This EIP adds an opcode that returns the current chain's EIP-155 unique identifier. ## Motivation -[EIP-155](https://eips.ethereum.org/EIPS/eip-155) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](https://eips.ethereum.org/EIPS/eip-712). +[EIP-155](./eip-155.md) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](./eip-712.md). ## Specification Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. Chain ID is a 256-bit value. The operation costs `G_base` to execute. diff --git a/EIPS/eip-137.md b/EIPS/eip-137.md index d32297b232240..b35e9ef62c264 100644 --- a/EIPS/eip-137.md +++ b/EIPS/eip-137.md @@ -163,7 +163,7 @@ Resolvers have one mandatory function: function supportsInterface(bytes4 interfaceID) constant returns (bool) ``` -The `supportsInterface` function is documented in [EIP-165](https://eips.ethereum.org/EIPS/eip-165), and returns true if the resolver implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a resolver returns `true` for `supportsInterface()`, it must implement the functions specified in that interface. +The `supportsInterface` function is documented in [EIP-165](./eip-165.md), and returns true if the resolver implements the interface specified by the provided 4 byte identifier. An interface identifier consists of the XOR of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. If a resolver returns `true` for `supportsInterface()`, it must implement the functions specified in that interface. `supportsInterface` must always return true for `0x01ffc9a7`, which is the interface ID of `supportsInterface` itself. diff --git a/EIPS/eip-1417.md b/EIPS/eip-1417.md index f30735effc242..449b374e3f517 100644 --- a/EIPS/eip-1417.md +++ b/EIPS/eip-1417.md @@ -21,7 +21,7 @@ A standard interface for Polls to be used with EIP-1261 (MVT). ## Abstract -The following standard allows for the implementation of a standard API for polls to be used with MVTs (refer [EIP-1261](https://eips.ethereum.org/EIPS/eip-1261)). The standard provides basic functionality to vote, unvote, tally votes, get voter turnout, and a lot more. The poll standard attempts to modularize blockchain voting by breaking down a poll into 4 crucial building blocks: voterbase qualification, vote weight calculation, vote consequences, and vote tallying. By creating a common interface for polls that have different kinds of building blocks, the poll standard makes it possible to make interactive front end applications which can seamlessly get data from a poll contract in order to bring transparency into consensus and decision making on the blockchain. +The following standard allows for the implementation of a standard API for polls to be used with MVTs (refer [EIP-1261](./eip-1261.md)). The standard provides basic functionality to vote, unvote, tally votes, get voter turnout, and a lot more. The poll standard attempts to modularize blockchain voting by breaking down a poll into 4 crucial building blocks: voterbase qualification, vote weight calculation, vote consequences, and vote tallying. By creating a common interface for polls that have different kinds of building blocks, the poll standard makes it possible to make interactive front end applications which can seamlessly get data from a poll contract in order to bring transparency into consensus and decision making on the blockchain. 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: @@ -60,7 +60,7 @@ All that being said, we are very excited to share our proposal with the communit 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 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) +3. Allow the compatibility with token standard such as [ERC-20](./eip-20.md) or (./eip-777.md)) and membership standard such as [EIP-1261](./eip-1261.md) 4. Flexibility allows for various voting schemes including but not limited to modern schemes such as PLCR Voting ### Use-cases: @@ -257,9 +257,9 @@ Voting Standard -- a reference implementation **Standards** -- [EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)](https://eips.ethereum.org/EIPS/eip-20) -- [EIP-165: Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) -- [EIP-721: Non-Fungible Token Standard(a.k.a. ERC-721)](https://eips.ethereum.org/EIPS/eip-721) +- [EIP-20: ERC-20 Token Standard (a.k.a. ERC-20)](./eip-20.md) +- [EIP-165: Standard Interface Detection](./eip-165.md) +- [EIP-721: Non-Fungible Token Standard(a.k.a. ERC-721)](./eip-721.md) - [ERC-1261 MV Token Standard](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1261.md) - [RFC 2119 Key words for use in RFCs to Indicate Requirement Levels](https://www.ietf.org/rfc/rfc2119.txt) diff --git a/EIPS/eip-1444.md b/EIPS/eip-1444.md index b46d4f58e7dca..4977ed7de67e0 100644 --- a/EIPS/eip-1444.md +++ b/EIPS/eip-1444.md @@ -23,7 +23,7 @@ There are many cases where an end user needs feedback or instruction from a smar Returning a hard-coded string (typically in English) only serves a small segment of the global population. This standard proposes a method to allow users to create, register, share, and use a decentralized collection of translations, enabling richer messaging that is more culturally and linguistically diverse. -There are several machine efficient ways of representing intent, status, state transition, and other semantic signals including booleans, enums and [ERC-1066 codes](https://eips.ethereum.org/EIPS/eip-1066). By providing human-readable messages for these signals, the developer experience is enhanced by returning easier to consume information with more context (ex. `revert`). End user experience is enhanced by providing text that can be propagated up to the UI. +There are several machine efficient ways of representing intent, status, state transition, and other semantic signals including booleans, enums and [ERC-1066 codes](./eip-1066.md). By providing human-readable messages for these signals, the developer experience is enhanced by returning easier to consume information with more context (ex. `revert`). End user experience is enhanced by providing text that can be propagated up to the UI. ## Specification @@ -135,7 +135,7 @@ Text with 2 or more arguments SHOULD use the POSIX parameter field extension. `bytes32` is very efficient since it is the EVM's base word size. Given the enormous number of elements (card(A) > 1.1579 × 1077), it can embed nearly any practical signal, enum, or state. In cases where an application's key is longer than `bytes32`, hashing that long key can map that value into the correct width. -Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](https://eips.ethereum.org/EIPS/eip-1066)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the the larger one. +Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](./eip-1066.md)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the the larger one. ### Local vs Globals and Singletons diff --git a/EIPS/eip-1459.md b/EIPS/eip-1459.md index 9c269fe8a6558..e559fc2bd8110 100644 --- a/EIPS/eip-1459.md +++ b/EIPS/eip-1459.md @@ -32,7 +32,7 @@ configure the client to use the provider's list. # Specification -A 'node list' is a list of 'node records' [as defined by EIP-778](https://eips.ethereum.org/EIPS/eip-778) +A 'node list' is a list of 'node records' [as defined by EIP-778](./eip-778.md) of arbitrary length. Lists may refer to other lists using links. The entire list is signed using a secp256k1 private key. The corresponding public key must be known to the client diff --git a/EIPS/eip-1462.md b/EIPS/eip-1462.md index 72196c51956d3..09e0fee83a588 100644 --- a/EIPS/eip-1462.md +++ b/EIPS/eip-1462.md @@ -16,15 +16,15 @@ An extension to ERC-20 standard token that provides compliance with securities r ## Abstract -This EIP defines a minimal set of additions to the default token standard such as [ERC-20](https://eips.ethereum.org/EIPS/eip-20), that allows for compliance with domestic and international legal requirements. Such requirements include KYC (Know Your Customer) and AML (Anti Money Laundering) regulations, and the ability to lock tokens for an account, and restrict them from transfer due to a legal dispute. Also the ability to attach additional legal documentation, in order to set up a dual-binding relationship between the token and off-chain legal entities. +This EIP defines a minimal set of additions to the default token standard such as [ERC-20](./eip-20.md), that allows for compliance with domestic and international legal requirements. Such requirements include KYC (Know Your Customer) and AML (Anti Money Laundering) regulations, and the ability to lock tokens for an account, and restrict them from transfer due to a legal dispute. Also the ability to attach additional legal documentation, in order to set up a dual-binding relationship between the token and off-chain legal entities. The scope of this standard is being kept as narrow as possible to avoid restricting potential use-cases of this base security token. Any additional functionality and limitations not defined in this standard may be enforced on per-project basis. ## Motivation -There are several security token standards that have been proposed recently. Examples include [ERC-1400](https://github.com/ethereum/EIPs/issues/1411), also [ERC-1450](https://eips.ethereum.org/EIPS/eip-1450). We have concerns about each of them, mostly because the scope of each of these EIPs contains many project-specific or market-specific details. Since many EIPs are coming from the respective backing companies, they capture many niche requirements that are excessive for a general case. +There are several security token standards that have been proposed recently. Examples include [ERC-1400](https://github.com/ethereum/EIPs/issues/1411), also [ERC-1450](./eip-1450.md). We have concerns about each of them, mostly because the scope of each of these EIPs contains many project-specific or market-specific details. Since many EIPs are coming from the respective backing companies, they capture many niche requirements that are excessive for a general case. -For instance, ERC-1411 uses dependency on [ERC-1410](https://github.com/ethereum/eips/issues/1410) but it falls out of the "security tokens" scope. Also its dependency on [ERC-777](https://eips.ethereum.org/EIPS/eip-777) will block the adoption for a quite period of time before ERC-777 is finalized, but the integration guidelines for existing ERC-20 workflows are not described in that EIP, yet. Another attempt to make a much simpler base standard [ERC-1404](https://github.com/ethereum/EIPs/issues/1404) is missing a few important points, specifically it doesn't provide enough granularity to distinguish between different ERC-20 transfer functions such as `transfer` and `transferFrom`. It also doesn't provide a way to bind legal documentation to the issued tokens. +For instance, ERC-1411 uses dependency on [ERC-1410](https://github.com/ethereum/eips/issues/1410) but it falls out of the "security tokens" scope. Also its dependency on [ERC-777](./eip-777.md) will block the adoption for a quite period of time before ERC-777 is finalized, but the integration guidelines for existing ERC-20 workflows are not described in that EIP, yet. Another attempt to make a much simpler base standard [ERC-1404](https://github.com/ethereum/EIPs/issues/1404) is missing a few important points, specifically it doesn't provide enough granularity to distinguish between different ERC-20 transfer functions such as `transfer` and `transferFrom`. It also doesn't provide a way to bind legal documentation to the issued tokens. What we propose in this EIP is a simple and very modular solution for creating a base security token for the widest possible scope of applications, so it can be used by other issuers to build upon. The issuers should be able to add more restrictions and policies to the token, using the functions and implementation proposed below, but they must not be limited in any way while using this ERC. @@ -65,15 +65,15 @@ interface BaseSecurityToken /* is ERC-20 */ { We introduce four new functions that should be used to check that the actions are allowed for the provided inputs. The implementation details of each function are left for the token issuer, it is the issuer's responsibility to add all necessary checks that will validate an operation in accordance with KYC/AML policies and legal requirements set for a specific token asset. -Each function must return a status code from the common set of Ethereum status codes (ESC), according to [ERC-1066](https://eips.ethereum.org/EIPS/eip-1066). Localization of these codes is out of the scope of this proposal and may be optionally solved by adopting [ERC-1444](https://github.com/ethereum/EIPs/pull/1444) on the application level. If the operation is allowed by a checking function, the return status code must be `0x11` (Allowed) or an issuer-specific code with equivalent but more precise meaning. If the operation is not allowed by a checking function, the status must be `0x10` (Disallowed) or an issuer-specific code with equivalent but more precise meaning. Upon an internal error, the function must return the most relevant code from the general code table or an issuer-specific equivalent, example: `0xF0` (Off-Chain Failure). +Each function must return a status code from the common set of Ethereum status codes (ESC), according to [ERC-1066](./eip-1066.md). Localization of these codes is out of the scope of this proposal and may be optionally solved by adopting [ERC-1444](https://github.com/ethereum/EIPs/pull/1444) on the application level. If the operation is allowed by a checking function, the return status code must be `0x11` (Allowed) or an issuer-specific code with equivalent but more precise meaning. If the operation is not allowed by a checking function, the status must be `0x10` (Disallowed) or an issuer-specific code with equivalent but more precise meaning. Upon an internal error, the function must return the most relevant code from the general code table or an issuer-specific equivalent, example: `0xF0` (Off-Chain Failure). -**For [ERC-20](https://eips.ethereum.org/EIPS/eip-20) based tokens,** +**For [ERC-20](./eip-20.md) based tokens,** * It is required that transfer function must be overridden with logic that checks the corresponding checkTransferAllowed return status code. * It is required that `transferFrom` function must be overridden with logic that checks the corresponding `checkTransferFromAllowed` return status code. * It is required that `approve` function must be overridden with logic that checks the corresponding `checkTransferFromAllowed` return status code. * Other functions such as `mint` and `burn` must be overridden, if they exist in the token implementation, they should check `checkMintAllowed` and `checkBurnAllowed` status codes accordingly. -**For [ERC-777](https://eips.ethereum.org/EIPS/eip-777) based tokens,** +**For [ERC-777](./eip-777.md) based tokens,** * It is required that `send` function must be overridden with logic that checks the corresponding return status codes: - `checkTransferAllowed` return status code, if transfer happens on behalf of the tokens owner; - `checkTransferFromAllowed` return status code, if transfer happens on behalf of an operator (i.e. delegated transfer). @@ -98,9 +98,9 @@ We also introduce two new functions that should be used for document management This EIP targets both ERC-20 and ERC-777 based tokens, although the most emphasis is given to ERC-20 due to its widespread adoption. However, this extension is designed to be compatible with the forthcoming ERC-777 standard, as well. -All checking functions are named with prefixes `check` since they return check status code, not booleans, because that is important to facilitate the debugging and tracing process. It is responsibility of the issuer to implement the logic that will handle the return codes appropriately. Some handlers will simply throw errors, other handlers would log information for future process mining. More rationale for status codes can be seen in [ERC-1066](https://eips.ethereum.org/EIPS/eip-1066). +All checking functions are named with prefixes `check` since they return check status code, not booleans, because that is important to facilitate the debugging and tracing process. It is responsibility of the issuer to implement the logic that will handle the return codes appropriately. Some handlers will simply throw errors, other handlers would log information for future process mining. More rationale for status codes can be seen in [ERC-1066](./eip-1066.md). -We require two different transfer validation functions: `checkTransferAllowed` and `checkTransferFromAllowed` since the corresponding `transfer` and `transferFrom` are usually called in different contexts. Some token standards such as [ERC-1450](https://eips.ethereum.org/EIPS/eip-1450) explicitly disallow use of `transfer`, while allowing only `transferFrom`. There might be also different complex scenarios, where `transfer` and `transferFrom` should be treated differently. ERC-777 is relying on its own `send` for transferring tokens, so it is reasonable to switch between checker functions based on its call context. We decided to omit the `checkApprove` function since it would be used in exactly the same context as `checkTransferFromAllowed`. In many cases it is required not only regulate securities transfers, but also restrict burn and `mint` operations, and additional checker functions have been added for that. +We require two different transfer validation functions: `checkTransferAllowed` and `checkTransferFromAllowed` since the corresponding `transfer` and `transferFrom` are usually called in different contexts. Some token standards such as [ERC-1450](./eip-1450.md) explicitly disallow use of `transfer`, while allowing only `transferFrom`. There might be also different complex scenarios, where `transfer` and `transferFrom` should be treated differently. ERC-777 is relying on its own `send` for transferring tokens, so it is reasonable to switch between checker functions based on its call context. We decided to omit the `checkApprove` function since it would be used in exactly the same context as `checkTransferFromAllowed`. In many cases it is required not only regulate securities transfers, but also restrict burn and `mint` operations, and additional checker functions have been added for that. The documentation functions that we propose here are a must-have tool to create dual-bindings with off-chain legal documents, a great example of this can be seen in [Neufund's Employee Incentive Options Plan](https://medium.com/@ZoeAdamovicz/37376fd0384a) legal framework that implements full legal enforceability: the smart contract refers to printed ESOP Terms & Conditions Document, which itself refers back to smart contract. This is becoming a widely adopted practice even in cases where there are no legal requirements to reference the documents within the security token. However they're almost always required, and it's a good way to attach useful documentation of various types. diff --git a/EIPS/eip-1474.md b/EIPS/eip-1474.md index 05900ffe9842b..0c2fe8b880b28 100644 --- a/EIPS/eip-1474.md +++ b/EIPS/eip-1474.md @@ -94,7 +94,7 @@ The RPC methods below take a default block identifier as a parameter. - `eth_call` - `eth_getProof` -Since there is no way to clearly distinguish between a `Data` parameter and a `Quantity` parameter, [EIP-1898](eip-1898.md) provides a format to specify a block either using the block hash or block number. The block identifier is a JSON `object` with the following fields: +Since there is no way to clearly distinguish between a `Data` parameter and a `Quantity` parameter, [EIP-1898](./eip-1898.md) provides a format to specify a block either using the block hash or block number. The block identifier is a JSON `object` with the following fields: |Property|Type|Description| |-|-|-| diff --git a/EIPS/eip-1484.md b/EIPS/eip-1484.md index fd0c7799ae8d8..28b1bc4885daf 100644 --- a/EIPS/eip-1484.md +++ b/EIPS/eip-1484.md @@ -17,7 +17,7 @@ A protocol for aggregating digital identity information that's broadly interoper This EIP proposes an identity management and aggregation framework on the Ethereum blockchain. It allows entities to claim an `Identity` via a singular `Identity Registry` smart contract, associate it with Ethereum addresses in a variety of meaningful ways, and use it to interact with smart contracts. This enables arbitrarily complex identity-related functionality. Notably (among other features) ERC-1484 `Identities`: are self-sovereign, can natively support [ERC-725](https://github.com/NoahZinsmeister/ERC-1484/tree/master/contracts/examples/Resolvers/ERC725) and [ERC-1056](https://github.com/NoahZinsmeister/ERC-1484/tree/master/contracts/examples/Resolvers/ERC1056) identities, are [DID compliant](https://github.com/NoahZinsmeister/ERC-1484/blob/master/best-practices/DID-Method.md), and can be fully powered by [meta-transactions](https://github.com/NoahZinsmeister/ERC-1484/tree/master/contracts/examples/Providers/MetaTransactions). ## Motivation -Emerging identity standards and related frameworks proposed by the Ethereum community (including ERCs/EIPs [725](https://eips.ethereum.org/EIPS/eip-725), [735](https://github.com/ethereum/EIPs/issues/735), [780](https://github.com/ethereum/EIPs/issues/780), [1056](https://eips.ethereum.org/EIPS/eip-1056), etc.) define and instrumentalize digital identity in a variety of ways. As existing approaches mature, new standards emerge, and isolated, non-standard approaches to identity develop, coordinating on identity will become increasingly burdensome for blockchain users and developers, and involve the unnecessary duplication of work. +Emerging identity standards and related frameworks proposed by the Ethereum community (including ERCs/EIPs [725](./eip-725.md), [735](https://github.com/ethereum/EIPs/issues/735), [780](https://github.com/ethereum/EIPs/issues/780), [1056](./eip-1056.md), etc.) define and instrumentalize digital identity in a variety of ways. As existing approaches mature, new standards emerge, and isolated, non-standard approaches to identity develop, coordinating on identity will become increasingly burdensome for blockchain users and developers, and involve the unnecessary duplication of work. The proliferation of on-chain identity solutions can be traced back to the fact that each codifies a notion of identity and links it to specific aspects of Ethereum (claims protocols, per-identity smart contracts, signature verification schemes, etc.). This proposal eschews that approach, instead introducing a protocol layer in between the Ethereum network and individual identity applications. This solves identity management and interoperability challenges by enabling any identity-driven application to leverage an un-opinionated identity management protocol. @@ -536,9 +536,9 @@ interface IdentityRegistryInterface { ## Additional References - [ERC-1484 Reference Implementation](https://github.com/NoahZinsmeister/ERC-1484) -- [ERC-191 Signatures](https://eips.ethereum.org/EIPS/eip-191) -- [ERC-725 Identities](https://eips.ethereum.org/EIPS/eip-725) -- [ERC-1056 Identities](https://eips.ethereum.org/EIPS/eip-1056) +- [ERC-191 Signatures](./eip-191.md) +- [ERC-725 Identities](./eip-725.md) +- [ERC-1056 Identities](./eip-1056.md) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-1485.md b/EIPS/eip-1485.md index 7b2c29f4f9f0c..bbddd55bb5abf 100644 --- a/EIPS/eip-1485.md +++ b/EIPS/eip-1485.md @@ -69,7 +69,7 @@ Provide original Ethash proof of work verification with minimal set of changes b #### 3. FNV1A hash algorithm description -Previous proposed algorithm based on FNV1 [EIP-1355](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1355.md) +Previous proposed algorithm based on FNV1 [EIP-1355](./eip-1355.md) There's a implementation that looks like "Missing Offset Bias" at **FNV1A**. diff --git a/EIPS/eip-1592.md b/EIPS/eip-1592.md index da3764bb7d83c..9345541329cf9 100644 --- a/EIPS/eip-1592.md +++ b/EIPS/eip-1592.md @@ -28,9 +28,9 @@ This standard proposal should answer the following challenges: If these challenges are answered, this proposal will provide a unified basis for transfer rules and hopefully address the transfer restriction needs of other EIPs as well, e.g. -[EIP-902](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-902.md), -[EIP-1066](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1066.md) -and [EIP-1175](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1175.md). +[EIP-902](./eip-902.md), +[EIP-1066](./eip-1066.md) +and [EIP-1175](./eip-1175.md). This document proposes specifications for a standard of **transfer rules** and interfaces to both the rules and the rule engine, which was made to be inherited by a token, but may have a much broader scope in the authors' opinion. diff --git a/EIPS/eip-1613.md b/EIPS/eip-1613.md index c284bb88a4a3f..2de2b2a663656 100644 --- a/EIPS/eip-1613.md +++ b/EIPS/eip-1613.md @@ -20,9 +20,9 @@ Require no network changes, and minimal contract changes. Communicating with dapps currently requires paying ETH for gas, which limits dapp adoption to ether users. Therefore, contract owners may wish to pay for the gas to increase user acquisition, or let their users pay for gas with fiat money. Alternatively, a 3rd party may wish to subsidize the gas costs of certain contracts. -Solutions such as described in [EIP-1077](https://eips.ethereum.org/EIPS/eip-1077) could allow transactions from addresses that hold no ETH. +Solutions such as described in [EIP-1077](./eip-1077.md) could allow transactions from addresses that hold no ETH. -The gas stations network is an [EIP-1077](https://eips.ethereum.org/EIPS/eip-1077) compliant effort to solve the problem by creating an incentive for nodes to run gas stations, where gasless transactions can be "fueled up". +The gas stations network is an [EIP-1077](./eip-1077.md) compliant effort to solve the problem by creating an incentive for nodes to run gas stations, where gasless transactions can be "fueled up". It abstracts the implementation details from both the dapp maintainer and the user, making it easy to convert existing dapps to accept "collect-calls". The network consists of a single public contract trusted by all participating dapp contracts, and a decentralized network of relay nodes (gas stations) incentivized to listen on non-ether interfaces such as web or whisper, diff --git a/EIPS/eip-162.md b/EIPS/eip-162.md index 8648c599d103e..21d2c2a82246d 100644 --- a/EIPS/eip-162.md +++ b/EIPS/eip-162.md @@ -31,7 +31,7 @@ created: 2016-10-25 This ERC describes the implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the Ethereum Name Service (ENS). The corresponding source code is [here](https://github.com/ethereum/ens/blob/mainnet/contracts/HashRegistrarSimplified.sol). -For more background, refer to [EIP 137](https://eips.ethereum.org/EIPS/eip-137). +For more background, refer to [EIP 137](./eip-137.md). > Registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ENS; the owner of a node in the ENS registry is its registrar. Registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts. > @@ -235,7 +235,7 @@ This approach is simpler than the familiar model of requiring owners to make rec ## Prior work This document borrows heavily from several sources: -- [EIP 137](https://eips.ethereum.org/EIPS/eip-137) outlines the initial implementation of the Registry Contract (ENS.sol) and associated Resolver contracts. +- [EIP 137](./eip-137.md) outlines the initial implementation of the Registry Contract (ENS.sol) and associated Resolver contracts. - [ERC 26](https://github.com/ethereum/EIPs/issues/26) was the first ERC to propose a name service at the contract layer - @alexvandesande's current implementation of the [HashRegistrar](https://github.com/ethereum/ens/blob/mainnet/contracts/HashRegistrarSimplified.sol) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index fafda89f9aec2..0c968c1e181b6 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -25,12 +25,12 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - `Block >= 1,561,651` on the Görli testnet ### Included EIPs - - [EIP-152](https://eips.ethereum.org/EIPS/eip-152): Add Blake2 compression function `F` precompile - - [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108): Reduce alt_bn128 precompile gas costs - - [EIP-1344](https://eips.ethereum.org/EIPS/eip-1344): Add ChainID opcode - - [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes - - [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction - - [EIP-2200](https://eips.ethereum.org/EIPS/eip-2200): Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change + - [EIP-152](./eip-152.md): Add Blake2 compression function `F` precompile + - [EIP-1108](./eip-1108.md): Reduce alt_bn128 precompile gas costs + - [EIP-1344](./eip-1344.md): Add ChainID opcode + - [EIP-1884](./eip-1884.md): Repricing for trie-size-dependent opcodes + - [EIP-2028](./eip-2028.md): Calldata gas cost reduction + - [EIP-2200](./eip-2200.md): Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change ## References diff --git a/EIPS/eip-1682.md b/EIPS/eip-1682.md index 6c81518296f14..c5301d840f013 100644 --- a/EIPS/eip-1682.md +++ b/EIPS/eip-1682.md @@ -32,13 +32,7 @@ upper bound on the size of the Ethereum state. Adding these new rules changes fundamental guarantees of the system and requires a hard fork. Users of Ethereum already pay for the creation and modification of accounts and their storage entries. Under the rules introduced in this EIP, users must also pay to keep -accounts accessible. A similar rent scheme was proposed in [EIP-103] but rejected -even back then because the proposal would've upset peoples expectations. As implementers -of Ethereum, we still feel that state rent is the right path to long-term sustainability -of the Ethereum blockchain and that its undesirable implications can be overcome with -off-protocol tooling and careful design. - -[EIP-103]: https://github.com/ethereum/EIPs/issues/35 +accounts accessible. ## Specification diff --git a/EIPS/eip-1706.md b/EIPS/eip-1706.md index 02174324a30f1..755fcfb266f83 100644 --- a/EIPS/eip-1706.md +++ b/EIPS/eip-1706.md @@ -16,7 +16,7 @@ superseded-by: 2200 The proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. This proposal will make the old assumptions hold even after a network upgrade. ## Abstract -[EIP-1283](https://eips.ethereum.org/EIPS/eip-1283) significantly lowers the gas costs of writing to contract's storage. This created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a 'stipend' of 2300 gas to simple transfer calls. +[EIP-1283](./eip-1283.md) significantly lowers the gas costs of writing to contract's storage. This created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a 'stipend' of 2300 gas to simple transfer calls. This danger is easily mitigated if SSTORE is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of this EIP. ## Motivation diff --git a/EIPS/eip-1710.md b/EIPS/eip-1710.md index 3b41b90d1ce33..f18e9f5f6db77 100644 --- a/EIPS/eip-1710.md +++ b/EIPS/eip-1710.md @@ -24,7 +24,7 @@ Lots of dApps that are trying to improve their mobile experience are currently ( In order to make the experience more seamless, dApps should still be able to recommend a specific mobile web3 browser via [deferred deeplinking](https://en.wikipedia.org/wiki/Deferred_deep_linking) but by having a standard url format, if the user already has a web3 browser installed that implements this standard, it will be automatically linked to it. -There is also a compatibility problem with the current `ethereum:` url scheme described in [EIP-831](https://eips.ethereum.org/EIPS/eip-831) where any ethereum related app (wallets, identity management, etc) already registered it and because of iOS unpredictable behavior for multiple apps handling a single url scheme, users can end up opening an `ethereum:` link in an app that doesn not include a web3 browser and will not be able to handle the deeplink correctly. +There is also a compatibility problem with the current `ethereum:` url scheme described in [EIP-831](./eip-831.md) where any ethereum related app (wallets, identity management, etc) already registered it and because of iOS unpredictable behavior for multiple apps handling a single url scheme, users can end up opening an `ethereum:` link in an app that doesn not include a web3 browser and will not be able to handle the deeplink correctly. ## Specification @@ -38,7 +38,7 @@ Web3 browser URLs contain "dapp" in their schema (protocol) part and are constru ### Semantics -`chain_id` is optional and it is a parameter for the browser to automatically select the corresponding chain ID as specified in [EIP-155](https://eips.ethereum.org/EIPS/eip-155) before opening the dApp. +`chain_id` is optional and it is a parameter for the browser to automatically select the corresponding chain ID as specified in [EIP-155](./eip-155.md) before opening the dApp. `dapp_url` is a valid [RFC3986](https://www.ietf.org/rfc/rfc3986.txt) URI diff --git a/EIPS/eip-173.md b/EIPS/eip-173.md index 0853913f85a0c..bc77693e94c80 100644 --- a/EIPS/eip-173.md +++ b/EIPS/eip-173.md @@ -87,7 +87,7 @@ Here are other schemes that were considered: This standard does not exclude the above ownership schemes or other schemes from also being implemented in the same contract. For example a contract could implement this standard and also implement the other schemes so that ownership could be managed and transferred in multiple ways. This standard does provide a simple ownership scheme that is backwards compatible, is light-weight and simple to implement, and can be widely adopted and depended on. -This standard can be extended by other standards to add additional ownership functionality. For example [EIP-2767](https://eips.ethereum.org/EIPS/eip-2767) uses and extends this standard by adding decentralized contract ownership governance. +This standard can be extended by other standards to add additional ownership functionality. For example [EIP-2767](./eip-2767.md) uses and extends this standard by adding decentralized contract ownership governance. ## Security Considerations diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index bc93338ba5e5d..ecea7c3fb8f02 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -23,10 +23,10 @@ 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 a master account (or app key) unique for the domain from an user private key (her root private key or any other private key of an account derived or not from her root one). This EIP aims at becoming a standard on how to derive keys specific to each application that can be regenerated from scratch without further input from the user if she restores her wallet and uses again the application for which this key was derived. -These app keys can then be endowed a different set of permissions (through the requestPermission model introduced in [EIP2255](https://eips.ethereum.org/EIPS/eip-2255)). This will potentially allow an user to partly trust some apps to perform some crypto operations on their behalf without compromising any security with respect to her main accounts. +These app keys can then be endowed a different set of permissions (through the requestPermission model introduced in [EIP-2255](./eip-2255.md)). This will potentially allow an user to partly trust some apps to perform some crypto operations on their behalf without compromising any security with respect to her main accounts. ## Motivation -Wallets developers have agreed on an HD derivation path for ethereum accounts using BIP32, BIP44, SLIP44, [(see the discussion here)](https://github.com/ethereum/EIPs/issues/84). Web3 wallets have implemented in a roughly similar way the rpc eth api. [EIP1102](https://eips.ethereum.org/EIPS/eip-1102) introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. +Wallets developers have agreed on an HD derivation path for ethereum accounts using BIP-32, BIP-44, SLIP-44, [(see the discussion here)](https://github.com/ethereum/EIPs/issues/84). Web3 wallets have implemented in a roughly similar way the rpc eth api. [EIP-1102](./eip-1102.md) introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. However several limitations remain in order to allow for proper design and UX for crypto permissioned apps. @@ -146,7 +146,7 @@ https://github.com/ethereum/EIPs/issues/85 https://ethereum-magicians.org/t/default-accounts-for-dapps/904 * non wallet/crypto accounts -[EIP1581: Non-wallet usage of keys derived from BIP32 trees](https://eips.ethereum.org/EIPS/eip-1581) +[EIP-1581: Non-wallet usage of keys derived from BIP-32 trees](./eip-1581.md) * state channel application @@ -174,22 +174,22 @@ MetaMask team, Christian Lundkvist, Counterfactual team, Liam Horne, Erik Bryn, * [Issue 85](https://github.com/ethereum/EIPs/issues/85) -* [EIP600 Ethereum purpose allocation for Deterministic Wallets](https://eips.ethereum.org/EIPS/eip-600) +* [EIP-600 Ethereum purpose allocation for Deterministic Wallets](./eip-600.md) -* [EIP601 Ethereum hierarchy for deterministic wallets](https://eips.ethereum.org/EIPS/eip-601) +* [EIP-601 Ethereum hierarchy for deterministic wallets](./eip-601.md) ### Previous proposals and discussions related to app keys * [Meta: we should value privacy more](https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475) -* [EIP1102: Opt-in account exposure](https://eips.ethereum.org/EIPS/eip-1102) +* [EIP-1102: Opt-in account exposure](./eip-1102.md) -* [EIP1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +* [EIP-1581: Non-wallet usage of keys derived from BIP-32 trees](./eip-1581.md) -* [EIP1581: discussion](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) +* [EIP-1581: discussion](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) -* [SLIP13: Authentication using deterministic hierarchy](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) +* [SLIP-13: Authentication using deterministic hierarchy](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) ## Copyright diff --git a/EIPS/eip-1803.md b/EIPS/eip-1803.md index 448ccbcc62d87..e3b5f20672ced 100644 --- a/EIPS/eip-1803.md +++ b/EIPS/eip-1803.md @@ -34,8 +34,7 @@ Not applicable. ## References -[EIP-6](https://eips.ethereum.org/EIPS/eip-6) previously renamed `SUICIDE` (`0xff`) to `SELFDESTRUCT`. -Renaming `SHA3` was previously proposed by [EIP-59](https://github.com/ethereum/EIPs/issues/59). +[EIP-6](./eip-6.md) previously renamed `SUICIDE` (`0xff`) to `SELFDESTRUCT`. ## Copyright diff --git a/EIPS/eip-1812.md b/EIPS/eip-1812.md index 29ddeff3feaff..fddd50a13dffa 100644 --- a/EIPS/eip-1812.md +++ b/EIPS/eip-1812.md @@ -14,10 +14,10 @@ requires: 712 ## Simple Summary -Reusable Verifiable Claims using [EIP 712 Signed Typed Data](https://eips.ethereum.org/EIPS/eip-712). +Reusable Verifiable Claims using [EIP 712 Signed Typed Data](./eip-712.md). ## Abstract -A new method for Off-Chain Verifiable Claims built on [EIP 712](https://eips.ethereum.org/EIPS/eip-712). These Claims can be issued by any user with a EIP 712 compatible web3 provider. Claims can be stored off chain and verified on-chain by Solidity Smart Contracts, State Channel Implementations or off-chain libraries. +A new method for Off-Chain Verifiable Claims built on [EIP 712](./eip-712.md). These Claims can be issued by any user with a EIP 712 compatible web3 provider. Claims can be stored off chain and verified on-chain by Solidity Smart Contracts, State Channel Implementations or off-chain libraries. ## Motivation Reusable Off-Chain Verifiable Claims provide an important piece of integrating smart contracts with real world organizational requirements such as meeting regulatory requirements such as KYC, GDPR, Accredited Investor rules etc. @@ -30,7 +30,7 @@ The W3C [Verifiable Claims Data Model and Representations](https://www.w3.org/TR While built on industry standards such as [JSON-LD](https://json-ld.org) and [JWT](https://jwt.io) neither of them are easy to integrate with the Ethereum ecosystem. -[EIP 712](https://eips.ethereum.org/EIPS/eip-712) introduces a new method of signing off chain Identity data. This provides both a data format based on Solidity ABI encoding that can easily be parsed on-chain an a new JSON-RPC call that is easily supported by existing Ethereum wallets and Web3 clients. +[EIP 712](./eip-712.md) introduces a new method of signing off chain Identity data. This provides both a data format based on Solidity ABI encoding that can easily be parsed on-chain an a new JSON-RPC call that is easily supported by existing Ethereum wallets and Web3 clients. This format allows reusable off-chain Verifiable Claims to be cheaply issued to users, who can present them when needed. diff --git a/EIPS/eip-1820.md b/EIPS/eip-1820.md index c4f5c2e7a44ea..89823809f3326 100644 --- a/EIPS/eip-1820.md +++ b/EIPS/eip-1820.md @@ -102,7 +102,7 @@ interface ERC1820ImplementerInterface { /// @title ERC1820 Pseudo-introspection Registry Contract /// @author Jordi Baylina and Jacques Dafflon /// @notice This contract is the official implementation of the ERC1820 Registry. -/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-1820 +/// @notice For more details, see ./eip-1820.md contract ERC1820Registry { /// @notice ERC165 Invalid ID. bytes4 constant internal INVALID_ID = 0xffffffff; @@ -634,7 +634,7 @@ The contract has the address above for every chain on which it is deployed. "notice": "Updates the cache with whether the contract implements an ERC165 interface or not." } }, - "notice": "This contract is the official implementation of the ERC1820 Registry.For more details, see https://eips.ethereum.org/EIPS/eip-1820" + "notice": "This contract is the official implementation of the ERC1820 Registry.For more details, see ./eip-1820.md" } }, "settings": { @@ -651,7 +651,7 @@ The contract has the address above for every chain on which it is deployed. }, "sources": { "./contracts/ERC1820Registry.sol": { - "content": "/* ERC1820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address (contract or regular account) can\n * register which interface it supports and which smart contract is responsible for its implementation.\n *\n * Written in 2019 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to\n * this software to the public domain worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see\n * .\n *\n * ███████╗██████╗ ██████╗ ██╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝███║██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚██║╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██║██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗ ██║╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.5.3;\n// IV is value needed to have a vanity address starting with '0x1820'.\n// IV: 53759\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC1820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface 'interfaceHash' for the address 'addr' or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC1820_ACCEPT_MAGIC only if the contract implements 'interfaceHash' for the address 'addr'.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n\n/// @title ERC1820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC1820 Registry.\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-1820\ncontract ERC1820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant internal INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant internal ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC1820_ACCEPT_MAGIC\"));\n\n /// @notice mapping from addresses and interface hashes to their implementers.\n mapping(address => mapping(bytes32 => address)) internal interfaces;\n /// @notice mapping from addresses to their manager.\n mapping(address => address) internal managers;\n /// @notice flag for each address and erc165 interface to indicate if it is cached.\n mapping(address => mapping(bytes4 => bool)) internal erc165Cached;\n\n /// @notice Indicates a contract is the 'implementer' of 'interfaceHash' for 'addr'.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates 'newManager' is the address of the new manager for 'addr'.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @return The address of the contract which implements the interface '_interfaceHash' for '_addr'\n /// or '0' if '_addr' did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == address(0) ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : address(0);\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address for which to set the interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @param _implementer Contract address implementing '_interfaceHash' for '_addr'.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == address(0) ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be an ERC165 hash\");\n if (_implementer != address(0) && _implementer != msg.sender) {\n require(\n ERC1820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC1820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets '_newManager' as manager for '_addr'.\n /// The new manager will be able to call 'setInterfaceImplementer' for '_addr'.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.)\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? address(0) : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == address(0)) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string calldata _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(\n _contract, _interfaceId) ? _contract : address(0);\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n // If the result is not cached a direct lookup on the contract address is performed.\n // If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling\n // 'updateERC165Cache' with the contract address.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = noThrowCall(_contract, ERC165ID);\n if (success == 0 || result == 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, INVALID_ID);\n if (success == 0 || result != 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, _interfaceId);\n if (success == 1 && result == 1) {\n return true;\n }\n return false;\n }\n\n /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return True if '_interfaceHash' is an ERC165 interface (ending with 28 zeroes), false otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\n bytes4 erc165ID = ERC165ID;\n\n assembly {\n let x := mload(0x40) // Find empty storage location using \"free memory pointer\"\n mstore(x, erc165ID) // Place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // To addr\n x, // Inputs are stored at location x\n 0x24, // Inputs are 36 (4 + 32) bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n", + "content": "/* ERC1820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address (contract or regular account) can\n * register which interface it supports and which smart contract is responsible for its implementation.\n *\n * Written in 2019 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright and related and neighboring rights to\n * this software to the public domain worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along with this software. If not, see\n * .\n *\n * ███████╗██████╗ ██████╗ ██╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝███║██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚██║╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██║██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗ ██║╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.5.3;\n// IV is value needed to have a vanity address starting with '0x1820'.\n// IV: 53759\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC1820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface 'interfaceHash' for the address 'addr' or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC1820_ACCEPT_MAGIC only if the contract implements 'interfaceHash' for the address 'addr'.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n\n/// @title ERC1820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC1820 Registry.\n/// @notice For more details, see ./eip-1820.md\ncontract ERC1820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant internal INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant internal ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant internal ERC1820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC1820_ACCEPT_MAGIC\"));\n\n /// @notice mapping from addresses and interface hashes to their implementers.\n mapping(address => mapping(bytes32 => address)) internal interfaces;\n /// @notice mapping from addresses to their manager.\n mapping(address => address) internal managers;\n /// @notice flag for each address and erc165 interface to indicate if it is cached.\n mapping(address => mapping(bytes4 => bool)) internal erc165Cached;\n\n /// @notice Indicates a contract is the 'implementer' of 'interfaceHash' for 'addr'.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates 'newManager' is the address of the new manager for 'addr'.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @return The address of the contract which implements the interface '_interfaceHash' for '_addr'\n /// or '0' if '_addr' did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == address(0) ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : address(0);\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address for which to set the interface.\n /// (If '_addr' is the zero address then 'msg.sender' is assumed.)\n /// @param _interfaceHash Keccak256 hash of the name of the interface as a string.\n /// E.g., 'web3.utils.keccak256(\"ERC777TokensRecipient\")' for the 'ERC777TokensRecipient' interface.\n /// @param _implementer Contract address implementing '_interfaceHash' for '_addr'.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == address(0) ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be an ERC165 hash\");\n if (_implementer != address(0) && _implementer != msg.sender) {\n require(\n ERC1820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC1820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets '_newManager' as manager for '_addr'.\n /// The new manager will be able to call 'setInterfaceImplementer' for '_addr'.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for 'addr'. (Pass '0x0' to reset the manager to '_addr'.)\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? address(0) : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == address(0)) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string calldata _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(\n _contract, _interfaceId) ? _contract : address(0);\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n // If the result is not cached a direct lookup on the contract address is performed.\n // If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling\n // 'updateERC165Cache' with the contract address.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return True if '_contract' implements '_interfaceId', false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = noThrowCall(_contract, ERC165ID);\n if (success == 0 || result == 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, INVALID_ID);\n if (success == 0 || result != 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, _interfaceId);\n if (success == 1 && result == 1) {\n return true;\n }\n return false;\n }\n\n /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return True if '_interfaceHash' is an ERC165 interface (ending with 28 zeroes), false otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\n bytes4 erc165ID = ERC165ID;\n\n assembly {\n let x := mload(0x40) // Find empty storage location using \"free memory pointer\"\n mstore(x, erc165ID) // Place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // To addr\n x, // Inputs are stored at location x\n 0x24, // Inputs are 36 (4 + 32) bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n", "keccak256": "0x64025ecebddb6e126a5075c1fd6c01de2840492668e2909cef7157040a9d1945" } }, @@ -908,11 +908,11 @@ The implementation is available in the repo: [0xjac/ERC1820]. ## Copyright Copyright and related rights waived via [CC0]. -[EIP155]: https://eips.ethereum.org/EIPS/eip-155 -[ERC165]: https://eips.ethereum.org/EIPS/eip-165 +[EIP155]: ./eip-155.md +[ERC165]: ./eip-165.md [ERC672]: https://github.com/ethereum/EIPs/issues/672 -[ERC820]: https://eips.ethereum.org/EIPS/eip-820 -[ERC1820]: https://eips.ethereum.org/EIPS/eip-1820 +[ERC820]: ./eip-820.md +[ERC1820]: ./eip-1820.md [ERC1820 registry smart contract]: https://github.com/0xjac/ERC1820/blob/master/contracts/ERC1820Registry.sol [erc1820-annoucement]: https://github.com/ethereum/EIPs/issues/820#issuecomment-464109166 [erc820-bug]: https://github.com/ethereum/EIPs/issues/820#issuecomment-452465748 diff --git a/EIPS/eip-1829.md b/EIPS/eip-1829.md index 07a0e3b7cb6b5..032ec912734b2 100644 --- a/EIPS/eip-1829.md +++ b/EIPS/eip-1829.md @@ -107,9 +107,8 @@ TODO: The special cases for `α` and `β` might be worth implementing and offere **Linear Combination.** We could instead have a simple multiply `C = r ⋅ A`. In this case we would need a separate pre-compile for addition. In addition, a linear combination allows for optimizations that like Shamir's trick that are not available in a single scalar multiplication. ECDSA requires `s₀ ⋅ A₀ + s₁ ⋅ A₁` and would benefit from this. -The BN254 (aka alt_bn8) multiplication operation introduced by the [EIP-196][eip196] precompile only handles a single scalar multiplication. The missed performance is such that for two or more points it is cheaper to use EVM, as practically demonstrated by [Weierstrudel][ws]. +The BN254 (aka alt_bn8) multiplication operation introduced by the [EIP-196](./eip-196.md) precompile only handles a single scalar multiplication. The missed performance is such that for two or more points it is cheaper to use EVM, as practically demonstrated by [Weierstrudel][ws]. -[eip196]: https://eips.ethereum.org/EIPS/eip-196 [ws]: https://medium.com/aztec-protocol/huffing-for-crypto-with-weierstrudel-9c9568c06901 **Variable Time Math.** When called during a transaction, there is no assumption of privacy and no mitigations for side-channel attacks are necessary. @@ -140,10 +139,10 @@ The reference implementation will be production grade and compile to a native li This EIP overlaps in scope with -* [EIP-196](https://eips.ethereum.org/EIPS/eip-196): ecadd, ecmul for altbn128 +* [EIP-196](./eip-196.md): ecadd, ecmul for altbn128 * [EIP issue 603](https://github.com/ethereum/EIPs/issues/603): ecadd, ecmul for SECP256k1. -* [EIP 665](https://eips.ethereum.org/EIPS/eip-665): ECDSA verify for ED25519. -* [EIP 1108](https://eips.ethereum.org/EIPS/eip-1108): Optimize ecadd and ecmul for altbn128. +* [EIP 665](./eip-665.md): ECDSA verify for ED25519. +* [EIP 1108](./eip-1108.md): Optimize ecadd and ecmul for altbn128. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-1884.md b/EIPS/eip-1884.md index f2baec0f91d53..df7ae675c325b 100644 --- a/EIPS/eip-1884.md +++ b/EIPS/eip-1884.md @@ -59,14 +59,14 @@ It can be seen that `storage_reads` and `account_reads` are the two most signifi ### `SLOAD` -`SLOAD` was repriced at [EIP-150][eip-150], from `50` to `200`. +`SLOAD` was repriced at [EIP-150](./eip-150.md), from `50` to `200`. The following graph shows a go-ethereum full sync, where each data point represents 10K blocks. During those 10K blocks, the execution time for the opcode was aggregated. ![graph](../assets/eip-1884/SLOAD-run3.png) -It can be seen that the repricing at [EIP-150][eip-150] caused a steep drop, from around `67` to `23`. -Around block `5M`, it started reaching pre-[EIP-150][eip-150] levels, and at block `7M` +It can be seen that the repricing at [EIP-150](./eip-150.md) caused a steep drop, from around `67` to `23`. +Around block `5M`, it started reaching pre-[EIP-150](./eip-150.md) levels, and at block `7M` it was averaging on around `150` - more than double pre-eip-150 levels. Increasing the cost of `SLOAD` by `4` would bring it back down to around `40`. @@ -75,7 +75,7 @@ state clearing efforts are implemented before that happens. ### `BALANCE` -`BALANCE` (a.k.a `EXTBALANCE`) is an operation which fetches data from the state trie. It was repriced at [EIP-150][eip-150] from `20` to `400`. +`BALANCE` (a.k.a `EXTBALANCE`) is an operation which fetches data from the state trie. It was repriced at [EIP-150](./eip-150.md) from `20` to `400`. ![graph](../assets/eip-1884/BALANCE-run3.png) @@ -94,7 +94,7 @@ opcodes: `EXTBALANCE(address)` and `SELFBALANCE`, and have two different prices. ### `EXTCODEHASH` -`EXTCODEHASH` was introduced in Constantinople, with [EIP-1052](https://eips.ethereum.org/EIPS/eip-1052). It was priced at `400` with the reasoning: +`EXTCODEHASH` was introduced in Constantinople, with [EIP-1052](./eip-1052.md). It was priced at `400` with the reasoning: > The gas cost is the same as the gas cost for the `BALANCE` opcode because the execution of the `EXTCODEHASH` requires the same account lookup as in `BALANCE`. @@ -108,7 +108,7 @@ The changes require a hardfork. The changes have the following consequences: - Certain calls will become more expensive. - Default-functions which access the storage and may in some cases require more than`2300` gas (the minimum gas that is always available in calls). - Contracts that assume a certain fixed gas cost for calls (or internal sections) may cease to function. - - A fixed gas cost is specified in [ERC-165](https://eips.ethereum.org/EIPS/eip-165) and implementations of this interface do use the affected opcodes. + - A fixed gas cost is specified in [ERC-165](./eip-165.md) and implementations of this interface do use the affected opcodes. - The ERC-165 method `supportsInterface` must return a `bool` and use at most `30,000` gas. - The two example implementations from the EIP were, at the time of writing 1. `586` gas for any input, and @@ -156,5 +156,3 @@ func opSelfBalance(pc *uint64, interpreter *EVMInterpreter, contract *Contract, ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - -[eip-150]: https://eips.ethereum.org/EIPS/eip-150 diff --git a/EIPS/eip-1898.md b/EIPS/eip-1898.md index 0d6ade6c5c64f..8a387deddcaae 100644 --- a/EIPS/eip-1898.md +++ b/EIPS/eip-1898.md @@ -15,7 +15,7 @@ For JSON-RPC methods which currently accept a default block parameter, additiona ## Abstract -This EIP can be considered a generalization of [EIP-234](https://github.com/ethereum/EIPs/blob/d053eb66921c5915f3e16d72c7566289e2d7c151/EIPS/eip-234.md). It would enable clients to unambiguously specify the block they want to query for certain JSON-RPC methods, even if the block is not in the canonical chain. This allows clients to maintain a coherent picture of blockchain state that they are interested in, even in the presence of reorgs, without requiring that the node maintain a persistent connection with the client or store any client-specific state. +This EIP can be considered a generalization of [EIP-234](./eip-234.md). It would enable clients to unambiguously specify the block they want to query for certain JSON-RPC methods, even if the block is not in the canonical chain. This allows clients to maintain a coherent picture of blockchain state that they are interested in, even in the presence of reorgs, without requiring that the node maintain a persistent connection with the client or store any client-specific state. ## Specification diff --git a/EIPS/eip-190.md b/EIPS/eip-190.md index 4b7edca48cfcd..bf909700db3f2 100644 --- a/EIPS/eip-190.md +++ b/EIPS/eip-190.md @@ -31,7 +31,7 @@ A packaging standard should have the following positive effects on the ecosystem * Greater overall productivity caused by the ability to reuse existing code. * Increased security caused by the ability to reuse existing well audited implementations of common patterns (ERC20, crowdfunding, etc). -Smart contract packaging should also have a direct positive effect on the end user. Wallet software will be able to consume a released package and generate an interface for interacting with any deployed contracts included within that package. With the advent of [ENS](https://eips.ethereum.org/EIPS/eip-137) all of the pieces will be in place for a wallet to take a human readable name and present the user with an interface for interacting with the underlying application. +Smart contract packaging should also have a direct positive effect on the end user. Wallet software will be able to consume a released package and generate an interface for interacting with any deployed contracts included within that package. With the advent of [ENS](./eip-137.md) all of the pieces will be in place for a wallet to take a human readable name and present the user with an interface for interacting with the underlying application. # Specification diff --git a/EIPS/eip-1901.md b/EIPS/eip-1901.md index 7affe394e3f90..ffc22317ea5ae 100644 --- a/EIPS/eip-1901.md +++ b/EIPS/eip-1901.md @@ -20,7 +20,7 @@ This was first proposed [here as an ECIP](https://github.com/etclabscore/ECIPs/b ## Motivation -Although [EIP-1474](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1474.md) outlines a JSON-RPC specification. Ethereum still lacks a machine-readable JSON-RPC Specification that can be used as the industry standard for tooling. This proposal attempts to standardize such a specification in a way that is versionable, and both human and machine readable. +Although [EIP-1474](./eip-1474.md) outlines a JSON-RPC specification. Ethereum still lacks a machine-readable JSON-RPC Specification that can be used as the industry standard for tooling. This proposal attempts to standardize such a specification in a way that is versionable, and both human and machine readable. Ethereum clients can expose RPC endpoints with different method signatures and cause compatibility issues between clients. diff --git a/EIPS/eip-191.md b/EIPS/eip-191.md index f3b79ae5ba8bb..d419a1adb3feb 100644 --- a/EIPS/eip-191.md +++ b/EIPS/eip-191.md @@ -50,12 +50,9 @@ Using `0x19` thus makes it possible to extend the scheme by defining a version ` | Version byte | EIP | Description | ------------ | -------------- | ----------- -| `0x00` | [191][eip-191] | Data with intended validator -| `0x01` | [712][eip-712] | Structured data -| `0x45` | [191][eip-191] | `personal_sign` messages - -[eip-191]: https://eips.ethereum.org/EIPS/eip-191 -[eip-712]: https://eips.ethereum.org/EIPS/eip-712 +| `0x00` | [EIP-191](./eip-191.md) | Data with intended validator +| `0x01` | [EIP-712](./eip-712.md) | Structured data +| `0x45` | [EIP-191](./eip-191.md) | `personal_sign` messages ### Example diff --git a/EIPS/eip-1921.md b/EIPS/eip-1921.md index 29ad1312cd2ac..8c530a056e3d1 100644 --- a/EIPS/eip-1921.md +++ b/EIPS/eip-1921.md @@ -11,11 +11,11 @@ requires: 1900 --- ## Simple Summary -In the context of dType, the Decentralized Type System described in [EIP-1900](https://eips.ethereum.org/EIPS/eip-1900), we are proposing to add support for registering functions (with a preference for `pure` and `view`) in the dType Registry. +In the context of dType, the Decentralized Type System described in [EIP-1900](./eip-1900.md), we are proposing to add support for registering functions (with a preference for `pure` and `view`) in the dType Registry. ## Abstract -This proposal is part of a series of EIPs focused on expanding the concept of a Decentralized Type System, as explained in [EIP-1900](https://eips.ethereum.org/EIPS/eip-1900). +This proposal is part of a series of EIPs focused on expanding the concept of a Decentralized Type System, as explained in [EIP-1900](./eip-1900.md). The current EIP specifies the data definitions and interfaces needed to support registering individual smart contract functions, as entries in the dType Registry. ## Motivation @@ -25,7 +25,7 @@ This implies having access to all the data needed to run the function inside the Aside from the above motivation, there are also near future benefits for this proposal. Having a globally available, non-custodial functions registry, will democratize the development of tools, such as those targeting: blockchain data analysis (e.g. block explorers), smart contract IDEs, security analysis of smart contracts. -Registering new smart contract functions can be done through the same consensus mechanism as [EIP-1900](https://eips.ethereum.org/EIPS/eip-1900) mentions, in order to avoid burdening the chain state with redundant or improper records. +Registering new smart contract functions can be done through the same consensus mechanism as [EIP-1900](./eip-1900.md) mentions, in order to avoid burdening the chain state with redundant or improper records. ## Specification diff --git a/EIPS/eip-1922.md b/EIPS/eip-1922.md index 37b01be376d05..aa6d0810699b2 100644 --- a/EIPS/eip-1922.md +++ b/EIPS/eip-1922.md @@ -167,12 +167,12 @@ Detailed example implementations and Truffle tests of these example implementati **Standards** -1. ERC-20 Token Standard. https://eips.ethereum.org/EIPS/eip-20 +1. ERC-20 Token Standard. ./eip-20.md -1. ERC-165 Standard Interface Detection. https://eips.ethereum.org/EIPS/eip-165 -1. ERC-173 Contract Ownership Standard (DRAFT). https://eips.ethereum.org/EIPS/eip-173 -1. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. https://eips.ethereum.org/EIPS/eip-196 -1. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. https://eips.ethereum.org/EIPS/eip-197 +1. ERC-165 Standard Interface Detection. ./eip-165.md +1. ERC-173 Contract Ownership Standard (DRAFT). ./eip-173.md +1. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. ./eip-196.md +1. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. ./eip-197.md 1. Ethereum Name Service (ENS). https://ens.domains 1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt diff --git a/EIPS/eip-1923.md b/EIPS/eip-1923.md index bf858c76936d6..2e2fc46591ca6 100644 --- a/EIPS/eip-1923.md +++ b/EIPS/eip-1923.md @@ -120,12 +120,12 @@ Detailed example implementations and Truffle tests of these example implementati **Standards** -1. ERC-20 Token Standard. https://eips.ethereum.org/EIPS/eip-20 +1. ERC-20 Token Standard. ./eip-20.md -1. ERC-165 Standard Interface Detection. https://eips.ethereum.org/EIPS/eip-165 -2. ERC-173 Contract Ownership Standard (DRAFT). https://eips.ethereum.org/EIPS/eip-173 -3. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. https://eips.ethereum.org/EIPS/eip-196 -4. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. https://eips.ethereum.org/EIPS/eip-197 +1. ERC-165 Standard Interface Detection. ./eip-165.md +2. ERC-173 Contract Ownership Standard (DRAFT). ./eip-173.md +3. ERC-196 Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. ./eip-196.md +4. ERC-197 Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. ./eip-197.md 5. Ethereum Name Service (ENS). https://ens.domains 6. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt diff --git a/EIPS/eip-1930.md b/EIPS/eip-1930.md index 9c20100888fe6..162704ffbd914 100644 --- a/EIPS/eip-1930.md +++ b/EIPS/eip-1930.md @@ -19,7 +19,7 @@ The current CALL, DELEGATE_CALL, STATIC_CALL opcode do not enforce the gas being This is for example the case for meta-transaction where the contract needs to ensure the call is executed exactly as the signing user intended. -But this is also the case for common use cases, like checking "on-chain" if a smart contract support a specific interface (via [EIP-165](https://eips.ethereum.org/EIPS/eip-165) for example). +But this is also the case for common use cases, like checking "on-chain" if a smart contract support a specific interface (via [EIP-165](./eip-165.md) for example). The solution presented here is to add new call semantic that enforce the amount of gas specified : the call either proceed with the exact amount of gas or do not get executed and the current call revert. @@ -58,7 +58,7 @@ Its main benefit though is that it does not require extra opcodes. #### strict gas semantic -To be precise, regarding the strict gas semantic, based on [EIP-150](https://eips.ethereum.org/EIPS/eip-150), the current call must revert unless G >= I x 64/63 where G is gas left at the point of call (after deducing the cost of the call itself) and I is the gas specified. +To be precise, regarding the strict gas semantic, based on [EIP-150](./eip-150.md), the current call must revert unless G >= I x 64/63 where G is gas left at the point of call (after deducing the cost of the call itself) and I is the gas specified. So instead of ``` @@ -82,7 +82,7 @@ if !callCost.IsUint64() || gas < callCost.Uint64() { ### Rationale -Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](https://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](./eip-150.md) 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. @@ -90,9 +90,9 @@ But this is also true for simple use case, like checking if a contract implement 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 interpreting 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](https://eips.ethereum.org/EIPS/eip-150) behavior and the current gas pricing so closely. +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](./eip-150.md) behavior and the current gas pricing so closely. -This would also allow the behaviour of [EIP-150](https://eips.ethereum.org/EIPS/eip-150) to be changed without having to affect contract that require this strict gas behaviour. +This would also allow the behaviour of [EIP-150](./eip-150.md) 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 unnecessary extra gas to their signed message to avoid the possibility of losing funds. See https://github.com/gnosis/safe-contracts/issues/100 @@ -143,7 +143,7 @@ None fully implemented yet. But see Specifications for an example in geth. ## References -1. EIP-150, https://eips.ethereum.org/EIPS/eip-150 +1. EIP-150, ./eip-150.md ## Copyright diff --git a/EIPS/eip-1948.md b/EIPS/eip-1948.md index a944d69e164c3..4800d20e335b8 100644 --- a/EIPS/eip-1948.md +++ b/EIPS/eip-1948.md @@ -29,7 +29,7 @@ The proposal is made to standardize on tokens with dynamic data. Interactions wi ## Specification -An extension of [ERC721](https://eips.ethereum.org/EIPS/eip-721) interface with the following functions and events is suggested: +An extension of [ERC721](./eip-721.md) interface with the following functions and events is suggested: ``` solidity pragma solidity ^0.5.2; diff --git a/EIPS/eip-1959.md b/EIPS/eip-1959.md index 40af70b401ca7..36c9624734e1a 100644 --- a/EIPS/eip-1959.md +++ b/EIPS/eip-1959.md @@ -18,9 +18,9 @@ To protect off-chain messages from being reused across different chain, a mechan This EIP adds an opcode that returns whether the specific number passed in has been a valid chainID (EIP-155 unique identifier) in the history of the chain (including the current chainID). ## Motivation -[EIP-155](https://eips.ethereum.org/EIPS/eip-155) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](https://eips.ethereum.org/EIPS/eip-712). +[EIP-155](./eip-155.md) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](./eip-712.md). -[EIP-1344](https://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. +[EIP-1344](./eip-1344.md) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. ## Specification Adds a new opcode ```VALID_CHAINID``` at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainID to test. It will push ```0x1``` onto the stack if the uint256 value is part of the history (since genesis) of chainIDs of that chain, ```0x0``` otherwise. @@ -34,7 +34,7 @@ Note though that the alternative to keep track of old chainID is to implement a ## Rationale The only approach available today is to specify the chain ID at compile time. Using this approach will result in problems after a contentious hardfork as the contract can't accept message signed with a new chainID. -The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per [EIP-712](https://eips.ethereum.org/EIPS/eip-712) (with the previous chainID) will fails to be accepted by the contracts after the fork. +The approach proposed by EIP-1344 is to give access to the latest chainID. This is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainID happens, every L2 messages signed as per [EIP-712](./eip-712.md) (with the previous chainID) will fails to be accepted by the contracts after the fork. That's why in the rationale of EIP-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainID via a trustless cache implemented via smart contract. diff --git a/EIPS/eip-1962.md b/EIPS/eip-1962.md index 3ef97b10f9c8c..f5ede1e6eebea 100644 --- a/EIPS/eip-1962.md +++ b/EIPS/eip-1962.md @@ -12,7 +12,7 @@ requires: 1109 # Simple summary -This proposal is an extension and formalization of [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) with an inclusion of pairings. [EIP1109](https://eips.ethereum.org/EIPS/eip-1109) is required due to low cost of some operations compared to the `STATICCALL` opcode (more information in the corresponding section below). +This proposal is an extension and formalization of [EIP1829](./eip-1829.md) with an inclusion of pairings. [EIP1109](./eip-1109.md) is required due to low cost of some operations compared to the `STATICCALL` opcode (more information in the corresponding section below). ## Abstract @@ -31,14 +31,14 @@ Full functionality of the precompile is described below in `Specification` secti ## Motivation -- There is a pending proposal to implement base elliptic curve arithmetic is covered by [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) and will allow to implement various privacy-preserving protocols with a reasonable gas costs per operation. +- There is a pending proposal to implement base elliptic curve arithmetic is covered by [EIP1829](./eip-1829.md) and will allow to implement various privacy-preserving protocols with a reasonable gas costs per operation. - Pairings are an important extension for basic arithmetic and so this new precompile is proposed with the following benefits: - Extended set of curves will be available to allow Ethereum users to choose their security parameters and required functionality. - Generic approach of this precompile will allow Ethereum users to experiment with newly found curves of their choice and new constructions constructions without waiting for new forks. - EC arithmetic is indeed re-implemented in this precompile, but it's strictly required. Most of the pairing-based protocols still need to perform standard EC multiplications or additions and thus such operations must be available on generic set of curves. - Gas costs - this EIP is designed to estimate gas-cost of performed operation as early as possible during the call and base if solely on specified parameters and operation type. This is a strict requirement for any precompile to allow Ethereum nodes to efficiently reject transactions and operations as early as possible. -Functionality of this newly proposed precompile is different from [EIP1829](https://eips.ethereum.org/EIPS/eip-1829) in the following aspects: +Functionality of this newly proposed precompile is different from [EIP1829](./eip-1829.md) in the following aspects: - Operation on arbitrary-length modulus (up to some upper-limit) for a base field and scalar field of the curve - Pairing operations are introduced - Different ABI due to variable parameter length diff --git a/EIPS/eip-1965.md b/EIPS/eip-1965.md index 387d3bdb01510..89357acbd80f0 100644 --- a/EIPS/eip-1965.md +++ b/EIPS/eip-1965.md @@ -14,11 +14,11 @@ requires: 155 This EIP adds a precompile that returns whether a specific chainID (EIP-155 unique identifier) is valid at a specific blockNumber. ChainID are assumed to be valid up to the blockNumber at which they get replaced by a new chainID. ## Motivation -[EIP-155](https://eips.ethereum.org/EIPS/eip-155) proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using [EIP-712](https://eips.ethereum.org/EIPS/eip-712). +[EIP-155](./eip-155.md) proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using [EIP-712](./eip-712.md). -[EIP-1344](https://eips.ethereum.org/EIPS/eip-1344) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced. +[EIP-1344](./eip-1344.md) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced. -[EIP-1959](https://github.com/ethereum/EIPs/pull/1959) solves the issue of EIP-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it remove some freedom to fork. We consider that all fork should be given equal oportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.** +[EIP-1959](./eip-1959.md) solves the issue of EIP-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it remove some freedom to fork. We consider that all fork should be given equal oportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.** ## Specification Adds a new precompile which uses 2 argument : a 32 bytes value that represent the chainID to test and a 32 bytes value representing the blockNumber at which the chainID is tested. It return 0x1 if the chainID is valid at the specific blockNumber, 0x0 otherwise. Note that chainID are considered valid up to the blockNumber at which they are replaced. So they are valid for every blockNumber past their replacement. diff --git a/EIPS/eip-1967.md b/EIPS/eip-1967.md index e8bf6e113c364..3f8a057b69c7c 100644 --- a/EIPS/eip-1967.md +++ b/EIPS/eip-1967.md @@ -24,7 +24,7 @@ However, the lack of a common interface for obtaining the logic address for a pr A classic example of this is a block explorer. Here, the end user wants to interact with the underlying logic contract and not the proxy itself. Having a common way to retrieve the logic contract address from a proxy would allow a block explorer, among other things, to show the ABI of the logic contract and not that of the proxy (see [this proxy](https://etherscan.io/token/0x00fdae9174357424a78afaad98da36fd66dd9e03#readContract) for an example). The explorer should check the storage of the contract at the distinguished slots to determine if it is indeed a proxy, in which case it should show information on both the proxy and the logic contract. -Another example are logic contracts that explicitly act upon the fact that they are being proxied. This allows them to potentially trigger a code update as part of their logic, as is the case of [Universal Upgradeable Proxy Standard (EIP1822)](https://eips.ethereum.org/EIPS/eip-1822). A common storage slot allows these use cases independently of the specific proxy implementation being used. +Another example are logic contracts that explicitly act upon the fact that they are being proxied. This allows them to potentially trigger a code update as part of their logic, as is the case of [Universal Upgradeable Proxy Standard (EIP1822)](./eip-1822.md). A common storage slot allows these use cases independently of the specific proxy implementation being used. ## Specification The main requirement for the storage slots chosen is that they must never be picked by the compiler to store any contract state variable. Otherwise, a logic contract could inadvertently overwrite this information on the proxy when writing to a variable of its own. @@ -51,7 +51,7 @@ Holds the address that is allowed to upgrade the logic contract address for this ## Rationale -This EIP standardises the **storage slot** for the logic contract address, instead of a public method on the proxy contract as [DelegateProxy (EIP897)](https://eips.ethereum.org/EIPS/eip-897) does. The rationale for this is that proxies should never expose functions to end users that could potentially clash with those of the logic contract. +This EIP standardises the **storage slot** for the logic contract address, instead of a public method on the proxy contract as [DelegateProxy (EIP897)](./eip-897.md) does. The rationale for this is that proxies should never expose functions to end users that could potentially clash with those of the logic contract. Note that a clash may occur even among functions with different names, since the ABI relies on just four bytes for the function selector. This can lead to unexpected errors, or even exploits, where a call to a proxied contract returns a different value than expected, since the proxy intercepts the call and answers with a value of its own. @@ -61,7 +61,7 @@ From [_Malicious backdoors in Ethereum proxies_](https://medium.com/nomic-labs-b > > Because the function selectors use a fixed amount of bytes, there will always be the possibility of a clash. This isn’t an issue for day to day development, given that the Solidity compiler will detect a selector clash within a contract, but this becomes exploitable when selectors are used for cross-contract interaction. Clashes can be abused to create a seemingly well-behaved contract that’s actually concealing a backdoor. -The fact that proxy public functions are potentially exploitable makes it necessary to standardise the logic contract address in a different way. This approach is also used as part of [Universal Upgradeable Proxy Standard (EIP1822)](https://eips.ethereum.org/EIPS/eip-1822), which could become a specialization of this EIP. +The fact that proxy public functions are potentially exploitable makes it necessary to standardise the logic contract address in a different way. This approach is also used as part of [Universal Upgradeable Proxy Standard (EIP1822)](./eip-1822.md), which could become a specialization of this EIP. ## Implementation Sample proxy implementations that follow this standard can be found in the [ZeppelinOS repository](https://github.com/zeppelinos/zos/blob/dc9e4ed/packages/lib/contracts/upgradeability/BaseUpgradeabilityProxy.sol), albeit with a different set of slots. diff --git a/EIPS/eip-1985.md b/EIPS/eip-1985.md index 95b940c2bda70..9b62be1f4e089 100644 --- a/EIPS/eip-1985.md +++ b/EIPS/eip-1985.md @@ -97,7 +97,7 @@ However, setting the limit `2^32 - 1` is beneficial from a VM design perspective ### Code size -[EIP-170](https://eips.ethereum.org/EIPS/eip-170) has implemented a code size limit of 0x6000, however even before that, it was practically impossible to deploy a code blob exceeding `2**32 - 1` bytes in size. +[EIP-170](./eip-170.md) has implemented a code size limit of 0x6000, however even before that, it was practically impossible to deploy a code blob exceeding `2**32 - 1` bytes in size. ### Comparing current implementations @@ -117,11 +117,6 @@ TBA TBA -## References - -- [EIP-92](https://github.com/ethereum/EIPs/issues/92) proposed the transaction gas limit to be limited at `2**63 - 1` and had a lengthy discussion about other limits. -- [EIP-106](https://github.com/ethereum/EIPs/issues/106) proposed the block gas limit to be limited at `2**63 - 1`. - ## TODO 1. Does the gas limit apply to the gas argument for call instructions? diff --git a/EIPS/eip-1996.md b/EIPS/eip-1996.md index 53cee83fae0a1..8043fa5c816e3 100644 --- a/EIPS/eip-1996.md +++ b/EIPS/eip-1996.md @@ -275,7 +275,7 @@ This standards provides a functionality, to guarantee future payments, which is It goes a step further than the ERC-20 `approve` function by ensuring that the held balance will be available when the transfer is done. Something that can not be done with `approve`, as the approved amount is only a maximum spending amount, but never guaranteed to be available. -While not requiring it, the naming of the functions `authorizeHoldOperator`, `revokeHoldOperator` and `isHoldOperatorFor` follows the naming convention of [ERC-777](https://eips.ethereum.org/EIPS/eip-777). +While not requiring it, the naming of the functions `authorizeHoldOperator`, `revokeHoldOperator` and `isHoldOperatorFor` follows the naming convention of [ERC-777](./eip-777.md). The `operationId` is a string and not something more gas efficient to allow easy traceability of the hold and allow human readable ids. It is up to the implementer if the string should be stored on-chain or only its hash, as it is enough to identify a hold. diff --git a/EIPS/eip-20-token-standard.md b/EIPS/eip-20-token-standard.md index b77c0de5b610d..c9773f2bc33b2 100644 --- a/EIPS/eip-20-token-standard.md +++ b/EIPS/eip-20-token-standard.md @@ -1 +1 @@ -Moved to [EIP 20](https://eips.ethereum.org/EIPS/eip-20). +Moved to [EIP 20](./eip-20.md). diff --git a/EIPS/eip-2003.md b/EIPS/eip-2003.md index c5ab43fa18435..bf35ffeef5b87 100644 --- a/EIPS/eip-2003.md +++ b/EIPS/eip-2003.md @@ -34,7 +34,7 @@ The EVMC module with implementations of precompiled contracts SHOULD: 1. The message kind ([`evmc_message::kind`]) is a call ([`EVMC_CALL`]). 2. The call destination address ([`evmc_message::destination`]) - is within the range of precompiled contracts defined by [EIP-1352]. + is within the range of precompiled contracts defined by [EIP-1352](./eip-1352.md). 3. There is no code provided (the `code` argument is `NULL` and `code_size` argument is `0`). @@ -99,7 +99,7 @@ EVMC provides the [evmc-vmtester] tool for checking compatibility with the EVMC - [EVMC – Ethereum Client-VM Connector API][EVMC] - [EVMC documentation] - [EVMC VM Implementation Guide][EVMC VM API] -- [EIP 1352: Specify restricted address range for precompiles/system contracts][EIP-1352] +- [EIP 1352: Specify restricted address range for precompiles/system contracts](./eip-1352) ## Copyright @@ -107,7 +107,6 @@ EVMC provides the [evmc-vmtester] tool for checking compatibility with the EVMC Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[EIP-1352]: https://eips.ethereum.org/EIPS/eip-1352 [EVMC]: https://github.com/ethereum/evmc [EVMC documentation]: https://ethereum.github.io/evmc/ [EVMC VM API]: https://ethereum.github.io/evmc/vmguide.html diff --git a/EIPS/eip-2009.md b/EIPS/eip-2009.md index 6374b55311d86..31ddc0a2fdd02 100644 --- a/EIPS/eip-2009.md +++ b/EIPS/eip-2009.md @@ -294,7 +294,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public [KYC-Wikipedia]: https://en.wikipedia.org/wiki/Know_your_customer [AML-Wikipedia]: https://en.wikipedia.org/wiki/Money_laundering#Anti-money_laundering -[ERC-777]: https://eips.ethereum.org/EIPS/eip-777 -[ERC-1066]: https://eips.ethereum.org/EIPS/eip-1066 -[ERC-1444]: https://eips.ethereum.org/EIPS/eip-1444 -[ERC-1462]: https://eips.ethereum.org/EIPS/eip-1462 +[ERC-777]: ./eip-777.md +[ERC-1066]: ./eip-1066.md +[ERC-1444]: ./eip-1444.md +[ERC-1462]: ./eip-1462.md diff --git a/EIPS/eip-2014.md b/EIPS/eip-2014.md index 918dcce09130e..d90b983626c85 100644 --- a/EIPS/eip-2014.md +++ b/EIPS/eip-2014.md @@ -20,7 +20,7 @@ This allows Ethereum contract languages to interact with this contract as if it ## Motivation -Over the past couple of years several proposals were made to extend the EVM with more data. Some examples include extended access to block hashes ([EIP-210]) and chain identifiers ([EIP-1344]). +Over the past couple of years several proposals were made to extend the EVM with more data. Some examples include extended access to block hashes ([EIP-210](./eip-210.md)) and chain identifiers ([EIP-1344](./eip-1344.md)). Adding them as EVM opcodes seems to be using the scarce opcode space for relatively less frequently used features, while adding them as precompiles is perceived as more complicated due to an interface needs to be defined and agreed on for every case. @@ -33,7 +33,7 @@ A new system contract ("precompile") is introduced at address `0x000000000000000 It can be queried using `CALL` or `STATICCALL` and follows the [Contract ABI Encoding] for the inputs and outputs. Using elementary types in the ABI encoding is encouraged to keep complexity low. -In the future it could be possible to extend ESO to have a state and accept transactions from a system address to store the passed data -- similarly to what [EIP-210] proposed. +In the future it could be possible to extend ESO to have a state and accept transactions from a system address to store the passed data -- similarly to what [EIP-210](./eip-210.md) proposed. Proposals wanting to introduce more data to the state, which is not part of blocks or transactions, should aim to extend the ESO. @@ -43,8 +43,8 @@ In the future if it is sufficiently extended and a need arises to have a state, ### Chain identifier Initially, a feature to read the current chain identifier is introduced: `getCurrentChainId()` returns the current chain identifier as a `uint64` encoded value. -It should be a non-payable function, which means sending any value would revert the transaction as described in [EIP-140]. -This has been proposed as [EIP-1344]. +It should be a non-payable function, which means sending any value would revert the transaction as described in [EIP-140](./eip-140.md). +This has been proposed as [EIP-1344](./eip-1344.md). The contract ABI JSON is the following: ```json @@ -68,7 +68,7 @@ The contract ABI JSON is the following: This will be translated into sending the bytes `5cf0e8a4` to the ESO and returning the bytes `0000000000000000000000000000000000000000000000000000000000000001` for Ethereum mainnet. -**Note:** It should be possible to introduce another interface checking the validity of a chain identifier in the chain history or for a given block (see [EIP-1959] and [EIP-1965]). +**Note:** It should be possible to introduce another interface checking the validity of a chain identifier in the chain history or for a given block (see [EIP-1959](./eip-1959.md) and [EIP-1965](./eip-1965.md)). ## Rationale @@ -90,8 +90,3 @@ TBA Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). [Contract ABI Encoding]: https://solidity.readthedocs.io/en/latest/abi-spec.html -[EIP-140]: https://eips.ethereum.org/EIPS/eip-140 -[EIP-210]: https://eips.ethereum.org/EIPS/eip-210 -[EIP-1344]: https://eips.ethereum.org/EIPS/eip-1344 -[EIP-1959]: https://github.com/ethereum/EIPs/pull/1959 -[EIP-1965]: https://github.com/ethereum/EIPs/pull/1965 diff --git a/EIPS/eip-2015.md b/EIPS/eip-2015.md index 7875f49016f2c..c7e2549c59eb1 100644 --- a/EIPS/eip-2015.md +++ b/EIPS/eip-2015.md @@ -17,7 +17,7 @@ Wallets can update the active chain when connected to a Dapp but not vice-versa, Dapp can request the Wallet to switch chains by providing the minimal parameters of `chainId`, `networkId`, `rpcUrl` and `nativeCurrency`. The Wallet will display a UI element to inform the user of this change. ## Motivation -Wallet and Dapp communication rely on the present provider that acts as middleware between the two. Using JSON-RPC methods, the Dapp is able to access not only the active accounts but also the active chain. With [EIP-1102](https://eips.ethereum.org/EIPS/eip-1102) we introduced the ability for Dapps to request access to the active accounts and the Wallet is able to provide a simple UI to inform the user of this action however the same is not currently possible for switching chains. The current pattern is to display some UI to request the user to switch chains within the Dapp, however this could be easily improved by triggering a UI from the Wallet side that can be approved or rejected by the user instead. +Wallet and Dapp communication rely on the present provider that acts as middleware between the two. Using JSON-RPC methods, the Dapp is able to access not only the active accounts but also the active chain. With [EIP-1102](./eip-1102.md) we introduced the ability for Dapps to request access to the active accounts and the Wallet is able to provide a simple UI to inform the user of this action however the same is not currently possible for switching chains. The current pattern is to display some UI to request the user to switch chains within the Dapp, however this could be easily improved by triggering a UI from the Wallet side that can be approved or rejected by the user instead. ## Specification The JSON RPC method will be part of `wallet_` namespaced methods which aim to improve the UX and interoperability between Dapps and Wallets. @@ -30,7 +30,7 @@ The JSON RPC method will be part of `wallet_` namespaced methods which aim to im ### Best Practices -- The Wallet should display a UI view similar to a [EIP-1102](https://eips.ethereum.org/EIPS/eip-1102) informing the user that the currently connected Dapp wants to switch to the specified chain. +- The Wallet should display a UI view similar to a [EIP-1102](./eip-1102.md) informing the user that the currently connected Dapp wants to switch to the specified chain. - the Wallet should default the rpcUrl to any existing endpoints matching a chainId known previously to the wallet, otherwise it will use the provided rpcUrl as a fallback. - the Wallet should call the rpcUrl with `net_version` and `eth_chainId` to verify the provided chainId and networkId match the responses from the rpcUrl - the Wallet should change all nativeCurrency symbols to the provided parameter diff --git a/EIPS/eip-2018.md b/EIPS/eip-2018.md index 75d72ee2b3738..3b3bada54b7a0 100644 --- a/EIPS/eip-2018.md +++ b/EIPS/eip-2018.md @@ -231,17 +231,17 @@ Emitted when an operator has been revoked from ordering transfers on behalf of a ## Rationale -This EIP uses [EIP-1996][EIP-1996] to hold the money after a transfer is ordered. A clearing agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token or not. +This EIP uses [EIP-1996](./eip-1996.md) to hold the money after a transfer is ordered. A clearing agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token or not. The `operationId` is a string and not something more gas efficient to allow easy traceability of the hold and allow human readable ids. It is up to the implementer if the string should be stored on-chain or only its hash, as it is enough to identify a hold. The `operationId` is a competitive resource. It is recommended, but not required, that the hold issuers used a unique prefix to avoid collisions. -While not requiring it, the naming of the functions `authorizeClearableTransferOperator`, `revokeClearableTransferOperator` and `isClearableTransferOperatorFor` follows the naming convention of [ERC-777](https://eips.ethereum.org/EIPS/eip-777). +While not requiring it, the naming of the functions `authorizeClearableTransferOperator`, `revokeClearableTransferOperator` and `isClearableTransferOperatorFor` follows the naming convention of [ERC-777](./eip-777.md). ## Backwards Compatibility -This EIP is fully backwards compatible as its implementation extends the functionality of [EIP-1996][EIP-1996]. +This EIP is fully backwards compatible as its implementation extends the functionality of [EIP-1996](./eip-1996.md). ## Implementation @@ -258,4 +258,3 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public [Clearing-Wikipedia]: https://en.wikipedia.org/wiki/Clearing_(finance) [KYC-Wikipedia]: https://en.wikipedia.org/wiki/Know_your_customer [AML-Wikipedia]: https://en.wikipedia.org/wiki/Money_laundering#Anti-money_laundering -[EIP-1996]: https://eips.ethereum.org/EIPS/eip-1996 diff --git a/EIPS/eip-2019.md b/EIPS/eip-2019.md index d4f05a2cff795..152bec120528e 100644 --- a/EIPS/eip-2019.md +++ b/EIPS/eip-2019.md @@ -252,4 +252,4 @@ This proposal has been collaboratively implemented by [adhara.io](https://adhara ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[ERC-20]: https://eips.ethereum.org/EIPS/eip-20 +[ERC-20]: ./eip-20.md diff --git a/EIPS/eip-2020.md b/EIPS/eip-2020.md index 94224224f2e44..24dbf6bcf5961 100644 --- a/EIPS/eip-2020.md +++ b/EIPS/eip-2020.md @@ -224,10 +224,10 @@ This proposal has been collaboratively implemented by [adhara.io](https://adhara ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[ERC-20]: https://eips.ethereum.org/EIPS/eip-20 -[ERC-1066]: https://eips.ethereum.org/EIPS/eip-1066 -[ERC-1462]: https://eips.ethereum.org/EIPS/eip-1462 -[ERC-1996]: https://eips.ethereum.org/EIPS/eip-1996 -[ERC-2018]: https://eips.ethereum.org/EIPS/eip-2018 -[ERC-2019]: https://eips.ethereum.org/EIPS/eip-2019 -[ERC-2021]: https://eips.ethereum.org/EIPS/eip-2021 +[ERC-20]: ./eip-20.md +[ERC-1066]: ./eip-1066.md +[ERC-1462]: ./eip-1462.md +[ERC-1996]: ./eip-1996.md +[ERC-2018]: ./eip-2018.md +[ERC-2019]: ./eip-2019.md +[ERC-2021]: ./eip-2021.md diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 416f7b5ae605f..02488175d52a5 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -129,7 +129,7 @@ Cancels a payout request. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | -| reason | The specific reason that explains why the payout request was rejected. [EIP-1066] codes can be used. | +| reason | The specific reason that explains why the payout request was rejected. [EIP-1066](./eip-1066.md) codes can be used. | #### processPayout @@ -163,7 +163,7 @@ Rejects a given operation with a reason. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request that has been executed. | -| reason | The specific reason that explains why the payout request was rejected. [EIP-1066] codes can be used | +| reason | The specific reason that explains why the payout request was rejected. [EIP-1066](./eip-1066.md) codes can be used | #### isApprovedToOrderPayout @@ -231,7 +231,7 @@ Emitted when an operator has rejected a payout request. | ---------|-------------| | orderer | The address of the payout request orderer. | | operationId | The unique ID to identify the payout. | -| reason | The specific reason that explains why the payout request was rejected. [EIP-1066] codes can be used | +| reason | The specific reason that explains why the payout request was rejected. [EIP-1066](./eip-1066.md) codes can be used | #### PayoutCancelled @@ -267,7 +267,7 @@ It's important to highlight that the token operator, need to process all payout Payout instruction format is open. ISO payment standard like is a good start point. -This EIP uses [EIP-1996] to hold the money after a payout is ordered. The token contract owner or agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the payout is executed or not. +This EIP uses [EIP-1996](./eip-1996.md) to hold the money after a payout is ordered. The token contract owner or agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the payout is executed or not. The `operationId` is a string and not something more gas efficient to allow easy traceability of the hold and allow human readable ids. It is up to the implementer if the string should be stored on-chain or only its hash, as it is enough to identify a hold. @@ -284,7 +284,3 @@ This proposal has been collaboratively implemented by [adhara.io](https://adhara ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - -[ERC-20]: https://eips.ethereum.org/EIPS/eip-20 -[EIP-1066]: https://eips.ethereum.org/EIPS/eip-1066 -[EIP-1996]: https://eips.ethereum.org/EIPS/eip-1996 diff --git a/EIPS/eip-2025.md b/EIPS/eip-2025.md index bc215c00a9e62..0b60e9f55a797 100644 --- a/EIPS/eip-2025.md +++ b/EIPS/eip-2025.md @@ -14,7 +14,7 @@ requires: 1890 Add `0.0055 ETH` per block for 18 months (A total of 17050 ETH) as a developer block reward reserved for funding specific Ethereum1.X working groups. The working groups are State rent (750k), Better sync (360k), Finality gadget (360k), Fee market (360k), Testing infrastructure (360k). Governance of the funds will be through a multisig of trusted individuals from the ecosystem including client teams, the foundation, and the community. -[EIP-1890](https://eips.ethereum.org/EIPS/eip-1890) proposes a mechanism to capture a portion of block rewards for sustainably funding ongoing network development. That EIP sets values and addresses to zero and so does not actually collect any rewards. This proposal is to explicitly set those values and begin collecting a portion of block rewards for 18 months in order to fund Ethereum 1.X working groups and organization efforts. This funding will be used to repay an initial loan provided by investors in the community funding this work with a small amount of interest. After 18 months the block reward would again reduce to zero. +[EIP-1890](./eip-1890.md) proposes a mechanism to capture a portion of block rewards for sustainably funding ongoing network development. That EIP sets values and addresses to zero and so does not actually collect any rewards. This proposal is to explicitly set those values and begin collecting a portion of block rewards for 18 months in order to fund Ethereum 1.X working groups and organization efforts. This funding will be used to repay an initial loan provided by investors in the community funding this work with a small amount of interest. After 18 months the block reward would again reduce to zero. ## Abstract diff --git a/EIPS/eip-2029.md b/EIPS/eip-2029.md index 3c8844c9e71c0..b6da59d61756d 100644 --- a/EIPS/eip-2029.md +++ b/EIPS/eip-2029.md @@ -35,7 +35,7 @@ Two alternative solutions were considered so far: 1. Extending the structure of the Ethereum state to introduce more fields, and hence change the way the state root is constructed. The main downside of this approach is the impact on the software what is currently coupled with the particular way the state root is constructed. Particularly it affects the software that deals with merkle proofs derived from the state root. -2. Extended State Oracle ([EIP-2014](https://eips.ethereum.org/EIPS/eip-2014)). Under such proposal, there will be a precompile contract with standardised interface, capable of returning +2. Extended State Oracle ([EIP-2014](./eip-2014.md)). Under such proposal, there will be a precompile contract with standardised interface, capable of returning current values of the counters. However, the actual data being returned by such oracle is not explicitly in the state, and is not Merkelised. It means that all the counters need to be added to the snapshots when the snapshot sync is perform, so they still present in the state, but implicitly. ## Backwards Compatibility diff --git a/EIPS/eip-2031.md b/EIPS/eip-2031.md index 9baee3c7c7af7..40de135a8f550 100644 --- a/EIPS/eip-2031.md +++ b/EIPS/eip-2031.md @@ -13,7 +13,7 @@ requires: 2029 ## Simple Summary Ethereum starts to track the number of transactions inside its state (for now, only number of transactions after this change is introduced, therefore it is called *Net* transaction count). -It is done by incrementing a storage slot in the special contract, called *State counter contract* ([EIP-2029](https://eips.ethereum.org/EIPS/eip-2029)). +It is done by incrementing a storage slot in the special contract, called *State counter contract* ([EIP-2029](./eip-2029.md)). ## Abstract It is part of the State Rent roadmap. This particular change makes any Ethereum transaction increment the transaction counter, which is a special storage slot diff --git a/EIPS/eip-2035.md b/EIPS/eip-2035.md index b4d0d900c1e00..81e469ad61f69 100644 --- a/EIPS/eip-2035.md +++ b/EIPS/eip-2035.md @@ -30,7 +30,7 @@ analysis, `SSTORE` is not considered, because its effect on the database accesse the block. Stateless clients approach to the contract storage will largely negate that latency because no database accesses will be required. Instead, bandwidth consumption goes up. There is emprical analysis (unpublished, but will be) suggesting that 1 uncached `SSTORE` or `SLOAD` adds at most 1 kB to the block proofs. At the current cost of data transmission (68 gas per byte), this translates to the increase of gas cost of both -operations by 69k gas. However, in light of proposal in [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028), the increase can be made much smaller. +operations by 69k gas. However, in light of proposal in [EIP-2028](./eip-2028.md), the increase can be made much smaller. ## Specification Not very formal at the moment, but will be formalised with more research and prototyping. Gas of operations `SLOAD` and `SSTORE` increases by `X` gas when the storage slots accessed (read by `SLOAD` or written by `SSTORE`) were not previously accessed (by another `SLOAD` or `SSTORE`) during the same transaction. @@ -39,11 +39,11 @@ Future variant (will be possible after the implementation of the *Gross contract depending on the size of the contract storage, i.e. `SLOAD` and `SSTORE` for smaller contracts will be cheaper. ## Rationale -[EIP-1884](https://eips.ethereum.org/EIPS/eip-1884) seeks to increase the gas cost of `SLOAD` but using a different justification +[EIP-1884](./eip-1884.md) seeks to increase the gas cost of `SLOAD` but using a different justification (latency of the execution as described in the Motivation). This EIP is likely to increase the cost of `SLOAD` by a larger amount, therefore partially (because EIP-1884 also proposed other increases) supersedes EIP-1884. -[EIP-2028](https://eips.ethereum.org/EIPS/eip-2028) describes the model that can be used for deciding the gas cost of data transmission. It is relevant +[EIP-2028](./eip-2028.md) describes the model that can be used for deciding the gas cost of data transmission. It is relevant because in the stateless client regime `SSTORE` and `SLOAD` operations add more data to be transmitted (as well as computation to verify the proofs). The main alternate design is the rent proportional to the size of the contract storage, which unfortunately introduces a serious griefing @@ -53,7 +53,7 @@ However, this approach is likely to be very expensive on the non-technical (ecos ## Backwards Compatibility This change is not backwards compatible and requires hard fork to be activated. There might also be an adverse effect of this change on the already deployed contract. It is expected that after this EIP and -[EIP-2026](https://eips.ethereum.org/EIPS/eip-2026) (rent prepayment for accounts), the recommendation will be made to raise the gas limit. This can somewhat dampen the +[EIP-2026](./eip-2026.md) (rent prepayment for accounts), the recommendation will be made to raise the gas limit. This can somewhat dampen the adverse effect of EIP. The most problematic cases would be with the contracts that assume certain gas costs of `SLOAD` and `SSTORE` and hard-code them in their internal gas computations. For others, the cost of interacting with the contract storage will rise and may make some dApps based on such interactions, non-viable. This is a trade off to avoid even bigger diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index ee3f998e59f1a..1b907af472bf6 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -13,7 +13,7 @@ created: 2019-05-17 According to recent benchmarks, EVM opcodes for computation (`ADD`, `SUB`, `MUL`, etc.) are generally overpriced relative to opcodes for storage I/O (`SLOAD`, `SSTORE`, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum. ## Motivation -The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035)[1](#eip2035), more research is needed on the potential effects of increasing the cost of storage opcodes). +The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in [EIP-2035](./eip-2035.md)[1](#eip2035), more research is needed on the potential effects of increasing the cost of storage opcodes). Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). @@ -111,7 +111,7 @@ TODO TODO ## References -1. [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035): Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs +1. [EIP-2035](./eip-2035.md): Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs 2. https://github.com/ewasm/benchmarking diff --git a/EIPS/eip-2046.md b/EIPS/eip-2046.md index ca35c7eefe8e8..91eaf8547879d 100644 --- a/EIPS/eip-2046.md +++ b/EIPS/eip-2046.md @@ -29,7 +29,7 @@ FIXME: extend this with recent reasoning about ECC repricings. ## Specification After block `HF` the `STATICCALL` (`0xfa`) instruction charges different basic gas cost (Gcall in [Yellow Paper]'s notation) depending on the destination address provided: -- for precompiles (address range as per [EIP-1352]) the cost is `40` +- for precompiles (address range as per [EIP-1352](./eip-1352.md)) the cost is `40` - for every other address the cost remains unchanged (`700`) ## Rationale @@ -37,7 +37,7 @@ After block `HF` the `STATICCALL` (`0xfa`) instruction charges different basic g Only the `STATICCALL` instruction was changed to reduce the impact of the change. This should not be a limiting factor, given precompiles (currently) do not have a state and cannot change the state. However, contracts created and deployed before Byzantium likely will not use `STATICCALL` and as a result this change will not reduce their costs. -Contrary to EIP-1109 gas reduction to `0` is not proposed. The cost `40` is kept as a cost representing the context switching needed. +Contrary to [EIP-1109](./eip-1109.md) gas reduction to `0` is not proposed. The cost `40` is kept as a cost representing the context switching needed. ## Backwards Compatibility @@ -54,7 +54,7 @@ TBA ## References -This has been previously suggested as part of [EIP-1109](https://github.com/ethereum/EIPs/pull/1109) and [EIP-1231](https://github.com/ethereum/EIPs/pull/1231). +This has been previously suggested as part of [EIP-1109](./eip-1109.md). However EIP-1109 was later changed to a very different approach. The author [has suggested to change EIP-1109](https://ethereum-magicians.org/t/eip-1109-remove-call-costs-for-precompiled-contracts/447/7). ## Acknowledgements @@ -66,4 +66,3 @@ Jordi Baylina (@jbaylina) and Matthew Di Ferrante (@mattdf) who have proposed th Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). [Yellow Paper]: https://github.com/ethereum/yellowpaper -[EIP-1352]: https://eips.ethereum.org/EIPS/eip-1352 diff --git a/EIPS/eip-2070.md b/EIPS/eip-2070.md index 876b9eef8d0a9..478b996d28dd5 100644 --- a/EIPS/eip-2070.md +++ b/EIPS/eip-2070.md @@ -24,13 +24,13 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Berl ### Accepted EIPs -- [EIP-2315](https://eips.ethereum.org/EIPS/eip-2315): Simple Subroutines for the EVM -- [EIP-2537](https://github.com/ethereum/EIPs/pull/2537): BLS12-381 curve operations +- [EIP-2315](./eip-2315.md): Simple Subroutines for the EVM +- [EIP-2537](./eip-2537.md): BLS12-381 curve operations ### Proposed EIPs -- [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles -- [EIP-2565](https://eips.ethereum.org/EIPS/eip-2565): Repricing of the EIP-198 ModExp precompile +- [EIP-2046](./eip-2046.md): Reduced gas cost for static calls made to precompiles +- [EIP-2565](./eip-2565.md): Repricing of the EIP-198 ModExp precompile ## Timeline diff --git a/EIPS/eip-2098.md b/EIPS/eip-2098.md index 38d2802d7e276..2a98c2a676a3b 100644 --- a/EIPS/eip-2098.md +++ b/EIPS/eip-2098.md @@ -50,7 +50,7 @@ used in Bitcoin.) Second, the top bit of the `s` parameters is **always** 0, due to the use of canonical signatures which flip the solution parity to prevent negative values, -which was introduced as [a constraint in Homestead](https://eips.ethereum.org/EIPS/eip-2). +which was introduced as [a constraint in Homestead](./eip-2.md). So, we can hijack the top bit in the `s` parameter to store the value of `v`, resulting in: diff --git a/EIPS/eip-2124.md b/EIPS/eip-2124.md index ff0d014deb1ab..3f8ee13b91fbe 100644 --- a/EIPS/eip-2124.md +++ b/EIPS/eip-2124.md @@ -16,7 +16,7 @@ Currently nodes in the Ethereum network try to find each other by establishing r To avoid this overhead, Ethereum needs a mechanism that can precisely identify whether a node will be useful, as early as possible. Such a mechanism requires a way to summarize chain configurations, as well as a way to disseminate said summaries in the network. -This proposal focuses only on the definition of said summary - a generally useful *fork identifier* - and it's validation rules, allowing it to be embedded into arbitrary network protocols (e.g. [discovery ENRs](https://eips.ethereum.org/EIPS/eip-778) or `eth/6x` handshakes). +This proposal focuses only on the definition of said summary - a generally useful *fork identifier* - and it's validation rules, allowing it to be embedded into arbitrary network protocols (e.g. [discovery ENRs](./eip-778.md) or `eth/6x` handshakes). ## Abstract diff --git a/EIPS/eip-2135.md b/EIPS/eip-2135.md index 181110035d7ea..12b475bd14592 100644 --- a/EIPS/eip-2135.md +++ b/EIPS/eip-2135.md @@ -54,7 +54,7 @@ The event notifies subscribers whoever are interested to learn an asset is being To keep it simple, this standard *intentionally* contains no functions or events related to creation of a consumable asset. This is because the creation of a consumable asset will need to make assumption of the nature of an actual use-case. If we see some common use-case of creation, we can have another follow up standard. -We also left out metadata associated to the consumables from the standard. If necessary, related metadata can be created with a separate metadata extension interface like [`ERC721Metadata`](https://eips.ethereum.org/EIPS/eip-721) +We also left out metadata associated to the consumables from the standard. If necessary, related metadata can be created with a separate metadata extension interface like [`ERC721Metadata`](./eip-721.md) ## Backwards Compatibility @@ -73,7 +73,7 @@ See [GitHub/xinbenlv/eip-2135/impl/test](https://github.com/xinbenlv/eip-2135/tr ## Reference ### Standards -- [ERC-721](https://eips.ethereum.org/EIPS/eip-721) +- [ERC-721](./eip-721.md) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-2193.md b/EIPS/eip-2193.md index a3be794f44f67..1d65946b60670 100644 --- a/EIPS/eip-2193.md +++ b/EIPS/eip-2193.md @@ -16,13 +16,13 @@ We are proposing Alias - a semantic standard for identifying on-chain resour ## Abstract -The dType Alias is a system for providing human-readable resource identifiers to on-chain content. A resource identifier is based on the type of data (identifier provided by dType, [EIP-1900](https://eips.ethereum.org/EIPS/eip-1900)) and the data content (identifier provided by a dType Storage Contract, [EIP-2157](https://eips.ethereum.org/EIPS/eip-2157)). It is a universal way of addressing content, supporting any type of data. +The dType Alias is a system for providing human-readable resource identifiers to on-chain content. A resource identifier is based on the type of data (identifier provided by dType, [EIP-1900](./eip-1900.md)) and the data content (identifier provided by a dType Storage Contract, [EIP-2157](./eip-2157.md)). It is a universal way of addressing content, supporting any type of data. ## Motivation -There are standards that currently address the need for attaching human-readable identifiers to Ethereum accounts, such as [EIP-137](https://eips.ethereum.org/EIPS/eip-137). These standards are an attempt to bring domain names to Ethereum, following the same format as DNS: `subdomain.domain.tld`. This leaf -> root format is unintuitive and contradicts the semantic meaning that `.` has in programming languages, which is a root -> leaf connection (e.g. in OOP, when accessing an object's property). A more intuitive and widely used approach is a root->leaf format, used in file browsers, hierarchical menus, and even in other decentralized systems, which give unique identifiers to resources (e.g. `0x56.Currency.TCoin` in [Libra](https://medium.com/r/?url=https%3A%2F%2Fdevelopers.libra.org). +There are standards that currently address the need for attaching human-readable identifiers to Ethereum accounts, such as [EIP-137](./eip-137.md). These standards are an attempt to bring domain names to Ethereum, following the same format as DNS: `subdomain.domain.tld`. This leaf -> root format is unintuitive and contradicts the semantic meaning that `.` has in programming languages, which is a root -> leaf connection (e.g. in OOP, when accessing an object's property). A more intuitive and widely used approach is a root->leaf format, used in file browsers, hierarchical menus, and even in other decentralized systems, which give unique identifiers to resources (e.g. `0x56.Currency.TCoin` in [Libra](https://medium.com/r/?url=https%3A%2F%2Fdevelopers.libra.org). -Moreover, [EIP-137](https://eips.ethereum.org/EIPS/eip-137) is not flexible enough to address smart contract content, which can contain heterogeneous data that belongs to various accounts. For example, a `PaymentChannel` smart contract can have an domain name. However, the `Alice-Bob` channel data from inside the smart contract, cannot have a subdomain name. Having uniquely identified, granular resources opens the way to creating both human and machine-readable protocols on top of Ethereum. It also provides a basis for protocols based on functional programming. +Moreover, [EIP-137](./eip-137.md) is not flexible enough to address smart contract content, which can contain heterogeneous data that belongs to various accounts. For example, a `PaymentChannel` smart contract can have an domain name. However, the `Alice-Bob` channel data from inside the smart contract, cannot have a subdomain name. Having uniquely identified, granular resources opens the way to creating both human and machine-readable protocols on top of Ethereum. It also provides a basis for protocols based on functional programming. This ERC proposes a set of separators which maintain their semantic meaning and provides a way to address any type of resource - from Ethereum addresses, to individual `struct` instances inside smart contracts. @@ -34,7 +34,7 @@ This alias system can be used off-chain, to replace the old DNS system with a de The dType registry will provide domain and subdomain names for the resource type. Subdomains can be attributed recursively, to dType types which contain other complex types in their composition. We define an `Alias` registry contract, that keeps track of the human-readable identifiers for data resources, which exist in dType storage contracts. -Anyone can set an alias in the `Alias` registry, as long as the Ethereum address that signs the alias data has ownership on the resource, in the dType storage contract. Storage contract data ownership will be detailed in [EIP-2157](https://eips.ethereum.org/EIPS/eip-2157). An owner can update or delete an alias at any time. +Anyone can set an alias in the `Alias` registry, as long as the Ethereum address that signs the alias data has ownership on the resource, in the dType storage contract. Storage contract data ownership will be detailed in [EIP-2157](./eip-2157.md). An owner can update or delete an alias at any time. ```solidity interface Alias { @@ -58,7 +58,7 @@ interface Alias { - `signature`: Alias owner signature on `dtypeIdentifier`, `identifier`, `name`, `separator`, `nonce`, `aliasAddress`, `chainId`. - `nonce`: monotonically increasing counter, used to prevent replay attacks - `aliasAddress`: Ethereum address of `Alias` contract - - `chainId`: chain on which the `Alias` contract is deployed, as detailed in [EIP-155](https://eips.ethereum.org/EIPS/eip-155), used to prevent replay attacks when updating the `identifier` for an alias. + - `chainId`: chain on which the `Alias` contract is deployed, as detailed in [EIP-155](./eip-155.md), used to prevent replay attacks when updating the `identifier` for an alias. Content addressability can be done: - using the `bytes32` identifiers directly, e.g. `0x0b5e76559822448f6243a6f76ac7864eba89c810084471bdee2a63429c92d2e7@0x9dbb9abe0c47484c5707699b3ceea23b1c2cca2ac72681256ab42ae01bd347da` @@ -69,9 +69,9 @@ Both of the above examples will resolve to the same content. ## Rationale -Current attempts to solve content addressability, such as [EIP-137](https://eips.ethereum.org/EIPS/eip-137), only target Ethereum accounts. These are based on inherited concepts from HTTP and DNS, which are not machine friendly. +Current attempts to solve content addressability, such as [EIP-137](./eip-137.md), only target Ethereum accounts. These are based on inherited concepts from HTTP and DNS, which are not machine friendly. -With [EIP-1900](https://eips.ethereum.org/EIPS/eip-1900) and [EIP-2157](https://eips.ethereum.org/EIPS/eip-2157), general content addressability can be achieved. dType provides type information and a reference to the smart contract where the type instances are stored. Additionally, Alias uses the semantic meaning of subdomain separators to have a [intuitive order rule](https://github.com/loredanacirstea/articles/blob/master/articles/Flexible_Alias_or_Why_ENS_is_Obsolete.md). +With [EIP-1900](./eip-1900.md) and [EIP-2157](./eip-2157.md), general content addressability can be achieved. dType provides type information and a reference to the smart contract where the type instances are stored. Additionally, Alias uses the semantic meaning of subdomain separators to have a [intuitive order rule](https://github.com/loredanacirstea/articles/blob/master/articles/Flexible_Alias_or_Why_ENS_is_Obsolete.md). Multiple aliases can be assigned to a single resource. Either by using a different `name` or by using a different `separator`. Each `separator` can have a specific standard for displaying and processing data, based on its semantic meaning. diff --git a/EIPS/eip-2200.md b/EIPS/eip-2200.md index d173862da8708..0ba5247fd4224 100644 --- a/EIPS/eip-2200.md +++ b/EIPS/eip-2200.md @@ -12,8 +12,8 @@ created: 2019-07-18 ## Simple Summary This is an EIP that implements net gas metering. It's a combined -version of [EIP-1283] and [EIP-1706], with a structured definition so as -to make it interoperable with other gas changes such as [EIP-1884]. +version of [EIP-1283](./eip-1283.md) and [EIP-1706](./eip-1706.md), with a structured definition so as +to make it interoperable with other gas changes such as [EIP-1884](./eip-1884.md). ## Abstract @@ -22,7 +22,7 @@ for `SSTORE` opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn’t match how most implementation works. -This is a combination of [EIP-1283] and [EIP-1706]. +This is a combination of [EIP-1283](./eip-1283.md) and [EIP-1706](./eip-1706.md). ## Motivation @@ -107,7 +107,7 @@ the counter always stays positive. ## Rationale This EIP mostly achieves what a transient storage tries to do -([EIP-1087] and [EIP-1153]), but without the complexity of introducing the +([EIP-1087](./eip-1087.md) and [EIP-1153](./eip-1153.md)), but without the complexity of introducing the concept of "dirty maps", or an extra storage struct. * We don't suffer from the optimization limitation of @@ -115,7 +115,7 @@ concept of "dirty maps", or an extra storage struct. and implicitly makes the assumption that a transaction's storage changes are committed to the storage trie at the end of a transaction. This works well for some implementations, but not for - others. After [EIP-658], an efficient storage cache implementation + others. After [EIP-658](./eip-658.md), an efficient storage cache implementation would probably use an in-memory trie (without RLP encoding/decoding) or other immutable data structures to keep track of storage changes, and only commit changes at the end of a block. For them, it is @@ -313,10 +313,3 @@ We always start at state X. The first `SSTORE` can: ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - -[EIP-1283]: https://eips.ethereum.org/EIPS/eip-1283 -[EIP-1706]: https://eips.ethereum.org/EIPS/eip-1706 -[EIP-1884]: https://eips.ethereum.org/EIPS/eip-1884 -[EIP-1087]: https://eips.ethereum.org/EIPS/eip-1087 -[EIP-1153]: https://eips.ethereum.org/EIPS/eip-1153 -[EIP-658]: https://eips.ethereum.org/EIPS/eip-658 diff --git a/EIPS/eip-2242.md b/EIPS/eip-2242.md index d4ecf0d290b6c..4be7be2946e0e 100644 --- a/EIPS/eip-2242.md +++ b/EIPS/eip-2242.md @@ -16,7 +16,7 @@ An additional, optional transaction field is added for "postdata," data that is A paradigm shift in how blockchains are used has been seen recently in Eth 2.0, with the rise of [_Execution Environments_](https://notes.ethereum.org/w1Pn2iMmSTqCmVUTGV4T5A?view) (EEs), and [_stateless clients_](https://ethresear.ch/t/the-stateless-client-concept/172). This shift involves blockchains serving as a secure data availability and arbitration layer, _i.e._, they provide a globally-accepted source of available data, and process fraud/validity and data availability proofs. This same paradigm can be applied on Eth 1.x, replacing EEs with [trust-minimized side chains](https://ethresear.ch/t/building-scalable-decentralized-payment-systems-request-for-feedback/5312). ## Motivation -While [EIP-2028](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2028.md) provides a reduction in gas cost of calldata, and is a step in the right direction of encouraging use of history rather than state, the EVM does not actually need to see all data that is posted on-chain. Following the principle of "don't pay for what you don't use," a distinct way of posting data on-chain, but without actually being usable within the EVM, is needed. +While [EIP-2028](./eip-2028.md) provides a reduction in gas cost of calldata, and is a step in the right direction of encouraging use of history rather than state, the EVM does not actually need to see all data that is posted on-chain. Following the principle of "don't pay for what you don't use," a distinct way of posting data on-chain, but without actually being usable within the EVM, is needed. For [trust-minimized side chains with fraud proofs](https://ethresear.ch/t/minimal-viable-merged-consensus/5617), we simply need to ensure that the side chain block proposer has attested that _some_ data is available. Authentication can be performed as part of a fraud proof should that data end up invalid. Note that [trust-minimized side chains with validity proofs](https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477) can't make use of the changes proposed in this EIP, as they required immediate authentication of the posted data. This will be [the topic of a future EIP](https://ethresear.ch/t/multi-threaded-data-availability-on-eth-1/5899). diff --git a/EIPS/eip-2255.md b/EIPS/eip-2255.md index 3a50c10da80e2..883ac33961a58 100644 --- a/EIPS/eip-2255.md +++ b/EIPS/eip-2255.md @@ -72,7 +72,7 @@ const response = await provider.send({ }) ``` -If this request was rejected, it would throw an error with a `code` value equal to `4001`, per [EIP 1193 errors](https://eips.ethereum.org/EIPS/eip-1193), which the MetaMask team has canonized in a module [eth-json-rpc-errors](https://github.com/metamask/eth-json-rpc-errors). +If this request was rejected, it would throw an error with a `code` value equal to `4001`, per [EIP 1193 errors](./eip-1193.md), which the MetaMask team has canonized in a module [eth-json-rpc-errors](https://github.com/metamask/eth-json-rpc-errors). If the request is accepted by the user, then subsequent requests to `eth_accounts` will succeed, and return an accounts array as usual. diff --git a/EIPS/eip-2256.md b/EIPS/eip-2256.md index 9912183e97a74..fcdeb3da52ad7 100644 --- a/EIPS/eip-2256.md +++ b/EIPS/eip-2256.md @@ -22,7 +22,7 @@ There is no standardized way for a dApp to request a list of owned assets from a There are financial dApps that require a list of owned assets from a user, for various purposes - calculating taxes, selecting customized payment options, etc. Each of these dApps are now forced to keep a list of popular assets (smart contract addresses, ABIs) and retrieve the user's data from the blockchain, for each asset. This leads to effort duplication and nonoptimal UX where the user is presented with either more or less asset options than the user would like - various airdrops, incomplete list of assets kept by the dApp. -This list of owned assets can be retrieved from the wallet used by the user. The wallet can allow the user to manage only the assets that the user is interested in. Therefore, a new JSON-RPC method is proposed: `wallet_getOwnedAssets`. This method is complementary to [EIP-747](https://eips.ethereum.org/EIPS/eip-747), which proposes a way for sites to suggest users new assets to watch on their wallet. +This list of owned assets can be retrieved from the wallet used by the user. The wallet can allow the user to manage only the assets that the user is interested in. Therefore, a new JSON-RPC method is proposed: `wallet_getOwnedAssets`. This method is complementary to [EIP-747](./eip-747.md), which proposes a way for sites to suggest users new assets to watch on their wallet. ## Specification @@ -31,7 +31,7 @@ New JSON-RPC method to be added to web3 browsers: `wallet_getOwnedAssets`. This **Arguments:** - type `address`, Ethereum address that owns the assets - options object, optional: - - `chainId` - type `uint`, chain id respecting [EIP-155](https://eips.ethereum.org/EIPS/eip-155); optional + - `chainId` - type `uint`, chain id respecting [EIP-155](./eip-155.md); optional - `limit` - type `uint`, the maximum number of owned assets expected by the dApp to be returned; optional - `types` - type `string[]`, array of asset interface identifiers such as `['ERC20', 'ERC721']`; optional - `justification` - type `string`, human-readable text provided by the dApp, explaining the intended purpose of this request; optional but recommended @@ -40,7 +40,7 @@ New JSON-RPC method to be added to web3 browsers: `wallet_getOwnedAssets`. This - array with asset records: - `address` - type `address`, Ethereum checksummed address - `chainId` - type `uint`, identifier for the chain on which the assets are deployed - - `type` - type `string`, asset interface ERC identifier; e.g. `ERC20`; optional - [EIP-1820](https://eips.ethereum.org/EIPS/eip-1820) could be used + - `type` - type `string`, asset interface ERC identifier; e.g. `ERC20`; optional - [EIP-1820](./eip-1820.md) could be used - `options` - an object with asset-specific fields; `ERC20` tokens example: - `name` - type `string`, token name; optional if the token does not implement it - `symbol` - type `string`, token symbol; optional if the token does not implement it diff --git a/EIPS/eip-2304.md b/EIPS/eip-2304.md index 73d4289c6db56..00f540589e13b 100644 --- a/EIPS/eip-2304.md +++ b/EIPS/eip-2304.md @@ -100,7 +100,7 @@ For example, the Bitcoin SegWit address `BC1QW508D6QEJXTDG4Y5R3ZARVARY0C5XW7KV8F To translate a text format checksummed hex address into binary format, simply remove the '0x' prefix and hex decode it. `0x314159265dD8dbb310642f98f50C066173C1259b` is hex-decoded and stored as the 20 bytes `314159265dd8dbb310642f98f50c066173c1259b`. -A checksum format is specified by [EIP 55](https://eips.ethereum.org/EIPS/eip-55), and extended by [RSKIP60](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP60.md), which specifies a means of including the chain ID in the checksum. The checksum on a text format address must be checked. Addresses with invalid checksums that are not all uppercase or all lowercase MUST be rejected with an error. Implementations may choose whether to accept non-checksummed addresses, but the authors recommend at least providing a warning to users in this situation. +A checksum format is specified by [EIP 55](./eip-55.md), and extended by [RSKIP60](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP60.md), which specifies a means of including the chain ID in the checksum. The checksum on a text format address must be checked. Addresses with invalid checksums that are not all uppercase or all lowercase MUST be rejected with an error. Implementations may choose whether to accept non-checksummed addresses, but the authors recommend at least providing a warning to users in this situation. When encoding an address from binary to text, an EIP55/RSKIP60 checksum MUST be used - so the correct encoding of the above address for Ethereum is `0x314159265dD8dbb310642f98f50C066173C1259b`. diff --git a/EIPS/eip-2327.md b/EIPS/eip-2327.md index be7ed55b92943..0aca4045bbd0a 100644 --- a/EIPS/eip-2327.md +++ b/EIPS/eip-2327.md @@ -16,14 +16,14 @@ Introduces a new opcode `BEGINDATA`, which indicates that the remaining bytes of It is common for smart contracts to efficiently store data directly in the contract bytecode. Examples include constant variables, compiler metadata and the contract runtime during the init phase. Currently, such data is not distinguished from normal bytecode and is still being analysed for `JUMPDEST`s by EVM interpreters. This EIP introduces a new opcode `BEGINDATA` at byte `0xb6`, which marks the remainding bytecode as data, indicating to EVM interpreters, static analysis tools and chain explorers that the remaining bytes do not represent opcodes. ## Motivation -The `BEGINDATA` opcode has been suggested before as part of the EIP `Subroutines and Static Jumps for the EVM` [EIP-615](https://eips.ethereum.org/EIPS/eip-615) as a way to determine the position of jumptables in contract bytecode. It is here introduced in its own right in order to exclude data from the `JUMPDEST` analysis of contracts, making it impossible to jump to data. This makes it easier for static analysis tools to analyse contracts, allows disassemblers, chain explorers and debuggers to not display data as a mess of INVALID opcodes and may even provide a marginal improvement in performance. Additionally, it paves the way for suggestions such as [EIP 1712](https://github.com/ethereum/EIPs/pull/1712) to disallow unused opcodes, jumptables [EIP-615](https://eips.ethereum.org/EIPS/eip-615) and speculative proposals to disallow for deployment of contracts with stack usage violations. +The `BEGINDATA` opcode has been suggested before as part of the EIP `Subroutines and Static Jumps for the EVM` [EIP-615](./eip-615.md) as a way to determine the position of jumptables in contract bytecode. It is here introduced in its own right in order to exclude data from the `JUMPDEST` analysis of contracts, making it impossible to jump to data. This makes it easier for static analysis tools to analyse contracts, allows disassemblers, chain explorers and debuggers to not display data as a mess of INVALID opcodes and may even provide a marginal improvement in performance. Additionally, it paves the way for suggestions such as disallowing unused opcodes, jumptables [EIP-615](./eip-615.md) and speculative proposals to disallow for deployment of contracts with stack usage violations. ## Specification While computing the valid `JUMPDEST`s of a contract, halt analysis if `BEGINDATA` is encountered. A `JUMP` to a value higher than the `PC` value of `BEGINDATA` should throw with a `BAD_JUMP_DESTINATION` error. Bytes past `BEGINDATA` remain accessible via `CODECOPY` and `EXTCODECOPY`. If `BEGINDATA` is encountered during contract execution, it has the same semantics as `STOP`. It uses 0 gas. ## Rationale -The byte `0xb6` was chosen to align with [EIP-615](https://eips.ethereum.org/EIPS/eip-615). +The byte `0xb6` was chosen to align with [EIP-615](./eip-615.md). The choice to `STOP` if `BEGINDATA` is encountered is somewhat arbitrary. An alternative would be to be to abort the execution with an out-of-gas error. ## Backwards Compatibility diff --git a/EIPS/eip-233.md b/EIPS/eip-233.md index 7dde4bafe6559..367bddadc028a 100644 --- a/EIPS/eip-233.md +++ b/EIPS/eip-233.md @@ -52,7 +52,7 @@ The Meta EIP representing the hard fork should move in to the `Accepted` state o ## Template -A template for the [Istanbul Hardfork Meta 1679](https://eips.ethereum.org/EIPS/eip-1679) is included below ([source file on GitHub](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1679.md)): +A template for the [Istanbul Hardfork Meta 1679](./eip-1679.md) is included below ([source file on GitHub](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1679.md)): ``` {% raw %} diff --git a/EIPS/eip-2334.md b/EIPS/eip-2334.md index de803a3b794ea..fbb03acfa4eda 100644 --- a/EIPS/eip-2334.md +++ b/EIPS/eip-2334.md @@ -12,11 +12,11 @@ requires: 2333 ## Simple Summary -This EIP defines the purpose of a given key, or family thereof, within a tree of keys. When combined with [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333), the combination of a seed and knowledge of the desired purpose of a key is sufficient to determine a key pair. +This EIP defines the purpose of a given key, or family thereof, within a tree of keys. When combined with [EIP-2333](./eip-2333.md), the combination of a seed and knowledge of the desired purpose of a key is sufficient to determine a key pair. ## Abstract -A standard for allocating keys generated by [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333) to a specific purpose. It defines a `path` which is a string that parses into the indices to be used when traversing the tree of keys that [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333) generates. +A standard for allocating keys generated by [EIP-2333](./eip-2333.md) to a specific purpose. It defines a `path` which is a string that parses into the indices to be used when traversing the tree of keys that [EIP-2333](./eip-2333.md) generates. ## A note on purpose @@ -24,9 +24,9 @@ This specification is designed not only to be an Ethereum 2.0 standard, but one ## Motivation -Ethereum 2.0 alongside many other projects will use BLS12-381 signatures. This new scheme requires a new key derivation mechanism, which is established within [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333). This new scheme is incompatible with the current form of this specification ([BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) due to the: exclusive use of hardened keys, the increased number of keys per level, not using [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for key derivation. It is therefore necessary to establish a new *path* for traversing the [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333) key-tree. +Ethereum 2.0 alongside many other projects will use BLS12-381 signatures. This new scheme requires a new key derivation mechanism, which is established within [EIP-2333](./eip-2333.md). This new scheme is incompatible with the current form of this specification ([BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)) due to the: exclusive use of hardened keys, the increased number of keys per level, not using [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for key derivation. It is therefore necessary to establish a new *path* for traversing the [EIP-2333](./eip-2333.md) key-tree. -The path structure specified in this EIP aims to be more general than [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) by not having UTXO-centric features [which gave rise to the 4 different types of wallet paths being used within Ethereum 1.0](https://github.com/ethereum/EIPs/issues/84#issuecomment-292324521) and gave rise to (draft) EIPs [600](https://eips.ethereum.org/EIPS/eip-600) & [601](https://eips.ethereum.org/EIPS/eip-601) +The path structure specified in this EIP aims to be more general than [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) by not having UTXO-centric features [which gave rise to the 4 different types of wallet paths being used within Ethereum 1.0](https://github.com/ethereum/EIPs/issues/84#issuecomment-292324521) and gave rise to (draft) EIPs [600](./eip-600.md) & [601](./eip-601.md) ## Specification @@ -40,14 +40,14 @@ m / purpose / coin_type / account / use #### Notation -The notation used within the path is specified within the [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333), but is summarized again below for convenience. +The notation used within the path is specified within the [EIP-2333](./eip-2333.md), but is summarized again below for convenience. * `m` Denotes the master node (or root) of the tree * `/` Separates the tree into depths, thus `i / j` signifies that `j` is a child of `i` ### Purpose -The `purpose` is set to `12381` which is the name of the new curve (BLS12-381). In order to be in compliance with this standard, the [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333) MUST be implemented as the KDF and therefore, the purpose `12381` MAY NOT be used unless this is the case. +The `purpose` is set to `12381` which is the name of the new curve (BLS12-381). In order to be in compliance with this standard, the [EIP-2333](./eip-2333.md) MUST be implemented as the KDF and therefore, the purpose `12381` MAY NOT be used unless this is the case. ### Coin Type @@ -89,13 +89,13 @@ The purpose needs to be distinct from these standards as the KDF and path are no ### Eth2 Specific Parameters -A new coin type is chosen for Eth2 keys to help ensure a clean separation between Eth2 and Eth1 keys. Although the distinction between Eth1 ETH and Eth2 ETH is subtle, they are distinct entities and there are services which only distinguish between coins by their coin name (eg. [ENS' multichain address resolution](https://eips.ethereum.org/EIPS/eip-2304)). `3600` is chosen specifically because it is the square of the Eth1's `coin_type` (`3600==60^2`) thereby signaling that it is second instantiation of Ether the currency. +A new coin type is chosen for Eth2 keys to help ensure a clean separation between Eth2 and Eth1 keys. Although the distinction between Eth1 ETH and Eth2 ETH is subtle, they are distinct entities and there are services which only distinguish between coins by their coin name (eg. [ENS' multichain address resolution](./eip-2304.md)). `3600` is chosen specifically because it is the square of the Eth1's `coin_type` (`3600==60^2`) thereby signaling that it is second instantiation of Ether the currency. The primary reason validators have separate signing and withdrawal keys is to allow for the different security concerns of actions within Eth2. The signing key is given to the validator client where it signs messages as per the requirements of being a validator, it is therefore a "hot key". If this key is compromised, the worst that can happen (locally) is that a slashable message is signed, resulting in the validator being slashed and forcibly exited. The withdrawal key is only needed when a validator wishes to perform an action not related to validating and has access to the full funds at stake for that validator. The withdrawal key therefore has higher security concerns and should be handled as a "cold key". By having the signing key be a child of the withdrawal key, secure storage of the withdrawal key is sufficient to recover the signing key should the need arise. ## Backwards Compatibility -[BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) and [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) are the commonly used standards for this purpose within Ethereum 1.0, however they have not been `Accepted` as standards as yet. Due to the use of a new KDF within [EIP-2333](https://eips.ethereum.org/EIPS/eip-2333), a new path standard is required. This EIP implements this, with minor changes. +[BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) and [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) are the commonly used standards for this purpose within Ethereum 1.0, however they have not been `Accepted` as standards as yet. Due to the use of a new KDF within [EIP-2333](./eip-2333.md), a new path standard is required. This EIP implements this, with minor changes. `purpose` `12381` paths do not support hardened keys and therefore the `'` character is invalid. diff --git a/EIPS/eip-2335.md b/EIPS/eip-2335.md index 561660f5c7ac9..4bad77e287bf1 100644 --- a/EIPS/eip-2335.md +++ b/EIPS/eip-2335.md @@ -28,7 +28,7 @@ The secure storage and exchange of keys is a vital component of the user experie In Ethereum 1, [the Web3 Secret Storage Definition](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) fulfills these requirements, however it is not perfectly suitable for these purposes moving forward. Specifically the problems with the existing standard are: -* __The use of Keccak256.__ Eth1 keystores use Keccak for their checksum, a sensible choice considering its usage within Ethereum 1. BLS12-381 [signatures](https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-00), [keys (EIP-2333)](https://eips.ethereum.org/EIPS/eip-2333), and key-storage are inter-chain standards, the establishment and proliferation of which hinges on them being neutral to all chains, something which Keccak is not. +* __The use of Keccak256.__ Eth1 keystores use Keccak for their checksum, a sensible choice considering its usage within Ethereum 1. BLS12-381 [signatures](https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-00), [keys (EIP-2333)](./eip-2333.md), and key-storage are inter-chain standards, the establishment and proliferation of which hinges on them being neutral to all chains, something which Keccak is not. * __A lack of abstraction.__ Eth1 keystores are a result of an iterative design process whereby functionality was added and modified as needed without considering how abstractions could simplify the notion of different properties. @@ -110,7 +110,7 @@ The `pubkey` is the public key associated with the the private key secured withi ## Path -The `path` indicates where in the key-tree a key originates from. It is a string defined by [EIP-2334](https://eips.ethereum.org/EIPS/eip-2334), if no path is known or the path is not relevant, the empty string, `""` indicates this. The `path` can specify an arbitrary depth within the tree and the deepest node within the tree indicates the depth of the key stored within this file. +The `path` indicates where in the key-tree a key originates from. It is a string defined by [EIP-2334](./eip-2334.md), if no path is known or the path is not relevant, the empty string, `""` indicates this. The `path` can specify an arbitrary depth within the tree and the deepest node within the tree indicates the depth of the key stored within this file. ## UUID diff --git a/EIPS/eip-2364.md b/EIPS/eip-2364.md index 88654d3d9d8ad..dde5598e4eb9c 100644 --- a/EIPS/eip-2364.md +++ b/EIPS/eip-2364.md @@ -12,9 +12,9 @@ requires: 2124 ## Abstract -The [`forkid` (EIP-2124)](https://eips.ethereum.org/EIPS/eip-2124) was designed to permit two Ethereum nodes to quickly and cheaply decide if they are compatible or not, not only at a genesis/networking level, but also from the perspective of the currently passed network updates (i.e. forks). +The [`forkid` (EIP-2124)](./eip-2124.md) was designed to permit two Ethereum nodes to quickly and cheaply decide if they are compatible or not, not only at a genesis/networking level, but also from the perspective of the currently passed network updates (i.e. forks). -[EIP-2124](https://eips.ethereum.org/EIPS/eip-2124) only defines how the `forkid` is calculated and validated, but does not specify how the `forkid` should be exchanged between peers. This EIP specifies the inclusion of the `forkid` as a new field in the Ethereum wire protocol (`eth`) handshake (releasing a new version, `eth/64`). +[EIP-2124](./eip-2124.md) only defines how the `forkid` is calculated and validated, but does not specify how the `forkid` should be exchanged between peers. This EIP specifies the inclusion of the `forkid` as a new field in the Ethereum wire protocol (`eth`) handshake (releasing a new version, `eth/64`). By cross-validating `forkid` during the handshake, incompatible nodes can disconnect before expensive block exchanges and validations take place (PoW check, EVM execution, state reconstruction). This further prevents peer slots from being taken up by nodes that are incompatible, but have not yet been detected as such. @@ -28,13 +28,13 @@ From a macro perspective, keeping incompatible nodes partitioned from one anothe The specification is tiny since most parts are already specified in EIP-2124. `eth/63` is not specified as an EIP, but is maintained [here](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). -- Implement `forkid` generation and validation per [EIP-2124](https://eips.ethereum.org/EIPS/eip-2124). +- Implement `forkid` generation and validation per [EIP-2124](./eip-2124.md). - Advertise a new `eth` protocol capability (version) at `eth/64`. - The old `eth/63` protocol should still be kept alive side-by-side, until `eth/64` is sufficiently adopted by implementors. - Redefine `Status (0x00)` for `eth/64` to add a trailing `forkid` field: - Old packet: `[protocolVersion, networkId, td, bestHash, genesisHash]` - New packet: `[protocolVersion, networkId, td, bestHash, genesisHash, forkid]`, - where `forkid` is `[forkHash: [4]byte, forkNext: uint64]` (fields per [EIP-2124](https://eips.ethereum.org/EIPS/eip-2124) ). + where `forkid` is `[forkHash: [4]byte, forkNext: uint64]` (fields per [EIP-2124](./eip-2124.md) ). Whenever two peers connect using the `eth/64` protocol, the updated `Status` message must be sent as the protocol handshake, and each peer must validate the remote `forkid`, disconnecting at a detected incompatibility. @@ -46,7 +46,7 @@ Advertising and validating the `forkid` in the discovery protocol is a more opti Compared to the `eth` protocol however, discovery is a bit fuzzy. The goal there is to suggest potential peers, not to be fool-proof. Information may be outdated, nodes may have changed or disappeared. Discovery can do a rough filtering, but more precision is still needed afterwards. -Additionally, `forkid` validation via the discovery protocol requires ENR implementation ([EIP-778](https://eips.ethereum.org/EIPS/eip-778)) and ENR extension support ([EIP-868](https://eips.ethereum.org/EIPS/eip-868)), which is not mandated by the Ethereum network currently. Lastly, the discovery protocol is just one way to find peers, but systems that cannot use UDP or that rely on other mechanism (e.g. DNS discovery ([EIP-1459](https://eips.ethereum.org/EIPS/eip-1459))) still need a way to filter connections. +Additionally, `forkid` validation via the discovery protocol requires ENR implementation ([EIP-778](./eip-778.md)) and ENR extension support ([EIP-868](./eip-868.md)), which is not mandated by the Ethereum network currently. Lastly, the discovery protocol is just one way to find peers, but systems that cannot use UDP or that rely on other mechanism (e.g. DNS discovery ([EIP-1459](./eip-1459.md))) still need a way to filter connections. ##### The `forkid` implicitly contains the genesis hash checksummed into the `FORK_HASH` field. Why doesn't this proposal remove the `genesisHash` field from the `eth` handshake? @@ -62,7 +62,7 @@ This EIP does not change the consensus engine, thus does _not_ require a hard fo ## Test Cases -For calculating and validating fork IDs, see test cases in [EIP-2124](https://eips.ethereum.org/EIPS/eip-2124). +For calculating and validating fork IDs, see test cases in [EIP-2124](./eip-2124.md). Testing proper advertising and validation at the networking level will require a [hive](https://github.com/ethereum/hive) test. diff --git a/EIPS/eip-2384.md b/EIPS/eip-2384.md index f00101490ac1b..2c7c39dd8accf 100644 --- a/EIPS/eip-2384.md +++ b/EIPS/eip-2384.md @@ -34,7 +34,7 @@ This EIP is not forward compatible and introduces backwards incompatibilities in Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. ## Implementation -The implementation in it's logic does not differ from [EIP-649](https://eips.ethereum.org/EIPS/eip-649) or [EIP-1234](https://eips.ethereum.org/EIPS/eip-1234); an implementation for Parity-Ethereum is available in [parity-ethereum#9187](https://github.com/paritytech/parity-ethereum/pull/9187). +The implementation in it's logic does not differ from [EIP-649](./eip-649.md) or [EIP-1234](./eip-1234.md); an implementation for Parity-Ethereum is available in [parity-ethereum#9187](https://github.com/paritytech/parity-ethereum/pull/9187). ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-2387.md b/EIPS/eip-2387.md index 095c30b4ef621..94e810c43825e 100644 --- a/EIPS/eip-2387.md +++ b/EIPS/eip-2387.md @@ -36,7 +36,7 @@ This fork will push back the Iceage as far as far as is reasonable and will give - `Block >= N/A` on the Görli testnet ### Included EIPs - - [EIP-2384](https://eips.ethereum.org/EIPS/eip-2384): Istanbul/Berlin Difficulty Bomb Delay + - [EIP-2384](./eip-2384.md): Istanbul/Berlin Difficulty Bomb Delay ## Rationale @@ -64,7 +64,7 @@ This fork would give us time to address the community to understand their priori ### POA Testnets -Muir Glacier never activates on PoA chains – thus will have zero impact on [forkid](https://eips.ethereum.org/EIPS/eip-2124). +Muir Glacier never activates on PoA chains – thus will have zero impact on [forkid](./eip-2124.md). ### Note on Issuance Reduction diff --git a/EIPS/eip-2400.md b/EIPS/eip-2400.md index b8ea5929a5288..9cc754e2a48b1 100644 --- a/EIPS/eip-2400.md +++ b/EIPS/eip-2400.md @@ -100,5 +100,5 @@ Future upgrades that are partially or fully incompatible with this proposal must Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[ERC-831]: https://eips.ethereum.org/EIPS/eip-831 -[ERC-681]: https://eips.ethereum.org/EIPS/eip-681 +[ERC-831]: ./eip-831.md +[ERC-681]: ./eip-681.md diff --git a/EIPS/eip-2470.md b/EIPS/eip-2470.md index f7a573a9a7952..49f31d76e7079 100644 --- a/EIPS/eip-2470.md +++ b/EIPS/eip-2470.md @@ -18,7 +18,7 @@ A permissionless factory for deploy of keyless deterministic contracts addresses ## Abstract -Some contracts are designed to be Singletons which have the same address no matter what chain they are, which means that should exist one instance for all, such as [EIP-1820] and [EIP-2429]. These contracts are usually deployed using a method known as [Nick]'s method, so anyone can deploy those contracts on any chain and they have a deterministic address. +Some contracts are designed to be Singletons which have the same address no matter what chain they are, which means that should exist one instance for all, such as [EIP-1820](./eip-1820.md). These contracts are usually deployed using a method known as [Nick]'s method, so anyone can deploy those contracts on any chain and they have a deterministic address. This standard proposes the creation of a CREATE2 factory using this method, so other projects requiring this feature can use this factory in any chain with the same setup, even in development chains. ## Motivation @@ -77,7 +77,7 @@ This contract is going to be deployed using the keyless deployment method---also (See [Nick's article] for more details). This method works as follows: 1. Generate a transaction which deploys the contract from a new random account. - - This transaction MUST NOT use [EIP-155] in order to work on any chain. + - This transaction MUST NOT use [EIP-155](./eip-155.md) in order to work on any chain. - This transaction MUST have a relatively high gas price to be deployed on any chain. In this case, it is going to be 100 Gwei. 2. Forge a transaction with the following parameters: @@ -180,18 +180,13 @@ https://github.com/3esmit/ERC2470 ## Security Considerations -Some contracts can possibly not support being deployed on any chain, or require a different address per chain, that can be safely done by using comparison in [EIP-1344] in constructor. -Account contracts are singletons in the point of view of each user, when wallets want to signal what chain id is intended, [EIP-1191] should be used. +Some contracts can possibly not support being deployed on any chain, or require a different address per chain, that can be safely done by using comparison in [EIP-1344](./eip-1344.md) in constructor. +Account contracts are singletons in the point of view of each user, when wallets want to signal what chain id is intended, [EIP-1191](./eip-1191.md) should be used. Contracts deployed on factory must not use `msg.sender` in constructor, instead use constructor parameters, otherwise the factory would end up being the controller/only owner of those. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[EIP-155]: https://eips.ethereum.org/EIPS/eip-155 -[EIP-1191]: https://eips.ethereum.org/EIPS/eip-1191 -[EIP-1344]: https://eips.ethereum.org/EIPS/eip-1344 -[EIP-1820]: https://eips.ethereum.org/EIPS/eip-1820 -[EIP-2429]: https://gitlab.com/status-im/docs/EIPs/blob/secret-multisig-recovery/EIPS/eip-2429.md [Nick's article]: https://medium.com/@weka/how-to-send-ether-to-11-440-people-187e332566b7 [Nick]: https://github.com/Arachnid/ diff --git a/EIPS/eip-2477.md b/EIPS/eip-2477.md index 82c9483aca1c2..af46e2cfeb049 100644 --- a/EIPS/eip-2477.md +++ b/EIPS/eip-2477.md @@ -106,7 +106,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL pragma solidity ^0.6.0; /// @title ERC-2477 Token Metadata Integrity -/// @dev See https://eips.ethereum.org/EIPS/eip-2477 +/// @dev See ./eip-2477.md /// @dev The ERC-165 identifier for this interface is 0x#######. //TODO: FIX THIS interface ERC2477 /* is ERC165 */ { /** @@ -296,17 +296,17 @@ TODO: ADD IMPLEMENTATIONS WITH 0XCERT ENJIN, NIKE, AZURE/MICROSOFT Normative standard references 1. RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt -2. ERC-165 Standard Interface Detection. https://eips.ethereum.org/EIPS/eip-165 -3. ERC-721 Non-Fungible Token Standard. https://eips.ethereum.org/EIPS/eip-721 -4. ERC-1155 Multi Token Standard. https://eips.ethereum.org/EIPS/eip-1155 +2. ERC-165 Standard Interface Detection. ./eip-165.md +3. ERC-721 Non-Fungible Token Standard. ./eip-721.md +4. ERC-1155 Multi Token Standard. ./eip-1155.md 5. JSON-LD. https://www.w3.org/TR/json-ld/ 6. Secure Hash Standard (SHS). https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf Other standards -1. ERC-1046 ERC-20 Metadata Extension (DRAFT). https://eips.ethereum.org/EIPS/eip-1046 -2. ERC-918 Mineable Token Standard (DRAFT). https://eips.ethereum.org/EIPS/eip-918 -3. ERC-1523 Standard for Insurance Policies as ERC-721 Non Fungible Tokens (DRAFT). https://eips.ethereum.org/EIPS/eip-1523 +1. ERC-1046 ERC-20 Metadata Extension (DRAFT). ./eip-1046.md +2. ERC-918 Mineable Token Standard (DRAFT). ./eip-918.md +3. ERC-1523 Standard for Insurance Policies as ERC-721 Non Fungible Tokens (DRAFT). ./eip-1523.md 4. W3C Subresource Integrity (SRI). https://www.w3.org/TR/SRI/ 5. The "data" URL scheme. https://tools.ietf.org/html/rfc2397 6. Uniform Resource Identifier (URI): Generic Syntax. https://tools.ietf.org/html/rfc3986 diff --git a/EIPS/eip-2488.md b/EIPS/eip-2488.md index c258c5050910e..35e548a31bc14 100644 --- a/EIPS/eip-2488.md +++ b/EIPS/eip-2488.md @@ -18,7 +18,7 @@ Deprecate `CALLCODE` in a *somewhat* backwards compatible way, by making it alwa `CALLCODE` was part of the Frontier release of Ethereum. In the first few weeks/months it became clear that it cannot accomplish its intended design goal. This was rectified with introducing `DELEGATECALL` -([EIP-7](https://eips.ethereum.org/EIPS/eip-7)) in the Homestead update (early 2016). +([EIP-7](./eip-7.md)) in the Homestead update (early 2016). `CALLCODE` became never utilized, but it still puts a burden on EVM implementations. diff --git a/EIPS/eip-2525.md b/EIPS/eip-2525.md index 35c330af139e3..8d0d7696b1906 100644 --- a/EIPS/eip-2525.md +++ b/EIPS/eip-2525.md @@ -12,7 +12,7 @@ requires: 137, 634, 1193, 2304 ## 1. Abstract -This presents a method to improve a universal method of login to the ethereum blockchain, leveraging the metadata storage provided by the ENS. We consider a user to be logged in when we have an [EIP 1193](https://eips.ethereum.org/EIPS/eip-1193) provider that can sign transaction and messages on his behalf. This method is inspired by [Alex Van de Sande's work](https://www.youtube.com/watch?v=1LVwWknE-NQ) and [Web3Connect](https://web3connect.com). In the future, the approach described here-after should be extended to work with any blockchain. +This presents a method to improve a universal method of login to the ethereum blockchain, leveraging the metadata storage provided by the ENS. We consider a user to be logged in when we have an [EIP 1193](./eip-1193.md) provider that can sign transaction and messages on his behalf. This method is inspired by [Alex Van de Sande's work](https://www.youtube.com/watch?v=1LVwWknE-NQ) and [Web3Connect](https://web3connect.com). In the future, the approach described here-after should be extended to work with any blockchain. ## 2. Motivation @@ -29,9 +29,9 @@ That way, ENSLogin would allow any user to connect to any Dapp with any wallet, The ENSLogin works as follow: * Request an ENS domain from the user -* Resolve the ENS domain to retrieve (see [EIP 137](https://eips.ethereum.org/EIPS/eip-20)) - * An address (see [EIP 137](https://eips.ethereum.org/EIPS/eip-20)) - * A text entry (see [EIP 634](https://eips.ethereum.org/EIPS/eip-634)) +* Resolve the ENS domain to retrieve (see [EIP 137](./eip-20.md)) + * An address (see [EIP 137](./eip-20.md)) + * A text entry (see [EIP 634](./eip-634.md)) * Interpret the text entry and download the file it points to * Evaluate the content of the downloaded file * Return the corresponding object to the Dapp @@ -42,7 +42,7 @@ This workflow is to be implemented by an SDK that Dapp could easily import. The ### 3.2. Details -* **Text entry resolution:** A pointer to the code needed to instantiate the wallet-provider is recorded using the ENS support for text entries (see [EIP 634](https://eips.ethereum.org/EIPS/eip-634)). The corresponding key is `enslogin` (**subject to change**). If no value is associated with the key `enslogin` at the targeted domain, we fallback to metadata store on the parent's node with the key `enslogin-default` (**subject to change**). +* **Text entry resolution:** A pointer to the code needed to instantiate the wallet-provider is recorded using the ENS support for text entries (see [EIP 634](./eip-634.md)). The corresponding key is `enslogin` (**subject to change**). If no value is associated with the key `enslogin` at the targeted domain, we fallback to metadata store on the parent's node with the key `enslogin-default` (**subject to change**). **Example:** for the ens domain `username.domain.eth`, the resolution would look for (in order): * `resolver.at(ens.owner(nodehash("username.domain.eth"))).text(nodehash("username.domain.eth"), 'enslogin')` * `resolver.at(ens.owner(nodehash("domain.eth"))).text(nodehash("domain.eth"), 'enslogin-default')` @@ -60,7 +60,7 @@ This workflow is to be implemented by an SDK that Dapp could easily import. The Note that this suffix mechanism is compatible with http/https as well as IPFS. It is a constraint on the storage layer as some may not be able to do this kind of resolution. * **Provider instantiation:** - * [JAVASCRIPT/ETHEREUM] The file containing the wallet-provider's code should inject a function `global.provider: (config) => Promise` that returns a promise to a standardized provider object. For EVM blockchains, the object should follow [EIP 1193](https://eips.ethereum.org/EIPS/eip-1193). + * [JAVASCRIPT/ETHEREUM] The file containing the wallet-provider's code should inject a function `global.provider: (config) => Promise` that returns a promise to a standardized provider object. For EVM blockchains, the object should follow [EIP 1193](./eip-1193.md). * Other blockchain types/langages should be detailed in the future. diff --git a/EIPS/eip-2535.md b/EIPS/eip-2535.md index 6f4db80dff5ec..2b02767d462d1 100644 --- a/EIPS/eip-2535.md +++ b/EIPS/eip-2535.md @@ -536,11 +536,11 @@ This standard makes upgradeable diamonds compatible with future standards and fu ## Inspiration & Development -The Diamond Standard is an improved design over [EIP-1538](https://eips.ethereum.org/EIPS/eip-1538) using ABIEncoderV2 and function selectors. +The Diamond Standard is an improved design over [EIP-1538](./eip-1538.md) using ABIEncoderV2 and function selectors. The Diamond Standard replaces EIP-1538. -This standard was inspired by [EIP-1538](https://eips.ethereum.org/EIPS/eip-1538) and ZeppelinOS's implementation of [Upgradeability with vtables](https://github.com/zeppelinos/labs/tree/master/upgradeability_with_vtable). +This standard was inspired by [EIP-1538](./eip-1538.md) and ZeppelinOS's implementation of [Upgradeability with vtables](https://github.com/zeppelinos/labs/tree/master/upgradeability_with_vtable). This standard was also inspired by the design and implementation of the [Mokens contract](https://etherscan.io/address/0xc1eab49cf9d2e23e43bcf23b36b2be14fc2f8838#code). diff --git a/EIPS/eip-2565.md b/EIPS/eip-2565.md index 969d9bf782ecd..a36e2a3224c63 100644 --- a/EIPS/eip-2565.md +++ b/EIPS/eip-2565.md @@ -12,7 +12,7 @@ requires: 198 --- ## Simple Summary -The [EIP-198](https://eips.ethereum.org/EIPS/eip-198) ‘big integer modular exponentiation’, or `ModExp`, precompile is currently overpriced. Re-pricing this precompile will enable more cost efficient verification of RSA signatures, verifiable delay functions (VDFs), primality checks, and more. +The [EIP-198](./eip-198.md) ‘big integer modular exponentiation’, or `ModExp`, precompile is currently overpriced. Re-pricing this precompile will enable more cost efficient verification of RSA signatures, verifiable delay functions (VDFs), primality checks, and more. ## Abstract After benchmarking the ModExp precompile, we discovered that it is ‘overpriced’ relative to other precompiles. We also discovered that the current gas pricing formula could be improved to better estimate the computational complexity of various ModExp input variables. To improve the gas cost pricing for this precompile the following options are available: @@ -88,7 +88,7 @@ There are no changes to the underlying interface or arithmetic algorithms, so th The biggest security consideration for this EIP is creating a potential DoS vector by making ModExp operations too inexpensive relative to their computation time. ## References -[EIP-198](https://eips.ethereum.org/EIPS/eip-198) +[EIP-198](./eip-198.md) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-2569.md b/EIPS/eip-2569.md index 482e769765726..da5c75627ec5e 100644 --- a/EIPS/eip-2569.md +++ b/EIPS/eip-2569.md @@ -117,7 +117,7 @@ import "@openzeppelin/contracts/token/ERC721/IERC721.sol"; /** * @title ERC-721 Non-Fungible Token Standard, optional retrieving SVG image extension - * @dev See https://eips.ethereum.org/EIPS/eip-721 + * @dev See ./eip-721.md */ contract IERC721GetImageSvg is IERC721 { function getTokenImageSvg(uint256 tokenId) external view returns (string memory); diff --git a/EIPS/eip-2583.md b/EIPS/eip-2583.md index f521d0eae6fc5..6514d9c9b92a3 100644 --- a/EIPS/eip-2583.md +++ b/EIPS/eip-2583.md @@ -28,7 +28,7 @@ From an implementation perspective, a node can (and does) use various caching me This is attackable. By forcing a node to lookup non-existent keys, an attacker can maximize the number of disk lookups. Sidenote: even if the 'non-existence' is cached, it's trivial to use a new non-existent key the next time, and never hit the same non-existent key again. Thus, caching 'non-existence' might be dangerous, since it will evict 'good' entries. -So far, the attempts to handle this problem has been in raising the gas cost, e.g. [EIP-150](https://eips.ethereum.org/EIPS/eip-150), [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884). +So far, the attempts to handle this problem has been in raising the gas cost, e.g. [EIP-150](./eip-150.md), [EIP-1884](./eip-1884.md). However, when determining gas-costs, a secondary problem that arises due to the large discrepancy between 'happy-path' and 'notorious path' -- how do we determine the pricing? diff --git a/EIPS/eip-2612.md b/EIPS/eip-2612.md index 9d559b9d1c536..5da9ab01b1244 100644 --- a/EIPS/eip-2612.md +++ b/EIPS/eip-2612.md @@ -11,7 +11,7 @@ requires: 20, 712 --- ## Simple Summary -A function `permit` extending [ERC-20](https://eips.ethereum.org/EIPS/eip-20) which allows for approvals to be made via `secp256k1` signatures. This kind of "account abstraction for ERC-20" brings about two main benefits: +A function `permit` extending [ERC-20](./eip-20.md) which allows for approvals to be made via `secp256k1` signatures. This kind of "account abstraction for ERC-20" brings about two main benefits: - transactions involving ERC-20 operations can be paid using the token itself rather than ETH, - approve and pull operations can happen in a single transaction instead of two consecutive transactions, @@ -26,13 +26,13 @@ However, a limiting factor in this design stems from the fact that the ERC-20 `a This ERC extends the ERC-20 standard with a new function `permit`, which allows users to modify the `allowance` mapping using a signed message, instead of through `msg.sender`. -For an improved user experience, the signed data is structured following [ERC-712](https://eips.ethereum.org/EIPS/eip-712), which already has wide spread adoption in major RPC providers. +For an improved user experience, the signed data is structured following [ERC-712](./eip-712.md), which already has wide spread adoption in major RPC providers. ## Motivation -While ERC-20 tokens have become ubiquotous in the Ethereum ecosystem, their status remains that of second class tokens from the perspective of the protocol. The ability for users to interact with Ethereum without holding any ETH has been a [long outstanding goal](https://github.com/ethereum/EIPs/blob/ed621645c8f3bc5756492f327cda015f35d9f8da/EIPS/eip-101.md) and the [subject](https://eips.ethereum.org/EIPS/eip-1077) [of](https://eips.ethereum.org/EIPS/eip-777) [many](https://github.com/ethereum/EIPs/issues/1776#) [EIPs](https://eips.ethereum.org/EIPS/eip-1271). +While ERC-20 tokens have become ubiquotous in the Ethereum ecosystem, their status remains that of second class tokens from the perspective of the protocol. The ability for users to interact with Ethereum without holding any ETH has been a long outstanding goal](./eip-101.md) and the [subject](./eip-1077.md) [of](./eip-777.md) many [EIPs](./eip-1271.md). -So far, many of these proposals have seen very little adoption, and the ones that have been adopted (such as [ERC-777](https://eips.ethereum.org/EIPS/eip-777)), introduce a lot of additional functionality, causing [unexpected behavior in mainstream contracts](https://medium.com/consensys-diligence/uniswap-audit-b90335ac007). +So far, many of these proposals have seen very little adoption, and the ones that have been adopted (such as [ERC-777](./eip-777.md)), introduce a lot of additional functionality, causing [unexpected behavior in mainstream contracts](https://medium.com/consensys-diligence/uniswap-audit-b90335ac007). This ERC proposes an alternative solution which is designed to be as minimal as possible and to only address _one problem_: the lack of abstraction in the ERC-20 `approve` method. diff --git a/EIPS/eip-2677.md b/EIPS/eip-2677.md index d7d32e7fb8f5f..749464a9ec793 100644 --- a/EIPS/eip-2677.md +++ b/EIPS/eip-2677.md @@ -17,7 +17,7 @@ Enforce a maximum size limit (`max_initcode_size`) of `49152` (`0xc000`) for `in Enforce a maximum size limit (`max_initcode_size`) for `initcode`. If the size of `initcode` exceeds `max_initcode_size`, then contract creation fails with an out of gas error. -Since [EIP-170](https://eips.ethereum.org/EIPS/eip-170) was implemented, there has been a size limit of `24576` (`0x6000`) on contract code. We propose to also limit the size of executable code to `2x` the above limit, i.e. `49152` (`0xc000`). +Since [EIP-170](./eip-170.md) was implemented, there has been a size limit of `24576` (`0x6000`) on contract code. We propose to also limit the size of executable code to `2x` the above limit, i.e. `49152` (`0xc000`). This also leads to two nice properties: diff --git a/EIPS/eip-2678.md b/EIPS/eip-2678.md index f9a43648e7414..4626d2844e1b0 100644 --- a/EIPS/eip-2678.md +++ b/EIPS/eip-2678.md @@ -40,7 +40,7 @@ practices in mind. As version 3 of this specification, this standard seeks to address a number of areas of improvement found for the previous version (defined in -[EIP-1123](https://eips.ethereum.org/EIPS/eip-1123)). +[EIP-1123](./eip-1123.md)). This version: @@ -2104,8 +2104,8 @@ dependent EIP submssions. ## Acknowledgements The authors of this document would like to thank the original authors of -[EIP-190](https://eips.ethereum.org/EIPS/eip-190), -[EIP-1123](https://eips.ethereum.org/EIPS/eip-1123), all community +[EIP-190](./eip-190.md), +[EIP-1123](./eip-1123.md), all community [contributors](https://github.com/ethpm/ethpm-spec/graphs/contributors), and the Ethereum community at large. diff --git a/EIPS/eip-2681.md b/EIPS/eip-2681.md index d76dfffa641c8..757a72947c8c8 100644 --- a/EIPS/eip-2681.md +++ b/EIPS/eip-2681.md @@ -34,7 +34,7 @@ If `block.number >= FORK_BLOCK` introduce two new restrictions: 1. It is unlikely for any nonce to reach or exceed the proposed limit. If one would want to reach that limit via external transactions, it would cost at least `21000 * (2^64-1) = 387_381_625_547_900_583_915_000` gas. 2. It must be noted that in the past, in the Morden testnet, each new account had a starting nonce of `2^20` in order to differentiate transactions from mainnet transactions. -This mode of replay protection is out of fashion since [EIP-155](https://eips.ethereum.org/EIPS/eip-155) introduced a more elegant way using chain identifiers. +This mode of replay protection is out of fashion since [EIP-155](./eip-155.md) introduced a more elegant way using chain identifiers. 3. Most clients already consider the nonce field to be 64-bit, such as go-ethereum. diff --git a/EIPS/eip-2733.md b/EIPS/eip-2733.md index da021a4a39a55..6816a3538b6fa 100644 --- a/EIPS/eip-2733.md +++ b/EIPS/eip-2733.md @@ -15,7 +15,7 @@ Creates a new transaction type which executes a package of one or more transactions, while passing status information to subsequent transactions. ## Abstract -After `FORK_BLOCK`, a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) +After `FORK_BLOCK`, a new [EIP-2718](./eip-2718.md) transaction of type `N` is recognized. Transactions of type `N` will define a list of transactions, which must be executed serially by clients. Execution information (e.g. `success`, `gas_used`, etc.) will be propagated forward to @@ -49,7 +49,7 @@ RESULT = result as defined below for the previous transaction, empty if its the ``` ### Serialization -After `FORK_BLOCK`, a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) +After `FORK_BLOCK`, a new [EIP-2718](./eip-2718.md) transaction type `N` will be interpreted as follows: `rlp([N, [v, r, s, chain_id, nonce, gas_price, [inner_tx_0, ..., inner_tx_n]])` diff --git a/EIPS/eip-2746.md b/EIPS/eip-2746.md index 769c6d1b6ccd4..36c65356f1ef2 100644 --- a/EIPS/eip-2746.md +++ b/EIPS/eip-2746.md @@ -28,7 +28,7 @@ pragma solidity ^0.6.0; /** @title ERC-2746 Rules Engine Standard - @dev See https://eips.ethereum.org/EIPS/eip-2746 + @dev See ./eip-2746.md */ interface ERCRulesEngine { @@ -214,7 +214,7 @@ The deployer of the contract should be the owner and administrator, allowing for ## References **Standards** -- [EIP-2535 Diamond Standard](https://eips.ethereum.org/EIPS/eip-2535) +- [EIP-2535 Diamond Standard](./eip-2535.md) ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-2926.md b/EIPS/eip-2926.md index 1ddf381337ae9..4a1d0c52d6951 100644 --- a/EIPS/eip-2926.md +++ b/EIPS/eip-2926.md @@ -20,7 +20,7 @@ Bytecode is currently the [second contributor](https://github.com/mandrigin/ethe ## Specification -This specification assumes that [EIP-2584](https://eips.ethereum.org/EIPS/eip-2584) is deployed, and the merkleization rules and gas costs are proposed accordingly. What follows is structured to have three sections: +This specification assumes that [EIP-2584](./eip-2584.md) is deployed, and the merkleization rules and gas costs are proposed accordingly. What follows is structured to have three sections: 1. How a given contract code is split into chunks and then merkleized 2. How to merkleize all existing contract codes during a hardfork @@ -56,9 +56,9 @@ To build a Merkle Patricia Tree we iterate `chunks` and process each entry, `C`, - Let the MPT value `v` be `RLP([firstInstructionOffset, C.code])`. - Insert `(k, v)` into the `codeTrie`. -We further insert a metadata leaf into `codeTrie`, with the key being `METADATA_KEY` and value being `RLP([METADATA_VERSION, codeHash, codeLength])`. This metadata is added mostly to facilitate a cheaper implementation of `EXTCODESIZE` and `EXTCODEHASH`. It includes a version to allow for differentiating between bytecode types (e.g. [EVM1.5/EIP-615](https://eips.ethereum.org/EIPS/eip-615), [EIP-2315](https://eips.ethereum.org/EIPS/eip-2315), etc.) or code merkleization schemes (or merkleization settings, such as larger `CHUNK_SIZE`) in the future. +We further insert a metadata leaf into `codeTrie`, with the key being `METADATA_KEY` and value being `RLP([METADATA_VERSION, codeHash, codeLength])`. This metadata is added mostly to facilitate a cheaper implementation of `EXTCODESIZE` and `EXTCODEHASH`. It includes a version to allow for differentiating between bytecode types (e.g. [EVM1.5/EIP-615](./eip-615.md), [EIP-2315](./eip-2315.md), etc.) or code merkleization schemes (or merkleization settings, such as larger `CHUNK_SIZE`) in the future. -The root of this `codeTrie` is computed according to the [EIP-2584](https://eips.ethereum.org/EIPS/eip-2584) rules (similar to the account trie) and stored in the account record, replacing the current `codeHash` field (henceforth called `codeRoot`). For accounts with empty code (including Externally-owned-Accounts aka EoAs) `codeRoot` will have the value `EMPTY_CODE_ROOT` (as opposed to empty `codeTrie` root hash) to maintain backwards compatibility. +The root of this `codeTrie` is computed according to the [EIP-2584](./eip-2584.md) rules (similar to the account trie) and stored in the account record, replacing the current `codeHash` field (henceforth called `codeRoot`). For accounts with empty code (including Externally-owned-Accounts aka EoAs) `codeRoot` will have the value `EMPTY_CODE_ROOT` (as opposed to empty `codeTrie` root hash) to maintain backwards compatibility. ### Updating existing code (transition process) @@ -78,7 +78,7 @@ Contract creation –– whether it is initiated via `CREATE`, `CREATE2`, or an We introduce an additional charge to account for the chunking and merkleization cost: `(ceil(len(code) / CHUNK_SIZE) + 1) * COST_PER_CHUNK`, where `COST_PER_CHUNK` is **TBD**. We also add a new fixed charge for `COST_OF_METADATA`, which equals to the cost of `rlpEncode([0, codeHash, codeSize])`. -The exact value of `COST_PER_CHUNK` is to be determined, but we estimate it will be on the order of `CHUNKING_COST + (2 * HASHING_COST) + (ceil(log2(NUM_CHUNKS)) * TREE_BUILDING_COST)`, where `HASHING_COST` is 36 (`Gkeccak256 + Gkeccak256_word`) and we have no estimate about `CHUNKING_COST` and `TREE_BUILDING_COST`. The hash cost could be reduced if the [EIP-2666](https://github.com/ethereum/EIPs/pull/2666) proposal is accepted. +The exact value of `COST_PER_CHUNK` is to be determined, but we estimate it will be on the order of `CHUNKING_COST + (2 * HASHING_COST) + (ceil(log2(NUM_CHUNKS)) * TREE_BUILDING_COST)`, where `HASHING_COST` is 36 (`Gkeccak256 + Gkeccak256_word`) and we have no estimate about `CHUNKING_COST` and `TREE_BUILDING_COST`. Preliminary cost comparison with `CHUNKING_COST=60`, `TREE_BUILDING_COST=30` and `COST_OF_METADATA=20` (note these values are *not* informed by benchmarks): @@ -98,7 +98,7 @@ There should be no change to `CODECOPY` and `CODESIZE`, because the code is alre ### Other remarks -[EIP-161](https://eips.ethereum.org/EIPS/eip-161) defines: +[EIP-161](./eip-161.md) defines: > An account is considered empty when it has no code and zero nonce and zero balance. We replace this statement with: @@ -108,7 +108,7 @@ We replace this statement with: ### Hexary vs binary trie -The Ethereum mainnet state is encoded as of now in a hexary Merkle Patricia Tree. As part of the Eth1x roadmap, a transition to a [binary trie](https://ethresear.ch/t/binary-trie-format/7621) has been [investigated](https://medium.com/@mandrigin/stateless-ethereum-binary-tries-experiment-b2c035497768) with the goal of reducing witness sizes. Because code chunks are also stored in the trie, this EIP would benefit from the witness size reduction offered by the binarification. Therefore we have decided to explicitly state [EIP-2584](https://eips.ethereum.org/EIPS/eip-2584) to be a requirement of this change. Note that if code merkleization is included in a hard-fork beforehand, then all code must be re-merkleized after the binary transition. +The Ethereum mainnet state is encoded as of now in a hexary Merkle Patricia Tree. As part of the Eth1x roadmap, a transition to a [binary trie](https://ethresear.ch/t/binary-trie-format/7621) has been [investigated](https://medium.com/@mandrigin/stateless-ethereum-binary-tries-experiment-b2c035497768) with the goal of reducing witness sizes. Because code chunks are also stored in the trie, this EIP would benefit from the witness size reduction offered by the binarification. Therefore we have decided to explicitly state [EIP-2584](./eip-2584.md) to be a requirement of this change. Note that if code merkleization is included in a hard-fork beforehand, then all code must be re-merkleized after the binary transition. ### Rationale behind chunk size @@ -137,13 +137,13 @@ Instead of encoding `codeHash` and `codeSize` in the metadata, they could be mad This proposal includes a `metadataVersion` field in the metadata, which can be used to distinguish both various merklization rules, as well as bytecodes. -An alternative option would be to move this versioning to the account level: either following [EIP-1702](https://eips.ethereum.org/EIPS/eip-1702), or by adding an `accountKind` field (with potential options: `eoa`, `merkleized_evm_chunk32`, `merkleized_eip2315_chunk64`, etc.) as the first member of the account. One benefit this could provide is omitting `codeHash` for EoAs. +An alternative option would be to move this versioning to the account level: either following [EIP-1702](./eip-1702.md), or by adding an `accountKind` field (with potential options: `eoa`, `merkleized_evm_chunk32`, `merkleized_eip2315_chunk64`, etc.) as the first member of the account. One benefit this could provide is omitting `codeHash` for EoAs. ### The keys in the code trie (and `KEY_LENGTH`) As explained in the specification above, the keys in the code trie are bytecode offsets. Since valid bytecode offsets start at `0`, there is no natural way to represent a "special key" needed for the metadata. -Even though the current bytecode limit is `0x6000` (as per [EIP-170](https://eips.ethereum.org/EIPS/eip-170)), we have decided to have a hard cap of `2^32-2` (influenced by [EIP-1985](https://eips.ethereum.org/EIPS/eip-1985)), which makes the proposal compatible with proposals increasing, or "lifting" the code size limit. +Even though the current bytecode limit is `0x6000` (as per [EIP-170](./eip-170.md)), we have decided to have a hard cap of `2^32-2` (influenced by [EIP-1985](./eip-1985.md)), which makes the proposal compatible with proposals increasing, or "lifting" the code size limit. Therefore it is safe to use `0xffffffff` as the key for the metadata. @@ -157,7 +157,7 @@ This proposal changes the meaning of the fourth field (`codeHash`) of the accoun Since `codeHash` is replaced with `codeRoot`, the root hash of the code trie, the value would be different for EoAs under the new rules: the root of the `codeTrie(metadata=[codeHash=keccak256(''), codeSize=0])`. An alternative would be simply using the hash of an empty trie. Or to avoid introducing yet another constant (the result of the above), one could also consider using `codeRoot = 0` for EoAs. -However, we wanted to maintain compatibility with [EIP-1052](https://eips.ethereum.org/EIPS/eip-1052) and decided to keep matters simple by using the hash of empty input (`c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`) for EoAs. +However, we wanted to maintain compatibility with [EIP-1052](./eip-1052.md) and decided to keep matters simple by using the hash of empty input (`c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`) for EoAs. ## Backwards Compatibility diff --git a/EIPS/eip-2929.md b/EIPS/eip-2929.md index 8498100df15e9..9a1d1404273b9 100644 --- a/EIPS/eip-2929.md +++ b/EIPS/eip-2929.md @@ -59,7 +59,7 @@ For `SLOAD`, if the `(address, storage_key)` pair (where `address` is the addres ### SSTORE changes -When calling `SSTORE`, check if the `(address, storage_key)` pair is in `accessed_storage_keys`. If it is not, charge an additional `COLD_SLOAD_COST` gas, and add the pair to `accessed_storage_keys`. Additionally, modify the parameters defined in [EIP 2200](https://eips.ethereum.org/EIPS/eip-2200) as follows: +When calling `SSTORE`, check if the `(address, storage_key)` pair is in `accessed_storage_keys`. If it is not, charge an additional `COLD_SLOAD_COST` gas, and add the pair to `accessed_storage_keys`. Additionally, modify the parameters defined in [EIP 2200](./eip-2200.md) as follows: | Parameter | Old value | New value | | - | - | - | diff --git a/EIPS/eip-607.md b/EIPS/eip-607.md index fe11ea7aac832..1186bbb13e271 100644 --- a/EIPS/eip-607.md +++ b/EIPS/eip-607.md @@ -20,10 +20,10 @@ This specifies the changes included in the hard fork named Spurious Dragon. - Block >= 2,675,000 on Mainnet - Block >= 1,885,000 on Morden - Included EIPs: - - [EIP 155](https://eips.ethereum.org/EIPS/eip-155) (Simple replay attack protection) - - [EIP 160](https://eips.ethereum.org/EIPS/eip-160) (EXP cost increase) - - [EIP 161](https://eips.ethereum.org/EIPS/eip-161) (State trie clearing) - - [EIP 170](https://eips.ethereum.org/EIPS/eip-170) (Contract code size limit) + - [EIP 155](./eip-155.md) (Simple replay attack protection) + - [EIP 160](./eip-160.md) (EXP cost increase) + - [EIP 161](./eip-161.md) (State trie clearing) + - [EIP 170](./eip-170.md) (Contract code size limit) ## References diff --git a/EIPS/eip-609.md b/EIPS/eip-609.md index daa5c6099e045..65bf65491283e 100644 --- a/EIPS/eip-609.md +++ b/EIPS/eip-609.md @@ -20,15 +20,15 @@ This specifies the changes included in the hard fork named Byzantium. - Block >= 4,370,000 on Mainnet - Block >= 1,700,000 on Ropsten testnet - Included EIPs: - - [EIP 100](https://eips.ethereum.org/EIPS/eip-100) (Change difficulty adjustment to target mean block time including uncles) - - [EIP 140](https://eips.ethereum.org/EIPS/eip-140) (REVERT instruction in the Ethereum Virtual Machine) - - [EIP 196](https://eips.ethereum.org/EIPS/eip-196) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) - - [EIP 197](https://eips.ethereum.org/EIPS/eip-197) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) - - [EIP 198](https://eips.ethereum.org/EIPS/eip-198) (Precompiled contract for bigint modular exponentiation) - - [EIP 211](https://eips.ethereum.org/EIPS/eip-211) (New opcodes: RETURNDATASIZE and RETURNDATACOPY) - - [EIP 214](https://eips.ethereum.org/EIPS/eip-214) (New opcode STATICCALL) - - [EIP 649](https://eips.ethereum.org/EIPS/eip-649) (Difficulty Bomb Delay and Block Reward Reduction) - - [EIP 658](https://eips.ethereum.org/EIPS/eip-658) (Embedding transaction status code in receipts) + - [EIP 100](./eip-100.md) (Change difficulty adjustment to target mean block time including uncles) + - [EIP 140](./eip-140.md) (REVERT instruction in the Ethereum Virtual Machine) + - [EIP 196](./eip-196.md) (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128) + - [EIP 197](./eip-197.md) (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128) + - [EIP 198](./eip-198.md) (Precompiled contract for bigint modular exponentiation) + - [EIP 211](./eip-211.md) (New opcodes: RETURNDATASIZE and RETURNDATACOPY) + - [EIP 214](./eip-214.md) (New opcode STATICCALL) + - [EIP 649](./eip-649.md) (Difficulty Bomb Delay and Block Reward Reduction) + - [EIP 658](./eip-658.md) (Embedding transaction status code in receipts) ## References diff --git a/EIPS/eip-615.md b/EIPS/eip-615.md index da50d218eeb5e..c1b31b50efe1f 100644 --- a/EIPS/eip-615.md +++ b/EIPS/eip-615.md @@ -44,7 +44,7 @@ The result is that all of the following validations and optimizations can be don ### Dependencies -> **[EIP-1702](https://eips.ethereum.org/EIPS/eip-1702). Generalized Account Versioning Scheme.** This proposal needs a versioning scheme to allow for its bytecode (and eventually eWasm bytecode) to be deployed with existing bytecode on the same blockchain. +> **[EIP-1702](./eip-1702.md). Generalized Account Versioning Scheme.** This proposal needs a versioning scheme to allow for its bytecode (and eventually eWasm bytecode) to be deployed with existing bytecode on the same blockchain. ### Proposal @@ -316,7 +316,7 @@ These changes would need to be implemented in phases at decent intervals: If desired, the period of deprecation can be extended indefinitely by continuing to accept code not versioned as new—but without validation. That is, by delaying or canceling phase 2. -Regardless, we will need a versioning scheme like [EIP-1702](https://github.com/ethereum/EIPs/pull/1702) to allow current code and EIP-615 code to coexist on the same blockchain. +Regardless, we will need a versioning scheme like [EIP-1702](./eip-1702.md) to allow current code and EIP-615 code to coexist on the same blockchain. ## Rationale diff --git a/EIPS/eip-663.md b/EIPS/eip-663.md index 5617a8ac37921..0bfd9cf7d5b04 100644 --- a/EIPS/eip-663.md +++ b/EIPS/eip-663.md @@ -75,8 +75,6 @@ TBA ## References -A similar proposal was made with [EIP-174](https://github.com/ethereum/EIPs/issues/174). Read the thread for some detailed discussion. - Rootstock [RSKIP26](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP26.md) also introduced `SWAPN` and `DUPN` with Option A described above. ## Copyright diff --git a/EIPS/eip-689.md b/EIPS/eip-689.md index 5b6935e93c238..fc820480e5896 100644 --- a/EIPS/eip-689.md +++ b/EIPS/eip-689.md @@ -20,7 +20,7 @@ Some test cases in the consensus test suite try to deploy a contract at an addre This EIP has no practical relevance to the main net history, but simplifies testing and reasoning. -This EIP has no effects after Constantinople fork because [EIP-86](https://github.com/ethereum/EIPs/pull/208) contains the changes proposed in this EIP. Even before the Constantinople fork, this EIP has no practical relevance because the change is visible only in case of a hash collision of keccak256. +This EIP has no effects after Constantinople fork because the changes proposed in this EIP are included in Constantinople. Even before the Constantinople fork, this EIP has no practical relevance because the change is visible only in case of a hash collision of keccak256. Regarding testing, this EIP relieves clients from supporting reversion of code overwriting. diff --git a/EIPS/eip-695.md b/EIPS/eip-695.md index 937126b865eb5..54cdb7bcba147 100644 --- a/EIPS/eip-695.md +++ b/EIPS/eip-695.md @@ -19,7 +19,7 @@ Include `eth_chainId` method in `eth_`-namespaced JSON-RPC methods. The `eth_chainId` method should return a single STRING result for an integer value in hexadecimal format, describing the currently configured `CHAIN_ID` value used for signing replay-protected transactions, -introduced by [EIP-155](https://eips.ethereum.org/EIPS/eip-155). +introduced by [EIP-155](./eip-155.md). ## Motivation @@ -33,7 +33,7 @@ the RPC. ### `eth_chainId` Returns the currently configured chain ID, a value used in replay-protected transaction -signing as introduced by [EIP-155](https://eips.ethereum.org/EIPS/eip-155). +signing as introduced by [EIP-155](./eip-155.md). The chain ID returned should always correspond to the information in the current known head block. This ensures that caller of this RPC method can always use the retrieved @@ -80,7 +80,7 @@ Not relevant. Consumers should prefer `eth_chainId` over `net_version`, so that they can reliably identify chain they are communicating with. -Implementers should take care to implement `eth_chainId` correctly and promote its use, since the chain ID is critical in replay attack prevention as described in [EIP-155](https://eips.ethereum.org/EIPS/eip-155), and consumers will rely on it to identify the chain they are communicating with. +Implementers should take care to implement `eth_chainId` correctly and promote its use, since the chain ID is critical in replay attack prevention as described in [EIP-155](./eip-155.md), and consumers will rely on it to identify the chain they are communicating with. ## Implementation diff --git a/EIPS/eip-712.md b/EIPS/eip-712.md index 282c8a39ff1aa..1e636f2dd52ca 100644 --- a/EIPS/eip-712.md +++ b/EIPS/eip-712.md @@ -36,7 +36,7 @@ This EIP aims to improve the usability of off-chain message signing for use on-c -Here we outline a scheme to encode data along with its structure which allows it to be displayed to the user for verification when signing. Below is an example of what a user could be shown when signing an EIP712 message. +Here we outline a scheme to encode data along with its structure which allows it to be displayed to the user for verification when signing. Below is an example of what a user could be shown when signing an EIP-712 message. @@ -95,9 +95,7 @@ The set of signable messages is extended from transactions and bytestrings `𝕋 This encoding is deterministic because the individual components are. The encoding is injective because the three cases always differ in first byte. (`RLP_encode(transaction)` does not start with `\x19`.) -The encoding is compliant with [EIP-191][eip191]. The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte domain separator `domainSeparator` and the 'data to sign' is the 32-byte `hashStruct(message)`. - -[eip191]: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-191.md +The encoding is compliant with [EIP-191](./eip-191.md). The 'version byte' is fixed to `0x01`, the 'version specific data' is the 32-byte domain separator `domainSeparator` and the 'data to sign' is the 32-byte `hashStruct(message)`. ### Definition of typed structured data `𝕊` @@ -160,12 +158,10 @@ where the type of `eip712Domain` is a struct named `EIP712Domain` with one or mo * `string name` the user readable name of signing domain, i.e. the name of the DApp or the protocol. * `string version` the current major version of the signing domain. Signatures from different versions are not compatible. -* `uint256 chainId` the [EIP-155][eip155] chain id. The user-agent *should* refuse signing if it does not match the currently active chain. +* `uint256 chainId` the [EIP-155](./eip-155.md) chain id. The user-agent *should* refuse signing if it does not match the currently active chain. * `address verifyingContract` the address of the contract that will verify the signature. The user-agent *may* do contract specific phishing prevention. * `bytes32 salt` an disambiguating salt for the protocol. This can be used as a domain separator of last resort. -[eip155]: https://eips.ethereum.org/EIPS/eip-155 - Future extensions to this standard can add new fields with new user-agent behaviour constraints. User-agents are free to use the provided information to inform/warn users or refuse signing. ### Specification of the `eth_signTypedData` JSON RPC @@ -223,10 +219,9 @@ Typed data is a JSON object containing type information, domain separator parame ##### Returns -`DATA`: Signature. As in `eth_sign` it is a hex encoded 129 byte array starting with `0x`. It encodes the `r`, `s` and `v` parameters from appendix F of the [yellow paper][yellow] in big-endian format. Bytes 0...64 contain the `r` parameter, bytes 64...128 the `s` parameter and the last byte the `v` parameter. Note that the `v` parameter includes the chain id as specified in [EIP-155][eip-155]. +`DATA`: Signature. As in `eth_sign` it is a hex encoded 129 byte array starting with `0x`. It encodes the `r`, `s` and `v` parameters from appendix F of the [yellow paper][yellow] in big-endian format. Bytes 0...64 contain the `r` parameter, bytes 64...128 the `s` parameter and the last byte the `v` parameter. Note that the `v` parameter includes the chain id as specified in [EIP-155](./eip-155.md). [yellow]: https://ethereum.github.io/yellowpaper/paper.pdf -[eip-155]: https://eips.ethereum.org/EIPS/eip-155 ##### Example @@ -244,7 +239,7 @@ Result: } ``` -An example how to use Solidity ecrecover to verify the signature calculated with `eth_signTypedData` can be found in the EIP712 [Example.js][example-js]. The contract is deployed on the testnet Ropsten and Rinkeby. +An example how to use Solidity ecrecover to verify the signature calculated with `eth_signTypedData` can be found in the EIP-712 [Example.js][example-js]. The contract is deployed on the testnet Ropsten and Rinkeby. [example-js]: https://github.com/ethereum/EIPs/blob/master/assets/eip-712/Example.js @@ -388,9 +383,7 @@ Similarly, a straightforward implementation is sub-optimal for directed acyclic Since different domains have different needs, an extensible scheme is used where the DApp specifies a `EIP712Domain` struct type and an instance `eip712Domain` which it passes to the user-agent. The user-agent can then apply different verification measures depending on the fields that are there. -A field `string eip719dsl` can be added and be rejected if the value does not match the hash of the [EIP-719][eip719] DSL interface string. - -[eip719]: https://github.com/ethereum/EIPs/issues/719 +A field `string eip719dsl` can be added and be rejected if the value does not match the hash of the **TBD** DSL interface string. ## Backwards Compatibility diff --git a/EIPS/eip-721.md b/EIPS/eip-721.md index ae2ef6633d79d..bf3f53029eee6 100644 --- a/EIPS/eip-721.md +++ b/EIPS/eip-721.md @@ -44,7 +44,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S pragma solidity ^0.4.20; /// @title ERC-721 Non-Fungible Token Standard -/// @dev See https://eips.ethereum.org/EIPS/eip-721 +/// @dev See ./eip-721.md /// Note: the ERC-165 identifier for this interface is 0x80ac58cd. interface ERC721 /* is ERC165 */ { /// @dev This emits when ownership of any NFT changes by any mechanism. @@ -177,7 +177,7 @@ The **metadata extension** is OPTIONAL for ERC-721 smart contracts (see "caveats ```solidity /// @title ERC-721 Non-Fungible Token Standard, optional metadata extension -/// @dev See https://eips.ethereum.org/EIPS/eip-721 +/// @dev See ./eip-721.md /// Note: the ERC-165 identifier for this interface is 0x5b5e139f. interface ERC721Metadata /* is ERC721 */ { /// @notice A descriptive name for a collection of NFTs in this contract @@ -221,7 +221,7 @@ The **enumeration extension** is OPTIONAL for ERC-721 smart contracts (see "cave ```solidity /// @title ERC-721 Non-Fungible Token Standard, optional enumeration extension -/// @dev See https://eips.ethereum.org/EIPS/eip-721 +/// @dev See ./eip-721.md /// Note: the ERC-165 identifier for this interface is 0x780e9d63. interface ERC721Enumerable /* is ERC721 */ { /// @notice Count NFTs tracked by this contract @@ -391,12 +391,12 @@ XXXXERC721, by William Entriken -- a scalable example implementation **Standards** -1. ERC-20 Token Standard. https://eips.ethereum.org/EIPS/eip-20 -1. ERC-165 Standard Interface Detection. https://eips.ethereum.org/EIPS/eip-165 -1. ERC-173 Owned Standard. https://eips.ethereum.org/EIPS/eip-173 +1. ERC-20 Token Standard. ./eip-20.md +1. ERC-165 Standard Interface Detection. ./eip-165.md +1. ERC-173 Owned Standard. ./eip-173.md 1. ERC-223 Token Standard. https://github.com/ethereum/EIPs/issues/223 1. ERC-677 `transferAndCall` Token Standard. https://github.com/ethereum/EIPs/issues/677 -1. ERC-827 Token Standard. https://eips.ethereum.org/EIPS/eip-827 +1. ERC-827 Token Standard. ./eip-827.md 1. Ethereum Name Service (ENS). https://ens.domains 1. Instagram -- What's the Image Resolution? https://help.instagram.com/1631821640426723 1. JSON Schema. https://json-schema.org/ diff --git a/EIPS/eip-725.md b/EIPS/eip-725.md index 8688e9cc86975..e342d6ce2d430 100644 --- a/EIPS/eip-725.md +++ b/EIPS/eip-725.md @@ -74,7 +74,7 @@ The `operationType` should represent the assembly operation as follows: - `0` for `call` - `1` for `create` -Others may be added in the future. Inspired by [ERC1077](https://eips.ethereum.org/EIPS/eip-1077) and [Gnosis](https://github.com/gnosis/safe-contracts/blob/master/contracts/Enum.sol#L7) +Others may be added in the future. Inspired by [ERC1077](./eip-1077.md) and [Gnosis](https://github.com/gnosis/safe-contracts/blob/master/contracts/Enum.sol#L7) ### Events diff --git a/EIPS/eip-777.md b/EIPS/eip-777.md index daf15ba2248e5..6e38c6d1b8277 100644 --- a/EIPS/eip-777.md +++ b/EIPS/eip-777.md @@ -1244,14 +1244,14 @@ Copyright and related rights waived via [CC0]. [operators]: #operators -[ERC20]: https://eips.ethereum.org/EIPS/eip-20 -[ERC165]: https://eips.ethereum.org/EIPS/eip-165 +[ERC20]: ./eip-20.md +[ERC165]: ./eip-165.md [ERC672]: https://github.com/ethereum/EIPs/issues/672 -[ERC777]: https://eips.ethereum.org/EIPS/eip-777 -[ERC820]: https://eips.ethereum.org/EIPS/eip-820 +[ERC777]: ./eip-777.md +[ERC820]: ./eip-820.md [ERC820a]: https://github.com/ethereum/EIPs/pull/1758 -[ERC1820]: https://eips.ethereum.org/EIPS/eip-1820 -[erc1820-set]: https://eips.ethereum.org/EIPS/eip-1820#set-an-interface-for-an-address +[ERC1820]: ./eip-1820.md +[erc1820-set]: ./eip-1820.md#set-an-interface-for-an-address [0xjac]: https://github.com/0xjac [0xjac/ERC777]: https://github.com/0xjac/ERC777 [master thesis]: https://github.com/0xjac/master-thesis diff --git a/EIPS/eip-820.md b/EIPS/eip-820.md index 0e0efd1d1671e..8ba9ee26750c7 100644 --- a/EIPS/eip-820.md +++ b/EIPS/eip-820.md @@ -100,7 +100,7 @@ interface ERC820ImplementerInterface { /// @title ERC820 Pseudo-introspection Registry Contract /// @author Jordi Baylina and Jacques Dafflon /// @notice This contract is the official implementation of the ERC820 Registry. -/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-820 +/// @notice For more details, see ./eip-820.md contract ERC820Registry { /// @notice ERC165 Invalid ID. bytes4 constant INVALID_ID = 0xffffffff; @@ -645,7 +645,7 @@ The contract has the address above for every chain on which it is deployed. }, "sources": { "./contracts/ERC820Registry.sol": { - "content": "/* ERC820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address\n * (contract or regular account) can register which interface it supports and\n * which smart contract is responsible for its implementation.\n *\n * Written in 2018 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright\n * and related and neighboring rights to this software to the public domain\n * worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along\n * with this software. If not, see\n * .\n *\n * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.4.24;\n// IV is value needed to have a vanity address starting with `0x820`.\n// IV: 9513\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n\n/// @title ERC820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC820 Registry.\n/// @notice For more details, see https://eips.ethereum.org/EIPS/eip-820\ncontract ERC820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant ERC820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC820_ACCEPT_MAGIC\"));\n\n mapping (address => mapping(bytes32 => address)) interfaces;\n mapping (address => address) managers;\n mapping (address => mapping(bytes4 => bool)) erc165Cached;\n\n /// @notice Indicates a contract is the `implementer` of `interfaceHash` for `addr`.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates `newManager` is the address of the new manager for `addr`.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// E.g., `web3.utils.keccak256('ERC777Token')`.\n /// @return The address of the contract which implements the interface `_interfaceHash` for `_addr`\n /// or `0x0` if `_addr` did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == 0 ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : 0;\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface.\n /// @param _implementer Contract address implementing _interfaceHash for _addr.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == 0 ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be a ERC165 hash\");\n if (_implementer != 0 && _implementer != msg.sender) {\n require(\n ERC820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets the `_newManager` as manager for the `_addr` address.\n /// The new manager will be able to call `setInterfaceImplementer` for `_addr`.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for `addr`.\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? 0 : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == 0) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(_contract, _interfaceId) ? _contract : 0;\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n /// The result may be cached, if not a direct lookup is performed.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = noThrowCall(_contract, ERC165ID);\n if (success == 0 || result == 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, INVALID_ID);\n if (success == 0 || result != 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, _interfaceId);\n if (success == 1 && result == 1) {\n return true;\n }\n return false;\n }\n\n /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return `true` if the hash is a ERC165 interface (ending with 28 zeroes), `false` otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\n bytes4 erc165ID = ERC165ID;\n\n assembly {\n let x := mload(0x40) // Find empty storage location using \"free memory pointer\"\n mstore(x, erc165ID) // Place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // To addr\n x, // Inputs are stored at location x\n 0x08, // Inputs are 8 bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n", + "content": "/* ERC820 Pseudo-introspection Registry Contract\n * This standard defines a universal registry smart contract where any address\n * (contract or regular account) can register which interface it supports and\n * which smart contract is responsible for its implementation.\n *\n * Written in 2018 by Jordi Baylina and Jacques Dafflon\n *\n * To the extent possible under law, the author(s) have dedicated all copyright\n * and related and neighboring rights to this software to the public domain\n * worldwide. This software is distributed without any warranty.\n *\n * You should have received a copy of the CC0 Public Domain Dedication along\n * with this software. If not, see\n * .\n *\n * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.4.24;\n// IV is value needed to have a vanity address starting with `0x820`.\n// IV: 9513\n\n/// @dev The interface a contract MUST implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface ERC820ImplementerInterface {\n /// @notice Indicates whether the contract implements the interface `interfaceHash` for the address `addr` or not.\n /// @param interfaceHash keccak256 hash of the name of the interface\n /// @param addr Address for which the contract will implement the interface\n /// @return ERC820_ACCEPT_MAGIC only if the contract implements `interfaceHash` for the address `addr`.\n function canImplementInterfaceForAddress(bytes32 interfaceHash, address addr) external view returns(bytes32);\n}\n\n\n/// @title ERC820 Pseudo-introspection Registry Contract\n/// @author Jordi Baylina and Jacques Dafflon\n/// @notice This contract is the official implementation of the ERC820 Registry.\n/// @notice For more details, see ./eip-820.md\ncontract ERC820Registry {\n /// @notice ERC165 Invalid ID.\n bytes4 constant INVALID_ID = 0xffffffff;\n /// @notice Method ID for the ERC165 supportsInterface method (= `bytes4(keccak256('supportsInterface(bytes4)'))`).\n bytes4 constant ERC165ID = 0x01ffc9a7;\n /// @notice Magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant ERC820_ACCEPT_MAGIC = keccak256(abi.encodePacked(\"ERC820_ACCEPT_MAGIC\"));\n\n mapping (address => mapping(bytes32 => address)) interfaces;\n mapping (address => address) managers;\n mapping (address => mapping(bytes4 => bool)) erc165Cached;\n\n /// @notice Indicates a contract is the `implementer` of `interfaceHash` for `addr`.\n event InterfaceImplementerSet(address indexed addr, bytes32 indexed interfaceHash, address indexed implementer);\n /// @notice Indicates `newManager` is the address of the new manager for `addr`.\n event ManagerChanged(address indexed addr, address indexed newManager);\n\n /// @notice Query if an address implements an interface and through which contract.\n /// @param _addr Address being queried for the implementer of an interface.\n /// (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// E.g., `web3.utils.keccak256('ERC777Token')`.\n /// @return The address of the contract which implements the interface `_interfaceHash` for `_addr`\n /// or `0x0` if `_addr` did not register an implementer for this interface.\n function getInterfaceImplementer(address _addr, bytes32 _interfaceHash) external view returns (address) {\n address addr = _addr == 0 ? msg.sender : _addr;\n if (isERC165Interface(_interfaceHash)) {\n bytes4 erc165InterfaceHash = bytes4(_interfaceHash);\n return implementsERC165Interface(addr, erc165InterfaceHash) ? addr : 0;\n }\n return interfaces[addr][_interfaceHash];\n }\n\n /// @notice Sets the contract which implements a specific interface for an address.\n /// Only the manager defined for that address can set it.\n /// (Each address is the manager for itself until it sets a new manager.)\n /// @param _addr Address to define the interface for. (If `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfaceHash keccak256 hash of the name of the interface as a string.\n /// For example, `web3.utils.keccak256('ERC777TokensRecipient')` for the `ERC777TokensRecipient` interface.\n /// @param _implementer Contract address implementing _interfaceHash for _addr.\n function setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer) external {\n address addr = _addr == 0 ? msg.sender : _addr;\n require(getManager(addr) == msg.sender, \"Not the manager\");\n\n require(!isERC165Interface(_interfaceHash), \"Must not be a ERC165 hash\");\n if (_implementer != 0 && _implementer != msg.sender) {\n require(\n ERC820ImplementerInterface(_implementer)\n .canImplementInterfaceForAddress(_interfaceHash, addr) == ERC820_ACCEPT_MAGIC,\n \"Does not implement the interface\"\n );\n }\n interfaces[addr][_interfaceHash] = _implementer;\n emit InterfaceImplementerSet(addr, _interfaceHash, _implementer);\n }\n\n /// @notice Sets the `_newManager` as manager for the `_addr` address.\n /// The new manager will be able to call `setInterfaceImplementer` for `_addr`.\n /// @param _addr Address for which to set the new manager.\n /// @param _newManager Address of the new manager for `addr`.\n function setManager(address _addr, address _newManager) external {\n require(getManager(_addr) == msg.sender, \"Not the manager\");\n managers[_addr] = _newManager == _addr ? 0 : _newManager;\n emit ManagerChanged(_addr, _newManager);\n }\n\n /// @notice Get the manager of an address.\n /// @param _addr Address for which to return the manager.\n /// @return Address of the manager for a given address.\n function getManager(address _addr) public view returns(address) {\n // By default the manager of an address is the same address\n if (managers[_addr] == 0) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice Compute the keccak256 hash of an interface given its name.\n /// @param _interfaceName Name of the interface.\n /// @return The keccak256 hash of an interface name.\n function interfaceHash(string _interfaceName) external pure returns(bytes32) {\n return keccak256(abi.encodePacked(_interfaceName));\n }\n\n /* --- ERC165 Related Functions --- */\n /* --- Developed in collaboration with William Entriken. --- */\n\n /// @notice Updates the cache with whether the contract implements an ERC165 interface or not.\n /// @param _contract Address of the contract for which to update the cache.\n /// @param _interfaceId ERC165 interface for which to update the cache.\n function updateERC165Cache(address _contract, bytes4 _interfaceId) external {\n interfaces[_contract][_interfaceId] = implementsERC165InterfaceNoCache(_contract, _interfaceId) ? _contract : 0;\n erc165Cached[_contract][_interfaceId] = true;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not.\n /// The result may be cached, if not a direct lookup is performed.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165Interface(address _contract, bytes4 _interfaceId) public view returns (bool) {\n if (!erc165Cached[_contract][_interfaceId]) {\n return implementsERC165InterfaceNoCache(_contract, _interfaceId);\n }\n return interfaces[_contract][_interfaceId] == _contract;\n }\n\n /// @notice Checks whether a contract implements an ERC165 interface or not without using nor updating the cache.\n /// @param _contract Address of the contract to check.\n /// @param _interfaceId ERC165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceId`, false otherwise.\n function implementsERC165InterfaceNoCache(address _contract, bytes4 _interfaceId) public view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = noThrowCall(_contract, ERC165ID);\n if (success == 0 || result == 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, INVALID_ID);\n if (success == 0 || result != 0) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, _interfaceId);\n if (success == 1 && result == 1) {\n return true;\n }\n return false;\n }\n\n /// @notice Checks whether the hash is a ERC165 interface (ending with 28 zeroes) or not.\n /// @param _interfaceHash The hash to check.\n /// @return `true` if the hash is a ERC165 interface (ending with 28 zeroes), `false` otherwise.\n function isERC165Interface(bytes32 _interfaceHash) internal pure returns (bool) {\n return _interfaceHash & 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF == 0;\n }\n\n /// @dev Make a call on a contract without throwing if the function does not exist.\n function noThrowCall(address _contract, bytes4 _interfaceId)\n internal view returns (uint256 success, uint256 result)\n {\n bytes4 erc165ID = ERC165ID;\n\n assembly {\n let x := mload(0x40) // Find empty storage location using \"free memory pointer\"\n mstore(x, erc165ID) // Place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // To addr\n x, // Inputs are stored at location x\n 0x08, // Inputs are 8 bytes long\n x, // Store output over input (saves space)\n 0x20 // Outputs are 32 bytes long\n )\n\n result := mload(x) // Load the result\n }\n }\n}\n", "keccak256": "0x8eecce3912a15087b3f5845d5a74af7712c93d0a8fcd6f2d40f07ed5032022ab" } }, @@ -884,10 +884,10 @@ The implementation is available in the repo: [jbaylina/ERC820]. ## Copyright Copyright and related rights waived via [CC0]. -[EIP155]: https://eips.ethereum.org/EIPS/eip-155 -[ERC165]: https://eips.ethereum.org/EIPS/eip-165 +[EIP155]: ./eip-155.md +[ERC165]: ./eip-165.md [ERC672]: https://github.com/ethereum/EIPs/issues/672 -[ERC820]: https://eips.ethereum.org/EIPS/eip-820 +[ERC820]: ./eip-820.md [ERC820 registry smart contract]: https://github.com/jbaylina/ERC820/blob/master/contracts/ERC820Registry.sol [manager]: #manager [lookup]: #get-an-implementation-of-an-interface-for-an-address @@ -898,7 +898,7 @@ Copyright and related rights waived via [CC0]. [Nick]: https://github.com/Arachnid/ [William Entriken]: https://github.com/fulldecent [ENS]: https://ens.domains/ -[ERC1820]: https://eips.ethereum.org/EIPS/eip-1820 +[ERC1820]: ./eip-1820.md [erc1820-annoucement]: https://github.com/ethereum/EIPs/issues/820#issuecomment-464109166 [erc820-bug]: https://github.com/ethereum/EIPs/issues/820#issuecomment-452465748 [erc820-fix]: https://github.com/ethereum/EIPs/issues/820#issuecomment-454021564 diff --git a/EIPS/eip-831.md b/EIPS/eip-831.md index 59d0741c15604..c31ae34de8dcf 100644 --- a/EIPS/eip-831.md +++ b/EIPS/eip-831.md @@ -39,7 +39,7 @@ The need for this ERC emerged when refining ERC-681. We need a container that do ## References -1. ERC-681, https://eips.ethereum.org/EIPS/eip-681 +1. ERC-681, ./eip-681.md 2. ERC-67, https://github.com/ethereum/EIPs/issues/67 ## Copyright diff --git a/EIPS/eip-868.md b/EIPS/eip-868.md index 9f71c55c7a907..921cb420b3959 100644 --- a/EIPS/eip-868.md +++ b/EIPS/eip-868.md @@ -14,7 +14,7 @@ discussions-to: https://github.com/ethereum/devp2p/issues/44 # Abstract This EIP defines an extension to Node Discovery Protocol v4 to enable authoritative -resolution of [Ethereum Node Records (ENR)](https://eips.ethereum.org/EIPS/eip-778). +resolution of [Ethereum Node Records (ENR)](./eip-778.md). # Motivation diff --git a/EIPS/eip-908.md b/EIPS/eip-908.md index f2a649d372c51..9c2bde7ca2d4a 100644 --- a/EIPS/eip-908.md +++ b/EIPS/eip-908.md @@ -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](https://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](./eip-1011.md), 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](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. +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](./eip-1015.md), 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,7 +55,7 @@ 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](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. +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](./eip-1015.md), 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](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). diff --git a/EIPS/eip-969.md b/EIPS/eip-969.md index 8b6301e621988..eb8b77d4551b7 100644 --- a/EIPS/eip-969.md +++ b/EIPS/eip-969.md @@ -159,7 +159,7 @@ An analysis can be done regarding the dispersion of these constants as compared `0x01000193`, using the following snippet. ``` c -// https://eips.ethereum.org/EIPS/eip-969 +// ./eip-969.md #include #include diff --git a/EIPS/eip-998.md b/EIPS/eip-998.md index 6eaf40ffb5301..41c6f9279d2a0 100644 --- a/EIPS/eip-998.md +++ b/EIPS/eip-998.md @@ -11,9 +11,9 @@ requires: 165, 721 --- ## Simple Summary -An extension of the [ERC721 standard](https://eips.ethereum.org/EIPS/eip-721) to enable ERC721 tokens to own other ERC721 tokens and ERC20 tokens. +An extension of the [ERC721 standard](./eip-721.md) to enable ERC721 tokens to own other ERC721 tokens and ERC20 tokens. -An extension of the [ERC20](https://eips.ethereum.org/EIPS/eip-20) and [ERC223](https://github.com/ethereum/EIPs/issues/223) standards to enable ERC20 and ERC223 tokens to be owned by ERC721 tokens. +An extension of the [ERC20](./eip-20.md) and [ERC223](https://github.com/ethereum/EIPs/issues/223) standards to enable ERC20 and ERC223 tokens to be owned by ERC721 tokens. This specification covers four different kinds of composable tokens: @@ -48,15 +48,15 @@ A non-fungible token is ERC998 compliant and is an ERC998 Composable if it imple ### ERC721 -ERC998ERC721 top-down, ERC998ERC20 top-down, and ERC998ERC721 bottom-up composable contracts must implement the [ERC721 interface](https://eips.ethereum.org/EIPS/eip-721). +ERC998ERC721 top-down, ERC998ERC20 top-down, and ERC998ERC721 bottom-up composable contracts must implement the [ERC721 interface](./eip-721.md). ### ERC20 -ERC998ERC20 bottom-up composable contracts must implement the [ERC20 interface](https://eips.ethereum.org/EIPS/eip-20). +ERC998ERC20 bottom-up composable contracts must implement the [ERC20 interface](./eip-20.md). ### ERC165 -The [ERC165 standard](https://eips.ethereum.org/EIPS/eip-165) must be applied to each ERC998 interface that is used. +The [ERC165 standard](./eip-165.md) must be applied to each ERC998 interface that is used. ### Authentication diff --git a/ISSUE_TEMPLATE.md b/ISSUE_TEMPLATE.md index f18eb4fd1e988..61f357858bf11 100644 --- a/ISSUE_TEMPLATE.md +++ b/ISSUE_TEMPLATE.md @@ -3,7 +3,7 @@ ATTENTION! If you would like to submit an EIP and it has already been written as If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion. Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive. -Keep in mind the following guidelines from [EIP-1](https://eips.ethereum.org/EIPS/eip-1): +Keep in mind the following guidelines from [EIP-1](./eip-1.md): > Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this. diff --git a/README.md b/README.md index 7e4772276c9f0..b2e560689a49a 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ A browsable version of all current and draft EIPs can be found on [the official # Contributing - 1. Review [EIP-1](EIPS/eip-1.md). + 1. Review [EIP-1](./EIPS/eip-1.md). 2. Fork the repository by clicking "Fork" in the top right. 3. Add your EIP to your fork of the repository. There is a [template EIP here](eip-template.md). 4. Submit a Pull Request to Ethereum's [EIPs repository](https://github.com/ethereum/EIPs).