Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Fast Forward Protocol

Fast Forward Protocol

C403a9e0b7bfed4c94020220b5ab89f7?s=128

shigeyuki azuchi

February 07, 2022
Tweet

More Decks by shigeyuki azuchi

Other Decks in Technology

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が増える。 
 
 • 恩恵を受けれるのは自分が最終的な受信者である場合のみ 
 ◦ 支払いを後続のノードにさらに転送する場合は、秘密鍵がオンライン 
 ◦ 自分が最終受信者であることがピアには分かる。