[LN#017]2nd layer

Lightning Network BOLTの概要について、書いていくシリーズ。
LN#000~#016で大まかに行っていることを説明してきたので、これからは個々の部分について書いていきたいと思います。

今回は「大まかな2nd layerのイメージ」についてです。


Lightning Networkは、2nd layer技術の1つ、と呼ばれています。

2nd layerがあるということは、1st layerがあるということになります。
Bitcoinの場合、1st layerはBitcoinのブロックチェーンです。
パブリックなものとしてはmainnetとtestnetがありますが、ノードとして「mainnetのノード」「testnetのノード」という種別は作っていません。

では、どこでmainnet/testnetを分けるかというと、チャネルになります。
チャネルを開設するときのメッセージにgenesis block hashを載せるので、それを受け付けるかどうかで決まることになります。
もし、自分が対応しない種別のブロックチェーンであれば、チャネル開設を行わないようにできます。
また、チャネルの開設途中でfunding transactionという2nd layerの開始となるトランザクションを1st layerに展開するのですが、異なるブロックチェーンをINPUTにすることはできないので、そこで失敗するでしょう。

そのfunding transactionがブロックチェーンに展開されて、ある程度のconfirmationが経過すると、そこが2nd layerでのチャネル開設完了になります(正確には、完了したことを通知し合うメッセージを交換した後)。

以降は2nd layer上でいろいろやって、チャネルを閉じる処理をします。
閉じるときは、funding transactionの出力から送金することになります。
つまり、1st layerから見ると、funding transactionがspentになるとチャネルが閉じたことになります。


閉じ方は3つあります。

1つは、チャネルの双方が合意して閉じるパターン。
この方法は、その時のチャネルに入っている額がそれぞれのアドレスに送金されるので、一番早く1st layerで使えるようになります。
BOLT5で”The good way (mutual close)”と言われるやり方です。

image


その次は、”The bad way (unilateral close)”と呼ばれ、どちらかが現在の状況を使って閉じる方法です。
2nd layer上で送金が確定すると、毎回commitment transactionというトランザクションを作ります。
これは、funding transactionを入力としたもので、それをブロックチェーンに展開すると取りあえずクローズできるというトランザクションになります。
お互い、チャネルにある額は戻ってくるのですが、不正防止のために展開した人はアドレスでは無くスクリプトへ送金され、そこから自分で使えるようにするまでロックがかかっているため、その時間が経過するまでは使用することができません。

また、送金途中のHTLCもスクリプトに送金され、それを取り戻すにはさらに時間がかかります(図には描いていません)。

通常はやりたくないですが、チャネルの相手が行方不明になった場合など、「Good Way」でどうしても閉じられない場合に使用することになるでしょう。

image


最後が”The ugly way (revoked transaction close”と呼ばれる方法。
これは、最新のcommitment transactionをブロックチェーンに展開するのでは無く、過去のcommitment transactionを展開した場合です。

毎回、2nd layer上で取引が発生すると、commitment transactionを作成し、いつでも展開できるように署名をするので、展開しようと思えばできてしまうのです。
ただ、その展開は「取引を無かったことにしてしまおうという」ということに他ならないため、罰則が与えられます。

すなわち、すべての額が展開しなかった人が取り戻せるようなスクリプトに送金されている、ということです。

image

ただ、万能では無く、一定時間内に相手が取り戻す動作をしなくてはなりません。
その時間が、前の「bad way」で取り戻すのに時間がかかる理由にもなってきます。


このように、1st layerから見ると、2nd layerで行われている内容はfunding transactionとその出力しかありません。
その間の細かいやりとりはブロックチェーンには載らず、結果のみが残される形となります。
2nd layerはブロックチェーンに戻ってくることで確定される、という言い方もできると思います。

[LN#016]転送 (3)

引き続き、Lightning Network BOLTの送金転送について説明していく。
前回は、update_add_htlcで各チャネルでHTLCが追加されるところまでだったので、今回はHTLCの反映について説明する。


HTLCの反映は2点間の送金と同じで、update_fulfill_htlcメッセージを使用する。
必要となるのは、invoice作成元が持っているpayment_preimageという、invoiceに入っていたハッシュ値(このブログでは「請求書ID」と記載している)の元になる値である。
2点間であれば、送金した相手がpayment_preimageを持っているが、転送している場合は相手が持っているのかはわからない(送金元ノードと送金先ノードだけはわかる)。

以下のことは覚えておいてよいだろう。
・送金元は、送金先までのルート(どのノードを経由させるか)を作成する
・ルート情報は暗号化されている
・ルート情報を受け取ったチャネルは、1つ先までの転送情報を復号できる
・送金先は、次の送金先が無いということがわかるし、請求書IDの元データを自分が持っていることも確認できる。

update_fulfill_htlcに載っているpayment_preimageがHTLCの請求書IDの元データだとわかれば、HTLCを減らしてamountに反映することができる。
これは、通常の送金と同じである。
違うのは、update_add_htlcを別チャネルに転送したのと同じように、update_fulfill_htlcも同じルートで戻していくことになる点である。
update_add_htlcにはルート情報が載っているが、update_fulfill_htlcにはルート情報がないので、各自の責任で戻していくことになる。


送金の転送についての説明は、以上となる。
最後に、3者で転送した場合の簡単なシーケンスを図で示す。

image

BOLTではHTLCを、送金する方を「offered HTLC」、着金する方を「received HTLC」と呼んでいる。
図では、青い方がoffered HTLC、赤い方がreceived HTLCとしている。
反映の際には、offered HTLCは自分のamountから減らして相手のamountを増やし、received HTLCは自分のamountを増やして相手のamountを減らす。