eip-1047:Token Metadata JSON Schema

  • summary

    A standard interface for token 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/ 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.


  • 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 protectionを可能とするopcodeを提供することである。それは、もしoverflowが起こったら、それを放り出すか、revertする考えである。


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/ 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.


  • 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.

  • rationale 上述した通り、既存の方法ではgascostが大きすぎる。

  • source

Ethereumのアドレス生成アルゴリズム Keccak-256 Online

keccak - How does the Keccak256 hash function work? - Ethereum Stack Exchange

EIPs/ at master · ethereum/EIPs · GitHub