安全性とプライバシーを強化するペイメントチャネルネットワーク「Multi-Hop Locks」

LNではHTLCを使って仲介者を経由したマルチホップ決済を可能にしている。例えばアリス→キャロルのオフチェーン決済をボブとマイクを経由して行うケースでは以下のような決済フローになる。

f:id:techmedia-think:20180704140150p:plain

最初に受信者のキャロルがランダムな値Rとそのハッシュ値H(R)を生成し、H(R)をアリスに渡す（invoice）。
アリスはキャロルまでの経路を決め、H(R)とタイムロックを組み合わせたHTLCトランザクションをボブとのペイメントチャネルに投げる。
仲介者はさらに経路上の隣のユーザーにHTLCを流していく。
キャロルまでHTLCが届いたら、マイクにRを明かして資金を受け取る。
今度は逆方向に終着点アリスまでRと交換に資金をセトルメントしていく。

ここでタイムロックとシークレットを組み合わせたHTLCは、以下のような条件を持つコントラクト（↑のアリスとボブで考えた場合）

3日経過する前にボブがハッシュを取るとH(R)になるようなRを生成できればアリスはボブにコインを支払う。
3日経過するとアリスにコインが戻ってくる。

こういったマルチホップ決済について、一般化し安全性およびプライバシー保護を強化するMulti-Hop Locksという新しい提案が発表された↓

https://eprint.iacr.org/2018/472.pdf

↑のホワイトペーパーの著者であるPedro Moreno-Sanchezのプレゼン↓

youtu.be

マルチホップ決済のモデル化

↑のホワイトペーパーではこのマルチホップ決済のようなロック機構をMulti-Hop Locksという暗号プリミティブとしてモデル化している。このモデル自体はマルチホップ環境下のロックを一般化したもので、LNはその使用形態の１つ。LNの場合はロックの解除＝コインの入手を意味するMulti-Hop Locksの一使用形態になる。

ホワイトペーパーでは、このモデルを実装するための方法として以下の３つの方法を提示している。

一方向準同型関数を使った一般的なスクリプトベースの構成
Schnorr署名を使ったScriptless Scriptベースの構成
ECDSAを使ったScriptless Scriptベースの構成

一般的なスクリプトベースの構成では一方向の準同型関数を使った任意のコントラクトを作成できるブロックチェーンである必要があり、EthereumやHyperledger Fabricがターゲットとして挙げられている。BitcoinはまだSchnorrはサポートしていないので、現状のBitcoinベースでMulti-Hop Locksを実装する場合、ECDSAを使ったScriptless Scriptの構成になる。この場合、2017年にYehuda Lindellが発表した「Fast Secure Two-Party ECDSA Signing」を使って後述する鍵生成やロックが実装される。

（参考） techmedia-think.hatenablog.com

Multi-Hop Locksは以下の5つのプロトコルで構成される。

f:id:techmedia-think:20180705095024p:plain

1. 鍵生成

チャネルを構成する二者間の鍵を生成するプロトコルで、アリスとボブがいた場合アリスの鍵 ${sk_1}$ とボブの鍵 ${sk_2}$ 、最後にアリスとボブの共通公開鍵 ${pk}$ を返す。

基本的にはチャネルを開設した時点で、お互いの公開鍵を知り、共通公開鍵を共有している状態（チャネルを開いた時点で鍵生成プロトコルは実行済み）になると思われる。

2. セットアップ

セットアッププロトコルは、参加者の集合（＝LNで決済する際の経路）が与えられた際に、経路上の各参加者に状態 ${s_i}$ を与えられる。また最後の参加者（＝LNでコインの最終的な受信者）にはさらにオープン鍵 ${k_n}$ が与えられる。各状態はこの後のロックを生成するのに使われる。

3. ロック

続いて隣り合う各参加者のペアがロックプロトコルを実行する。ユーザーのペアを ${U_i}$ と ${U_{i+1}}$ とした場合、2人は両者の初期状態 ${s_i}$ と ${s_{i+1}}$ を使ってロック（ ${L_i}$ ）を作成する。このロックは、ある暗号条件が ${U_{i+1}}$ によって解かれた場合に、 ${U_{i}}$ がある量のコインを ${U_{i+1}}$ に支払うというコミットメントになっている。

既存のLNではこのロックをアンロックする際に必要となるのは、受信者がコインを受け取る際に必要なプリイメージで、経路上の全ノードのコミットメントで同じ値が使用されるが、Multi-Hop Locksの場合はアンロック条件は隣り合うノード毎に異なるのが特徴だ。

↑の図のアリスとボブの場合は、初期状態 ${s_0}$ 、 ${s_1}$ を使って、ロック ${L_0}$ を生成し、 ${s_0^{R}}$ をアリスに ${s_1^{L}}$ をボブに送る。

このロックは、 ${L_0}$ のロックを解いたらアリスがボブにコインを支払うというコミットメントを表す。

4. リリース

リリースプロトコルは↑のロックを解放するプロトコルで、オープン鍵kと ${(s_i , s_i^{R}, s_{i}^{L})}$ が与えられた時、新しいオープン鍵k'を返す。

↑の図では、キャロルがロック ${L_2}$ をアンロックするために、最初に受信したオープン鍵 ${k_3}$ と ${(s_3 , s_{3}^{L})}$ を使って新しいオープン鍵 ${k_2}$ を入手する。キャロルは ${k_2}$ でL2をアンロックすると、今度はマイクが ${k_2}$ と ${(s_2 , s_2^{R}, s_{2}^{L})}$ を使って、L1をアンロックするためのオープン鍵 ${k_1}$ を入手できる。これを送信者のアリスに辿り着くまで続ける。

