ブロックチェーンの一般的な障害要因：コンセンサス、アプリ、インフラのリスク |QuicknodeAutomated USDC Yield in Your AppThe Quicknode Earn API handles the vaults, the rebalancing, and the bridging. Live on 7 chains.
Read the announcement 回答>ブロックチェーンのセキュリティの基礎について学ぶ>ブロックチェーンの一般的な障害モード // Tags
ブロックチェーンの障害ブロックチェーンへの攻撃
要約：ブロックチェーンの障害モードは、3つの異なるレイヤーにまたがっています。すなわち、コンセンサス層の障害（バリデーターのバグ、ネットワークの分断、51%攻撃）、アプリケーション層の障害（スマートコントラクトの脆弱性、オラクルの操作、ガバナンスの悪用）、そしてインフラ層の障害（ノードのクラッシュ、プロバイダーのサービス停止、クラウドのインシデント）です。 各レイヤーには、固有の攻撃ベクトル、リスクプロファイル、および緩和策が存在します。実際の金銭的価値を扱うシステムにおける障害の影響は、従来のソフトウェアよりもはるかに深刻であるため、これらの障害モードを理解することは、耐障害性の高いブロックチェーンアプリケーションを構築するために不可欠です。
わかりやすい説明
ブロックチェーンはしばしば「信頼不要」かつimmutable」であると説明されますが、だからといってそれが絶対無欠であるわけではありません。他の複雑な分散システムと同様、ブロックチェーンもさまざまなレベルで、さまざまな形で障害が発生する可能性があります。開発者にとって重要な点は、ブロックチェーンの障害が「多層的」であるということです。つまり、完全に安全なスマートコントラクトであっても、データを供給するオラクルが改ざんされればユーザーの資金を失う可能性があり、また、完璧に記述されたアプリケーションであっても、基盤となるノードインフラがダウンすれば機能しなくなる可能性があるのです。
これを建物に例えて考えてみてください。基礎（コンセンサス層）にひびが入る可能性があります。配管や配線（アプリケーション層）から水漏れやショートが発生する可能性があります。不動産管理会社（インフラ層）が倒産する可能性があります。それぞれのmode 異なる種類の保護mode 、現実世界におけるレジリエンスを実現するには、これら3つすべてに対して同時に防御策を講じる必要があります。
コンセンサス層の障害
コンセンサス層は、あらゆるブロックチェーンの基盤です。これは、バリデーターがどの取引が有効か、どのブロックをチェーンに追加すべきかについて合意を形成するための仕組みです。コンセンサスが成立しない場合、その影響は極めて深刻であり、チェーンが停止したり、再編成されたり、矛盾するブロックが生成されたりする可能性があります。
バリデーターのバグは、コンセンサス層における最も一般的な障害要因の一つです。ブロックチェーンのクライアントソフトウェアは複雑であり、ブロック生成、認証ロジック、または状態遷移の計算におけるバグにより、バリデーターが無効なブロックを生成したり、コンセンサスラウンド中にクラッシュしたり、正しい状態について他のバリデーターと意見が一致しなくなったりする可能性があります。このリスクは、単一のクライアント実装がネットワークを支配している場合にさらに増大します。 もしバリデーターの70％が同じクライアントを実行しており、そのクライアントにバグがある場合、ネットワークの70％が同時に影響を受けることになります。これが、同じプロトコルの複数の実装を実行する「クライアントの多様性」が、ブロックチェーンのセキュリティにおいて繰り返し取り上げられるテーマとなっている理由です。
SOC 2 タイプ II 認証取得・ISO 27001
ネットワークのパーティションは、通常、インターネットインフラの問題、標的型DDoS攻撃、または地理的なルーティング障害により、バリデーターのグループ同士が相互に通信できなくなった場合に発生します。 パーティションによって十分な数のバリデーターが分断され、いずれの側もコンセンサス閾値（通常はステークされたウェイトの3分の2）に達しなくなった場合、ブロックの生成は停止します。パーティションが部分的なもの（双方とも独立して閾値に達することができる）である場合、チェーンは一時的にフォークし、各パーティションが独自のブロックを生成することになります。パーティションが解消されると、リオーガナイゼーションによってフォークは解消されますが、より短い方のフォークにおけるトランザクションは取り消されます。
51%攻撃（あるいはBFTベースのチェーンにおける34%攻撃）では、過半数のコンセンサス権限を持つ攻撃者が、最近のチェーンの履歴を書き換えることが可能になります。攻撃者は、パブリックチェーンから分岐したプライベートチェーンを作成し、より多くのプルーフ・オブ・ワークやバリデーターの認証を蓄積した上で、それをネットワークにブロードキャストします。攻撃者のチェーンの方が累積的な重みが高いため、ネットワークはそれを正規のチェーンとして採用し、パブリックチェーンの最近のブロックは孤立（オーファン）状態となります。 これにより二重支払いが可能になります。攻撃者はパブリックチェーン上で資金を送金し、確認を待った後、その取引を含まないプライベートチェーンを公開することで、資金を手元に残したまま、事実上商品を受け取ることになります。
アプリケーション層の障害
アプリケーション層には、スマートコントラクト、DeFiプロトコル、オラクル、そして数十億ドル規模のユーザー資金を管理するオンチェーンロジックが含まれます。アプリケーション層での障害は、ブロックチェーンにおける損失の原因として最も頻繁に発生し、最も多額の損害をもたらすものです。
再入攻撃は、スマートコントラクトが自身の状態を更新する前に、別のコントラクトに対して外部呼び出しを行うという脆弱性を悪用するものです。呼び出されたコントラクトは、状態の更新が行われる前に元のコントラクトに「再入」し、同じ関数を再度実行することができ、その結果、資金が流出しかねません。 2016年に発生し、Ethereum につながり、約6,000万ドルの損失をもたらした「DAOハッキング」は、再入攻撃によるものでした。再入の脆弱性は長年にわたり広く知られていますが、「チェック・エフェクト・インタラクション（check-effect-interaction）」のパターンに従っていない新しいスマートコントラクトにおいて、依然としてこの脆弱性が発見され続けています。
整数のオーバーフローおよびアンダーフローの脆弱性は、算術演算の結果がデータ型の範囲外となり、値がラップオーバーした際に発生します。本来は負の数になるはずの減算が、代わりに天文学的に大きな正の数となり、攻撃者が本来受け取る権利のないトークンを不正に取得できてしまう可能性があります。 Solidity 0.8.0 では、オーバーフローが発生した場合にトランザクションをロールバックする組み込みのオーバーフローチェック機能が追加されましたが、古いバージョンでコンパイルされたコントラクトや、チェックされていない算術ブロックを使用しているコントラクトは、依然としてこの脆弱性の影響を受けます。
アクセス制御の不具合は、管理機能に適切な権限チェックが欠如しているために発生し、その結果、権限のないユーザーが契約所有者や特定の役割のみが利用可能な関数を呼び出せる状態になります。これには、保護されていないアップグレード機能（誰でも契約のロジックを置き換えられてしまう）、引き出し機能における所有権チェックの欠如、および不適切に設定されたロールベースのアクセス制御などが含まれます。
オラクル操作は、オンチェーンデータとオフチェーンデータの間のインターフェースを悪用するため、特に悪質な攻撃手法です。貸付、清算、またはデリバティブ取引において価格オラクルに依存しているスマートコントラクトは、操作された価格に基づいて動作するように仕向けられる可能性があります。 フラッシュローン攻撃が最も一般的な手法です。攻撃者は、大量のトークンを借り入れ、それらを使ってオラクルが参照するDEXの価格を操作し、その操作された価格を利用して標的となるプロトコル上で利益を生むアクションをトリガーし、フラッシュローンを返済します。これらすべてが、単一のアトミックトランザクション内で実行されます。標的となるプロトコルのスマートコントラクトは、設計通りに正確に機能していました。失敗の原因は、短期的な価格操作を考慮していなかったオラクルの設計にありました。
ガバナンス攻撃は、DAOやDeFiプロトコルの分散型ガバナンスメカニズムを標的とします。攻撃者は（多くの場合、フラッシュローンを利用して）十分な量のガバナンストークンを取得し、トレジャリーから資金を引き出す悪意のある提案を可決させたり、プロトコルのパラメータを変更して悪用可能な状況を作り出したり、アクセス制御を変更して攻撃者に管理権限を与えたりします。
インフラストラクチャ層の障害
インフラストラクチャ層の障害は、ブロックチェーンそのものを損なうものではありませんが、アプリケーションやユーザーがブロックチェーンとやり取りする機能を妨げます。エンドユーザーや開発者にとって、インフラストラクチャの障害はチェーンレベルの障害と見分けがつかない場合があります。なぜなら、実際の結果は同じ、つまりアプリケーションが動作しなくなるからです。
ノードのクラッシュや同期の失敗により、個々のノードがオフラインになったり、古いデータを配信したりすることがあります。チェーンの先端から数ブロック遅れをとったノードは、古い残高を返したり、最近のトランザクションを見逃したり、最近の状態変化に依存する有効なトランザクションを拒否したりする可能性があります。（フェイルオーバー機能のない）単一のノードに依存しているアプリケーションは、そのノードに障害が発生すると完全に停止してしまいます。
プロバイダーのサービス停止は、そのインフラプロバイダーの全顧客に同時に影響を及ぼします。主要なRPCプロバイダーでサービス停止が発生した場合、そのプロバイダーのエンドポイントを利用しているすべてのアプリケーションがブロックチェーンへのアクセスを失います。これは、本来は分散型であるはずのエコシステムにおける集中化リスクです。つまり、何千ものアプリケーションが同じインフラプロバイダーを共有することで、単一障害点が生じてしまうのです。
クラウドプロバイダーでの障害は、他のクラウドホスト型サービスと同様に、ブロックチェーンインフラにも影響を及ぼします。AWSやGCP、その他のクラウドプロバイダーでリージョン単位の障害が発生すると、そのリージョンで稼働しているブロックチェーンノードはすべてオフラインになります。ブロックチェーンノードの過半数が、ごく少数のクラウドプロバイダー上で稼働しているため、クラウドの障害はネットワークの状態やアプリケーションの可用性に甚大な影響を及ぼす可能性があります。
DNS やネットワークの障害が発生すると、エンドポイントが正常に機能している場合でも、アプリケーションが RPC エンドポイントにアクセスできなくなる可能性があります。DNS ハイジャック、BGP ルーティングの問題、TLS 証明書の問題などは、いずれもアプリケーションとブロックチェーンインフラストラクチャ間の接続を妨げる要因となり得ます。
緩和策
ブロックチェーンの障害モードに対する防御には、これら3つのレベルすべてに対応する多層的なアプローチが必要となる。
コンセンサス層において、クライアントの多様性は最も影響力の大きい防御策です。複数のクライアント実装を稼働させることで、あるクライアントのバグがネットワーク全体に影響を及ぼすことを防げます。ステークの分散も重要です。広範で分散化されたバリデーターセットを促進することで、協調的な障害や51%攻撃のリスクを低減できます。
アプリケーション層では、セキュリティ監査、形式検証、およびバグ報奨金プログラムが主要な防御策となります。
スマートコントラクトは、展開前に複数の独立した企業による監査を受けるべきです。形式検証により、コントラクトのコードが仕様と一致していることが数学的に証明され、手動によるレビューでは見落とされがちなバグを検出できます。バグ報奨金制度は、ホワイトハットハッカーが脆弱性を発見し、責任を持って開示するよう促します。タイムロック機能付きのアップグレードにより、提案された変更が有効になる前にコミュニティが検討する時間が確保され、悪意のあるアップグレードやバグを含むアップグレードが即座に展開されるのを防ぎます。管理機能に対するマルチシグ要件により、単一の鍵が侵害されたとしても、特権操作を実行できないようにします。
インフラストラクチャ層において、プロバイダー、リージョン、クラウドプラットフォームをまたぐ冗長性は、レジリエンスの基盤となります。アプリケーションは、単一のRPCプロバイダー、単一のデータセンター、あるいは単一のクラウドプロバイダーに依存してはなりません。サーキットブレーカーは、障害が発生したコンポーネントが上流のシステムをダウンさせる前に自動的に接続を切断することで、連鎖的な障害を防ぎます。グレースフル・デグラデーションの設計により、一部のインフラストラクチャコンポーネントが利用できない場合でも、アプリケーションは（残高の表示など）中核的な機能を引き続き提供できるようになります。
Quicknode どのように耐障害性をQuicknode
Quicknodeインフラストラクチャは、14以上のリージョンおよび5以上のクラウド・ベアメタルプロバイダーへの地理的分散、利用可能な範囲でのクライアントの多様化、正常でないノードからのリクエストを迂回させる自動フェイルオーバー、そして専任のブロックチェーン運用チームによる24時間365日の監視を通じて、インフラストラクチャ層の障害を軽減するように設計されています。
Quicknode Streams 、配信保証、ファイナリティ順の処理、およびリオーガナイゼーションの自動処理を通じて、データパイプラインの耐障害性をStreams 。リオーガナイゼーションなどのコンセンサス層のイベントが発生した場合、Streams 影響を受けたデータを自動的にStreams 修正します。アプリケーション層のモニタリングに関しては、Streams 、開発者は特定のコントラクトイベント、異常なトランザクションパターン、およびエクスプロイトの進行を示唆する可能性のある状態の変化を監視Streams 。
最も厳しい信頼性要件を課されるチーム向けに、Quicknode専用Clusters 、共有トラフィックとは独立した、稼働時間がSLAで保証された隔離されたインフラストラクチャClusters 。これにより、他の顧客のトラフィック急増によってパフォーマンスが低下する「ノイジーネイバー」リスクを排除し、ミッションクリティカルなブロックチェーンアプリケーションに必要な隔離環境を実現します。
ブロックチェーンの障害で最も一般的なものは何ですか？
上記で取り上げた障害の発生形態は、その発生源となるレイヤーごとに分類することができ、それによって各障害に対する防御責任の所在も明らかになります。以下の表には、最も一般的な障害、その代表的な例、および対策の担当部署をまとめています。
レイヤー | よくある不具合 | 例 | 緩和策の現場 |
|---|
コンセンサス | 51%攻撃または再編成 | 多数派が近現代史を書き換える | プロトコルとバリデータセット |
コンセンサス | ネットワークの分割または停止 | バリデーターが閾値に達することができない | プロトコルとクライアントの多様性 |
用途 | 再入可能性またはオラクル操作 | フラッシュローンが融資プールを枯渇させる | スマートコントラクトと監査 |
用途 | アクセス制御またはガバナンスの脆弱性 | 保護されていない管理機能 | スマートコントラクトとマルチシグ |
インフラ | ノードのクラッシュまたはプロバイダーのサービス停止 | endpoint 古いデータをendpoint | 冗長化されたインフラ |
損失が生じる前に、ブロックチェーンの障害をどのように検知すればよいでしょうか？
検知の有無が、インシデントを封じ込められるか、あるいは壊滅的な事態に発展するかの分かれ目となります。ブロックチェーンインフラを継続的に監視することで、ノードの遅延、エラーの急増、同期のずれなどをリアルタイムで把握できます。さらに、広範な可観測性により、これらのシグナルをアプリケーションの挙動と関連付けることで、ユーザーが影響を感じる前に、エクスプロイトやサービス停止の兆候を察知することが可能になります。
「チェーン・ハルト」と「チェーン・リオーガナイゼーション」の違いは何ですか？
これら2つのコンセンサス層の障害は、しばしば混同されがちです。チェーンの停止は、バリデーターがコンセンサスの閾値に達することができないため、ブロックの生成が完全に停止し、新しいトランザクションが一切確定しなくなります。一方、ブロックチェーンの再編成では、ブロックの生成は継続されますが、最近承認されたブロックが競合するチェーンのブロックに置き換えられるため、確定したように見えたトランザクションが取り消される可能性があります。
インフラの冗長化は、どのようにして障害リスクを低減するのでしょうか？
よくある質問
ブロックチェーンの障害にはどのような3つの層があるのでしょうか？
障害は、コンセンサス層（バリデーターのバグ、パーティション、51%攻撃）、アプリケーション層（スマートコントラクトのバグ、オラクルの改ざん、ガバナンスの悪用）、あるいはインフラ層（ノードのクラッシュ、プロバイダーやクラウドのサービス停止）で発生します。耐障害性の高いシステムは、これら3つすべてに対処します。
ブロックチェーンによる損失の最も一般的な原因は何ですか？
アプリケーション層の障害、とりわけスマートコントラクトの脆弱性やオラクルの改ざんは、最も頻繁に発生し、最も多大な損害をもたらすものです。多くの場合、基盤となるブロックチェーンは設計通りに正常に動作しているにもかかわらず、欠陥のあるコントラクトやオラクルのロジックが悪用されるのです。
RPCプロバイダーの1つがダウンしただけで、私のアプリが利用できなくなることはありますか？
はい。アプリケーションが1つのプロバイダー、1つのデータセンター、または1つのクラウドリージョンに依存している場合、そこで障害が発生するとサービスが停止してしまいます。冗長化されたプロバイダーやリージョンにトラフィックを分散させ、自動フェイルオーバーを設定することで、この単一障害点を排除できます。
51%攻撃はネットワークパーティションと同じものですか？
いいえ。51%攻撃とは、コンセンサス権限の過半数が意図的に履歴を書き換えようとする行為であるのに対し、ネットワークの分断とは、バリデーター間の通信が偶発的に途絶える現象です。どちらもリオーガナイゼーションを引き起こす可能性がありますが、その原因や防御策は異なります。
オラクル攻撃からどのように防御すればよいでしょうか？
複数の情報源や時間帯にわたる価格を集約するオラクルを使用し、単一のDEXのスポット価格に依存することを避け、妥当性チェックやサーキットブレーカーを導入してください。これらの対策により、価格フィードを一時的に歪めるフラッシュローン攻撃の被害を軽減できます。
参考資料
