Develop with pleasure!

福岡でCloudとかBlockchainとか。

ブロックヘッダのバージョンについてソフトフォークのデプロイ以外の汎用利用を提案するBIP-320

Bitcoinのブロックヘッダにはバージョンを表すnVersionフィールドが存在する。現在このnVersionフィールドは、コンセンサスに影響するような新しい機能をソフトフォークで導入する際に、ソフトフォークの準備ができたことを各マイナーがシグナリングするのに使われている。(と言っても、Segwit以降新たなソフトフォークの計画はまだ発表されてないけど)

BIP-9で定義されたこの仕様は、nVersionフィールドをビット列として解釈し、ソフトフォークの対応状況をその各bitを使ってシグナリングしている。詳細な仕様ついては↓参照。

techmedia-think.hatenablog.com

BIP-9のversion bitsによるシグナリングにより、異なるソフトフォークを29個同時にデプロイできるようになっているが、実際にそんな数のソフトフォークを並行デプロイするようなことはこれまで無かったし、今後も考えにくい。

そこで、このブロックヘッダのnVersionフィールドをソフトフォークのデプロイ以外にも使用できるようにしようというのがBtcDrakによって提案されたBIP-320↓

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

簡単に説明すると、ブロックヘッダのnVersionフィールドは4バイト(32 bit)あるが、そのうち16 bitを汎用的な目的のために確保し、BIP-9のversion bitsの解釈から取り除こうという提案。16 bitを任意に利用できるようにすることで、マイニング効率の向上などに繋げようと。

一時期話題にあがったAsicBoostだが、covert型とovert型の内、Segwitのデプロイによりcovert型は実質不可能になったが(Bitcoin Cashでは可能)、overt型の方はバージョンローリングをする方式なので、ちょうどこのBIPの内容に当てはまる。AsicBoostの特許は、その所有者がブロックチェーンの防衛特許ライセンス↓

bitcoinmagazine.com

に加入したことで、BDPLに参加するメンバーはその特許が利用可能になっていることから、そのあたりの絡みもあっての提案なのかもね。まぁ実際に現段階でそういう使い方をされていることもあるので、適用には問題ないと思う(あと、そもそも29個並行デプロイとかないし)。

以下、BIP-320の定義内容。

動機

マイナーはnVersionフィールドのいくつかのbitを、様々な用途に使用したいと考えている。しかし現在は、マイナーによってアクティベートされるソフトフォークの調整に使用しているため、これらのbitをソフトフォーク以外のシグナリング目的で使用すると、フルノードが未知のソフトフォークだと認識して誤った警告を生成する。nVersionフィールドのbitを汎用的な使用のために確保することで、ノードソフトウェアがそれらのbitを無視するようにアップグレードすることができ、誤った警告を生成することもなくなる。汎用的な使用のために16 bitを確保しても、まだ13個のソフトフォークの並行デプロイが可能であり十分だ。

使用例

以下はnVersionフィールドの一部のbitを使用できるようにすることで得られる利益の一例だ。このリストは網羅的ではない。

Bitcoinのマイニングハードウェアは現在200ms未満で32 bitのnonceフィールドを使い切る。このためコントローラは多くの帯域幅とCPU時間を消費して新しいジョブを非常に頻繁に各マイニングチップに配布する必要がある。これはより多くのbitをローリングすることで大幅に削減できる。同じくブロックヘッダにあるnTimeの多くのbitをローリングするという方法もあるが、タイムスタンプをより長い時間に渡って歪める可能性があるので理想的ではない。

バージョンローリングをするAsicBoostでは、4方向の衝突を計算するのにnVersionフィールドから2 bit必要だ。任意の2 bitが使用できると、マイニング装置はStratumの「version-rolling」拡張を使ってどのbitがマイニングプールで使用されるか交渉することができる。

仕様

13から始まり28(0x1fffe000を含む)で終わるブロックヘッダのnVersionフィールドの16 bitを汎用的な使用のために確保され、BIP-8およびBIP-9の仕様からは削除される。nVersion bitに0xe0001fffのマスクを適用し、ソフトフォークのシグナリングおよびソフトフォークの警告に対してbit 13〜28を無視する。

参照実装

github.com

後方互換

アップグレードされていないノードは、この提案で確保されるbitをソフトフォークのシグナリングとして解釈し、さらに未知のソフトフォークの警告システムをアクティブにすることがある。

この提案を実装するのにソフトフォークは必要としない。

これが記載されている時点で、このBIPで確保しようとしている16 bitのいずれも既知のソフトフォークで確保されてはおらず、ハッシュレートの少なくない割合がすでにそれらのbitを使用していることを考慮すると、将来のソフトフォークでアクティベーションシグナリングにこれらのbitを使用すべきではない。