Что означает «мягкий форк» в криптовалютах?

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

• Что такое мягкая вилка? Это обновление сети, цель которого — сузить набор допустимых правил, сохраняя при этом совместимость с устаревшими узлами.
• Что изменилось? Это позволяет сети добавлять более строгие правила, не требуя от всех участников одновременного обновления.
• Главная опасность. Спорный софтфорк может привести к отклонению блоков, риску реорганизации цепочки или даже разделению, если его активация будет осуществляться без надлежащей координации.

Представьте себе правила Биткойна в виде большого круга, и любой блок внутри этого круга считается действительным.

В результате мягкого форка внутри себя образуется меньший круг. Теперь обновленные узлы принимают блоки только внутри меньшего круга. Но ключевой момент: каждый блок внутри меньшего круга также находится внутри большего круга. Поэтому старые узлы, которые все еще используют исходные правила, видят эти обновленные блоки и без проблем принимают их.

Это концепция обратной совместимости. Более старое программное обеспечение может следовать новой серии, даже не подозревая об изменении правил.

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

Взаимосвязь между правилами работает следующим образом:

• В старых узлах применяются более общие правила, действовавшие до введения вилки.
• В обновленных узлах, помимо новых ограничений, применяются старые правила.
• Блоки, соответствующие новым правилам, по-прежнему проходят и проверку по старым правилам.
• Обновленные узлы отклоняют несовместимые блоки.
• Если достаточная доля сети производит совместимые блоки, старые узлы остаются в той же цепочке, не замечая никаких изменений.

Ключевое слово — подмножество . Мягкий форк сохраняет новые правила в пределах старых границ. Жесткий форк полностью выходит за их пределы. В этом случае старые узлы рассматривают новые блоки цепочки и сразу же отклоняют их, поскольку эти блоки нарушают правила, которые они по-прежнему соблюдают. В итоге два набора оказываются на разных цепочках.

Чтобы глубже разобраться в взаимосвязи базового реестра, стоит сначала прочитать руководство «Блокчейн: объяснение для начинающих».

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

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

Важное значение имеет и дифференциация рынка. Bitcoin Cash — самый яркий пример успешного хардфорка: отдельная сеть, отдельный цифровой актив и отдельное сообщество. С тех пор Ethereum сделал запланированные хардфорки своим стандартным путем обновления. Однако форк Ethereum Classic в 2016 году остается самым значительным расколом в его управлении.

Это техническое различие также очевидно на платформах для торговли криптовалютами. Во время мягкого мягкого форка основная задача платформ для торговли криптовалютами — обеспечить корректную работу операций по пополнению, снятию средств и настройке кошельков. Однако во время жесткого форка платформы сталкиваются с более сложным решением: включить новый цифровой актив в листинг, проигнорировать его или предоставить существующим держателям монет обе валюты.

Успех софтфорка не зависит от какой-либо одной организации; для его осуществления требуется сотрудничество всех вовлеченных сторон.

Разработчики пишут и проверяют код, а операторы полных узлов определяют правила, которые обеспечивают их программы. Майнеры создают блоки, которые либо соответствуют новым правилам, либо нет. Кошельки и биржи занимаются пользовательской стороной вопроса. Вся система работает только в том случае, если достаточная часть сети действительно обеспечивает соблюдение более строгих правил.

В случае с Биткоином основным инструментом координации была сигнализация майнеров. Версия BIP-9 использует биты в заголовке блока для отслеживания готовности в течение периодов по 2,016 блоков, примерно по две недели каждый. Как только достаточное количество майнеров сигнализирует о своей поддержке в течение периода готовности, начинается период блокировки, после которого вступают в силу новые правила.

Вот что каждая группа фактически делает в процессе активации:

• Разработчики предлагают изменения в правилах, тестируют их и анализируют.
• Полный текст контракта определяет правила, которые операторы устанавливают для каждого полученного ими блока.
• Майнеры или разработчики блоков создают блоки, которые либо соответствуют, либо не соответствуют самым строгим правилам.
• Когда изменения затрагивают части протокола, доступные пользователю, управляющий протоколом обновляет потоки подписей, форматы адресов, графические инструменты или поведение отображения.
• Биржи управляют депозитами, выводом средств, количеством подтверждений и уведомлениями клиентов.
• Постоянные держатели монет ждут, проверяют поддержку кошелька и избегают спешки с совершением транзакций во время спорных периодов активации.

