Develop with pleasure!

福岡でCloudとかBlockchainとか。

version bitsを利用したソフトフォークのデプロイに対するマイナーの対応とISMによるソフトフォークとの違い

BIP-9として定義されているBitcoinのソフトフォークのデプロイメントプロセス

techmedia-think.hatenablog.com

に関して、Bitcoin Coreのブログにマイナー向けのQ&Aが掲載されて具体例を交えてマイナーがどう対応すればいいのか記載されてたので見てみる。

Bitcoin Core :: Version bits FAQ for miners

マイナーが行う対応

BIP-9では、ブロックのnVersionフィールドを使ってソフトフォークのデプロイス状況を判断する。
(nVersionフィールドにセットするversion bitやステータスの仕様についてはBIP-9参照)

マイナーはブロックを生成する際にnVersionフィールドを使ってソフトフォークに対する意思表示をする。

なんのソフトフォークもデプロイされていない場合

マイナーはversionフィールドに0x20000000をセットする。

なんらかのソフトフォークがデプロイされている場合

  • そのソフトフォークに賛成する場合
    そのソフトフォークに設定されているstart time後に、0x20000000と一緒に関連するversion bitを設定する。
  • ソフトフォークがアクティベートされたか、FAILEDステータスになった場合
    version bitsには何もセットしない。
  • そのソフトフォークに反対の場合はversion bitsには何もセットしない。

マイナーの95%が対象期間にソフトフォークに賛成すると、そのソフトフォークはアクティベートされる。
ソフトフォークの状態がLOCKED_INになったら、その後のdifficulty retarget期間内(約2週間以内)に残りのマイナーもそのソフトフォークのルールに従う必要がある。

version bitsの設定方法

アリスがbit 0を使ってソフトフォークをデプロイした場合

マイナーが合意する場合、セットする値は0x1 + 0x20000000で、

f:id:techmedia-think:20160612165627p:plain

ボブがbit 1を使ってソフトフォークをデプロイした場合

マイナーが合意する場合、セットする値は0x2 + 0x20000000で、

f:id:techmedia-think:20160612165637p:plain

↑のソフトフォークが平行して存在する場合

マイナーが合意する場合、セットする値は0x3 + 0x20000000(0x1 + 0x2 + 0x20000000)で、

f:id:techmedia-think:20160612165755p:plain

ISMによるソフトフォークとの違い

ブロックのバージョンを2,3,4とアップデートした際のソフトフォークにはISM(IsSuperMajority)が使用された。
これは、1000ブロックの内950ブロックが新しいblock versionでマイニングされたら、新しいルールをアクティベートするというソフトフォークトリガーで、version bitsによるソフトフォークとは以下のような違いがある。

  1. ISMによるソフトフォークでは、アクティベーションされるとすぐに以前のバージョンのブロックは拒否される。例えば現在のブロックバージョンが4だとすると、次のソフトフォークでバージョン5にアクティベーションされるとすぐにバージョン4のブロックは全てリジェクトされる。
  2. version bitsによるソフトフォークがアクティベーションされると、ノードは単に新しいルールを適用するだけで、新しいルールに違反しない限りブロックをリジェクトするようなことはしない。
  3. ISMでは直前の1000ブロックを確認するが、version bitsの場合はmining difficulty retargets前の2016ブロックを確認する。(mining difficulty retargetsというのは、アクティベーションの対象期間のこと?)
  4. ISMにはタイムアウトのような概念は無いが、version bitsの場合はstart time とtimeoutの期間内にアクティベーションされる必要がある。