5. 検証

検証プロトコルは、↑のリリースプロトコルで生成したオープン鍵とロックから、そのロックがリリースできるか検証する。

一方向準同型関数を使った実装

モデルでなんとなーくのイメージは掴めるけど、一般化されたモデルで実際のロジックが分かりづらいため、一方向準同型関数を使った実装で理解する。

一方向準同型関数というのは、 ${ y = f(x)}$ のような関数で、yからxを計算することが困難で、かつ ${f(x) \cdot f(x') = f(x \cdot x')}$ のような準同型性がある関数。

楕円曲線の鍵ペアを使うのが簡単で、秘密鍵をxとした場合y = xGとなり、xG + x'G = (x + x')Gとなる性質を持つ関数を採用する。

セットアップフェーズ

LNで支払いを行う送信者は受信者までの数分（n）、ランダムに値をサンプリング（ ${y_0, ..., y_n}$ ）する。
送信者は受信者までの各ユーザーに対して３つのアイテム=を送る。参加者が3人の場合、以下のデータが送られる。
- ${U_0}$ （送信者）には ${(n/a, y_0G, y_0)}$
- ${U_1}$ （中間者）には ${(y_0G, (y_0 + y_1)G, y_1)}$
- ${U_2}$ （受信者）には ${((y_0 + y_1)G, (y_0 + y_1 + y_2)G, y_2)}$
受信者にだけ、 ${\sum_{i=0}^{n-1}y_i}$ をオープン鍵を送る（この場合オープン鍵 = ${y_0 + y_1 + y_2}$ ）。

ロックフェーズ

各ユーザーは、送信者から送られたデータを元に、ロックスクリプトを構成する。3つ受信したアイテムの内、右側のノードの2つめのアイテムと、左側のノードの1つめのアイテムは同じデータを指しているので、それを使ってロックをする。

例えば $U_2$ と $U_3$ の間のロックは $U_2$ の ${(y_0G, (y_0 + y_1)G, y_1)}$ の2つめのデータと、 $U_3$ の ${((y_0 + y_1)G, (y_0 + y_1 + y_2)G, y_2)}$ の１つめのデータは ${(y_0 + y_1)G}$ で同じ値になる。これを使ってロックスクリプトを構成する。この時の条件は、 ${y_0 + y_1}$ が明らかになれば $U_2$ から $U_3$ にコインを支払うというもの。

これがHTLCの代わりで経路上の全ノードが実行する。

リリースフェーズ

受信者がセットアップフェーズで送信者から送られた $y_{n-1}$ とオープン鍵を使ってコインを入手する。3者の場合、受信者 $U_3$ は、 $y_2$ を知っているので、別途送信者からもらったオープン鍵 ${k = y_0 + y_1 + y_2}$ から $y_2$ を引いて ${y_0 + y_1}$ の知識を得る。 ${y_0 + y_1}$ は、 ${U_2}$ と ${U_3}$ 間でロックされているコインのアンロックするのに有効なプリイメージなので、これを ${U_2}$ 開示するとコインを入手することができる。

続いて ${U_2}$ は ${y_0 + y_1}$ が分かるので、セットアップフェーズで受信した $y_1$ を引いて $y_0$ を計算する。 $y_0$ が分かれば ${U_0}$ からコインを入手できるという仕組みだ。

図にまとめると↓な感じ。

f:id:techmedia-think:20180801142831p:plain

説明のためにプリイメージのみをアンロック条件として記載しているけど、実際はプリイメージを知っているアリスが不正をしないよう、各ノード間のコントラクトには別途参加者の鍵での署名も条件に加わると思われる。

こうやって準同型性のある一方向関数を使うことで、受信者側（左側）から順にコインをアンロックし、アンロックに使用した値がさらにその先のロックをアンロックするのに使われる仕組みを実現しており、これがHTLCの代替になる。HTLCと比べて各中間ノードで扱われる条件はそれぞれ異なるのでプライバシー及びセキュリティの向上になると考えられる。

※ なお、現状のBitcoinでは一方向準同型関数を使った構成はスクリプトで実装できないので、現状のBitcoinに適用する場合は別のECDSAを使ったScriptless Scriptの構成を取る必要がある。SchnorrやECDSAを利用した実装については、別途書けるといいな。

Multi-Hop Locks のメリット

従来のペイメントチャネルが、ハッシュのプリイメージとコインを交換するHTLCの連鎖であったのに対し、Multi-Hop Locksでは各ホップで両者の状態（ ${s_i, s_{i+1}}$ ）を使ってロックを構成し、そのロックは右側のロックをリリースした際のオープン鍵を使ってアンロックできるようになっている。

このモデルでは既存のペイメントチャネルに比べて以下のようなメリットがある。

HTLCでは経路上に同じシークレット値とそのハッシュを使用するが、Multi-Hop Locksは各ホップ毎にロック条件が異なるのでプライバシーが向上する。
HTLCの場合、途中のコミットメントトランザクションがブロードキャストされると、HTLCが使われていたことがチェーン上で明らかになるが、Scriptlessで構成した場合チェーン上に現れるのは（P2PKHのような）通常の決済のトランザクションと同じになるのでプライバシーが向上し、さらにトランザクションサイズも削減され、その結果、手数料、オンチェーン上のスペースの削減が見込まれる。
Scriptlessの構成の場合、EthereumなどのECDSA（もしくはSchnorr）をサポートするその他の暗号通貨にも同様に適用可能。
LNに限らずAtomic SwapもScriptlessベースで行うと、HTLCトランザクションがオンチェーン上に記録されることはなく、プライバシーの向上が見込める。

Develop with pleasure!

福岡でCloudとかBlockchainとか。