Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Fast Forward Protocol
shigeyuki azuchi
February 07, 2022
Technology
0
20
Fast Forward Protocol
GBEC解説動画の資料です↓
https://goblockchain.network/2022/02/fast-forward-protocol/
shigeyuki azuchi
February 07, 2022
Tweet
Share
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
OP_CTV(BIP-119)
azuchi
0
8
CoinPool
azuchi
0
11
LNで受信者の匿名性を提供するRoute Blinding
azuchi
0
14
Peer Swap
azuchi
0
14
LNDのgRPC/RESTインターフェース
azuchi
0
28
楕円曲線の点の乗算
azuchi
0
58
Vault
azuchi
0
16
Liquidity Ads in LN
azuchi
0
24
x-only Public Key
azuchi
0
23
Other Decks in Technology
See All in Technology
SPAとWebアプリケーションでCognitoの使い方はどう変わるのか? / How do we use cognito with SPA and web applications?
kitano_yuichi
0
410
やってみたLT会 Fleet Managerのススメ
yukiiiiikuma
PRO
0
410
EC/CRMの自社サービス開発をマネジメントするようになって1年でやってきたこととこれから / devio2022-takano-sho-road-to-good-development-team-management
masaru_b_cl
0
440
金融領域のマルチプロダクトを効率よく開発・運用するためのシステム基盤と組織設計について / 2022-07-28-multi-product-platform
stajima
0
150
CloudWatchアラームによるサービス継続のための監視入門 / Introduction to Monitoring for Service Continuity with CloudWatch Alarms
inomasosan
1
440
ログラスを支える技術的投資の仕組み / loglass-technical-investment
urmot
9
2k
Power Automate for desktopで 配信環境を改善してみた話
akiika
0
330
COSCUP x KCD Taiwan 2020 - 那些年我們在開源社群的日子 - Cloud Native Taiwan
pohsien
0
120
大声で伝えたい!定時に帰る方法
sbtechnight
0
240
ログ集約基盤をCloudWatchからOpenSearchに変えてみた
yuhta28
0
140
ソフトウェアアーキテクチャの基礎: Software Architecture in a Nutshell
snoozer05
31
9k
Step-by-Step MLOps and Microsoft Products
shisyu_gaku
2
600
Featured
See All Featured
How to name files
jennybc
40
63k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
226
15k
Debugging Ruby Performance
tmm1
65
10k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
498
130k
Embracing the Ebb and Flow
colly
73
3.4k
Six Lessons from altMBA
skipperchong
14
1.4k
5 minutes of I Can Smell Your CMS
philhawksworth
196
18k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
236
1.1M
Rebuilding a faster, lazier Slack
samanthasiow
62
7.3k
The Brand Is Dead. Long Live the Brand.
mthomps
46
2.7k
Designing for humans not robots
tammielis
242
24k
Navigating Team Friction
lara
175
11k
Transcript
Fast Forward Protocol
1 Fast Forward Protocol 秘密鍵をオフラインにしたままLN支払いを受けられるようにするプロトコル提案 https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003038.html • オフラインにできるのは受信者の秘密鍵のみ
• 送信者の秘密鍵はオンラインである必要がある →支払いをルーティングする場合も • 秘密鍵をオフラインにできるが、受信者自身はオンラインである必要がある • 強制クローズが実行された場合は、秘密鍵をオンラインにして対応が必要 メリットを受けるのは、LN支払いを受け入れるマーチャントなど
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
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>
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によるタイムロックが付与される
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 の ロックスクリプトと同じ
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の更新を 発生させないのがポイント
7 Fast Forwardのデメリット • 強制クローズ 支払いの度に、HTLC Txのチェーンが増えていくため、強制クローズした場合、 オンチェーンTxの手数料は既存のプロトコルより増加する。
定期的にCommitment Txの状態を更新する必要がある。 • HTLCの支払いに対して、O(n)で保持すべきTxが増える。 • 恩恵を受けれるのは自分が最終的な受信者である場合のみ ◦ 支払いを後続のノードにさらに転送する場合は、秘密鍵がオンライン ◦ 自分が最終受信者であることがピアには分かる。