トランポリンルーティングとは？LNの経路探索を委託する仕組み

三倉大司 • 2026年08月27日

一般的にライトニングの送金は送信者自身が受信者までのネットワークの決済経路を探索し、その経路でかかる手数料などを計算した上で送金を行います。

そのため送信者は経路計算に必要な情報（手数料ポリシー・タイムロック・転送可能容量など）を利用するためにライトニングネットワーク（LN）の最新情報を常に同期し続けなければなりません。

一方でモバイルウォレットの場合、24時間アプリを起動し続けて最新情報を同期し続けることは非常に困難です。

仮にモバイルウォレットがLNグラフを同期する場合、前回のグラフ情報の履歴から差分をリクエストする必要があります。アプリの起動時やネットワークの接続時に差分を毎回リクエストする往復自体がオーバーヘッドとなり、帯域を占領してしまうことに繋がります。

また継続的なデータの同期はストレージを圧迫するため、ウォレットを起動する際の差分ダウンロードに時間を要してしまい、LNの送金操作に中々進めないというUX上の問題も発生します。

本稿ではモバイルウォレットが抱えるLNのグラフ同期問題を解決する方法の1つとして「トランポリンルーティング（トランポリンペイメント）」という手法を解説します。

まずは比較のため一般的なライトニング送金についておさらいしましょう。

一般的なライトニング送金：ソースルーティング

送信者がインボイスやゴシップの情報をもとに全ホップ（支払い経路）を事前に決定する現行の方式をソースルーティングと言います。

例としてAからBに送金する様子を考えてみましょう。

上図のように直接AB間でチャネルが繋がっていない場合は、複数のホップを経由して支払いを行います。このとき事前に同期した情報を基にLNグラフを構築し、送信者のA自身が経路の候補を探します。

\(A→N_1→N_2→B\)
\(A→N_6→N_2→B\)
\(A→N_6→N_7→N_2→B\)
\(A→N_5→N_6→N_2→B\)
\(A→N_5→N_6→N_7→N_2→B\)

太線で示されたチャネルはA自身が「チャネル残高の配分」を知ることができる状態にあります。またLN間で伝達される情報（ゴシップ）により細線で示されたチャネルでは容量のみ知ることができます。そのため送金に対して残高不足または容量不足のチャネルは真っ先に除外可能です。

今回の送金で\(A→N_5\)と\(N_6→N_7\)は送金額に対して残高や容量が不足しているとしましょう。

このとき支払い経路の候補は以下の3つに限定されます。

\(A→N_1→N_2→B\)
\(A→N_6→N_2→B\)
\(A→N_1→N_3→N_2→B\)

送金を行う際は経路の中で手数料の計算をして重みづけを行い、安い手数料の経路から送金を試みます。仮に送金が失敗した場合はトライ＆エラーで別の経路で送金を行うことになります。

また特定経路で送金が複数回失敗した場合は、ヒューリスティックス（経験則）により送金経路の優先度を下げることで相対的な送金失敗を防ぐ仕組みになっています。

以上が一般的なソースルーティングの方法です。

加えてMPP（Multi-parts-payments）といい送金額を複数に分割して送ることも可能です。その場合は分割したビットコインそれぞれに対してソースルーティングを行い、最後に一か所に集まることで送金が完了します。

💡

実装間の調整や相互運用の類が求められないためソースルーティング（経路探索アルゴリズム）の仕様はBOLTで規格化されていません。
支払い体験に違いが出るのは各実装により戦略やアルゴリズムが異なるためです。

トランポリンルーティングとは

トランポリンルーティングとは、モバイルウォレットなどのLNのグラフを全て同期しないノードが送金経路の計算の一部を中間ノード（トラポリンノード）に委ねる仕組みです。重要なのは計算経路全体をトランポリンノードに委ねるのではなく、一部のみを委ねているという所にあります。

💡

送金経路の計算を委託したとしてもHTLCにより支払いのアトミック性は担保されるのでトランポリンノードに資金を持ち逃げされるという事はありません。

またトランポリンノードを2つ以上経由することでプライバシーを保ちながら送金をすることが可能です。（トランポリンノードを1つしか経由しない場合については後ほど解説します）

💡

一次情報として名前の由来は見つかりませんでしたが、支払いが飛び跳ねて送金しているように見えるとこから「トランポリン」と名付けられたと考えています。

トランポリンルーティングの送金フロー

例としてAがモバイルウォレットのノードである場合にAからFに送金することを考えます。

トランポリンルーティングの場合、AやFのノードはグラフ全体を同期する必要はなく、自分たちのローカルな領域を同期すればよいので、帯域幅を大幅に節約することができます。経路探索アルゴリズムを実行する際も非常に小さなグラフ上で実行されるため、処理速度が速くなります。

1. インボイスの作成

最初のステップは受信者のFがインボイスを作成することです。このインボイスにはFの近隣にいるトランポリンノードをいくつか含める必要があり、これらのトランポリンノードがFに送金をルーティングします。

例としてFはインボイスに単一のトランポリンノードDを含めることを考えます。

送信者のAはFのインボイスをスキャンしてトランポリンノードのDを含める必要があることを知り、Aは自身の近隣のトランポリンノードCを選択して送金ルートに含めます。

\(A→C→D→F\)

2. 近隣のトランポリンノードに送金する

送信者AはローカルなLNグラフは同期しているのでトランポリンノードCまでの経路を探索することが可能です。（Dまでの経路はLNグラフを保持していないためわからない）

