1 Yellow Paper から読み解くEthereumブロックチェーン の詳細仕様 Reading out specifications from Ethereum Yellow Paper 2018/11/13 Hikalab Naochika Hanamura

2 これまでやってきたこと 自己紹介：2017年5月頃からブロックチェーンのエンジニアをしており、開発 や暗号通貨の監査などに関わってきました 開発・研究 •  ブロックチェーンデータの分析基盤構築 •  ブロックチェーン領域のモニタリングサービス開発 •  Moneroのトレーサブルリング署名研究 コミュニティ活 動 •  DashのWhitePaper翻訳関与 •  技術ブログ「Neutrinoで働くブロックチェーンエンジニアのブログ」 (www.blockchainengineer.tokyo/) ҉߸௨՟ 監査 •  暗号通貨監査の技術アドバイザリー ✓ 特に取引所の監査手続開発 ✓ 特定通貨の監査手法などのリサーチ 花村直親（Naochika Hanamura） @naomasabit

3 自己紹介：8月からcatabiraという会社を共同創業してブロックチェーンデータ の分析・モニタリングSaaSを作っています https://catabira.com/ We are hiring.

•  Ethereum Yellow PaperとはEthereumの詳細仕様を定めたもの。Dr.Gavin Woodに最 初定められて、議論しながら作られた。 •  詳細すぎるほどに多くの記号や数式を用いていることが特徴。多くの参加者でコンセ ンサスをとれるためと思われる。 •  今回読むのはBYZANTIUM VERSION e94ebda - 2018-06-05 Yellow PaperはEthereumの詳細仕様を定めたもので、読み解く事で データ構造など開発向けの知識を得られる 4 The Yellow Paper is a formal definition of the Ethereum protocol, originally by Gavin Wood, currently maintained by Nick Savers and with contributions from many people around the world.

•  一緒にEthereum Yellow Paper勉強会をしていただいた@TomoyaIshida04 さん、T.Mさん、T.Fさんありがとうございました。色々と引用させていただき ました 謝辞 5

Ethereumとは •  Abstract •  1. Introduction •  2. The Blockchain Paradigm •  3. Conventions Ethereum Data Modelの概要について •  4. Blocks, State and Transactions Transaction/Contract Creationについて •  4. Blocks, State and Transactions •  7. Contract Creation Recursive Length Prefixについて •  Appendix B. Recursive Length Prefix Transaction/Message Callについて •  8. Message Call Transaction/Gasについて •  5. Gas and Payment より Ethereum Virtual Machine(EVM)について •  9. Execution Model •  Appendix G. Fee Schedule •  Appendix H. Virtual Machine Specification State / World State •  4. Blocks, State and Transactions Block/ブロックの構造 •  4. Blocks, State and Transactions Block/ブロックチェーンの正しさの基準 •  10. Blocktree to Blockchain •  11. Block Finalisation まとめ •  14. Conclusion 目次とrefer章 6

•  6. Transaction Execution •  12. Implementing Contracts •  13. Future Directions •  15. Acknowledgements •  16. Availability •  Appendix A. Terminology •  Appendix C. Hex-Prefix Encoding •  Appendix D. Modified Merkle Patricia Tree •  Appendix E. Precompiled Contracts •  Appendix F. Signing Transactions •  Appendix I. Genesis Block •  Appendix J. Ethash •  Appendix K. Anomalies on the Main Network •  Appendix L. List of mathematical symbols Referしない章 7

Ethereumとは Abstract 1. Introduction 2. The Blockchain Paradigm 3. Conventions より

