BIP 8, BIP 9 либо современная активация софт-форка: каким быть может последующее обновление Биткойна

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 содержит в себе некие конфигурации. Во-1-х, BIP 8 дозволяет к истечению срока изменять ноды сразу под две разных политики: с принудительной активацией, как описывалось в 2-ух прошлых абзацах, либо без принудительной активации, как в 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 с активацией в назначенную дату (хотя вероятен и вариант с принудительной сигнализацией).

1-ый шаг, как и в BIP 9 заключается в том, что майнеры получают возможность активировать софт-форк средством хеширующих мощностей. Если активации не происходит в течение, скажем, года, то срок первого периода активации исходит. Тогда вторым шагом, создатели берут некое время на то, чтоб проанализировать причину, по которой активация не свершилась, и, может быть, пересмотреть предложение, если найдут источник задачи в нем. Если же они сделают вывод, что неувязка кроется не в предложении, то 3-ий шаг состоит в повторной попытке активации софт-форка, сейчас с внедрением механизма BIP 8 с активацией в назначенную дату: майнеры опять получают шанс активировать предложение средством хеширующих мощностей, но если этого вновь не произойдет, софт-форк активизируется автоматом по окончании второго сигнального периода. (В течение этого второго сигнального периода также может равномерно понижаться требуемый для активации пороговый процент хеширующей мощности, как дает очередной разраб Bitcoin Core Энтони Таунс.)

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

Основной аргумент против «современной активации софт-форка» состоит в том, что при отсутствии содействия со стороны майнеров этот процесс занимает достаточно много времени, а некие и совсем считают 1-ый шаг с попыткой активации по BIP 9 пустой растратой времени. Первоначальное предложение Коралло включает один год сигнализации по BIP 9, потом 6 месяцев на пересмотр предложения, и, в конце концов, два года сигнализации по 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 состоит в том, что отсрочка обновления по инициативе (либо отсутствию инициативы) майнеров не просит от их никаких издержек. Обычный отказ говорить о готовности к обновлению не стоит им ничего и при всем этом потенциально быть может применен для политического давления на сеть.

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

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

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

 

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

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

 

Делитесь вашим воззрением о данной для нас статье в комментах ниже.

Author: Anonim