皆さんはBoltzを利用したことはありますか？
Boltzは「Submarine Swap」と呼ばれるオンチェーンとオフチェーンのスワップを実行できる代表的なサービスとして、多くのユーザーに支持されています。公式Webサイトからは簡単なステップで利用できるほか、MuunやMisty Breezといったウォレットでは、バックエンドとして採用されていることでも知られています。
Submarine Swapを知らない方向けに簡単に説明をすると、チャネルを新たに開閉することなくLightning上の残高とオンチェーン上の残高をアトミックに交換することができる仕組みです。
何かと利用機会の多いBoltzですが、Boltzの利用にあたって「自分の資金が本当に奪われないのか」というトラストレス性は気になるポイントだと思います。
Boltzの公式ドキュメントでは、Boltzは「異なるビットコインのレイヤー間をつなぐノンカストディアルなブリッジ」として紹介されています。つまり、プロトコルの設計上「Boltzを信用しなくても成立する（＝トラストレスな）構造」である、という立場が示されています。
本稿では、このBoltzが実際にどこまでトラストレスと言えるのかを、仕組みの観点から整理して解説します。
なお、「トラストレスとは何か」自体が気になる方は、以下の過去記事をご参照ください。
押川 拓夢
そもそもSubmarine Swapとは何か？
本章は、Submarine Swapの仕組みをまだ知らない方向けの導入です。すでにご存じの方は、次章以降の本題から読み進めていただいても構いません。
Submarine Swapは、オンチェーン上のBTCとLightning上のBTCを交換するための仕組みで、広い意味ではAtomic Swapの一種に分類できます。
Atomic Swapという名称は、「両方の取引が成立するか、あるいは両方とも成立しないか」のいずれかで、途中で片方だけが実行されるような中途半端な状態にならないというアトミックな性質に由来します。
そして、Atomic Swapの中でも片側がオンチェーン取引、もう片側がLightningネットワーク上の支払いとして構成されるものを、一般的にSubmarine Swapと呼びます。
「Submarine Swap」オンチェーン→ライトニングの場合
手元にオンチェーンのBTCがあり、それをLightningの残高に移したい場合、この種の交換は一般的にSubmarine Swapと呼ばれます。
ここでは例として、AliceがオンチェーンBTCをBobに送金し、その見返りとしてBobからLightningで支払いを受け取る、Submarine Swapの流れを説明します。
① Aliceは秘密値（プリイメージ）を生成し、そこからハッシュ値を計算して、そ のハッシュを条件とするLightningインボイス（請求書）を作成します。
② Bobは受け取ったインボイスをもとに、オンチェーン側でHTLCの受け取り条件を満たすアドレス（スクリプト）を作成し、Aliceに提示します。
このアドレスの資金は、Bobがプリイメージを提示しない限りBTCを使えない仕組みとなっている。
③ AliceはBobが提示したオンチェーンのHTLCアドレスにBTCを送金し、資金をロックします。この時点では、Bobはまだ自由に使える形で受け取れておらず、HTLC条件下で拘束されています。
④ Bobはオンチェーンでのロックアップを確認した後、Lightningでインボイス宛てに支払いを実行します。Aliceはこの支払いを受け取るためにプリイメージを公開（提示）する必要があり、その瞬間にBobにもプリイメージが伝わります。
⑤ Bobは入手したプリイメージを用いて、オンチェーン側のHTLCを解錠し、ロックされていたBTCを自分のアドレスへ引き出します。これにより、オンチェーンBTCとLightning残高の交換がアトミックに成立します。
このため、Aliceが支払いを受け取るためにプリイメージを公開すると、その情報がBobにも伝わり、BobもオンチェーンのHTLCを解錠できます。結果として、プリイメージの公開をトリガーにして、双方がそれぞれのBTCを受け取れる構造になっています。
仮にBobからのライトニングペイメントが失敗した場合、タイムロックという仕組みにより一定時間が経過するとRefundトランザクションというものを作成してBTCを取り戻すことができます。
「Reverse Submarine Swap」ライトニング→オンチェーンの場合
手元にLightningの残高があり、それをオンチェーンのBTCに移したい場合、この種の交換は一般的にReverse Submarine Swapと呼ばれます。
ここでは例として、AliceがLightningで支払いを行い、その見返りとしてBobからオンチェーンBTCを受け取るReverse Submarine Swapの流れを見ていきましょう。
① Aliceは秘密値（プリイメージ）を生成し、そのハッシュ値をBobに共有します。
② Bobは受け取ったハッシュ値を条件として、Lightningインボイス（請求書）を作成します。
③ さらにBobは同じハッシュ値を用いて、オンチェーン側のHTLCアドレス（スクリプト）を作成します。このアドレスの資金は、Aliceのプリイメージを提示しない限り引き出せない仕組みになっています。
④ AliceはBobから受け取ったインボイス宛てにLightningで支払います。ただしこの時点では、Bobはプリイメージをまだ知らないため、支払いを最終的に受け取ることはできません。
⑤ Bobはオンチェーンで、先ほど作成したHTLCアドレスにBTCを送金し、資金をロックします。
⑥ オンチェーンでBTCがロックされたことを確認したAliceは、プリイメージを公開（提示）してHTLCを解錠し、オンチェーンBTCを受け取ります。
⑦ 公開されたプリイメージをBobが取得し、それを用いてLightning側の条件を満たすことで支払いを受領し、取引が完了します。
今回の場合、仮にBobからオンチェーンにBTCをロックされなかったとしても、AliceはRefundトランザクションを作成する必要はなく、ライトニングのHTLCの期限が過ぎると自然にBTCは返ってきます。
Boltzがトラストレスな理由
Boltzのフロントエンドを確認する
前章では、Submarine Swapの仕組みについて整理しました。では、なぜBoltzは「トラストレス」と言えるのでしょうか。 まずはBoltzにてSubmarine Swapを行う際の取引画面をご覧ください。
左はSubmarine Swap（オンチェーン → Lightning）、右はReverse Submarine Swap（Lightning → オンチェーン）を実行する際の、BoltzのWeb App（フロントエンド）の画面です。
- Submarine Swapでは「インボイス（またはLNURL）」の貼り付け
- Reverse Submarine Swapでは「BTCアドレス」の入力
が求められます。
つまり私たちは、インボイスやBTCアドレスを入力するだけでBoltzを利用しており、外部ウォレットを接続して操作しているわけでも、プリイメージを直接入力しているわけでもないことが分かります。
このWeb appは、アドレスの確認や支払いの検証、Reverse Submarine Swapではプリイメージの管理を行うなどの機能をユーザーに代わり実行します。さらにWeb appは、オープンソースとして公開されているため、コードを監査することで、その挙動が信頼に依存しない（トラストレスな）設計になっているかを確認することができるということです。
加えて、こちらのWeb appは自作することもでき、その場合はBoltzのバックエンドと直接やり取りしてSwapを実行することも可能です。
BoltzExchange
Web appがどのような機能をしているか？
Web appがどのような働きをしているのか見てみましょう。
BoltzのSubmarine Swap（オンチェーン → Lightning）は、概ね上図のようなフローで進行します。
ユーザーが直接操作するのは、赤色で示した 「インボイスの貼り付け」と「オンチェーンでの送金」の2点のみです。それ以外の処理は、Web appとBoltz Backend、オンチェーン、そしてLightning Network上で自動的に進められています。
Web appの主要な役割は以下の3つです。
- 主要な秘密情報を保持する (Refund 用秘密鍵、Taproot / MuSig2 用秘密鍵)
- これらの秘密情報は Backend側には渡さず、Web app（＝ユーザー側）で保持します。
- Boltz Backend が返すデータを検証する
- Backendが提示したBTCアドレス（スクリプト）が想定どおりかを検証した上で、ユーザーに提示します。
- Backendから受け取った情報（例：プリイメージ／ハッシュ条件）に基づき、Lightning側の支払いが正しく成立しているかを確認します。
- ライトニング送金が成功したことを確認してからマルチシグの署名を提供
- Web appは、提供されたプリイメージがハッシュ条件と一致することを検証した上で、必要な署名を生成します。
このように、Web appは単なるUIではなく、ユーザー側で秘密鍵を保持しつつ、Backendの出力を検証し、条件成立時にのみ署名を提供する検証・制御レイヤーとして機能します。
結果として、プロトコル設計とWeb appの検証・署名ロジックが組み合わさることで、Boltzは原理的に「Boltzを信用しなくても成立する」すなわちトラストレスな構造だと言うことができるのです。
Reverse Submarine Swapについても見てみましょう。
Reverse Submarine Swap（Lightning → オンチェーン）でも、ユーザーが直接操作するのは 赤色で示された「BTCアドレスの入力（貼り付け）」 と 「Lightningでの送金」 の2点のみです。
このときオンチェーンでBTCを受け取る構成として、Taprootのマルチシグ（MuSig2）を用いているのは、従来のオンチェーンHTLCをスクリプトで解錠して送金する場合に比べて、手数料（オンチェーンコスト）を抑えやすいためです。実際には、通常は協調的に署名してKey Path Spendで完了させることで、オンチェーン上の負担を軽くできます。
Taprootの仕組みをより詳しく知りたい方は、以下の動画も参考になります。
まとめ
Boltz が「トラストレスに利用できる」と言える本質は、Boltz というサービスを信用する必要があるからではなく、信用しなくても成立するように設計されたプロトコルと実装にあります。
また、Submarine Swap は、オンチェーンと Lightning を同一のプリイメージ（ハッシュ条件）で結び付けることで、「両方の取引が成立するか、あるいは両方とも成立しないか」というアトミックな性質を実現しています。これにより、片側だけが実行されて資金を失うような状態を原理的に防いでいます。
ここで、Boltz を利用する際のWeb app は、単なる操作画面ではありません。ユーザー側で秘密鍵を保持し、バックエンドが提示するアドレスやスクリプト、インボイス、プリイメージを検証したうえで、条件が正しく満たされた場合にのみ署名を提供する、検証・制御レイヤーとして機能します。
この Web app はオープンソースとして公開されており、誰でもコードを確認・監査・自前で実行することが可能です。つまり Boltz のトラストレス性とは、「Boltz を信頼すること」ではなく、「検証可能なコードと暗号学的プロトコルに基づいて取引を行うこと」によって成立しています。
