day3:EIP1014,1015,1046
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/eip-1015.md 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.
まあ普通に考えて、json形式で書いた方が開発者も混乱しないし、あとで見たときの後方互換性も高まるし統一した方が良いんでない？っていう提案。
Rare Art Labs (WIP) Open Zeppelin (WIP) とかで試す予定.
- source
