eip1057:ProgPoW, a Programmatic Proof-of-Work

  • short summary

    The following is a proposal for an alternate proof-of-work algorithm - “ProgPoW” - tuned for commodity hardware in order to close the efficiency gap available to specialized ASICs.


  • motivation
Until Ethereum transitions to a pure proof-of-stake model, proof-of-work will continue to be a part of the security of the network - whether it’s adapted into a hybrid model (as is the case of Casper FFG), or adopted by a hard fork.

Ethash allows for the creation of an ASIC that is roughly twice as efficient as a commodity GPU. Ethash’s memory accesses are paired with a very small amount of fixed compute. Most of a GPU’s capacity and complexity sits idle, wasting power, while waiting for DRAM accesses. A specialized ASIC can implement a much smaller (and cheaper) compute engine that burns much less power.

As miner rewards are reduced with Casper FFG, it will remain profitable to mine on a specialized ASIC long after GPUs have exited the network. This will make it easier for an entity that has access to private ASICs to stage a 51% attack on the Ethereum network.

casperFFGによってPOSに移行するまでにPOWによって、Ethereum networkのセキュリティを守らないといけない。しかし、現状のようにマイニング特化したASICの存在は51%アタックの可能性も高めるし、commodity cpu/gpuの報酬も減るので、インセンティブ的にも、セキュリティ的にもよくない。CasperFFGによるPOSへの移行、またはhard forkを用いずとも仕組みをうまく回すために今回のアルゴリズムの提案をする。

  • specification

使用に関してはEIPs/ at master · ethereum/EIPs · GitHub を見た方が早い

  • test

  • Model/Hashrate (MH/s)

RX580    9.4
Vega56  16.6
Vega64      18.7
GTX1070Ti   13.1
GTX1080     14.9
GTX1080Ti   21.8

eip-1062:Formalize IPFS hash into ENS(Ethereum Name Service) resolver

  • simple summary

To specify the mapping protocol between resources stored on IPFS and ENS(Ethereum Naming Service).

  • motivation
To build fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages :

Address large amounts of data, and has unique cryptographic hash for every record.
Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, with safer way and lower the millions of cost for the bandwidth.
IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network.
Those features makes perfect match for integrating into ENS, and these make users can easily access content through ENS, and show up in the normal browser.


  1. より多くのデータにアドレスでき、データをハッシュ化してユニークなものとして扱える。

  2. IPFSはp2pの元となっているので、より大容量のデータをより安全にデリバリーできる。そしてそれは帯域コストを何百万も下げうる。

  3. IPFSはストレージデータに対して、あらゆるサービスにアクセスする最も効率的な方法。また、複製リスクもなくす。


  • specification
The condition now is that the IPFS file fingerprint using base58 and in the meantime, the Ethereum uses hex in API to encode the binary data. So that need a way to process the condition requires not only we need to transfer from IPFS to Ethereum, but also need to convert it back.

To solve these requirements, we can use binary buffer bridging that gap.
When mapping the IPFS base58 string to ENS resolver, first we convert the Base58 to binary buffer, turn the buffer to hex encrypted format, and save to the contract. Once we want to get the IPFS resources address represented by the specific ENS, we can first find the mapping information stored as hex format before, extract the hex format to binary buffer, and finally turn that to IPFS Base58 address string.


  1. Base58をbinary bufferに変換。hexをencrypted formatに帰る。

  2. IPFSリソースを特定のENSによってアドレスしたい時になって初めて、ためていたデータをhex formatにしてhex formatをbinary bufferにする。

  3. そして最終的にはbinary bufferをIPFSにBase58 address stringにする。

  4. implementation

GitHub - PortalNetwork/portal-network-browser-extension: 🕳️🌐🔌 Portal Network Browser Extension, enables browsing IPFS website by using Ethereum Name Service and Ethereum Classic Name Service.

EIPs/ at master · ethereum/EIPs · GitHub

eip-1066:Status Codes

  • simple summary

Broadly applicable status codes for Ethereum smart contracts.

  • abstract
This standard outlines a common set of Ethereum status codes (ESC) in the same vein as HTTP statuses. This provides a shared set of signals to allow smart contracts to react to situations autonomously, expose localized error messages to users, and so on.

The current state of the art is to either revert and require human intervention, or return a Boolean pass/fail status. Status codes are similar-but-orthogonal to reverting with a reason, but aimed at automation and translation.

As is the case with HTTP, having a standard set of known codes has many benefits for developers. They remove friction from needing to develop your own schemes for every contract, makes inter-contract automation easier, and makes it easier to broadly understand which of the finite states your request produced. Importantly, it makes it much easier to distinguish between expected errors states, and truly exceptional conditions that require halting execution.


  • motivation

    • Autonomy

    • Semantic Density

    • User Feedback

    • More than Pass/Fail

  • specification

