BTC
ETH
HTX
SOL
BNB
View Market
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

形勢逆転: イーサリアムの現状

ECN以太坊中国
特邀专栏作者
この記事は約3978文字で、全文を読むには約6分かかります
このブログ投稿の目的は、ベルリンのハードフォークに先立って、イーサリアム プラットフォームに関する重大かつ明白な問題を正式に暴露することです。
AI要約
このブログ投稿の目的は、ベルリンのハードフォークに先立って、イーサリアム プラットフォームに関する重大かつ明白な問題を正式に暴露することです。

出典 | イーサリアムブログ

出典 | イーサリアムブログ

このブログ投稿の目的は、ベルリンのハードフォークに先立って、イーサリアム プラットフォームに関する重大かつ明白な問題を正式に暴露することです。

このブログ投稿の目的は、ベルリンのハードフォークに先立って、イーサリアム プラットフォームに関する重大かつ明白な問題を正式に暴露することです。

副題

州

イーサリアムの背景とその「状態」から始めましょう。

イーサリアムの状態は、プレフィックス ツリーの一種であるパトリシア マークル トライで構成されています。この記事では技術的な詳細には触れませんが、簡単に言えば、状態が成長するにつれて、ツリーの枝はますます密になっていきます。参加する各アカウントは新しい葉です。木の根と葉の間には、多数の「中間」ノードがあります。

特定のアカウント、つまりこの巨大なツリーの「葉」を見つけるには、ツリーのルートから中間ノードを経由して、最終的に探しているデータをハッシュするために 6 ~ 9 個のハッシュを解決する必要があります。 。

つまり、アカウントを検索するすべてのトライ クエリに対して、8 ~ 9 回の解析操作が実行されます。各解析操作はデータベース クエリであり、各データベース クエリは実際のディスク操作をいくつでも実行できます。ディスク操作の数を予測するのは困難ですが、トライ キーは暗号的にハッシュされている (衝突耐性がある) ため、キーは「ランダム」であり、これはデータベースにとって最悪のシナリオです。

イーサリアムが成長するにつれて、ツリーアクセス操作のガスコストを増加させることが常に必要になってきました。 2016 年 10 月、「上海攻撃」を経験した後、イーサリアム ネットワークはブロック高さ 2,463,000 でタンジェリン ホイッスル ハード フォークを受けました。これには EIP 150 が含まれており、特定の操作のガス コストが大幅に増加し、防御のための大量の変更が導入されました。 DoS攻撃に対して。

2019 年 12 月のイスタンブールのアップグレードでは、EIP 1884 が有効になり、ガス料金がさらに値上げされました。

EIP-1884 では、ガス料金に次の変更が導入されています。

➤SLOAD が 200 ガスから 800 ガスに増加

➤EXTCODEHASH が 400 から 700 ガスに増加

副題

問題

2019 年 3 月、Martin Swende は EVM オペコードのパフォーマンス測定を行っていました。その後の EIP-1884 はこの調査に基づいています。 Broken Meter は、EIP-1884 がアクティブ化される数か月前にこの論文 (2019/9) を発表しました。

2人のイーサリアムセキュリティ研究者、ヒューバート・リッツドルフ氏とマティアス・エグリ氏、そして論文著者の一人ダニエル・ペレス氏は、脆弱性を「武器化」し、イーサリアムのバグ報奨金プログラムに提出した。これは2019年10月4日のことです。

非常に詳細な内容が記載されているので、提出した文書をすべて読むことをお勧めします。

同日、Geth、Parity、Aleth の開発者は、クロスクライアント セキュリティ専用のチャネルでこの文書について知りました。

この脆弱性の本質は、ランダムなトライ クエリをトリガーすることです。簡単な例を次に示します。

研究者らのレポートでは、eth_call を使用して、メイン ネットワークを同期するノード上でこのペイロードを実行しました。以下は、実行中のデータであり、1,000 万ガスの費用がかかりました。

  • Parity: ~90s

  • Geth: ~70s

➤ EXTCODEHASH (400 ガス) は 1,000 万ガスを消費します

  • Parity : ~50s

  • Geth : ~38s

➤ 1000万ガスを消費するEXTCODEHASH(700ガス)

明らかに、EIP-1884 の変更はこの攻撃の影響を軽減するのに役立ちましたが、十分ではありませんでした。

大阪での開発者カンファレンスが近づいてきました。開発者カンファレンスでは、この問題に関する情報がメインネット上のクライアント開発者と共有されました。私たちはまた、ヒューバート、マティアス、そしてグレッグ・マルコウ(Chainsafe 社の彼は当時 ETC の仕事もしていました)にも会いました。 ETC の開発者もこのレポートを受け取りました。

2019 年が終わりに近づくにつれて、悪意のあるトランザクションによってブロック時間が数分の範囲に達する可能性があり、問題は以前の予想よりも悪化していることがわかっています。さらに悪いことに、開発者コミュニティは EIP-1884 に不満を抱いています。これは、EIP-1884 が一部の契約プロセスを破っており、ユーザーとマイナーがブロックのガス制限を引き上げることに非常に熱心であるためです。

副題

解決

解決

2 番目の方法は、クライアントのデータ モデルと構造を変更するソフトウェア エンジニアリングによって問題を解決することです。

副題

プロトコル層の働き

この種の攻撃に対処する方法に関する最初のリリースはここにあります。 2020 年 2 月に、EIP 2583 として正式にリリースされました。このアイデアは、トライ ルックアップの結果がミスになるたびにペナルティを課すことです。

しかし、Peter は、このペナルティの上限 (約 800) を事実上制限する「シールド リレー」攻撃という対抗策を見つけました。

