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
38
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
Fiat-Shamir変換と注意点
azuchi
0
26
AssumeUTXOを利用したブロックチェーンの同期
azuchi
0
6
BIP-374 離散対数の等価性証明
azuchi
0
24
BIP-353 DNS Payment Instructions
azuchi
0
40
OP_CAT and Schnorr Trick
azuchi
0
35
Pay to Anchorと1P1Cリレー
azuchi
0
38
プロアクティブ秘密分散法
azuchi
0
54
v3トランザクションリレー
azuchi
0
57
ランポート署名
azuchi
0
100
Other Decks in Technology
See All in Technology
Claude Code でアプリ開発をオートパイロットにするためのTips集 Zennの場合 / Claude Code Tips in Zenn
wadayusuke
4
490
「その開発、認知負荷高すぎませんか?」Platform Engineeringで始める開発者体験カイゼン術
sansantech
PRO
2
270
S3アクセス制御の設計ポイント
tommy0124
3
200
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
270
Automating Web Accessibility Testing with AI Agents
maminami373
0
1.3k
下手な強制、ダメ!絶対! 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは?
tsukaman
2
450
2025/09/16 仕様駆動開発とAI-DLCが導くAI駆動開発の新フェーズ
masahiro_okamura
0
110
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
580
AWSで始める実践Dagster入門
kitagawaz
1
720
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
470
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
130
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
500
Featured
See All Featured
Done Done
chrislema
185
16k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
Raft: Consensus for Rubyists
vanstee
140
7.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
Making the Leap to Tech Lead
cromwellryan
135
9.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
We Have a Design System, Now What?
morganepeng
53
7.8k
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手数料のレートは異なるかもしれない。