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

Пост разработчика Bitcoin Core Мэтта Коралло о предлагаемой им стратегии «современной активации софт-форка»

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

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

1. Следует избегать активации софт-форка при наличии значимых разумных и аргументированных возражений. Не обсуждается. Если у кого-то есть хорошо себя зарекомендовавшее разумное применение Биткойна, которое работает сегодня, нет явных причин полагать, что это должно измениться в будущем, а вносимые изменения существенно затрудняют этот вариант использования либо полностью его исключают, то такие изменения не должны вноситься в протокол. Я надеюсь, что это не вызывает ни у кого возражений (см. также важную оговорку в последнем пункте – момент, на который, я уверен, все сразу же укажут).
2. Следует избегать активации софт-форка в сроки, не позволяющие рассчитывать на высокий процент принятия изменений на уровне полных узлов. Отмечу, что, как и во всех аргументах, касающихся нод/узлов, я имею в виду именно «экономически используемые» ноды, а не тысячу или около того нод-наблюдателей на Google Cloud и AWS. Изменения правил – будь то софт- или хард-форк – не будут иметь смысла, если эти правила не будут применяться нодами, поэтому активация в чрезмерно сжатые сроки, делающие невозможным или маловероятным масштабное принятие изменений узлами сети, не имеет никакого смысла, однако может вызвать непреднамеренные побочные эффекты.
3. Не следует (без необходимости) терять хеширующую мощность из-за необновившихся майнеров. Поскольку безопасность Биткойна во многом обеспечивается майнерами, побочный эффект от изменений в виде снижения хеширующей мощности сети будет нежелательным ослаблением ключевого параметра безопасности сети. Поэтому в недавней истории для принятия софт-форков требовалось, чтобы 95% хеширующей мощности сети обновилось и сигнализировало о готовности применять новые правила сети. Кроме того, по этой причине ни один из относительно недавних софт-форков не подразумевал внесения изменений, исключающих обратную совместимость с майнингом на стандартном инстансе Bitcoin Core.
4. Желательно использовать давление хеширующих мощностей, где это возможно, чтобы снизить риски, связанные с процессом обновления. Одна из основных причин для выполнения софт-форков заключается в том, что введение правил, подкрепленное хеширующими мощностями, является элегантным способом избежать разделения сети в процессе обновления узлов. Хотя нет смысла инвестировать материальные ценности в системы, защищенные новыми правилами до тех пор, пока эти правила не начнет применять большинство «экономических узлов», поддержка хеширующих мощностей позволяет нам аккуратно преодолеть временной разрыв между активацией софт-форка и полным переходом на новые правила. Если соблюдение новых правил обеспечивается подавляющим большинством майнеров, то попытки нарушения этих правил не приводят к значимому расколу сети, влияющему на опыт существующих пользователей системы. Не имея намерения воспользоваться этим преимуществом, лучше производить обновление через хард-форк, с неизбежным увеличением сроков, которое это за собой влечет.
5. Необходимо следовать воле сообщества, вне независимости от индивидуальных или необоснованных возражений, однако никогда не отвергая никаких резонных и обоснованных контраргументов. В недавней истории случались «возражения» против софт-форков в духе «это плохо, потому что не решает другую проблему, решение которой я бы хотел увидеть как можно скорее». Думаю, все согласятся, что такого рода возражения против введения предлагаемых изменений нельзя назвать аргументированными, и мы как сообщество (но никогда – как разработчики или иная отдельная группа) должны игнорировать такие реплики и двигаться дальше. Хорошие инженерные решения не достигаются путем объединения в один пакет несвязанных функций ради достижения каких-то политических целей или не имеющего под собой веской аргументации компромисса.

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

BIP 8 выдвигалось как альтернативное решение, в основном, в качестве ответа на проблемы с 5 пунктом. Однако при наивном его применении, вероятнее всего, будут провалены пункты 1, 3 и 4, а на мой взгляд, и 5 тоже, потому что оба этих предложения, как будто, создают впечатление, прецедент и, возможно, даже фактически увеличивают способность разработчиков определять правила консенсуса системы. Развертывание BIP 8, более точно определяющего поддержку сообщества, в качестве предварительного условия, вероятно, может решить проблему соответствия пунктам 1 и 5, хотя я не знаю никаких конкретных предложений относительно реализации подобного решения. Вероятно, значительно более длительное окно активации может позволить BIP 8 выполнить также пункты 3 и 4, но исключительно за счет оговорок насчет «без необходимости» и «где это возможно».

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

Поэтому, чтобы найти баланс между недостатками BIP 8 и BIP 9, в раздел обсуждения предложения «Great Consensus Cleanup» был включен такой текст (со спецификацией, описывающей развертывание BIP 9):

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

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

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

1. Стандартное развертывание BIP 9 на годичном временном интервале для активации с 95-процентной готовностью майнеров.
2. В случае если активации с течение года не происходит, берется пауза на шесть месяцев, в течение которых сообщество может проанализировать и обсудить причины, по которым активации не произошло.
3. В том случае, если это будет иметь смысл, простое изменение из командной строки параметра в bitcoin.conf, поддерживаемое еще с момента первоначального развертывания, позволит пользователям выбрать развертывание BIP 8 с 24-месячным временным горизонтом для активации в назначенную дату.

Это дает очень длительный временной горизонт для более стандартной активации, в то же время обеспечивая достижение целей, обозначенных в 5 пункте, даже если в этих случаях временной горизонт должен быть значительно расширен для соответствия пункту 3. Разработка Биткойна – не гонка на скорость. Ожидание в 42 месяца, если оно потребуется, гарантирует, что мы не создадим неосторожными действиями негативный прецедент, о котором еще придется жалеть позже, по мере дальнейшего роста Биткойна.