この記事の由来はMedium翻訳者 | モニ

翻訳者 | モニ

編集者 | 陸暁明

編集者 | 陸暁明

編集者注: この記事は、イリノイ大学アーバナシャンペーン校 (UIUC) 傘下の分散システム研究所 (Decentralized Systems Lab) の研究チームによって書かれた「リソース枯渇の脆弱性」に関する研究レポートです。チームのメンバー: Sanket Kanjalkar を含む) 、Yunqi Li、Yuguang Chen、Joseph Kuo、コンサルタントのAndrew Miller。これらの脆弱性はプルーフ・オブ・ステークに基づいて合計26以上の仮想通貨に影響を与えていると報告されており、サイバー攻撃者は非常に小さな「ステーク」（賭け金）を使用するだけで、対応するソフトウェアを実行しているネットワークノードをクラッシュさせることができます。研究チームは、影響を受ける可能性のある仮想通貨の開発者にこの件を知らせることを目的として、2018年10月に調査の公開を開始しており、現在そのほとんどは緩和策を導入している。

プルーフ・オブ・ステーク (PoS) 暗号通貨、特にビットコインに似た PoSv3 (プルーフ・オブ・ステーク バージョン 3: プルーフ・オブ・ステーク バージョン 3) 暗号通貨は、基本的に UTXO (Unspent Transaction Output: 未使用トランザクション出力) モデルを使用し、最長チェーンコンセンサスルール。いわゆる UTXO は、ビットコイン アドレスに関連付けられたビットコイン量のコレクションを指します。ビットコイン システムにはアカウントの概念がないため、ネットワーク全体のブロックチェーンには未消費のトランザクション出力のみが存在します。データと実行可能コードの構造。 UTXO の基本単位は「サトシ」で、「サトシ」はビットコインの最小測定単位であり、1 ビットコインは 10^8 サトシに相当します。一度作成されたUTXOは分割することができず、トランザクションの投入としてのみ使用することができ、使用後は新たなUTXOが生成され、繰り返し通貨の価値移転が実現されます。したがって、ビットコインウォレットに表示されるアカウント残高は、実際には、未消費のトランザクション出力の集計計算の結果です。

「プルーフ・オブ・ワーク」と比較して、プルーフ・オブ・ステークには、エネルギー消費量が少なく環境に影響を与えない、51% 攻撃に対するセキュリティが向上するなど、潜在的な利点がいくつかあります。実際、今日市場に出回っている多くの暗号通貨は、ビットコインのコードベース (またはビットコインの派生) をフォークしたもので、プルーフ・オブ・ステークのコンセンサスメカニズムが移植されていますが、一部の設計コンセプトは安全にコピーされておらず、その結果、いくつかの新しいバグが修正されました。元のコードベースにはなかったものです。

また、この記事の残りの部分では、脆弱性と攻撃について詳しく説明し、それらがどのような微妙な影響を与える可能性があるかについて説明します。後になって考えると、脆弱性自体は複雑ではないように見えますが、完全に対処するのは難しく、現在実施されている緩和策ではブロックチェーンのフォークを引き起こすリスクがあります (詳細は後ほど)。

副題

「False Stake」脆弱性の詳細に入る前に、Proof-of-Stake がどのように機能するかを説明しましょう。

副題

プルーフ・オブ・ステーク・マイニング:

プルーフ・オブ・ワーク・マイニングと同様に、プルーフ・オブ・ステーク・マイニングには、ブロック・ヘッダーのハッシュ値と難易度目標が含まれます (注: 難易度目標とは、ネットワーク全体の計算能力でブロックをおよそ生成できるようにするために必要な難易度の値です) 10分ごと）。プルーフ・オブ・ステークの大まかな目標は、各利害関係者が、管理している暗号通貨の量に比例して次のブロックをマイニングするチャンスを確実に持つことです。これを達成するために、プルーフ・オブ・ステークのコンセンサスメカニズムでは、ハッシュ値はブロックヘッダーだけでなく、ステークホルダーによってブロックに挿入された特別な「コインステーク」トランザクションに含まれるコインの数にも依存します。

• 「コインステーク」は、権利と利益の証明の創始者であるサニー・キングによって特別に設計された特別なトランザクションです。ビットコインの創始者「サトシ・ナカモト」のコインベースの設計に基づいています。入力と出力にはいくつかの厳しい制限があります。

