Причиной был не спор о новом правиле, а скрытая зависимость валидации от реализации базы данных: более новая LevelDB обработала блок с необычно большим числом входов, тогда как прежние версии исчерпали стандартное число блокировок Berkeley DB; майнеры скоординировали возврат к совместимой ветви, а последующий выпуск 0.8.1 подготовил управляемый переход.
11 марта 2013 года узел с 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 опубликовал экстренное предупреждение и рекомендовал продавцам приостановить обработку платежей. После обсуждения разработчиков и операторов BTCGuild под руководством Michael Marsee, известного как Eleuthria, и Slush Pool Marek Palatinus вернулись на Bitcoin 0.7. Целью было не навсегда объявить технически более новую ветвь неверной, а быстро сосредоточить работу на истории, которую могли проверить обе широко распространенные версии. [3]
Когда совместимая ветвь вышла вперед по накопленной работе, узлы 0.8 реорганизовались на нее, а блоки, добытые только в исходной ветви 0.8, стали stale. BIP 50 фиксирует как минимум один крупный double spend во время разделения; согласно post-mortem, это был эксперимент, а не преднамеренная кража. Тем не менее событие показало, почему биржи и продавцы при неопределенной вершине цепочки останавливают депозиты и ждут дополнительных подтверждений. [1]
Bitcoin Core 0.8.1 вышел 18 марта 2013 года. Он ввел временное правило приема блоков, действовавшее с 21 марта по 15 мая и не позволявшее принимать блоки, которые старые пиры не могли обработать, а также встроенный checkpoint на блоке 225 430. Post-mortem указывает оценочный предел 10 000 блокировок, лимит добываемого блока 500 000 байтов и backport с лимитом 537 000 блокировок Berkeley DB. [4]
Временная совместимость не была конечным состоянием. Операторы старых узлов должны были до 15 мая перейти на 0.8.1, обновленный backport или явно повысить лимит блокировок; майнерам нельзя было увеличивать его до согласованной даты, чтобы вновь не создать блок, отклоняемый остальной сетью. 16 августа 2013 года сеть приняла блок 252 451 и окончательно оставила неисправленные узлы позади. [5]
Инцидент показал, что консенсус — это больше, чем описание формата блока. Он включает точное поведение кода валидации, библиотек, транзакций базы данных, путей ошибок и граничных тестов. Последующие меры включали стрессовую генерацию транзакций в testnet, улучшенные предупреждения для сервисов, наблюдение за длинными боковыми ветвями и более осторожную координацию изменений; быстрое восстановление также выявило тогдашнюю зависимость от нескольких доступных разработчиков и крупных пулов. [1]
Для полной картины прочитайте эту статью вместе с Bitcoin Core, Правила консенсуса, Hard Fork, Reorg, Full Node, Mining Pool. На эту статью также ссылаются Schelling Point.
01Решила ли одна группа, какой блокчейн настоящий?+
Разработчики и крупные пулы координировали экстренные действия, но не могли удаленно переписать узлы. BTCGuild и Slush сменили софт своих майнеров, а пользователи запускали версии с собственными правилами валидации. Совместимая ветвь победила лишь после того, как ее приняло достаточно узлов и она накопила больше работы с точки зрения узлов Bitcoin 0.8.
02Были ли обе ветви одновременно действительными?+
Это зависело от валидирующей версии. Bitcoin 0.8 считал блок 225 430 и его ветвь действительными, а часть старых узлов отклоняла блок из-за лимита Berkeley DB и знала только другую ветвь. Разные ответы на одни данные — именно сбой консенсуса; нынешняя активная история продолжает согласованно выбранную совместимую ветвь.