ミス クエリにペナルティを課す場合の問題は、ペナルティを課すかどうかを決定するために最初に検索が必要になることです。ただし、ガソリン残量が違約金を支払うのに十分でない場合は、未払い消費が行われたことになります。たとえそれによって例外がスローされたとしても、これらの状態読み取りをネストされた呼び出しにラップすることが可能で、外部呼び出し元は (全額) ペナルティを支払うことなく反復攻撃を続けることができます。

このため、この EIP は放棄され、より良い代替案を探しています。

➤ Alexey Akhunov は、2 番目のガス源である石油の概念を提案しましたが、実行層には見えず、トランザクションがグローバルにロールバックされる可能性があるため、本質的にはガスと同じではありません。

➤ Martin は 2020 年 5 月にも同様の提案を作成しました (Gas And Karma)

これらのさまざまなメカニズムを繰り返しながら、Vitalik Buterin 氏は、ガスコストを直接増加させ、アクセスリストを維持することを提案しました。 2020年8月、MartinとVitalikはEIP-2929とその姉妹品であるEIP-2930の精製を開始した。

EIP-2929 は、これまでの問題の多くを効果的に解決します。

➤ 無条件にガスコストを増加させる EIP-1884 と比較して、EIP-2929 は未訪問部分のガスコストのみを増加させます。これにより、純コストの増加は 1 パーセント未満になりました。

➤ EIP-2930 の追加により、契約プロセスが中断されることはありません

2021 年 4 月 15 日、ベルリンのアップグレードで両方の EIP がアクティブ化されました。

副題

開発業務

Peter が 2019 年 10 月に提案した解決策は、「動的状態スナップショット」です。

スナップショットはイーサリアムの状態をフラット形式で保存するために使用される補助データ構造であり、Geth ノードのライブ操作中に完全にオンラインで構築できます。スナップショットの利点は、状態アクセスのための加速された構造として機能することです。

➤ アカウントまたはストレージ・スロットにアクセスするための O(log N) ディスク読み取り (x LevelDB オーバーヘッド) の代わりに、スナップショットにより直接 O(1) アクセス時間 (x LevelDB オーバーヘッド) を提供できます。

➤ スナップショットは,エントリあたり O(1) の複雑さでアカウントとストレージの反復をサポートするため,リモート・ノードは以前よりはるかに安価に順次状態データを取得できるようになります。

➤ スナップショットを使用すると、オフラインでの状態のプルーニングや他のデータ形式への移行など、より特殊な使用例も可能になります。

スナップショットの欠点は、元のアカウントとストレージ データが事実上複製されてしまうことです。メインネットの場合、これは追加の 25 GB の SSD スペースを意味します。

動的スナップショットの概念は 2019 年半ばから開始されており、当初の目的は主にスナップショット同期の実現を促進することでした。当時、ゲスのチームは多くの「大きなプロジェクト」で忙しかった。

➤ オフラインでトリミング

➤ 動的スナップショット + スナップショット同期

➤ シャーディングステートによる LES (Light Ethereum Subprotocol) ステート分散の実現

副題

要約する

要約する

2021 年 3 月から 4 月にかけて、snap/1 プロトコルが geth クライアントに実装され、新しいスナップショット ベースのアルゴリズムによる同期が可能になりました。まだデフォルトの同期モードではありませんが、これはスナップショットを攻撃防御としてだけでなく、ユーザーにとっても重要な最適化にするための重要なステップです。

合意によれば、ベルリンの改修は2021年4月に完了する予定だ。

以下に、AWS モニタリング環境で開発されたベンチマークをいくつか示します。

➤ ベルリンアップグレード前、スナップショットなし、25M ガス: 14.3 秒

➤ ベルリンのアップグレードの前に、25M ガス: 1.5 秒のスナップショットがありました。

➤ ベルリンのアップグレード後、スナップショットなし、25M ガス: ~3.1 秒

➤ ベルリンのアップグレード後、スナップショットあり、25M ガス: ~0.3 秒

大まかな数字は、Perlin のアップグレードにより攻撃の有効性が 5 分の 1、スナップショットの効果が 10 分の 1 に軽減され、合計で影響が 50 分の 1 に軽減されたことを示しています。

現在、メインネット (15M ガス) では、スナップショットを使用しない geth ノードの場合、2.5 ~ 3 秒の実行時間でブロックを作成できると推定されています。非スナップショット ノードの場合、この数値は状態が大きくなるにつれて悪化し続けます。

この攻撃の実行可能性については、攻撃者がブロック全体を購入するのにかかるコストは約数 ETH です (15M ガスは 100 Gwei で 1.5 ETH に相当します)。

副題

なぜ今公開するのか?

実際、このリスクは常に「公然の秘密」であり、これまでに複数回誤って公開され、コア開発者会議でも何度も言及されてきましたが、詳細には関与していませんでした。

ベルリンのアップグレードが実装され、geth のノードもデフォルトでスナップショット同期を使用しているため、脅威は非常に低くなり、舞台裏で何が起こっているかを完全に開示する時期が来たと私たちは推定しています。

この記事は Martin Holst Swende と Peter Szilagyi によって 2021 年 4 月 23 日に書かれました。 2021-04-26 にイーサリアムベースのプロジェクトと共有され、2021-05-18 に一般公開されます。

元のリンク:https://blog.ethereum.org/2021/05/18/eth_state_problems/

ETH
Odaily公式コミュニティへの参加を歓迎します
購読グループ:
https://t.me/Odaily_News
チャットグループ:
https://t.me/Odaily_GoldenApe
公式アカウント:
https://twitter.com/OdailyChina