ブロックチェーンのパラダイムは、暗号学的に保護されたトランザクションと組み合わせると、多くのプ ロジェクトを通じてその有用性が実証された。Bitcoinは最も注目されている。このような各プロジェクト は、分散化されたシングルトンのコンピューティングリソース上の単純なアプリケーションと見ることが できる。 このパラダイムは、状態を共有したトランザクション型シングルトンマシンと呼ぶことができる。 Ethereumはこのパラダイムを一般化された方法で実装する。 さらに、それは、それぞれ異なる状態お よび動作コードを有するが、メッセージ通信フレームワークを介して他のものと相互作用することがで きるリソースを提供する。その設計、実装の問題、それが提供する機会、そして我々が想定する将来 のハードルについて議論する。 Ethereumとは、トランザクション型シングルトンマシンを一般化して 実装したプラットフォームである 9 > The blockchain paradigm when coupled with cryptographically-secured transactions has demonstrated its utility through a number of projects, with Bitcoin being one of the most notable ones. Each such project can be seen as a simple application on a decentralised, but singleton, compute resource. We can call this paradigm a transactional singleton machine with shared-state. > Ethereum implements this paradigm in a generalised manner. Furthermore it provides a plurality of such resources, each with a distinct state and operating code but able to interact through a message- passing framework with others. > We discuss its design, implementation issues, the opportunities it provides and the future hurdles we envisage. Abstract.

> There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another. このプロジェクトには多くの目標がある。 1つの重要な目標は、互いに信頼する手段を 持たない同意する個人間の取引を円滑にすることである（トラストレスな取引手段の実 現） > By specifying a state-change system through a rich and unambiguous language, and furthermore architecting a system such that we can reasonably expect that an agreement will be thus enforced autonomously, we can provide a means to this end. リッチで明確な言語で状態(state)を変更するシステムを指定し、それによって自律的に 協定が施行されることを合理的に期待できるようなシステムを構築することで、我々は このための手段を提供することができる Ethereumの大きな目的の一つは、お互いの事を信頼しなくても（＝ト ラストレスに）個人間の取引を円滑にする事 10

Ethereumは「state(状態)を共有したトランザクションベースの stateマシン」と言え、genesis stateから段階的にstateを更新する > Ethereum, taken as a whole, can be viewed as a transaction-based state machine: we begin with a genesis state and incrementally execute transactions to morph it into some final state. 11 Gene sis State 1 State 2 State n Transaction Transaction Transaction … > It is this final state which we accept as the canonical “version" of the world of Ethereum

•  state（状態）には、アカウント残高、評判、信託取り決め、現実世界の情報に関する データなどの情報が含まれている一言で言えば、現在コンピュータで表現できるも のはすべて許容される state（状態）は、Ethereum世界の「バージョン」とも言え、 現実世界の状態を表現するとしている 12 •  Final state がEthereum世界の正当なバージョンとみなせる

