|
北京時間2月20日から22日まで、Findoraが主催する2020年スタンフォードブロックチェーンカンファレンスがスタンフォード大学で開催されました。会議では、ブロックチェーンシステムにおけるセキュリティエンジニアリングとリスク管理方法に焦点が当てられ、暗号化技術、分散プロトコル、形式手法、実証分析の応用を通じてブロックチェーンシステムのセキュリティを向上させる方法が検討されました。
会議の2日目には、イーサリアムの共同創設者であるヴィタリック・ブテリン氏が「51%攻撃を超えて」と題した講演を行った。会議中、彼はまず、最も一般的なロールバック攻撃、検閲攻撃、ライトクライアント攻撃、阻止攻撃、そして最も深刻なスポーンキャンプ攻撃など、さまざまな種類の 51% 攻撃について言及しました。彼は、プルーフ・オブ・ワーク（PoW）型暗号通貨はこうした攻撃に対して脆弱である一方、プルーフ・オブ・ステーク（PoS）型暗号通貨は、99%フォールトトレラント・コンセンサスや適時性検出器（TD）などの技術を通じて攻撃チェーンや検閲攻撃を検出できるため、51%攻撃による脅威を排除できると考えています。 （写真：2020年スタンフォードブロックチェーンカンファレンスでのヴィタリック氏のスピーチ）
ヴィタリック氏のスピーチは次のとおりです。
51% 攻撃では何ができるでしょうか? 51% 攻撃にはさまざまな種類があり、さまざまなアプリケーションに対してさまざまなアクションを実行し、さまざまな結果と影響を生み出す可能性があります。皆さんがよくご存知の 51% 攻撃の 1 つのタイプは、ブロックのロールバックです。取引を行い、取引所に送金し、それらのコインを別のコインと交換し、それらのコインを引き出し、51% 攻撃を実行して入金取引を元に戻します...
これは、私たちが過去 10 年間議論してきた 51% 攻撃の主な種類であり、最もよく考えられているものです。
1. その他の種類の51%攻撃
1.1 トランザクション検閲攻撃
実際、トランザクション検閲も 51% 攻撃の別の形です。レイヤー 2 プロトコルと DeFi はどちらも最近のメガトレンドであるため、トランザクションの検閲は特に危険になります。多くのレイヤー 2 プロトコル環境 (プラズマ、チャネル、一般化状態チャネル、ライトニング ネットワーク、楽観的ロールアップ、インタラクティブ計算、TruBit など) では、検閲は盗難を意味します。
つまり、チャレンジ取引を検閲できれば、人々からお金を盗むことができるのです。これは zk Rollup には当てはまりませんが、この攻撃は現在検討されているプロトコルの大部分に当てはまります。検閲は、市場を操作して価値を引き出すためのツールであるため、DeFi の文脈では特に危険です。
Uniswap に関係するすべての Ethereum ブロックチェーン トランザクションを検閲して 1 日待つことができれば、Ether の価格が少し変動し、この攻撃から大量の裁定取引価値を引き出すことができる可能性があります。
検閲は危険であると言えますが、DeFi プロトコルやレイヤー 2 プロトコルでは、トランザクションの検閲は盗難に等しいとも考えられます。
1.2 ライトクライアント攻撃
多くの人が軽量クライアントを実行していますが、軽量クライアントを実行している場合、51% 攻撃により、それらの軽量クライアントが完全に無効なトランザクションを含むブロックを含むチェーンを受け入れる可能性があります。不正な署名、不正なトランザクション、不正な署名（あるアカウントから資金を盗み、他のアカウントに転送する）により、ブロックがネットワークによって利用可能として受け入れられる可能性があります。
1.3 データ利用不可攻撃
データ可用性の問題に詳しい人はいますか?まあ、全員ではないですが、多くの人がそれについて知るようになりました。ここでの考え方は、ブロック ヘッダーを公開するチェーンを作成できるということです。ライト クライアントはチェーンを見ることはできますが、ブロック本体の一部またはすべてのデータを公開することはできません。これが良くない理由は、データが公開されていない場合、そのデータが正しいかどうかは不明であり、そのデータが正しい可能性が高いことを他の人に証明する証拠を生成する方法がないため、人々が将来の取引を作成するために使用する可能性のある情報を拒否することになるからです。つまり、利用できないブロックも非常に危険です。
1.4 攻撃を阻止する
落胆攻撃とは、他の参加者を悪意を持って妨害し、収入を失わせて共謀させたり、辞めるよう強制することを指す用語です。計算能力の 1/3 以上を使用した利己的なマイニングがその一例です。そうは言っても、51% 攻撃は非常に強力な阻止攻撃でもあります。
1.5 ブロックチェーンの不変性について
したがって、51% 攻撃は非常に強力であり、このタイプの攻撃はブロックチェーンの不変性に対する脅威となります。
これを覚えている人はいますか?ある取引所から多額の金が盗まれ、取引所は金を取り戻すためにビットコインブロックチェーン上で1日限りの逆転を求めることを検討している。もしそのようなことが可能であれば、ブロックチェーン内のものが復元され、ブロックチェーンとしての重要な特性が失われることになり、恐ろしいです。
また、51% 攻撃は民主的ではなく、金権政治であるため、民主的な方法としては役に立ちません。
2. 現実に発生した 51% 攻撃と最悪の 51% 攻撃のシナリオ 現実でも、51% 攻撃は実行される可能性があります。これは2015年の香港ビットコインスケーリングカンファレンスの写真です。この写真では、ビットコインの計算能力の 90% をコントロールしている人々が、まるで自分たちにその力があるかのようにポーズをとって一緒に座っています（笑）。
51% 攻撃が達成可能です。たとえば、ETC、Bitcoin Gold などはいずれも 51% 攻撃を経験しています。 1、2 回は見逃したと思いますが、これらの攻撃はすでに発生しています。
スポーンキャンプ攻撃
現実には、これまでに見られた 51% 攻撃は最悪のものではありません。スポーンキャンプ攻撃は、このタイプの攻撃にとって最悪の悪夢のシナリオです。基本的に、チェーンを攻撃するのに十分なハードウェアを取得し、チェーンが回復するのを待ってから、ハードウェアをまだ保持しているため再度攻撃する必要があります。最終的に、コミュニティはこれにうんざりし、Proof of Work (PoW) アルゴリズムに切り替えるでしょう。短期間で ASIC を構築する方法はないため、攻撃を続けるには大量の CPU と GPU の計算能力をレンタルするしかありません。そして、Proof of Stake (PoS) に切り替えるか、完全に中央集権化されない限り、チェーンは消滅します。
3. Proof of Stake (PoS) アルゴリズムはこのサイクルを打破できますか?
これは私が 2016 年に書いたブログ投稿で、Proof of Stake (PoS) の背後にある哲学が何であるか、なぜそれが存在すると期待されるべきか、そしてそれがなぜ理にかなっているかを説明しようとしました。プルーフ・オブ・ステーク（PoS）には非対称性があり、これはプルーフ・オブ・ワーク（PoW）とは異なります。プルーフ・オブ・ワーク（PoW）では報酬のみが得られるため、攻撃に参加した場合や攻撃に参加しなかった場合の罰はブロック報酬のみとなります。プルーフ・オブ・ステーク（PoS）システムでは、攻撃が検出され、罰金が科せられる預金額よりも失う預金額の方がはるかに大きくなります。
これらは、Casper CBC や、セキュリティ デポジットとスラッシュに基づくその他のさまざまなプルーフ オブ ステーク (PoS) アルゴリズムに組み込まれています。理論的には、この設計の目標は 51% 攻撃を非常に高価にすることです。基本的に、PoS チェーンを攻撃したい場合は、大量のコインを購入し、システム内のコインの 50% 以上を制御する必要があります。そして、攻撃が発覚すると罰金が科せられ、再度攻撃を仕掛けるにはさらに多くのコインを購入する必要があります。そして、購入し続けると、コインの価格が上昇し、最終的には破産することになります。したがって、この観点から、攻撃者が PoW をターゲットにするのではなく、チェーンを PoS に移行させることが私たちの目標です。
他の種類の攻撃についてはどうでしょうか?
さて、最初の質問である、PoS は他の種類の攻撃をどのように解決するかについて議論しましょう。これまでは、最終的な反転に焦点を当ててきました。これは、ビザンチンフォールトトレラントコンセンサス理論では非常に一般的です。基本的な考え方は、当事者の 2/3 が一方側にいて、1/3 がもう一方側にいる場合、バリデーターの 1/3 が 2 つの矛盾したメッセージを送信しているはずであり、それを検出してペナルティを課すことができるというものです。ただし、これは反転攻撃についてです。
他の種類の攻撃についてはどうでしょうか?無効なデータ、利用できないデータ、検閲、悪意のある破壊?
これを一つずつ取り上げていきましょう。データの有効性については気にせず、データの可用性が保証され、ブロックがブロックチェーンの一部である場合、そのブロック内のすべてのデータがネットワーク内のノードによってダウンロードできるという保証があることに注目します。検閲耐性があり、ブロックを公開すると、最終的にはそれが組み込まれるため、この 2 つのことから有効性が得られます。その理由は、インタラクティブな計算、Rollup、およびこれらの既存のプロトコルです。基本的に、ロールアップを使用すると、すべてのデータをオンチェーンで公開し、チェーンがその可用性を保証し、不正の証明が得られ、計算が無効な場合は検閲不可能な不正の証明を公開してオンチェーンで処理できることが保証されます。したがって、レイヤー 1 とレイヤー 2 での不正証明によってこの問題を解決できるため、データの有効性はそれほど重要ではありません。
他の人のブロックを検閲できない場合、それがブロックチェーンに含まれるのを防ぐことはできません。したがって、インセンティブに対する罰則が効果的に管理されている限り、悪意のある被害（Griefing）は大きな問題にはなりません。
これを要約すると、データ可用性攻撃と検閲攻撃の 2 つになります。
無効なデータと利用できないデータ
これは私がMusalbasらと共著した論文です。 2017年に、ブロックチェーン クライアントが実際にすべてのデータをダウンロードすることなくブロックチェーン データの可用性を検証できるスキームについて説明しました。
このスキームの単純な仮のバージョンは次のようになります。ブロックが利用可能かどうかを確認する最も愚かな方法は、ブロック全体をダウンロードすることです。しかし、ここでは、スケーラブルで、おそらくシャード化されたブロックチェーンを想定しており、2 MB/秒を超えるデータがチェーンにアップロードされ、クライアントはそれをすべてダウンロードすることはできません。データの可用性を確認したいクライアントの場合、ランダム サンプリング テストを実行するだけで済みます。 30 フラグメント、40 フラグメント、80 フラグメントなどのデータ フラグメントをランダムに選択します。位置をランダムに選択し、これらの位置のマークル証明を要求します。受け入れたすべてのポジションから有効な応答を受け取った場合、ブロックを受け入れ、有効とみなします。
この方式を使用してブロックを受け入れると、そのブロックが有効である可能性が高くなります。データの 50% 未満しか利用できない場合、たとえば、左側のデータはすべて利用可能で、右側のデータもすべて利用できる場合、少なくとも 1 つのチェックは失敗する可能性が高くなります。
このスキームにより、攻撃者は少数の特定のクライアントを欺くことができます。ただし、攻撃者が十分な数のクライアントを騙してリーフ データの半分をダウンロードさせると、それらのクライアントはそこからデータを再構築できるようになります。
これは、ブロックが完全に利用可能であることを証明するものではなく、一部が欠落している可能性もありますが、少なくとも半分のブロックが利用可能であることは証明します。データの 50% からブロック全体を復元できる技術があれば素晴らしいでしょう。
消失訂正符号
ここで消失訂正符号が登場します。データを取得します。これは多項式評価であるとしましょう。同じ多項式を複数のポイントで評価すると、データの 50% があればすべてのデータを回復できます。このスキームを導入すると、ブロックが有用であること、また、個人が 20 ～ 200 KB のデータをダウンロードする場合でも、ブロックが非常に大きなサイズでも使用可能であることを確認できます。
これが最初の部分です。これには、Ethereum 2.0 シャーディング ソリューションの一部であるデータ可用性攻撃が含まれ、これにより、少なくともシャードされたブロックチェーンに同じ可用性保証を与えることができます。
正しさを証明する
では、ルートがこの消去コードのルートであることをどうやって証明するのでしょうか?そこにジャンクデータが詰まっていないことをどうやって証明するのでしょうか?この 2D のような不正証明を使用できます。コードを間違えると、誰かが短い不正証明を作成し、それをネットワークにブロードキャストして、ネットワークがブロックを拒否できるようになります。この 2D スキームは 2017 年に開始されました。最近、マークル ツリーのエンコードに関するものがいくつか登場しました。マークル ツリーでは、各レベルをマークル ツリーにエンコードしますが、これには優れた特性があります。 STARK や SNARK を使用してマークル根の計算が正しいことを証明するなど、不正証明に依存しない方法もあります。また、多項式コミットメントを使用する可能性もあります。データを取得し、それを多項式の評価として解釈し、多項式を計算し、多数のポイントで多項式コミットメントの大量のオープニングを実行します。データ可用性チェックでは、80 個のオープニングではなく 80 個の位置が要求されます。または、巧みな代数を使用して何らかのマルチオープニングを取得すれば、さらに効率を高めることができます。
これらのスキームの利点は、不正証明に依存しないことです。そのため、ブロック データを検証するために使用されるスキームはすでに公開されており、追加のレイテンシの仮定が組み込まれていません。
シャーディング: 委員会を超えて
現在存在するシャード ブロックチェーンは、通常、委員会に依存しており、多数のノードがあり、その中からランダムにいくつかを抽出し、その過半数または超多数の承認を得てブロックを承認しないと、ネットワークがそのブロックを有効なものとして受け入れないという考え方です。
問題は、委員会ベースのアプローチはどれも、一定の基準を超える悪質な行為者による精査の対象となることです。 51% 攻撃に対する耐性について話しているのであれば、多数派が攻撃を開始したとしても、少数派がシステム自体を操作し続けることができるシステムについて話していることになります。
固定しきい値シャーディングスキームは実際には役に立ちません。したがって、ここでの解決策は、プロトコルが委員会に依存するのではなく、一連のデータ可用性チェックにもっと全面的に依存する必要があるということです。
レビューについて
あなたたちの中で検閲を止めたい人はいますか?はい、人が多いので現状はあまり良くありません。これは、Ethereum の形式検証に関する研究を行った nrryuya による記事です。彼は、イーサリアム2.0の現在の設計では、大多数の人がブロックを確認できるようにする戦略があると述べた記事を書きました。このレビューは単一ブロックの遅延と区別がつかず、誰が責任を負うのか判断するのが困難です。
ここでの攻撃はかなり怪しく、攻撃者は一部のバリデータを侵害し、別のブロックに投票させ、他のバリデータを使用して、実際に検閲されるコンテンツを含む自分のブロックに投票させます...しかし、彼ら自身は 51% を超えるのに十分な投票を持っていないため、彼らが検閲しようとしているコンテンツは実際には含まれません。これは複数のレベルでの間接的な影響です。 Ethereum 1.0 と Ethereum 2.0 の両方で、51% 攻撃を実行する悪意のある当事者が検閲を行う可能性があり、検閲が十分に厳しい場合は、措置を講じる必要があるかどうかを判断することが困難になる可能性があります。
アンクルブロックを含める
これは現時点で実行できる最も基本的なことです。アンクル ブロックを含めることです。ここでの考え方は、Ethereum 1.0 ではブロックチェーンの一部ではなかったブロックを後から含めることができたが、新しいアプローチでは、アンクル ブロック内のトランザクションも処理されるというプロトコル ルールを追加するというものです。
つまり、アンクルブロックも含まれるこのようなブロックチェーンが存在します。
アイデア: 適時性検出器 (TD)
少なくともオンラインのクライアント、つまりネットワーク上で何かをダウンロードしたり、他のクライアントと定期的に通信したりできるクライアントが存在できたらどうなるか想像してみてください。ブロックが時間どおりに到着したかどうかを確認させます。
ブロックが時間どおりに到着し、そのブロックが長期間チェーンによって受け入れられていないことがわかった場合、そのブロックは自動的に失格になります。ブロックが時間どおりに到着しない場合は、それを使用して 51% ロールバック攻撃を実行できます。
その考え方は、クライアントがブロックが到着予定時刻に到着したかどうかをローカルで検出し、それを情報として使用してどのチェーンに従うかを決定するというものです。
オフライン ノードも存在する可能性があるため、すべてのノードがプロトコルに従うことはできません。 51% 攻撃が進行中でない限り、攻撃が発生していない場合は、勝利したブロックチェーンは正常なチェーンになります。攻撃が発生していてオフラインの場合は、何が起こっているかを確認するためにソーシャル レイヤーをチェックする必要がありますが、そうする参加者は少数であり、他の参加者はかなり明確なコンセンサスを持っています。
問題: エッジ攻撃
ブロックを生成し、それが時間どおりに到着した場合、そのブロックの定義が何であれ、一部のノードではブロックが異なる時間に到着したと認識されます。したがって、ノードは、ブロックが長期間検閲されているかどうか、ブロックが時間どおりに公開されたかどうかについて意見が一致しない可能性があり、これらの時間パラメータについても意見が一致しない可能性があります。
攻撃者はこれを悪用して、攻撃が発生したかどうかについて他者の間で長期的な意見の相違を引き起こし、多くのガバナンスの問題を引き起こす可能性があります。
そのため、より優れた適時性検出器（TD）が必要になります。
タイムリーさ検出器 (TD) の改善
ビザンチン将軍問題、つまりレスリー・ランポートが 1982 年に書いた論文に戻りましょう。論文には、人々があまり話題にしていないが、おそらくもっと話題にするべきアルゴリズムが含まれていることが判明しました。この文章を偽造不可能な書面情報（デジタル署名を参照）で抽象的に隠します。ランバート氏は、最大 99% の誤った攻撃者を許容できるコンセンサス アルゴリズム (つまり、99% のフォールト トレラント コンセンサス) を持っていると主張しています。
このアルゴリズムは機能し、その利点は、コンセンサスを行うマイナーとバリデーターの間だけでなく、マイナーとクライアントの間、クライアントと他のクライアントの間でも同期の仮定がある限り機能することです。誰がオンラインであるべきかについてより強い仮定があり、その仮定を使用してより高いフォールト トレランスを実現しますが、これは私たち自身が望まない非常に危険な仮定です。
シングルプローバーバージョンについて説明します。ここで、1 人の証明者が正直であり、合計で n 人の証明者がいると仮定すると、正直である証明者は 1/n 人だけ必要です。
ここでの考え方は、たとえばブロックが公開されると、クライアントと認証者は、ブロックが時間どおりであるとみなすために、そのブロックを受信する必要がある期限を持つというものです。クライアントにとって期限は t であり、証明者にとって期限は t+δ です。ここで、提案者はブロック b を公開しようとしています。提案者が少し悪意を持って限界攻撃を試み、ノード 1 が期限前にそれを確認し、ノード 2 も期限前にそれを確認します。証明者はブロックを送信しますが、ネットワークの同期性の仮定により、ブロックを受け入れるノードが 1 つある場合、ブロックは証明者に送信できるため、証明者は期限前にブロックを受け入れることが保証されます。たとえ 1 人のクライアントでもブロックがタイムリーであると判断された場合、認証者は期限前にそのブロックを確認したことが保証されるため、認証者は独自の署名を追加します。また、ネットワークの同期により、別のクライアントは、署名されたブロックの期限前にそのブロックが署名を追加したことを確認できます。
これを複数の証明者に拡張する方法は簡単です。証明者は多数あり、クライアントは t+δ*k になります。この研究については eth.research に記事を書いていますので、詳細を知りたい場合はぜひご覧ください。一般的な考え方としては、複数の攻撃者がいて、それぞれが期限を少しずつ遅らせることができるため、1 人の攻撃者がブロックを受信すると、ネットワークの遅延がデルタ パラメータを下回っている限り、ブロックの適時性がネットワークの残りの部分に伝播されるというものです。
興味深い事実
このような適時性検出器があれば、すべての適時ブロックを自己宣言した時間順に処理するだけです。唯一の問題は、非常に長いブロック時間を必要とすることです。これは、バリデーターの入金、出金、およびスラッシュを処理する場合には興味深いプロトコルかもしれませんが、ブロックチェーンを実行するための最適なプロトコルではありません。
もっと正確に言えば、適時性検出器を使用して、検閲攻撃だけでなく攻撃チェーンも検出できます。
4. 結論 検閲防止技術は、ネットワークとクライアント間の同期を前提としているため、他の技術ほど完璧ではありません。この期間は好きな時間に設定できますが、許容できる検閲のレベルに関係します。オンライン ノードのセット間の一貫性を保証でき、攻撃が発生した場合には、チェーンが攻撃チェーンであるかどうかなど、その他すべてについて合意に達することができます。これを回復方法に関する部分的な社会的合意の始まりとして利用することができ、これにより、攻撃者が誰であるかをより確実に判断できるため、攻撃者に対してより厳しい罰則を割り当てることができます。
一般的に言えば、攻撃者が利用できないチェーンを公開した場合、データ可用性チェックによってそれが捕捉され、無効なブロックを公開した場合は不正証明によってそれが捕捉され、ブロックを長期間検閲した場合、そのチェーンはネットワークによって自動的に無視されます。中程度の時間ブロックを検閲する場合は、適時性検出器を使用してそれをきれいに処理できます。また、攻撃者が委員会に参加しないようにしたり、委員会を破壊したりしようとしている場合は、委員会を使用しないだけです。
そうですね、私たちは基本的に 51% 攻撃に対する恐怖を大幅に軽減し、それを無視するか、攻撃から回復できるようにする一連のツールを持っています。皆様ありがとうございました。
| 
