これは、ビットコインの分野で独学の教育者であり、技術志向のビットコインポッドキャストホストであるShinobiによる意見編集です。
チャネル ジャミングは、ライトニング ネットワークで最も深刻な未解決の問題の XNUMX つです。 これは、ネットワーク上のサービス拒否攻撃ノードにオープンなメカニズムを提供して、ノードがルーティングされないようにし、流動性がロックされ、料金を稼ぐための支払いを転送できない間にお金を失います。 攻撃者は、自分自身から自分自身に他のノードを介して支払いをルーティングし、支払いを完了することを拒否できます。 これにより、ハッシュ化されたタイムロック コントラクト (HTLC) のタイムロックが期限切れになり、支払いが払い戻されるまで、その流動性は他の支払いの転送には役に立たなくなります。
先月、Lightning 開発者の Antoine Riard は、この問題を解決するための正式な仕様を提案しました。 XNUMX 月、Riard と Gleb Naumenko は、 研究 一般的な問題自体と、それを軽減または解決するために使用できるさまざまなソリューションを検討します。 これらの提案されたソリューションの XNUMX つは、匿名化されたクレデンシャルの形式でした。これを使用して、ノードを介して支払いをルーティングするユーザー向けの一種のレピュテーション スコアリング システムを構築できます。そのレピュテーションを公開したり、人々のプライバシーに悪影響を与える静的な識別子に関連付けたりする必要はありません。 このソリューションは現在、 正式な議定書の提案 先月 Riard によって作成されました。
Inside The Channel 妨害緩和の提案
アイデアの核となるのは Chaumian の ecash トークンです。 これらは、トークンの発行が後でトークンの償還に関連付けられるのを防ぐ方法で、造幣局によって発行される集中化されたトークンです。 これは、ブラインド方式でトークンに署名することによって行われ、トークンの受信者が署名を無効にすることなくトークンのブラインドを解除できるようにします。 発行者は、トークンが発行されたときにそのトークンを接続できなくても、それが正当なトークンであることを確認できます。
この提案では、ネットワーク上の各ルーティング ノードによって発行されるこれらの Chaumian トークンを、評判の証明の形式として使用することを提案しています。 支払いをルーティングするとき、支払いホップの各ノードによって発行された Chaumian ecash トークンは、支払いに沿ってそのノードのオニオン バンドルにラップされます。 トークン ユニットは、許可された HTLC の値と払い戻しのタイムロック期間の両方を表します。 HTLC を転送する前に、各ノードは、タマネギのブロブに含まれるトークンが有効であり、以前に償還されたことがないことを確認し、これらの条件の両方が真である場合にのみ HTLC を転送します。
HTLC が正常に決済され、プリイメージが明らかになった場合、支払いパスに沿ったすべてのノードが署名し、HTLC プリイメージと共に送信者に返される新しく発行された Chaumian トークンが含まれます。 HTLC が正常に解決されない場合、ルーティング ノードはトークンを使用済みトークン テーブルに含めることによってトークンを「焼き付け」、新しいトークンを発行しません。 これにより、送信者はそれらのノードを介して支払いを再度ルーティングするために、それらのノードから新しいトークンを取得する必要があります。 全体的な概念は、ジャミング攻撃は常に解決に失敗するということです。したがって、このスキームでは、ジャミング攻撃を実行すると、通過する各ノードによって発行されたこれらのトークンが焼かれ、それを再度実行するためにさらに取得するコストが発生します。 現在、ジャミング攻撃には時間しかかからないため、経済的コストが追加されます。
それでは、部屋で象について議論する時が来ました: ネットワーク全体でこれらのトークンの発行と流通をどのようにブートストラップしますか? 経由したい各ノードには、それらによって発行されたトークンが必要です。 解決策：彼らに支払います。 チャネル妨害の問題に対するもう XNUMX つの提案された解決策は、前払い料金です。つまり、支払いが成功するかどうかに関係なく、支払いのルーティングを試みるために料金を請求することです。 そのため、失敗した支払いでも送信者に料金が発生します。
Riard の提案は、これらのトークンを XNUMX 回限りの購入として各ノードから直接購入することです。 その時点から、すべての支払いに対して前払い料金を支払う代わりに、前の支払いが正常に決済される限り、「ルーティング トークン」が再発行され、次の提案された支払いを手数料なしでルーティングできるようになります。 このようにして、成功した支払いは実際のルーティング料金のみを支払い、失敗した支払いは前払い料金のみを支払い、成功した支払いの一種の「二重料金」を防ぎます. 少なくとも経済的には、これは、失敗した支払いには費用がかからず、成功した支払いのみが手数料を支払う現在の状況と、すべての支払いが前払い料金を支払い、成功したものはルーティング料金も支払います。
提案からのポイント
個人的には、この種の事前のトークンの直接支払いは、Lightning Network を使用するプロセスに UX の大きな摩擦をもたらす可能性があると思います。 ただし、提案を少し調整することで、その摩擦に対する非常に簡単な解決策があると思います。
Chaumian トークンを前もって各ノードに直接支払う必要がある代わりに、この提案は、前払い料金の提案とより直接的にハイブリッド化することができます。 ノードのトークンがある場合は、タマネギのブロブにそれらを含めます。単純に HTLC プロポーザル内で前払い料金を直接支払うのではなく、支払いが正常に決済された場合、あなたのアップに比例して Chaumian トークンが発行されます。・フロント料金ありました。 このように、事前に多くの異なるノードからトークンを収集する必要はなく、頻繁に使用し、コストが発生することはほとんどないさまざまなノードから適切なコレクションが得られるまで、最初の支払いを行う過程でトークンを取得するだけです。それらを達成するための前払い料金の。
もう XNUMX つの潜在的な摩擦の原因は、ノード オペレーターにあり、Chaumian ecash 自体の根本的な問題に帰着します。 トークンが XNUMX 回だけ使用されるようにするために、発行者は使用されたすべてのトークンのデータベースを維持する必要があります。 これは永遠に拡大し、トークンの有効性を確認するためのルックアップは、データベースが大きくなるにつれてますます高価になり、時間がかかります。 このため、Riard は、ノードごとのゴシップ プロトコルでアドバタイズされたブロックの高さで、これらの Chaumian トークンを定期的に期限切れにすることを提案しています。 これは、送信者がこれらのトークンを定期的に買い戻す必要があることを意味します。または、実装がそれをサポートしている場合は、以前のトークンの有効期限が切れた後に、新しい署名キーによって署名された新しいトークンと交換する必要があります。
これにより、支払いの送信者に通常の経済的コストがかかるか、古いトークンの有効期限が切れたときに再発行を確実にするために定期的にチェックインする必要があります。 実際には、これは独自の Lightning ノードを実行している人々に対して自動化できます。また、Lightning サービス プロバイダー (LSP) モデルを中心に構築されたウォレットの場合、LSP 自体がユーザーに代わってトークンの取得と維持を実際に処理できます。ユーザーの支払いのためのトークン プロビジョニング。 ただし、完全なLightningノードまたはLSPがなければ、これはライトウォレットユーザーにとって少し面倒になる可能性があります.
この提案は、特に基本的な前払い料金スキームともう少し緊密にハイブリッド化された場合、攻撃ベクトルとしてのチャネルジャミングを軽減するのに実際に大いに役立つと思います。また、UX の摩擦のほとんどは、LSP ユーザーとユーザーにとって非常に簡単に処理できます。独自の Lightning ノードを運用する人々。 また、前払い料金が高い摩擦をもたらすとしても、単純に ビットコイン UTXO の制御を証明する トークンを取得するために実際に料金を支払う代わりに使用できます。
忍によるゲスト投稿です。 表明された意見は完全に独自のものであり、必ずしもBTCIncまたはBitcoinMagazineの意見を反映しているわけではありません。