•  “highly structured”ͰTop LevelͷState Value͸ΪϦγϟখจࣈͰଠจࣈ σ - ϫʔϧυεςʔτɹμ-ػցঢ়ଶ •  ؔ਺͸ΪϦγϟେจࣈ Υ – EthereumͷstateભҠؔ਺ɹ •  ༻్Λࢦఆ͍ͨ͠৔߹͸খจࣈ΋ར༻͢Δ C – ίετؔ਺ / CSSTORE – SSTORE(Storage΁ͷอଘʣ͢Δίετؔ਺ •  KECCAK256ϋογϡؔ਺ʢSHA3ʣ͸”KEC”ͱͯ͠ఆٛ •  λϓϧ͸େจࣈͰఆٛɻݸผཁૉͷRefer͸ԼจࣈΛ͚ͭΔ T – EthereumͷτϥϯβΫγϣϯ Tn -τϥϯβΫγϣϯͷnonce •  ೚ҙͷ௕͞ͷ഑ྻ͸খจࣈͰଠจࣈ o – message callͷΞ΢τϓοτσʔλ •  ԑऔΓจࣈ͸ू߹ : Bytes : Integer Yellow Paper内でよく出てくる記号表記に関して（一部） 3. Conventions ΑΓ 13

Ethereum Data Modelの概要について 4. Blocks, State and Transactions より

Ethereumデータモデルの主要な構成要素として、Block、Transaction、 Stateがある 15 Block Transac tion Blockͱ͸ɺTransactionΛ·ͱ Ίͯ֬ఆ͢Δ୯Ґͷ͜ͱ State StateΛߋ৽͢ΔʮऔҾʯ Ethereumͷ࣋ͭʮঢ়ଶʯ ֤ΞΧ΢ϯτͷ࢒ߴͳͲ

State, Transaction, Transaction ReceiptはMerkle Patricia Trieという木構造 で保存されており、Blockにルートのハッシュ値が刻まれる。次頁から 主要なデータ項目を軸にYellow Paperを読み解く 16 Merkle Patricia TrieʹΑΔ໦ߏ଄؅ཧਤ https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture

Transaction/Contract Creationについて 4. Blocks, State and Transactions 6. Transaction Execution より

Transactionは、実行結果としてstateを変更し、message callとcontract creationに分けられる 18 >There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as `contract creation'). (4.2. The Transaction.) >A transaction (formally, T) is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. (4.2. The Transaction.) τϥϯβΫγϣϯ͸҉߸ॺ໊ͷ໋͍ͭͨྩͰɺ2ͭͷछྨ͕͋Δ •  contract creation ίϯτϥΫτΞυϨεΛ࡞੒͢ΔτϥϯβΫγϣϯɻ •  message call Message Callʢϝοηʔδίʔϧʣ͸ɺૹۚ΍ίϯτϥΫτͷίʔυɺؔ਺ͳͲΛݺ ͼग़͢ͱ͖ʹ࢖ΘΕΔτϥϯβΫγϣϯͰ͢ɻ ʹ෼͚ΒΕΔ

EthereumにおいてはEOA(Externally Owned Address)とContract Addressがあ る •  いわゆる「銀行口座」であり、秘密鍵と公開鍵を持っている •  スマートコントラクトのコードは保持していない EOA Contract Address •  スマートコントラクトのコードをもち、実行する「機械」 •  Etherを預けることも可能 •  DEX（分散型取引所）などもコントラクトコードとして動いている 19

スマートコントラクトをアドレスに乗せてEthereumにデプロイするこ とをContract Creationといい、実行式は以下で定義されている 20 1.  εςʔτ / World State 2.  ૹ৴ऀ / sender 3.  τϥϯβΫγϣϯ࡞੒ऀ / original transactor 4.  ར༻ՄೳΨε / available gas 5.  ΨεՁ֨ / Gas price 6.  ૹֹۚ / Value (Endowment) 7.  EVMͷॳظԽίʔυ / the initialisation EVM code 8.  ελοΫͷݱࡏͷਂ͞ / The present depth of the message-call/ contract-creation stack 9.  εςʔτͷมߋڐՄ / Permission to make modifications to the state 1.  มߋޙͷεςʔτ / World State 2.  ࢒ͬͨ gas 3.  accrued transaction substate 4.  Error message 5.  Output Data Contract Creation ͷτϥϯβΫγϣ ϯʹRecipient͸ͳ͍

新しいコントラクトアドレスはRLPエンコーディングとKECCAK256を 組み合わせて作られる 256 bit 96..255 … KECCAK256 - 256-bit hash func 21 RLPΤϯίʔσΟϯά – ࣍ϖʔδΑΓղઆ

RLP(Recursive Length Prefix)エンコーディング について Appendix B. Recursive Length Prefix

RLP(Recursive Length Prefix)エンコーディングはEthereumで利用される シンプルな符号化の方法である >RLP is intended to be a highly minimalistic serialization format; its sole purpose is to store nested arrays of bytes. Unlike protobuf, BSON and other existing solutions, RLP does not attempt to define any specific data types such as booleans, floats, doubles or even integers RLP͸ߴ౓ʹ࠷খԽͨ͠γϦΞϥΠθʔγϣϯϑΥʔϚοτͰɺωετ͞Εͨ Byte഑ྻΛอଘ͢Δ໨తͷͨΊʹ͋Δɻprotobuf΍BSONͳͲͱ͸ҧͬͯɺ Boolean΍FloatɺDouble΍Integer͑͞ఆٛ͠ͳ͍ Ethereum Wiki https://github.com/ethereum/wiki/wiki/Design-Rationale#rlp ΑΓ 23

1.  バイト配列が単純な1バイトで、128より小さい時、そのままアウトプットする 2.  バイト配列が56バイトより小さい場合、バイト配列の長さ＋128に等しいバイトを加 えた配列に等しくなる 3.  他の場合、ビッグエンディアン整数として解釈した時に最小となる入力バイト配列 の長さを、接頭辞として入力に付与する。加えて、その長さに183を足した長さを 接頭辞に付与する Yellow PaperのAPPENDIX Bにはバイト配列をRLPエンコーディングす る場合の定義が書かれている 24

go-ethereumのrlp packageを用いた簡易検証コードでYellow Paperに書か れていた3パターンのRLPエンコーディングを試行した 25 ࣮ߦ݁Ռ go-ethereumͷrlpΛ༻͍ͨ؆қݕূίʔυ

RLPエンコーディング Case1:バイト配列が単純な1バイトで、128より 小さい時、そのままアウトプットする 26 input: 1 => encoded: 01 input: 2 => encoded: 02 input: 127 => encoded: 7f encodedΛ16ਐ਺Ͱߟ͑Δͱೖྗ஋ͱಉ͡਺஋͕ग़͖͍ͯͯΔ

RLPエンコーディング Case2:バイト配列が56バイトより小さい場合、 バイト配列の長さ＋128に等しいバイトを加えた配列に等しくなる 27 input: dog => encoded: 83646f67 0x83: 0x80 + len(dog) = 0x80 + 0x03=0x83 0x64: d 0x6f : o 0x67: g input: doge => encoded: 84646f6765 0x84 : 0x80 + len(doge) = 0x80 + 0x04=0x84 0x64 : d 0x6f : o 0x67 : g 0x65 : e input: cat => encoded: 83636174 0x83 : 0x80 + len(cat) = 0x80 + 0x03=0x83 0x63 : c 0x61 : a 0x74 : t c

RLPエンコーディング Case2:バイト配列が56バイトより小さい場合、 バイト配列の長さ＋128に等しいバイトを加えた配列に等しくなる 28 input: 0123456789012345678901234567890123456789012345678901234 ⇒  encoded: b73031323334353637383930313233343536373839303132333435363738 3930313233343536373839303132333435363738393031323334 0xb7:0x80 + len(input) = 0x80(128) + 0x37(55) =0xb7(183) 0x30: 0 0x31: 1 0x32: 2 … 0x34: 4 55όΠτͷΠϯϓοτ

RLPエンコーディング Case3 : Case1, 2に当てはまらない場合の56バイ トの例 29 input: 01234567890123456789012345678901234567890123456789012345 => encoded: b838303132333435363738393031323334353637383930313233343536373839303 1323334353637383930313233343536373839303132333435 0138 / 0x0204 0xb8 : 183 + LEN(BE(LEN(input))) = 183 + LEN([38]) = 183 + 1 = 184 = 0xb8 0x38 : BE(LEN(input)) = BE(56) = BE(0x38) = 0x38 0x30 : 0, 0x31: 1, … 0x35 : 5 ϏοάΤϯσΟΞϯ੔਺ͱͯ͠ղऍͨ࣌͠ʹ࠷খͱͳΔೖྗόΠτ഑ྻͷ௕͞Λɺ઀಄ ࣙͱͯ͠ೖྗʹ෇༩͢ΔɻՃ͑ͯɺͦͷ௕͞ʹ183Λ଍ͨ͠௕͞Λ઀಄ࣙʹ෇༩͢Δ

RLPエンコーディング Case3 : Case1, 2に当てはまらない場合の1024バ イトの例 30 https://github.com/ethereum/go-ethereum/blob/release/1.8/rlp/encode_test.go ΑΓ input: “Lorem ipsum ....” encoded: b904004c6f72.... 0xb9 : 183 + LEN(BE(LEN(input))) = 183 + LEN([0x04 0x00]) = 183 + 2 = 185 = 0xb9 0x04 0x00 : BE(LEN(input)) = BE(1024) = 0x0400 0x4c : L 0x6f : o ...

（再掲）新しいコントラクトアドレスはRLPエンコーディングと KECCAK256を組み合わせて作られる 256 bit 96..255 … KECCAK256 - 256-bit hash func 31 RLPΤϯίʔσΟϯά

Transaction/Message Callについて 8. Message Call より

Message Call（メッセージコール）は、送金やコントラクトのコード、 コントラクトの関数などを呼び出すトランザクション >Aside from evaluating to a new state and transaction substate, message calls also have an extra component the output data denoted by the byte array o. This is ignored when executing transactions, however message calls can be initiated due to VM-code execution and in this case this information is used. •  Message Callは、stateやトランザクションのsubstateに変更を加えて、バイト配列Oで示されるア ウトプットデータを得る •  トランザクションを実行する最初は使われないが、VMコードの実行時に、返り値を使うなどの ケースでアウトプットデータが使用される、と言っている。 τϥϯβΫγϣϯͷ࣮ߦΛ্ࣜͰද͍ͯ͠Δɻ ࠨ͸ δ' :มߋ͞ΕͨޙͷWorld State g' :࣮ߦޙͷgasͷ஋ʢ࢒Γʣ A :τϥϯβΫγϣϯͷsubstateʢYellow Paperʮ6.1. Substate.ʯʹఆٛ͋Γʣ z :࣮ߦ݁Ռʢ੒ޭɾࣦഊʣ O:Ξ΢τϓοτσʔλ 33

Message Call Functionの定義は以下式になる 34 1.  変更された後のWorld State 2.  実行後のgasの値（残り） 3.  トランザクションのsubstate（Yellow Paper「6.1. Substate.」に定義あり） 4.  実行結果（成功・失敗） 5.  実行結果の返り値アウトプットデータ 1.  World State 2.  送信アドレス sender 3.  作成アドレス original transactor 4.  受信アドレス recipient 5.  コードが実行されるアドレス（通常は受信者） 　 the account whose code is to be executed 6.  利用可能ガス available gas 7.  送金額value 8.  ガス価格 gas price 9.  DELEGATECALL命令で利用されるvalue値 10. バイナリデータ(data) 11. メッセージコール、コントラクト作成スタックの 現在の深さ / the present depth of message-call/contract-creation stack 12. stateに変更を与える権限 / the permission to make modications to the state

Message Call（メッセージコール）は、例外が発生して実行が止まっ た場合、送信者へのガスの払い戻しは行われない >The account's associated code (identified as the fragment whose Keccak hash is [c]c) is executed according to the execution model (see section 9). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. ). •  コントラクト作成（contract creation）で失敗した場合と同様に、例外が発生し て実行が止まった場合、送信者へのガスの払い戻しは行われない •  Message Callによって変更を加えようとしていたstateは送信前に戻される 35

precompiled contractという複雑な計算処理をEVMでなく外部で処理し て実行している実行手法がある >As can be seen, there are eight exceptions to the usage of the general execution framework for evaluation of the message call: these are eight so-called `precompiled' contracts, meant as a preliminary piece of architecture that may later become native extensions. message callには8つの特殊な例外的とも 言える実行手法がある 1.  楕円曲線暗号で公開鍵を復元する機 能 （ecrecover関数と呼ばれるもの） 2.  SHA256ハッシュ 3.  RIPEMD160ハッシュ 4.  データコピー（identity 関数） 5.  任意の精度における冪剰余 6.  楕円曲線暗号の値を加算 7.  楕円曲線暗号の値を掛け算 8.  楕円曲線暗号のペアをチェック 36 contracts.go var PrecompiledContractsByzantium = map[common.Address]PrecompiledContract{ common.BytesToAddress([]byte{1}): &ecrecover{}, common.BytesToAddress([]byte{2}): &sha256hash{}, common.BytesToAddress([]byte{3}): &ripemd160hash{}, common.BytesToAddress([]byte{4}): &dataCopy{}, common.BytesToAddress([]byte{5}): &bigModExp{}, common.BytesToAddress([]byte{6}): &bn256Add{}, common.BytesToAddress([]byte{7}): &bn256ScalarMul{}, common.BytesToAddress([]byte{8}): &bn256Pairing{}, } https://github.com/ethereum/go-ethereum/blob/master/ core/vm/contracts.go ΑΓ go-ethererumͷprecompiled contract࣮ߦ෦ ʮAppendix E. Precompiled Contractsʯʹৄࡉఆ ٛ͋Γ

Contract CreationとMessage Callで共通の引数がある 37 Transactionʹڞ௨͢ΔҾ਺ •  nonce: ૹ৴ऀʹΑΔτϥϯβΫγϣϯ ͷ࿈൪ ܕ͸hexͰ2ͷ256৐·Ͱ •  gasPrice: 1gas୯ҐͰ෷͏ETH(wei)ͷ஋ஈ ܕ͸hexͰ2ͷ256৐·Ͱ •  gasLimit: ར༻gasͷ࠷େ஋ ܕ͸hexͰ2ͷ 256৐·Ͱ •  to: ૹΓઌΞυϨε͔ɺίϯτϥΫτ࡞ ੒࣌͸φ ΞυϨεͷ৔߹20byteɺίϯτ ϥΫτ •  ࡞੒࣌͸empty •  value: ૹΔETH(wei) ܕ͸hexͰ2ͷ256৐ ·Ͱ •  v, r, s: τϥϯβΫγϣϯʹॺ໊ͨ࣌͠ͷ ஋Ͱɺ͜ΕʹΑͬͯެ։伴ʢΞυϨ εʣ͕Θ͔Δɻ v͸2ͷ5৐·Ͱɻ r,sͷ ܕ͸hexͰ2ͷ256৐·Ͱ

Contract Creation , Message Callで、特有の引数はinit / dataとある 38 Contract Creationಛ༗ͷҾ਺ Message Callಛ༗ͷҾ਺ Init:ΞΧ΢ϯτ࡞੒࣌ͷॳظԽʹ͓͚Δ EVMίʔυ͕ॻ͔Ε͍ͯΔ data: input dataͱͯ͠ઃఆ͢Δɻయܕ తʹ͸ݺͼग़͢Function΍Ҿ਺ͳͲ͕ ؚ·ΕΔ

Ethereum Virtual Machine(EVM) とは 9. Execution Model Appendix G. Fee Schedule Appendix H. Virtual Machine Specification

•  EVMはEthereumの実行コンポーネントと言える。EVMは、スマートコントラクトのコード を行単位で実行する EVM – スマートコントラクトを実行するためのバーチャルマシンとし ての概念 •  EVMは、バイトコードとdataから Ethereum stateをどう変更するかを決定する実行モデ ル

EVMはシンプルなスタックベースのアーキテクチャであり、実行用の OPERATION（OPCODE）が定められている Appendix H. Virtual Machine Specification

608060405260043610604957600035 7c0100000000000000000000000000 000000000000000000000000000000 900463ffffffff16806360fe47b114604e 5780636d4ce63c146078575b600080f d5b348015605957600080fd5b506076 600480360381019080803590602001 9092919050505060a0565b005b3480 15608357600080fd5b50608a60aa565 b60405180828152602001915050604 05180910390f35b8060008190555050 565b600080549050905600a165627a 7a72305820d54b1c9f41f33b6d64f70f a185cfdf713f0b4f01eb132fcb6c1a851 db95a22c50029 例えば、左のようなスマートコントラクト(solidity)は右のOPCODEと対 応しておりEVMでの実行ステップごとにGasがかかる 42 pragma solidity ^0.4.24; contract SimpleStorage { uint storedData; function set(uint x) public { storedData = x; } function get() constant public returns (uint retVal) { return storedData; } } solidity bytecode PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH2 0x10 ... ... SWAP16 COINBASE RETURN EXTCODESIZE PUSH14 0x64F70FA185CFDF713F0B4F01EB13 0x2f 0xcb PUSH13 0x1A851DB95A22C5002900000000 ≡ ≡ OPCODE

OPCODEに関連するGasはAppendixなどを参照 43 Appendix G. Fee Schedule Appendix H. Virtual Machine Specification

•  EVMの実装として掲載されているリスト WikiにはEVMの実装リストがある https://github.com/ethereum/wiki/wiki/Ethereum-Virtual-Machine-(EVM)-Awesome-List#evm-implementations 44 https://github.com/ethereum/go-ethereum/blob/master/ core/vm/instructions.go vm packageͷҰ෦

Transaction/Gasについて 5. Gas and Payment より

•  Gasはトランザクションの送信でも、スマートコントラクトのデプロイ、ストレージ領域 の利用、EVM上でのOPCODE実行にもかかります •  スマートコントラクトの実行時のGasは、スマートコントラクトがEVMで実行される OPCODEに変換され、その実行単位ごとにかかる Ethereum上でトランザクションを利用するための手数料の単位として Gasがある 46 > Gas: The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-4), which is converted freely to and from Gas as required. Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low. (APPENDIX AΑΓ)

