ライトニングの交換サイクリング攻撃の検証に関する検証結果

「ライトニングの交換サイクリング攻撃の検証の結果」

最近、アントワーヌ・リアルト氏によって公開されたライトニングの脆弱性について、大騒ぎが起きています。多くの人々が天地逆さまになると主張しているが、ライトニングが根本的に壊れているということは全く事実ではありません。問題の一部は、まずこの脆弱性の仕組みを理解していないこと、そしてさらに、この個別の脆弱性がライトニングネットワーク上の他の既知の問題と重なっていることを理解していない人が多いということです。

まずは、この脆弱性自体を理解しましょう。ライトニングの支払いがネットワークを介してルーティングされる際、失敗した支払いの返金のタイムロックがどのように機能するか理解することが重要です。受信者に最も近いホップのタイムロックは ‘x’ であり、送信元に戻るにつれてホップごとに ‘x+1’、’x+2’などとなります。ホップが進むごとにタイムロックは徐々に長くなります。これは、支払いが受信者に到達し、しかし何らかの問題でプレイムージが送信元まで伝わらない場合、停止したホップがオンチェーンでそれを強制し、全ての前のホップが支払いを確認するためのプレイムージをそこに置く時間があるからです。そうしなければ、失敗が発生する中間の段階で、失敗したホップがプレイムージを使って資金を要求し、それを転送するホップが返金経路を使って要求し、その中間者が資金を失うことになります。

Replacement Cycling Attackは、目的とする望ましくない結果、つまり、出口ホップが成功するトランザクションで資金を要求し、入口ホップが返金トランザクションを通じて資金を要求するというものです。これには、被害者ノードを停止させ、成功トランザクションでのプレイムージを片側でタイムロックが切れる前に見えなくする必要があります。そのため、被害者ノードのメンプールを操る非常にターゲテッドで複雑なゲームが必要です。ここで、実際のトランザクション構造を見てみましょう。ライトニングチャネルの状態を表す主要なトランザクションであるコミットメントトランザクションがあります。そのトランザクションは、チャネルの一方が完全に制御する資金を表現するための出力を持ち、ルーティング中の各HTLCのために出力があります。これらの出力が関心事です。各HTLCの出力は、受信者のプレイムージとそれによる即時の支払い、または返金のタイムロックが切れた後にいつでも支払うことができます。

攻撃には、悪意のある当事者または共謀者が、被害者ノードに対して支払いをルーティングしているノードの両側にチャネルを持っていることが必要です。つまり、被害者であるボブは、アリスとキャロルとチャネルを持っており、キャロルからボブへアリスへ支払いがルーティングされます。このとき、アリスとボブの間の返金経路のタイムロックは、キャロルとボブの間の返金よりも切れて有効になることを覚えておいてください。

攻撃者はボブを介して支払いをルーティングし、その後アリスがボブに対して支払いを最終化するためにプレイムージを送らないようにします。ボブはアリスとの間でのタイムロックウィンドウが切れるまで待ち、チャネルコミットメントトランザクションと返金トランザクションをブロードキャストしてタイムロックウィンドウが切れる前に確定させます。アリスはプレイムージトランザクションを使ってチャネルとは関係のない出力で資金を要求し、その直後にプレイムージトランザクションの2番目の入力をダブルスペンドします。この目標は、ボブのタイムアウトトランザクションをメンプールから追い出すことですが、同時にプレイムージトランザクションも追い出してしまい、ボブがそれを見ることはありません。もし彼が見たら、彼はプレイムージを学び、タイムアウトトランザクションが有効になる前にキャロルとのチャネルで簡単に資金を要求できます。

アリスとキャロルは、ボブがアリスと彼のタイムアウトトランザクションを再ブロードキャストするたびに、一貫してこれを行わなければなりません。ただし、キャロルが有効なタイムアウトトランザクションが存在しないブロック高度を経過するまで。それから彼らはアリス側で成功トランザクションを提出し、キャロル側でタイムアウトトランザクションを提出し、ルーティングしていた支払いの価値を失ったボブを放置します。

問題は、二つの面倒なことです。まず第一に、被害者のBitcoin Coreノードは、プレイムージ成功トランザクションがライトニングノードがプレイムージを取得できるメンプールにいつも伝播しないようにするように特定の対象にされなければなりません。第二に、アリスがプレイムージトランザクションを追い出すために使用する2番目のトランザクションが確定すると、アリスにコストが発生します(つまり、アイデアはタイムアウトトランザクションをプレイムージで置き換えるためのものなので、それがメンプールから追い出され、プレイムージトランザクションが2番目の入力をダブルスペンドするもの)。つまり、ボブが自分のタイムアウトトランザクションを再ブロードキャストするたびに、アリスはそれを再追い出すためにより高い手数料を支払わなければならず、その確定時に実際にコストが発生します。

よく、Bobは高い手数料で彼のタイムアウトトランザクションを定期的に再ブロードキャストすることで、Aliceに大きなコストを負わせることができます。つまり、支払いHTLCのアウトプットがAliceが負担する手数料よりも大幅に高くなければ、この攻撃は経済的に実行する価値がありません。HTLCの成功およびタイムアウトトランザクションの構築方法を変更することで、この攻撃を完全に防ぐことも可能です。この攻撃には、トランザクション全体に署名が含まれており、最小の詳細(この攻撃に必要なプレイムージトランザクションに新しいインプットを追加するなど)が変更された場合に無効になるSIGHASH_ALLフラグを使用することができます。これは、現行バージョンのアンカーアウトプットを使用するライトニングチャネルでは機能しませんが、この問題を完全に解決することができます。Peter Toddはまた、新しいコンセンサス機能を提案しており、これは一定の時間またはブロック高の経過後にトランザクションが無効になる逆タイムロックのようなもので、この問題を完全に解決することができます。しかし、私の意見では、それほどまでに進む必要はありません。

定期的にトランザクションを再ブロードキャストしてわずかな手数料を上乗せするだけで、攻撃の影響を大幅に緩和することができますが、さらに、この問題は重大な問題ではないとする要素も多数あります。まず、ルーティングノードでない場合、これは本当に深刻な問題ではありません。したがって、ほとんどのエンドユーザーはこの攻撃から安全です。さらに、ノードがランダムな人にチャネルを開くことを許可していない理由はたくさんあります。ランダムなチャネルは効率的に管理されていないか専門的に管理されていない場合、未使用のチャネルに投資した資本が発生するためです。したがって、攻撃に対して魅力的なターゲットとなる大規模なノードは、最初に接続するだけでも簡単ではありません。

さらに、過去に私が以前に書いたように、ネットワーク上で可能な他の攻撃も、ノードがHTLCをどのように処理するかのフィルターや制限がすでに必要とされています。つまり、転送できる支払いのサイズの制限、一度に許可する支払いの数などです。したがって、攻撃の対象となるノードとチャネルを開くことができたとしても、ネットワークが進化するにつれて、最初に支払いを転送するかどうかを判断するための詳細な基準やフィルターが追加されるでしょう。

全体的には、これは合法的な問題であり、可能な攻撃ではありますが、直接的な対策や攻撃が長期的に他の問題の解決策とどのように相互作用するかを考えると、これは解決できない問題ではありません。これは合法的な問題ですし、それを単なるFUD(恐怖、不確実性、疑念)として無視するのは正確ではありませんが、天井が落ちてきて、ライトニングネットワークがプロトコルとして失敗すると主張するのは過度な反応です。

時間は流れていきますし、問題が発生するでしょうし、問題は発生すれば修正されるでしょう。いつものように。