Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

shigeyuki azuchi

May 24, 2021
Tweet

More Decks by shigeyuki azuchi

Other Decks in Technology

Transcript

  1. Bitcoinのソフトフォークの

    デプロイ方法


    View Slide

  2. 1
    ソフトフォークとは?

    後方互換性を維持したままコンセンサスルールを変更する方法

    → 新しい機能が実装されていない古いノード実装も動作し続ける


    Block

    旧ルール

    Block

    旧ルール

    Block

    旧ルール

    Block

    新ルール

    Block

    新ルール

    Block

    新ルール

    新ルール

    新ルールは、旧ルールの制限をより厳しくするもの

    ● ブロックサイズを小さくする →旧ルールのコンセンサスでも有効

    ● 予約opcodeに新たなルールを課す

    ● 未定義のsegwit versionに新しいルールを課す


    →旧ルールのコンセンサスでは誰もが使用可能

    (Anyone can sped)

    ソフトフォークのデプロイは、新ルールのアクティベートタイミングを

    ネットワークで合意するための仕組み

    View Slide

  3. 2
    Block height指定

    アクティベートするブロックの高さをハードコードするデプロイ方法


    ● 2009年12月22日: nLocktimeをコンセンサスルールに追加

    (Bitcoinで初めてデプロイされたソフトフォーク)


    View Slide

  4. 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

  5. 4
    IsSuperMajority(ISM)

    Blockのversionを利用したアクティベーションルール


    1. 75%ルール

    直近1000ブロック内の75%がversion nのルールに従っている場合、

    version nのルールに従わないブロックを拒否する。


    2. 95%ルール

    直近1000ブロック内の95%がversion nのルールに従っている場合、

    versionがn-1のブロックを拒否する。


    ブロック高とは関係なく、ネットワークのハッシュレートのみで

    アクティベーションされるようになる


    View Slide

  6. 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形式の署名フォーマットを適用

    https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki

    →アクティベート後に不正なバージョンを含むブロックを作成するマイナーが2回発生。 

     一時的にチェーン分岐し6個と3個の無効ブロックが作られる(不正利用はなし) 


    ● Version4(2015年):OP_CHECKLOCKTIMEVERIFY(OP_CLTV)導入

    https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

    提案はCLTVの方が先だったが緊急性からBIP 66が先行される。

    →同時にデプロイできない制限


    View Slide

  7. BIP 9 version bits

    IsSuperMajorityの課題を解決する新しいデプロイ方法


    ● 並列デプロイをサポート







    ● デプロイ期間を設定:

    タイムアウト期間までに閾値に達しない場合は、アクティベート失敗

    ● マイナーの無効ブロック作成のリスクを軽減:

    version bitsはシグナリングのみで、ブロック自体が無効になることはない

    ブロックヘッダ

    バージョン

    前のブロックのハッシュ

    マークルルート

    ...
 固定値 各ソフトフォークのシグナリングに使われるビット領域
    最大29個のソフトフォークを同時にデプロイ可能
    retarget period(2016ブロック=約2週間)毎に評価 

    95%のブロックのビットが立っていれば LOCKED_INになり、

    次のretarget periodでACTIVE。


    View Slide

  8. 7
    BIP9を使ったデプロイ

    ● version bit 0(2016年):相対的なロックタイムの導入

    ○ Relative locktime

    https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

    ○ OP_CHECKSEQUENCEVERIFY(OP_CSV)

    https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

    ○ Median time-past

    https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki


    ● version bit 1(2017年):Segregated witness

    BIP 141/143/147

    https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
    https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki
    → version bitsが準備完了のシグナリングではなくマイナーによる投票として扱われる 


    View Slide

  9. Segwitアクティベートのための試み

    ● BIP 148:UASF

    https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

    2017年8月1日以降、BIP 9のversion bit 1をシグナリングしないブロックを拒否する。

    → チェーン分岐のリスクが高まる。

    ● BIP 149:

    https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki

    Segwitがアクティベートされず2017年11月にタイムアウトした場合にトリガーされ、2018年7月に
    Segwitをアクティベートする。ただし、支持を得ることは無かった。

    ● BIP 91:

    https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

    version bit 4を使用し、このBIPがアクティベートされたら、それ以降のブロックに
    version bit 1の
    シグナリングを強制するという内容。2段階のアクティベートで

    BIP 148のチェーン分岐リスクを低減しようとするもの。

    → 実際にアクティベートされ、その後
    Segwitもアクティベートされる。


    View Slide

  10. 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

  11. 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