ライトニングネットワークは多くの点で画期的ですが、送る側も受け取る側も同時にノードがオンラインでないと支払いが成功しないというちょっとした不便があります。今回紹介するLightning Rodは、LNの支払いにおけるノード間のバケツリレーを途中で一旦停止して、最終目的地がオンラインになったときに続行させることができるようにする、という提案です。

LIGHTNING ROD

10月にベルリンで開催されたLightning Conferenceで提案されたLightning Rodは、hodl-invoiceという特殊なインボイスを使うことによって支払いが経由するルーティングノードのうちLightning Rod (避雷針)という特殊なもので一時的に支払いを留め置くことで、最終目的地がインボイスの支払い期限までにオンラインになれば支払い時点でオンラインでなくてもよい仕組みを作るものです。

メリットとしては、カストディの形を取らずにオフラインでの受け取りが可能になることが何より大きいです。(LNの普通の支払いの流れに、途中で待つ機能がつくだけのため)
一方でデメリットとしては、受け取り手がインボイスの期限が切れるまでオンラインにならない場合は通常通り支払いが失敗するほか、支払い経路上にLightning Rodノードが存在しなければ使えないことです。これを理由に考案者はウォレットプロバイダーがLightning Rodノードを運用することが好ましいとしています。(考案者自身、Breezというモバイルウォレットの開発者です)

また通常のライトニング支払いとは違い、Lightning Rod経由での支払いの際は送金元と送金先が直接LN外のサービスを使用してシークレットを交換するのでトラストレス性があります。ただ、個人間の場合これは使用感としては少し煩わしいかもしれません。

HODL-INVOICE

名前がついているのでなにか普通と違うのかなと思う方もいるでしょうが、hodl-invoiceが通常のインボイスと違う点はタイムロックの時間が通常より長いことだけです。

ライトニングネットワークの仕組みは過去に説明した通り、各ステップにおいてタイムロックを使用しています。これはつまり、送信側が資金をコミットしてから制限時間内に受信側がプレイメージと呼ばれるデータを提供すると支払いが成功するということなのですが、hodl-invoiceはこの制限時間を通常より長く取ることで「送金側がコミットした資金を受け取れる期限を長くする」というものです。Lightning Rodは、目的のノード(送金先)がオフラインのとき、そこでインボイスを一旦差し止めてオンラインになったときに改めて送付する仕組みになっています。

Lightning Rod以外でも、単純に支払いの最終ステップでhodl-invoiceが活用されれば「注文を受けたが入れ違いで在庫がなくなったので受信側が支払いをキャンセルする」ことや、「ユーザー(送信側)が不正をしたら受信側に没収されるが、不正がなければ返還される供託金」のようなことが実現できます。

単純ですが強力な仕組みなので、他チェーンの資産とLN上のビットコインを交換するサブマリンスワップなどの複雑な処理にも活用できます。

まとめ

自分がライトニングまわりの技術開発で一番感心するのは、シンプルでとてもハッキーな解決策を思いつく開発者が多いことです。例えば、秘密鍵をオフラインの自販機に搭載せずにライトニング払いを受け付けられるようにする暗号学的方法を思いつくような、発明家精神が強い開発者が多いです。(ビットコイン自体の開発者にも多いですが)
制限時間が長いインボイスを使ってオフラインのノードがオンラインになったときに支払いを受け取るLightning Rodも、またhodl-invoiceを利用した返金や供託金の仕組みも、難しい問題に対するシンプルな解決策だと思います。双方が同時にオンラインである必要がある仕組みの代表例は電話ですが、電話よりメール、チャットを好む人が多いことからも同時接続の要件はあまりポピュラーなUXではないと考えられます。

こうした機能が実現できるようになり、ウォレットに実装されていくにつれライトニングそのものの完成度が高まっていくと感じています。