day4:EIP1047,1051,1052

eip-1047:Token Metadata JSON Schema

summary
A standard interface for token metadata

ERC20とERC721と区別なくmetadataの統一

specificaiton

{
    "title": "Asset Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this token represents",
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this token represents",
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
        }
    }
}

rationale
One JSON schema standard will allow for simpler maintenance of this critical schema

メンテナンスが楽になる。

source

EIPs/eip-1047.md at master · ethereum/EIPs · GitHub

eip-1051:Overflow checking for the EVM

summary
This EIP adds overflow checking for EVM arithmetic operations, and two new opcodes that check and clear the overflow flags.

overflow検知とopcodeの追加

speculation

Two new flags are added to the EVM state: overflow (ovf) and signed overflow (sovf).
rationale

Rationale Any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. One option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. However, this limits the manner in which overflows can be handled.

現状のコントラクトのoverflowを防ぐ方法に当たる変更はかなり大きなものとなってしまう。

そのため、解決策としてはいくつか考えられる。

一つ目のオプションはoverflow protectionを可能とするopcodeを提供することである。それは、もしoverflowが起こったら、それを放り出すか、revertする考えである。

しかし、その方法にはoverflowが行われる方法に対しての手法としては限界がある。

Instead, we replicate functionality from real world CPUs, which typically implement 'carry' and 'overflow' flags.

代わりにreal world CPUsから複製するという感が型もある。それはcarryとoverflowのフラグを立てるものである。

Separate flags for signed and unsigned overflow are necessary due to the fact that a signed overflow may not result in an unsigned overflow.

signed and unsignedに対してのフラグを切り分けることは重要である。それはsigned overflowはunsigned overflowという結果にはならないという事実のためである。

source

EIPs/eip-1051.md at master · ethereum/EIPs · GitHub

EIP-1051: Arithmetic overflow detection for the EVM - EIPs - Fellowship of Ethereum Magicians

eip-1052:EXTCODEHASH opcode

abstract

This EIP specifies a new opcode, which returns the keccak256 hash of a contract's code.
motivation

Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself. For instance, a contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.

Contracts can presently do this using the EXTCODECOPY opcode, but this is expensive, especially for large contracts, in cases where only the hash is required. As a result, we propose a new opcode, EXTCODEHASH, which returns the keccak256 hash of a contract's bytecode.

とりあえず、既存のEXTCODECOPYというコードがコスパがあまり良くなくて、容量をめちゃくちゃ食うので、新たにEXTCODEHASHというopcodeを提案したという話。

speculation
A new opcode, EXTCODEHASH, is introduced, with number 0x3F. The EXTCODEHASH takes one argument from the stack, zeros the first 96 bits and pushes to the stack the keccak256 hash of the code of the account at the address being the remaining 160 bits.

In case the account does not exist 0 is pushed to the stack.

In case the account does not have code the keccak256 hash of empty data (i.e. c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470) is pushed to the stack.

The gas cost of the EXTCODEHASH is 400.