Blinded Paths

ざっくりまとめ

LNでの支払時のルーティングのプライバシーを高めるためにBOLT12で導入された。

従来のルーティングだとインボイスに受取ノードの情報が含まれていたり、送信者がルーティングを決めるため支払いの経路などの情報が見えてしまう。

Blinded Pathsを導入することで最終的に受け取る人が誰なのかを送金者にもわからないようにできる。

簡単な流れとしては受取人がインボイスを発行する際に自分の周辺のノードから自分までの支払い経路を作成し、その情報を送金者にわたす。

送金者は受け取った情報を下に送金するが、送金先が受取人の周辺のノードであるため最終的な受取人が誰なのかはわからない

code:mmd

sequenceDiagram

participant Receiver as 受取ノード(Receiver)

participant Sender as 送信ノード(Sender)

participant R1 as 中継ノード1

participant R2 as 中継ノード2

participant BlindEntry as ブラインド化入り口ノード

participant Blinded as ブラインド化区間(暗号化情報)

rect rgba(220, 220, 220, 0.5)

Note left of Receiver: 1. 受取ノードが「自分への最終ルート」<br>（BlindEntry→...→Receiver の複数ホップ）を<br>暗号化して "Blinded Paths" を生成

end

Receiver->>Sender: 2. "請求書(Invoice/Offer)" + Blinded Paths情報を送付

Note over Sender: 3. Senderは通常のチャネル情報を使って<br>自ノード→BlindEntry までの経路を探索し、<br>Blinded Pathsデータを末尾に付加した<br>オニオンパケットを作成

Sender->>R1: 4. オニオンパケットを転送

R1->>R2: 5. オニオンパケットを転送

R2->>BlindEntry: 6. オニオンパケットを転送

Note over BlindEntry: ここから先は<br>Blinded Pathsの暗号化情報を使って<br>（実際のノード列はSenderにも不明）

BlindEntry->>Blinded: 7. 暗号化された経路を順次処理

Blinded->>Receiver: 8. 支払い最終到達（受取ノード）

code:mmd

----------------------------------------------------------------------------------------

以下はchatgptからの情報

Lightning Network (以下、LN)におけるBlinded Paths（ブラインド・パス）とは、受取側のノード（支払いを受け取る側）のプライバシーを高めるために提案されている機能・仕組みです。支払いを受け取るノードがルート（経路）の一部あるいはすべてを暗号化して送り手に提供し、送り手は「どのノードを経由するのか正確にはわからない」状態で支払いを転送できるようにするものです。以下のポイントが重要です。

Blinded Pathsを用いると、受取側は「自分のどのノードやチャネルを使うか」を外部に明らかにすることなく、支払いを受け取る際に必要な「暗号化された経路情報」だけを送り手に渡します。送り手が実際にルートを探しながら支払いを転送する時、経路の最終部分は暗号化された“ブラインド”な情報を使うので、受取側ノードや具体的チャネルが推測されにくくなる、という仕組みです。

Sphinxプロトコル

通常のLNの支払いの際、送信者から受信者へ行く途中の各ホップは自分の前後のノードしか分かりません。これによって元々ある程度の匿名性が保たれています。しかし最終的な受取ノードや、使われうるチャネルを明確に“請求書”に書いてしまうと、受取側が特定されやすくなります。

Blinded Pathsの仕組み

受取側が経路の末端部分を「暗号化された複数ホップ」としてまとめ、トークンや鍵素材とともに作成する。

この“ブラインド”な経路情報を支払いの要求（請求書）と一緒に送り手に渡す。

送り手は支払いをルーティングする際に、「途中までは通常のルート探索を行い、最終区間（複数ホップ）は受取側が提供した暗号化された情報を使う」形で支払いを行う。

中継ノードや支払い送信者自身は、そのブラインド情報が具体的にどのノードを指しているかを解読できず、“最終ノードがどこか”を特定できなくなる。

受取側の公開情報や利用チャネルが推測されにくくなるため、プライバシーが向上します。