• Coinbase 構造では、入力数量が 1 である必要があり、入力 Prevout フィールド (前のトランザクションの出力を指定する) が空である必要があり、出力数量が 1 以上である必要があります。

Coinstake 構造では、入力の数が 1 以上である必要があり、最初の入力の Prevout フィールドを空にすることはできません。つまり、カーネルが存在する必要があり、出力の数が 2 以上である必要があります。最初の出力は空でなければなりません。

さらに、これら 2 つの特別なトランザクションには、ブロックチェーン内の保存場所に関する特別な要件もあります。サトシ ナカモトは、各ブロックの最初のトランザクションは Coinbase に配置する必要があると規定しています。これは、Coinbase がブロック内の他の場所に存在できないことも意味します。サニー・キングは明らかにこのルールを破りたくなかったが、コインステークを「プルーフ・オブ・ステーク」ブロックの2番目のトランザクションに配置する必要があるというルールを追加した。これは、コインステークがブロックチェーン上の他の場所に出現できないことも意味する。言い換えれば、2 番目のトランザクションが Coinstake である限り、このブロックはプルーフ オブ ステーク ブロックとして扱われる必要があります。

プルーフ・オブ・ステーク マイニングには多くの詳細が含まれるため、ここでは詳しく説明しませんが、当面は次の 2 つの側面に焦点を当てます。

2. Coinstake トランザクションで消費された UTXO (未消費トランザクション出力)。

副題

ブロック検証リソースの確保における Proof-of-Work の役割

誰もが知っているように、プルーフ・オブ・ワークはビットコインのコンセンサスにおいて重要な役割を果たしてきましたが、ディスク、帯域幅、メモリ、CPUに関連する一連の問題もあり、ビットコインの人気はあまり高くありませんでした。分散型暗号通貨ネットワークでは、トランザクションの前提は実際には信頼に基づいていないため、リソース枯渇攻撃 (リソース枯渇攻撃) を防ぐために、ビットコイン ノードは最初に、より多くのリソース (RAM にブロックを保存するなど) またはディスクに送信します。作業証明メカニズムを使用してすべてのトランザクション受信ブロックをチェックします。ただし、プルーフ・オブ・ステークを使用してブロックをチェックすることはプルーフ・オブ・ワークよりもはるかに複雑であり、このコンセンサスメカニズムは状況に依存する（または状況に依存する）ため、多くのプルーフ・オブ・ステークは実装時に検証することが実際には非常に困難であることが判明しました。 「ケチ」。

リソース枯渇の脆弱性がどのように引き起こされるかを理解する前に、まずブロックが検証される前にどのように保存されるかを詳しく説明する必要があります。実際、ブロックチェーン ノードは、現時点で最長のチェーンを追跡するだけでなく、フォーク チェーンのツリー全体も追跡する必要があります。フォーク チェーンのいずれかが最長のチェーンになる可能性があり、タイム ゾーンを切り替えるためにブロックチェーン ノードを「再編成」する必要があるからです。準備されていないアップグレード、二重支出攻撃 (イーサリアム クラシックに対する 51% 攻撃など)、または一時的なネットワーク分割の場合など、最長のチェーンへの「再編成」が可能です。

この場合、これらの「オフメインチェーン」上のブロックを検証することは非常に困難です。ブロックを完全に検証したい場合は、前のブロックの現時点でのすべての未使用のトランザクション出力 (UTXO) のコレクションを取得する必要があります。ビットコインは、未使用のトランザクション出力のセットを最良のチェーンの現在の先端に保持しますが、フォークされたブロックチェーン上のブロックはビットコインのアプローチに従っていない可能性があります。フォーク上のブロックを完全に検証するには、主に 2 つの方法があります。

1. 現在のビュー (未消費のトランザクション出力のセット) をフォーク前の時点に「ロールバック」します。または、

2. すべての初期ブロックの未使用のトランザクション データ コレクションのコピーを保存します。

