Методология активации софтфорков BTC

BitMEX Research

Аннотация. Обновление софтфорка биткоина Taproot почти готово, и биткоин-сообщество всерьез обсуждает возможные методики его активации. В этой статье мы вкратце рассмотрим основные способы активации и обсудим наиболее важные разногласия. Мы придем к выводу, что идеальной методики активации не существует. Любой способ активации может создать плохой прецедент, который в будущем может быть использован в неблаговидных целях. Однако, несмотря на активное обсуждение малозначимых подробностей из-за отсутствия консенсуса об этом конкретном обновлении, на данном этапе конкретный способ активации может быть не таким уж и важным. Представляется, что выпуск Bitcoin Core клиентского приложения со сравнительно пассивной логикой активации и последующим выпуском другими членами биткоин-сообщества клиентов, в принудительном порядке использующих такой  же, но чуть более удобный метод активации, мог бы отчасти решить некоторые существующие дилеммы и, возможно, способствовать дальнейшему развитию системы.

Обзор

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

История активации софтфорков в сети биткоина

Прежде чем выбирать оптимальный путь дальнейшего развития, нелишним будет проанализировать историю софтфорков в системе биткоина. Насколько нам известно, в истории биткоина было 16 софтфорков (см. наш материал «Полная история консенсусных софтфорков в сети биткоина», опубликованный в декабре 2017 года). Большинство обновлений, а именно девять из шестнадцати, пришлись на период с начала 2010 по 2012 год и были проведены в принудительном порядке в заранее определенный день (т.н. «день флага»). При этом семь софтфорков были активированы по сигналу готовности со стороны майнеров, пороговый уровень которого варьировался от 55% до 95%.

 

Беспроблемное обновление

 Значительные проблемы Всего

Плановый запуск в «день флага» или запуск с немедленной активацией

 8* 1 9
Активация майнерами      
Порог активации 55%   1 1
Порог активации 80% 1*   1
Порог активации 95% 4 1 5
Total with miner threshold 5 2 7

Общее количество активаций

 13 3 16

(Источник: BitMEX Research) (Примечание. *Нам известно об одном софтфорке с плановой активацией в «день флага» по обязательному сигналу о готовности майнеров (BIP148) и одном софтфорке с активацией по пороговому значению и обязательному сигналу майнеров (BIP 91)).

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

Война за размер блоков

Еще один элемент исторического контекста, который сегодня уже не актуален, — «война за размер блоков», сотрясавшая криптовалютное сообщество в 2015-2017 гг. В этот период активно обсуждался запуск софтфорка под названием Segregated Witness (SegWit), призванного увеличить предельный размер блоков. Однако из-за «войны за размер блоков» его активация превратилась в хаос, который поставил под угрозу безопасность пользователей, поэтому сегодня многие члены соообщества хотят улучшить методику активации.

Логика активации обновления SegWit была включена в Bitcoin Core. У майнеров был год для активации обновления; требовалось, чтобы 95% блоков на протяжении любого интервала сложности включали сигнал о готовности к обновлению. При этом принудительная активация в «день флага» не была предусмотрена. В конце периода ожидания активации два разных софтфорка, софтфорк с активацией в «день флага» (BIP148) и софтфорк с активацией майнерами с порогом 80% (BIP91) сделали сигнал о готовности к принятию SegWit обязательным, в результате чего он был наконец активирован. Ни один из этих двух софтфорков (BIP148 и BIP91) не был включен в систему Bitcoin Core.

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

Споры об активации

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

  1. Должен ли день активации наступать после периода, отведенного для сигнализации о достижении порогового уровня готовности?
  2. Какие части логики активации (если таковые имеются) должны быть включены в Bitcoin Core?
  3. Должен ли сигнал о готовности майнеров к обновлению стать обязательным в конечном итоге?

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

Дерево принятия решений в отношении метода активации софтфорков (при наличии той или иной формы сигнализации о достижении порога готовности майнеров)

(Источник: BitMEX Research)(Примечание. Правая сторона дерева, которая предусматривает обязательный сигнал о готовности майнеров, соответствует решению BIP 8, а левая сторона — решению BIP 9)

В таблицах ниже мы попытались систематизировать основные аргументы «за» и «против» по каждому из приведенных выше сложных вопросов, ответы на которые могут потребоваться для определения способа активации софтфорков.

Активация в определенный день по окончании периода сигнализации о готовности к обновлению

