Fast Forward Protocol

GBEC解説動画の資料です↓

https://goblockchain.network/2022/02/fast-forward-protocol/

Transcript

1. Fast Forward Protocol

2. 1 Fast Forward Protocol
 秘密鍵をオフラインにしたままLN支払いを受けられるようにするプロトコル提案
 https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003038.html 
 
 • オフラインにできるのは受信者の秘密鍵のみ
 • 送信者の秘密鍵はオンラインである必要がある
 →支払いをルーティングする場合も
 • 秘密鍵をオフラインにできるが、受信者自身はオンラインである必要がある
 • 強制クローズが実行された場合は、秘密鍵をオンラインにして対応が必要
 
 メリットを受けるのは、LN支払いを受け入れるマーチャントなど
 

3. 2 現在のチャネル構成
 現在のLNチャネルは、
 各支払いの都度、チャネル参加者の各残高を更新した 
 新しいCommitment Txと署名を
 お互いに作成し、交換する。
 
 
 
 署名作成のため、支払い＝チャネルの更新時には 
 秘密鍵へのアクセスが必要になる。 
 Commitment Tx1
 In
 Out
 to_remote (P2WPKH) 
 Funding UTXO
 to_local (P2WSH) 
 • <timelock> CSV to_local 
 • revocation key to_remote 
 Commitment Tx2
 In
 Out
 to_remote (P2WPKH) 
 Funding UTXO
 to_local (P2WSH) 
 • <timelock> CSV to_local 
 • revocation key to_remote 
 Commitment Tx3
 In
 Out
 to_remote 
 Funding UTXO
 to_local 
 • <timelock> CSV to_local 
 • revocation key to_remote 

4. 3 現在のチャネル構成
 • to_remote
 相手の残高で、Commitment Txが承認されると 
 すぐに利用可能。
 （Anchorチャネルの場合、1承認待つ） 
 • to_local（自身の残高）
 Commitment Tx
 In
 Out
 to_remote
 Funding UTXO
 to_local
 • <timelock> CSV to_local 
 • revocation key to_remote 
 OP_IF <revocationpubkey> # 旧状態がブロードキャストされた場合のペナルティ用 OP_ELSE `to_self_delay` OP_CSV OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIG
 to_local Offered/Received HTLC (P2WSH) 
 • revocation key 
 • <timelock> CLTV 
 • <preimage> 

5. 4 Fast Forwardのチャネル構成
 Commitment Txの各アウトプットを対称的な内容に更新し、 
 Remote Penalty Claim Keyという新しい鍵を導入する。
 
 
 OP_IF # ペナルティ・トランザクション用 <local_revokepubkey> OP_CHECKSIGVERIFY <remote_penaltyclaimpubkey> OP_ELSE `to_self_delay` OP_CSV OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIG OP_IF # ペナルティ・トランザクション用 <local_revokepubkey> OP_CHECKSIGVERIFY <remote_penaltyclaimpubkey> OP_ELSE `to_self_delay` OP_CSV OP_DROP <remote_delayedpubkey> OP_ENDIF OP_CHECKSIG to_local to_remote これまで、to_remoteは、相手がブロードキャストしたらすぐに利用可能だったが、 
 to_localと同様OP_CSVによるタイムロックが付与される 

6. 5 Fast Forwardのチャネル構成
 Commitment Tx A
 In
 Out
 to_remote
 Funding UTXO
 to_local
 Commitment Tx B
 In
 Out
 to_remote
 Funding UTXO
 to_local
 Fast Forward HTLC Tx A
 Fast Forward HTLC Tx B
 In
 Out
 Commitment Tx AのUTXO 
 In
 Out
 Commitment Tx BのUTXO 
 Aのお釣り
 A→BへのHTLC 
 Aへのお釣り 
 A→BへのHTLC 
 アリス→ボブへの支払いが発生した場合
 ボブの署名
 アリスの署名
 OP_IF <アリスの revokepubkey> OP_CHECKSIGVERIFY <ボブの penaltyclaimpubkey> OP_ELSE `to_self_delay` OP_CSV OP_DROP <アリスの delayedpubkey> OP_ENDIF OP_CHECKSIG OP_IF <ボブの revokepubkey> OP_CHECKSIGVERIFY <アリスの penaltyclaimpubkey> OP_ELSE `to_self_delay` OP_CSV OP_DROP <アリスの delayedpubkey> OP_ENDIF OP_CHECKSIG アリスの
 Penalty Claim Key による署名
 アリスの
 Penalty Claim Key による署名
 ※ HTLCはCommitment Txにアウトプットが追加されるのではなく、子Txで処理される 
 鍵が違うだけで、 
 基本的にCommitment Tx の
 ロックスクリプトと同じ 

7. 6 その後のHTLCの更新
 Fast Forward HTLC Tx A
 Fast Forward HTLC Tx B
 In
 Out
 Commitment Tx AのUTXO 
 In
 Out
 Commitment Tx BのUTXO 
 Aのお釣り
 A→BへのHTLC 
 Aへのお釣り 
 A→BへのHTLC 
 アリスの
 Penalty Claim Key による署名
 アリスの
 Penalty Claim Key による署名
 Fast Forward HTLC Tx A2
 Fast Forward HTLC Tx B2
 In
 Out
 FF HTLC Tx AのUTXO 
 Aのお釣り
 A→BへのHTLC 
 In
 Out
 FF HTLC Tx BのUTXO 
 Aのお釣り
 A→BへのHTLC 
 アリスの
 Penalty Claim Key による署名
 アリスの
 Penalty Claim Key による署名
 アリス→ボブへの支払いが発生した場合
 ・・・ 支払いはすべてFast Forward HTLC Tx の
 チェーンになる。
 
 Txをブロードキャストするための条件は 
 • 自分が持つRevocation Keyによる署名 
 • 相手が持つPenalty Claim Keyによる署名 
 
 
 Fast Forward HTLC Txは相手の資金をインプットとした 
 Txであるため、Tx作成時に自身の秘密鍵による署名を 
 相手に渡す必要がない。 
 アリス（送信者）の署名はTxの作成時＝状態更新時に 
 Txと一緒に相手から送信される。 
 
 
 
 
 ※ 資金を受け取るだけであれば、自身の秘密鍵は不要、 
 　つまり、オフラインのままでいい。 
 
 両者の秘密鍵を必要とするCommitment Txの更新を 
 発生させないのがポイント 

8. 7 Fast Forwardのデメリット
 • 強制クローズ
 支払いの度に、HTLC Txのチェーンが増えていくため、強制クローズした場合、 
 オンチェーンTxの手数料は既存のプロトコルより増加する。 
 定期的にCommitment Txの状態を更新する必要がある。 
 
 • HTLCの支払いに対して、O(n)で保持すべきTxが増える。 
 
 • 恩恵を受けれるのは自分が最終的な受信者である場合のみ 
 ◦ 支払いを後続のノードにさらに転送する場合は、秘密鍵がオンライン 
 ◦ 自分が最終受信者であることがピアには分かる。