普通のライトニングユーザーはライトニングノードの実装がいくつもあることをご存知ないかもしれません。代表的なものではLnd、c-lightning、Eclair、Electrum、Ptarmiganなどそれぞれの実装に特徴があり、共通点はライトニングのプロトコル(BOLT)への対応のみです。

共通規格以外の部分については各実装に委ねられているため、同じ実装間でしか使えない機能があったり、複数の実装に対応するアプリケーションの開発が難しかったり、不可能なことがあるという弊害があります。

今回の記事はその例として、LNURL-authの普及が阻まれていること、細かい違いがロックインに繋がっていることを解説します。

LNURL-AUTHとは

LNURL-authとはライトニングノードが公開鍵認証によってパスワードレスにウェブサイト等にログインするための規格です。LNURL-authに対応したウォレットにLNURLをコピーペーストするか、QRコードを読み取ることでワンボタンでログインすることができます。

裏ではサイト(URL)ごとに異なるキーペアが導出され、そのキーペアもログインにしか使用されないため匿名性の高いものとなっています。

スマートコントラクト界隈でのMetamaskサインインとほぼ同様のものですが、URLによってサインインに使用する鍵が違うため異なるサイトのアカウントを結びつけることができず、プライバシー面でのメリットがあります。

BIP39とAEZEEDという違い

一般的なビットコインウォレットはシードフレーズを元にたくさんの秘密鍵を生成することで大量のアドレスを扱うことができます。典型的なビットコインウォレットはBIP32階層的決定性ウォレット (HD Wallet)という規格を使っており、BIP39のシードフレーズ12/24単語から生成される「マスター秘密鍵」というものからBIP44に沿ってm/<用途>'/<チェーン番号>'/<ウォレット番号>'/<お釣り用or入金用>/<アドレス番号>という書式のパスを指定することで鍵を導出する具体的な方法を定めています。合わせて使うとシードとパスを控えれば同じアドレスが導出できる共通規格です。

さて、ライトニングノードにもビットコインウォレットの機能が付属しており、チャネルを開く際などにオンチェーンのアドレスを発行する必要があります。ところがライトニングノードの中でもLndはBIP39ではなく、BIP39にバージョン情報とシード誕生日という概念を加えたaezeedという方式を使用しているのでBIP39と互換性がありません。

LNURL-authはURLごとに異なる鍵を生成する方法として、URLから値a,b,c,dを算出し、BIP32・44に従ってm/138'/<a>'/<b>'/<c>/<d>という形式で導出します。したがって、元は同じシードを使用していても、Lndとそれ以外の実装ではシードの形式が異なるため生成される鍵が一致しません。ずっと同じ実装を使用する場合は実用上問題がなくても、移行したい場合などにポータビリティが担保されません。

さらに問題は続きます。

署名方法とLNURL-AUTH

Lndはメッセージへの署名機能で与えられたメッセージのSHA256ハッシュの結果に対して署名するのに対して、LNURL-authではメッセージ自体への署名を求めています。その上、Lnd自体にノード秘密鍵による署名機能はあれど、BIP32で導出した鍵を使って署名する機能はありません。これらのことからネイティブでのLNURL-authへの対応が不可能となっています。

署名を活用したユースケースはログイン以外にも多数考えられますが、実装による署名方法の違いは悩みの種です。後述のようにアプリケーション層の設計などで吸収するしかないように思われます。

アプリケーション層で吸収を試みたケース

有名なノード管理ツールのうち、ThunderHubは独自にLNURL-authに対応しています。下層で動いているノードがLndであっても、トップ画面→Quick Actions→LNURLから貼り付けることで使用可能です。これはThunderHub内からLndとEphemeral Diffie Hellman鍵交換で共通鍵を生成し、それをBIP39シードとして扱ってBIP32とLNURL-authの規格に沿って個別の鍵を生成しています。

あるいはその横のLNMarkets Loginというボタンも、裏ではLNURL-authを使用してLNMarketsに登録・ログインします。

このときノードに渡す自身の公開鍵は実はEphemeralではなく毎回ノード自体の公開鍵を渡すというハックさえ覚えておけばノードのシードフレーズからLNURL-authのシードまで導出できそうですが、ノード公開鍵は公知なのでこの共通鍵はSigner RPCへのアクセスがあれば誰にでも入手できることには注意が必要そうです。(こんな方法をよく思いついたなと個人的には感心してますw)

このように、LNURL-authへのウォレット側の対応の難しさが、LNURL-authの普及の足かせになっています。これを含め欠点をいくつか改善したLNURL-auth v2の話もにわかに出ていますが、何らかのBOLTが提案される可能性やv1がある程度普及してしまった慣性から新しい規格に置き換えることは難しいかもしれません。

バックアップ方法の違い等がロックインにつながる

LNURL-auth以外にノード実装の相違点が生む問題として、使用しているデータベースやデータ構造の違いから、チャネルを維持したまま他のノード実装に乗り換えることが非常に難しいという事実があります。自分の知る限りでは、チャネルを開いたままLndからc-lightningに乗り換えるためにデータ構造を書き換えるツールは存在しません。

このようなスクリプトを書くのも意外と大変です。c-lightningには1ノードあたり1チャネルまでという制限があったため、もし同じノードと複数のチャネルがある場合は移行スクリプトがあったとしても移行前に1つになるまでクローズする必要があります。 (現在もこの制限があるかは確認していませんが。)

BOLT以外の細かい仕様の違いやその頻繁な変更、そして万が一のバグが発生した際にペナルティトランザクションでチャネル内の残高を失う可能性が移行ツールの開発を阻んでいます。そもそも実装の移行はレアケースなので開発の動機も弱いです。

ノードの多様性の維持は難しい

ビットコインノードにせよ、イーサリアムノードにせよ、耐障害性の向上のために複数の実装が存在しても結局のところネットワーク効果で1つの実装に集中しがちという事実があります。この場合のネットワーク効果とは、問題解決に使用できるオンラインの情報量や周辺ツール・機能の充実、アプリの対応などによって構成されているといえるでしょう。

これを踏まえると、ライトニングノードも同じようなことになっていくと考えられ、もはや既にそうなっているとさえ主張できそうです。

ノード実装をしているチームによってソフトウェアの設計思想やライトニングの理想像が違うので、ノード実装の偏りはそのままライトニングネットワーク自体の方向性にも大きな影響を及ぼしかねません。

ノード実装間の違いが大きいほど耐障害性などのメリットが大きくなるはずが、結果的に１つのノード実装にユーザーが集中してしまうというのはP2Pソフトの普遍的なパラドックスなのかもしれません。