DoS攻撃や監視のリスク低減

受取側ノードのIDやチャネル構造がわかりにくければ、そのノードに対する標的型攻撃（DoS攻撃やプロービング攻撃など）も起こりにくくなります。

経路ヒント管理の簡略化

請求書に書かれる「経路ヒント」（ルートヒント）に実際のチャネル構造を露出させる必要がなくなるため、受取側が様々なチャネルを持っていたり、あるいは時々刻々と状態が変わるような状況でも、一部情報だけで済む可能性があります。

LNで支払を行う場合、送信者（支払いをするノード）は以下の手順を踏みます。

ルート探索（Path Finding）

送信者は、受取ノードIDとネットワーク上のチャネル情報（公開チャネル、あるいはInvoiceに含まれるルートヒントなど）をもとに、自分→受取側への経路を計算・探索する。

オニオンパケットの作成（Sphinxプロトコル）

見つけた経路の各ホップ（中継ノード）ごとに暗号化レイヤーを用意し、送信者が最終的な目的地（受取ノード）まで含めた経路全体をオニオンパケットに埋め込む。

このとき、「次に転送すべきノードの情報」が暗号化された形で各ホップに渡される。中継ノードは“1ホップ先”のノード情報しか読めない。

中継ノードごとのデータ処理

最初の中継ノードは、オニオンを一層剥がして「次のノードはXだ」と知り、支払いを転送する。次のノードでも同様の処理を行い、最終的に受取ノードに到達する。

ここで重要なのは、送信者が「最終的な目的地＝受取ノード」や全経路を知っているという点です。

受取ノードの情報はInvoice（請求書）に書かれており、送信者はそれを見て経路探索をする。

送信者が経路を組み立てるので、中継ノードや最終ノードのID自体は送信者にすべてわかる（ただし、送信者が構築したオニオンを剥く中継ノード自身は、その時点の「次ホップ」以外はわからない）。

Blinded Pathsでは、受取側ノード（支払いを受け取る側）が、「自分の元に到達するためのルート（複数ホップ）」をあらかじめ作成します。

そして、その作成した経路情報を特殊な方法で暗号化（ブラインド化）して保管し、その暗号化されたデータのみを送信者へ渡します。

送信者は経路の“最終区間”を知らないまま支払いルートを構築

送信者は、受取側からもらった「Blinded Pathsの暗号化データ」を、通常のルート探索で求めた「自分からブラインド化入り口ノード（あるいは入口付近のノード）までのルート」と合体させる形でオニオンを組み立てる。

しかし、送信者には「Blinded Pathsの中身（具体的にどんなノードを経由するか）」は分からない。暗号化されているので、最終区間がどこを通って受取ノードに行くのかを知ることができず、受取ノードの正体や使われるチャネルを推測しづらい。

中継ノードから見た情報の違い

通常のオニオンルーティングでも、中継ノードは「自分の前後のホップ」しか知らない仕組みになっています。

Blinded Pathsにおいては、さらに受取側が経路末端を暗号化するため、仮に送信者や一部中継ノードが暗号を開封できたとしても（実際はできないよう設計されていますが）、経路の最終部分がどのノードを通るかは見えません。

結果として、「支払ルートの最後にどのノードがいるのか？」「どのチャネルを介しているのか？」をより強固に隠せるようになります。

受取ノードが「自分に到達するための複数ホップ（途中ノード列）」を選びます。

例: N_1 -> N_2 -> ... -> N_k -> Receiver

いわゆる「Blinded Pathの入口ノード（入口付近）」から最終的な受取ノードまでの全ルートです。

2. 受取ノードが暗号的な“ブラインディング”処理を行う

受取ノードはまずランダムな“ブラインディング用の公開鍵” (blinding key) を生成します。

各ホップ (N_i) の実際の公開鍵（ノードID）を “ブラインド” した公開鍵へ写像する演算を行います。

例としては、下記のような楕円曲線上の演算ルールが検討されています（実際の式はプロトコル・実装により若干変わる可能性あり）：

