BIP 8, BIP 9 или современный софт форк — Как будет активировано следующее обновление биткоина?

Bitcoin Magazine — Аарон ван Вирдум — «BIP 8, BIP 9 Or Modern Soft Fork Activation: How Bitcoin Could Upgrade Next»

Предложенное обновление Taproot, которое позволит повысить приватность и гибкость биткоина, проходит последние этапы разработки. Контрибьюторы Bitcoin Core соглашаются, что обновление станет положительным событием для биткоина. Участники более широкого сообщества также в большинстве своем, по всей видимости, поддерживают его. Таким образом, велика вероятность того, что код Taproot будет добавлен в релиз Bitcoin Core, после чего то же самое могут сделать разработчики других клиентов.

Тем не менее, остается актуальным вопрос: как должна обновляться сеть биткоина? Taproot является консенсусным изменением протокола. Это означает, что ноды биткоина должны как-то переключиться со старых правил на новые, не вызывая разделение сети на разные части, каждая из которых следовала бы собственным правилам. В силу различных причин этот момент вызывал затруднения в прошлом.

В настоящее время предлагаются улучшенные стратегии активации обновления.

Предыдущие софт форки и BIP 9

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

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

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

С 2012 года хешрейт все больше использовался для направления обновлений биткоина. Встраивая элемент данных в блок, майнеры могут дать сигнал о том, что они обновили свое ПО и готовы работать на новых правилах. Как только достаточный объем хешрейта даст такой сигнал, все обновленные ноды могут переходить на новые правила.

Со временем эта стратегия был описана в качестве предложения по улучшению биткоина BIP 9. Оно использовалось, например, при активации софт форка Segregated Witness (SegWit). Майнерам дали год на подготовку к обновлению, а условием его активации было наличие сигнала о готовности в 95% блоков в течение двухнедельного периода сложности. Если бы после года подготовки такая готовность не была обнаружена, обновление считалось бы провалившимся.

Тем не менее, в случае SegWit этот план не сработал. Как и при предыдущих обновлениях, некоторые майнеры могли не обновиться в срок из-за простого бездействия. Однако некоторые майнеры восприняли сигнал о готовности как свой шанс проголосовать за или против обновления и воспользовались этим, чтобы заблокировать его.

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

В результате был выпущен клиент со схемой BIP 91, которая позволила снизить требование к хешрейту с 95% до 75% и активировать софт форк за день до BIP 148. Оказавшись перед угрозой раскола, майнеры сдались и согласились поддержать SegWit, однако разработчики Bitcoin Core учли недостатки BIP 9.

BIP 8

BIP 8 стало ранней альтернативой BIP 9, предложенной автором BIP 148 Shaolinfry и контрибьютором Bitcoin Core Luke-jr. Изначально оно напоминало BIP 9, но содержало одно важное отличие: вместо отмены обновления через год после отказа майнеров поддержать его оно в любом случае должно быть активировано в обозначенный момент. Майнеры, не обновившие свое ПО, будут добывать блоки, которые не будут приниматься обновленными майнерами и пользователями.

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

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

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

Контрибьютор Bitcoin Core Мэтт Коралло предлагает другой подход. Его идея «современной активации софт форка» состоит из трех этапов, объединяющих BIP 9 и BIP 8.

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

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

BIP 8 + BIP 91

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

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

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

Спорк

Предложение разработчика Джереми Рубина носит название вероятностного софт форка биткоина (Spork). Он заявляет, что при использовании BIP 9 майнеры могут задерживать обновление, не неся никаких издержек. Просто отказываясь сигнализировать о готовности, они ничего не теряют, но обретают политическую силу.

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

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

Предложение Рубина является довольно новым и еще не проходило тщательного тестирования, поэтому вряд ли всерьез будет рассматриваться для активации Taproot, но, тем не менее, заслуживает внимания как интересная концепция.
Комментарии 0