Mutiny WalletがE-cashを使ってライトニング決済のオフライン受取りを実現するアプローチを発表
世間ではアダルトコンテンツに対するクレジットカード決済からの締め出しが進んでいます。今週も日本のファンクラブサイトがVISA・Mastercardを使った決済を提供できなくなるなど、主にTwitter上で大きく話題になっていました。
もちろん、コンテンツ事業者もやられっぱなしではありません。もう1つ今週の発見として、日本でコンテンツ販売を手掛ける大手の1社であるFC2(法人自体はアメリカに所在)がいつのまにかライトニング決済に対応していたというものがありました。

まだまだユーザーが少ないライトニング決済ですが、多くの人がライトニングウォレットを手軽に持つことができればこのように対応するサービスも増えてくると思われます。そのためにはカストディアルウォレットの普及が一番手っ取り早いですが、日本ではカストディ規制もありなかなか進んでいません。
ノンカストディアルなライトニングウォレットの普及にとって一番の障壁は「オフライン受取」(非同期支払い)に関する挙動です。この問題への取り組みは昔から存在していますが、今日はMutiny Walletが発表したE-cashを応用する新しい方法について解説させていただきます。
・モバイルウォレットでのオフライン受取の問題
・Mutiny Walletが提案する、E-cashを併用するアイデア
・そもそもノンカストディアルではない
モバイルウォレットでのオフライン受取の問題
冒頭で述べたとおり、ノンカストディアルなライトニングウォレットはライトニングノードを内蔵しているため、送金の受取時にオンラインである必要があります。(これは送金と引き換えにプリイメージを返すことで決済するLNの特性上どうすることもできません)
しかし、モバイル上ではバッテリー管理の問題からアプリが立ち上がっていなければライトニングノードがオフラインになってしまいます。つまり、受取時にアプリを開いていないと送金を受け取ることができません。
この問題へのアプローチはいくつか考えられますが、一般的なものとしてLSP型のウォレットが採用するものに「あらかじめプリイメージハッシュをいくつかLSPに渡し、LSPがHodlインボイスを使って送金を仮決済の状態で保持する」というものがあります。この場合、ユーザーがHodlインボイスの期限までにオンラインに復帰すればLSPとの間で同じプリイメージによる送金を行うことで実質的にオフライン受取が実現できます。また、このソリューションであればLSP側でLightning Addressを設定することも可能です。
去年このソリューションを導入した代表的なウォレットにZeusとBlixtというものがあります。しかし、Hodlインボイスを使う設計が送金のタイムアウトによるチャネル強制閉鎖を招きやすく、まさにMutiny WalletとZeusの間で揉めていました。当時の記事はこちらです:
そこでMutiny WalletはHodlインボイスを利用しない新しい方式でのオフライン受取を実装しようと動いたようです。
Mutiny Walletが提案する、E-cashを併用するアイデア
本稿にもたびたび登場しているE-cashですが、おさらいすると単一主体またはフェデレーションが運用するサーバー内で、秘匿化されたトークンをユーザー間でやり取りできるというものです。実際の流れとしては、サーバーにビットコインを預け、その預り証となるE-cashトークンをユーザー間で取引し、サーバー外で使用したい場合に出金するという形になります。
いくつかE-cash関連の記事をおさらい用にリンクしておきます:

さて、今回Mutiny Walletが提唱したE-cashを利用したライトニングのオフライン受取の流れを見ていきましょう。
①受取ユーザーがE-cashサーバー、LNURLサーバーに登録
このとき、ブラインド署名を使ってE-cashサーバーとLNURLサーバーの間で特にデータの共有をする必要がなく、理論上は2つのサービスを分離することもできるようです。
②送金者がLNURLサーバーに問い合わせ、E-cashサーバーに送金
ここは通常のLightning Addressと同じです。また、Hodl Invoiceを使わないため、送金者の視点ではここで送金が完了します。
③E-cashサーバーは受取ユーザーの公開鍵でロックされたE-cashトークンを作成
ここからがE-cash特有の機能になります。E-cashトークンには使一種のスマートコントラクトのように用条件を記述することができ、この機能を使ってライトニング送金とのアトミックスワップなどができます。
今回はその機能を使って、受け取った送金額と同額のE-cashトークンを、受取ユーザーの公開鍵でしか支払えないトークンとして保存します。
④受取ユーザーだけがE-cashサーバーに接続して当該トークンをClaimできる
最後に受取ユーザーはE-cashサーバーに接続して当該トークンをダウンロードします。受取ユーザーはこのトークンをいつでも使って送金ができるため、受取はここで完了したことになります。
E-cash関連の機能をよりふんだんに活用していますが、2月に紹介したCashu Addressにも発想は似ていますね。
そもそもノンカストディアルではない
このスキームにケチをつける点があるとすれば、それはE-cashをノンカストディアルなものと見なすかどうかと、LNURLサーバー・E-cashミントに対するトラストの度合いです。
E-cashはノンカストディアルではなく、必ずカストディを伴う仕組みのものです。もちろん、フェデレーションによるカストディは場合によっては法的にはカストディにあたらない場合もあるでしょう。しかしそれはあくまで法的な側面であって、自身で保有しているわけではないことに注意が必要です。単一主体よりはフェデレーションのほうが安心できるかもしれませんが。
また、今回のスキームでLightning Addressサーバーが送金を横領しようとしたり、E-cashサーバーが送金を横領しないことはトラストする必要があります。これは第三者にLightning Addressサーバーの運用を委託したり、カストディを任せることと同じ程度のトラストであるといえるでしょう。(というか、同じことです)
もちろんLSP型のノンカストディアルウォレットにもトラストが発生するポイントは多少存在するので完全な白黒で論ずるのはあまり生産的な話ではないと感じますが、E-cashを使ってライトニング送金を受け取るのがノンカストディアルだとは考えないほうがよいと思います。
しかしながら、オフライン受取のUX面での課題やHodlインボイスを使うことによるライトニングネットワーク自体への負担を大きく軽減するソリューションであり、非常によくできていると思います。
まとめ
・LSPとHodlインボイスを用いたオフライン受取(非同期支払い)はライトニングネットワークへの負担が大きく、チャネルの強制閉鎖などにつながりやすい
・Mutinyが開発した手法はE-cashフェデレーションで送金を受け取り、E-cashトークンを受取ユーザーの公開鍵でロックする方法
・ノンカストディアルではないがフェデレーション型のカストディも選べて、UX面での課題や強制閉鎖の問題を大きく軽減する有用なソリューション
次の記事
読者になる
一緒に新しい世界を探求していきましょう。

ディスカッション