イーサリアムにおけるストレージ爆発問題の分析と最適化

特邀专栏作者

2021-12-28 11:22

この記事は約3310文字で、全文を読むには約5分かかります

DeFi や GameFi などの分散型アプリケーションの活発な開発により、低トランザクション手数料で高性能なブロックチェーンの需要が大幅に増加しています。この記事では、イーサリアムがス

背景

DeFiやGameFiなどの分散型アプリケーションの活発な開発により、取引手数料が低い高性能ブロックチェーンに対する需要が大幅に増加しています。ただし、高性能ブロックチェーンを構築する際の主要な課題は、ストレージの爆発的な増加です。下の画像は、Etherscan から取得した、Ethereum フルノード (アーカイブ) のブロックチェーンデータサイズを示すグラフです。

副題

ストレージのオーバーヘッドを分析する

ストレージの使用状況をさらに分析すると、ブロックデータは約 300 GB (ブロックの高さ 0 ～ 13.6 M) しか占めておらず、9 TB よりもはるかに少ないことがわかります。では、残りの 8.7TB のデータはどこから来たのでしょうか?

ブロック

ブロック
州
取引の領収書

その中で、状態は8.7TBの主なコンポーネントです。そのため、ストレージの爆発を「状態の爆発」と呼ぶこともあります。しかし、なぜ州はこれほど大きいのでしょうか?

イーサリアムの状態とは何ですか?

イーサリアムの状態はマークルパトリカツリー (MPT) です。

リーフノードはアドレス (0x...) => アカウントのマッピングであり、アカウントにはアドレスに関連付けられた残高、ナンスなどが保存されます。
内部ノードはツリー構造を維持するため、ツリー全体のハッシュルートを迅速に計算できます。

副題

フルノードを取得する

アーカイブノード状態の爆発の問題を解決するために、Geth の天才エンジニアは、MPT を定期的にのみ保存する「プルーン」モードと呼ばれる新しいモードを作成しました。ここでは、ノードが 3 ブロックごとの MPT のみを保存する単純化された例を示します。 (状態ブロックを含まない状態を取得するには、ノードはそのブロックの前の最新の状態を取得し、後続のトランザクションを再実行する必要があることに注意してください)。

副題

Geth 用の高速同期可能なフルノード

Genesis ブロックからすべてのトランザクションを再生してノードを実行する場合の問題の 1 つは、すべてのトランザクションの再生に時間がかかることです。一般に、そのようなノードを確立してジェネシスブロックからのネットワークの最新の状態に追いつくには数週間かかります。ノードの起動プロセスを高速化するために、Geth は高速同期モードをさらに提供します。このモードでは、ブロックの前の履歴 MPT を再生および維持することなく、最新の安定したブロックの MPT をダウンロードできます。 MPT をダウンロードした後、完全なノードのように新しいブロックを (定期的な状態ストレージを使用して) 再生します。

質問

現在のイーサリアムのストレージサイズが 447GB および 15 TPS であるため、1TB SSD を搭載した一般的な構成のコンピューターは、かなりの期間 (たとえば数年) にわたってイーサリアムノードを実行できるはずであると予想されます。それでは、ストレージの爆発や状態の爆発は本当にあるのでしょうか?おそらくイーサリアムは今後数年はそうではないでしょうが、イーサリアムの仮想マシン (EVM) を数百または数千の TPS まで拡張できたらどうなるでしょうか?

もう一つの EVM ベースのチェーン、Binance Smart Chain (BSC) に注目してみましょう。 2021 年 12 月 8 日の時点で、BSC は次のとおりです。

約 984 GB のオンチェーンデータのうち、ブロックが約 550 GB、状態が約 400 GB を占めます。
20億6,623万トランザクション、100 TPS

トランザクション数によってデータサイズをさらに予測すると、次のことが得られます。

TPS が 100 の場合、約 3,153 万 TPY になります。

1 年後、合計 TX 〜 5,219M、ブロック〜 1.375 TB、状態〜 1.085 TB
3 年後、合計 TX ~11,525M、ブロック ~3.025TB、状態 ~2.387 TB

TPS が 150 (観測されたピーク TPS) の場合、約 4,730 万 TPY になります。

1 年後、合計 TX ~6,796M、ブロック ~1.809 TB、状態 ~1.427 TB
3 年後、合計 TX 〜 16,256M、ブロック〜 4.327 TB、状態〜 3.414 TB

