06:13

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

Пост разработчика Bitcoin Core Мэтта Коралло о предлагаемой им стратегии «современной активации софт-форка» Есть несколько вариантов дизайна софт-форка, показавших в последнее время значимый прогресс в отношении применения и будущего принятия. Однако, по ряду причин, различные способы активации софт-форка обсуждались гораздо меньше. Я бы хотел несколько оживить дискуссию на эту тему. Начать, мне кажется, стоит с того, чтобы еще раз проговорить основные цели как для софт-форков, так и для методов их активации. Вероятно, я могу здесь что-то упустить, но некоторые основные требования таковы: Следует избегать активации софт-форка при наличии значимых разумных и аргументированных возражений. Не обсуждается. Если у кого-то есть хорошо себя зарекомендовавшее разумное применение Биткойна, которое работает сегодня, нет явных причин полагать, что это должно измениться в будущем, а вносимые изменения существенно затрудняют этот вариант использования либо полностью его исключают, то такие изменения не должны вноситься в протокол. Я надеюсь, что это не вызывает ни у кого возражений (см. также важную оговорку в последнем пункте – момент, на который, я уверен, все сразу же укажут). Следует избегать активации софт-форка в сроки, не позволяющие рассчитывать на высокий процент принятия изменений на уровне полных узлов. Отмечу, что, как и во всех аргументах, касающихся нод/узлов, я имею в виду именно «экономически используемые» ноды, а не тысячу или около того нод-наблюдателей на Google Cloud и AWS. Изменения правил – будь то софт- или хард-форк – не будут иметь смысла, если эти правила не будут применяться нодами, поэтому активация в чрезмерно сжатые сроки, делающие невозможным или маловероятным масштабное принятие изменений узлами сети, не имеет никакого смысла, однако может вызвать непреднамеренные побочные эффекты. Не следует (без необходимости) терять хеширующую мощность из-за необновившихся майнеров. Поскольку безопасность Биткойна во многом обеспечивается майнерами, побочный эффект от изменений в виде снижения хеширующей мощности сети будет нежелательным ослаблением ключевого параметра безопасности сети. Поэтому в недавней истории для принятия софт-форков требовалось, чтобы 95% хеширующей мощности сети обновилось и сигнализировало о готовности применять новые правила сети. Кроме того, по этой причине ни один из относительно недавних софт-форков не подразумевал внесения изменений, исключающих обратную совместимость с майнингом на стандартном инстансе Bitcoin Core. Желательно использовать давление хеширующих мощностей, где это возможно, чтобы снизить риски, связанные с процессом обновления. Одна из основных причин для выполнения софт-форков заключается в том, что введение правил, подкрепленное хеширующими мощностями, является элегантным способом избежать разделения сети в процессе обновления узлов. Хотя нет смысла инвестировать материальные ценности в системы, защищенные новыми правилами до тех пор, пока эти правила не начнет применять большинство «экономических узлов», поддержка хеширующих мощностей позволяет нам аккуратно преодолеть временной разрыв между активацией софт-форка и полным переходом на новые правила. Если соблюдение новых правил обеспечивается подавляющим большинством майнеров, то попытки нарушения этих правил не приводят к значимому расколу сети, влияющему на опыт существующих пользователей системы. Не имея намерения воспользоваться этим преимуществом, лучше производить обновление через хард-форк, с неизбежным увеличением сроков, которое это за собой влечет. Необходимо следовать воле сообщества, вне независимости от индивидуальных или необоснованных возражений, однако никогда не отвергая никаких резонных и обоснованных контраргументов. В недавней истории случались «возражения» против софт-форков в духе «это плохо, потому что не решает другую проблему, решение которой я бы хотел увидеть как можно скорее». Думаю, все согласятся, что такого рода возражения против введения предлагаемых изменений нельзя назвать аргументированными, и мы как сообщество (но никогда – как разработчики или иная отдельная группа) должны игнорировать такие реплики и двигаться дальше. Хорошие инженерные решения не достигаются путем объединения в один пакет несвязанных функций ради достижения каких-то политических целей или не имеющего под собой веской аргументации компромисса. На мой взгляд, 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, как минимум, служит источником ценных данных об уровне готовности сообщества и его заинтересованности в реализации предлагаемых изменений. Хотя мы можем (и должны) узнавать много нового о готовности сообщества принять предлагаемые изменения посредством информационных кампаний и открытого обсуждения, есть в изменениях с ограниченными временными рамками что-то, что заставляет людей рассматривать их более тщательно. Таким образом, возвращая обсуждение в более предметное русло, я думаю, что метод активации, который бы устанавливал правильный прецедент и соответствующим образом учитывал описанные выше цели, мог бы выглядеть так: Стандартное развертывание BIP 9 на годичном временном интервале для активации с 95-процентной готовностью майнеров. В случае если активации с течение года не происходит, берется пауза на шесть месяцев, в течение которых сообщество может проанализировать и обсудить причины, по которым активации не произошло. В том случае, если это будет иметь смысл, простое изменение из командной строки параметра в bitcoin.conf, поддерживаемое еще с момента первоначального развертывания, позволит пользователям выбрать развертывание BIP 8 с 24-месячным временным горизонтом для активации в назначенную дату. Это дает очень длительный временной горизонт для более стандартной активации, в то же время обеспечивая достижение целей, обозначенных в 5 пункте, даже если в этих случаях временной горизонт должен быть значительно расширен для соответствия пункту 3. Разработка Биткойна – не гонка на скорость. Ожидание в 42 месяца, если оно потребуется, гарантирует, что мы не создадим неосторожными действиями негативный прецедент, о котором еще придется жалеть позже, по мере дальнейшего роста Биткойна.   Подписывайтесь на BitNovosti в Telegram! Делитесь вашим мнением об этой статье в комментариях ниже. Источник Поделиться ссылкой:Нажмите, чтобы поделиться в vkontakte (Открывается в новом окне)Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)Нажмите, чтобы поделиться в Instagram (Открывается в новом окне)Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)ЕщёНажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)Послать это другу (Открывается в новом окне)Нажмите для печати (Открывается в новом окне)Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне) Related

• 17:00 5 разлоков токенов, за которыми стоит следить на следующей неделе
• 14:57 Майкл ван де Попп: Биткоину грозит сценарий Flash Crash
• 14:28 Криптовалюты растут после заявления «главного злодея»
• 13:05 Эксперт усомнился в успехе биткоин-политики MicroStrategy
• 12:35 4-летние циклы фондового рынка и биткоина: неожиданная синхронизация
• 11:32 Суд Нидерландов оставил создателя криптомиксера Tornado Cash под стражей
• 10:21 В Узбекистане токенизировали права на прибыль от продажи деревьев
• 09:44 Завьялов Илья Николаевич про Aerodrome. Рыночный взгляд (Ч.1).

И еще 5