今週、比較的ポピュラーなノンカストディアルライトニングウォレットの１つであるZeusがバージョン0.8をリリースし、様々な機能が追加されました。

その中に非同期ペイメントの受け取りという機能があり、賛否両論を呼んでいます。非同期ペイメントとは送金者・宛先のどちらかがオフラインでも送金が可能になる(オンライン復帰するまで仮決済状態になる)という機能で、ライトニングのUXを改善するものですが、なぜ否定的な意見があるのでしょうか？

それには非同期ペイメントを実現する方法が関係しています。否定派の1人、Matt Corallo氏は以下の指摘をしています：

「最大24時間もの間、未決済のHTLCがネットワークに滞留する機能が広く使われるとライトニング送金のルーティングに悪影響を与える恐れがある」という指摘です。これに対して、最近輝いているSuper Testnet氏は以下のように反論しています：

「資金の拘束時間を加味して手数料を課したいノードがそうすることは別に問題ないではないか」という意見で、こちらもごもっともに感じます。

今日はこの議論を理解するための背景知識としてZeusが非同期ペイメントに使うLSPと"Hodl Invoice"と呼ばれる技術について、かつて日本国内でライトニングの非同期支払いを活用したプロダクトを開発した経験から解説します。

・ライトニング送金と非同期支払いの難しさ

・Hodl InvoiceとLSPによる非同期支払いのアーキテクチャ

・膨大な数のHTLCはネットワークを詰まらせる可能性がある

・Hodl Invoice自体のUXもあまり良くない

・まとめ

ライトニング送金と非同期支払いの難しさ

ライトニングネットワークでの送金は送金者が宛先への経路を選択し、その経路場を送金情報が流れていき、最終的に宛先側から送金者側へと順々に決済されていきます。ここの基本的な仕組みが知りたい方は過去記事やFAQ、ビットコイナー反省会のYouTube企画「サトシ学園」などでご確認ください。

ビットコイン研究所 (Page 1)
ビットコイン研究所Authors

この経路上で情報が伝わる際には通信のために伝える側と伝わる側が両方オンラインである必要があります。現実的な時間で送金を試行するには経路上のすべてのノードがオンラインであったほうが好ましいのもわかると思います。

ところが、一般人が一時的にオフライン環境にいることは珍しくなく、モバイルアプリは電池節約のため常時オンラインであり続けることが難しくなっています。「全員がサーバーにノードを立てる」という解決策はもちろん非現実的です。そこで非同期支払いというものの需要が発生します。

送金者は宛先のユーザーがオフラインでも送金を実行できれば、あとは通知を受け取った宛先ユーザーがオンラインに復帰・決済し、送金者もその後にオンライン復帰して自身で決済を完了させればよい、という流れになればぎこちないながらもユーザーを困惑させるエラーの原因が１つ減ります。実際、送金アプリで相手がオンラインでなければ送れないものなんて普通の人は使いませんからね。

Hodl InvoiceとLSPによる非同期支払いのアーキテクチャ

この機能を実現するアーキテクチャとして、Zeusは独自のLSPとHodl Invoiceという技術を組み合わせることを選びました。

LSP (Lightning Service Provider)とは近年のノンカストディアル・モバイルLNウォレットが利用することが多い設計で、具体的にはエンドユーザーのウォレット(ノード)がウォレット開発者側のノードを経由してライトニングネットワークつながるアーキテクチャを採用することで通常のライトニングノードが利用できない機能を提供するものです。その機能の代表例がまさに非同期支払い(オフラインでも支払いを受け付けられる)などです。

また、Hodl Invoiceとは宛先が決済を保留することを言い、先述したライトニング送金の流れを一時的に止めることを言います。名前からは特殊なインボイスの形式がありそうなイメージをしてしまいやすいですが、あくまで決済のタイミングを先延ばしすることです。

つまりZeusが採用した方法とはZeusのLSP側で宛先ユーザーのオンラインが確認できるまで送金のルーティングを保留し、宛先ユーザーがオンライン復帰した際に転送と決済を完了させるという仕組みです。

膨大な数のHTLCはネットワークを詰まらせる可能性がある

ここで問題となるのが、仮にHodl Invoiceを使った非同期支払いが非常に流行したとき、ライトニングネットワークの送金中継能力に広範な影響を与えてしまう懸念です。

