Софт-форк — это скоординированный переход от набора достоверности V(старый) к его подмножеству V(новый). Активация определяет блок, из которого обновленные полные узлы реализуют ограничение. Сигнализация майнера может координировать готовность, но достоверность определяется правилом, выполняемым на узлах; проектирование, реализация, развертывание, активация и внедрение — это не одно и то же.
Отметим V(old) все блоки, принятые правилами до обновления. Это изменение является мягким форком только в том случае, если V(new) лежит внутри V(old): новый узел отклонит следующий класс блоков, но блок, соответствующий новым правилам, также пройдет старые проверки. Название говорит о совместимости правил достоверности, а не о размере, безопасности или социальной совместимости изменения. Увеличение лимита, видимого для старого узла, или разрешение ранее недействительных расходов расширяет пул и обычно требует хард-форка. [Руководство для разработчиков Bitcoin — Изменения в правилах консенсуса] [Bitcoin Optech — Активация софт-форка]
Старый полный узел может продолжать следовать по цепочке, поскольку обновленные майнеры регулярно создают блоки, которые он распознает. Но он не проверяет добавленное условие. Если ветвь с большим количеством работы нарушает новое правило, старый узел может его принять, а обновленный — отклонить. Те, кому нужна новая гарантия, должны обновить свое собственное программное обеспечение для проверки; способность кошелька принимать платежи, совместимость форматов и полная проверка консенсуса — это разные вещи. [Руководство разработчика Bitcoin — Изменения в правилах консенсуса] [BIP 341 — Развертывание Taproot]
Биткойн создал подмножества, используя несколько методов. BIP66 запретил нестрогие подписи DER, которые допускались старыми правилами. BIP65 и BIP112 добавили условия к кодам операций NOP, которые старый интерпретатор считал успешным бездействием. SegWit и Taproot придали смысл зарезервированным версиям программы-свидетеля, которую старый узел считает доступной для всех. В то же время конструкция должна предотвращать обход нового контроля; Таким образом, SegWit зафиксировал данные-свидетели через Coinbase и сохранил старые базовые правила блокировки. [BIP 66 — Строгие подписи DER] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Отдельное свидетельство] [BIP 341 — Развертывание Taproot]
Код может содержать неактивное правило задолго до того, как оно вступит в силу в основной сети. BIP и проверенная реализация не являются развертываниями, параметры развертывания не являются блокируемыми, блокировка только планирует будущее применение, и только состояние ACTIVE означает проверку данного блока. Каждый узел вычисляет состояние на основе предков своей ветки. Реорганизация на границе может привести к его перерасчету, и программное обеспечение с другими параметрами может начать применять несовместимые правила. [BIP 9 — биты версии с таймаутом и задержкой] [Bitcoin Core — versionbits.cpp]
BIP9 назначает развертыванию имя, разрядную версию, время начала и тайм-аут. Исходный вариант основной сети оценивает периоды после 2016 блоков: после как минимум 1916 сигнальных блоков, т.е. 95%, он переходит от STARTED к LOCKED_IN, ждет один период и затем становится АКТИВНЫМ; в противном случае это может закончиться ОШИБКОЙ. Полная последовательность — DEFINED, STARTED, LOCKED_IN, ACTIVE и FAILED. Состояние блока зависит от его предков, а не от его собственной nVersion, и сигнализация после блокировки больше не меняет результат. [BIP 9 — биты версии с тайм-аутом и задержкой]
Биты версии указывают на готовность майнера и координируют переход; они не предоставляют майнерам постоянное владение консенсусом. BIP8 использует высоты и с помощью lockinontimeout может принудительно передавать сигнал в последнем окне. BIP148, с другой стороны, предписывал участвующим узлам отклонять блоки сигнализации, не относящиеся к SegWit; BIP91 снизил порог майнинга, чтобы соответствовать этому давлению. Обязательная активация может разделить цепочку, если узлы, скорость хэширования и экономическое внедрение будут расходиться, поэтому даже метод активации является компромиссом с безопасностью. [BIP 8 — Биты версии с блокировкой по высоте] [BIP 148 — Обязательная активация SegWit] [BIP 91 — Пониженный порог SegWit MASF] [Bitcoin Optech — Активация софт-форка]
P2SH в соответствии с BIP16 был активирован в 2012 году посредством сигнализации Coinbase и ограничения по времени. BIP34 использовал версию блока и порог обязательной высоты в базе монет. Одна и та же целочисленная процедура запускала строгий DER в BIP66 и CHECKLOCKTIMEVERIFY в BIP65, но потребляла значения версий и не могла выполнять одновременные развертывания. Поэтому в BIP9 были введены независимые биты. BIP68, BIP112 и BIP113 затем активировались вместе как относительное время блокировки и CSV на высоте 419 328 в 2016 году. [BIP 16 — Оплата по хэшу сценария] [BIP 34 — Блок v2, высота в базе монет] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — Строгие подписи DER] [BIP 112 — ПРОВЕРИТЬ ПОСЛЕДОВАТЕЛЬНОСТЬ]
SegWit активирован на 481 824 в августе 2017 года. Старый узел видит транзакцию без данных-свидетеля и считает свидетеля v0 доступным для всех; обновлена проверка свидетеля, новый дайджест подписи и правила защиты от податливости. Обязательство Меркла следить за данными в базе монет не позволяет майнеру изменять или пропускать данные без обнаружения. Выставление счетов по весу увеличивало эффективную емкость без того, чтобы базовый блок, видимый для старого узла, превышал старый лимит в один мегабайт. [BIP 141 — Отдельный свидетель]
BIP341 и BIP342 свидетельствуют о расходовании путей ключей и сценариев программы версии 1 с помощью подписей Шнорра и Tapscript. Старый узел снова рассматривает зарезервированную программу как программу, которую может потратить каждый: подмножество сохраняется, а полная проверка — нет. В сети использовалась модифицированная версия BIP9 Speedy Trial с порогом 1815 из 2016 блоков, или 90%, и минимальной высотой активации 709 632. Taproot активирован в нем 14 ноября 2021 года; Правила Taproot и способы их активации — это два отдельных вопроса аудита. [BIP 341 — развертывание Taproot] [BIP 342 — Tapscript] [Примечания к выпуску Bitcoin Core 0.21.1 — развертывание Taproot]
Когда BIP66 был активирован в июле 2015 года, некоторые майнеры сигнализировали о новой версии, но не проверяли в достаточной степени родительский блок, на котором они майнили. Они расширили недействительный блок и 4 июля создали недействительную ветку из шести блоков; На следующий день последовал еще один более короткий инцидент. Обновленные проверяющие узлы отклонили обе ветви. Номер версии или бит — это заявление майнера, а не доказательство того, что он сам проверил шаблон, родителей и транзакции. [BIP 66 — строгие подписи DER] [Bitcoin.org — предупреждение о разветвлении цепочки BIP66, июль 2015 г.]
В состоянии ACTIVE обновленные узлы отклоняют блок-нарушитель независимо от доли хэш-скорости; возникнет ли постоянное разделение, зависит от работы отделений и их хозяйственного использования. Простое снятие ограничения снова активирует сегодняшние недействительные блоки и, следовательно, является хард-форком; параметры или код могут быть заменены согласованным выпуском перед активацией. Оператор проверяет свою версию, getdeploymentinfo или getblockchaininfo, точные параметры, высоту активации и логи. Ни граф сигналов, ни метка проводника не могут заменить локальную проверку. [Руководство разработчика Bitcoin — Изменения в правилах консенсуса] [Bitcoin Core — versionbits.cpp] [Примечания к выпуску Bitcoin Core 0.21.1 — развертывание Taproot]
Для полной картины прочитайте эту статью вместе с Правила консенсуса, BIP (Bitcoin Improvement Proposal), SegWit, Taproot, Hard Fork, Bitcoin. На эту статью также ссылаются Hard Fork, BIP (Bitcoin Improvement Proposal), Правила консенсуса, Reorg.