皆様こんばんは。私は最近はLNのペイメントの仕組みや信用を利用した効率化などに興味があり、関連する研究などを読み進めています。その中で、Pedro Moreno-Sanchez氏という研究者が面白い内容のものを多数出しているため、しばらくは彼の論文から特に興味のある内容を紹介することになるかもしれません。

本日はライトニングネットワークに利用されているHTLCやこれから導入されるPTLCとはまた異なる、1ラウンドの通信で支払いが完了するプロトコルBlitzについて解説しようと思います。

”Blitz: Secure Multi-Hop Payments Without Two-Phase Commits" Lukas Aumayr, Pedro Moreno-Sanchez, Aniket Kate, Matteo Maffei, 2021.

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

スマートフォンから書いているので、見出し等のフォーマットが設定できていなかったり、文章にまとまりがなかったらごめんなさい。

〜HTLCは支払い完了に2ラウンド必要〜

本コラムの読者はすでにHTLCについて耳が痛いほど聞いているかと存じます。わからない方のためにまとめると、ライトニングチャネルを通しての支払いは「プリイメージというデータと引き換えでの支払いを約束するラウンド」(宛先側のチャネル更新) と「相手から送られてくるプリイメージによって自身に送られてきた資金を受け取る」(送金者側のチャネル更新) という2つのラウンドからなります。これがHTLCでチャネルを更新する段取りです。

さて、今まとめたように、HTLCを使った支払いには「資金をコミットするラウンド」「コミットされた資金を受け取るラウンド」の2ラウンドがあります。そして実はこの仕組みがいくつかの攻撃方法や問題に繋がっています。

代表的なものを挙げると、1ラウンド目のあと、2ラウンド目で相手がわざと音信不通になってしまうグリーフィング攻撃 (イタズラ攻撃・DoS攻撃)があります。これは攻撃対象の資金を長期間拘束できてしまう上に、比較的簡単に実行することができ、予防が難しいという問題があります。HTLCを用いたペイメントチャネルネットワークでは、各ステップにおいて安全のために相手が1日程度音信不通でも待つようになっていますが、この方針もあって資金の凍結状態が長期化してしまいます。

ほかにも、ワームホール攻撃というものがあります。ユーザー視点では影響はありませんが、これは2ステップ目のプリイメージの伝送において中継経路を短絡させることで、排除されたノードが受け取る予定だった手数料を攻撃者が奪うという攻撃です。

※ただし、ワームホール攻撃に関しては、近い将来にHTLCを少し改善した仕組みであるPTLCの導入で対策される予定があります。

これらの問題への根本的な解決方法として、HTLCのような2ラウンドの通信を必要とするペイメントチャネルネットワークに代わる、1ラウンドで完了するプロトコルとしてBlitzが考案されました。

〜Blitzで支払いが1ラウンドで完了する仕組み〜

さて、Blitzはどのようにして支払いを1ラウンドで完了させるのでしょうか。HTLCとは仕組みが根本的に異なるので、白紙ベースで考えてみましょう。

これには論文の著者たちが"Pay-or-Revoke"と呼ぶ、HTLCに代わるコントラクトを考える必要があります。これは送金側のノードから宛先側のノードへと資金が移るか、送金が失敗して送金側のノードに返金されるかの2つの結末がある仕組みを1ラウンドで実現するということです。(もっと厳密に言えば、経路上の全てのチャネルにおいて同時にどちらかの結末になる必要があります。)

Blitzにおいて、これは送金者が返金トランザクションをあらかじめ用意しておくことで実現しています。詳しく見ていきましょう。

支払いが成功するとき、Blitzにおけるチャネルのアップデートはタイムロックのみによって行われます。送金者側から宛先側へと、チャネル内の残高が1つ1つタイムロック付きで移動され、タイムロックの時間経過後に送金が成功したことになります。同じタイムロックを設定するため、全てのチャネルで同時に送金が成功したことになります。

送金が開始されたときは、とりあえずタイムロック付きで次のノードに資金を渡しているのですね。

