本稿で何度か取り上げているビットコインの新しいレイヤー2:Arkですが、ライトニングとの差別化ポイントとして「ライトニングの流動性問題を解決した」と表現されることがよくあります。

ビットコインで話題の新レイヤー2「Ark」はどのような技術なのか
読者の皆さんはちょうど昨年のこの時期にBurak Keceli氏がBitcoin 2023カンファレンスで「Ark」として正式に発表したレイヤー2の話題を覚えていらっしゃるでしょうか? 今年の5月29-31日に開催されたBitcoin SeoulカンファレンスでArkの開発者のうちの1人(Steven Roose氏)による発表と質疑応答の時間があり、ようやく自分の中で内容の整理がつきました。発表当初と少しデザインが変わった部分もありますが、今日はArkの仕組みについて軽く解説してみようと思います。 ・コベナンツを前提としたArkの仕組み(図説) ・少し仕組みを変えて現在稼働しているArkもある ・おまけ:コベナンツではないが、相続を念頭に置いたウォレットLianaが面白い

実際にArkはエンドユーザーにとってライトニングウォレットの自己管理が難しすぎることへのアンサーとして開発された側面があり、私の予想ではArkのような仕組みを採用したセルフカストディ型のライトニングウォレットが来年あたり登場するでしょう。

今日はライトニングの流動性問題と呼ばれるUX面での課題をArkがどのように解決したか、そしてその副作用でどのような影響が考えられるかについて触れていきます。

・ライトニングの流動性問題とは

・Arkは流動性の管理責任をユーザーからASPへと移転した

・利用コストにどう影響してくるかは実際にやってみないとわからない

ライトニングの流動性問題とは

セルフカストディ型のライトニングウォレットを持とうと思うと、少なくとも軽量版のライトニングノードを動かして自身でライトニングチャネルを持つ必要があります。ソフトウェア面ではPhoenix WalletやZeusなど様々なモバイル向けのアプリがあり、セットアップや実行が難しいものではありませんが、自身でライトニングチャネルを持つということは、その残高のバランスを管理する必要が出てきます。

💡
おさらいですが、ライトニングチャネルのバランスとは、チャネル内の残高のうちいくらが「自分のもの」で、いくらが「チャネルの接続相手のもの」かの最新状況を示します。

なぜなら、例えば自分から開いたチャネルであれば最初はバランスが全て自分の側(Local Balance)に偏っており、そのチャネルで新たに資金を受け取ろうにも相手側(Remote Balance)から送ってもらうことができないためです。これをInbound Capacity問題と呼ぶことがあります。

解決策としては、誰かにチャネルを開いてもらう、共同入金(Dual Funding)でチャネルを開く、受け取る前に送金に使う(送金した総額の範囲内でしか受け取れない)などが挙げられます。しかし、そもそもが直感的ではなかったり、チャネル自体のサイズが送受金できる金額の上限になるなど直感的ではない部分があります。

Phoenix Walletのように、最初のチャネル解説をPhoenix側からしてくれたり、チャネルの容量が足りなければSplicingで新しいチャネルに作り替えてくれる優れたウォレットもあるので完全に初心者殺しかというとそうではありませんが、自己管理の難しい部分ではあります。(そしてもちろんPhoenixの提供するような便利機能はオンチェーン送金のコストがユーザーにかかってしまいます。)

最終的にはユーザーがライトニングを使う金額が大きければそれほどの問題ではないとも考えられますが、現状では扱う金額の割に手間やオンチェーンの送金コストがかかるため、ライトニングユーザーの多くがカストディ型のウォレットを使うという現状があります。

💡
カストディ型のウォレットをユーザーが好むのは合理的だと思います。ただし、規制が強化されてきており、提供者としてはセルフカストディ型のウォレットのほうが運営しやすく、悩みどころです。

Arkはこのようなライトニングのクセを軽減することができるのでしょうか?

Arkは流動性の管理責任をユーザーからASPへと移転した

エンドユーザーがセルフカストディするライトニングウォレットだと、ライトニングチャネルのバランスは全て利用者が個別に管理することになります。先述したようにPhoenixのように利用者にそれを意識させないUXを実現しているウォレットもありますが、構造的には変わりません。