今回はBを経由してトランポリンノードCに送金をします。

\(A→B→C\)

Bは送金の前後を知ることはできますが送金がどこから来て、どこへ向かうのか知ることはできません。また通常のルーティングなのでトランポリンルーティングが行われていることを知りません。

💡

詳しい方向けに補足すると、送信者Aが構築するのはA→B→C間の通常オニオンです。その最終ペイロード（Cが受け取る部分）の中に、C→D→Fへ導くための小さなトランポリンオニオンを埋め込むことでこれを実現します。

3. トランポリンノードが経路探索を行う

送金を受け取ったCはトランポリンノードとして送金をDへ転送する必要があることを知り、経路探索を行います。今回は N1、N2、N3、N4を経由してDへ送金することを考えます。

\(C→N_1→N_2→N_3→N_4→D\)

N1、N2、N3、N4はB同様に送金の前後の情報を知ることはできますが、送金の送り主や受け取り主の情報を知ることはできず、トランポリンの送金であることもわかりません。

4. 再度トランポリンノードが中継を行う

N4からの送金を受け取ったDはトランポリンノードとしてFに送る必要があることを知ります。

💡

送り先がモバイルウォレットである場合はルーティングを行わない性質上、送金の最終受取先であることがわかってしまいます。
つまりトランポリンノードが間に1つしかない場合は、送り主と受け取り主を同時に推定できてしまうため、トランポリンノードは2つ以上挟むことが推奨されます。

今回はトランポリンノードDが経路探索を行い、Eを経由してFへ送金を転送します。

\(D→E→F\)

Eは送金の前後を知ることができるため、Fがモバイルウォレットであれば最終受取人であることがわかってしまいます。しかしこれは通常のルーティングでも同じことが言えるのでトランポリン特有の問題ではありません。（トランポリンノードDにも最終受取人がわかってしまうことが特有の問題）

最終受取人がわかってしまう問題を解決するにはBOLT12で活用されている「Blinded Path」という仕組みを利用して最後の経路をブラックボックス化することで匿名性を確保することができます。

一方で、トランポリンルーティングは最短経路を通って送金が行われているとは限らないことに注意が必要です。例えば以下のオレンジの線の様な最短経路が存在する可能性もあります。

トランポリンルーティングはホップ数が増えることで通常の送金と比べて手数料が高くなる可能性があります。また送信者Aからすると途中のトランポリンノードCやDが行う経路探索で手数料がいくらになるかわからないため送金する段階で余裕を持った手数料を渡す必要があることにも注意が必要です。

💡

トランポリンルーティングにおいて送信者が手数料を多めに見積もりすぎて余ったものについてはトランポリンノードの報酬となります。

トランポリンルーティングの対応状況

2026年8月現在、トランポリンルーティングを行っている実装についても軽くまとめます。

Eclair（Phoenixで利用）	Electrum	LND	CLN	LDK
〇	〇	✘	✘	△（開発中）

LN実装の1つであるEclairは「Phoenix」というモバイルウォレットで、またElectrumという2011年から存在するソフトウェアウォレットでもLNの対応としてトランポリンルーティングを採用しています。

💡

トランポリンルーティングはACINQ社が自社のモバイルウォレットであるPhoenixのために実装を行った機能であるため、PR #829としては存在するもののBOLTの仕様としてマージされていません。
そのため主要なLN実装であるLNDやCLNは2026年8月現在も未対応のままです。

ACINQ社が独自に開発を行うLN実装のEclairについては規新さんの記事にて解説されているのでぜひご覧ください。

おまけ：将来に向けたゴシップ拡張案とは

興味がある人に向けてゴシッププロトコルの拡張案をご紹介しましょう。この提案はトランポリンルーティングの開発には必須ではありませんが、便利な拡張機能と言えます。

まずは課題として現行のゴシップでは「距離N以内のchannel_updateのみ」を要求する手段がなく、近傍だけを同期したい制約ノードでも帯域が無駄になることが挙げられます。

これらの解決として筆者が把握している範囲で将来的なBOLT7拡張案が2つあります。

1つは距離Nより遠いノード由来の更新を中継しないよう依頼するフィルタを取り入れること。

2つ目は距離ベースのゴシップクエリ実装する事です。

通常はゴシップを全同期する運用が前提なのでニーズは狭まりますが、拡張案としては面白い提案だと思ったので書いておきます。

Improving Routing in the Lightning Network with Trampoline Payments

まとめ

トランポリンルーティングは、モバイルウォレットがLNグラフ全体を同期しなくても送金できるよう、経路探索の一部を中間の「トランポリンノード」に委ねる仕組みです。帯域・ストレージの負担を軽減できる一方、ノードを1つしか経由しないとプライバシーが弱くなる、最短経路にならず手数料が上がりやすいという注意点があります。

現状Eclair（Phoenix）とElectrumが対応済みで、LND・CLNは未対応、BOLTの正式仕様にはまだ組み込まれていません。

三倉大司

大学では量子コンピュータのゲート方式を中心に、QAOAを用いた問題解決手法の研究を行っていました。また、GPT をはじめとする Transformer アーキテクチャにも関心を持ち、機械学習モデルの構造理解や応用に取り組んできました。現在は日本ビットコイン産業株式会社の R&D 部門に所属し、主に Lightning Network（LN）関連技術の調査・研究開発を担当しています。特に、LN におけるネットワークのデータ分析やルーティング効率改善に関するテーマに興味を持ち研究しています。