引き続き、Lightning Network BOLTの送金転送について説明していく。
今回は送金に関するメッセージについて見ていく。
送金の転送は、2ノード間の送金処理を送金元から行っていくことになる。
請求書の発行者が直接の相手ではないため、送金元から着金したノードは、別のノードに送金する。
これを繰り返すことで、送金先まで届くことになる。
BOLTメッセージで言えば、 update_add_htlcによってHTLCを追加する動作が行われることになる。
ここまでで、いろいろ疑問点が出てくる。
すぐ出てくるのは、こういうところだ。
- 送金されたノードは、それをそのままもらったままにしないのか？
- 送金されたノードは、次の転送先をどうやって決めるのか？
まず、もらったままにしないかどうかだが、update_add_htlcはHTLCを追加するだけのため、それだけでは自分の持ち分にすることができない。
HTLCは中に請求書IDのハッシュ値が入っていて、請求書IDそのものをもらうことによってスクリプトを解くことができ、自分の持ち分にすることができるのだ。
そして、請求書IDは送金先だけしか知らないので、それもまた遡るようにして転送してもらうことになる。
次に、次の転送先の決め方であるが、これはupdate_add_htlcのパラメータに入っている。
送金元から送金先までのルート情報は、送金元がすべて決定し、BOLT#4に沿って変換し、update_add_htlcに載せて送っている。
受け取ったノードはルート情報を自分が分かる鍵でデコードすると、次に転送するノードと、転送額がわかるようになっている(相手から送られてきた額と転送額の差が、転送する手数料として受け取る)。
転送するときは、デコードしたルート情報を載せて送る。
次に受けとった人も同じようにデコードすると、また次に転送する情報が載っているので、転送していく。
デコードして次に転送先がなかった場合、それが自分への送金ということがわかるようになっている。
送金の転送は、異なるチャネル間をノードが中継することになる。
チャネル内にfundingされている額は、チャネル外に出すことはできない。
例えば、よく送金に使われる経路があった場合、片方のチャネルは着金を受け付けるだけで、もう片方のチャネルは送金を行うだけ、ということがあるかもしれない。
そうすると、ノードとしては持っている額のトータルは変わらない(手数料によって増えることはあるが)ものの、チャネル内の額の偏りが生じてしまい、いつかは送金できる額がなくなってしまうだろう。
もちろん、経路の途中で送金ができなかった場合は、update_fail_htlcというメッセージがあり、HTLCを追加する前の状態に戻すことになっている。
額が足りなくなったチャネルは、今のところ一度closeして、またチャネルを作り直すしかないと考えられる。
次のBOLT仕様ではrefundという項目があるため、そこで解決される可能性もある。
このようにして、まずは送金元までの経路でHTLCを追加していく作業が行われる。
次回は、HTLCを反映させて自分の持ち分にするところを説明していく。