あとは支払い失敗(＝キャンセル) のケースを扱えばよいのですが、キャンセルは前述の通り、送金者が返金トランザクションをブロックチェーン上に配信することで、各チャネルはその返金トランザクションの特定の出力を使って送金前の状態に戻します。

つまり、経由する各ノード用にそれぞれ出力のあるキャンセル用のトランザクションが送金時に署名前の状態で各ノードに渡され、キャンセル時に各チャネルで実行されるトランザクションはこのキャンセル用トランザクションの配信が前提となるため、当初の送金者のみが各ノードのチャネル更新を、全て同時にキャンセルするよう仕向けることができるというわけです。

これは送金者のみがタイムロックまでの一定時間内は返金を開始することができる仕組みで、送金開始後は経路上のノードか宛先のノードにしか送金のキャンセルができない現在のLNとは大きく異なります。

他にも、この1ラウンドによるプロトコルでは、一定時間が経過すると各ノード間のチャネルが支払い成功時の状態に更新できるようになるため、支払いが確定したことになります。これも送金成功時の即時性が高いLNとは異なる点ですね。

なお、現在のLNとは異なり、宛先から着金の連絡はBlitzプロトコル内では送られてこないため、キャンセルをするかどうかはプロトコル外の情報に頼ることになります。(支払い確認メールや商品の提供、未払いの通知など)

ちなみに、Blitzにおいても、送金経路上のノードが全てオンラインであり、正直である場合においては各ノードは単純に各チャネルの内容を正しくアップデートすればよいだけであるため、任意で2ラウンドの通信(2ラウンド目は宛先側から送金者側への着金成否の通知) を行えば、決済にタイムロックまで待つことなく即時性のある送金や返金を行うことができます。(送金失敗時の巻き戻しに関しても同様です)

〜メリット〜

まず、先述したようにグリーフィング攻撃への耐性が大幅に強化され、ワームホール攻撃は不可能になります。

また、1ラウンドで完了することで支払いの中継に資金が拘束される時間が大幅に減少するため、使用したかったチャネルの資金が拘束されていたことによる送金失敗率が大幅低下するなど、ネットワーク全体の効率が向上します。

資金拘束の他にも、1ラウンド目と2ラウンド目の間に通信に問題(ノードが落ちてしまうなど) が発生することによる支払いの失敗率も低下します。

Blitzで送金キャンセルを実現する仕組みが、宛先の協力が前提となるHodl invoiceよりトラストレスなのも評価に値するのではないでしょうか。(その代わりキャンセルにコストがかかりますが)

最後に、Blitzで持ち合うトランザクションの大きさがHTLCより26%小さいので、1つのチャネルが同時に処理できる件数がアップします。(1つのライトニングノードが1つのチャネル内で同時に持てる未決済送金の数は、オンチェーンで決済することを考慮して総データ量によって制限されています。)

現在のライトニングネットワークとは仕組みは異なりますが、必ずしも別のネットワークである必要はなく、機能として追加できるかもしれないところもメリットかもしれません。(少々複雑にはなりますが…)

〜デメリット〜

送金者が、送金失敗による返金を開始するにはオンチェーントランザクションを出さなければならないためコストがかかり、またこのコストは経路が長いほど大きくなります。したがって、ある程度以上の金額でなければ送金を事実上キャンセルできません。

また、2ラウンド目を行わない場合、完全に失敗でキャンセルすべきなのか、時間が経てば成功するので待つべきなのかの判断に困るような気もします。

最後に、悪意ある中継ノードが次のノードへの送金を行わない場合、キャンセルにかかるコストが送金者にのみかかるのではないかという疑問があります。(勘違いかもしれません。)

〜まとめ〜

・Blitzは支払い中継時にライトニングチャネルの通信が1ラウンドで済む新しいプロトコル

・タイムロックと予め用意された返金トランザクションにより、一定時間内は当初の送金者が全てのチャネルの更新をキャンセルすることができる

・2ラウンド目も行うことで即時着金も可能

・HTLCの問題点をいくつか解決し、効率面でも有利そうである