エンドユーザーでもライトニングネットワークの利用時に必ず目にするインボイス。現行の形式のかゆいところに手が届く、新しいインボイスの仕様が提案されています。今日はライトニングの新しいインボイスの仕様として提案されているBOLT12について見ていきます。

BOLTとは

Basis of Lightning Technology (BOLT)とは、ライトニングネットワークの仕様を定めた仕様集です。現時点ではBOLT0～5と7～11が定められています。(6番は7番に置き換えられて欠番です)現在のインボイスの形式を定めたBOLT11の欠点を改善するものとして、今回紹介するBOLT12が提案されています。

現在のインボイスの不自由な点

BOLT11に定められている現在のインボイス形式は、送金を受け取りたい方がインボイスを発行して、送金する側がそのインボイスに従って送金し、送金が完了するとインボイスの作成に使用されたプリイメージというデータを受け取って確認できるというものです。本コラムでもおなじみですね。まず、このインボイスの形式には使っているうちにわかってきた不自由な点がいくつかあります。例えば、インボイス自体はQRコード表示などに便利なbech32という形式でエンコーディングされていますが、これに問題が発見されたり、LN自体で(後述の支払ってほしいインボイスを送りつける際など)bech32のデータをやり取りする際に厄介になっているので、変えようという意見があります。また、通常のインボイスは安全に使えるのは1度きりで、毎度発行する必要があり、使い回せません。今のところ実際の運用ではLNURLというウォレットの仕様群で解決するのが主流ですが、ライトニング自体の公式の仕様ではないため、ウォレットやウェブサイトなどが対応していないと利用できません。他にも、今年発覚したLNDの脆弱性の防止策としてプリイメージに加えてpayment_secretという識別情報を使う話がありましたが、これもインボイス自体が第三者の手に渡る場合は機能しません。インボイス自体の署名も、証明する際にインボイスの全体を開示する必要があります。不自由な点はそれ以外にも挙げられていますが、BOLT12は新しいインボイスの仕様を使ってそれらを改善する提案です。

BOLT12 "OFFERS"とは

ライトニング払いをしたい買い手を「ユーザー」、ユーザーに何かを売った売り手を「マーチャント」とします。「オファー」はBOLT12が指定する、インボイスの発行または支払いを要求するためのリクエストを送るためのデータです。

オファーはSphinx.chatなどで使われる、全てのライトニングノードが対応している既存のTLVメッセージと同じエンコードがされています。

BOLT12には2種類の支払い方式があります。１つ目は、ユーザーがマーチャントに対して支払う方式です。このとき、マーチャントは「オファー」を提示し、ユーザーはそれを読み取ります。ウォレットがオファーの通りにインボイスをリクエストし、返送してきたインボイスを支払います。
このときオファーは「インボイスを出すよ」というオファーです。

ここだけを見ると、BOLT11のOffer機能はLNURL-payに非常に似ています。LNURL-payはサーバーからインボイスを取得するためのコードで、支払うユーザーは対応したウォレットで読み取ることで通常のインボイスと同様にウォレット内から支払うことができます。

もう１つの支払い方式は、マーチャントがユーザーに支払う方式です。例えば返金だったり、ライトニングATMに使えます。マーチャントがユーザーのために生成した「金額つきオファー」、返金の場合は「金額と元のインボイスを指定したオファー」を表示し、ユーザーはそれに従ってマーチャントにインボイスと、必要なら元のインボイスを支払った証明を送ります。マーチャントはこれを検証し、インボイスを支払うことで返金します。
このときオファーは「返金(送金)するよ」というオファーです。

これもマーチャントにインボイスを送りつける点でLNURL-Withdrawに似ていますが、過去に支払ったインボイスの返金に便利な機能 (支払った本人であることを確認する機能)が追加されています。

BOLT12では、「インボイスを発行するよ」というオファーからインボイスをリクエストする際に公開鍵を添付することで、後ほどそのインボイスをリクエストしたのが自分だということを証明できます。
通常のプリイメージを使った送金の証明は「支払いがされたことの証明」しかできず、支払い完了後に第三者がプリイメージを利用して返金を求めることができる本人性の証明に関する問題がありましたが、これを解決します。さらに、BOLT12のインボイスに対する署名はマークルツリーになっているので、争議の際にインボイス全体のデータ(金額やメモなど)を開示せずに特定の部分だけを開示して証明できるため、プライバシーも守られます。

BOLT12でなにができるのか

一見、BOLT12で実現できる機能はLNURL群で既にできることのように感じるかもしれませんが、LNURL群より優れている点があります。それは、ライトニングネットワーク自体でインボイスをリクエストできるため、データのやり取りがライトニングネットワーク上で完結することです。つまり、特定のウォレットやライブラリを利用せずとも使えるのです。

春にTLVShopという実験がありました。これは、ライトニングノード間のTLVというメッセージだけでオンラインショップが作れないか？とのもので、ノード間のTLVメッセージを利用して商品の配送先を伝えるというところで名前がついた、実用性というよりはコンセプト重視の実験でした。BOLT12はTLVメッセージを活用し、似たような形でライトニングノードの機能をよりEコマースに寄せるものだと言えるでしょう。
まとめ

・BOLT12 = "Offers"は、ライトニングネットワーク上のTLVメッセージを利用してインボイスをリクエストしたり、返金・送金をリクエストする仕組み・現在のBOLT11インボイスへの不満(エンコードの問題、印刷するなどして使い回しできない、プリイメージだけで本人性を証明できない)から生まれた・LNURL-pay, LNURL-withdrawを更に強化したような機能が、ライトニングノード自体で利用できるようになる