Ethereumのチェーン同期法 Full / Fast / Snap

GBECの解説動画の資料です。
https://goblockchain.network/2021/04/geth_sync_mode/

Transcript

1. Ethereumのチェーン同期方法
 Full / Fast / Snap

2. 1 ブロックチェーンの同期
 • Bitcoinの場合
 チェーンの同期＝UTXOセットの同期
 • Ethereumの場合
 チェーンの同期＝ステートツリーの同期
 
 Node
 Node
 Node
 Node
 Node
 Local chain 
 Local chain 
 Local chain 
 Local chain 
 Local chain 
 ネットワークに参加したばかりのノードは、 
 接続したピアからブロックをダウンロードし、 
 ローカルのブロックチェーンのコピーを構築する。 
 
 他のノードが持つ全ブロックのコピーが終わると 
 ブロックチェーンの同期が完了する。 

3. 2 Ethereumのステート
 • ステートツリー
 各アカウントのステートで構成されるツリー
 ◦ ストレージツリー 
 各アカウントのストレージツリー
 • トランザクションツリー
 ブロック内のトランザクションで構成されるツリー
 • レシートツリー
 ブロック内のトランザクションレシートで構成されるツリー
 
 ↑の解説については、GBEC動画「Coparing Bitcoin and Ethereum」参照↓
 https://goblockchain.network/2020/02/comparing-bitcoin-and-ethereum/
 
 
 同期のボトルネックになるのはここ

4. 3 Merkle Patricia Trie
 EthereumでKey-Value形式でデータを格納し、その暗号学的なコミットメントを
 提供するhex-aryツリーで、データの挿入・削除が効率的に行える
 
 
 
 
 
 
 
 
 
 詳しいデータ構造や仕組みはGBEC動画「RLPとMerkle Patoricia Tree」参照↓
 https://goblockchain.network/2020/01/rlp-merkle-patrical-tree/
 Root Hash
 0
 1
 2
 ...
 e
 f
 値
 Hash
 0
 1
 2
 ...
 e
 f
 値
 Hash
 0
 1
 2
 ...
 e
 f
 値
 各中間ノードは最大16個の
 子ノードのハッシュ値を持つ
 Hash
 5e3(ニブル)
 値
 ・・・
 Hash
 f(ニブル)
 値
 Hash
 4c21(ニブル)
 値
 あるキーの値は、ルートノードから
 キーのデータを辿った先の
 リーフノードに存在。
 キー「1e…f」の値

5. 4 Full sync
 最も単純なブロックチェーンの同期方法
 
 
 
 
 
 
 ブロック内のトランザクションをすべて実行し、ステートツリーを更新
 
 • 一番トラストレスにステートツリーを構築できる
 • ジェネシスブロックから最新ブロックまですべてのトランザクションを実行するのはヘビー
 ◦ 現状、性能の良いマシンで初期同期に1週間から10日
 ◦ CPUリソースとディスクIOに負荷
 New Block
 Transactions
 New Root
 EVM

6. 5 Fast sync
 Geth v1.6.0から導入された高速同期モードで、ある時点のツリーを直接ダウンロードする 
 
 ピボットブロックを選択
 ・・ ・・ ・・ ・・ IBD Node
 Peer
 GetNodeData
 NodeData
 ピボットブロックの
 ステートルートハッシュをトリガーに
 ツリーのノードデータを要求
 NodeDataで対象のノードデータを送信
 ルートノードから、下に
 すべてのノード情報をダウンロードし
 ステートツリーを復元
 ステートツリー復元後はFull syncと同様、
 トランザクションを実行してステートツリーを更新

7. 6 Fast syncのメリットとボトルネック
 • Fast syncのメリット
 ◦ ジェネシス〜全Txを実行する必要がなくなり、同期速度が向上（約11時間）
 • Fast syncのボトルネック
 ◦ ステートツリーの成長
 
 ・・ ・・ ・・ 現在、mainnetのステートツリーには、約 6億7500万個の
 ノードが存在し、そのダウンロードがボトルネックに 
 
 • 最低でも175万回の通信のラウンドトリップが発生。 
 → ネットワークのRTTの合計が約 150分
 • ピアがGetNodeData要求に対応する際の 
 ディスクアクセスが約2700回弱。 
 →構造上ランダムアクセスになり、 
 10ピアと並行実行しても約 108分のRead時間
 • GetNodeDataによるハッシュのアップロードが約21GB、 NodeDataによ るダウンロードが2倍ちょっと。 
 →アップロードに56分、ダウンロードに63分
 Fast syncではネットワークの帯域幅、レイテンシー、ディスクIOがボトルネックに 

8. 7 Snap sync
 Geth v1.10.0から利用可能になったスナップショットを利用した同期方法
 SNAP protocol: https://github.com/ethereum/devp2p/blob/master/caps/snap.md 
 
 
 Peer
 ・・ ・・ ・・ Snapshot
 IBD Node
 チェーンのある時点のViewであるSnapshotを作成 
 GetAccountRanges
 AccountRange
 GetStorageRanges
 StorageRange
 GetByteCodes
 ByteCodes
 取得したステートデータから 
 ツリーを再構築
 
 大量のツリーの中間ノードを 
 ダウンロードせずに済み、 
 Fast syncのボトルネックを解消 

9. 8 Snap syncのトレードオフ
 • Snap syncに同期時間が短縮
 
 
 
 
 
 
 • Snap syncのオーバーヘッド
 ◦ スナップショットの初期作成に1日〜1週間かかる （要：スナップショットを持つピアへの接続） 
 ◦ 現状20〜25GBの追加のディスクスペースが必要 
 ◦ 巨大なReorgが発生するとスナップショットを再作成する必要がある 
 ▪ Reorgに対応するためスナップショットは永続化レイヤーと 
 インメモリの差分レイヤーで構成される。 
 再作成は、永続化レイヤーに影響を与えるReorgが発生した場合のみ。