«За» «Против»
  • Отсутствие «дня флага» при первоначальной активации SegWit вызвало проблемы, так как майнеры своевременно не активировали софтфорк, что вызвало сомнения в реализации обновления.
  • Сигнал о готовности майнеров к обновлению без определенной даты активации («дня флага») создает ложное впечатление, что майнеры контролируют правила протокола, в то время как на самом деле достижение порогового уровня — это всего лишь сигнальный механизм для удобства майнеров, показывающий, что они готовы к активации софтфорка, решение о которой уже принято.
  • Если майнеры решат не активировать софтфорк в срок, они могут безопасно активировать его позднее, причем намного. В конечном итоге правила протокола контролируют конечные пользователи, а не майнеры. Достижение порогового уровня для активации — это всего лишь способ безопасной ранней активации софтфорка.
  • Сегодня активация в «день флага» — слишком агрессивный метод. Вместо этого следует применять более дружественный подход и прибегать к плановой принудительной активации только в исключительных обстоятельствах, если среди участников появляется враждебность.
  • Когда речь идет о правилах протокола, очень важно проявлять максимальное терпение и дружелюбие. Если майнеры недовольны обновлением, должны сохранятся существующие правила консенсуса и активация софтфорка не должна состояться. Это гарантирует жизнеспособность и эффективность правил  сети биткоина в долгосрочной перспективе.
  • При отсутствии разногласий и противоречий майнеры все равно с большой вероятностью добровольно активируют софтфорк. Так зачем же использовать агрессивную и рискованную систему принудительной активации, если в этом нет необходимости?
  • Плановая активация в «день флага» создает целый ряд новых проблем. Например, кто имеет право назначить дату активации? Каким образом сообщество согласует эту дату? Любой человек может в любой момент создать софтфорк с плановой активацией, и его новые правила могут понравиться далеко не всем.

Включение частей логики активации в Bitcoin Core

«За» «Против»
 
  • Если метод активации софтфорка не реализован в Bitcoin Core, возникает проблема координации параметров активации.
  • При этом выпуск клиента, включающего логику активации, другими членами криптовалютного сообщества создаст опасный прецедент. При отсутствии достаточного консенсуса многие пользователи могут выпускать любые типы клиентов для софтфорков, что увеличивает риск опасных разрывов цепочки в будущем.
  • Включение методики активации софтфорка в Bitcoin Core — меньшее из всех зол (т.е. наименее проблемный из всех проблемных вариантов развития событий).
  • Даже если Bitcoin Core выпустит клиент, включающий логику активации, он не будет сгруппирован с другими программными обновлениями (в том числе патчами/исправлениями ошибок). Кроме того, в Bitcoin Core нет функции автоматического обновления. Поэтому обновление совершенно необязательно, и Bitcoin Core не вводит изменение протокола в принудительном порядке; на новые правила протокола переходят только пользователи, решившие использовать новое программное обеспечение.
  • Одно из главных негативных последствий войны за размер блоков в том, что многие сегодня переоценивают степень влияния Bitcoin Core на правила консенсуса в сети биткоина. Сегодня это серьезная проблема, поэтому сообщество должно быть уверено в том, что Bitcoin Core не сможет самостоятельно изменить правила консенсуса.
  • Инициатором изменения правил консенсуса должна быть большая группа пользователей системы, а не разработчики программного обеспечения; такие изменения должны идти «снизу», то есть от рядовых пользователей.
  • Плановое обновление в «день флага» — слишком спорный и агрессивный ход со стороны Bitcoin Core; это неприемлемая демонстрация силы. Пользователи и/или майнеры должны выразить поддержку предложенного  софтфорка, прежде чем Bitcoin Core назначит дату активации.

Обязательный сигнал о готовности майнеров до даты активации

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

Заключение

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

Возможно, существует компромиссный вариант решения очевидной дилеммы в отношении метода активации:

  • Bitcoin Core может включить логику активации на основе решения BIP 9, то есть выбрать активацию майнерами по достижению 95% порога готовности без «дня флага» в конце периода активации и без обязательного сигнала о готовности майнеров. В этом случае Bitcoin Core не будет действовать агрессивно, так как для активации софтфорка потребуется активное участие майнеров. Подобные случаи уже были, в прошлом Bitcoin Core неоднократно выпускал клиенты с такой логикой активации.
  • После этого другие участники сообщества (не Bitcoin Core) могут выпустить собственные версии программного клиента. Эти версии могут содержать логику плановой активации в определенный день в конце установленного периода окна активации Bitcoin Core, с обязательным сигналом о готовности майнеров к принятию софтфорка Bitcoin Core. Таким образом, этот управляемый сообществом софтфорк активирует софтфорк Bitcoin Core.

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

Дополнительные материалы