•  ネットワークの乱用や攻撃を避け、チューリング完全性を保つためにはプログラム に対して手数料をかける必要がある •  Ethereumはワールドコンピュータとしての思想で作られているのでチューリング完 全性を担保しようとしているが、自由に無限ループなどを起こすことができてしま うと、ネットワークを停止させかねない •  そのため、何らかの形で実行制限をつける必要があり、gasという手数料を設けて いる •  無限ループを起こしたとしてもgasが延々と消費されてしまうので、攻撃のインセ ンティブは減る Gasはチューリング完全性を保つため、プログラムに対して手数料を かける役割を持つ 47 >In order to avoid issues of network abuse and to sidestepthe inevitable questions stemming from Turing completeness, all programmable computation in Ethereum is subject to fees.

•  購入は、取引の種でもあるガス価格で行われる 送信者が定める消費上限値としてのGasLimit、1Gasに対して払うEther の設定値がGasPriceがトランザクションには設定される > The purchase happens at the according gasPrice, also specied in the transaction. > Every transaction has a specific amount of gas associated with it: gasLimit. This is the amount of gas which is implicitly purchased from the sender's account balance. GasLimit Gas͸جຊతʹ͸τϥϯβΫγϣϯૹ৴ऀͷ࢒ߴ͔Βফඅ͞ΕΔɻૹ৴ऀ͕εϚʔτίϯ τϥΫτΛ࣮ߦ͢Δ৔߹ͳͲʹɺ૝ఆ͍ͯ͠ΔΑΓ΋ଟ͘ͷGasΛফඅ͠ͳ͍Α͏ʹɺ্ ݶ஋ΛఆΊ͓͖ͯ·͢ɻͦͷ্ݶ஋͕GasLimit •  すべての取引には特定の金額のガス（gasLimit）が関連付けられている。 送信者の 口座残高から暗黙的に購入されたガスの量である 1Gas୯Ґʹ͍͘ΒEtherΛ෷͏͔Λઃఆ͢Δ஋͕GasPriceɻར༻͞ΕΔGasʹ GasPrice͕͔͚ΒΕͯɺEtherͷ୯Ґʹ௚͞ΕΔ GasPrice

