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
Extension Block
Search
shigeyuki azuchi
January 21, 2020
Technology
0
28
Extension Block
GBEC動画解説コンテンツのスライドです。
https://goblockchain.network/2020/01/extension-block/
shigeyuki azuchi
January 21, 2020
Tweet
Share
More Decks by shigeyuki azuchi
See All by shigeyuki azuchi
Replacement Cycling Attack
azuchi
0
12
Bitcoinのタイムロックの仕組み
azuchi
0
8
Inner Product Argument
azuchi
0
25
Codex32
azuchi
0
9
PSBT
azuchi
0
31
Trampoline Payment
azuchi
0
15
KZG Commitment
azuchi
0
99
Silent Payment
azuchi
0
62
FROST
azuchi
0
9
Other Decks in Technology
See All in Technology
[新卒向け研修資料] テスト文字列に「うんこ」と入れるな(2024年版)
infiniteloop_inc
4
16k
今年のRubyKaigiはProfiler Year🤘
osyoyu
0
170
Janus
bkuhlmann
1
490
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
320
Além do else! Categorizando Pokemóns com Pattern Matching no JavaScript
wmsbill
0
640
DevOpsメトリクスとアウトカムの接続にトライ!開発プロセスを通して計測できるメトリクスの活用方法
ham0215
2
240
Tellus の衛星データを見てみよう #mf_fukuoka
kongmingstrap
0
210
ServiceNow Knowledge 24の歩き方 EYストラテジー・アンド・コンサルティング
manarobot
0
200
【NW X Security JAWS#3】L3-4:AWS環境のIPv6移行に向けて知っておきたいこと
shotashiratori
0
350
長期間TiDBを使ってきた話 @ 私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT / Experiences with TiDB Over Time
chibiegg
2
900
JAWS-UG Bedrock Claude Night
yamahiro
3
610
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.8k
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1025
450k
Building Adaptive Systems
keathley
31
1.9k
Code Review Best Practice
trishagee
55
15k
Infographics Made Easy
chrislema
238
18k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.6k
[RailsConf 2023] Rails as a piece of cake
palkan
23
4k
Reflections from 52 weeks, 52 projects
jeffersonlam
345
19k
How to Ace a Technical Interview
jacobian
272
22k
The Invisible Side of Design
smashingmag
294
49k
Designing with Data
zakiwarfel
96
4.8k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
Designing on Purpose - Digital PM Summit 2013
jponch
110
6.5k
Transcript
【Bitcoin】Extension Block
1. ブロックチェーンの機能追加の仕組み 2. Soft-forkでブロックサイズを増やす Auxiliary Blockの提案 3. Extension Blockの仕組み 4.
Litecoinで提案されている Extension Blockの導入 1 今日話すこと Extension Block
ブロックチェーンのコンセンサスルールに影響する変更を加える際の方法 • Soft-fork 既存のルールをより厳しくする際に使用するアップグレード方法で、 アップグレードしていない旧ノードもそのまま動作する。 ◦ ブロックサイズの縮小:32MB → 1MB
◦ OP_NOPに検証ルールを追加(OP_CLTV, OP_CSV) ◦ 新しいルールをサポートするsegwit version, programを追加 • Hard-fork(Network Upgrade) 既存のルールを易しくする際に使用するアップグレード方法で、 全ノードのアップグレードが必要。 ◦ ブロックサイズの拡大: 1MB → 2MB ◦ コンセンサスアルゴリズムの変更PoW→PoS 2 ブロックチェーンの機能追加の仕組み
3 Soft-forkでブロックサイズを拡大? 2013年にJahnson Lauが提案したSoft-forkでブロックサイズを拡大する方法。 Block Block Block Block Auxiliary Block
Auxiliary Block Auxiliary Block Auxiliary Block Block Auxiliary Block Auxiliary Blockでもメインチェーンと同様Bitcoinの送金ができる。 ① <serialized script x> OP_AUX という scriptPubkey宛にコインを送金する。 Tx ② 対応するAuxiliary BlockのコインベースTxに 同量のコインを持つUTXOが作られる。 UTXO: <serialized script xを展開したもの> コインがメインBlockからAuxiliary Blockに移動 Coinbase Tx コインがAuxiliary BlockからメインBlockに移動 ④ コインを <serialized script y> OP_AUX OP_RETURN 宛に送金する。 Tx ⑤ 対応するメインBlockで未使用のOP_AUXのUTXOを選択 し、ロックされているコインを同量、 <serialized script yを展開したもの> 宛に送金する。 ※ OP_RETURN によりAuxiliary Block 上の コインは消滅する。 ③ Auxiliary Blockの全Txのマークルルートが メインBlockのコインベースTxに記録される。
4 新旧ノードの振る舞い Block Block Block Block Auxiliary Block Auxiliary Block
Auxiliary Block Auxiliary Block Block Auxiliary Block Auxiliary Blockはどんなブロックサイズでもよく、コンセンサスルールも自由に設計できる。 ① <serialized script x> OP_AUX という scriptPubkey宛にコインを送金する。 Tx Coinbase Tx ③ コインを <serialized script y> OP_AUX OP_RETURN 宛に送金する。 Tx 新ノード 旧ノード 旧ノードから見ると OP_AUX = OP_NOPであるため、 このUTXOは誰もが使用可能なUTXOと認識する。 つまり、そのまま動作可能。 ※ 但し使おうとしても新ノードによるマイニングにより実際は使えない。 旧ノードはAuxiliary Blockについては関知しない。 新ノードは、以下の検証を行う。 • メインBlock<->Auxiliary間のコインの移動が正しく行 われているか • Auxiliary Blockのトランザクションが 新しいルールの下、有効か
5 Extension Blockの仕組み • 既存のメインBlockと1対1で対応するExtension Blockを用意する。 コインをメインBlockからExtension Blockへ移動させることで、Extension Block上では メインBlockのコンセンサスに縛られない
新しいルールの下で取引が可能になる。 ◦ Peg-in:メインBlockのコインをあるルールの下、ロックすることで メインBlockのコインをExtension Blockに移動する。 ◦ Peg-out:Extension Blockのコインをあるルールの下、 消滅させることでコインをメインBlockに戻す。 • 旧ノードはそのまま動作するため、従来ハードフォークが必要だった変更も ソフトフォークでの導入が可能になる。
6 Litecoinで提案されているExtension Block LitecoinにExtension Blockの導入を提案するLIP-0002 https://github.com/litecoin-project/lips/blob/master/lip-0002.mediawiki Block Block
Block Block Extension Block Extension Block Extension Block Extension Block Block Extension Block ① 新しいwitness program <ver> <commitment> 宛にコインを 送金してメインBlockのコインをロックする Peg-in Txを作成する。 Peg-in Tx ② 対応するEBのコインベースTxに 同量のコインを持つ UTXOが作られる。 UTXOのアンロック条件は <commitment>と対応する。 Coinbase Tx ③ コインをLitecoinのアドレスへのコミットメントの宛に 送金するPeg-out Txを作成する。 Peg-out Tx ExtAddrのscriptPubkeyは↓ ExtVer <eb_commitment> eb_commitmentは対応するEBのコミットメントで、 MimblewimbleのEBの場合は、 • EB内の全Txのトランザクションカーネル • EB内のUTXOセット のデータからコミットメントが作られる。 1つのIntegration Txにつき1つのExtAddrアウトプットが 作られ、そのブロック時点 EB側のコインの総量がロックされる。 ④ マイナーはメイン Block内のPeg-in Txを収集し、 EB内のPeg-out Txを収集し、Integration Txを 作成し、メインBlockの最後に配置する。 Integration Tx In 前のBlockのExtAddr UTXO Peg-in UTXO A Peg-in UTXO B Out ExtAddr UTXO Peg-Out UTXO Ⅰ Peg-Out UTXO Ⅱ
7 まとめ • Extension BlockはメインチェーンのBlockと1対1で対応するブロック ◦ EB側のブロックにコインを移動し、EB内では任意の コンセンサスルールを実行する拡張方法の1つ。 今までHFを必要としていた変更もSFで可能になる。 •
コインの移動の表現がサイドチェーンに似ているが、 ◦ コインの移動やEBのコンセンサスもメインチェーンの アップグレード済みフルノードにより検証される。 ◦ EB作成の手数料はメインBlockのコインとして徴収できる。 ◦ メインBlock、EBの両方がフルノードによって検証されるため、 フルノードの検証コストは上がる。 ◦ EBにはマイニング報酬はなく手数料報酬のみである。 ▪ メインBlockのTx手数料とEBのTx手数料のレートは異なるかもしれない。