---
title: "Хард-форк и софт-форк: совместимость правил, активация и разделение цепи"
description: "Хард-форк и софт-форк описывают разные отношения совместимости старых и новых правил консенсуса. Наборы допустимых блоков, активацию, проверку узлами, производителей, операционную готовность, риск повтора и фактическое разделение цепи следует анализировать отдельно."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Хард-форк и софт-форк: совместимость правил, активация и разделение цепи
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Хард-форк и софт-форк классифицируют изменение правил консенсуса по тому, как обновленные и необновленные узлы оценивают блоки. Пусть `V_old` — набор блоков, принимаемых старыми правилами, а `V_new` — новыми. Софт-форк ограничивает допустимость так, что `V_new subset V_old`: каждый допустимый по новым правилам блок допустим и по старым, хотя старый узел не применяет дополнительное ограничение. Хард-форк допускает хотя бы один новый блок, который старый узел отклоняет: `exists b: b in V_new and b not in V_old`. Наборы могут расширяться или быть несопоставимыми; «хард» не означает просто больший блок или более радикальную функцию.
Совместимость асимметрична. При успешном софт-форке старые узлы остаются в той же цепи, поскольку принимают блоки обновленных производителей, но могут принять то, что новые узлы отклоняют, и дают более слабую гарантию. При хард-форке старые узлы не могут следовать за первым новым блоком вне старого допустимого набора. Если экономически значимые участники поддерживают оба набора, возможны две устойчивые сети; без реальной поддержки одной стороны два актива не обязаны сохраниться.
Термины описывают правила, а не легитимность управления, безопасность, экономическую поддержку или способ активации. Предложение может называться хард-форком до активации, активированное изменение может не создать длительного разделения, а случайная несовместимость реализации может разделить цепь без голосования. Сигналы производителей координируют готовность, но не делают для полного узла допустимым блок, отклоняемый его правилами.
Не путайте форк консенсуса с временным ответвлением при одинаковых правилах, реорганизацией, форком репозитория или обновлением приложения. Операционный вопрос состоит в том, какую сеть, правила, условие активации и историю признают каждый узел, кошелек, биржа, хранитель, оракул и контракт.
## Как анализировать форк протокола
1. **Зафиксировать идентичность и область.** Записать `chain`, `network`, `client version`, предложение активации, генезис или финализированную контрольную точку, текущий хэш и затронутый уровень. Одно имя на тестовой, основной, исполнительной, консенсусной или прикладной сети может означать разные правила.
2. **Сравнить допустимость консенсуса.** Перечислить измененные правила блоков, транзакций, подписей, переходов состояния, газа, времени, финальности и выбора ветви. Классифицировать примеры в обеих версиях как `valid`, `invalid` или `unknown`; одних примечаний к выпуску недостаточно.
3. **Доказать отношение наборов.** Проверить, остается ли каждый новый допустимый объект допустимым по старым правилам. Тогда возможна совместимость софт-форка; один новый допустимый, но старый недопустимый блок требует для этих узлов хард-форка. Проверить и старые объекты, ставшие недопустимыми.
4. **Воспроизвести активацию.** Сверить высоту, эпоху, медианное время, порог сигналов, задержку фиксации, общую сложность или триггер управления со спецификацией и кодом. Сигнализация, фиксация, активация и применение — разные состояния.
5. **Сопоставить участников.** Измерить обновленный производящий вес и определить полные узлы, ретрансляторы, кошельки, биржи, хранителей, мосты, эмитентов стейблкоинов, оракулы и контракты каждой стороны. Хэшрейт или доля сами по себе не определяют экономическое принятие.
6. **Отслеживать разделение и транзакции.** Проверять родительские хэши и допустимость по обоим наборам. Изучить подтверждения, расхождение мемпула, защиту от повтора, адреса, идентификаторы цепи, домены подписей, вывод и исполнение на обеих ветвях.
7. **Установить операционные меры.** При неясном происхождении остановить или продлить расчеты; осознанно обновиться и создать резервные копии; сверить балансы и обязательства по ветвям; проверить подпись и восстановление офлайн; возобновить работу только по явным критериям цепи, узла, контрагента и финальности.
Метод разделяет четыре события, часто объединяемые словом «форк»: предложение правил, условие активации, наблюдаемое расхождение и последующее экономическое выживание одной или нескольких ветвей. Ни одно автоматически не доказывает следующее.
## Примеры расчета
### 1. Совместимость допустимых наборов
Пусть старые правила принимают `100` форм блока, а новые только `80`. Если все эти `80` входят в старый набор, отношение соответствует софт-форку; остальные `20` старых форм новые узлы отклоняют. Числа иллюстрируют наборы, а не вероятности или пороги голосования.
Если новые правила принимают форму, отклоняемую каждым старым узлом, одного такого контрпримера достаточно для нарушения обратного принятия, даже если почти все прочие блоки допустимы с обеих сторон. Сохранение разделения зависит затем от производителей, пользователей и инфраструктуры.
### 2. Активация BIP 34 — не определение
`BIP 34` потребовал высоту блока в coinbase-транзакции и использовал скользящий механизм готовности. При `750 of 1,000` предыдущих блоков версии 2 или выше узлы отклоняли недопустимые блоки версии 2; после `950 of 1,000` — версию 1. В BIP блок `227,835` указан как последний блок версии 1.
Пороги координировали развертывание, но не определяли софт-форк. Совместимость возникала потому, что новые узлы сужали прием, а старые клиенты принимали соответствующие блоки. Позже `BIP 9` разделил состояния развертывания и биты версии, показав различие отношения правил и механизма активации.
### 3. Segregated Witness как софт-форк
`BIP 141` ввел данные `witness` и включил обязательство их дерева через coinbase-транзакцию в существующую структуру. Старые узлы принимали соответствующие блоки, не проверяя новые witness-правила, а обновленные узлы применяли их.
Это обратное принятие, а не равная проверка. Старый узел может считать выходы под новыми правилами менее ограниченными; пользователю новых свойств безопасности нужна обновленная проверка. Фраза «старое ПО продолжает работать» не завершает анализ риска.
### 4. DAO Fork в Ethereum
EIP-779 описывает DAO Fork на блоке основной сети `1,920,000`: нестандартное изменение состояния перевело балансы из списка счетов `L` в контракт `WithdrawDAO`, не меняя опкоды EVM, формат транзакций и структуру блоков.
Применившие переход и отказавшиеся узлы рассчитали разные состояния. Хард-форку не нужен больший блок или новый опкод: достаточно разового правила перехода, а длительная поддержка обеих историй может сохранить отдельные сети.
## Риски и ошибки проверки
### Ошибки классификации и спецификации
- Называть хард-форком любую временную конкурирующую вершину, хотя все используют одинаковые правила и обычный выбор ветви ее устраняет.
- Считать любое смягчение хард-форком, а ограничение софт-форком без проверки реальных допустимых наборов.
- Приравнивать обратное принятие к полной безопасности; старые узлы не применяют новые ограничения.
- Выводить консенсус из бренда, плана, примечания или ветви репозитория вместо развернутого кода и параметров.
- Смешивать обновления mainnet, testnet, исполнения, консенсуса, мостов, роллапов и приложений.
- Считать предложение, выпуск клиента, сигнализацию, фиксацию и активацию одним событием.
- Считать сигнал производителей обязательным голосом пользователей, бирж, хранителей или полных узлов.
### Риски разделения и транзакций
- Полагать, что активация гарантирует разделение или разделение — два ликвидных и устойчивых актива.
- Использовать только высоту, хотя на ней могут быть разные блоки; проверять хэши и происхождение.
- Отправлять средства без проверки replay-защиты, идентификаторов, доменов подписи и конструкции по ветвям.
- Зачислять депозит на одной ветви, а обязательство или вывод рассчитывать на другой.
- Доверять одному обозревателю, RPC или ярлыку хранителя, когда поставщики могут отставать или выбрать иные правила.
- Игнорировать реорганизацию, остановку финальности, разделение пиров, миноритарный майнинг, двойной голос или отсутствие данных.
- Предполагать одинаковую поддержку эмитента для тикера, контракта, стейблкоина, цены оракула или требования моста на обеих ветвях.
### Риски управления и эксплуатации
- Выдавать совместимость за доказательство легитимности, децентрализации, безопасности или экономической поддержки.
- Обновлять рабочие узлы без воспроизводимых файлов, копий, пределов отката, теста миграции и независимой сверки хэшей.
- Считать откат всегда безопасным после новых данных состояния, форматов кошелька или условий слэшинга.
- Перемещать ключи или «получать монеты форка» непроверенным ПО, способным раскрыть секреты или повторить подписи.
- Считать баланс снимка доступным без проверки срока, блокировок, состояния контракта и политики хранения.
- Делать налоговые, учетные или оценочные выводы до определения владения, контроля, ликвидности и местных правил.
## Распространенные заблуждения
- **Хард-форк всегда создает новую монету.** Второму активу нужны производство, пользователи, инфраструктура и рынок; многие обновления сходятся к одной истории.
- **Софт-форк безопасен, потому что старые узлы работают.** Они могут следовать цепи, но не применяют новое правило и проверяют слабее.
- **Большинство хэшрейта или доли само меняет любые правила.** Полные узлы отклоняют недопустимые по их правилам блоки; вес действует лишь среди принятых.
- **Хард означает спор, а софт — единогласие.** Термины классифицируют совместимость, не общественный консенсус или качество управления.
- **Любой форк в обозревателе — обновление.** Конкурирующие блоки при одинаковых правилах и реорганизации возникают без смены консенсуса.
## Связанные темы
- [Механизмы консенсуса](/ru/crypto/consensus-mechanism/)
- [Полные узлы](/ru/crypto/full-node/)
- [Правила выбора ветви](/ru/crypto/fork-choice-rule/)
- [Реорганизации цепи](/ru/crypto/chain-reorg/)
- [Биткоин](/ru/crypto/bitcoin/)
## Источники
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (дата обращения: 2026-08-19)
- [Bitcoin Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (дата обращения: 2026-08-19)
- [BIP 34: Block v2, Height in Coinbase](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) - Bitcoin BIPs (дата обращения: 2026-08-19)
- [BIP 66: Strict DER signatures](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) - Bitcoin BIPs (дата обращения: 2026-08-19)
- [BIP 9: Version bits with timeout and delay](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) - Bitcoin BIPs (дата обращения: 2026-08-19)
- [BIP 141: Segregated Witness (Consensus layer)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) - Bitcoin BIPs (дата обращения: 2026-08-19)
- [BIP 50: March 2013 Chain Fork Post-Mortem](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki) - Bitcoin BIPs (дата обращения: 2026-08-19)
- [EIP-779: Hardfork Meta: DAO Fork](https://eips.ethereum.org/EIPS/eip-779) - Ethereum Improvement Proposals (дата обращения: 2026-08-19)
Source: https://wiki.fcontext.com/ru/crypto/hard-fork-soft-fork/index.mdx