$ B i =N i +H(seed,i)G (ある種の鍵導出関数)

ここで H( ) はハッシュ関数や鍵導出関数、G は生成元（ジェネレーター）を指します。

受取ノードのランダム種（あるいはブラインディング用鍵）を使って各ホップをずらしているイメージです。

こうして出来た “ブラインド化ノードID” を並べていくと、「外部からは誰が本当のノードか分からないが、実際のノードにだけ復号できる鍵情報」が埋め込まれた経路データ（Blinded Path）になります。

3. 暗号化された“Blinded Path”と関連情報を請求書やOffer（BOLT 12）に載せる

受取ノードは、この暗号化済みのルート情報や鍵素材の一部（Blinded Path全体を復号するために必要な要素の一部）をエンコードし、請求書 (BOLT 11) やオファー (BOLT 12) などに含めます。

送信者は、それを“黒箱”として受け取るだけです。中身の具体的ノード列などは解読できないようになっています。

4. 送信者は自分 → Blinded Pathの入口 までを通常のルート探索で決め、最後にブラインド化パートを接続する

送信者（支払ノード）はネットワークの公開チャネル情報や、請求書に含まれる公開されている部分のヒントだけを使って、まずは「自分からBlinded Pathの入口（例：N_1に相当するブラインド化されたノード）まで」のルートを探す。

最後の区間は提供された“Blinded Path”をそのまま（暗号化データごと）オニオンに組み込み、最終的な受取ノードへルーティングできるようにする。

5. 中継ノード＆最終受取ノードが暗号を段階的に復号しながら転送

オニオンルーティングの各ホップは、Sphinxプロトコルの要領で“自分の秘密鍵”と“ブラインディングに基づく鍵素材”を使い、必要な情報を復号して次に送る先を知る。

しかし外部からは「どの実ノードが使われているか」完全には分からない。送信者も最後の受取ノードがどこか特定できずに支払いが完了する。

1. ブラインディング用鍵 (blinding key) の生成

受取ノードがランダムな秘密鍵 b を選び、それに対応する公開鍵 B = b·G（楕円曲線上での乗算）を得る。

この B がベースとなり、各ホップの公開鍵を“ずらす”ことで、外部からは元のノードIDと対応付けられなくします。

2. 各ホップの“ブラインド化”

例えば、ホップiに対応する本当の公開鍵を P_i とする。

あるハッシュ関数（H）によってホップごとに導出されるスカラー値 α_i を計算（α_i = H(..., i) のような形）。

ブラインド化公開鍵を B_i = P_i + α_i·B と定義する。

中継ノード自身（P_i を持つノード）は、到着したオニオン情報を見て「自分向けの暗号を復号するときに、b や α_i に基づく鍵導出」を行い、本来の宛先が自分であると認識し、次の宛先を導ける。

3. 受取ノードだけが知る復号プロセス

受取ノードは自分の秘密鍵 b を持っているので、最終的にチャネルを確立したり、さらにルーティング情報を復号して次に転送したりできる。

送信者や一般の中継ノードには、“B_i は誰に紐づいているのか”が分からず、暗号化された形のノードIDとして見える。

BOLT 11（従来の請求書） では拡張TLVフィールドを追加してBlinded Pathsを載せる提案・実装が進行中。

BOLT 12（Offers） では、そもそもBOLT 11のフォーマット制限を取り払い、より柔軟に請求・支払い情報をやり取りできる仕組みを定義予定。その中でブラインディングキーやブラインド化された経路をやり取りするオプションが用意されます。

Onion Payloadの拡張

LNのオニオンルーティング（Sphinx）におけるペイロードに、新しいTLV（Type-Length-Value）項目を追加して「ブラインド化ホップの暗号情報」や「ブラインド化されたノードの公開鍵」などを含められるようにする。

中継ノードは、自分が“該当するホップ”であれば、そのブラインド化公開鍵を使ってECDHをし、暗号化された次ホップ情報を解読して転送先を知る。