EIP1014:Skinny CREATE2

simply and request to refer to SHA-3 as keccak256.

Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using sha3(msg.sender ++ salt ++ init_code)[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.

  • source

EIP-1014: Use keccak256 name instead of sha3 by chfast · Pull Request #1247 · ethereum/EIPs · GitHub

EIP1015:Configurable On Chain Issuance

- simple summary

This EIP changes the block reward step by instead of setting it to be hard coded on the clients and to be given to the miner/validator etherbase, it should instead go to an address decided by an on-chain contract, with hard limits on how it would be issued (six month lock-in; issuance can only decrease or be mantained, but not increase;). A decision method is suggested but not essential to the notion of this EIP. This would not be a generic governance solution, which is a much broader and harder topic, would not affect technical upgrade decisions or other hard forks, but seen as a forum to attempt to prevent contentious hard forks that can be solved with the issuance.

EIPs/ at master · ethereum/EIPs · GitHub

EIP1046:ERC20 Metadata Extension

  • simple summary

    Optionally extend ERC20 token interface to support the same metadata standard as ERC721 tokens.

  • motivation

    The ERC721 standard was created to support the creation of perfectly unique, 1-of-1, non-divisible tokens known as "non-fungible tokens".

The initial use case for the ERC721 standard was to support the creation of crypto-collectibles and gaming assets, initially for the "Crypto Kitties" collectibles game. The success of Crypto Kitties catalyzed significant application development to support the display of ERC721 assets using the tokenURI metadata parameter.

However, not all crypto-collectibles and gaming assets need to be unique and non-fungible. Gaming assets (items, weapons, characters), crypto-artworks with non-unique "prints", and more will function more like traditional ERC20 tokens with a fungible supply. Many applications such as wallets, exchanges, games, etc. will want to support both fungible and non-fungible assets containing similar metadata. This proposal will extend the ERC20 standard to optionally include a nearly identical tokenURI parameter supporting the same JSON metadata schema as the ERC721 standard.

cryptkittiesは確かにnon-fungible tokenとしてユニークさを持って、tokenURL metadata parameterで管理されることによって価値を持ったが、全てのcrypto-collectible and gaming assetsが必ずしもunique and non-fungibleである必要もない。erc20とerc721をなるべく似たような規格にすることによって、クリプトネットワークの連携しやすさを高めた方が良いのではという提案(な気がする)。

  • rationale

    This proposal will make adding metadata to ERC20 tokens straightforward for developers with minimal-to-no disruption to the overall ecosystem. By using the same parameter name and by consolidating the underlying Token JSON Metadata Standard, developers will confidently understand how to add and interpret token metadata between ERC20 and ERC721 tokens.


Rare Art Labs (WIP) Open Zeppelin (WIP) とかで試す予定.

  • source

EIPs/ at master · ethereum/EIPs · GitHub