ここ最近はライトニングネットワーク(LN) の効率化の話を書くこと多くなっています。今日もそんな話にお付き合い下さい。

LNにおける効率とは、突き詰めれば「LN上のトランザクション総額 / かかったオンチェーントランザクション手数料」であり、これを改善する方策としてはオンチェーンでのチャネル開閉が必要になる場面を減らすことがメインです。(資金効率の話もよく出てきますが、資金が大きいほうが上記の効率が高くなりやすいため、有利かもしれません)

コストのかかるチャネル開閉を減らすには、チャネルのリバランスの頻度が下がるよう運用を工夫するなどノード管理者の努力も当然されていますが、送金経路上のノードがオフラインになった場合などにチャネルを閉じる必要がある仕組みを見直すなど、根本的な提案もされています。

今回説明するPedro Moreno-Sanchez氏論文紹介シリーズの第三弾は、オンチェーントランザクションを伴わない、ペイメントチャネル上に構築する「仮想チャネル」でLNを効率化する方法であるDonnerについてです。

https://eprint.iacr.org/2021/855.pdf

LIGHTWEIGHT VIRTUAL PAYMENT CHANNELS

実はDonnerより前、ちょうど１年ほど前に発表された論文にLightweight Virtual Payment Channelsというものがあります。

https://eprint.iacr.org/2020/998.pdf

これは近距離(１ホップ先までーつまり中継ノードは１つ) のノードを直接つなげる仮想チャネルをマルチシグとタイムロックのみを使って実現する方法で、オンチェーントランザクションが発生するのはその仮想チャネルを強制的にクローズする必要がある場合のみです。

また、この仮想チャネルの上にさらに仮想チャネルを構築することによって、任意のホップ数先のノードまで直接仮想チャネルをつなげることもできます。(Recursive LVPC)

しかしRecursive LVPCは大きな欠点として、いくつも重なった仮想チャネルの上位層がオンチェーンに決済する必要ができると、関係する下層の仮想チャネルもオンチェーンに決済する必要があること、いたずらなどによる資金のロックも同様に下層の仮想チャネルに波及することなどが挙げられます。

DONNERの大まかな機能

大まかな機能として、Donnerは仮想チャネルに使用する資金と同額を実際のLN上でも担保し、仮想チャネル上の資金のやり取りは直接チャネルがあるのと同様に管理し、友好的にクローズする際には残高を実際のLN上で決済します。この場合、オンチェーンには１つもトランザクションは発行しません。

そのために、セットアップ時にLN上の経路を設定し、その中継ノードを巻き込んで仮想チャネルをセットアップします。

LNの手数料は基本的にはパーセンテージなので、おびただしい量のトランザクションを捌く必要がある場合には手数料がかなり高く付くことになります。Donnerのような仮想チャネルを使って直接チャネルを開いた状態を仮想的に実現することで、手数料を気にせず大量のペイメントをやり取りすることができます。金融機関や従量制課金などのユースケースに非常に向いていると言えます。

オンチェーンの決済を、あとでまとめて行うことでトランザクション数を圧縮するのがLNなら、LNの決済をあとでまとめて行うことでトランザクション数を圧縮するのがDonnerです。

DONNERの詳しい流れ

では今日紹介するDonnerはどのような仕組みで以上の問題点を改善しようとするのでしょうか。実は仕組みは1ヶ月ほど前に紹介したBlitzプロトコルに似ています。

BlitzプロトコルとはHTLCに代わる、マルチシグとタイムロックのみによるLN上の送金中継の仕組みで、一定時間の経過で自動的に経路上の中継がすべて成功するようになっています。もし送金者が一定時間の経過する前に送金をキャンセルしたい場合は、返金用のオンチェーントランザクションを発行します。このオンチェーントランザクションは各中継ノードにあらかじめ渡しており、中継ノードはそのオンチェーントランザクションを参照してチャネルを元の状態に戻します。