•  トランザクションの実行結果をエンコードしてTransaction Receiptを作る Transactionの実行結果としてTransactionRecieptが発行される > 4.3.1. Transaction Receipt. > In order to encode information about a transaction concerning which it may be useful to form a zero-knowledge proof, or index and search, we encode a receipt of each transaction containing certain information from its execution. Transaction Receiptには R u : 使われたガス、R b : logのブルームフィルタ　R l : 実行ログ　R z : 実行の成否 が刻まれるとしている 49

State / World State, Account State 4. Blocks, State and Transactionsより

おさらいとしてEthereumとは「状態(state)を共有したトランザクショ ン型シングルトンマシン」と言える 51 ʢ࠶ܝʣ Gene sis State 1 State 2 State n Transaction Transaction Transaction …

Ethereumのstateは「world state」と「account state」がある 52 4.1. World State. The world state (state), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix B). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in modifed Merkle Patricia tree (trie, see Appendix D). (4. Blocks, State and Transactions ΑΓ) •  「world state」（ワールドステート）は、「address」と「account state」（アカウントステート） のマッピング情報である •  σ =‘world state’ σ[a] = ‘account state’ •  「account state」が持つ情報は次頁にて解説

「account state」はnonce、balance、storageRoot、codeHashの4項目を もつ 53 σ[a]:account state •  Nonce •  アドレスの作ったトランザクション数。マ イニングに関わるnonceとは別 •  Balance •  Ether残高(単位はWei) •  storageRoot •  アカウントが持っているstorage Merkle Patricia Trieのルートノードハッシュ(デ フォルトは空) •  codeHash •  EVMコードのハッシュ値

