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
Lightning Networkノード運用(2019年6月版)
Search
Nayuta
June 14, 2019
Technology
1
300
Lightning Networkノード運用(2019年6月版)
Lightning Networkの着金ノードを運用するときに気にすること。
Nayuta
June 14, 2019
Tweet
Share
More Decks by Nayuta
See All by Nayuta
Lightning Networkとは
nayutainc
0
210
Lightning Network Ptarmigan Hands-on
nayutainc
0
190
How to use Lightning Software
nayutainc
0
170
For_BCCC(20190520)
nayutainc
0
250
Other Decks in Technology
See All in Technology
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.6k
TanStack Routerに移行するのかい しないのかい、どっちなんだい! / Are you going to migrate to TanStack Router or not? Which one is it?
kaminashi
0
600
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
3
220
[CV勉強会@関東 ECCV2024 読み会] オンラインマッピング x トラッキング MapTracker: Tracking with Strided Memory Fusion for Consistent Vector HD Mapping (Chen+, ECCV24)
abemii
0
220
iOS/Androidで同じUI体験をネ イティブで作成する際に気をつ けたい落とし穴
fumiyasac0921
1
110
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
410
飲食店データの分析事例とそれを支えるデータ基盤
kimujun
0
100
アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato
shift_evolve
0
160
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
550
Terraform CI/CD パイプラインにおける AWS CodeCommit の代替手段
hiyanger
1
240
【若手エンジニア応援LT会】ソフトウェアを学んできた私がインフラエンジニアを目指した理由
kazushi_ohata
0
150
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
140
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
We Have a Design System, Now What?
morganepeng
50
7.2k
Building an army of robots
kneath
302
43k
Designing Experiences People Love
moore
138
23k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
A Tale of Four Properties
chriscoyier
156
23k
Automating Front-end Workflow
addyosmani
1366
200k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Building Adaptive Systems
keathley
38
2.3k
Done Done
chrislema
181
16k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Unsuck your backbone
ammeep
668
57k
Transcript
Lightning Network 着金ノード 2019年6月バージョン
前提 • Lightning Networkの詳細については踏 み込みません。 • 手数料や単位などは、省略するか、考慮 しません。 • 「お金」と書いたときは、Bitcoinだったり
Lightning Network上で扱うBitcoinだっ たりしますが、文脈で読み替えてくださ い。 • その他、話を簡単にするためにいろいろ とLightning Networkの説明を省略しま す。
ノード? BitcoinやLightning NetworkのようにP2Pで通信する場合、 サーバやクライアントのような明示的な役割分担がないため、 ノード(node)と呼ぶことが多い。 “Lightning Network”は長いので、以下ではLNと略します。
着金ノード? Bitcoinノードの場合、他のノードを検出するしくみがあるため、ア プリを起動すればなんとかなる。 LNノードにも同じようなしくみは用意されているのだが、まだ十分 に発達していないため、アプリを起動するだけでは足りないこと がある。 今回は特に着金に注目して、LNノードをどうするのがよいか検 討していく。
ノード接続 LNノードアプリを立ち上げたら、他のLNノードと接続しないと意 味が無い。 テストだけなら自分が立ち上げたLNノードたちを接続すれば良 いが、いろいろな人に使ってもらうためには外部のLNノードと接 続するのがよいだろう。 LNノードの接続は2段階あって、単なる接続と、チャネル接続が ある。意味があるのはチャネル接続の方である。
チャネル 2つのLNノード間で送金できる関係を「チャネル」という。 BitcoinでそれぞれのLNノードが管理するアドレスを作り、そこに 送金することでチャネルが作られる。 チャネルを作るのにはBitcoinのブロックチェーンが関係する。 LNノード作成には30分(3 confirmation)くらい時間がかかること が多い。 MultiSig
チャネルの作り チャネル作成する際、2つのLNノードのどちらかがBitcoinを送金 するようになっている。 送金するのは、LNプロトコルで「チャネルを作る」という要求を始 める方である。 そのため、チャネルを作るためにはBitcoinが必要である。 自分のLNノードであれば操作ができるので、自分からチャネル を作り始めるのは簡単である。 が、相手からチャネルを作ってほしいシーンは多い。 MultiSig
チャネルを作っ てください!
LNの送金 相手にチャネルを作ってほしい理由を知るには、LNの送金という ものを知る必要がある。 LNの送金は、バケツリレーのように送金元からのBitcoinがその まま中継されるのではない。 どちらかといえば、玉突きのように衝撃を反対側に伝えるような もので、A-B間のBitcoinがB-C間に移動することはない。 A B C
A B C A B C
LN送金の結果 話を単純化するため、チャネルに左のBitcoinが入った状態だとす る(単位は気にしない)。手数料なども無しとする。 この状態でAさんからCさんに4単位を送金したいとする。 そうすると、まずA-B間で4移動し、次にB-C間で4移動する。 BさんはAさん側とCさん側のそれぞれにチャネルがあるが、 Aさん側は4増えて、Cさん側は4減るだけで、A-B間からB-C間に移 動することはない。 送金後はBからCに送金できるのは1しかないため、AからCへも1ま でしか送金できない。
A B C 8 1 5 9 4 5 4 5 1 13 5 9
チャネルを作った直後 チャネルを作る際、片方の人しかBitcoinを送金しない。 そしてチャネルができると、片方にしかBitcoinがない状態から開 始することになる。 そうなると、チャネルを作った人から相手の方向には送金できる けれども、その逆の方向には送金することができない。 ものを売るなどの着金がメインのLNノードを作った場合、チャネ ルをたくさん作って送金してもらえるルートを作りたくなるが、自 分から作ってもあまり意味が無いのだ。 MultiSig
10 10 0 SHOP
相手にチャネルを作ってもらう つまり、最初から相手に送金してもらえる状態にするには、相手 からチャネルを作ってもらうのが早い。 簡単なところでは、自分のホームページなどにノードの情報を載 せておき、チャネルを作ってもらうようにお願いする、などだろう。 手数料がかかるかもしれないが、LNBIGやThorなどのサービス を利用して作ってもらうのも良いだろう。 SHOP
チャネルが生きている間 • チャネルを作った後、そのチャネルに入金はできない • チャネルを作ったときのBitcoinは、チャネルを閉じる以外に 取り戻す方法はない • 複数のチャネルを持っていても、それをまとめたりすること はできない •
つまり、着金するだけのサービスを運用する場合、相手に チャネルを作ってもらっても、いつかは相手の額が足りなく なることを意味する
チャネルの後始末 LN上にあるBitcoinは、そのままBitcoinとして使用することはで きない。使用したいのであれば、Bitcoinアドレスに送金する必要 がある。 LN上で送受金を何度行ったとしても、ブロックチェーンから見え ているのはチャネルを作るときに送金したときの情報だけであ る。 Bitcoinの送金を行うと元のトランザクションが使用済みになるの で、チャネルもまた使用済みになる。 MultiSig
LN上
個人の感想 • 最後に今までLN仕様について説明してきて、なかなか理解してもらえなかったことを感想として残しておこう。 • 1つは「送金」だ。送受金でもよいのだが、とにかくその言葉が混乱を招いていると思う。 ◦ 一対一の送金であれば混乱しないようだ ◦ 一対一の送金を繰り返すことで目的の送金先まで送り届けるとなると (ホップする、などという
)、Bitcoinのルールに縛られていると いうことを忘れてしまいがちである。すなわち、 BitcoinのINPUTをOUTPUTに割り振るだけになる、ということを忘れてしまいがち なのだ。 ◦ このBitcoinルールが何を意味するかというと、大きくは 2つだ。 ▪ チャネルに後からお金を入れることはできない • 足りなくなったら、別のチャネルを作る ▪ 送受金したお金は、各チャネルの中でしか移動しない • 「別のチャネルに全額転送して、片方のチャネルだけ閉じよう」 →できないか、意味が無い • なぜなら、送金は各チャネル内での移動にしかならないからだ。 • エネルギー保存の法則ではないが、チャネル内の Bitcoin総量はLN送受金によって変化しないのだ。 • もう1つも同じようなものだが、チャネルを閉じること、あるいは着金を手に入れることについてだ。 ◦ チャネルはそれぞれ独立している。 ◦ チャネルはBitcoinのMultiSigアドレス送金で作成しているので、それを Bitcoinで使えるようにするには送金された MultiSigアドレ スから各人に送金するしかない。 ◦ つまり、送受金した BitcoinをBitcoinとして使うためには、そのチャネルを閉じるしかない。 • 隠れた要因として、チャネルを作るのに時間がかかる、というのは忘れられがちである。 • チャネルにはannouncementというLNプロトコル仕様もあり、作ればすぐに認められるというものでも無い。