From EIP-1:
EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.
EIP/ERC # | Title | Author | Layer | Status | Created | |
---|---|---|---|---|---|---|
EIP Purpose and Guidelines |
Martin Becze, Hudson Jameson |
Meta |
Final |
|||
Homestead Hard-fork Changes |
Vitalik Buterin |
Core |
Final |
|||
Renaming Suicide Opcode |
Hudson Jameson |
Interface |
Final |
|||
|
Vitalik Buterin |
Core |
Final |
|||
devp2p Forward Compatibility Requirements for Homestead |
Felix Lange |
Networking |
Final |
|||
ERC-20 Token Standard. Describes standard functions a token contract may implement to allow Dapps and Wallets to handle tokens across multiple interfaces/DApps. Methods include: |
Fabian Vogelsteller, Vitalik Buterin |
ERC |
Final |
Frontier |
||
ERC-55 Mixed-case checksum address encoding |
Vitalik Buterin |
ERC |
Final |
|||
Setting the stage for "abstracting out" account security, and allowing users creation of "account contracts" toward a model where in the long-term all accounts are contracts that can pay for gas, and users are free to defined their own security model (that perform any desired signature verification and nonce checks instead of using the in-protocol mechanism where ECDSA and default nonce scheme are the only "standard" way to secure an account, which is currently hard-coded into transaction processing). |
Vitalik Buterin |
Core |
Draft |
Constantinople |
||
Setting the Blockhash and state root refactoring to store blockhashes in the state to reduce protocol complexity and need for client implementation complexity necessary to process the |
Vitalik Buterin |
Core |
Constantinople |
|||
Change formula that computes the difficulty of a block (difficulty adjustment algorithm) to target mean block time and take uncles into account. |
Vitalik Buterin |
Core |
Final |
Metropolis Byzantinium |
||
Serenity Currency and Crypto Abstraction. Abstracting Ether up a level with the benefit of allowing Ether and sub-Tokens to be treated similarly by contracts, reducing level of indirection required for custom-policy accounts such as Multisigs, and purifying the underlying Ethereum protocol by reducing the minimal consensus implementation complexity |
Vitalik Buterin |
Active |
Serentiy feature |
Serenity Casper |
||
"Sharding scaffolding" EIP to allow Ethereum transactions to be parallelised using a binary tree sharding mechanism, and to set the stage for a later sharding scheme. Research in progress: https://github.com/ethereum/sharding |
Vitalik Buterin |
Active |
Serentiy feature |
Serenity Casper |
||
Ethereum Domain Name Service - Specification |
Nick Johnson |
ERC |
Final |
|||
Add |
Alex Beregszaszi, Nikolai Mushegian |
Core |
Final |
Metropolis Byzantinium |
||
Designated invalid EVM instruction |
Alex Beregszaszi |
Core |
Final |
|||
Gas cost changes for IO-heavy operations |
Vitalik Buterin |
Core |
Final |
|||
Simple Replay Attack Protection. Replay Attack allows any transaction using a pre-EIP155 Ethereum Node or Client to become signed so it is valid and executed on both the Ethereum and Ethereum Classic chains. |
Vitalik Buterin |
Core |
Final |
Homestead |
||
EXP cost increase |
Vitalik Buterin |
Core |
Final |
|||
State trie clearing (invariant-preserving alternative[EIP-161] |
Gavin Wood |
Core |
Final |
|||
ERC-162 ENS support for reverse resolution of Ethereum addresses |
Maurelian, Nick Johnson |
ERC |
Final |
|||
Contract code size limit |
Vitalik Buterin |
Core |
Final |
|||
ERC-181 ENS support for reverse resolution of Ethereum addresses |
Nick Johnson |
ERC |
Final |
|||
ERC-190 Ethereum Smart Contract Packaging Standard |
Merriam, Coulter, Erfurt, Catalano, Matias |
ERC |
Final |
|||
Precompiled contracts for addition and scalar multiplication operations on the elliptic curve alt_bn128, which are required in order to perform zkSNARK verification within the block gas limit |
Christian Reitwiessner |
Core |
Final |
Metropolis Byzantinium |
||
Precompiled contracts for optimal Ate pairing check of a pairing function on a specific pairing-friendly elliptic curve alt_bn128 and is combined with EIP 196 |
Vitalik Buterin, Christian Reitwiessner |
Core |
Final |
Metropolis Byzantinium |
||
Precompile to support big integer modular exponentiation enabling RSA signature verification and other cryptographic applications |
Vitalik Buterin |
Core |
Final |
Metropolis Byzantinium |
||
New opcodes: |
Christian Reitwiessner |
Core |
Final |
Metropolis Byzantinium |
||
New opcode: |
Vitalik Buterin, Christian Reitwiessner |
Core |
Final |
Metropolis Byzantinium |
||
Rinkeby Testnet using Proof-of-Authority where blocks only mined by trusted signers |
Homestead |
|||||
Metropolis Difficulty Bomb Delay and Block Reward Reduction - Delay of the Ice Age (aka the Difficulty Bomb by 1 year), and reduction of the block reward from 5 to 3 ether. |
Afri Schoedon, Vitalik Buterin |
Core |
Final |
Metropolis Byzantinium |
||
Embedding transaction status code in receipts. Fetch and embed status field indicative of success or failure state to transaction receipts for callers, as was no longer able to assume the transaction failed if and only if (iff) it consumed all gas after the introduction of the |
Nick Johnson |
Core |
Final |
Metropolis Byzantinium |
||
DEVp2p snappy compression |
Péter Szilágyi |
Networking |
Final |
|||
ERC-721 Non-Fungible Token (NFT) Standard. It is a standard API that would allow smart contracts to operate as unique tradable non-fungible tokens (NFT) that may be tracked in standardised wallets and traded on exchanges as assets of value, similar to ERC-20. CryptoKitties was the first popularly-adopted implementation of a digital NFT in the Ethereum ecosystem. |
William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs |
Standard |
Draft |