このデータのほとんどは、ルーティング料金、イベント リクエスト、支払いチャネル ID に関する情報を含む「チャネル更新」メッセージから取得されます。転送する必要がある合計金額は、支払い金額と後続の各ホップに請求される料金の合計です。一方、支払いの秘密の値は Dina によって計算され、支払い請求書に埋め込まれます (各ホップへのオニオン メッセージによって通知されます)。ホップ）。
アリスは最終ノードのディナから開始します。パッケージには、転送金額、タイムロック期間値、支払い秘密値、および支払い金額が含まれます。ディナは最終ノードであり、支払いを他の人に転送する必要がないため、チャネル ID を追加する必要がないことに注意してください。
このキーは、タマネギ内に含まれるデータの整合性をチェックするためにも使用されますが、エラーが返された場合にのみ使用されます。そう、「む」を逆から書くと「ウム」と呼ばれるのです。支払いエラーの場合、エラーを検出するジャンプは um キーを使用してチェックサムを作成し、前のノードがエラー レポートを受信すると、メッセージの整合性を検証するために um キーも使用します。
このプロセスは、メッセージが最終ノード Dina に送信されるまで続きます。 Dina は、update_add_htlc メッセージを受信すると、自分で生成したシークレット値のハッシュ値を入力できます。これは、この HTLC が自分を対象としたものであることを意味します。したがって、ディナは指紋を確認し、オニオン メッセージを解明し、自分のペイロードを明らかにするだけで済みます。
＃＃ トラブルシューティング
私たちは成功事例、つまりすべてが計画通りに進んだケースについて話していますが、途中で何か問題が発生した場合は、問題が発生したことをすべてのノードに通知するためにメッセージをずっと送り返す必要があります。このプロセスは、通常のオニオン ルーティングと似ています。障害のあるノードを特定するには、共有シークレット値から um キーを導出し、それを使用してランダムなバイト文字列を生成し、XOR 演算を使用して返されたオニオン パーセルを難読化する必要があります。
エラーを見つけたノードは、支払いパスの前のノードにメッセージを送り返します。各ホップは、um キーと ammag キーを使用して、送信者がパッケージを受信するまで同じ操作を実行します。最後に、送信者は ammag キーと um キーを使用してパッケージの難読化を解除し、検証します。
ライトニングネットワークの「オニオンルーティング」とその仕組み
著者: ロレンツォ
ネットワーク内のコンピュータはプロトコルに従って相互に通信します。ここで、「プロトコル」とは、メッセージの送信方法と解釈方法を指定するルールのシステムを指します。ライトニングネットワークプロトコルの決済メッセージ送信部分はBOLT#4で記述されており、「Onion Routing Protocol（オニオンルーティングプロトコル）」とも呼ばれます。
オニオン ルーティングは、ライトニング ネットワークよりも 25 年前に開発されたテクノロジーです。 Tor でも使用されており、「Tor」（「The Onion Router」）という名前の由来となっています。 Lightning Network は、「オリジンベースのオニオン ルーティング」(略称「SPHINX」) と呼ばれるわずかに変更されたバージョンを使用します。この記事では、オニオンルーティングがどのように機能するかについて説明します。
オニオン ルーティングを使用する理由
世界にはさまざまな通信プロトコルが存在しますが、ライトニング ネットワークは支払いネットワークであるため、転送される支払いに関する情報をできるだけ明らかにしないプロトコルを選択するのが合理的です。
ライトニングネットワークがインターネットと同じプロトコルを使用していれば、すべての仲介者は、支払いの送金者、受取人、および経路上の他の仲介者が誰であるかを知ることになります。オニオン ルーティングは、その特性により中間ノードが保証されるため、良い選択です。
オニオンルーティングの概要
オニオン ルーティングがどのように機能するかを説明するための例えとしてパーセルを使用してみましょう。
アリスがディナに支払いたいとします。まず、アリスは実行可能な支払い方法を見つける必要があります。
アリス→ボブ→チャン→ディナ
次に、彼女は「タマネギ」を構築します。彼女はディナから始めます（道の終わりから）。彼女はディーナに送る荷物に秘密のメッセージ（支払い内容）を入れ、自分とディーナだけが知っている鍵でロックする。さて、彼女はこの荷物をチャンに送る別の荷物に入れ、彼女とチャンだけが知っている鍵を使ってその荷物をチャンにロックします。そうですね、などなど。
アリスは、最後のタマネギ (パッケージ) をパス上の最初の仲介者であるボブに送信します。ボブは自分の鍵で荷物のロックを解除し、次の荷物がチャン宛であることを確認します。そこで彼はその荷物をチャンに転送した。チャンも同様で、荷物を開梱した後、中の荷物をディナに渡しました。最後に、ディナさんは自分の荷物を開けると、中に支払いメッセージが入っているのを見つけました。
オニオンルーティングでは、ボブやチャンのような仲介者は、ディナへのメッセージの内容も、支払い経路全体の長さも知りません。彼らが知っている唯一のことは、誰が荷物を転送したか、そして誰が次にそれを受け取るかということです。これにより、メッセージのプライバシーとパスの機密性が保証されます。各仲介者は、TA 用に特別に作成されたメッセージの層にのみ触れることができます。
Lightning Network のソースベースのオニオン ルーティングでは、送信者が支払いパスを選択し、そのパスに対して完全なオニオンを構築します。これはプライバシー ホールとみなされる可能性があります (翻訳者注: 受信者のネットワークの場所は送信者に公開される必要があります)。 「ブラインド ルーティング」（中国語訳）などの他のルーティング スキームは、送信者への支払いパスの一部を難読化することでこの問題を解決します。ただし、この記事では SPHINX のみに焦点を当てます。
玉ねぎを組み立てる
ここで、オニオンルーティングの仕様を見てみましょう。最初に、次のことを定義する必要があります。
ジャンプロードを構築する
アリスが支払いパスを選択すると、ゴシップ プロトコルから各支払いチャネルの情報を取得して各ホップのペイロードを作成し、基本的に転送される支払い用の HTLC の作成方法を各ホップに指示します (ハッシュ タイムロック コントラクト)。
適切な HTLC を確立するには、各ホップで次のことを行う必要があります。
このデータのほとんどは、ルーティング料金、イベント リクエスト、支払いチャネル ID に関する情報を含む「チャネル更新」メッセージから取得されます。転送する必要がある合計金額は、支払い金額と後続の各ホップに請求される料金の合計です。一方、支払いの秘密の値は Dina によって計算され、支払い請求書に埋め込まれます (各ホップへのオニオン メッセージによって通知されます)。ホップ）。
アリスは最終ノードのディナから開始します。パッケージには、転送金額、タイムロック期間値、支払い秘密値、および支払い金額が含まれます。ディナは最終ノードであり、支払いを他の人に転送する必要がないため、チャネル ID を追加する必要がないことに注意してください。
転送金額は支払金額と同じなので、一見冗長に思えますが、マルチパス決済では複数の経路で支払金額を送信するため、両者の値が一致しなくなります。
Chan のペイロードに、Alice は Chan と Dina のチャネル ID を追加します。また、転送量とタイムロック値も追加しました。最後に、アリスはボブのペイロードを作成します。チャンは自分とディナの間のチャネルを通じて支払いとして 100 サトシに請求するため、アリスはボブに転送金額が支払いと手数料を足したものであることを伝える必要があります。 Chan のチャネル更新メッセージによると、タイムロック値も 20 (ブロック単位) 増加しました。最後に、アリスはボブの手数料とタイム ロック要件も考慮し、タイム ロック長が 700040、値が 100200 サトシの HTLC をボブに与えます。
共有シークレットの値とキーの生成
次に、アリスは各ホップ (最終ノードを含む) の共有秘密を生成することでオニオンを準備します。この共有秘密値は、アリス自身の秘密鍵と相手の公開鍵を乗算することによって、アリスとターゲット ホップによってそれぞれ生成できます。
共有シークレット値はオニオン ルーティングに必要であり、アリスと各ホップが同じキーを導出できるようになります。次に、アリスはそれらのキーを使用してタマネギの各層を難読化し、ホップはそのキーを使用して難読化を解除します。
アリスのプライバシーを保護するために、彼女は自分のノード公開鍵を使用するのではなく、オニオン用のワンタイムセッション鍵を作成して共有秘密値を導出します。このセッション キーを最初のホップに使用し、その後のホップごとに、アリスは最新のキーにブラインド係数を乗算してキーを決定的にランダム化します。これらは、「一時キー」と呼ばれる共有秘密値キーを作成するために使用されます。
ボブ、チャン、ディナは全員、アリスと同じシークレット値を取得する必要があるため、セッションで使用する一時キーを知っている必要があります。アリスは、メッセージ サイズを節約するために最初のキーのみをオニオンに置きます。各ホップは次の一時キーを計算し、それを次のノードのオニオンに埋め込みます。各ホップは、独自の公開鍵と共有秘密値を使用して、アリスが次の一時鍵を決定するために使用するブラインド係数を計算できます。
前述したように、共有秘密の値はいくつかのキーを生成するために使用され、アリスと対応するジャンプはこれらのキーを使用してオニオンに対していくつかの操作を実行できます。各キーの機能を見てみましょう。
ローキー
Rho キーは、アリスがオニオン層を暗号化するために使用します。これにより、ペイロードの内容が難読化され、部外者が解読できなくなります。 rho キーの所有者のみがペイロードを復号化できます。これがオニオンを受信するノードが行う必要があることです。アリスとの共有秘密値を使用して rho キーを取得し、オニオンを復号して内容を読み取ります。
ミューキー
アリスは、mu キーを使用して各ペイロードのチェックサムを作成します。また、オニオンを受け取るホップにチェックサムを渡します。次に、このホップは、mu キーを使用して受信したペイロードのチェックサムを生成し、それがアリスによって指定されたものと一致することを確認します。これは、ペイロードの整合性をチェックし、改ざんされていないことを確認するためです。
パッドキー
このキーは、ランダムな「ガベージ」データを生成するためにアリスによってのみ使用されます。これらのデータもオニオンの一部であり、支払いパスの長さやオニオンが通過したホップの数とは無関係であり、たとえその内容の一部が無関係であっても、オニオンは常に同じサイズに保たれます。このようにして、オニオン ルーティングはパスの長さを隠し、送信者と受信者のプライバシーを事実上保護します。
かぎ
このキーは、タマネギ内に含まれるデータの整合性をチェックするためにも使用されますが、エラーが返された場合にのみ使用されます。そう、「む」を逆から書くと「ウム」と呼ばれるのです。支払いエラーの場合、エラーを検出するジャンプは um キーを使用してチェックサムを作成し、前のノードがエラー レポートを受信すると、メッセージの整合性を検証するために um キーも使用します。
オニオン層のカプセル化
最終的なタマネギのラップは次のようになります。
これで、アリスは各ホップのペイロードと各ホップの共有秘密値を取得しました。アリスがこの情報をどのように最終的なタマネギに変換するかを見てみましょう。彼女は最後のノードから始めて、一歩ずつ戻っていきます。
彼女はまず、すべてのオニオン ペイロードの合計長である 1300 バイトの長さの空のフィールドを作成します。次に、パッド キーを使用して、長さ 1300 バイトのランダムな文字列を作成します。これは、どのホップにも役に立たないゴミです。このステップは、オニオンの各層が同じに見えるようにするために行われるため、パスの全長 (ホップ数) も、送信者と受信者もわかりません。
次に、使用する必要があるペイロードのチェックサムを作成し、それをペイロードの最後に置きます。最終ノードへのメッセージでは、チェックサムはすべて 0 で、Dina がこのオニオンの最終受信者であることを通知します。チェックサムをペイロードの最後に追加した後、Alice はペイロード (およびチェックサム) をガベージの先頭に置き、メッセージ全体のうち 1300 バイトを超える部分を削除して、メッセージ全体の長さが 1300 バイトになるようにします。
次に、アリスは rho キーを使用してランダムなバイト文字列を作成し、前のステップで取得したオニオン ペイロードに対して排他的論理和 (XOR) 演算を使用して、難読化されたペイロードを取得します。ペイロードの元のテキストは、難読化されたテキストに対してこのランダムなバイト列の XOR 演算を使用することで取得できます (訳者注: つまり、ここでの XOR は対称暗号化のアルゴリズムであり、ランダムなバイト列がキーです)。 XOR 演算は、オニオン ペイロードをランダムなバイト文字列 (rho キーによって生成される) とビットごとに比較し、データ ビットの 1 つが 1 の場合にのみ 1 を出力します。これにより、難読化されたペイロードが生成されます。 XOR 演算の賢い点は、正しいランダム バイト文字列と難読化されたペイロードを取得している限り、難読化されたペイロードを取得するには、その 2 つを使用して XOR 演算を再度実行するだけで済むことです。
オニオンを受信するノードは同じ rho キーを導出できるため、アリスと同じランダムなバイト列を生成できます。このようにして、途中の各ノードが混乱を解き、コンテンツを読み取ることができます。
1 ホップの混乱オニオンを準備した後、アリスは次のノードに対して同じ手順を繰り返します。主な違いは、Dina の玉ねぎが完成したら、ゴミを生成する必要がなくなることです。彼女は、前のステップで難読化されたオニオンを有用なペイロードとチェックサムの後に追加し、1300 バイトを超える部分を削除するだけです。
最後に、アリスは最後の難読化されたオニオンを取得し、ボブがこのオニオンの整合性を検証できるようにチェックサムを追加します。次に、アリスはセッション公開キーを追加し、ボブがこの公開キーを使用して共有秘密値を計算できるようにします。最後に、バージョンを表すバイトも追加し、その中のデータを解釈する方法を他のノードに伝えます。 BOLT #4 で記述されるバージョンの場合、バージョン バイトは 0 でなければなりません。
前方タマネギ
このオニオン パッケージを送信するために、送信者は次のフィールドを含む update_add_htlc メッセージを作成します。
メッセージを準備した後、アリスはボブにメッセージを送信します。メッセージを受信した後、ボブは自分のタマネギの解読を開始できます。彼はまずオニオン ラッパーからセッション キーを取得し、それを使用してアリスとの共有秘密の値を導き出します。
共有秘密の値を入手したボブは、オニオン パッケージに埋め込まれたペイロードのチェックサムを検証するための mu キーを生成します。ペイロードが改ざんされていない場合、チェックサムは一致するはずです。
パス内の他のノードにパスの長さが分からないように、ボブはオニオン パケットにゼロで埋められた 1300 バイトのフィールドを追加します。次に、ボブは rho キーから 2600 バイトの長さのランダムなバイト文字列を生成します。ボブは、このランダムなバイト文字列を使用して、ゼロで埋められたオニオン ペイロードを XOR します。
混乱を招く玉ねぎの投入についてお話したことを覚えていますか?難読化されたオニオン ペイロードを入力として使用し、同じバイト文字列で「XOR」演算を実行して、難読化前のオニオン ペイロードを取得します。アリスとボブは同じ共有秘密値を使用し、同じ rho キーを生成するため、ボブは難読化を解除できます。これには、1300 バイトの長さのパッド文字をランダムなバイトに変換するという追加のボーナスがあります。
ボブの難読化されていないペイロードには、ホップのペイロード データとフィンガープリントが含まれています。ボブはこのフィンガープリントを保存して、チャンに送信するタマネギのパッケージに追加できるようにします。ボブは、オニオン メッセージから自分のペイロードを分離した後、オニオン パケットを元のサイズの 1300 バイトに変換し、アリスと同じようにセッション キーをランダム化します。最後に、Bob は、バージョン バイト、セッション キー、およびオニオン ペイロードに含める予定のフィンガープリントを追加し、update_add_htlc メッセージを介してオニオン パケットを Chan に転送します。
このプロセスは、メッセージが最終ノード Dina に送信されるまで続きます。 Dina は、update_add_htlc メッセージを受信すると、自分で生成したシークレット値のハッシュ値を入力できます。これは、この HTLC が自分を対象としたものであることを意味します。したがって、ディナは指紋を確認し、オニオン メッセージを解明し、自分のペイロードを明らかにするだけで済みます。
＃＃ トラブルシューティング
私たちは成功事例、つまりすべてが計画通りに進んだケースについて話していますが、途中で何か問題が発生した場合は、問題が発生したことをすべてのノードに通知するためにメッセージをずっと送り返す必要があります。このプロセスは、通常のオニオン ルーティングと似ています。障害のあるノードを特定するには、共有シークレット値から um キーを導出し、それを使用してランダムなバイト文字列を生成し、XOR 演算を使用して返されたオニオン パーセルを難読化する必要があります。
エラーを見つけたノードは、支払いパスの前のノードにメッセージを送り返します。各ホップは、um キーと ammag キーを使用して、送信者がパッケージを受信するまで同じ操作を実行します。最後に、送信者は ammag キーと um キーを使用してパッケージの難読化を解除し、検証します。
エラーは、onion パッケージ、ノード、またはチャネルによって発生する可能性があります。ライトニングネットワークをよく利用していると、「チャンネルが利用できない」「料金が足りない」などのエラーが発生したことがあるかもしれません。