ビットコイナー反省会で2ヶ月ほど前にライトニングネットワークのワームホール攻撃を参考にペイメントの経路を最適化して資金効率を向上させるというアイデアをプレゼンした際、大変よく参考にさせていただいているビットコイン技術者の安土さんがAtomic Multi-Channel Updatesというものに似ていると印象をコメントしてくださったので、そちらの論文を読んでみました。

最近紹介したBlitzという通信が1ラウンドで完結するライトニングネットワークの支払いプロトコルに引き続き、Pedro Moreno-Sanchez氏の論文紹介シリーズ第二弾です。

https://publik.tuwien.ac.at/files/publik_287981.pdf

ライトニングネットワークの要件

とりあえず、この論文で提案されているAtomic Multi-Channel Updatesというイカツイ名前の仕組みを読み解いていきましょう。

Atomicは不可分性と訳されますが、データベースなどで使われる用語にアトミック操作というものがあります。これは複数の処理からなる１つの大きな処理において、個別の処理がすべて成功すれば大きな処理が完了し、個別の処理が１つでも失敗すれば個別の処理はすべて巻き戻され、大きな処理は失敗するというものになります。

例えばクラウドファンディングにおいて、各参加者は事前にクレジットカードで仮決済しているが、もし期限までに十分な金額が集まらなかったときにすべての仮決済がキャンセルされ、もし集まったときはすべて決済されるような場合がアトミックな処理の例としてわかりやすいでしょう。

ライトニングネットワークを始めとするペイメントチャネルネットワークにおいて、直接つながっていない相手への送金は中継によって行いますが、このとき各チャネルの送金について不可分性が必要となります。もし不可分性がなければ、一部のチャネルでは送金に失敗し、中継をするはずだったノードがまるごと損することにつながります。

したがって、Atomic Multi-Channel Updatesとはペイメントチャネルネットワークの根本的な機能要件の１つと言えるでしょう。現在のライトニングネットワークにおいては、HTLCという仕組みを用いて実現しています。

HTLCについては私が担当する記事で頻繁に触れているため、ぜひ過去のコラムなどをご覧ください。

HTLCの弱点：資金効率

現在のライトニングネットワークですでにHTLCを利用して実現できていることについて、わざわざ新しい方法を提案する理由はなんでしょうか。Atomic Multi-Channel Updatesの場合は、資金効率の面にあります。

HTLCを利用したペイメントの中継は、使用するチャネルの数×送金する金額×解決までの時間が拘束されます。ペイメントの所要時間が数秒であれば問題として表面化しにくいですが、途中のノードがオフラインであったり、宛先のノードが決済を保留する(hodl invoiceと呼ばれます)場合などは数時間～数日などの比較的長い期間、この金額を支払いの中継に使用することができません。特にこの待ち時間が各ホップごとに発生しうるため、非常に長い時間に及ぶ可能性があります。

ライトニングネットワークは、参加するのにホットウォレットで資金を保管する必要があったり、中継ノードはより多くのペイメントを中継して手数料を稼がなければ競争力がなくなるなど、資金効率面についてシビアな設計です。したがって、ペイメントごとに資金が拘束される最大時間が短く済む仕組みはこの重要な側面において優れていることになります。

資金効率がよくなる仕組み

AMCUは4つのフェーズからなります。以下に各フェーズについて手短な説明をします。前提知識として、これから言うトランザクション・チャネルはすべてオフチェーンで保持・更新する前提ですが、相手に悪意があったり問題が発生した際にはオンチェーンに決済することもできます。

また、どの段階もトランザクションの用意は各チャネルで同時並行的に行うことができ、すべてのチャネルの準備ができると次のフェーズに移ります。

～～～

まず、セットアップフェーズにおいて、すべてのホップについて、チャネルを支払いに使う金額と、他の取引に使える金額(仮想的なチャネル)に分けるトランザクションに署名します。チャネル(10⇔0)をチャネル(8⇔0) (今回の送金に関する部分)とチャネル(2⇔0) (残り部分、本手順実行中も使用可能)に分けるという風に。以後のフェーズは今回の送金に関する部分にのみ関係します。

次に、ロックフェーズにおいて、すべてのホップについて、送金額をタイムロックつきで送金中継前の状態にするトランザクションを生成、署名します。すなわち、一定期間経過後に、現在のチャネル(8⇔0)を新たなチャネル(8⇔0)に変えることができるトランザクションです。

このトランザクションは、送金が完了しなかった場合など一定期間の経過後には分割したチャネルの送金額部分を中継前の状態に復活できることを意味します。同時に、残りのフェーズの実行期限とも捉えられます。

ちなみに、送金完了後にこの段階で生成した巻き戻しトランザクションを発行されないように、これを無効にするためのトランザクションを最後の方で生成します。

コンシュームフェーズでは、送金額を相手に送るトランザクションを生成します。ただし、入力値に追加で未だ存在しないUTXOを指定するため、すぐにはオンチェーンで決済することができない、未決済の送金となります。

未存在チャネル(7.99⇔0)と未存在UTXO(0.01)をチャネル(0⇔8)にするトランザクションです。

最後のファイナライズフェーズのみ、不可分性を作り出すのに経路上のすべてのチャネルを更新するため、関係するすべてのノードが協力して１つのトランザクションを生成します。このフェーズでは、送金の完了に使うenableと、ロックフェーズで作った巻き戻しトランザクションの無効化に使うdisableという２つのトランザクションを協力して作ります。

ロックフェーズで作ったタイムロックによる巻き戻しトランザクションを無効にするために、逆タイムロック (一定期間後は使用できない)を使用したいところですが、ビットコインにその機能はありません。したがって、後述のEnableトランザクションが存在していれば巻き戻しトランザクションの結果をさらに巻き戻すことのできるDisableトランザクションを作成、署名します。(Enableトランザクションが出力する未存在UTXOを使います)

最後に作るEnableトランザクションは、各チャネルを送金額よりわずかに小さい仮想チャネルと、ごく僅かなUTXOに分割します。このわずかに小さい仮想チャネルと極小のUTXOの存在によって、コンシュームフェーズで作ったトランザクションが有効になり、各チャネルが決済状態となります。

具体的には、各チャネルについて、チャネル(8⇔0)を、コンシュームフェーズのトランザクションの入力値となるチャネル(7.99⇔0)とUTXO(0.01)に分けます。

～～～

文字で説明するとやや複雑ですが、１つ１つの段階でやっていること自体はそれほど難しいことではないと感じました。

HTLCと比べてのメリットは、ずばり支払いの成否がわかる期限が事前に決まっており、さらに経路の長さに依らす一定なので、資金が拘束される期間が予めわかり、短い点かと思います。

また、発展可能性として、LN上の複数のトランザクションをアトミックに処理できる方法として、今回のAMCUの仕組みを応用することでクラウドファンディングなどにも使えるかもしれません。

まとめ

・AMCUは、HTLCを使わずトランザクションの持ち合いを巧妙に設計することでトランザクションの成否までの待ち時間を固定することができる仕組み

・HTLCを使ったLNでは、経路上のチャネルの数だけオフチェーンのトランザクションを順次解決していく必要があるが、AMCUでは3つのラウンドを同時並行的に行なえば良いので、経路が長いほどメリットが大きい

・複数のオフチェーンの送金をアトミックに実行する方法として発展可能性があるかもしれない