BIP 34 ビットコインブロックのバージョンアップ(aka. softfork, v1 → v2)
Segwit なかなか有効化されないなあ…ところでビットコインのバージョンアップはどのように行われるのだろう?と疑問に思ったので BIP を眺めてきました。BIP とは Bitcoin Improvement Proposal の略で、ビットコインの改善提案ですかね、がまとめられているものです。GitHub で公開されています。
Segwit は BIP 9 の手順でデプロイされるようですが、BIP 9 から BIP 34 への参照があったので先に BIP 34 を見てみました。
BIP 34 は
Block v2, Height in Coinbase
ということで、バージョン1からバージョン2へバージョンアップする際の手順を示した BIP です。バージョン2では scriptSig という場所の最初に coinbase の height を入れることにしたようです。 BIP 34 には実際の実装を行った pull request へのリンクも貼られています。コードを見ると理解が深まります。良い。
各ブロックにバージョンが埋め込まれており、マイナーの間にどれくらいバージョン2以降が浸透しているか(過去nブロックにおけるバージョンを確認する)によって挙動を変えています。
- バージョンアップ率 75%以上: 過去1000ブロック中、750ブロック以上がバージョン2以降である
- バージョン2以降であり、scriptSig の最初に height を持っていないブロックは捨てる
- バージョンアップ率 95%以上: 過去1000ブロック中、950ブロック以上がバージョン2以降である
- バージョン1のブロックは拒否する
さて Decentralize で皆が好き勝手にやっているビットコインネットワークでバージョンアップが成功するのでしょうか?ブロックのバージョンはブロックヘッダの最初の4バイトです。ブロックヘッダを書くのはマイナーなので、マイナーがバージョンアップするか、バージョンアップするモチベーションがあるかが焦点になります。
旧バージョンでのブロック受け入れ判定のコードを見ると、ブロックのバージョンによって拒否はしていないようです。 従ってバージョンアップ率ごとのブロック受け入れ状態は次のようになります。
- 0% ~ 75%
- 旧バージョン利用マイナー: ブロックは受け入れられる
- 新バージョン利用マイナー: ブロックは受け入れられる
- 75% ~ 95%
- 旧バージョン利用マイナー: ブロックは受け入れられる
- 新バージョン利用マイナー: ブロックは受け入れられる
- 95% ~ 100%
- 旧バージョン利用マイナー: ブロックは受け入れられない
- 新バージョン利用マイナー: ブロックは受け入れられる
旧バージョン利用マイナーはブロックが受け入れられない可能性が出てきます。 せっかく計算資源を消費してマイニングしたブロックが受け入れられないとマイナーとしては何をしているかわかりません。バージョンアップするモチベーションはありそうです。
ところでバージョンアップ率が95%のとき、古いバージョンを動かしている5%のノードではバージョン1のブロックを受け入れ、その他大勢は受け入れないことになります。これは問題にならないのでしょうか? 一時的にはバージョン1のブロックが先頭に付いた状態のチェーンを5%のノードが採用する状態が出来ますが、マイニングパワーの95%が新しいバージョンとなっているので、すぐにバージョン1のブロックを含まないチェーンの方が長くなります。 ビットコインでは最長のチェーンを採用することになっているので、バージョン1のブロックを含むチェーンは採用されません。
今回は BIP 34 を見ましたが、BIP 9 もそのうち読みたい。どうやら複数の機能が並行で試せるようになっているみたい(?)