Bitcoinと Ethereumの違い　　　　　　　　　　　ブロックチェーンとデータ構造

ちゃーりー（@charlie_rebirth）

2016年 9月

ブロックチェーンの構造のこと

Bitcoinのブロックチェーン構造について

Mastering Bitcoinなどでよくまとまっている

(7章「ブロックチェーン」に詳細が解説）

が、 Ethereumのブロックチェーンは解説が世の中にあまりない？

それについて話します

Bitcoinのブロックチェーン

・ヘッダー部

・トランザクション部

＊　すべての取引情報（お金のやり取り）はブロックチェーンに書いてある。

ブロックチェーンのデータさえあれば残高わかる

ブロックの図

HEADER部：ブロックに関するデータ

timestampDifficulty:採掘難度Nonce: PoWの結果の値

Merkle Root: マークルツリーの根（ root)の値

Transactions部：取引データ

ex )Alice to Bob: 1BTC

Bob to Charlie: 0.5 BTC

etc

Merkle　 Root

ブロックの中のトランザクションデータの要約値

＝　取引が改ざんされていないことを確認するための値

マークルツリー（ハッシュ木）

マークル・パス

マークルツリーをたどって特定の取引データにたどり着くための必要最小限の情報

マークルパス

途中のノードのハッシュ値だけでたどることができる

Bitcoinのおさらい

Merkle Treeが使われる

取引データの整合性の確認ための木構造データ

・通貨を送るだけのシステムではない。

・ユーザーが任意のプログラムを書いてそれを実行させる（万能チューリング・マシン）

・取引データだけでなく、「状態データ」（ State)を記憶しないといけない

（全アカウント・コントラクトの情報）

膨大なデータ量！！！

Ethereumは複雑だった

Bitcoin

Ethereum

Ethereum Architecture

参考ページ

Ethereum block architecture

http://ethereum.stackexchange.com/questions/268/ethereum-block-architecture

