update

EIPS/eip-1319.md

@@ -60,7 +60,7 @@ Implementations are free to choose any scheme for generating a **releaseId**. A
 function generateReleaseId(string packageName, string version)
   public
   view
-  returns (bytes32)
+  returns (bytes32 releaseId)
   {
     return keccak256(abi.encodePacked(packageName, version));
   }
@@ -114,21 +114,21 @@ The read API consists of a set of methods that allows tooling to extract all con
 function getAllPackageIds(uint offset, uint limit) public view
   returns (
     bytes32[] packageIds,
-    uint offset
+    uint pointer
   );
 
 // Retrieves the unique string `name` associated with a package's id.
-function getPackageName(bytes32 packageId) public view returns (string name);
+function getPackageName(bytes32 packageId) public view returns (string packageName);
 
 // Retrieves the registry's unique identifier for an existing release of a package.
-function getReleaseId(string packageName, string version) public view returns (bytes32);
+function getReleaseId(string packageName, string version) public view returns (bytes32 releaseId);
 
 // Retrieves a slice of the list of all release ids for a package.
 // `offset` and `limit` enable paginated responses / retrieval of the complete set. (See note below)
 function getAllReleaseIds(string packageName, uint offset, uint limit) public view
   returns (
-    bytes32[] ids,
-    uint offset
+    bytes32[] releaseIds,
+    uint pointer
   );
 
 // Retrieves package name, release version and URI location data for a release id.
@@ -144,7 +144,7 @@ function getReleaseData(bytes32 releaseId) public view
 function generateReleaseId(string packageName, string version)
   public
   view
-  returns (bytes32);
+  returns (bytes32 releaseId);
 
 // Returns the total number of unique packages in a registry.
 function numPackageIds() public view returns (uint totalCount);
@@ -154,7 +154,7 @@ function numReleaseIds(string packageName) public view returns (uint totalCount)
 ```
 **Pagination**
 
-`getAllPackageIds` and `getAllReleaseIds` support paginated requests because it's possible that the return values for these methods could become quite large. The methods should return an `offset` that is a pointer to the next available item in a list of all items such that a caller can use it to pick up from where the previous request left off.  (See [here](https://mixmax.com/blog/api-paging-built-the-right-way) for a discussion of the merits and demerits of various pagination strategies.) The `limit` parameter defines the maximum number of items a registry should return per request.
+`getAllPackageIds` and `getAllReleaseIds` support paginated requests because it's possible that the return values for these methods could become quite large. The methods should return a `pointer` that points to the next available item in a list of all items such that a caller can use it to pick up from where the previous request left off.  (See [here](https://mixmax.com/blog/api-paging-built-the-right-way) for a discussion of the merits and demerits of various pagination strategies.) The `limit` parameter defines the maximum number of items a registry should return per request.
 
 ## Rationale
 The proposal hopes to accomplish the following:

EIPS/eip-1344.md

@@ -1,16 +1,43 @@
 ---
 eip: 1344
 title: ChainID opcode
-author: Richard Meissner (@rmeissner)
+author: Richard Meissner (@rmeissner), Bryant Eisenbach (@fubuloubu)
 discussions-to: https://ethereum-magicians.org/t/add-chain-id-opcode-for-replay-protection-when-handling-signed-messages-in-contracts/1131
 category: Core
 type: Standards Track
-status: Draft
+status: Last Call
 created: 2018-08-22
+review-period-end: 2019-04-30
 ---
- ### Specification
- Adds a new opcode at 0x46, which takes 0 stack arguments. It will return the chain id of the chain where the block was mined. It should cost 2 gas (G_base) to execute this opcode.
- ### Motivation
- [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/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. 
- The current approach proposed by [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md) is to specify the chain id on compile time. Using this approach will result in problems after a hardfork. 
- By adding the opcode it would be possible to access the current chain id and validate signatures based on that.
+
+## Abstract
+This EIP adds an opcode that returns the current chain's EIP-155 unique identifier.
+
+## Motivation
+[EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/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](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md).
+
+## Specification
+Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It will push the current chain ID onto the stack. The operation costs `G_base` to execute.
+
+## Rationale
+The current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages. 
+By adding the proposed opcode it will be possible to access the current chain ID and validate signatures based on that.
+
+Currently, there is no specification for how chain ID is set for a particular network, relying on choices made manually by the client implementers and the chain community. There is a potential scenario where, during a "contentious split" over a divisive issue, a community using a particular value of chain ID will make a decision to split into two such chains. When this scenario occurs, it will be unsafe to maintain chain ID to the same value on both chains, as chain ID is used for replay protection for in-protocol transactions (per EIP-155), as well as for L2 and "meta-transaction" use cases (per EIP-712 as enabled by this proposal). There are two potential resolutions in this scenario under the current process: 1) one chain decides to modify their value of chain ID (while the other keeps it), or 2) both chains decide to modify their value of chain ID.
+
+In order to mitigate this situation, users of the proposed `CHAINID` opcode **must** ensure that their application can handle a potential update to the value of chain ID during their usage of their application in case this does occur, if required for the continued use of the application. A Trustless Oracle that logs the timestamp when a change is made to chain ID can be implemented either as an application-level feature inside the application contract system, or referenced as a globally standard contract. Failure to provide a mitigation for this scenario could lead to a sudden loss of legitimacy of previously signed off-chain messages, which could be an issue during settlement periods and other longer-term verification events for these types of messages. Not all applications of this opcode may need mitigations to handle this scenario, but developers should provide reasoning on a case-by-case basis.
+
+## Backwards Compatibility
+This EIP is fully backwards compatible with all chains which implement EIP-155 chain ID domain separator for transaction signing.
+
+## References
+This was previously suggested as part of [EIP901](https://github.com/ethereum/EIPs/issues/901).
+
+## Test Cases
+TBD
+
+## Implementation
+A sample implementation was attempted here: https://github.com/fubuloubu/py-evm/commit/eaab5ffa2164d4cc06ae5c855a49d030965be828
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1577.md

@@ -42,6 +42,8 @@ When resolving a `contenthash`, applications MUST use the protocol code to deter
 
 ### Example
 
+#### IPFS
+
 Input data:
 
 ```
