Непростой кейс софтфорка: как будет активировано следующее обновление биткоина

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

В январе один из создателей протокола Segregated Witness (SegWit) Питер Велле оформил в качестве официальных предложений по улучшению биткоина софтфорки Schnorr/Taproot (BIP-340, BIP-341 и BIP-342).

Активация Taproot влечет за собой консенсусное изменение протокола. Это означает, что узлам сети (нодам) необходимо каким-то образом переключиться со старых правил на новые, не вызывая разделение сети на несколько цепей, каждая из которых будет работать по разным правилам. В прошлом этот процесс – по различным причинам – вызывал проблемы.

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

*

В отличие от хардфорка, который удаляет или ослабляет правила, софтфорк их добавляет или уточняет. При проведении софтфорка все, что обновленная нода считает действительным, необновленная нода тоже считает действительным. Например, если необновленная нода принимает транзакции типа A и B, а новые правила допускают только транзакции A, то обновленная нода остается совместимой с остальными.

На раннем этапе развития биткоина софтфорки планировались на определенный день (flag day). Разработчики, в частности, Сатоши Накамото, указывали в коде нового релиза клиента время, когда обновленные ноды начнут применять новые правила. Майнерам и пользователям (которые в то время часто были одними и теми же людьми) рекомендовалось обновиться до этой даты, чтобы избежать разделения сети.

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

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

Эта стратегия описана в BIP-9, которое использовалось для активации SegWit. Майнерам отвели год для перехода на обновление: требовалось, чтобы 95% блоков на протяжении любого периода перерасчета сложности включали бит, сигнализирующий о готовности к обновлению. Если бы через год этого не произошло, то период активации бы истек.

Активация BIP-9, впрочем, оказалась не столь простой. Как и в случае с некоторыми предыдущими апгрейдами, часть майнеров не спешила, поскольку не имела достаточных для этого стимулов. Другая проблема заключалась в том, что некоторые майнеры стали рассматривать этот процесс как своего рода голосование, где вместо того, чтобы сигнализировать о готовности, они будут (или не будут) сигнализировать о его поддержке. Хуже того, некоторые решили использовать это «голосование», чтобы попытаться получить политические рычаги влияния на процесс разработки биткоина и извлечь из этого выгоду.

После затянувшихся драматических событий SegWit все же активировали, но произошло это только после того, как новые схемы активации включили альтернативные клиенты биткоина. Часть сети использовала клиент BIP-148, и включенное в него одноименное предложение было запрограммировано на прием только тех блоков, которые сигнализировали о поддержке обновления протокола. В это же время BIP-91, включенное в клиент btc1, снизило требования к хешрейту с 95% до 75%. Как итог, большинство разработчиков Bitcoin Core признали BIP-9 не самым оптимальным решением и начали искать альтернативы.

BIP-8

Первой альтернативой BIP-9 стало BIP-8, которое предложили автор BIP-148 Shaolinfry и разработчик Bitcoin Core Люк Дэш-младший. Его отличие от BIP-9 в том, что вместо отмены обновления через год из-за недостаточной поддержки хешрейта происходит прямо противоположное — софтфорк активируется принудительно в определенный день. Все обновленные ноды с этого момента начинают применять новые правила, а майнеры на ПО со старой версией рискуют начать добывать блоки, которые будут отклоняться.

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

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

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

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

Современная активация софтфорка

Контрибьютор Bitcoin Core Мэтт Коралло предложил концепцию «современной активации софтфорка» (Modern Soft Fork Activation). Она состоит из трех этапов, объединяющих BIP-9 и BIP-8.

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

Если причин для пересмотра обновления не обнаружено, софтфорк будет переоформлен согласно правилам BIP-8 (flag day). Таким образом майнеры получают повторный шанс поддержать обновление, но по истечении установленного срока ноды перейдут на измененные правила автоматически.

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

Главным возражением против современной активации софтфорка является то, что без сотрудничества с майнерами процесс займет слишком много времени. Изначально Коралло предлагал отводить один год на BIP-9, полгода — на анализ причин отказа, и два года — на BIP-8. Таким образом, на принятие обновления может уйти три с половиной года. Такой длительный период активации несет риски: майнеры могут по-прежнему играть в политические игры, задерживая активацию, в то время как сокращение времени сопряжено с опасностью разделения сети.

BIP-8 + BIP-91

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

Если разработчики не находят проблем в самом предложении (например, активация не состоялась из-за пассивности майнеров), они могут выбрать развертывание нового софтфорка по схеме BIP-91, которая использовалась для активации SegWit. Это позволит снизить требования к необходимому для поддержки хешрейта и, соответственно, ускорить процесс.

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

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

Sporks

Разработчик Bitcoin Core Джереми Рубин предложил концепцию «вероятностного софтфорка биткоина» (Sporks), призванную предложить больше стимулов по сравнению с традиционными софтфорками с использованием хешрейта.

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

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

Из-за случайности хешей майнер не может контролировать, какие именно хеши он генерирует ― обычные или активирующие обновление. Если майнер генерирует хеш, который активирует обновление, у него будет два варианта: транслировать его в сеть биткоина, заработать награду за блок и активировать софтфорк, или отказаться от трансляции хеша, активации софтфорка и вознаграждения за блок. Таким образом, задержка с активацией обновления может стоить майнерам денег.

Концепция Sporks относительно новая идея и пока мало изучена. Некоторые разработчики считают ее интересной, но на данный момент она вряд ли будет рассмотрена в качестве претендента на способ активации Taproot.

Еще одна идея, которую начали активно обсуждать в последнее время, предполагает изначальное развертывание BIP-8 с относительно длинным периодом сигнализации (например, два года) без принудительной активации после завершения. Это позволит майнерам активировать софтфорк так же, как они это уже делали в прошлом.

Если через некоторое время (например, шесть месяцев) софтфорк не будет активирован, и не будет веских причин для задержки, в новом клиенте может быть выпущен BIP-8 с принудительной активацией.

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

Ранее ForkLog опубликовал перевод статьи Аарона ван Вирдума о принципах работы Taproot, объясняющей, почему это решение сделает биткоин сильнее.

Подписывайтесь на новости ForkLog в Telegram: ForkLog Feed — вся лента новостей, ForkLog — самые важные новости и опросы.