Lnurlスタンダードの定着が与える影響を考える

東晃慈 • 2020年05月06日

Lightning Networkのユーザー体験や機能性の向上を目指すLnurlというスタンダードが、先日Coindeskの記事でも紹介され、水面下で少しづつ利用が進みつつあるのですがその概要と影響について考えてみます。

スタンダードの浸透というのは非常に地味なことにも思えますが、後で考察するようにERC-20トークンスタンダードなどその後の開発やビジネスの進展に非常に大きな影響を与えた事例もいくつもあるので、個人的には最近特にこれらのLN開発やユーザー体験を改善するスタンダードの浸透に注目しています。

現在のLNのユーザー体験の問題

研究所ではすでにLightningについて色々解説しているので、自分でウォレットを運用してLightningで支払いをしてみたり、Lappsと呼ばれるゲームやサービスを実験的に使ったことがある人も多いと思います。また、以前Lightningに関するウォレットの分類とそれぞれ一長一短ある、という説明をしましたが、共通して言えることは全体的にLightningのユーザー体験はまだまだ使いやすいとは言い難いです。

Lightning Walletの分類↓

例えば、以前から研究所でも解説している通り、LN上で支払いを受取りたい場合Inbound capacityが必要になります。Inbound capacityを得るには、簡単に言えば他のノード運営者に「自分のこれこれのノード（ウォレット）にこの条件でチャネルを貼ってきてください」というリクエストをしなくてはいけないのですが、現状だとこのプロセスはマニュアルでNodeのURIやポート番号を指定する必要があったりわかりづらいです。

例えば、無料でInbound capactiyを提供してくれる「LNBig」（（https://lnbig.com/...
lncli connect 028a8e53d70bc0eb7b5660943582f10b7fd6c727a78ad819ba8d45d6a638432c49@lnd-33.LNBIG.com:9735 >/dev/null 2>&1; lncli getinfo|grep '"identity_pubkey"'|sed -e 's/.*://;s/[^0-9a-f]//g'|tr -d '\n'| curl -G --data-urlencode remoteid@- 'https://lnbig.com/api/v1/oc...' &>/dev/null

Inbound capacityがないとLN上で支払いの受取りすら出来ないのですが、これだとかなり面倒くさい。何かこれをモバイルウォレットからQRコード読むだけで簡単に処理出来るようにならないの？といった問題を解決するのがまさにLnurlです。

Lnurlのスペックの一つ「Lnurl-channel」はまさに上記の例のようなチャネルの構築依頼をモバイルからQRコード読み取りで簡単に実現する為の共通スタンダードです。これを提案しているBitcoin Lightning Walletではすでに実装されており、BLWの利用者ならLNBigのサイトでQRコードを読み込むだけで簡単にInbound capacityをリクエスト出来るので、是非やってみてください。LNBigは無料で太っ腹にInbound capacityを提供してくれますし、かなり便利です。

同じ要領でLnurlは、LightningのノードIDを利用したQRコード認証（サインイン）システム（LNURL-auth)、QRコードを読み込むだけで指定額を自分のLightning walletにSweep出来る（LNURL-withdrawal）などが存在し、すでに主要なウォレットやLappsで採用されつつあります。

また、まだ利用は限定的ですが個人的には「LNURL-pay」というスタンダードに注目しており、これを使うことで自分のウォレットに紐づく「支払いリクエストURL」の共通フォーマットを作成することが出来るようになります。

このURLを使うことで、受け取り手に手動で毎回Invoice発行をリクエストする必要なく、支払い手は裏で自動的に適切なInvoiceを入手できるようになります。

今後これらのスタンダードが定着していくことで、Lapps間での支払いの送受信のリクエストの自動化、複数Lappsをまたぐ支払いがよりスムーズになり、新しいタイプのサービスが構築可能になっていくのでは、と期待しています。

LNURLなどのスタンダードの重要性

このように比較的細かい話ですが、今Lightningでは水面下で「よりスムーズにウォレットとノードでチャネル情報を共有」したり、「より簡単にLightning WalletとLapps間、もしくはLapps間同士で交信」が出来るようなスタンダードが固まりつつあります。LNURLの他にもウォレットとLightningノードをQRコードで簡単にリモート連携させるためのlndconnectなどもそのようなスタンダードの一つです。
これらのスタンダードの浸透は地味であまり興奮するようなものではないかもしれないですが、一度こういう土台のスタンダードが固まってくると、開発の効率化や新しいアプリケーションエコシステムの実現、ユーザー体験の向上など非常に重要な意味をもっています。

Lnurlだけとっても、すでにモバイルウォレットのユーザー体験は以前と比べると大きく向上してきていますし、これらのスタンダードが整うことで初めて本格的なLapps開発のブームが始まると思います。
この界隈でもそういう現象はすでに何回も起きており、特にイーサリアム周りで大きな影響を与えたのが、「ICOで広く利用されたERC-20スタンダード」と、「Non Fungible TokenのERC-721スタンダード」なのはすでにご存じの人もいると思います。それぞれのスタンダードが固まってきたくらいのタイミングでそれぞれ「ICOブーム」、「NFTブーム」が始まりました。逆に言えばこれらのスタンダードが定着するまではイーサリアムのトークン体験も非常に粗かったです。
例えば、ERC-20が定着する前にも、当然イーサリアム上でトークンを発行しているプロジェクトは存在しましたし、ICOも存在しました。ただしERC-20が定着するまではトークンをコントラクトで表現するだけでも難易度が比較的高かったのと、トークンの規格がバラバラだったので各Dappsの互換性が低く、現状のイーサリアムのように「ERC20トークンならまとめて扱えるウォレット」「ERC‐20をまとめトレードできるDex」などは存在せず、それぞれのプロジェクトのトークンの規格にウォレットはマニュアルに対応しなくてはいけないような状態でした。
ERC-20が出てきたことで、より多くの人が比較的安全に簡単にEthereum上でトークンの発行が可能になり、その土台が一時期のイーサリアム上のICOブームの直接的な要因となりました。ERC-721も同様で、それまでにもNFTというコンセプト自体はすでに16年以前から存在していましが、CryptokittiesがNFTのスタンダードを広めたことで一気に18年以降NFTトークンのブームが始まったといえます。

Lightningは今まさに水面下でこういう重要なスタンダードがいくつか姿を現してきており、今後の開発エコシステムの爆発を受け入れる体制が整いつつある状態と言えます。

最近個人的には特にこういう地味な改善や議論、実装の進展を見てLightningも少しづつ足元が固まってきていること、アプリケーションを考案するような立場からも手札が揃いつつあるのを感じています。

東晃慈