EIPs/ at master · ethereum/EIPs · GitHub 見ると図示化されていてわかりやすい

  • dex
0x03 = Waiting
0x31 = Other Party (ie: not you) Agreed
0x41 = Available
0x43 = Not Yet Available


AwesomeCoin                 DEX                     TraderBot
     +                       +                          +
     |                       |       buy(AwesomeCoin)   |
     |                       | <------------------------+
     |         buy()         |                          |
     | <---------------------+                          |
     |                       |                          |
     |     Status [0x43]     |                          |
     +---------------------> |       Status [0x43]      |
     |                       +------------------------> |
     |                       |                          |
     |                       |        isDoneYet()       |
     |                       | <------------------------+
     |                       |                          |
     |                       |       Status [0x43]      |
     |                       +------------------------> |
     |                       |                          |
     |                       |                          |
     |     Status [0x41]     |                          |
     +---------------------> |                          |
     |                       |                          |
     |       buy()           |                          |
     | <---------------------+                          |
     |                       |                          |
     |                       |                          |
     |     Status [0x31]     |                          |
     +---------------------> |      Status [0x31]       |
     |                       +------------------------> |
     |                       |                          |
     |                       |                          |
     |                       |                          |
     |                       |                          |
     +                       +                          +
0x01 = Generic Success
0x10 = Disallowed
0x11 = Allowed

                                              Token Validation

           Buyer                  RegulatedToken           TokenValidator               IDChecker          SpendLimiter
             +                          +                         +                         +                   +
             |        buy()             |                         |                         |                   |
             +------------------------> |          check()        |                         |                   |
             |                          +-----------------------> |          check()        |                   |
             |                          |                         +-----------------------> |                   |
             |                          |                         |                         |                   |
             |                          |                         |         Status [0x10]   |                   |
             |                          |       Status [0x10]     | <-----------------------+                   |
             |        revert()          | <-----------------------+                         |                   |
             | <------------------------+                         |                         |                   |
             |                          |                         |                         |                   |
+---------------------------+           |                         |                         |                   |
|                           |           |                         |                         |                   |
| Updates ID with provider  |           |                         |                         |                   |
|                           |           |                         |                         |                   |
+---------------------------+           |                         |                         |                   |
             |                          |                         |                         |                   |
             |         buy()            |                         |                         |                   |
             +------------------------> |        check()          |                         |                   |
             |                          +-----------------------> |         check()         |                   |
             |                          |                         +-----------------------> |                   |
             |                          |                         |                         |                   |
             |                          |                         |       Status [0x11]     |                   |
             |                          |                         | <-----------------------+                   |
             |                          |                         |                         |                   |
             |                          |                         |                         |   check()         |
             |                          |                         +-------------------------------------------> |
             |                          |                         |                         |                   |
             |                          |                         |                         |  Status [0x11]    |
             |                          |       Status [0x11]     | <-------------------------------------------+
             |        Status [0x01]     | <-----------------------+                         |                   |
             | <------------------------+                         |                         |                   |
             |                          |                         |                         |                   |
             |                          |                         |                         |                   |
             |                          |                         |                         |                   |
             +                          +                         +                         +                   +
  • rationale

    • encoding

    • Alternative

    • Multiple Returns

    • Human Readable

    • Extensibility

    • EVM codes

    • Empty space

    • Nibble Order

  • Implementation

GitHub - expede/ethereum-status-codes: Status codes for Ethereum smart contracts

  • semantic

セマンティックウェブ | WWW用語辞典 | IT用語辞典 | 日立ソリューションズ EIPs/ at master · ethereum/EIPs · GitHub

Mastering Ethereum: Ethereum Clients

今日はMastering Etherumのなかのethereum clientsの項目を読んだ。



  • Ethereum Networks
Full Node Advantages and Disadvantages
Public Testnet Advantages and Disadvantages
Local Instance (ganache) Advantages and Disadvantag

Running an Ethereum client
Hardware Requirements for a Full Node
Minimum Requirements: 
Recommended Specifications:

Software Requirements for Building and Running a Client (Node)
Go-Ethereum (Geth)
The First Synchronization of Ethereum-based Blockchains
JSON-RPC Interface
Remote Ethereum Clients
Mobile (Smartphone) Wallets
Browser wallets



  • どういうイーサリウムクライアントが存在しているか

  • ルノード、テストネット、プライベートネットの特徴

  • それぞれのメリット、デメリット

  • parity/gethをはじめとしたクライアントの説明と概要説明、メリットデメリット

  • どのようなファイル形式で扱われるか。

  • 起動方法

  • remote client

  • mobile wallet

  • browserwallet






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


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

mastering ethereum


  • introductionの項目

we’ve set up a wallet using MetaMask and we’ve funded it using a faucet on the Ropsten Test Network. We received ether into our wallet’s Ethereum address.

