ライトニング決済は数年前と比べ安定性も大幅に改善しており、普通の支払いや送金が失敗するなどのトラブルはかなり減ったように思います。ところがインターネット上での支払いの少なくない割合を占める「サブスクリプションの支払い」にライトニングを使う例は全くと良いほど出てきていません。ライトニングの仕組みとの親和性が低いためです。

これに対してBOLT12とセットで提案されたRecurring Paymentsという規格がライトニングにサブスクリプションをもたらす！と数年前に話題になりました。今日はBOLT12のLndへの導入が年末～来年頃に見込まれる中、ついにライトニングがサブスクリプションの支払いに使われるようになるのか？という疑問を掘り下げていきます。

・ライトニングでサブスク決済が難しかった理由は「毎回手動で支払う必要があるから」

・BOLT12には当初はRecurring Payments (繰り返しの支払い)という仕様が含まれていた。これはウォレットが定期的に特定の金額のインボイスを自動的に取得して支払うというものであった。

・Recurring PaymentsはBOLT12から取り除かれたため、BOLT12の普及で自動的に使えるようになるわけではない。しかし、BOLT12の普及がRecurring Paymentsの実現を強力に後押しするのは間違いなく、おそらくウォレットがBOLT12に対応し始めると短期間でRecurring Paymentsの普及も進むと予想される。

今まで困難だったサブスクリプション

ライトニングネットワークの支払いは基本的に送金先がインボイスを発行するところから始まるため、一方的にビットコインを送りつけることはできません。

Keysendという裏技的な送り付け方でなら一方的に送金することはできますが、支払い関連でトラブルになりやすい仕組みなので一般的な支払いには推奨されません。

ということは仮に毎月課金されるサービスがあったら、毎月の支払期日の直前にインボイスをユーザーがメールなどで受け取って支払わなければなりません。手動の支払いになってしまうため誤って期日を過ぎてしまったり、サービス側からすると解約率が上がりやすいという問題があります。

このため、ライトニング決済を採用する事業者(主にライトニング関連のサービス)はサブスクリプションの代わりに前払い式(チャージ式)を支払うか、面倒を前提に定期的にインボイスを支払ってもらっています。(大抵は前払い式と従量課金です)

問題は定期的な支払いだとしても毎回ユーザーが手動でウォレットを開き支払う必要があることです。ということは、それを自動化できればサブスクリプションが実現できる！というのがBOLT12の仕様に含まれていたRecurring Payments (繰り返しの支払い)という規格です。

BOLT12に含まれていた「繰り返しの支払い」

BOLT12 Offersはライトニングの共通仕様を定めたBOLT (Basis of Lightning Technology)への大きな追加として各ライトニング実装に徐々に導入されています。一番時間がかかっている最大手Lndにも年末から来年にかけて導入される予定で、その後アプリケーションでの普及が進むものと考えられます。

BOLT12の目的は"Offers"と呼ばれる短い固定のデータを元にウォレットがライトニングノードに直接インボイスを求めることができることです。これまではメール、オンラインストア、チャットアプリなどでやり取りしていたライトニングのインボイスを、ウォレットがライトニングネットワーク上で直接求めることができれば送金者側から自発的な支払いができるほか、ウォレットが自動的にインボイスを取得して支払うこともできるようになります。

これまで何度も本稿で取り上げているLNURL-Payなどと目的がかぶるのですが、差別化ポイントとしてはLNURLだとHTTPリクエストを捌くサーバーをノード側が立てる必要があるのに対し、BOLT12はノード自体の機能なので誰でも簡単に利用できるという点があります。(逆にウォレットはHTTPリクエストよりは若干複雑なロジックを実装する必要がありますが)

ちなみにLNURL / Lightning Addressを使った繰り返しの支払いはCoin Cornerが提供していますが、あまり使われている様子はありません。

BOLT12の初期の段階にはRecurring Paymentsという仕様が含まれており、これは金額、支払い間隔を併記したBOLT12 Offerを読み取るとウォレットがその間隔でその金額のインボイスを取得してくる、というものでした。

BOLT12 Offerにどのように記載するかという点以外はウォレット内部の動作であるため、これは後に簡単に拡張できるためBOLT12の仕様からは外されました。

上記のCoin Cornerの例も、単純にCoin Cornerが間隔と金額を記憶してくれているだけなので特に特別な仕様がなくても利用できます。ただし、やはり受け取る側が指定した金額・間隔と異なる場合にトラブルに発展しやすいため、将来的にはこれらを指定する規格が求められていくと予想されます。

BOLT12から外されたが、シナジーはある

上で説明した通り、Recurring Paymentsは今のBOLT12には厳密には含まれていない発展的なプロトコルです。しかしLNURLでも利用できるように、インボイスを取得してくる手段とは全く別個の問題であるため、BOLT12とは独立して普及を目指すことができる性質のプロトコルでもあります。(特に支払いを受け付ける事業者はLNURLサーバーを立てる層と一致するので、LNURL+Recurring Paymentsにも一定の需要があるかもしれません。)

BOLT12が普及すればもはやLNURLサーバーを立てる必要がなくなり、誰でもRecurring Paymentsを受け付けることができるようになるでしょう。そうなればOfferにどのように金額・間隔の情報を追加するかという議論がまとまるのも時間の問題と考えられます。Offerで簡単にサブスクリプションの支払いを受け付けることができるというのはDeveloper Experienceの側面からも後押ししたいです。

また余談ですが、個人的にはサブスクリプションというのは忘れて課金している人がヘビーユーザーの分の料金を負担している形なので本当にフェアな課金方法ではないと感じる側面もあります。必ずしもライトニング決済が「世直し」をする必要はないと思いますが、ライトニング決済の面白さは従量課金性の実現しやすさ(少額決済のしやすさ)にもあると思うので、いつかサブスクリプションに代わって従量課金が主流になるときが来るとしたらそのとき本領発揮するのかもしれません。