ビットコインのコードベースは 2 番目のアプローチをサポートしておらず、たとえサポートできたとしても、追加のストレージ コストが追加されます (ビットコイン ノードのパフォーマンスは、不必要なデータの継続的な「プルーン」に依存しています)。 1 つ目の方法は、ビットコイン コードベースが現在再編成を処理する方法とまったく同じですが、非常にコストがかかる可能性があるため、フォークされたチェーン内の作業証明の量が現在のメイン ブロックチェーンよりも大きい場合、ロールバックと完全な検証は、最後の瞬間。そのため、ノードが最も長いチェーンの一部ではないブロックまたはヘッダーを初めて受信すると、完全な検証をスキップし、ブロックをローカル ストレージに保存します。

Proof of Stake では、同様の初期チェックでコインステーク トランザクションが検証され、前のブロック カーネルの目標難易度を超えたかどうかがチェックされます。 Cointake トランザクションの計算能力を計算するのは簡単ですが、Cointake トランザクションに入力された未消費のトランザクション データが有効で、消費されていないかを確認するのは非常に困難です。前述したように、この操作は未消費のトランザクション データのコレクションをチェックする必要があるため、前のブロックには適用されません。コインステークトランザクションを完全に検証するのは難しいため、ほとんどのプルーフオブステークベースのブロックチェーンは「ヒューリスティック」または「近似」チェックのみを使用しますが、これは多くの場合不適切であり、悪用される可能性があることが判明しています。

副題

抜け穴 #1: 「それが株式ではないと思う」

私たちが最初にこの問題を調査したとき、5 つの暗号通貨 (Qtum、Particl、Navcoin、HTMLcoin、および Emercoin) にかなり単純な形式の脆弱性があることが判明しました。つまり、ブロックが RAM またはディスクにコミットされる前に、これらの暗号化された通貨はおそらく暗号化されます。コインテイクトランザクションをまったくチェックしていません。これら 5 つの暗号通貨に共通するのは、ビットコインの「ヘッダー ファースト」機能を採用しており、ブロックの伝播が 2 つの別個のメッセージ (1 つはブロック用、もう 1 つはゾーン用) に分割されることです。ブロックヘッダーがproof-of-workを通過した後、ノードはそのブロックが最長のチェーンであるかどうかのみを尋ねます。コインテイクトランザクションはブロックヘッダーではなくブロック内にのみ現れるため、ノードは独自にブロックヘッダーを検証できません。代わりに、ブロック ヘッダーをメモリ内のデータ構造 (mapBlockIndex) に保存します。したがって、ネットワーク攻撃者は、たとえ利害関係を持たない攻撃者であっても、潜在的な被害者ノードの RAM を満杯にする可能性があります。

この攻撃の 2 番目の亜種はコード ベースをターゲットにしていますが、方法が少し異なり、別のリソースがターゲットになっていますが、ターゲットは RAM ではなくディスクです。おそらく、ディスクを伴う攻撃は被害ノードにとってより有害であり、RAM がいっぱいになってノードがクラッシュした場合は単純な再起動が必要ですが、ディスクがいっぱいの場合は、外部スクリプトを実行してクリアするなど、手動による介入が必要になります。ディスクからの古いブロック。

これらの脆弱性のいずれかを悪用すると、賭け金なしで暗号通貨に影響を与える可能性があります。対照的に、RAM への攻撃は影響が少ない可能性がありますが、ディスクへの攻撃には技術的な観点からもう少し注意が必要であり、どちらもステーク要件はありません。

副題

脆弱性 2: スペントステーク攻撃

これらのコードベースの系譜をたどることで、バグ 1 がもともとビットコインの「ヘッダー ファースト」機能を PoSv3 コードベースにマージしていたことに気づきました。ただし、この攻撃は以前のバージョン (Peercoin など) では機能しないため、ブロックをディスクに保存する前に、さらに 2 つの予備チェックが必要です。

1. すべての出力がメインチェーンに存在するかどうかを確認します。

2. Proof of Stake カーネル ハッシュが難易度のターゲット要件を満たしているかどうかを確認します。

• 最初のチェックは、現在のメイン チェーン内のこれまでのすべてのトランザクションを追跡するトランザクション データベース (TxDB) の検索によって行われます。言い換えれば、予備検証は全く検証しないよりはマシですが、完全な検証はまだ不可能であり、「ヒューリスティック」および「近似的」検証のみが可能です。この考え方を説明し続けると、さらに 2 つの疑問が生じる可能性があります。

• 懸念事項 A: 最初のチェックでは、トークンが存在することは確認されますが、トークンが未使用であるかどうかは判断できません。この状況は、すぐに次に説明する別の脆弱性につながります。

