今回読むのは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.
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とは、トランザクション型シングルトンマシンを一般化して 実装したプラットフォームである 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.
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
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
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ʢϝοηʔδίʔϧʣɺૹۚίϯτϥΫτͷίʔυɺؔͳͲΛݺ ͼग़͢ͱ͖ʹΘΕΔτϥϯβΫγϣϯͰ͢ɻ ʹ͚ΒΕΔ
ૹ৴ऀ / 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ͳ͍
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ྻΛอଘ͢ΔతͷͨΊʹ͋ΔɻprotobufBSONͳͲͱҧͬͯɺ BooleanFloatɺDoubleInteger͑͞ఆٛ͠ͳ͍ Ethereum Wiki https://github.com/ethereum/wiki/wiki/Design-Rationale#rlp ΑΓ 23
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
トランザクションの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
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
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ʯʹৄࡉఆ ٛ͋Γ
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ΑΓ)
• 無限ループを起こしたとしても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.
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
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), 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」が持つ情報は次頁にて解説
> 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ΑΓ)
naomasabit
chriscoyier
ufuk
bcantrill
sachag
kevinliebholz
jonyablonski
danielanewman
sstephenson
caitiem20
vanstee
62gerente
philnash
![「account state」はnonce、balance、storageRoot、codeHashの4項目を もつ 53 σ[a]:account state • Nonce • アドレスの作ったトランザクション数。マ](https://files.speakerdeck.com/presentations/ab23b216a34047e0966f7da4a2022dbf/slide_52.jpg){kind=link}