codeHashはスマートコントラクトコードがない場合、空白文字の KECCAK256ハッシュ値がはいる 54

Block/ブロックの構造 4. Blocks, State and Transactions(4.3. The Block.) より

Blockは、Transactionをまとめて確定する単位であり、マイニングと 呼ばれる作業で作成される 56 Bitcoin: A Peer-to-Peer Electronic Cash System 4. Proof-of-Work

•  H : ブロックヘッダ •  T : トランザクション •  U : 他のブロックヘッダ（ommer と呼ばれる分岐ブロック） BlockにはBlock Header, Transaction List, Ommers List(分岐したブ ロックのリスト)が含まれる

•  parentHash: 親ブロックのハッシュ値（KECCAK256） •  ommersHash: ommer ブロックリストのハッシュ値（KECCAK256） •  beneficiary: マイニングリワード受け取り用アドレス •  stateRoot: state Trieのルートハッシュ •  transactionsRoot: transaction Trieのルートハッシュ •  receiptsRoot: transactionReciept Trieのルートハッシュ •  logsBloom: BloomFilter用のIndex情報 •  difficulty: ブロックの採掘難易度 •  number: ブロック番号 •  gasLimit: ブロックに含められるGasLimit合計 •  gasUsed: ブロックに含めたトランザクションのGasUsed合計 •  timestamp: マイニングタイムスタンプ •  extraData: Blockに刻める32バイトのデータ領域 •  nonce: マイニングで求める値 •  mixHash: nonceからProofOfWorkで求められる中間値 ブロックヘッダには15項目が刻まれ、主要なTrie木のルートハッシュ も検証のために含まれている 58