懸念事項 A に基づいて、私たちは「スペント ステーク攻撃」と呼ぶ、より巧妙な攻撃を使用してこれらの小切手を騙す方法を発見しました。最初のチェックをバイパスするには、すでに消費された出力をノードに表示させます。2 番目のチェックをバイパスするには、まず難易度目標を通過する有効なブロックをマイニングする必要があります。そうするには、かなりの量を所有する必要がある場合があります。資本の。しかし、「ステーク増幅」と呼ばれる手法を使用して、不完全に検証されたトランザクションをいくつか取得し、任意の量の見かけ上のステークを生成できることが判明しました。

副題

エクイティの増幅

システムのステークが 0.01% しかない場合でも、攻撃者が 50% の明白なステーク ブロックをマイニングするのに必要なのは 5000 トランザクションだけであることがわかります。攻撃者は、大量の見かけのステークを収集した後、新しく収集した見かけのステーク出力を使用してプルーフ オブ ステーク ブロックのマイニングを開始します。最後に、上の図の右側に示すように、攻撃者は被害者ノードのディスクを無効なブロックで埋めます。実際、攻撃者は仮想通貨取引所からトークンを購入し、上記の方法で利益を拡大し、これらのトークンを取引所に売り戻し、その後攻撃を実行することができます。負担するコストは少額の取引手数料だけです。

副題

調整された脆弱性の開示

私たちはまず、2 つの暗号通貨、Particl と Qtum に「脆弱性 1」があるかどうか、つまり、これらの暗号通貨がブロックが RAM またはディスクにコミットされる前にコインテイク トランザクションをチェックするかどうかを調査しました。脆弱性の規模を判断するために、2018 年 8 月 9 日に CoinMarketCap.com から時価総額ごとに既知の暗号通貨のリストを収集し、ブロックチェーン ベースのプルーフ オブ ステーク コンセンサス タイプでフィルタリングしました。コードベースがビットコインからフォークされた仮想通貨のみを調査したことに注意してください。合計 26 の仮想通貨をチェックしたところ、Qtum、Navcoin、HTMLcoin、Emercoin と Partickl の 5 つの仮想通貨が脆弱性の影響を受けていることがわかりました。私たちの攻撃は他の暗号通貨には当てはまらないようです。

脆弱性をさらに確認するために、影響を受ける 5 つの追加のコードベースに攻撃を実装しました。ビットコイン ソフトウェアの既存のテスト スイート、特にシミュレートされたタイムスタンプと簡単なブロック作成をサポートする「regtest」モードを活用します。さらに、Bitcoin TestFramework をベースとした Python 開発言語に基づいたテスト ノードも構築し、攻撃者の動作によって拡張できるようにします。テストには Docker コンテナを使用し、脆弱性開示の一環として、依存関係と影響を受ける特定のコミット ハッシュを再利用可能なツールキットにパッケージ化しました。これにより、影響を受ける 5 つの開発チームすべてとこの情報を簡単に共有できます。

ただし、ここにはさらに「厄介な」問題がまだあります。つまり、ほとんどのコード ベースは「regtest」モードを使用しないため、攻撃を視覚的に実証したり、コード ベースごとに複数回使用できるツールキットを提供したりすることはできません。したがって、stratisX の C++ コード ベース デモのみを提供します。コードベースの類似性に基づいて、影響を受ける可能性のある 15 の仮想通貨開発チームすべてに、彼らのトークンがエクスプロイトの影響を受けると思われることを通知しました。このうち、5 つの仮想通貨開発チームが脆弱性を認め、3 つの仮想通貨開発チームが現在調査中、別の 3 チームが脆弱性を認めていない（そして、いくつかのアップグレード変更が実装される場合があると指摘）、4 つのチームがまだ脆弱性を調査中です。与えられた。返答のなかった 4 チームについては、Web サイトから連絡先情報を見つけ、脆弱性を確認するための再現性ツールキットを GitHub コード リポジトリに配置しました。

副題

緩和

すでに、一部の暗号通貨開発チームが、この記事で開示された脆弱性に対する一連の緩和策を実装しているのを確認しています。緩和策を実装した暗号通貨は、エクスプロイトを検出できるだけでなく、問題のあるフォークを切断することもできます。簡単に言えば、ノードはフォークされたチェーン上で送信される多数のブロック ヘッダーなどの異常な動作を監視できます。

