Menu

Subscribe

sendpayment

Lightning network上で、sendpaymentはできない。invoice決済だからだ。っていうのは知ってる。ではsphinxはどうやっているのか。どうやらatomic multi path paymentが重要らしい。

この記事が日本語ではもっとも厳密かな、けど最近は原文が一番わかりやすいって感覚がわかってきた。

よくある質問として、「2$デポジットしたチャンネルが５つあるとして、atomicに6$って送れるの？」っていうのがある。答えは、できる！だ。どうやるかを説明する。

って感じ。atomicっていう言葉のニュアンスがよくわからないんだよなあ。

Multi hop payments

通常のmulti hop paymentでは、例えばAからDに支払いをするならば、

1　 D -> Aにhashを送る。
2　 A、B、Cとhashが伝染。

3　 D、C、B、Aと順にsecretが伝染してアンロック。

じゃあ、単純に考えれば、こんな感じになる。まず、受信者はhtlcのhashのpreimageを５つのノードに送って、各自が支払いするのを待つ。だけど、この仕組みはpreimageを複数のノードが使うことになり、支払いを盗むチャンスを得ることになる。なぜか。

1　 D -> A、A'にhashを送る。
2　 A and A'、B、Cとhashが伝染。

この構造では、BがAのトランザクションだけ経由し、A'は自分だけ取得するということができてしまう可能性がある。この状態を「atomicでない」というのだと思う。

前提事項

以上のことから、複数のnodeを統合して支払いをするときの前提事項が決まる。

  1. アトミック性：部分的な決済は不可能にして、支払いは成功か失敗のどちらかでなくてはならない。

  2. Hashの再利用の禁止：LNのマルチホップ決済ではHTLCが使われ、あるハッシュのプリイメージとコインの交換がアトミックに行われる仕組みになっているが、AMPで決済に使用する複数のチャネルで同じプリイメージ・ハッシュを使用してはならない。悪意ある中間者が不正に資金を抜き取ることを禁止するために必要な事項。

  3. 注文の普遍性：もし部分支払いが先に届いたとしても、全ての注文が届くよう堅牢でなくてはならない。

  4. 相互作用不要：受取り側と直接インタラクティブなやり取りをすることなく、送金側のみでAMP支払いが準備可能である。これはほとんど、送信者が支払いに関係するノードの数を選択できることを意味し、かつ、今までのinvoiceベースの支払いも可能な状態を維持する。

Atomic Multi-Path Payment

(1) not re-using any payment hashes across all payment flows, and
(2) adding a strong guarantee that the receiver won't be paid until all partial payment flows are extended.
We call this scheme AMP
(Atomic Multi-path Payments).

前提事項を満たす仕組みが、AMPとなる。送金者、受信者のやり取りの変更のみであり、現在のlightningのprotocolへのいかなる変更も必要としない。

簡単にまとめると、オニオンルーティングのpayloadで未使用スペースとなっている箇所に、このプロトコル用のシグナルを追加して、完全なpre imageを取得するまで受信者が支払いを受け取れないようにする方法だ。

オニオンルーティングについては一旦別の場所で理解することにして、今回はここの仕組みに焦点を絞る。

Benefit

これができると、下記の利点がある。

  1. 大きなキャパシティをチャンネルにもつ必要がなくなる。結果的には、支払いグラフは拡散することになる。

  2. 大きな額の支払い手数料を下げる可能性がある。

  3. 複数のnodeに分散して支払えるため、論理的な最大支払い額を大きくすることができる。

  4. いくらの支払いを実施したかが分散するため、プライバシーが向上する。

  5. 少額支払いであってもパスが分散するため、支払い履歴の分析が困難になる。

ここから技術核心になるわけだけど、これは分ける。 にしても、Lightning Networkって異様に複雑だ。