新しい規則をめぐる対立ではなく、検証がデータベース実装に隠れて依存していた。新しい LevelDB は入力数が異例に多いブロックを処理できた一方、従来版は Berkeley DB の既定ロック数を使い切った。そこで採掘者は互換ブランチへの復帰を調整し、後続の 0.8.1 が制御された移行を準備した。
2013 年三月 11 日、Bitcoin 0.8 を動かすノードがブロック 225 430 を採掘した。新バージョンは受け入れたが、0.7.2 以前の一部ノードは拒否したため、同じ親からそのブロックを含むブランチと含まないブランチが伸びた。違いは hash や proof of work 自体ではなく、ローカルのソフトウェアがそもそもブロックを有効と判断するかにあった。 [2]
引き金は単なるバイト単位のブロックサイズではない。ブロックには前例のない数のトランザクション入力があり、旧ノードは書き込み時に Berkeley DB の既定ロック数を使い切った。必要なロック数は各ノードのデータベースページ配置にも左右されたため、以前の最大サイズのテストブロックが通っても、より小さく本来は有効なブロックが失敗し得た。 [1]
Bitcoin 0.8 はブロックとトランザクションのインデックスを Berkeley DB から、同じロック上限を持たない LevelDB へ移した。当初は約 60 % のハッシュレートが 0.8 ブランチ上で構築したが、旧ノードは起点のブロックを拒否したため、その仕事量を数えなかった。最重チェーン規則はノードが先に有効と検証した履歴だけから選ぶので、この不一致を単独では解消できなかった。 [1]
Pieter Wuille は緊急警報を公開し、加盟店に決済処理の停止を勧めた。開発者と運用者の協議後、Eleuthria として知られる Michael Marsee が率いる BTCGuild と Marek Palatinus の Slush Pool は Bitcoin 0.7 に戻った。技術的に新しいブランチを永久に誤りとするのではなく、広く使われる両バージョンが検証できる履歴へ仕事量を速やかに集めることが目的だった。 [3]
互換ブランチが累積仕事量で先行すると、0.8 ノードはそこへ reorg し、元の 0.8 ブランチだけで採掘されたブロックは stale になった。BIP 50 は分裂中に少なくとも一件の大きな double spend を記録するが、事後報告では盗難目的ではなく実験だった。とはいえ、チェーン先端が不確かなときに取引所や加盟店が入金を止め、追加承認を待つ理由を示した。 [1]
Bitcoin Core 0.8.1 は 2013 年三月 18 日に公開された。三月 21 日から五月 15 日まで適用され、旧 peer が処理できないブロックの受け入れを防ぐ一時ルールと、ブロック 225 430 の内蔵 checkpoint を追加した。事後報告はさらに、10 000 ロックの推定上限、500 000 バイトの採掘上限、Berkeley DB のロック上限を 537 000 にした backport を示す。 [4]
一時的な互換性は最終状態ではない。旧ノード運用者は五月 15 日までに 0.8.1、更新済み backport、または明示的に高いロック上限へ移る必要があった。採掘者は、ネットワークの残りが拒否するブロックを再び作らないよう、調整日より前に上限を上げてはならなかった。2013 年八月 16 日、ネットワークはブロック 252 451 を受け入れ、未修正ノードを恒久的に切り離した。 [5]
この事件は、コンセンサスがブロック形式の説明だけではないことを示した。検証コード、ライブラリ、データベーストランザクション、エラー経路、境界テストの正確な挙動も含まれる。その後は testnet での負荷トランザクション生成、サービス向け警報の改善、長いサイドブランチの監視、変更の慎重な調整が進められた。迅速な復旧は同時に、当時のネットワークが連絡可能な少数の開発者と大手 pool に依存していたことも露呈した。 [1]
理解を深めるには、この項目とあわせて次もお読みください Bitcoin Core, コンセンサスルール, Hard Fork, Reorg, Full Node, Mining Pool. 次の項目からも参照されています Schelling Point.
01どのブロックチェーンが本物かを一つの集団が決めたのか？+
開発者と大手 pool は緊急対応を調整したが、ノードを遠隔で書き換えることはできなかった。BTCGuild と Slush は採掘者が使うソフトウェアを変更し、利用者は独自の検証規則を持つ各バージョンを動かしていた。互換ブランチは、十分なノードが受け入れ、Bitcoin 0.8 ノードから見てより多くの仕事量を積んで初めて優勢になった。
02両方のブランチが同時に有効だったのか？+
検証するバージョンによって異なった。Bitcoin 0.8 はブロック 225 430 とそのブランチを有効としたが、一部の旧ノードは Berkeley DB 上限により拒否し、別のブランチしか認識しなかった。同じ入力に異なる答えを返すことこそコンセンサス障害であり、現在の有効な履歴は協調して選ばれた互換ブランチから続いている。