Содержание статьи:
Taproot, предлагаемое обновление протокола, призванное улучшить конфиденциальность и гибкость Биткойна, находится на поздних фазах разработки. Разработчики Bitcoin Core сходятся в том, что это обновление будет полезно для Биткойна, и более широкая экосистема Биткойна, похоже, пока тоже его приветствует. Поэтому кажется вполне вероятным, что Taproot войдет в один из релизов Bitcoin Core, а за этим могут последовать и другие имплементации.
Однако один вопрос остается пока неотвеченным: как именно должно происходить обновление самой сети Биткойна? Taproot – это изменение протокола консенсуса, то есть подразумевается, что биткойн-ноды должны каким-то образом переключиться со старых правил на новые, не расколов сеть на части, применяющие разные правила. По разным причинам в прошлом это иногда оказывалось непростой задачей.
Сейчас сообществом рассматриваются усовершенствованные стратегии активации обновлений протокола.
Предыдущие софт-форки и BIP 9
Хорошая новость состоит в том, что Taproot может быть активирован через софт-форк. Этот тип обновления позволяет добавлять новые или ужесточать имеющиеся правила – в отличие от хард-форков, в которых правила могут также удаляться либо ослабляться. Плюс добавления или ужесточения правил заключается в том, что все, что считают валидным обновленные ноды, необновленные ноды тоже считают таковым. То есть существует обратная совместимость: если старая нода принимает оба типа транзакций, А и Б, а по новым правилам транзакции должны принадлежать к типу А, то старая нода будет оставаться совместимой с сетью, применяющей новые правила.
Ранние софт-форки Биткойна активировались в заранее запланированные даты (flag days). Разработчики (в частности, Сатоши Накамото) вписывали будущую дату в код нового релиза клиентского ПО Биткойна, указывая момент времени, начиная с которого обновленные ноды будут применять новые правила. Майнерам и пользователям (кстати, в те дни это чаще были одни и те же люди, нежели сегодня) рекомендовалось обновиться до указанной даты, чтобы избежать разделения сети.
Поскольку необновленные ноды остаются совместимыми с новыми правилами, удобное преимущество софт-форков заключается в том, что, если большая часть хеш-мощностей выполнит обновление и перейдет на новые правила, то и вся сеть найдет консенсус в их версии блокчейна. Это также подразумевает меньше настоятельной необходимости в немедленном обновлении всех нод сразу после активации новых правил, что дает пользователям некоторую гибкость. (Хотя пользователям все равно рекомендуется обновиться – в конце концов, именно они обеспечивают соблюдение новых правил, отклоняя не соответствующие им транзакции и блоки.)
Примерно с 2012 года хеширующие мощности все чаще стали использоваться в качестве координационного механизма при проведении софт-форков для согласованного переключения на новые правила. Включая в свои блоки дополнительный фрагмент данных, майнеры могут сигнализировать остальной сети о том, что они обновили свое ПО и готовы к применению новых правил. Когда о поддержке сигнализирует достаточное количество хеширующих мощностей, все обновленные ноды начинают применять новые правила.
В процессе нескольких обновлений эта стратегия эволюционировала до Bitcoin Improvement Proposal 9 (BIP 9) («Предложение по улучшению Биткойна 9»). Механизм BIP 9 использовался, например, для активации последнего софт-форка Биткойна, Segregated Witness (SegWit). Майнерам был дан год на то, чтобы активировать обновление. Для этого требовалось, чтобы 95 процентов блоков в любом интервале сложности включали фрагмент данных, сигнализирующий о готовности к переходу на новые правила. Если бы этого не случилось в течение года, период активации истек бы, и обновления правил сети не произошло. (Конечно, в этом случае можно было бы просто попробовать еще раз.)
Однако в случае с SegWit BIP 9 сработал небезупречно. Как и в случае с некоторыми предыдущими обновлениями, часть майнеров не обновлялась какое-то время – вероятно, из безразличия: часто у майнеров нет какого-то существенного стимула к тому, чтобы обновиться оперативно. Но куда большая проблема заключалась в том, что некоторые майнеры восприняли процесс сигнализации как своего рода голосование об обновлении, в котором, вместо подачи сигнала о технической готовности работать по новым правилам, они будут сигнализировать (или нет) о своей поддержке этих правил. Хуже того, некоторые майнеры в конечном счете стали использовать это «голосование», чтобы заблокировать обновление и попытаться получить политическое влияние на процесс разработки Биткойна, и/или они «голосовали» против обновления, чтобы тайно извлекать выгоду из некоего недочета в протоколе, исправляемого в этом обновлении.
После продолжительных и довольно драматичных перипетий, SegWit в конечном счете был активирован, но только после выпуска альтернативных биткойн-клиентов включавших новые схемы активации. Клиентские программы с включенным BIP 148, на которые переключилась часть пользователей, были написаны таким образом, чтобы, начиная с заданной даты, принимать исключительно блоки, сигнализирующие о поддержке обновления протокола. Тем временем, BIP 91, включенное в клиент btc1 и запущенное майнерами прямо перед датой, прописанной в BIP 148, фактически снижал требуемую для активации хеш-мощность с 95 до 75 процентов. Перед лицом потенциального раскола сети и вероятной потери дохода препятствовавшие обновлению майнеры отступили. Но по мнению большинства разработчиков Bitcoin Core, BIP 9 оказалось неоптимальным решением, и они начали думать об альтернативах.
BIP 8
BIP 8 было ранней альтернативой BIP 9, предложенной Shaolinfry (автором BIP 148) и Luke-jr, разработчиком Bitcoin Knots и Bitcoin Core. Оно практически идентично BIP 9, за одним существенным отличием: вместо отмены обновления через год в случае неполучения достаточной поддержки хеширующих мощностей, BIP 8 предусматривает прямо противоположное – активацию софт-форка. Как и при простом обновлении в заданную дату, все обновленные ноды с определенного дня начинают применять новые правила. Необновившиеся майнеры при этом рискуют, что добываемые ими блоки будут отвергаться обновившимися майнерами и пользователями.
Основная идея BIP 8 состоит в том, что такой механизм не позволяет майнерам блокировать софт-форк, а значит, они не могут использовать это в своих интересах. Майнеры имеют возможность ускорить активацию и помочь скоординировать плавное обновление протокола, но обновление в конечном счете произойдет, даже если они не активируют его сами.
Более поздний проект BIP 8 включает в себя некоторые изменения. Во-первых, BIP 8 позволяет к истечению срока конфигурировать ноды одновременно под две различных политики: с принудительной активацией, как описывалось в двух предыдущих абзацах, или без принудительной активации, как в BIP 9. Кроме того, настроенные таким образом ноды, вместо того, чтобы непосредственно активировать обновление, фактически обеспечивают сигнализацию за обновление. Блоки, не сигнализирующие о поддержке обновления, отклоняются, а значит, работа по новым правилам по-прежнему гарантируется, по крайней мере, в отношении обновленных нод. В сочетании эти два изменения дают интересный эффект: если большая часть хеширующих мощностей Биткойна будет вынуждена сигнализировать о поддержке обновления, то даже BIP 8 ноды, не настроенные на то, чтобы форсировать сигнализацию, присоединятся к обновлению.
Аргумент против BIP 8, с его принудительной сигнализацией (или автоматической активацией), в частности, состоит в том, что такой механизм может оказаться рискованным, особенно при сжатых сроках реализации. Если большая часть хеш-мощностей и по крайней мере часть пользователей не обновятся, такой механизм активации может спровоцировать разделение сети на две части – с обновленными и необновленными нодами. Если предположить, что большинство пользователей поддерживают обновление, то в конечном счете ситуация, вероятно, разрешится в пользу обновленной части сети. Но при этом необновившиеся пользователи будут рисковать потерять средства, а необновившиеся майнеры будут тратить контролируемые ими хеш-мощности в ущерб безопасности Биткойна.
Пожалуй, эффективнее всего противодействовать этому риску можно, заложив на обновление достаточные сроки. К сожалению, общего консенсуса в отношении того, какой срок считать достаточным, пока не сформировалось; одни считают, что к принудительной сигнализации можно переходить через год или даже раньше, другие – что на процесс обновления нужно закладывать несколько лет.
Еще одна сложность с BIP 8 заключается в настройке по умолчанию для принудительной сигнализации. Если принудительная сигнализация по умолчанию будет отключена, пользователи могут повести себя несогласованно, увеличивая риск раскола сети. С другой стороны, если принудительная сигнализация будет включена по умолчанию в релизе Bitcoin Core, то, учитывая распространенность ПО Bitcoin Core, это само по себе практически гарантирует обновление. И есть мнение, что это наделит разработчиков Bitcoin Core слишком большим влиянием на правила протокола Биткойна. Соавтор BIP 8 Luke-jr считает правильным, чтобы BIP 8 реализовывалось только через специальные клиентские программы, подобно клиенту BIP 148.
Другие возражают, что разработчики Bitcoin Core, в общем, всегда выпускают ПО, руководствуясь собственными соображениями, учитывая запросы пользователей и избегая спорных обновлений, и установка настроек по умолчанию для BIP 8 не должна быть исключением. В конце концов, тот, кто несогласен с выбором Bitcoin Core, может просто отказаться от обновления до нового релиза или даже форкнуть код Bitcoin Core и выпустить конкурирующий клиент.
Современная активация софт-форка
Хотя разработчики Bitcoin Core действительно стараются принимать во внимание пользовательский спрос и избегают спорных обновлений, не все согласны, что это всегда возможно в полной мере соблюсти. Существует вероятность того, что сомнения в отношении предлагаемого обновления выйдут на поверхность только с выходом нового релиза. Возможно, этот релиз поставит перед сообществом совершенно иные проблемы. Или, может быть, на этот раз Bitcoin Core просто что-то упустили.
Это одна из причин, почему разработчик Bitcoin Core Мэтт Коралло предложил вниманию сообщества стратегию под названием «Современная активация софт-форка». Эта стратегия включает в себя три этапа, вместе, по сути, представляющие собой сочетание BIP 9 (или BIP 8 без принудительной сигнализации) и BIP 8 с активацией в назначенную дату (хотя возможен и вариант с принудительной сигнализацией).
Первый шаг, как и в BIP 9 состоит в том, что майнеры получают возможность активировать софт-форк посредством хеширующих мощностей. Если активации не происходит в течение, скажем, года, то срок первого периода активации истекает. Тогда вторым шагом, разработчики берут некоторое время на то, чтобы проанализировать причину, по которой активация не состоялась, и, возможно, пересмотреть предложение, если обнаружат источник проблемы в нем. Если же они придут к выводу, что проблема кроется не в предложении, то третий шаг состоит в повторной попытке активации софт-форка, на этот раз с использованием механизма BIP 8 с активацией в назначенную дату: майнеры снова получают шанс активировать предложение посредством хеширующих мощностей, но если этого вновь не произойдет, софт-форк активируется автоматически по окончании второго сигнального периода. (В течение этого второго сигнального периода также может постепенно снижаться требуемый для активации пороговый процент хеширующей мощности, как предлагает еще один разработчик Bitcoin Core Энтони Таунс.)
Коралло считает, что стратегия с повторным запуском (в случае, если не будет выявлено проблем с самим предложением) процесса софт-форка по BIP 8 сохранит все преимущества BIP 9, нивелировав при этом его недостатки. Код выкладывается на всеобщее обозрение в первом сигнальном периоде, майнеры, при желании, могут скоординировать плавное обновление, а если активации софт-форка в первый сигнальный период не произойдет, то, в отсутствие даты принудительной активации, у разработчиков есть возможность уделить пересмотру предложения столько времени, сколько потребуется. При этом у майнеры имеют намного меньшую мотивацию блокировать обновление без веской на то причины, потому что они знают, что в конечном счете софт-форк все равно будет активирован.
Главный аргумент против «современной активации софт-форка» заключается в том, что при отсутствии содействия со стороны майнеров этот процесс занимает довольно много времени, а некоторые и вовсе считают первый этап с попыткой активации по BIP 9 пустой тратой времени. Первоначальное предложение Коралло включает один год сигнализации по BIP 9, затем шесть месяцев на пересмотр предложения, и, наконец, два года сигнализации по BIP 8 перед автоматической активацией – в общей сложности 3,5 года. Хотя, конечно, эти сроки еще не утверждены окончательно, сокращение временных интервалов, отводимых на описанные выше этапы, оставило бы меньше времени на пересмотр предложения разработчиками и/или обновление ПО участниками, в обоих случаях повышая риск раскола сети.
Многие также опасаются, что, ввиду большого запаса времени до потенциальной принудительной активации, майнеры могут попытаться приобрести некое политическое влияние, и в случае успеха это может отсрочить активацию изменений на годы.
BIP 8 + BIP 91
Еще одно недавнее предложение, циркулирующее в «технических» коммуникационных каналах биткойн-комьюнити, пожалуй, лучше всего описывается как некий гибрид BIP 8 и «современной активации софт-форка», по крайней мере, по духу. Безымянное предложение подразумевает длительный период сигнализации по BIP 8 – его продолжительность может быть сравнима с 3,5 годами «современной активации», – по окончании которого включается принудительная сигнализация. Однако если, скажем, через год обновление еще не было активировано, разработчики, как и при «современной активации», могут взять некоторое время на то, чтобы пересмотреть предложение.
Если проблем с предложением выявлено не будет, и разработчики придут к выводу, что активации не произошло из-за апатии майнеров или по иной несостоятельной причине, они могут принять решение о проведении софт-форка по BIP 91, использовавшемуся при активации SegWit. Это фактически снизило бы необходимое для активации пороговое значение поддержки хеширующих мощностей, предположительно ускорив процесс активации.
С другой стороны, если разработчики все-таки обнаружат проблему в предложении, они могут развернуть новый софт-форк, исправляющий эту проблему, или даже полностью отменяющий исходный софт-форк (в данном случае Taproot). Обозначенных сроков «современной активации софт-форка» – 3,5 года до принудительной сигнализации – должно быть достаточно для пересмотра предложения, принятия и воплощения в жизнь соответствующего решения.
Главный аргумент против этого предложения, пожалуй, заключается в том, что разворачивать в случае необходимости софт-форк который бы отменял другой софт-форк, представляется не слишком элегантным решением. Конкретнее, оно подразумевает необходимость для майнеров и пользователей обновляться до новых релизов ПО до истечения изначально обозначенных сроков перед лицом риска разделения сети.
Спорки (Sporks)
Наконец, в качестве нестандартной идеи, несколько выпадающей из общего контекста, разработчик Bitcoin Core Джереми Рубин предположил, что изобретенная им концепция «вероятностных софт-форков», или «спорков» (англ. spork – вилка, комбинированная с ложкой, образуется от слов spoon [ложка] и fork [вилка]), может лучше согласовываться со стимулами участников сети, нежели обычные софт-форки, обеспечиваемые хеширующими мощностями.
По мнению Рубина, суть проблемы BIP 9 заключается в том, что отсрочка обновления по инициативе (или отсутствию инициативы) майнеров не требует от них никаких затрат. Простой отказ сигнализировать о готовности к обновлению не стоит им ничего и при этом потенциально может быть использован для политического давления на сеть.
В «спорке» сигнал о готовности получается не из фрагмента данных, включаемого майнерами в добываемые ими блоки, а из хеша заголовка блока, случайным образом сгенерированного доказательства работы, которую они произвели, инвестировав в это время и ресурсы. Обновленные ноды соглашаются, что небольшое количество хешей заголовков валидных блоков – статистически они могут находиться с периодичностью в шесть месяцев или около того – будет служить триггером для активации обновления.
Из-за случайной природы хешей, майнер не будет контролировать, производит ли он обычные хеши заголовков блоков или хеши, активирующие обновление; он просто статистически будет случайным образом периодически выдавать один из последних. Таким образом, если, потратив на это необходимые ресурсы, он случайно сгенерирует хеш заголовка, активирующий обновление, у него будет два варианта: либо передать его в сеть, получить награду за блок и активировать софт-форк, либо воздержаться от передачи блока, отложив активацию софт-форка, в среднем, примерно на шесть месяцев, но ценой отказа от награды за уже добытый блок. При таком подходе отсрочка обновления будет требовать существенных затрат.
Основная проблема со спорками на сегодня заключается, пожалуй, в том, что это относительно новая идея, не прошедшая еще должной проработки и обсуждения, не говоря уже о проверке в реальных условиях. Хотя многие находят такую концепцию интересной, наиболее вероятным претендентом на роль метода активации Taproot она пока еще не является.
Еще одна идея, набирающая популярность в последнее время, заключается в том, чтобы сначала развернуть BIP 8 с относительно длительным периодом сигнализации (скажем, два года) и без принудительной сигнализации по окончании этого периода. Это позволит майнерам относительно нормально активировать софт-форк, как они уже делали это несколько раз в прошлом. Однако, если через какое-то время (например, через шесть месяцев) софт-форк не будет активирован без видимой веской причины для задержки, может быть выпущен новый программный клиент, тоже с BIP 8, только уже с включенной принудительной сигнализацией ближе к концу заданного изначально периода или еще раньше. Предполагается, что в этом случае большинство майнеров активируют софт-форк либо еще до, либо в течение этого периода принудительной сигнализации.
Дискуссии об активации софт-форков вообще и Taproot в частности идут полным ходом; это не исчерпывающий обзор всех имеющихся предложений об обновлении Биткойна, особенно если учитывать предложения с альтернативными параметрами и настройками, со всеми их подразумеваемыми плюсами и минусами.
Подписывайтесь на BitNovosti в Telegram!