一方、Arkでは仕組み上、ユーザーはオンチェーンのビットコインを持っているのとほぼ違いはありません。送金するときは持っている資金の範囲内で、受け取るときは上限なくビットコインを受け取ることができます。チャネルのバランスが原因で送受金が失敗することはありません(※)。その代わり、Arkの資金をライトニングに中継する(多くの場合、ASP=Ark Service Providerが運営するであろう)ライトニングノードの流動性管理が大事になります。

💡
※…もちろんライトニング側で送金経路上の問題で送金が失敗する可能性はありますが、Ark内では失敗しないという話です。

仮にArk内に10BTC存在していて、そのうち8BTCが旧にArk外へと移転する場合、Arkの仕組みでは以下の流れで送金が行われます:

・8BTCがArk内でASPへと移転。この資金をASPのウォレット(オンチェーン)に戻すには一定期間かかる。
・これと引き換えに、ASPのウォレットやノードから8BTCが外部に即時送金される(LNやオンチェーンで)

つまり、ASPがユーザーたちから受け取った資金に一定期間触れられないにもかかわらず、ユーザーたちの出金に応えるための別の8BTCをすぐに用意する必要があるというわけです。つまり、(特に出金について)ASPがユーザーたちの出金需要を肩代わりできるよう流動性を管理する必要があります。

💡
厳密には出金需要だけでなく、Arkの残高は一定期間ごとにユーザーが更新する必要があるため、その更新需要も同様の仕組みで拘束されてしまいます。

ライトニングのクセとはまた別の種類のクセが色々ある仕組みですね。

利用コストにどう影響してくるかは実際にやってみないとわからない

このように、ASPは出金や更新を肩代わりするための資金を用意する必要があります。どれくらい用意する必要があるのでしょうか?

これは難しい問題で、実際の利用状況を見ないとわからない部分があります。例えば頻繁に入出金されている場合や、更新期限までまだ長いのに更新された場合などは、Ark内に拘束されるASPの残高や期間(=ASPが肩代わりしないといけない出金や更新の金額)が大きく長くなり、実際のユーザー残高の合計の数倍になることだって考えられます。

ASPがこの資金需要に取引所などからBTCを借り入れて応える場合、利息のコストをユーザーに転嫁する必要が出てきます。これがどれくらいになるかは実際にやってみるまでわかりませんが、仮に平均して預け入れ金額の2倍の拘束金額が発生している(貨幣の流通速度が高い)Arkであれば、金利が3%ならユーザーの残高に対して最低でも年利6%の利息を手数料として課すことになります。

💡
課す利息についても、どのタイミングで課すのか、どうやって課すのかという面はまだどうなるかわかりません。
金利需要が発生するのは「送金~期限まで」「更新~期限まで」の間だけなので、長期保管していて期限直前に更新しているだけのユーザーは資金需要をあまり発生させない一方、期限まで長いコインを出金するユーザーは多く発生させるため、出金時に課すことになるでしょう。

したがって、Arkは確かにエンドユーザーをLNチャネルの流動性管理から解放するかもしれませんが、その分ASPに流動性管理の負担を押し付けることになり、それが翻ってユーザーに手数料として返ってくる可能性が高そうです。

個人的には、どのようなUXでユーザーに変動する送金手数料に納得してもらうかが気になるところです。

まとめ

・エンドユーザーがライトニングチャネルをもつ場合は各ユーザーごとに流動性管理が必要だったが、Arkだと流動性管理はASP(Ark Service Provider)が一手に引き受ける。

・Arkのユーザーが出金したり、期限到来前に残高を更新する際に、一時的にASPが資金を立て替えているような状況になるため、ASPは取引所などからBTCを借り入れるなどして、多くの資金需要に対応できる必要がある。

・Ark内のユーザーの使い方によってはユーザーの総残高の数倍の資金需要が発生する場合も考えられるため、出金時に期限到来までの期間に応じてユーザーに金利のような手数料を課すことになると予想される。今までとは違う手数料の決まり方なので、UX面で工夫が必要そうである。

ユーザーの残高をArkで管理するライトニングウォレットが規制以外の側面でカストディ型のライトニングウォレットと競争できるのかは不透明な部分もありますが、個人的には関心がある領域なので引き続きウォッチしていきたいです。