status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master'

This commit is contained in:
Jack Peterson 2017-12-15 11:31:13 -08:00
parent 69194eab82 5781898510
commit da84b4a13c
15 changed files with 714 additions and 68 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
EIPS/eip-1.md
View File

@ -103,6 +103,10 @@ Each EIP should have the following parts:
- Implementations - The implementations must be completed before any EIP is given status “Final”, but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of API details.
<!-- -->
- Copyright Waiver - All EIPs must be in public domain. See the bottom of this EIP for an example copyright waiver.
EIP Formats and Templates
-------------------------
@ -174,19 +178,13 @@ The current EIP editors are
` * Casey Detrio (@cdetrio)`
` * Fabian Vogelsteller (@frozeman)`
` * Gavin Wood (@gavofyork)`
` * Hudson Jameson (@Souptacular)`
` * Jeffrey Wilcke (@obscuren)`
` * Martin Becze (@wanderer)`
` * Nick Johnson (@arachnid)`
` * Roman Mandeleil (@romanman)`
` * Yoichi Hirai (@pirapira)`
` * Vitalik Buterin (@vbuterin)`
@ -237,7 +235,7 @@ February 1, 2016: EIP 1 has added editors, made draft improvements to process, a
[devp2p]: https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol
[EIP8]: 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://gist.github.com/gluk256/4654922ca45eb9d0846d941d7ca326f4
[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
[EIP59]: https://github.com/ethereum/EIPs/issues/59
@ -260,3 +258,8 @@ February 1, 2016: EIP 1 has added editors, made draft improvements to process, a
[README.md]: README.md "wikilink"
[Bitcoin's BIP-0001]: https://github.com/bitcoin/bips
[Python's PEP-0001]: https://www.python.org/dev/peps/
Copyright
---------
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

39
EIPS/eip-100.md Normal file
View File

@ -0,0 +1,39 @@
```
EIP: 100
Title: Change difficulty adjustment to target mean block time including uncles
Author: Vitalik Buterin
Type: Standard Track
Category: Core
Status: Final
Created: 2016-04-28
```
### Specification
Currently, the formula to compute the difficulty of a block includes the following logic:
``` python
adj_factor = max(1 - ((timestamp - parent.timestamp) // 10), -99)
child_diff = int(max(parent.difficulty + (parent.difficulty // BLOCK_DIFF_FACTOR) * adj_factor, min(parent.difficulty, MIN_DIFF)))
...
```
If `block.number >= BYZANTIUM_FORK_BLKNUM`, we change the first line to the following:
``` python
adj_factor = max((2 if len(parent.uncles) else 1) - ((timestamp - parent.timestamp) // 9), -99)
```
### Rationale
This new formula ensures that the difficulty adjustment algorithm targets a constant average rate of blocks produced including uncles, and so ensures a highly predictable issuance rate that cannot be manipulated upward by manipulating the uncle rate. A formula that accounts for the exact number of included uncles:
``` python
adj_factor = max(1 + len(parent.uncles) - ((timestamp - parent.timestamp) // 9), -99)
```
can be fairly easily seen to be (to within a tolerance of ~3/4194304) mathematically equivalent to assuming that a block with `k` uncles is equivalent to a sequence of `k+1` blocks that all appear with the exact same timestamp, and this is likely the simplest possible way to accomplish the desired effect. But since the exact formula depends on the full block and not just the header, we are instead using an approximate formula that accomplishes almost the same effect but has the benefit that it depends only on the block header (as you can check the uncle hash against the blank hash).
Changing the denominator from 10 to 9 ensures that the block time remains roughly the same (in fact, it should decrease by ~3% given the current uncle rate of 7%).
### References
1. EIP 100 issue and discussion: https://github.com/ethereum/EIPs/issues/100
2. https://bitslog.wordpress.com/2016/04/28/uncle-mining-an-ethereum-consensus-protocol-flaw/

58
EIPS/eip-140.md Normal file
View File

@ -0,0 +1,58 @@
## Preamble
EIP: 140
Title: REVERT instruction
Author: Alex Beregszaszi, Nikolai Mushegian (nikolai@nexusdev.us)
Type: Standard Track
Category: Core
Status: Final
Created: 2017-02-06
## Simple Summary
The `REVERT` instruction provides a way to stop execution and revert state changes, without consuming all provided gas and with the ability to return a reason.
## Abstract
The `REVERT` instruction will stop execution, roll back all state changes done so far and provide a pointer to a memory section, which can be interpreted as an error code or message. While doing so, it will not consume all the remaining gas.
## Motivation
Currently this is not possible. There are two practical ways to revert a transaction from within a contract: running out of gas or executing an invalid instruction. Both of these options will consume all remaining gas. Additionally, reverting an EVM execution means that all changes, including LOGs, are lost and there is no way to convey a reason for aborting an EVM execution.
## Specification
On blocks with `block.number >= BYZANTIUM_FORK_BLKNUM`, the `REVERT` instruction is introduced at `0xfd`. It expects two stack items, the top item is the `memory_offset` followed by `memory_length`. It does not produce any stack elements because it stops execution.
The semantics of `REVERT` with respect to memory and memory cost are identical to those of `RETURN`. The sequence of bytes given by `memory_offset` and `memory_length` is called "error message" in the following.
The effect of `REVERT` is that execution is aborted, considered as failed, and state changes are rolled back. The error message will be available to the caller in the returndata buffer and will also be copied to the output area, i.e. it is handled in the same way as the regular return data is handled.
The cost of the `REVERT` instruction equals to that of the `RETURN` instruction, i.e. the rollback itself does not consume all gas, the contract only has to pay for memory.
In case there is not enough gas left to cover the cost of `REVERT` or there is a stack underflow, the effect of the `REVERT` instruction will equal to that of a regular out of gas exception, i.e. it will consume all gas.
In the same way as all other failures, the calling opcode returns `0` on the stack following a `REVERT` opcode in the callee.
In case `REVERT` is used in the context of a `CREATE` or `CREATE2` call, no code is deployed, `0` is put on the stack and the error message is available in the returndata buffer.
The content of the optionally provided memory section is not defined by this EIP, but is a candidate for another Informational EIP.
## Backwards Compatibility
This change has no effect on contracts created in the past unless they contain `0xfd` as an instruction.
## Test Cases
```
6c726576657274656420646174616000557f726576657274206d657373616765000000000000000000000000000000000000600052600e6000fd
```
should:
- return `0x726576657274206d657373616765` as `REVERT` data,
- the storage at key `0x0` should be left as unset and
- use 20024 gas in total.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

6
EIPS/eip-161.md
View File

@ -50,7 +50,13 @@ Same as #158 except that several edge cases are avoided since we do not break in
`CREATE` avoids zero in the nonce to avoid any suggestion of the oddity of `CREATE`d accounts being reaped half-way through their creation.
# Addendum (2017-08-15)
On 2016-11-24, a consensus bug occurred due to two implementations having different behavior in the case of state reverts.[3] The specification was amended to clarify that empty account deletions are reverted when the state is reverted.
# References
1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158
2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161
3. https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/
> Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes.

106
EIPS/eip-196.md Normal file
View File

@ -0,0 +1,106 @@
## Preamble
EIP: 196
Title: Precompiled contracts for addition and scalar multiplication
on the elliptic curve alt_bn128
Author: Christian Reitwiessner<chris@ethereum.org>
Type: Standard Track
Category: Core
Status: Final
Created: 2017-02-02
## Simple Summary
Precompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit.
## Abstract
This EIP suggests to add precompiled contracts for addition and scalar multiplication on a specific pairing-friendly elliptic curve. This can in turn be combined with [EIP-197](./eip-197.md) to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property).
## Motivation
Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive
to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced.
Note that while fixing these parameters might look like limiting the use-cases for zkSNARKs, the primitives are so basic that they can be combined in ways that are flexible enough so that it should even be possible to allow future advances in zkSNARK research without the need for a further hard fork.
## Specification
If `block.number >= BYZANTIUM_FORK_BLKNUM`, add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve "alt_bn128".
Address of ADD: 0x6
Address for MUL: 0x7
The curve is defined by:
```
Y^2 = X^3 + 3
over the field F_p with
p = 21888242871839275222246405745257275088696311157297823662689037894645226208583
```
### Encoding
Field elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements `(x, y)`, where the point at infinity is encoded as `(0, 0)`.
Tuples of objects are encoded as their concatenation.
For both precompiled contracts, if the input is shorter than expected, it is assumed to be virtually padded with zeros at the end (i.e. compatible with the semantics of the `CALLDATALOAD` opcode). If the input is longer than expected, surplus bytes at the end are ignored.
The length of the returned data is always as specified (i.e. it is not "unpadded").
### Exact semantics
Invalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates) is equal or larger than the field modulus p, the contract fails. The scalar can be any number between `0` and `2**256-1`.
#### ADD
Input: two curve points `(x, y)`.
Output: curve point `x + y`, where `+` is point addition on the elliptic curve `alt_bn128` specified above.
Fails on invalid input and consumes all gas provided.
#### MUL
Input: curve point and scalar `(x, s)`.
Output: curve point `s * x`, where `*` is the scalar multiplication on the elliptic curve `alt_bn128` specified above.
Fails on invalid input and consumes all gas.
### Gas costs
- Gas cost for ``ECADD``: 500
- Gas cost for ``ECMUL``: 40000
## Rationale
The specific curve `alt_bn128` was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts.
The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification: The gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve.
A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).
## Backwards Compatibility
As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256.
## Test Cases
Inputs to test:
- Curve points which would be valid if the numbers were taken mod p (should fail).
- Both contracts should succeed on empty input.
- Truncated input that results in a valid curve point.
- Points not on curve (but valid otherwise).
- Multiply point with scalar that lies between the order of the group and the field (should succeed).
- Multiply point with scalar that is larger than the field order (should succeed).
## Implementation
Implementation of these primitives are available here:
- [libff](https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.cpp) (C++)
- [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust)
In both codebases, a specific group on the curve alt_bn128 is used and is called G1.
- [Python](https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_curve.py) - probably most self-contained and best readable.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

