Hard Fork — изменение консенсуса, при котором новое множество допустимых состояний не является подмножеством старого. Типичный случай — расширение: V(new) допускает состояние вне V(old), например блок большего размера, чем разрешает старый узел, или конструкцию, которую старое ПО считает недействительной. Активация новых правил не заставляет старые узлы переходить: они продолжают применять свои правила, поэтому непрерывность зависит от добровольной координации.
Обозначим через V(old) все блоки, принимаемые исходными правилами. Изменение является Hard Fork, если новое ПО принимает хотя бы один блок вне этого множества. Часто множество допустимых блоков расширяется, но решающим критерием остаётся совместимость: если блок может быть действительным для нового узла и недействительным для старого, старый валидатор не может следовать новой цепи, сохраняя прежние правила. [Bitcoin Developer Guide — Consensus rule changes]
Старый полный узел не знает и не признаёт нового правила. Когда обновлённые майнеры создают блок, превышающий прежний лимит или использующий новую разрешённую конструкцию, старый узел остаётся на последнем действительном для него блоке и отвергает последующую ветвь. Его не переголосовали; он детерминированно выполняет другую программу консенсуса. [Bitcoin Developer Guide — Consensus rule changes]
Фиксированная дата, высота блока или сигнал майнеров могут координировать принявших обновление, но не изменяют ПО узла, который его не принял. Если у каждой из двух систем правил остаются экономически значимые участники, обе цепи могут продолжаться. Поэтому план активации Hard Fork является планом перехода с риском разделения. [Bitcoin Developer Guide — Consensus rule changes]
В точке разделения обе ветви наследуют одну и ту же прежнюю историю UTXO. Затем они могут подтверждать разные транзакции, применять разные лимиты и накапливать разный chainwork. Если обе сохраняются, держатель обычно имеет соответствующие монеты в обеих цепях с учётом последующих правил, защиты от replay и поддержки кошельков. Это уже не одна запись в едином реестре. [BCHN Technical Bulletin — shared history and 2017 split]
Proof of Work выбирает между ветвями лишь после признания их блоков действительными. Старый узел не сравнивает chainwork ветви, содержащей недействительный по его правилам блок, с работой своей допустимой цепи: он сначала отбрасывает такого кандидата. Утверждение «побеждает цепь с наибольшим hashrate» неполно без указания правил проверки. [Bitcoin Developer Guide — Consensus rule changes]
Общий формат подписи и транзакции может сделать одну подписанную транзакцию действительной в обеих сетях после разделения. Это риск replay — повторного использования транзакции в другой цепи. Форк может добавить защиту, другие правила sighash или формат адресов, но это самостоятельные меры. Нужно различать сети, балансы, производные адреса и правила бирж для зачисления депозитов и вывода средств. [Bitcoin Cash upgrade specification — 2017 hard fork]
Bitcoin Cash отделился от Bitcoin на высоте блока 478559 1 августа 2017 года. Его правила разрешили блоки большего размера, чем тогда принимали узлы Bitcoin, и создали собственную продолжающуюся цепь. Узлы Bitcoin отвергали блоки, допустимые только для BCH, а узлы BCH следовали собственной действительной истории. Этот Hard Fork создал отдельную сеть, а не заменил Bitcoin обновлением в той же сети. [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]
Не всякое несовместимое разделение является намеренным новым денежным проектом. Ошибка ПО может временно рассогласовать реализации, а аварийный выпуск — скоординировать возвращение к единым правилам. Разделение Bitcoin в марте 2013 года возникло из-за различий версий в работе с базой данных и её лимитами. Его устранили согласованным возвращением майнеров на ветвь, принимаемую старыми узлами версии 0.7; это отличается от длительного поддержания самостоятельной сети BCH. [BIP 50 — March 2013 chain fork post-mortem]
Soft Fork сужает множество допустимых состояний, сохраняя V(new) внутри V(old). Старый узел может следовать совместимым блокам, но не применяет нового ограничения. Hard Fork не обладает такой односторонней совместимостью: новый действительный блок может быть недействительным для старого узла. Soft Fork тоже может разделить сеть при плохой координации, но Hard Fork требует перехода на новые правила по определению. [Bitcoin Developer Guide — Consensus rule changes]
Разработчики могут выпускать код, майнеры — перенаправлять hashrate, компании — выбирать торговые обозначения и правила депозитов, пользователи — программное обеспечение. Ничто из этого автоматически не переписывает чужой консенсус. Разделение может сохраняться, если достаточно независимых участников добровольно поддерживают и ценят обе системы правил; не всякое несовместимое изменение обязано создавать две постоянно действующие сети. Назвать одну ветвь «обновлением» — общественная договорённость, а не правило консенсуса. [Bitcoin Developer Guide — Consensus rule changes]
Оператор должен проверить идентификаторы сети, конкретный выпуск ПО, параметры консенсуса, соседние узлы, вершину цепи, хеш блока в точке форка и соответствующие примечания к выпуску или контрольные точки. При значительных средствах разумно разделить кошельки и рабочие процессы до расходования монет ответвлений. Обозреватель блоков или торговое обозначение помогают, но не заменяют собственный проверяющий узел. [Bitcoin Core v29.0: getblockchaininfo]
Для полной картины прочитайте эту статью вместе с Soft Fork, Правила консенсуса, Full Node, Reorg, Война за размер блока, UTXO. На эту статью также ссылаются Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, Война за размер блока.