Перейти к содержанию
Financial Context Wiki

Хард-форк и софт-форк: совместимость правил, активация и разделение цепи

Хард-форк и софт-форк описывают разные отношения совместимости старых и новых правил консенсуса. Наборы допустимых блоков, активацию, проверку узлами, производителей, операционную готовность, риск повтора и фактическое разделение цепи следует анализировать отдельно.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Хард-форк и софт-форк классифицируют изменение правил консенсуса по тому, как обновленные и необновленные узлы оценивают блоки. Пусть 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 или ярлыку хранителя, когда поставщики могут отставать или выбрать иные правила.
  • Игнорировать реорганизацию, остановку финальности, разделение пиров, миноритарный майнинг, двойной голос или отсутствие данных.
  • Предполагать одинаковую поддержку эмитента для тикера, контракта, стейблкоина, цены оракула или требования моста на обеих ветвях.

Риски управления и эксплуатации

  • Выдавать совместимость за доказательство легитимности, децентрализации, безопасности или экономической поддержки.
  • Обновлять рабочие узлы без воспроизводимых файлов, копий, пределов отката, теста миграции и независимой сверки хэшей.
  • Считать откат всегда безопасным после новых данных состояния, форматов кошелька или условий слэшинга.
  • Перемещать ключи или «получать монеты форка» непроверенным ПО, способным раскрыть секреты или повторить подписи.
  • Считать баланс снимка доступным без проверки срока, блокировок, состояния контракта и политики хранения.
  • Делать налоговые, учетные или оценочные выводы до определения владения, контроля, ликвидности и местных правил.

Распространенные заблуждения

  • Хард-форк всегда создает новую монету. Второму активу нужны производство, пользователи, инфраструктура и рынок; многие обновления сходятся к одной истории.
  • Софт-форк безопасен, потому что старые узлы работают. Они могут следовать цепи, но не применяют новое правило и проверяют слабее.
  • Большинство хэшрейта или доли само меняет любые правила. Полные узлы отклоняют недопустимые по их правилам блоки; вес действует лишь среди принятых.
  • Хард означает спор, а софт — единогласие. Термины классифицируют совместимость, не общественный консенсус или качество управления.
  • Любой форк в обозревателе — обновление. Конкурирующие блоки при одинаковых правилах и реорганизации возникают без смены консенсуса.

Связанные темы

Источники

Навигация

Поиск по вики...