> eth.getBlock(2040449){ difficulty: 57164803413005, extraData: "0xe4b883e5bda9e7a59ee4bb99e9b1bc", gasLimit: 4712380, gasUsed: 252000, hash: "0x00a75e75a5a70f7a2550718ae56a34904d63c8a28ef293a18611eb8766a58c92", logsBloom: "", miner: "0x61c808d82a3ac53231750dadc13c777b59310bd9", nonce: "0x5f130ae01311795b", number: 2040449, parentHash: "0x5ef63a62aa871d58b8f26cd4acda621557806a943f46ed76e401030f79982b2b", receiptRoot: "0x42dbcf6a2f8716f63d441459a96b54fdc6d70bc44f6641c144f24647c04c3a97", sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", size: 1896, stateRoot: "0xb4980433b3f53d0dbfffbe833102e0f37296b60081e9e8170975a05a767d7946", timestamp: 1470749971, totalDifficulty: 46140009996266484451, transactions: ["0xf38046731a2268e0558305449f366c49604bccc0c056efda0dac20207cecd802", "0x8c10abdf63e369d2db09297de90a9d8b2831ad0b796de36be8ef109643e7d6f5", "0x0a090cc48494aba9ab587e8e0b4d48e632d27578aab333adc37f85b79dbd1684", "0xaea8cfbae769dd579d274c0ebbf731b182167decf83ac6dd7c0f42f9d7551acf", "0x0547b8962b4be66a3636be1ad39221d21f4ad630e203ad62b7ac52ef8e5aabaa", "0x1505b8a9438f676c1d9a0173c4c60ac1e402c68c98832b44091fc73e2a6f66ff", "0x97da5d166c5a4fdb7963cbcb1877af4c48a541de4f333e9f73c69f896172ae93", "0x3e19c7a256538b938d91fdf7cd3df66c91a4d4f6a5d2fddd8c77ab4b265e9a3b", "0x3e5b07b25f339dcaf0d9052d1853aac30e4526cd3870c8c7f3fe48f4a21cbf30", "0x20649015c3f309095c5c80d164ac3ee69c11029cb334cd228f43b7f7f0bcc292", "0x67dd9ba7831f1008a2316d35622d3aeb9de3fcabc2a8691feff364148632724d", "0xf62f5d9d7b2964c63dca18b383fe03dc80b8a966d97049ccf8b64cd2416a9e6b"], transactionsRoot: "0xbcfd8a30e9f48aaf922babef7aa1ffbe36307ae37aa4c6f757e1281fa41d3b73", uncles: []}

ブロックチェーンに記録されているのはトランザクション情報のみ

✕「ブロックチェーンにコントラクトを書き込んであってすべての変数が保存されている」

正しくは↓

コントラクトそのものや、内部変数、状態変数のデータは

ブロックチェーン上には無い

大丈夫かそれ？

状態データ、アカウントデータ

各ノードでデータを保持してる

Transactionsを元に、各ノード独自で State Treeを計算して生成

State Tree（全アカウント・コントラクトの状態を記録した木構造のデータ）

容量が大きくなるが、ブロックチェーン本体さえあればいつでも再構築できるのがポイント（ State Treeを改ざんできない）

Merkle Patricia Tree

データの整合性 (改ざんへの耐性）のためのMerkle Tree

　　　　　　×

データの効率的保持のための State Tree（ Patricia Tree)

　　　　　　　　↓

融合合体

マークルツリー（ハッシュ木）

Radix Tree (基数木、トライ： Trie）

・検索が高速

・必要なノード（節）の数が多い

⇨

深くなるほどデータ容量がO(N^2）で増える

非効率

※ハッシュ値は長い文字列なので非効率

Patricia Tree(パトリシア木）

通常のトライ木と異なり、

辺には 1つの文字だけでなく文字の並びが

ラベルとして付与される。

これは長い文字列の集合や

長い接頭部を共有する文字列の集合などで

効果を発揮する。

パトリシア木

・必要なノード（節）の数が少なくできる。

⇨データ容量を減らせる・だが、実装は複雑になる

Merkle Patricia Trie

●Patricia Treeのように効率よくデータを格納・取り出しができる

●Merkle Treeのようにハッシュ値を元にしたツリー構造で改ざんされていない証明ができる

　（ツリーのどこかのデータが変わると State Root値が変わってしまう）

⇨　 State Treeにも暗号学的な改ざんへの耐性がある（ PoWに基づく）

State tree

● state root から分岐する木構造

● 各ノードはハッシュ値を保持し、子ノードのハッシュ値は親ノードのハッシュ値に影響を与える

● いずれかのノード内の値を変えると、ハッシュ値が変更 親ノードのハッシュ値が変更⇨⇨ root hashが変更される

● root hashが与えられた時、そのハッシュ値と整合性のある State treeのみが正しい。　

⇨　不正な変更は見つかる

※各ノードの保持するデータ

　ユーザーアカウント、コントラクトアカウント、様々な変数の値

Ethereum wiki / Ethereum Development Tutorialより

Ethereum Scalability and Decentralization Updates

Merkle Patricia tree のノードの種類

1. NULL (空文字 )　　 [ null ]

2. key-value型　 [ key, value]

3. 配列型　 [ v0 ... v15, vt ]　

例

＜以下の key:valueを記録する場合＞

('dog', 'puppy'), ('horse', 'stallion'), ('do', 'verb'), ('doge', 'coin')

key を 16進数の値（ ASCIIコード）に変換し、配列にする。（その配列は対応する valueまで辿る経路を表す）

[ 6, 4, 6, 15, 16 ] : 'verb'　[ 6, 4, 6, 15, 6, 7, 16 ] : 'puppy'[ 6, 4, 6, 15, 6, 7, 6, 5, 16 ] : 'coin'[ 6, 8, 6, 15, 7, 2, 7, 3, 6, 5, 16 ] : 'stallion'

Ethereum

基数木（ Radix Tree)で値を保存する場合

存在する全経路・分岐でノードを作成する必要がある

⇨

分岐（ノード）が多く、深くなればなるだけ記憶容量をとってしまう。

Merkle Patricia Tree

Patricia Tree状になるように計算（ key の値は RLPエンコーディングというもので変換されている）

ROOT: [ '\x16', A ]A: [ '', '', '', '', B, '', '', '', C, '', '', '', '', '', '', '', '' ]B: [ '\x00\x6f', D ]D: [ '', '', '', '', '', '', E, '', '', '', '', '', '', '', '', '', 'verb' ]E: [ '\x17', F ]F: [ '', '', '', '', '', '', G, '', '', '', '', '', '', '', '', '', 'puppy' ]G: [ '\x35', 'coin' ]C: [ '\x20\x6f\x72\x73\x65', 'stallion' ]

この時、子ノードへの参照である A,B,C,D,E,F,Gは ハッシュ関数 sha3([..... ]) によって算出される。

そのため、値が変わると参照値が変更され、 Rootのハッシュ値も変更される。

Patricia Treeに valueを格納する図

必要なノード数が少ない

⇨ 記憶容量の節約

詳細は

Understanding the ethereum triehttps://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/

または　

Ethereum wiki の Patricia Treeの項目参照

まとめ

●Ethereumでは、ブロックチェーンに全データを保持していなくても、改ざん不可能なデータ構造を各クライアントに保持させることができる。

●外部記録を有効に活用することで、ブロックチェーンのサイズの肥大化は抑えられているみたいだー。