要約すると、BSC の場合、現在の速度が維持されるか、それ以上であれば、すぐにイーサリアムアーカイブノードと同じストレージサイズに達することになりますが、これは通常のコンピューターでは実行がほぼ不可能です。

非常に高い TPS を備えたブロックチェーンのストレージ爆発問題

非常に高い TPS を持つブロックチェーン (QuarkChain が実行できるなど) についてより大胆な仮定を立てた場合、この数値はどうなるでしょうか? 1000 TPS のブロックチェーンを考えて、そのブロックと状態のサイズを分析してみましょう。次のようになります。

TX サイズが約 100 バイトであると仮定すると、各ブロックに必要なストレージは 1000 (TPS) * 100 (TX あたりのバイト数) * 365 * 24 * 3600 = 2.86 TB となります。
MPT に 100 億のアカウント (世界の人口よりも多い!) があると仮定すると、状態のサイズは 150G (イーサリアムの状態サイズ) / 0.18B (イーサリアムの一意のアドレス) * 10B = 8.3 TB になると予想されます。

これらの数字をまとめると、これは通常の構成のほとんどのコンピューターでは処理できない要件であるという結論に達するのは簡単です。

最適化

副題

状態ストレージの最適化

私たちが提案する最初の最適化は、MPT の代わりにプレーン KV を使用することです。 MPT が大きい場合、MPT 内のすべての内部ノードのコストが非常に高くなる可能性があります。そして、最適化により MPT のすべての内部ノードが削除されます。各アカウントのデータが約 50 バイト (20 アドレス + 2 ノンス + 12 アカウント + その他) であると仮定すると、次の 100 億アカウントのデータは次のように保存できます。

~ 10B * 50 + 100GB (コード) = 600 GB、MPT バージョンの約 1/10!

プレーン KV を使用することには大きな利点がありますが、大きな問題は、このような短いブロック間隔で各ブロックのハッシュ後の状態を計算できないことです。これは、イーサリアムの次の利点が失われることを意味します。

高速同期: 任意のブロックの状態をダウンロードし、残りのブロックを再生することでネットワークを迅速に同期します。
フォーク検出 (またはビザンチン検出): ピアから新しく作成されたブロックが、ローカルで実行されたブロックとは異なる状態になるかどうか。

高速同期を有効にするために、定期的なスナップショットブロック (スナップショット間隔 = エポック = 例: 14 週間) があります。スナップショットブロックには、前のスナップショットブロックの事後状態ハッシュ (トランザクション実行後の状態ハッシュ) である前状態ハッシュの追加情報が含まれています。

非スナップショットブロックは状態ハッシュを維持しませんが、その代わりに、そのブロックのすべてのトランザクションの元のデータベース操作 (削除、更新) のハッシュを含む増分ハッシュを持ちます。これによりフォーク検出が可能になります。
Ethereum のブロックには、トランザクション後の状態ハッシュではなく、トランザクション前の状態ハッシュを使用します。その理由は、ノードはトランザクション後にすぐに状態ハッシュを計算できないためですが、トランザクション前の状態ハッシュを使用することで、ノードはエポック間隔全体を使用してハッシュを計算できるためです。たとえば、状態ハッシュ計算が 1 秒あたり 10M の状態データを処理すると仮定すると、600 GB の状態全体を計算するには、600 GB / 10M ~ 16.67 時間かかります (エポック = 14 週間と比較)。

事前状態ハッシュを計算するプロセスは次のとおりです。

1. スナップショットブロックが受信されて完了すると、その KV 状態がスナップショットされ、すべての KV エントリ (アドレス => アカウント) を反復処理してハッシュを計算するバックグラウンドスレッドが作成されます。

2. 次のスナップショットブロックが作成されると、計算された前の状態のハッシュ値がそのブロックに保存されます。同様に、ノードは KV の別のスナップショットを作成し、バックグラウンドでそのハッシュを計算します。

3. 次のスナップショットブロックが作成されると、状態前のハッシュの保存に加えて、ノードはスナップショットブロックの KV スナップショットを解放できるようになります。これは、スナップショットブロックから削除/更新されたすべてのデータが自動的にガベージコレクションされることを意味します。 (例: levelDB での圧縮)