- EOAとcontractに関して
- walletの説明(walletとはworld computer/evmの入り口、mobile, desktop, web- base etc...)
- metamaskの説明
- 実際にremix上でfaucetやコントラクトの作成(ropsten)




  • erc20のトークン発行とmyetherwalletとの接続と送受金。
  • erc721のdapps作成、画像変更、画像生成アルゴリズムの作成と実装
  • mvp(minimalvaiableplasma)の動作確認と、関連プロジェクトの確認、vyperでのmvpを取り込んだプロトコルの開発





mvp(minimal viable plasma)に関して



dapps に関してはあと数個作って、実装までのテンプレ的なフローを作ったらある程度はそこで止めといても良い気がする。dexみたいに関連プロトコル繋げる拡張可能性のあるものは作っておくが。web側のデプロイはgkeベースにしても良いがいかんせんお金がかかるのでgaeにするか(コストどうなんだろ?)、もしくは普通にサーバー借りてnginxかApacheで組むか、firebase でも使うか、netlify見ないなの使うかプロトみたいな軽いやつデプロイ用と長期でデプロイするので従量課金か定額か、自由度が効くか、固定化されたやつか試しながら考える。



eip-1010: Uniformity Between 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c

This document proposes to improve the uniformity of ether distribution between wallet address 0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B and wallet address 0x15E55EF43efA8348dDaeAa455F16C43B64917e3c which are currently experiencing a significant non-uniformity.


EIPs/ at master · ethereum/EIPs · GitHub

eip-1011: Hybrid Casper FFG

Specification of the first step to transition Ethereum main net from Proof of Work (PoW) to Proof of Stake (PoS). The resulting consensus model is a PoW/PoS hybrid.

This EIP specifies a hybrid PoW/PoS consensus model for Ethereum main net. Existing PoW mechanics are used for new block creation, and a novel PoS mechanism called Casper the Friendly Finality Gadget (FFG) is layered on top using a smart contract.

Through the use of Ether deposits, slashing conditions, and a modified fork choice, FFG allows the underlying PoW blockchain to be finalized. As network security is greatly shifted from PoW to PoS, PoW block rewards are reduced.

This EIP does not contain safety and liveness proofs or validator implementation details, but these can be found in the Casper FFG paper and Validator Implementation Guide respectively.

ethereumのコンセンサスアルゴリズムをpowからpow/posのハイブリッド型にする提案。 Existing PoW mechanics are used for new block creationの上にcasperFFGと呼ばれるposアルゴリズムを取り込んでその上でスマートコントラクト を実装運用することを目標とする。


  • epoch: The span of blocks between checkpoints. Epochs are numbered starting at the hybrid casper fork, incrementing by one at the start of each epoch.
  • finality: The point at which a block has been decided upon by a client to never revert. Proof of Work does not have the concept of finality, only of further deep block confirmations.
  • checkpoint: The block/hash under consideration for finality for a given epoch. This block is the last block of the previous epoch. Rather than dealing with every block, Casper FFG only considers checkpoints for finalization. When a checkpoint is explicitly finalized, all ancestor blocks of the checkpoint are implicitly finalized.
  • validator: A participant in the Casper FFG consensus that has deposited ether in the casper contract and has the responsibility to vote and finalize checkpoints.
  • validator set: The set of validators in the casper contract at any given time.
  • dynasty: The number of finalized checkpoints in the chain from root to the parent of a block. The dynasty is used to define when a validator starts and ends validating. The current dynasty only increments when a checkpoint is finalized as opposed to epoch numbers that increment regardless of finality.
  • slash: The burning of some amount of a validator's deposit along with an immediate logout from the validator set. Slashing occurs when a validator signs two conflicting vote messages that violate a slashing condition. For an in-depth discussion of slashing conditions, see the Casper FFG Paper.


Casper FFG solves problems such as "Nothing at Stake" and "Long Range Attacks" through requiring validators to post slashable deposits and through defining economic finality.


EIPs/ at master · ethereum/EIPs · GitHub

eip-1013: Hardfork Meta: Constantinople

This meta-EIP specifies the changes included in the Ethereum hardfork named Constantinople. Constantinopleという名のハードフォークを含んだ変更部分の具体化


Codename: Constantinople Aliases: Metropolis/Constantinople, Metropolis part 2 Activation: Block >= TBD on the Ethereum mainnet Block >= TBD on the Ropsten testnet Included EIPs: EIP 145: Bitwise shifting instructions in EVM EIP 210: Blockhash refactoring EIP 1014: Skinny CREATE2 EIP 1052: EXTCODEHASH Opcode EIP 1087: Net gas metering for SSTORE operations TBD: Ice-age delay


EIPs/ at master · ethereum/EIPs · GitHub