Donnerに基づく仮想チャネルの開設は、保有するビットコインから仮想チャネルの資金を拠出し(ここからコミットメントトランザクションを作り、仮想チャネル自体に利用)、さらに実在のLN上で２つのノードを結ぶ各中継ノードが単独で使用できる少額のビットコインを含むトランザクションを用意することで行います。

また、このときに仮想チャネルの「寿命」を決めておき、以下に記述する実在のLNチャネルにおける処理を行います。

LN上の各中継チャネルにおいて、実際のチャネル残高から、仮想チャネルの金額を一定期間(仮想チャネルの寿命) 経過後は送金先・中継先が自由に使え、それ以前なら二者の署名とより短い時間経過(中継の時差用) で使用できるトランザクションを作成します。言い換えると、仮想チャネルの寿命が来るまで、LN上でも仮想チャネルの金額＋手数料分をマルチシグにロックしています。

もし仮想チャネルの寿命が来たら、LN上の各チャネルにおいて仮想チャネル全体に等しい資金が受け渡されてLN上で決済されるということですね。(※仮想チャネル残高の更新や手数料考慮せず)

また、返金用のトランザクションも作成します。このトランザクションの入力値には先述した各ノードが単独で使用できるようになる少額のビットコインのうち、該当するノードのものが含まれます。このことによって、仮想チャネル開設のトランザクションが実際に配信されオンチェーンで承認された場合には、各中継ノードが返金用トランザクションを使用することできるようになります。

そう、仮想チャネルでの紛争発生時には仮想チャネルは実際のチャネルのように送信元・宛先ノード間でオンチェーン決済され、中継ノードたちはその返金用トランザクションを使って担保としてロックしていた金額を取り戻すのです。つまり、仮想チャネル開設のトランザクション自体が返金用トランザクションなのです。

さて、ここまでで仮想チャネルのセットアップが完了し、使用できるようになりました。

仮想チャネルを使用する際には、単純に送信者と受信者が通常のペイメントチャネルと同様に仮想チャネル上でやり取りすれば良く、実在のチャネルの中継者などは無関係です。もし紛争が発生した場合には２者間で解決され、その過程で上記のとおり返金用トランザクションが有効になりLN上に実在する中継ノードたちは担保を取り戻せます。

最後に、友好的なチャネルクローズ時には、実在のLN上で中継ノードを介して決済が行われます。このとき、仮想チャネルの最終的な残高を反映するように中継ノードに送る金額を調整し、宛先まで問題なく届けばLN上で決済され、仮想チャネルは全額が送信者側にある状態で終了し、オンチェーンで開設されることのないまま閉鎖扱いとなります。

仮想チャネルの寿命を後から調整することも、中継ノードたちの協力があればできそうです。実際に行う場合は、(仮想チャネルのセットアップ時もですが) ある期間の資金拘束を伴うので手数料が発生することが望ましいでしょう。

長所・短所

仮想チャネルというアイデア自体の長所として、LNよりさらに上位のレイヤーとして高頻度の取引に向いているという点が挙げられるでしょう。仮想チャネルを組み合わせたネットワークが場合によってオンチェーンに一切決済せずに存在できる可能性を考えるとわかりやすいと思います。(実際はLN上の中継ノードの問題で決済が必要になることもあるでしょうが、その場合もオンチェーントランザクションの量は少ないです)

前半で紹介したRecursive LVPCの問題点もほぼ解決しており、驚異的によくできた仕組みだなと感じます。

無理やり短所を指摘するにしても、

・返金用トランザクションの都合上、紛争解決時にはオンチェーン手数料に加えて中継チャネルの数×546サトシの費用がかかる (大した金額ではない)

・仮想チャネルの寿命が長いと、途中のノードがオフラインになるなどしてLNで決済できる可能性が下がっていく (しかし、その場合でもオンチェーントランザクション１つで決済できてしまう)

くらいではないでしょうか。

かなり面白い割にまだ新しく、全然知られていない仮想チャネル技術ですが、Donnerは完成度がとても高いように思えたので、こんなものが生まれてるんだなとぜひ頭の片隅に置いておいてください。