冒頭で紹介したMatt Corallo氏は仮にネットワーク上の多くの送金がこのように数時間以上決済を先延ばしされてしまうと良くないと言っています。ではなぜ良くないのでしょうか？

ライトニングチャネルは二者間のマルチシグアドレスから双方へと決済済みの金額を送金するトランザクションをオフラインで保持しているものです。送金の中継時、決済されるまではここに「HTLC」という出力を追加して未決済の金額を表現しますが、トランザクションサイズがあまりに大きくなるとオンチェーンで強制決済できないため１つのチャネルで保持可能なHTLC数に上限があります。また、強制決済時のコストが嵩むリスクを鑑みてこの上限を厳し目に制限しているチャネルも多いです。

仮にライトニングネットワークの送金の多くが６時間Hodlされてしまうと、様々なチャネルで未決済のHTLCが多数滞留し、新たなHTLCを作ることができないという状況が考えられます。こうなると資金はあっても新たな送金を中継することができず、ライトニングが機能不全に陥るという懸念があるのです。

逆にSuper Testnet氏の反論はこのリスクも加味した手数料水準になれば問題ない、あるいは長期間の未決済送金を受け入れるノードが十分な数存在すれば(受け付けないノードも存在すれば)結果的に問題ない、というものです。「ないほうがベター」「あっても市場原理が解決する」という２つの見方の違いで、個人的にはどちらも正しいような気がします。いずれにせよ、現状のライトニングネットワークはおびただしい数のHodl Invoiceには対応できませんし、もし流行するのであればこれから中継ノード運用者たちが許容リスクに応じて長時間未決済になりうる送金に対して中継サービスを提供していくことになりそうです。

ちなみに私が開発したPaddleというオークションサービスではこの問題が入札妨害につながる可能性を検討して、常時保持される未決済送金がオークション１つあたり１つまでになるように制限していました。Hodl Invoiceの利用が増えた場合にルーティングノードが運用面で最適化できる部分も多量に残っていると想像しています。

Hodl Invoice自体のUXもあまり良くない

ここからは余談に近いですが、Hodl Invoiceという技術自体で実現できる非同期支払いや仮決済は活用の幅が広く、非常に便利なものです。例えばクレジットカードの仮決済のようにデポジットを取ったり、オンラインショッピングでも在庫確認が取れるまで仮決済の状態で保留できて宛先側から無料でキャンセルできるのは非常に便利です。

しかし、仕組み的に送金者側のウォレットからは「普通の送金がなぜか途中でひっかかって決済に時間がかかっている」のか「Hodl Invoiceによる決済保留中」なのかということが一切わかりません。ストア等のWebアプリ側では仮決済を受け付けた時点で表示を変えて対応できますが、ウォレット内では送金が完了していない旨が表示されることが多いです。

例えばカストディアルウォレットの中にはDoS攻撃対策として仮決済状態のHTLCを１ユーザーあたり１つまでという制限を設けているものもあり、このようなウォレットのユーザーは送金をHodlされると決済されるまで次の送金ができないという問題に直面します。また、ウォレット内の表示も送金が完了しない原因がわからないため親切にはなりません。

このようにHodl InvoiceにはUX面での課題があり、将来的にどのように解決していくべきかまだまだ考え抜かれていない側面があります。なにせ裏技的なテクニックに名前をつけて利用しているだけなので…。

具体的にはインボイス自体に「この送金はHodlするかも」のようなフラグを立てるなどすればウォレット側での対応もしやすくなるため、そのような規格の誕生とウォレット側での対応が待たれます。

まとめ

Hodl Invoiceはライトニングネットワーク上の送金決済を宛先側で保留(先延ばし)できるテクニックで、デポジットを受け付けたり宛先の事情で返金しないといけないような送金を数時間～数日ホールドするのに便利な裏技です。しかし、仮に今日大量のライトニング送金がホールドされてしまった場合、多数のチャネルで新たな送金を中継することができなくなり、機能不全に陥る可能性もあります。

唯一の解決策はルーティング市場が環境の変化に適応していくことで、チャネルで保持できる期限を短く設定したり、あるいは長く設定したチャネルの手数料率を上げることでHodl Invoiceの送金が使えるチャネルを限定していく形になると考えられます。Hodl InvoiceにはUX面でも課題がありますが、非同期支払いを含めて非常に魅力的なユースケースを提供してくれるテクニックなので今後使いやすく発展していくことはライトニングにとって好ましいことだと感じます。