@@ -65,6 +67,35 @@ Text format:
 ipfs://QmRAQB6YaCyidP37UdDnjFY5vQuiBrcqdyoW1CuDgwxkD4
 ```
 
+### Swarm
+
+Input data:
+
+```
+storage system: Swarm (0xe4)
+CID version: 1 (0x01)
+content type: swarm-manifest (0xfa)
+hash function: keccak256 (0x1b)
+hash length: 32 bytes (0x20)
+hash: d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
+```
+
+Binary format:
+```
+0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
+```
+
+Text format:
+```
+bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
+```
+
+Example usage with swarm hash:
+```
+$ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162                                 
+> e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162
+```
+
 ### Fallback
 
 In order to support names that have an IPFS or Swarm hash in their `content` field, a grace period MUST be implemented offering those name holders time to update their names. If a resolver does not support the `multihash` interface, it MUST be checked whether they support the `content` interface. If they do, the value of that field SHOULD be treated in a context dependent fashion and resolved. This condition MUST be enforced until at least March 31st, 2019.

EIPS/eip-1679.md

@@ -2,6 +2,7 @@
 eip: 1679
 title: "Hardfork Meta: Istanbul"
 author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)
+discussions-to: https://ethereum-magicians.org/t/hardfork-meta-istanbul-discussion/3207
 type: Meta
 status: Draft
 created: 2019-01-04
@@ -16,11 +17,31 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista
 
 - Codename: Istanbul
 - Activation: TBD
-- Included EIPs: TBD
+
+### Included EIPs
+
+- TBD
+
+### Accepted EIPs
+
+- TBD
+
+### Proposed EIPs
+
+- [EIP-1344](https://eips.ethereum.org/EIPS/eip-1344): Add ChainID opcode
+- [EIP-1352](https://eips.ethereum.org/EIPS/eip-1352): Specify restricted address range for precompiles/system contracts
+- [EIP-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme
+
+## Timeline
+
+* 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"
+* 2019-07-19 (Fri) soft deadline for major client implementations
+* 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet)
+* 2019-10-16 (Wed) projected date for mainnet upgrade ("Istanbul")
 
 ## References
 
-TBA
+- [Core Dev call notes](https://github.com/ethereum/pm/issues/66#issuecomment-450840440) where timeline was proposed and accepted
 
 ## Copyright
 

EIPS/eip-1890.md

@@ -0,0 +1,53 @@
+---
+eip: 1890
+title: Commitment to Sustainable Ecosystem Funding
+author: Gregory Markou <[email protected]>, Kevin Owocki <[email protected]>, Lane Rettig <[email protected]>
+discussions-to: https://t.me/joinchat/DwEd_xahL5hHvzNYH2RnQA
+status: Draft
+type: Standards Track
+category: Core
+created: 2019-03-31
+---
+
+# Commitment to Sustainable Ecosystem Funding
+
+## Simple Summary
+
+Ethereum currently provides a block reward to proof of work miners every block, but it does not capture any block rewards for ecosystem funding. This EIP adds a simple mechanism for capturing a portion of block rewards for ecosystem funding as a credible commitment to doing so in future, but it does not actually capture any such rewards.
+
+## Abstract
+
+A mechanism that allows specification of two parameters, a beneficiary address and a per-block reward denominated in wei, that allows a portion of block rewards to be captured for the purpose of ecosystem funding. Both values are set to zero.
+
+## Motivation
+
+In order for Ethereum to succeed, it needs talented, motivated researchers and developers to continue to develop and maintain the platform. Those talented researchers and developers deserve to be paid fairly for their work. At present there is no mechanism in the Ethereum ecosystem that rewards R&D teams fairly for their work on the platform.
+
+We recognize that, while technically trivial, the real challenge in inflation-based funding is social: how to fairly capture, govern, and distribute block rewards. It will take time to work out the answer to these questions. For this reason, this EIP only seeks to make a credible commitment on the part of core developers to securing the funding they need to keep Ethereum alive and healthy by adding a mechanism to do so, but the actual amount of rewards captured remains at zero, i.e., there is no change at present to Ethereum’s economics. Raising the amount captured above zero would require a future EIP.
+
+## Specification
+
+Two new constants are introduced: BENEFICIARY_ADDRESS, an Address, and DEVFUND_BLOCK_REWARD, an amount denominated in wei. Both are set to zero.
+
+Beginning with block ISTANBUL_BLOCK_HEIGHT, DEVFUND_BLOCK_REWARD wei is added to the balance of BENEFICIARY_ADDRESS at each block.
+
+We may optionally add another constant, DECAY_FACTOR, which specifies a linear or exponenential decay factor that reduces the reward at every block > ISTANBUL_BLOCK_HEIGHT until it decays to zero. For simplicity, it has been omitted from this proposal.
+
+## Rationale
+
+We believe that the technical design of this EIP is straightforward. The social rationale is explained in [this article](https://medium.com/gitcoin/funding-open-source-in-the-blockchain-era-8ded753bf05f).
+
+## Backwards Compatibility
+
+This EIP has no impact on backwards compatibility.
+
+## Test Cases
+
+This EIP makes no changes to existing state transitions. Existing consensus tests should be sufficient.
+
+## Implementation
+
+Reference implementations are included for the Trinity, go-ethereum, and parity clients.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).