Bitcoinのソフトフォークのデプロイ方法

Bitcoinのソフトフォークの 
デプロイ方法 

View Slide

1
ソフトフォークとは？ 
後方互換性を維持したままコンセンサスルールを変更する方法 
→ 新しい機能が実装されていない古いノード実装も動作し続ける 
 
Block 
旧ルール 
Block 
旧ルール 
Block 
旧ルール 
Block 
新ルール 
Block 
新ルール 
Block 
新ルール 
新ルール 
新ルールは、旧ルールの制限をより厳しくするもの 
● ブロックサイズを小さくする　→旧ルールのコンセンサスでも有効 
● 予約opcodeに新たなルールを課す 
● 未定義のsegwit versionに新しいルールを課す 
 
→旧ルールのコンセンサスでは誰もが使用可能 
（Anyone can sped） 
ソフトフォークのデプロイは、新ルールのアクティベートタイミングを
 
ネットワークで合意するための仕組み
 

View Slide

2
Block height指定 
アクティベートするブロックの高さをハードコードするデプロイ方法 
 
● 2009年12月22日: nLocktimeをコンセンサスルールに追加 
（Bitcoinで初めてデプロイされたソフトフォーク） 

View Slide

3
Block height指定+ハッシュレート測定 
ブロック高のハードコードとネットワークハッシュレートの組み合わせ 
 
● 2012年2月: OP_EVALの導入 
https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki  
2012年2月1日をアクティベートターゲットとし、マイナーは作成するブロックに  
文字列”OP_EVAL”を記載する。2012年1月15日までに OP_EVALを記載した 
ブロックが50％未満の場合、アクティベートを延期。  
→リリース前に脆弱性が見つかり、導入は中止に。 
 
● 2012年4月:P2SHの導入 
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki  
2012年3月1日をターゲットとしたが、2月15日時点で50%未満で延期。  
2012年4月1日をターゲットとし、3月15日で十分なサポートが得られ、  
Bitcoin Core 0.6.0をリリースし、4月1日にアクティベート成功。  

View Slide

4
IsSuperMajority（ISM） 
Blockのversionを利用したアクティベーションルール 
 
1. 75%ルール 
直近1000ブロック内の75%がversion nのルールに従っている場合、 
version nのルールに従わないブロックを拒否する。 
 
2. 95%ルール 
直近1000ブロック内の95%がversion nのルールに従っている場合、 
versionがn-1のブロックを拒否する。 
 
ブロック高とは関係なく、ネットワークのハッシュレートのみで 
アクティベーションされるようになる 

View Slide

5
IsSuperMajorityを使ったデプロイ 
● Version 2（2012年）： 
Coinbase TxのscriptSigにブロック高を記録する（TXIDの重複無効化）
 
https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
 
 
● Version 3（2015年）：String DER signature 
厳密なDER形式の署名フォーマットを適用
 
 
→アクティベート後に不正なバージョンを含むブロックを作成するマイナーが2回発生。  
　一時的にチェーン分岐し6個と3個の無効ブロックが作られる（不正利用はなし）  
 
● Version4（2015年）：OP_CHECKLOCKTIMEVERIFY(OP_CLTV)導入 
 
提案はCLTVの方が先だったが緊急性からBIP 66が先行される。 
→同時にデプロイできない制限 

View Slide

BIP 9 version bits 
IsSuperMajorityの課題を解決する新しいデプロイ方法 
 
● 並列デプロイをサポート 
 
 
 
 
 
 
● デプロイ期間を設定： 
タイムアウト期間までに閾値に達しない場合は、アクティベート失敗 
● マイナーの無効ブロック作成のリスクを軽減： 
version bitsはシグナリングのみで、ブロック自体が無効になることはない 
ブロックヘッダ 
バージョン 
前のブロックのハッシュ
 
マークルルート 
...  固定値各ソフトフォークのシグナリングに使われるビット領域
最大29個のソフトフォークを同時にデプロイ可能
retarget period(2016ブロック＝約２週間)毎に評価  
95%のブロックのビットが立っていれば LOCKED_INになり、 
次のretarget periodでACTIVE。 
 

View Slide

7
BIP9を使ったデプロイ 
● version bit 0（2016年）：相対的なロックタイムの導入 
○ Relative locktime 
 
○ OP_CHECKSEQUENCEVERIFY(OP_CSV)
 
 
○ Median time-past 
 
 
● version bit 1（2017年）：Segregated witness 
BIP 141/143/147 
→ version bitsが準備完了のシグナリングではなくマイナーによる投票として扱われる  

View Slide

Segwitアクティベートのための試み 
● BIP 148：UASF 
 
2017年8月1日以降、BIP 9のversion bit 1をシグナリングしないブロックを拒否する。
 
→ チェーン分岐のリスクが高まる。
 
● BIP 149： 
 
Segwitがアクティベートされず2017年11月にタイムアウトした場合にトリガーされ、2018年7月に
Segwitをアクティベートする。ただし、支持を得ることは無かった。 
● BIP 91： 
 
version bit 4を使用し、このBIPがアクティベートされたら、それ以降のブロックに
version bit 1の
シグナリングを強制するという内容。2段階のアクティベートで
 
BIP 148のチェーン分岐リスクを低減しようとするもの。
 
→ 実際にアクティベートされ、その後
Segwitもアクティベートされる。 
 

View Slide

9
BIP-8 
BIP 9がマイナーの投票のように扱われたことから、 
確実にソフトフォークをアクティベートするデプロイ方法が提案される。 
https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki 
 
アクティベーション期間に達すると、ソフトフォークがアクティベートする。 
 
その後の変更で、LOCKINONTIMEOUTパラメータが導入され、 
● LOT = true 
タイムアウト前の最終retarget periodでSFのシグナリングを行う 
● LOT = false 
シグナリングを強制されず、タイムアウトまでに 
アクティベートされなければソフトフォークは失敗 

View Slide

10
Speedy Trial 
Taproot/Tapscript（BIP 341/342）の安全な早期導入にむけた新しいデプロイ方法の提案
 
 
● マイナーのシグナリング期間の制限
 
BIP 9がスタートタイム〜タイムアウトまで（基本1年間）、すべてマイナーが 
シグナリング可能だったのに対し、Speedy Trialでは、 
スタートタイム〜3ヶ月をシグナリング期間とし、閾値は90%。 
● アクティベートまでの猶予期間 
スタートタイム〜3ヶ月でLOCK_INしたら、丸ヶ月後にアクティベートする。 
 
Speedy Trialにより3ヶ月でLOCK_INしない場合、別のデプロイ手段へ切り替えが可能。
 
 
Bitcoin Core 0.21.1はBIP 9をベースにSpeedy Trialを実装： 
● version bit 2 
● min_activation_height パラメータを追加（ブロック #709632） 
● 2021年4月24日をスタートタイムとし、マイナーのタイムアウトは8月11日以降のRP。  
https://taproot.watch/  
→ LOCK_INしたら2021年11月上旬〜中旬にアクティベート予定
 

View Slide

Bitcoinのソフトフォークのデプロイ方法

Bitcoinのソフトフォークのデプロイ方法

shigeyuki azuchi

More Decks by shigeyuki azuchi

Other Decks in Technology

Featured

Transcript