Fast Forward Protocol

Fast Forward Protocol 

View Slide

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

View Slide

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

View Slide

3
現在のチャネル構成 
● to_remote 
相手の残高で、Commitment Txが承認されると
 
すぐに利用可能。 
（Anchorチャネルの場合、1承認待つ）
 
● to_local（自身の残高） 
Commitment Tx 
In 
Out 
to_remote 
Funding UTXO 
to_local 
OP_IF
# 旧状態がブロードキャストされた場合のペナルティ用
OP_ELSE
`to_self_delay`
OP_CSV
OP_DROP

OP_ENDIF
OP_CHECKSIG 
to_local
Offered/Received HTLC (P2WSH)  
● revocation key  
● CLTV  
●  

View Slide

4
Fast Forwardのチャネル構成 
Commitment Txの各アウトプットを対称的な内容に更新し、
 
Remote Penalty Claim Keyという新しい鍵を導入する。 
 
 
OP_IF
# ペナルティ・トランザクション用
OP_CHECKSIGVERIFY

OP_ELSE
`to_self_delay`
OP_CSV
OP_DROP

OP_ENDIF
OP_CHECKSIG
OP_IF
# ペナルティ・トランザクション用
OP_CHECKSIGVERIFY

OP_ELSE
`to_self_delay`
OP_CSV
OP_DROP

OP_ENDIF
OP_CHECKSIG
to_local to_remote
これまで、to_remoteは、相手がブロードキャストしたらすぐに利用可能だったが、  
to_localと同様OP_CSVによるタイムロックが付与される  

View Slide

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 による署名 
アリスの 
※ HTLCはCommitment Txにアウトプットが追加されるのではなく、子Txで処理される
 
鍵が違うだけで、  
基本的にCommitment Tx の 
ロックスクリプトと同じ  

View Slide

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

View Slide

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

View Slide

Fast Forward Protocol

Fast Forward Protocol

shigeyuki azuchi

More Decks by shigeyuki azuchi

Other Decks in Technology

Featured

Transcript