На узле, где фактически применяются правила, всё работает как единое целое. Майнер может найти блок, но узел отклонит его, если он нарушает правила, установленные этим узлом. Такое разделение очень важно, когда сигнал майнера и выполнение на узле направлены в разные стороны.

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

Обновления Биткоина не всегда проходили гладко. Некоторые обновления были быстрыми и незаметными, в то время как другие занимали годы и едва не раскололи сообщество. Но всех их объединяет одна и та же структура консенсуса: новые правила, которым могут продолжать следовать старые узлы.

Вот что именно изменило каждое крупное обновление:

• P2SH (BIP-16, 2012): Это позволило пользователям отправлять средства на хеш скрипта, а не показывать весь скрипт в выходных данных транзакции. Для старых узлов транзакция P2SH отображалась как стандартная транзакция «платить кому угодно». Однако для обновленных узлов это привело к внедрению более сложной логики. Практический результат: адреса с мультиподписью стали короче и намного проще в обработке.
• Блок и коэффициент тестирования (BIP-34, BIP-65, BIP-66): Три отдельных обновления ужесточили конкретные правила, касающиеся высоты блока в транзакциях Coinbase, временной блокировки выходных данных и токенизации подписей. Каждое из них добавило более строгие критерии, применяемые обновленными узлами, в то время как старые узлы остались в блокчейне.
• SegWit (BIP-141, 2017): Самое политически противоречивое обновление Биткоина на сегодняшний день. SegWit переместил подписи транзакций в отдельную структуру данных, освободив место в блоке без увеличения лимита размера блока. Он исправил проблему изменчивости транзакций, из-за которой идентификаторы транзакций могли быть изменены до подтверждения, и впервые сделал работоспособными платежные каналы, такие как Lightning Network. Технически обновление было успешным. Но в политическом плане оно едва не раскололо сообщество и в конечном итоге привело к хардфорку Bitcoin Cash.
• Главный корень (BIP-341 и BIP-342, 2021): Подписи Шнорра, конфиденциальность скриптов в стиле MAST и Tapscript были объединены в одно обновление. Кошелек, совместимый с Taproot, позволяет сделать сложную многостороннюю транзакцию идентичной простой транзакции с одной подписью в блокчейне. Это представляет собой значительное повышение как конфиденциальности, так и эффективности. Внедрение Taproot прошло гладко, но его реальное распространение было медленным, поскольку кошельки, поставщики инфраструктуры и авторы скриптов должны были обновляться независимо друг от друга.
• Litecoin SegWit (2017): Litecoin внедрил SegWit на несколько месяцев раньше Bitcoin, отчасти потому, что в его сообществе было меньше заинтересованных сторон с расходящимися интересами. Одно и то же техническое обновление, другая политическая обстановка, более быстрые результаты.

SegWit — это поучительная история. Хотя на уровне протокола он был обратно совместим, споры вокруг него — по поводу размера блока, комиссий майнеров и контроля за разработкой — сделали его одним из самых противоречивых моментов в истории Биткоина . Taproot, с другой стороны, представляет собой противоположный конец спектра: широкая поддержка, плавная активация и постепенное внедрение. Техническое определение мягкого форка не отражает масштаба политического хаоса.

Термин «обратная совместимость» — это чисто техническое описание, и он никоим образом не является предсказанием того, как будет вести себя цифровое сообщество.

Проблема в том, что старые узлы принимают блоки, соответствующие старым правилам. Однако не каждый блок, принятый старым узлом, будет соответствовать более строгим новым правилам. Когда обновленные и необновленные майнеры одновременно создают конфликтующие блоки, в цепочке возникают краткосрочные форки. Именно это произошло во время внедрения BIP-66 для Биткоина в 2015 году. Майнинг без проверки, когда майнеры создавали блоки, не проверяя их фактически, способствовал возникновению периодических форков в цепочке, прежде чем майнеры исправили свои ошибки (дата внедрения мягких обновлений Bitcoin Optech).

Одни и те же конфликты возникают практически в каждом спорном процессе активации:

• Порог активации: Если пороговое значение установлено слишком низко, продвижение продвигается быстро, но встречает значительное сопротивление. Если же оно установлено слишком высоко, процесс затягивается на неопределенный срок, пока соперники тянут время.
• Сигналы майнеров: Сигнал призван указывать на готовность, но майнеры могут использовать его стратегически, чтобы отсрочить предложение или добиться уступок. Сигнал не означает исполнения.
• Контроль со стороны пользователей: Операторы полных узлов могут отклонять блоки, созданные майнерами, даже если майнеры указывают на свою поддержку. В этом и заключается смысл софтфорка, инициированного пользователем. Решение принимают пользователи, а не майнеры.
• Экономический вес: Биржи, трейдеры, доверительные управляющие и инвестиционные портфели определяют, в какую цепочку люди смогут реально вкладывать деньги. Этот экономический вес часто определяет, какая цепочка выживет, когда две ее версии конкурируют.
• Расширение масштабов проекта: Изменение правила может решить одну проблему, но при этом незаметно исключить будущие варианты проектирования. Критики часто поднимают этот вопрос, и иногда они правы.

BIP-110 — яркий тому пример. В его проекте предлагается временное ограничение на уровне консенсуса для определенных полей данных: лимит в 34 байта для новых выходных scriptPubKeys, если только первый код операции не равен OP_RETURN, что позволит сохранить действительными до 83 байт. Сторонники утверждают, что это простой мягкий форк, защищающий затраты на полный узел и финансовую концентрацию Биткоина. Критики, однако, утверждают, что спорная активация может изолировать миноритарную цепочку или предотвратить законные варианты использования, которые еще даже не придуманы. Оба аргумента могут быть верны одновременно. Любое предложение может соответствовать всем техническим критериям мягкого форка и при этом нести риск реального раскола, если экономические участники займут противоположные позиции еще до начала активации.

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

Поддержка кошелька важнее, чем заголовки о форках, потому что разные кошельки реагируют на обновления с разной скоростью:

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

Для большинства пользователей контрольный список при активации любого софтфорка довольно короткий:

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

Софтфорк может изменить возможности будущих транзакций, не меняя при этом права собственности на существующие монеты. Исключение составляют маргинальные программы или сложные скрипты, которые полагаются на поведение, ограниченное новыми правилами, — именно поэтому разработчикам кошельков и создателям приложений требуется более тщательная проверка, чем пассивным держателям монет.

В основе большинства текущих дискуссий об обновлении сети Bitcoin лежат три ключевых вопроса: какие ограничения должна накладывать сеть на уровне консенсуса, какие новые возможности она должна получить и какой уровень консенсуса действительно необходим, прежде чем можно будет ввести более строгие правила.

Планы целевого финансирования (BIP) — это всего лишь предложения. Номер BIP не является обязательным правилом.

• Ограничения по объему данных: BIP-110 вписывается в эту дискуссию. Его предложение предполагает, что майнеры будут сигнализировать с помощью 4-го бита, с порогом одобрения в 55% за период в 2,016 блоков и безусловной максимальной высотой активации примерно 1 сентября 2026 года. Основной спор здесь вращается вокруг того, должен ли уровень консенсуса Биткоина отслеживать данные, записываемые в цепочку, и кто несет издержки, если что-то пойдет не так.
• Квантовая готовность: BIP-360 предлагает механизм оплаты корневому элементу Меркла (Pay-to-Merkle-Root), новый тип вывода древовидной структуры скриптов. Цель состоит в снижении долгосрочной уязвимости к квантовым атакам путем исключения расходования закрытого ключа Taproot из этой структуры вывода. Это не экстренное решение существующей угрозы, а скорее проектное решение о том, как долго Биткойн хочет поддерживать свою безопасность, прежде чем квантовые вычисления станут действительно опасными.
• Заветы: Соглашения позволят Биткоину устанавливать условия использования созданных им монет в будущем. Сторонники видят в этом основу для хранилищ, контроля перегрузок и новых путей развития. Критики, однако, опасаются непредвиденных ограничений и споров, которые могут последовать за их внедрением.

Прежде чем рассматривать любое из этих предложений как действительные правила, стоит проверить три вещи. Во-первых, находится ли предложение все еще на стадии проекта или оно перешло на стадию развертывания, установки или активации? Во-вторых, затрагивает ли оно обычные переводы с кошельков или только сложные скрипты? В-третьих, имеет ли путь активации реальную экономическую поддержку со стороны бирж, кошельков и крупных операторов узлов, а не только со стороны разработчиков?