Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マスタリング・ライトニングネットワークの歩き方
Search
shigeyuki azuchi
February 06, 2023
Technology
290
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
マスタリング・ライトニングネットワークの歩き方
ビットコインとか勉強会#73のスライドです。
https://www.youtube.com/watch?v=eVM-wSv6ZcI
shigeyuki azuchi
February 06, 2023
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
FORS
azuchi
0
8
クラスターmempool
azuchi
0
31
W-OTS+
azuchi
0
34
Shorのアルゴリズム
azuchi
0
56
DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
azuchi
0
42
Fiat-Shamir変換と注意点
azuchi
0
220
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
55
BIP-374 離散対数の等価性証明
azuchi
0
72
BIP-353 DNS Payment Instructions
azuchi
0
88
Other Decks in Technology
See All in Technology
千葉での単身赴任からAWSをやり続け、千葉に戻ってきた話
yama3133
1
120
組織における AI-DLC 実践
askul
0
140
テスト設計の本質を改めて考えてみる~生成AIを活用する時代だからこそ、作ったテストの説明性を高めよう~
yamasaki696
1
120
FPGAの開発コンペでZephyrを使ってみた
iotengineer22
0
210
“詰む”前に仕組みを作れ 〜技術の波に溺れないためのキャッチアップ術〜
takasyou
7
4.2k
4人目のSREはAgent
tanimuyk
0
270
作る力から、見極める力へ — AI時代に広がるエンジニアの価値と役割
rince
0
360
攻撃者がいなくてもAIエージェントはインシデントを起こす
nomizone
0
120
現場のトークンマネジメント
dak2
1
200
「勝手に広まる」人気 AI エージェントを爆速で作ろう!(AWS Summit Japan 2026講演資料)
minorun365
PRO
10
2.6k
螺旋型キャリアの生存戦略 / kinoko-conf2026
rakus_dev
1
1.2k
2026-06-24_人とAIの責務分離に基づく開発プロセスの提案.pdf
takahiromatsui
0
240
Featured
See All Featured
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
1.1k
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
240
The Invisible Side of Design
smashingmag
301
52k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
23k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
210
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
380
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
610
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.3k
How to Ace a Technical Interview
jacobian
281
24k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
140
Principles of Awesome APIs and How to Build Them.
keavy
128
18k
Transcript
マスタリング・ライトニングネットワークの歩き方 2023.01.31 ビットコインとか勉強会 #73
自己紹介 • 安土 茂亨(Shigeyuki Azuchi) • chaintope, Inc ◦ エンタープライズ向けブロックチェーンの開発
• Twitter: @techmedia_think • Blog: https://techmedia-think.hatenablog.com/ • OSS: ◦ bitcoinrb ◦ bech32rb ◦ kzg ◦ etc.. • GBEC: https://goblockchain.network/ • 共著/監修
Lightning Networkの概要を理解する • 1章:ざっくりとLightning Networkの概要を説明 • 2章:Lightning Networkが想定するユースケース • 3章:ペイメントチャネルを開いて閉じるまで
• 7章:Lightning Networkではどうやって、 トラストレスにオフチェーン決済を実現しているのか?仕組みを解説
4章 Lightning Networkのノード実装 • 主要なノード実装 ◦ Core Lightning(旧c-lightning) https://github.com/ElementsProject/lightning ◦
LND https://github.com/lightningnetwork/lnd ◦ Eclair https://github.com/ACINQ/eclair 各ノード実装について、 • ビルド方法の解説 • docker-composeを利用したテスト環境での動作確認 付録Bにて、簡単なDockerのセットアップと使用方法を提供
5章 ノードの運用 • ノード運用のハードルを下げる便利なツール •
ノードの管理 ◦ セキュリティ ◦ バックアップ ◦ 可用性 ◦ チャネル管理 1〜5章で、Lightning Networkの概要と 実際に使ってみるために必要なことを解説
8章 ルーティング 複数のペイメントチャネルを使って、支払いをルーティングする Secret C SHA-256( C) • 3日後までに、
Cが分かれば、5,200 sat支払い • 2日後までに、 Cが分かれば、5,100 sat支払い • 1日後までに、 Cが分かれば、5,000 sat支払い Fee Fee ① インボイスをリクエスト ② シークレットを生成 ③ インボイス ④ パスに沿ってチャネルを更新 Alice Bob Mike Carol
8章 ルーティング 複数のペイメントチャネルを使って、支払いをルーティングする Secret C • Cを開示して 5,200 satを受け取り
• Cを開示して 5,100 satを受け取り • Cを開示して、 5,000 satを受け取る Fee Fee 支払いの証明として シークレットを受け取る 逆順にパスに沿って支払いを受け取り チャネルを更新 Secret C Secret C Alice Bob Mike Carol
8章 ルーティング # 旧状態への対応 OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL OP_IF OP_CHECKSIG OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL OP_IF # HTLCによる送金成功 OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG OP_ELSE # 有効期限切れによるタイムアウト OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG OP_ENDIF OP_ENDIF 適切な受取人が、シークレットを 提供した場合に使用可能 有効期限が切れた場合に使用可 能 資金提供者のが資金を回収 チートしようした相手の資金を没収 Lightning Networkで使用されるコントラクト 各ノードは、協力してオフチェーンで チャネルの状態を更新するが、 このコントラクトをブロードキャストして オンチェーンで決済することも可能。
付録A Bitcoinの基本的概念 Lightning Networkの詳細な仕組みを見ていく前に抑えておきたいポイント • 公開鍵暗号とデジタル署名 • Bitcoinのトランザクション •
Bitcoin Script ◦ 公開鍵を使った資金のロック ◦ シークレットを利用した資金のロック ◦ マルチシグ ◦ タイムロック ▪ 相対的 ▪ 絶対的 ◦ 条件分岐やフロー制御
9章 チャネル操作 支払いに伴うチャネルの状態を更新するための、チャネル参加者のフローを解説 update_add_htlc HTLCによる支払いをオファー commitment_signed 支払いに伴う新しい状態 =新しいコミットメントTxの
署名を作成/送付 revoke_and_ack commitment_signed revoke_and_ack 古い状態を失効させ、 新しいTxへの署名を作成/送付 update_fulfill_htlc ︙ 受信者側から送られてきた シークレットを送信し、 支払いのHTLCを受け取り Secret OR update_fail_htlc / update_fail_malformed_htlc エラー/有効期限切れにより、 HTLCを削除 チャネルからHTLCを削除するため、削除後の状態を新しい状態として commitment_signed / revoke_and_ack をトリガー Alice Bob
… 10章 オニオンルーティング update_add_htlc update_add_htlc update_add_htlc Onion Payload •
ショートチャネルID: Bob <-> Mike • 転送金額: 5,200 sat • タイムアウト値: 700,038 Onion Payload • ショートチャネルID: Mike<->Carol • 転送金額: 5,100 sat • タイムアウト値: 700,018 Onion Payload • 転送金額: 5,000 sat • タイムアウト値: 700,018 • 合計金額: 5,000 sat • Payment Secret Alice Bob Mike Carol Bobのペイロード Bobの鍵 Mikeの鍵 Carolの鍵 Mikeのペイロード Carolのペイロード Version セッション鍵 HMAC Onion Packet 送信者は、セッション鍵で、 各ノードの鍵とECDHを行い、 共有シークレットを導出し、 各ノードのOnion Payloadを難読化 中継ノードが知るのは自分の前後のノードのみで、 誰から誰への支払いなのかは分からない。
11章 チャネルグラフ Lightning Node Lightning Node Lightning Node Lightning Node channel
Node Channel Node 初めて起動したノードは、ネットワークに参加するため、 DNSサーバーに、Lightning Networkのノード情報を照会する https://github.com/cdecker/lseed Lightning Node DNS Server 返ってきたノード情報を元に、 ネットワーク内のノードに接続 ネットワークに参加すると、リモートピアから、 チャネルとノードに関する通知を受け取ることができる。 • node_announcement ノードに関する情報を公表 公開鍵、接続情報(IPアドレス、ポート) サポートする機能など • channel_annoucement 新しいチャネルの情報を公表 • chanel_update 各方向毎のチャネルの情報を公表 ◦ 手数料 ◦ タイムロックの差分 ◦ HTLCの最低金額 Lightning Node Channel Graph LNノードはこのチャネルグラフを 最新に保ちながら、支払いを ルーティング可能な経路を探索する
成長するLightning Network 2018年1月 2019年1月 2022年11月 • 約 17,000 ノード •
約 81,000 チャネル • 約 5,300 BTC(約155億円)
12章 経路探索 ネットワークにゴシップされるのはチャネルのキャパシティ(総量)のみ チャネルの参加者のどちらにどれだけの残高があるかは不明 ノードは、支払い額以上のキャパシティを持つ経路をピックアックし、 •
手数料(固定、比例) • タイムロック時間 • これまでの支払いの試行の成功確率 の重みを持つ有向グラフ(フローネットワーク)から、最適な経路を選択する。 ダイクストラ(Dijkstra)法など、最短経路問題のアルゴリズムを適用。 ※ MPP(Multi-Path Payment)など支払いの細分化アプローチも
13章 ワイヤープロトコル ネットワーク上でプロトコルメッセージを送信する際のエンコード方法を解説 • メッセージフォーマット メッセージタイプの付録Cにリストアップ •
TLV(Type Length Value) ◦ レコードのタイプを表す整数(BigSize) ◦ レコードの長さ(BigSize) ◦ レコード値 • 機能ビット サポートする機能を示す値(ビット番号奇数はオプション、偶数は必須) node_announcement / channel_announcement / init メッセージに含まれる メッセージタイプ(2バイト) 可変長メッセージペイロード(最大65KB) extension(TLV Stram)
14章 暗号化トランスポート層 Lightning Node Lightning Node E2Eの暗号化通信 • 1st Layerと異なり、すべての通信は暗号化される
(Onion Payloadの難読化とはまた別) • Noise_XK_secp256k1_ChaChaPoly_SHA256 を使用した暗号化 • 各内容について仕組みとフローを解説 ◦ 3段階のハンドシェイク ◦ 暗号化メッセージの作成と送信 ◦ 受信した暗号化メッセージに復号 ◦ 鍵のローテーション
15章 ペイメントリクエスト インボイスをリクエスト Alice Carol インボイスを送信 lnbc2500u1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwz qfqqqsyqcyq5rqwzqfqypqdq5xysx xatsyp3k7enxv4jsxqzpuaztrnwngzn3kdzw5hydlzf03qdgm2
hdq27cqv3agm2awhz5se903vruatf hq77w3ls4evs3ch9zw97j25emudupq63nyw24cg27h2rspfj9 srp bech32エンコードされたインボイス 1st Layerと違って、支払いの度にインボイスを作成する必要があり、 受信者はオンラインである必要がある。
16章 セキュリティとプライバシー • 1st Layerと比較したプライバシー ◦ 送金の秘匿性は向上(オフチェーン支払い、通信層の暗号化) ◦ ノードIDとIPアドレスの公開に伴うプライバシーのリーク
• 攻撃手法 ◦ プロービングを利用したチャネル残高の調査 ◦ プロービング結果のスナップショットから支払人、受取人の探索 ◦ ルーティングした金額とタイムロックの値から匿名セットを限定、 タイミング分析 ◦ 失敗する支払いによるDoS攻撃、 ◦ HTLCスロット/金額のロックアップ • クロスレイヤーの非匿名化 • スケールフリーなネットワーク・トポロジーに対する攻撃