ブロック内には、ブロックヘッダ以外にトランザクションリストと Ommer(Uncle) Blockリストが刻まれている // Request curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params": ["0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", true],"id":1}’ // Result { "id":1, "jsonrpc":"2.0", "result": { "number": "0x1b4", // 436 "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "parentHash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "logsBloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "stateRoot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "difficulty": "0x027f07", // 163591 "totalDifficulty": "0x027f07", // 163591 "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000", "size": "0x027f07", // 163591 "gasLimit": "0x9f759", // 653145 "gasUsed": "0x9f759", // 653145 "timestamp": "0x54e34e8e" // 1424182926 "transactions": [{...},{ ... }] "uncles": ["0x1606e5...", "0xd5145a9..."] } } eth_getBlockByHashͷExample https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getblockbyhash 59

Block/ブロックチェーンの正しさの基準 10. Blocktree to Blockchain 11. Block Finalisation

•  Bitcoinでは「最長チェーン」を「正しいチェーン」とみなしている ブロックチェーンのブロックは時々分岐し、どれかを「正しい」 チェーンとみなす必要がある 61

Ethereumでは「最も多くの計算能力が使われたチェーンを正しい」 としている 62 •  正規のブロックチェーンは、ルートからリーフまでのブロックツリー全体を通るパスで ある •  コンセプトとしては、最も計算量が多いパス、または”heaviest path”と言えるものを 特定する > The canonical blockchain is a path from root to leaf through the entire block tree. In order to have consensus over which path it is, conceptually we identify the path that has had the most computation done upon it, or, the heaviest path. (10. BLOCKTREE TO BLOCKCHAINΑΓ)

Difficulty=採掘難易度の合計を「最も多くの計算能力」の基準として いる 63 •  “Heaviest Path”は、分岐チェーンのうち、採掘難易度合計が最も大きいもの Total Difficulty Total Difficulty of parent Block Difficulty of Block Parent of Block

まとめ 14. Conclusion

65

ETH 2.0(Serenity) is in progress. 66