142
EIPS/eip-197.md Normal file
View File

@ -0,0 +1,142 @@
## Preamble
EIP: 197
Title: Precompiled contracts for optimal ate pairing check
on the elliptic curve alt_bn128
Author: Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>
Type: Standard Track
Category: Core
Status: Final
Created: 2017-02-06
## Simple Summary
Precompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit.
## Abstract
This EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with [EIP-196](./eip-196.md) to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property).
## Motivation
Current smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive
to fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced.
Note that fixing these parameters will in no way limit the use-cases for zkSNARKs, it will even allow for incorporating some advances in zkSNARK research without the need for a further hard fork.
Pairing functions can be used to perform a limited form of multiplicatively homomorphic operations, which are necessary for current zkSNARKs. This precompile can be used to run such computations within the block gas limit. This precompiled contract only specifies a certain check, and not an evaluation of a pairing function. The reason is that the codomain of a pairing function is a rather complex field which could provide encoding problems and all known uses of pairing function in zkSNARKs only require the specified check.
## Specification
For blocks where `block.number >= BYZANTIUM_FORK_BLKNUM`, add a precompiled contracts for a bilinear function on groups on the elliptic curve "alt_bn128". We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below.
Address: 0x8
For a cyclic group `G` (written additively) of prime order `q` let `log_P: G -> F_q` be the discrete logarithm on this group with respect to a generator `P`, i.e. `log_P(x)` is the smallest non-negative integer `n` such that `n * P = x`.
The precompiled contract is defined as follows, where the two groups `G_1` and `G_2` are defined by their generators `P_1` and `P_2` below. Both generators have the same prime order `q`.
```
Input: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k
Output: If the length of the input is incorrect or any of the inputs are not elements of
the respective group or are not encoded correctly, the call fails.
Otherwise, return one if
log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0
(in F_q) and zero else.
```
Note that `k` is determined from the length of the input. Following the section on the encoding below,
`k` is the length of the input divided by `192`. If the input length is not a multiple of `192`,
the call fails. Empty input is valid and results in returning one.
In order to check that an input is an element of `G_1`, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For `G_2`, in addition to that, the order of the element has to be checked to be equal to the group order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617`.
### Definition of the groups
The groups `G_1` and `G_2` are cyclic groups of prime order `q = 21888242871839275222246405745257275088548364400416034343698204186575808495617` on the elliptic curve `alt_bn128` defined by the curve equation
`Y^2 = X^3 + 3`.
The group `G_1` is a cyclic group on the above curve over the field `F_p` with `p = 21888242871839275222246405745257275088696311157297823662689037894645226208583` with generator `P1 = (1, 2)`.
The group `G_2` is a cyclic group on the same elliptic curve over a different field `F_p^2 = F_p[i] / (i^2 + 1)` (p is the same as above) with generator
```
P2 = (
11559732032986387107991004021392285783925812861821192530917403151452391805634 * i +
10857046999023057135944570762232829481370756359578518086990519993285655852781,
4082367875863433681332203403145435568316851327593401208105741076214120093531 * i +
8495653923123431417604973247489272438418190587263600148770280649306958101930
)
```
Note that `G_2` is the only group of order `q` of that elliptic curve over the field `F_p^2`. Any other generator of order `q` instead of `P2` would define the same `G_2`. However, the concrete value of `P2` is useful for skeptical readers who doubt the existence of a group of order `q`. They can be instructed to compare the concrete values of `q * P2` and `P2`.
### Encoding
Elements of `F_p` are encoded as 32 byte big-endian numbers. An encoding value of `p` or larger is invalid.
Elements `a * i + b` of `F_p^2` are encoded as two elements of `F_p`, `(a, b)`.
Elliptic curve points are encoded as a Jacobian pair `(X, Y)` where the point at infinity is encoded as `(0, 0)`.
Note that the number `k` is derived from the input length.
The length of the returned data is always exactly 32 bytes and encoded as a 32 byte big-endian number.
### Gas costs
The gas costs of the precompiled contract are `80 000 * k + 100 000`, where `k` is the number of
points or, equivalently, the length of the input divided by 192.
## Rationale
The specific curve `alt_bn128` was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts.
The feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification; the gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve or does not admit an efficient pairing implementation.
A non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).
The encoding of field elements in `F_p^2` was chosen in this order to be in line with the big endian encoding of the elements themselves.
## Backwards Compatibility
As with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the "reserved range" below 256.
## Test Cases
To be written.
## Implementation
The precompiled contract can be implemented using elliptic curve pairing functions, more specifically, an optimal ate pairing on the alt_bn128 curve, which can be implemented efficiently. In order to see that, first note that a pairing function `e: G_1 x G_2 -> G_T` fulfills the following properties (`G_1` and `G_2` are written additively, `G_T` is written multiplicatively):
(1) `e(m * P1, n * P2) = e(P1, P2)^(m * n)`
(2) `e` is non-degenerate
Now observe that
```
log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q)
```
if and only if
```
e(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = 1 (in G_T)
```
Furthermore, the left hand side of this equation is equal to
```
e(log_P1(a1) * P1, log_P2(b1) * P2) * ... * e(log_P1(ak) * P1, log_P2(bk) * P2)
= e(a1, b1) * ... * e(ak, bk)
```
And thus, the precompiled contract can be implemented by verifying that
`e(a1, b1) * ... * e(ak, bk) = 1`
Implementations are available here:
- [libff](https://github.com/scipr-lab/libff/blob/master/libff/algebra/curves/alt_bn128/alt_bn128_g1.hpp) (C++)
- [bn](https://github.com/zcash/bn/blob/master/src/groups/mod.rs) (Rust)
- [Python](https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_pairing.py)
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

6
EIPS/eip-20-token-standard.md
View File

@ -96,8 +96,6 @@ function balanceOf(address _owner) constant returns (uint256 balance)
Transfers `_value` amount of tokens to address `_to`, and MUST fire the `Transfer` event.
The function SHOULD `throw` if the `_from` account balance does not have enough tokens to spend.
A token contract which creates new tokens SHOULD trigger a Transfer event with the `_from` address set to `0x0` when tokens are created.
*Note* Transfers of 0 values MUST be treated as normal transfers and fire the `Transfer` event.
``` js
@ -128,7 +126,7 @@ Allows `_spender` to withdraw from your account multiple times, up to the `_valu
**NOTE**: To prevent attack vectors like the one [described here](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/) and discussed [here](https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729),
clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to `0` before setting it to another value for the same spender.
THOUGH The contract itself shouldn't enforce it, to allow backwards compatilibilty with contracts deployed before
THOUGH The contract itself shouldn't enforce it, to allow backwards compatibility with contracts deployed before
``` js
function approve(address _spender, uint256 _value) returns (bool success)
@ -152,6 +150,8 @@ function allowance(address _owner, address _spender) constant returns (uint256 r
MUST trigger when tokens are transferred, including zero value transfers.
A token contract which creates new tokens SHOULD trigger a Transfer event with the `_from` address set to `0x0` when tokens are created.
``` js
event Transfer(address indexed _from, address indexed _to, uint256 _value)
```

66
EIPS/eip-211.md Normal file
View File

@ -0,0 +1,66 @@
## Preamble
EIP: 211
Title: New opcodes: RETURNDATASIZE and RETURNDATACOPY
Author: Christian Reitwiessner <chris@ethereum.org>
Type: Standard Track
Category Core
Status: Final
Created: 2017-02-13
Requires:
Replaces: 5/8
## Simple Summary
A mechanism to allow returning arbitrary-length data inside the EVM has been requested for quite a while now. Existing proposals always had very intricate problems associated with charging gas. This proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. Its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. At the next call, the buffer is overwritten. This mechanism is 100% backwards compatible.
## Abstract
Please see summary.
## Motivation
In some situations, it is vital for a function to be able to return data whose length cannot be anticipated before the call. In principle, this can be solved without alterations to the EVM, for example by splitting the call into two calls where the first is used to compute only the size. All of these mechanisms, though, are very expensive in at least some situations. A very useful example of such a worst-case situation is a generic forwarding contract; a contract that takes call data, potentially makes some checks and then forwards it as is to another contract. The return data should of course be transferred in a similar way to the original caller. Since the contract is generic and does not know about the contract it calls, there is no way to determine the size of the output without adapting the called contract accordingly or trying a logarithmic number of calls.
Compiler implementors are advised to reserve a zero-length area for return data if the size of the return data is unknown before the call and then use `RETURNDATACOPY` in conjunction with `RETURNDATASIZE` to actually retrieve the data.
Note that this proposal also makes the EIP that proposes to allow to return data in case of an intentional state reversion ([EIP-140](./eip-140.md)) much more useful. Since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the CALL opcode has signalled a failure, even if the regular output area is not large enough to hold the data.
## Specification
If `block.number >= BYZANTIUM_FORK_BLKNUM`, add two new opcodes and amend the semantics of any opcode that creates a new call frame (like `CALL`, `CREATE`, `DELEGATECALL`, ...) called call-like opcodes in the following. It is assumed that the EVM (to be more specific: an EVM call frame) has a new internal buffer of variable size, called the return data buffer. This buffer is created empty for each new call frame. Upon executing any call-like opcode, the buffer is cleared (its size is set to zero). After executing a call-like opcode, the complete return data (or failure data, see [EIP-140](./eip-140.md)) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. As an exception, `CREATE` and `CREATE2` are considered to return the empty buffer in the success case and the failure data in the failure case. If the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty.
As an optimization, it is possible to share the return data buffer across call frames because at most one will be non-empty at any time.
`RETURNDATASIZE`: `0x3d`
Pushes the size of the return data buffer onto the stack.
Gas costs: 2 (same as `CALLDATASIZE`)
`RETURNDATACOPY`: `0x3e`
This opcode has similar semantics to `CALLDATACOPY`, but instead of copying data from the call data, it copies data from the return data buffer. Furthermore, accessing the return data buffer beyond its size results in a failure; i.e. if `start + length` overflows or results in a value larger than `RETURNDATASIZE`, the current call stops in an out-of-gas condition. In particular, reading 0 bytes from the end of the buffer will read 0 bytes; reading 0 bytes from one-byte out of the buffer causes an exception.
Gas costs: `3 + 3 * ceil(amount / 32)` (same as `CALLDATACOPY`)
## Rationale
Other solutions that would allow returning dynamic data were considered, but they all had to deduct the gas from the call opcode and thus were both complicated to implement and specify ([5/8](https://github.com/ethereum/EIPs/issues/8)). Since this proposal is very similar to the way calldata is handled, it fits nicely into the concept. Furthermore, the eWASM architecture already handles return data in exactly the same way.
Note that the EVM implementation needs to keep the return data until the next call or the return from the current call. Since this resource was already paid for as part of the memory of the callee, it should not be a problem. Implementations may either choose to keep the full memory of the callee alive until the next call or copy only the return data to a special memory area.
Keeping the memory of the callee until the next call-like opcode does not increase the peak memory usage in the following sense; any memory allocation in the caller's frame that happens after the return from the call can be moved before the call without a change in gas costs, but will add this allocation to the peak allocation.
The number values of the opcodes were allocated in the same nibble block that also contains `CALLDATASIZE` and `CALLDATACOPY`.
## Backwards Compatibility
This proposal introduces two new opcodes and stays fully backwards compatible apart from that.
## Test Cases
## Implementation
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

52
EIPS/eip-214.md Normal file
View File

@ -0,0 +1,52 @@
## Preamble
EIP: 214
Title: New opcode STATICCALL
Author: Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>;
Type: Standard Track
Category: Core
Status: Final
Created: 2017-02-13
## Simple Summary
To increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).
## Abstract
This proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). Any opcode that attempts to perform such a modification (see below for details) will result in an exception instead of performing the modification.
## Motivation
Currently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. This poses certain difficulties about smart contract engineers; after a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. Furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases.
This EIP adds a way to call other contracts and restrict what they can do in the simplest way. It can be safely assumed that the state of all accounts is the same before and after a static call.
## Specification
Introduce a new `STATIC` flag to the virtual machine. This flag is set to `false` initially. Its value is always copied to sub-calls with an exception for the new opcode below.
Opcode: `0xfa`.
`STATICCALL` functions equivalently to a `CALL`, except it takes only 6 arguments (the "value" argument is not included and taken to be zero), and calls the child with the `STATIC` flag set to `true` for the execution of the child. Once this call returns, the flag is reset to its value before the call.
Any attempts to make state-changing operations inside an execution instance with `STATIC` set to `true` will instead throw an exception. These operations include `CREATE`, `CREATE2`, `LOG0`, `LOG1`, `LOG2`, `LOG3`, `LOG4`, `SSTORE`, and `SELFDESTRUCT`. They also include `CALL` with a non-zero value. As an exception, `CALLCODE` is not considered state-changing, even with a non-zero value.
## Rationale
This allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else. This may also make purely functional HLLs easier to implement.
## Backwards Compatibility
This proposal adds a new opcode but does not modify the behaviour of other opcodes and thus is backwards compatible for old contracts that do not use the new opcode and are not called via the new opcode.
## Test Cases
To be written.
## Implementation
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

50
EIPS/eip-234.md Normal file
View File

@ -0,0 +1,50 @@
## Preamble
```
EIP: 234
Title: Add `blockHash` to JSON-RPC filter options.
Author: Micah Zoltu
Type: Standard Track
Category: Interface
Status: Draft
Created: 2017-03-24
```
## Simple Summary
Add an option to JSON-RPC filter options (used by `eth_newFilter` and `eth_getLogs`) that allows specifying the block hash that should be included in the results. This option would be an alternative to `fromBlock`/`toBlock` options.
## Abstract
This addition would allow clients to fetch logs for specific blocks, whether those blocks were in the current main chain or not. This resolves some issues that make it difficult/expensive to author robust clients due to the nature of chain reorgs, unreliable network connections and the result set not containing enough details in the empty case.
## Specification
The filter options used by `eth_newFilter` would have an additional optional parameter named `blockHash` whose value is a single block hash. The Ethereum node responding to the request would either send back an error if the block hash was not found or it would return the results matching the filter (per normal operation) constrained to the block provided. Internally, this would function (presumably) similar to the `fromBlock` and `toBlock` filter options.
## Rationale
A client (dApp) who needs reliable notification of both log additions (on new blocks) and log removals (on chain reorgs) cannot achieve this while relying solely on subscriptions and filters. This is because a combination of a network or remote node failure during a reorg can result in the client getting out of sync with reality. An example of where this can happen with Websockets is when the client opens a web socket connection, sets up a log filter subscription, gets notified of some new logs, then loses the web socket connection, then (while disconnected) a re-org occurs, then the client connects back and establishes a new log filter. In this scenario they will not receive notification of the log removals from the node because they were disconnected when the removals were broadcast and the loss of their connection resulted in the node forgetting about their existence. A similar scenario can be concocted for HTTP clients where between polls for updates, the node goes down and comes back (resulting in loss of filter state) and a re-org also occurs between the same two polls.
In order to deal with this while still providing a robust mechanism for internal block/log additional/removal, the client can maintain a blockchain internally (last `n` blocks) and only subscribe/poll for new blocks. When a new block is received, the client can reconcile their internal model with the new block, potentially back-filling parents or rolling back/removing blocks from their internal model to get in sync with the node. This can account for any type of disconnect/reorg/outage scenario and also allows the client (as an added benefit) to talk to a cluster of Ethereum nodes (e.g., via round-robin) rather than being tightly coupled to a single node.
Once the user has a reliable stream of blocks, they can then look at the bloom filter for the new block and if the block *may* have logs of interest they can fetch the filtered logs for that block from the node. The problem that arises is that a re-org may occur between when the client receives the block and when the client fetches the logs for that block. Given the current set of filter options, the client can only ask for logs by block number. In this scenario, the logs they get back will be for a block that *isn't* the block they want the logs for and is instead for a block that was re-orged in (and may not be fully reconciled with the internal client state). This can be partially worked around by looking at the resulting logs themselves and identifying whether or not they are for the block hash requested. However, if the result set is an empty array (no logs fetched) then the client is in a situation where they don't know what block the results are for. The results could have been legitimately empty (bloom filter can yield false positives) for the block in question, or they could be receiving empty logs for a block that they don't know about. At this point, there is no decision the client can make that allows them a guarantee of recovery. They can assume the empty logs were for the correct block, but if they weren't then they will never try to fetch again. This creates a problem if the block was only transiently re-orged out because it may come back before the next block poll so the client will never witness the reorg. They can assume the empty logs were for the wrong block, an refetch them, but they may continue to get empty results putting them right back into the same situation.
By adding the ability to fetch logs by hash, the client can be guaranteed that if they get a result set, it is for the block in question. If they get an error, then they can take appropriate action (e.g., rollback that block client-side and re-fetch latest).
## Backwards Compatibility
The only potential issue here is the `fromBlock` and `toBlock` fields. It wouldn't make sense to include both the hash and the number so it seems like `fromBlock`/`toBlock` should be mutually exclusive with `blockHash`.
## Test Cases
`{ "jsonrpc": "2.0", "id": 1, "method": "eth_getLogs", params: [{"blockHash": "0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c"}] }` should return all of the logs for the block with hash `0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c`. If a `topics` field is added to the filter options then a filtered set of logs for that block should be returned. If no block exists with that hash then an error should be returned with a `code` of `-32602`, a `message` of `"Invalid params"` and a `data` of `"Block with hash 0xbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0cbl0c was not found."`.
## Implementation
- [ ] Geth
- [ ] Parity
- [ ] EthereumJ
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

30
EIPS/eip-55.md
View File

@ -26,7 +26,7 @@ def checksum_encode(addr): # Takes a 20-byte binary address as input
return '0x'+o
def test(addrstr):
assert(addrstr == checksum_encode2(bytes.fromhex(addrstr[2:])))
assert(addrstr == checksum_encode(bytes.fromhex(addrstr[2:])))
test('0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed')
test('0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359')
@ -37,6 +37,13 @@ test('0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb')
In English, convert the address to hex, but if the `i`th digit is a letter (ie. it's one of `abcdef`) print it in uppercase if the `4*i`th bit of the hash of the lowercase hexadecimal address is 1 otherwise print it in lowercase.
# Rationale
Benefits:
- Backwards compatible with many hex parsers that accept mixed case, allowing it to be easily introduced over time
- Keeps the length at 40 characters
- On average there will be 15 check bits per address, and the net probability that a randomly generated address if mistyped will accidentally pass a check is 0.0247%. This is a ~50x improvement over ICAP, but not as good as a 4-byte check code.
# Implementation
In javascript:
@ -45,7 +52,7 @@ In javascript:
const createKeccakHash = require('keccak')
function toChecksumAddress (address) {
address = address.toLowerCase().replace('0x','');
address = address.toLowerCase().replace('0x', '')
var hash = createKeccakHash('keccak256').update(address).digest('hex')
var ret = '0x'
@ -72,12 +79,21 @@ Note that the input to the Keccak256 hash is the lowercase hexadecimal string (i
var hash = createKeccakHash('keccak256').update(Buffer.from(address.toLowerCase(), 'ascii')).digest()
```
# Rationale
# Test Cases
Benefits:
- Backwards compatible with many hex parsers that accept mixed case, allowing it to be easily introduced over time
- Keeps the length at 40 characters
- On average there will be 15 check bits per address, and the net probability that a randomly generated address if mistyped will accidentally pass a check is 0.0247%. This is a ~50x improvement over ICAP, but not as good as a 4-byte check code.
```
# All caps
0x52908400098527886E0F7030069857D2E4169EE7
0x8617E340B3D01FA5F11F306F4090FD50E238070D
# All Lower
0xde709f2102306220921060314715629080e2fb77
0x27b1fdb04752bbc536007a920d24acb045561c26
# Normal
0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed
0xfB6916095ca1df60bB79Ce92cE3Ea74c37c5d359
0xdbF03B407c01E7cD3CBea99509d93f8DDDC8C6FB
0xD1220A0cf47c7B9Be7A2E6BA89F429762e7b9aDb
```
# Adoption

26
EIPS/eip-609.md
View File

@ -5,9 +5,9 @@
Author: Alex Beregszaszi
Type: Standard Track
Category: Core
Status: Draft
Status: Final
Created: 2017-04-23
Requires: 100, 140, 196, 197, 198, 211, 214
Requires: 100, 140, 196, 197, 198, 211, 214, 649, 658
## Abstract
@ -18,16 +18,22 @@ This specifies the changes included in the hard fork named Byzantium.
- Codename: Byzantium
- Aliases: Metropolis/Byzantium, Metropolis part 1
- Activation:
- Block not specified yet
- Block >= 4,370,000 on Mainnet
- Block >= 1,700,000 on Ropsten testnet
- Included EIPs:
- EIP 100 (Change difficulty adjustment to target mean block time including uncles)
- EIP 140 (REVERT instruction in the Ethereum Virtual Machine)
- EIP 196 (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128)
- EIP 197 (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128)
- [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 (Precompiled contract for bigint modular exponentiation)
- EIP 211 (New opcodes: RETURNDATASIZE and RETURNDATACOPY)
- EIP 214 (New opcode STATICCALL)
- EIP 658 (Embedding transaction return data in receipts)
- [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
1. https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/
## Copyright

74
EIPS/eip-649.md Normal file
View File

@ -0,0 +1,74 @@
## Preamble
EIP: 649
Title: Metropolis Difficulty Bomb Delay and Block Reward Reduction
Authors: Afri Schoedon, Vitalik Buterin
Type: Standard Track
Category: Core
Status: Final
Created: 2017-06-21
Replaces: 186
## Simple Summary
The average block times are increasing due to the difficulty bomb (also known as the "_ice age_") slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately one and a half year and to reduce the block rewards with the Byzantium fork, the first part of the Metropolis fork.
## Abstract
Starting with `BYZANTIUM_FORK_BLKNUM` the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 3 million blocks later than previously specified with the Homestead fork. Furthermore, block rewards will be adjusted to a base of 3 ETH, uncle and nephew rewards will be adjusted accordingly.
## Motivation
The Casper development and switch to proof-of-stake is delayed, the Ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another one and a half years. With the delay of the ice age, there is a desire to not suddenly also increase miner rewards. The difficulty bomb has been known about for a long time and now it's going to stop from happening. In order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. Reducing the reward also decreases the likelihood of a miner driven chain split as Ethereum approaches proof-of-stake.
## Specification
#### Relax Difficulty with Fake Block Number
For the purposes of `calc_difficulty`, simply replace the use of `block.number`, as used in the exponential ice age component, with the formula:
fake_block_number = max(0, block.number - 3_000_000) if block.number >= BYZANTIUM_FORK_BLKNUM else block.number
#### Adjust Block, Uncle, and Nephew rewards
To ensure a constant Ether issuance, adjust the block reward to `new_block_reward`, where
new_block_reward = 3_000_000_000_000_000_000 if block.number >= BYZANTIUM_FORK_BLKNUM else block.reward
(3E18 wei, or 3,000,000,000,000,000,000 wei, or 3 ETH).
Analogue, if an uncle is included in a block for `block.number >= BYZANTIUM_FORK_BLKNUM` such that `block.number - uncle.number = k`, the uncle reward is
new_uncle_reward = (8 - k) * new_block_reward / 8
This is the existing pre-Metropolis formula for uncle rewards, simply adjusted with `new_block_reward`.
The nephew reward for `block.number >= BYZANTIUM_FORK_BLKNUM` is
new_nephew_reward = new_block_reward / 32
This is the existing pre-Metropolis formula for nephew rewards, simply adjusted with `new_block_reward`.
## Rationale
This will delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times at the end of 2018. An alternate proposal was to add special rules to the difficulty calculation to effectively _pause_ the difficulty between different blocks. This would lead to similar results.
This was previously discussed at All Core Devs Meeting [#09](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%209.md#metropolis-timing-and-roadmap-discussion), [#12](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2012.md#5-metropolis-update), [#13](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2013.md#3-eip-186-reduce-eth-issuance-before-proof-of-stake-hudson), and [#14](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2014.md#1-eip-186-reduce-eth-issuance-before-proof-of-stake-core-devs). Consensus on the specification was achieved in All Core Devs Meeting [#19](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2019.md) and specification drafted in EIP issue [#649](https://github.com/ethereum/EIPs/issues/649). It was decided to replace EIP [#186](https://github.com/ethereum/EIPs/issues/186) and include the block reward reduction along with the difficulty bomb delay in All Core Devs Meeting [#20](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2020.md) and [#21](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2021.md); accepted in [#22](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2022.md).
## 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 first of the two Metropolis hard-forks, the _Byzantium_ fork.
## Test Cases
Test cases exist in ethereum/tests [#269](https://github.com/ethereum/tests/pull/269).
## Implementation
The following clients implemented EIP-649:
- Geth [#15028](https://github.com/ethereum/go-ethereum/pull/15028)
- Parity [#5855](https://github.com/paritytech/parity/pull/5855)
- EthereumJ [#927](https://github.com/ethereum/ethereumj/pull/927)
- Cpp-Ethereum [#4050](https://github.com/ethereum/cpp-ethereum/issues/4050)
- PyEthereum [#383](https://github.com/ethereum/pyethereum/pull/383)
The Yellow Paper implements EIP-649 in [#333](https://github.com/ethereum/yellowpaper/pull/333).
Other notable implementations:
- Eth-Isabelle [#459](https://github.com/pirapira/eth-isabelle/issues/459)
- Py-EVM [#123](https://github.com/pipermerriam/py-evm/pull/123)
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

31
EIPS/eip-658.md Normal file
View File

@ -0,0 +1,31 @@
## Preamble
EIP: 658
Title: Embedding transaction status code in receipts
Author: Nick Johnson <nick@ethereum.org>
Type: Standard Track
Category Core
Status: Final
Created: 2017-06-30
Requires: 140
Replaces: 98
## Abstract
This EIP replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed.
## Motivation
With the introduction of the REVERT opcode in EIP140, it is no longer possible for users to assume that a transaction failed iff it consumed all gas. As a result, there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied.
Full nodes can provide RPCs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical.
Instead, we propose to replace the intermediate state root, already obsoleted by EIP98, with the return status (1 for success, 0 for failure). This both allows callers to determine success status, and remedies the previous omission of return data from the receipt.
## Specification
For blocks where block.number >= BYZANTIUM_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success.
## Rationale
This constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for Metropolis.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

77
README.md
View File

@ -10,46 +10,43 @@ First review [EIP-1](EIPS/eip-1.md). Then clone the repository and add your EIP
* **Final** - an EIP that has been adopted in a previous hard fork (for Core/Consensus layer EIPs).
* **Deferred** - an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.
# Accepted EIPs (planned for adoption in the Byzantium Metropolis hard fork)
| Number |Title | Author | Layer | Status |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------- | -------------------- | ------------| ----------|
| [100](https://github.com/ethereum/EIPs/issues/100) | Change difficulty adjustment to target mean block time including uncles | Vitalik Buterin | Core | Accepted |
| [140](https://github.com/ethereum/EIPs/pull/206) | REVERT instruction in the Ethereum Virtual Machine | Beregszaszi, Mushegian| Core | Accepted |
| [196](https://github.com/ethereum/EIPs/pull/213) | Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 | Reitwiessner | Core | Accepted |
| [197](https://github.com/ethereum/EIPs/pull/212) | Precompiled contracts for optimal Ate pairing check on the elliptic curve alt_bn128 | Buterin, Reitwiessner | Core | Accepted |
| [198](https://github.com/ethereum/EIPs/pull/198) | Precompiled contract for bigint modular exponentiation | Vitalik Buterin | Core | Accepted |
| [211](https://github.com/ethereum/EIPs/pull/211) | New opcodes: RETURNDATASIZE and RETURNDATACOPY | Christian Reitwiessner| Core | Accepted |
| [214](https://github.com/ethereum/EIPs/pull/214) | New opcode STATICCALL | Buterin, Reitwiessner | Core | Accepted |
| [649](https://github.com/ethereum/EIPs/pull/669) | Metropolis Difficulty Bomb Delay and Issuance Reduction | Schoedon, Buterin | Core | Accepted |
| [658](https://github.com/ethereum/EIPs/pull/658) | Embedding transaction return data in receipts | Nick Johnson | Core | Accepted |
# Deferred EIPs (adoption postponed until the Constantinople Metropolis hard fork)
| Number |Title | Author | Layer | Status |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------- | -------------------- | ------------| ----------|
| [86](https://github.com/ethereum/EIPs/pull/208) | Abstraction of transaction origin and signature | Vitalik Buterin | Core | Deferred |
| [96](https://github.com/ethereum/EIPs/pull/210) | Blockhash refactoring | Vitalik Buterin | Core | Deferred |
| [145](EIPS/eip-145.md) | Bitwise shifting instructions in EVM | Alex Beregszaszi, Paweł Bylica | Core | Deferred |
| Number | Title | Author | Layer | Status |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------ | ---------- | -------- |
| [86](https://github.com/ethereum/EIPs/pull/208) | Abstraction of transaction origin and signature | Vitalik Buterin | Core | Deferred |
| [96](https://github.com/ethereum/EIPs/pull/210) | Blockhash refactoring | Vitalik Buterin | Core | Deferred |
| [145](EIPS/eip-145.md) | Bitwise shifting instructions in EVM | Alex Beregszaszi, Paweł Bylica | Core | Deferred |
# Finalized EIPs (standards that have been adopted)
| Number |Title | Author | Layer | Status |
| ------------------------------------------------------- | ----------------------------------------------------------- | ----------------| ------------| --------|
| [2](EIPS/eip-2.md) | Homestead Hard-fork Changes | Vitalik Buterin | Core | Final |
| [6](EIPS/eip-6.md) | Renaming Suicide Opcode | Hudson Jameson | Interface | Final |
| [7](EIPS/eip-7.md) | DELEGATECALL | Vitalik Buterin | Core | Final |
| [8](EIPS/eip-8.md) | devp2p Forward Compatibility Requirements for Homestead | Felix Lange | Networking | Final |
| [20](EIPS/eip-20-token-standard.md) | ERC-20 Token Standard | Fabian Vogelsteller, Vitalik Buterin | ERC | Final |
| [55](EIPS/eip-55.md) | ERC-55 Mixed-case checksum address encoding | Vitalik Buterin | Core | Final |
| [137](EIPS/eip-137.md) | Ethereum Domain Name Service - Specification | Nick Johnson | ERC | Final |
| [141](EIPS/eip-141.md) | Designated invalid EVM instruction | Alex Beregszaszi| Core | Final |
| [150](EIPS/eip-150.md) | Gas cost changes for IO-heavy operations | Vitalik Buterin | Core | Final |
| [155](EIPS/eip-155.md) | Simple replay attack protection | Vitalik Buterin | Core | Final |
| [160](EIPS/eip-160.md) | EXP cost increase | Vitalik Buterin | Core | Final |
| [161](EIPS/eip-161.md) | State trie clearing (invariant-preserving alternative) | Gavin Wood | Core | Final |
| [162](EIPS/eip-162.md) | ERC-162 ENS support for reverse resolution of Ethereum addresses | Maurelian, Nick Johnson | ERC | Final |
| [170](EIPS/eip-170.md) | Contract code size limit | Vitalik Buterin | Core | Final |
| [181](EIPS/eip-181.md) | ERC-181 ENS support for reverse resolution of Ethereum addresses | Nick Johnson | ERC | Final |
| [190](EIPS/eip-190.md) | ERC-190 Ethereum Smart Contract Packaging Standard | Piper Merriam, Tim Coulter, Denis Erfurt (mhhf), RJ Catalano (VoR0220), Iuri Matias (iurimatias) | ERC | Final |
| [606](EIPS/eip-606.md) | Hardfork Meta: Homestead | Alex Beregszaszi | Meta | Final |
| [607](EIPS/eip-607.md) | Hardfork Meta: Spurious Dragon | Alex Beregszaszi | Meta | Final |
| [608](EIPS/eip-608.md) | Hardfork Meta: Tangerine Whistle | Alex Beregszaszi | Meta | Final |
| [706](EIPS/eip-706.md) | DEVp2p snappy compression | Péter Szilágyi | Networking | Final |
| Number | Title | Author | Layer | Status |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------| ---------- | -------- |
| [2](EIPS/eip-2.md) | Homestead Hard-fork Changes | Vitalik Buterin | Core | Final |
| [6](EIPS/eip-6.md) | Renaming Suicide Opcode | Hudson Jameson | Interface | Final |
| [7](EIPS/eip-7.md) | DELEGATECALL | Vitalik Buterin | Core | Final |
| [8](EIPS/eip-8.md) | devp2p Forward Compatibility Requirements for Homestead | Felix Lange | Networking | Final |
| [20](EIPS/eip-20-token-standard.md) | ERC-20 Token Standard | Fabian Vogelsteller, Vitalik Buterin | ERC | Final |
| [55](EIPS/eip-55.md) | ERC-55 Mixed-case checksum address encoding | Vitalik Buterin | ERC | Final |
| [100](https://github.com/ethereum/EIPs/issues/100) | Change difficulty adjustment to target mean block time including uncles | Vitalik Buterin | Core | Final |
| [137](EIPS/eip-137.md) | Ethereum Domain Name Service - Specification | Nick Johnson | ERC | Final |
| [140](https://github.com/ethereum/EIPs/pull/206) | REVERT instruction in the Ethereum Virtual Machine | Alex Beregszaszi, Nikolai Mushegian | Core | Final |
| [141](EIPS/eip-141.md) | Designated invalid EVM instruction | Alex Beregszaszi | Core | Final |
| [150](EIPS/eip-150.md) | Gas cost changes for IO-heavy operations | Vitalik Buterin | Core | Final |
| [155](EIPS/eip-155.md) | Simple replay attack protection | Vitalik Buterin | Core | Final |
| [160](EIPS/eip-160.md) | EXP cost increase | Vitalik Buterin | Core | Final |
| [161](EIPS/eip-161.md) | State trie clearing (invariant-preserving alternative) | Gavin Wood | Core | Final |
| [162](EIPS/eip-162.md) | ERC-162 ENS support for reverse resolution of Ethereum addresses | Maurelian, Nick Johnson | ERC | Final |
| [170](EIPS/eip-170.md) | Contract code size limit | Vitalik Buterin | Core | Final |
| [181](EIPS/eip-181.md) | ERC-181 ENS support for reverse resolution of Ethereum addresses | Nick Johnson | ERC | Final |
| [190](EIPS/eip-190.md) | ERC-190 Ethereum Smart Contract Packaging Standard | Merriam, Coulter, Erfurt, Catalano, Matias | ERC | Final |
| [196](https://github.com/ethereum/EIPs/pull/213) | Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128 | Christian Reitwiessner | Core | Final |
| [197](https://github.com/ethereum/EIPs/pull/212) | Precompiled contracts for optimal Ate pairing check on the elliptic curve alt_bn128 | Vitalik Buterin, Christian Reitwiessner | Core | Final |
| [198](https://github.com/ethereum/EIPs/pull/198) | Precompiled contract for bigint modular exponentiation | Vitalik Buterin | Core | Final |
| [211](https://github.com/ethereum/EIPs/pull/211) | New opcodes: RETURNDATASIZE and RETURNDATACOPY | Christian Reitwiessner | Core | Final |
| [214](https://github.com/ethereum/EIPs/pull/214) | New opcode STATICCALL | Vitalik Buterin, Christian Reitwiessner | Core | Final |
| [606](EIPS/eip-606.md) | Hardfork Meta: Homestead | Alex Beregszaszi | Meta | Final |
| [607](EIPS/eip-607.md) | Hardfork Meta: Spurious Dragon | Alex Beregszaszi | Meta | Final |
| [608](EIPS/eip-608.md) | Hardfork Meta: Tangerine Whistle | Alex Beregszaszi | Meta | Final |
| [609](EIPS/eip-609.md) | Hardfork Meta: Byzantium | Alex Beregszaszi | Meta | Final |
| [649](https://github.com/ethereum/EIPs/pull/669) | Metropolis Difficulty Bomb Delay and Block Reward Reduction | Afri Schoedon, Vitalik Buterin | Core | Final |
| [658](https://github.com/ethereum/EIPs/pull/658) | Embedding transaction return data in receipts | Nick Johnson | Core | Final |
| [706](EIPS/eip-706.md) | DEVp2p snappy compression | Péter Szilágyi | Networking | Final |