ただし、ここにはまだ難しい問題があります。それは、実際の攻撃の「偽りの賭け金」と法的組織再編の誠実なノードをどのように区別するかということです。いくつかの緩和策は、誠実なノードを誤って禁止する危険性があるためです。これまでに確認した緩和策の一部はかなりうまく実装されていますが、その後の効果を確認するにはさらなる調査と分析が必要です。

一部の暗号通貨には、特定の長さ内で機能を部分的に検証する緩和策もあります。メインチェーン上で指定された長さを超えるフォークされたブロックを受信した場合、そのブロックは破棄されます。たとえば、Bitcoin Cash ABC コードベースはこのアプローチを採用しており、10 ブロックごとにローリング チェックポイントを設定します。しかし、このアプローチには他の欠点もあります。それは、「ブロックチェーンの分割」の可能性です。なぜなら、より多くの正直なノードがブロックチェーンの異なるフォークに現れると、ブロックチェーンの分割が発生するからです。特に、ネットワーク接続が不十分なためにノードの同期が失われ、競合するチェックポイントを作成するのに十分な時間がない場合、「ブロックチェーンの分割」が発生する可能性もあります。ノードが接続を回復したとしても、チェーンの共通ビューに到達することはできません。

しかし重要なことに、現在のチェーンのトランザクション出力を使用してコインステークトランザクションが検証される場合、ノードが一時的にフォーク上にあることが判明するため、この緩和策を講じたとしても「ブロックチェーンの分割」のリスクがあることに注意してください。 、実際のメインチェーンに切り替えることができない場合があります。

また、「ブロックチェーンの分割」リスクは、敵対的なマイナーに新たな攻撃ベクトルをもたらします。マイナーは、長いチェーンを密かにマイニングし、それをノードのサブセットに公開してブロックチェーンの分割を引き起こそうとする可能性があります。初期ブロック ダウンロード (初期ブロック ダウンロード) のノードと、長期間オフラインで再起動したばかりのノードは、このタイプの攻撃に対して特に脆弱です。また、この攻撃は、Eclipse 攻撃と組み合わせて、正直なノードを「導入」することもできます。ブロックチェーン上の攻撃者の制御に侵入します。

したがって、これらすべての緩和策は攻撃の実行を困難にするだけであり、実際には完全な認証に代わるものではないことがわかります。 Qtumを含む一部の暗号通貨は、将来のバージョンで非メインブロックチェーン上のブロックを完全に検証することを計画していると報告されています。

副題

最終的な考え

最終的な考え

「フォールス ステーク」攻撃は理論的には単純ですが、プルーフ オブ ステーク暗号通貨の設計に潜在的な問題があることを明らかにしています。つまり、プルーフ オブ ワークで意味をなすいくつかのアイデアが、プルーフ オブ ステークに安全に変換されていません。ビットコインコアのコードシェアがPoSv3暗号通貨の非常に「上流」であることを考えると、これらのプルーフ・オブ・ステーク暗号通貨はさらに精査されるべきであると私たちは考えています。これらの脆弱性を調査していると、さまざまなコード ベースで実行された作業やコメントアウトされたコードでいくつかの例が見つかりました。私たちにとって、これは、プルーフ・オブ・ステーク暗号通貨開発者の中には、暗号通貨を設計する際にこのコンセンサスメカニズムを完全に理解していない人がいることを示しています。

一方で、ブロックチェーンの処理効率を向上させるために無効なブロックをできるだけ早く拒否したいと考えていますが、他方では、実際のトランザクションに影響を与えたり遅延させたりする、フォークされたブロックチェーン上でのブロックに遭遇したくないのです。メインチェーン上での処理 この問題に対する体系的な解決策は、現在の作業グループで未解決のままです。

最近、この脆弱性が少なくとも 2 つのコードベース (ビットコインの CVE 2018-17144 など) に影響を及ぼしていることが確認されていますが、私たちの知る限りでは 20 以上の暗号通貨が影響を受けており、これはそれほど多くはありません。暗号通貨における設計アイデアの重複やコードの再利用が蔓延していることを考えると、将来的にはそのような脆弱性がさらに増えることが予想されます。