Сценарии UASF BIP148 и теория игр —
Я написал уже немало статей на тему BIP148, но в последнее время стало появляться большое количество спекуляций на тему того, что будет происходить после старта UASF, назначенного на 1 августа. В этой статье я опишу несколько возможных сценариев реализации BIP148. Но сначала несколько предостережений:
В заключение я выскажу несколько соображений о том, какие факторы в конечном итоге будут иметь значение, но цель этой статьи не в том, чтобы предсказать будущее, а в том, чтобы показать, насколько сложным и разрушительным может оказаться любой из возможных вариантов развития событий.
Для простоты, я буду называть стороны «пользователями» и «майнерами». UASF (активируемый пользователями софт-форк) BIP148 инициируется, соответственно, «пользователями». Конечно, эти категории носят очень приблизительный характер (могут быть пользователи, поддерживающие майнеров, и наоборот) и применяются исключительно для удобства. Имея в виду всё вышесказанное, давайте попробуем взглянуть на несколько сценариев событий, которые может повлечь за собой UASF BIP148.
Майнеры капитулируют
Это, пожалуй, самый простой для понимания сценарий. Майнеры, желая избежать рисков, связанных с софт-форком, решают поддержать SegWit (SegWit2x, блоки расширения либо BIP141) и им удаётся закрепить поддержку SegWit до 1 августа. Простая капитуляция по BIP141 – идеальный сценарий для сторонников BIP148, поскольку это означает, что они получат SegWit, и им не придётся прибегать к софт-форку.
Закрепление SegWit через Segwit2x или блоки расширения также создаст ситуацию, при которой реализация BIP148 станет бесполезной. Это не обязательно будет идеальным вариантом для сторонников BIP148, но тем не менее тоже позволит избежать софт-форка. В результате, в Биткойне будет реализована поддержка SegWit, так что этот сценарий можно признать, по крайней мере, частичной победой пользователей, даже если он и будет сопровождаться более значительным увеличением размера блока.
Пользователи получают минимально необходимые хэширующие мощности
В этом сценарии 1 августа у пользователей будет что-то вроде от 0 до 13% хэширующих мощностей сети по состоянию на 31 июля. Очевидное следствие столь малой скорости хэширования – очень медленное формирование блоков (1 блок/80+ минут). Это создаст две большие проблемы.
Первая проблема будет заключаться в том, что в блокчейне пользователей образуется огромное количество неподтверждённых транзакций. На подтверждение транзакций потребуется очень много времени, и, поскольку размер блока ограничен, комиссии будут очень высоки. Стоимость и скорость проведения транзакций в пользовательском форке может оказать сильное давление на цену в сторону её снижения. Это, в свою очередь, может привести к переходу хэширующих мощностей на блокчейн майнеров, что ещё больше усугубит ситуацию.
Вторая проблема – это то, что у многих могут возникнуть сомнения в том, будет ли SegWit активирован на блокчейне пользователей! Дело в том, что для активации SegWit необходимо, чтобы 95% блоков сигнализировали SegWit в течение двухнедельного периода корректирования сложности сети, который должен закончиться до 15 ноября. Однако, поскольку пользователи будут контролировать <13% от хэширующих мощностей, период корректирования сложности сети займёт более 15 недель. Период с 1 августа по 15 ноября насчитывает всего около 15 недель, что ставит активацию SegWit (BIP141) на пользовательском форке под сомнение.
И тогда возникает очевидный вопрос: а зачем вообще нужен форк, если он не приведёт к активации SegWit? В конце концов, не будет ли проще назначить другую дату для «дня установления флага» UASF – после 15 ноября? Чем более очевидным будет становиться то, что SegWit не будет активирован, тем меньше будет у хэширующих мощностей причин оставаться на пользовательском форке.
Майнеры ничего не предпринимают
В этом сценарии пользователи будут контролировать от 25% до 75% хэширующих мощностей сети. Майнеры же в этом сценарии не выказывают никакой реакции – словно олень, замерший в свете фар.
Если пользовательский форк получит 51% хэш-мощности и более, то останется только одна ветка и на этой ветке будут поддерживаться только блоки, сигнализирующие SegWit. В этом случае может возникнуть большое количество потерянных блоков и, возможно, их реорганизаций, которые порой могут затрагивать по 3–4 блока. Это значительно упростит двойное расходование, поэтому биржи и предприниматели, скорее всего, не будут принимать транзакции менее чем с 6 или 8 подтверждениями, но в остальном всё будет происходить почти как обычно. Здесь стоит отметить, что «сценарий 51–65 %» на самом деле сложнее, но, для удобства, я отошлю читателя к уже опубликованной мной ранее статье.
Если пользовательский форк получит менее 50% хэш-мощностей, то будут существовать две цепочки –пользователей и майнеров. Если в какой-то момент пользовательская цепочка получит больше хэш-мощностей и превзойдёт по длине цепочку майнеров, то именно здесь сыграет свою роль тот факт, что UASF является софт-форком. Цепочка майнеров в этом случае будет стёрта. То есть все блоки в цепочке майнеров будут заменены пользовательским форком.
Таким образом, никаким подтверждениям на форке майнеров доверять будет нельзя, и это приведёт к многочисленным нарушениям. Конечно, биржи и предприниматели по-прежнему смогут принимать монеты форка майнеров, но любые монеты, акцептованные или распределённые в форке майнеров, в этом сценарии будут связаны с большим риском, поскольку могут попросту исчезнуть.
Риск уничтожения цепочки даст майнерам огромный стимул к тому, чтобы постараться устранить этот риск, особенно когда пользовательский форк начнёт догонять по длине цепочку майнеров. Но в этом сценарии мы рассматриваем ситуацию, в которой майнеры не предпринимают ничего и этот риск не устраняется по причине, например, внутренних распрей или слишком медленной разработки.
Обратите внимание, что, с точки зрения майнеров, UASF очень напоминает атаку. Это связано с тем, что UASF, с их точки зрения, выглядит как принуждение (особенно в отношении поддержки SegWit), а ведь никому не нравится, когда ему указывают, что делать, даже если он и согласен с необходимостью этих действий. Следовательно, даже в случае реализации сценария, в котором майнеры не вырабатывают никакой коллективной реакции, вполне могут иметь место индивидуальные реакции, направленные на то, чтобы помешать росту пользовательского форка. Важно отметить, что при реализации подобного сценария чрезвычайно опасно осуществлять любые транзакции на форке майнеров.
Майнеры реализуют перманентный форк
Как я уже упоминал в предыдущем сценарии, у майнеров уже есть стимул для того, чтобы устранить риск стирания их цепочки. Существует и другой риск для обеих цепочек, и это риск дублирования транзакций. Для того чтобы объяснить и тот и другой риск, давайте взглянем на ситуацию с точки зрения биржи.
В течение всего этого времени будет существовать огромная потребность в бирже, осуществляющей торги монетами и пользовательского форка, и форка майнеров. В конце концов, сторонники UASF захотят продать принадлежащие им монеты форка майнеров и приобрести монеты форка пользователей. Для того чтобы биржи могли предложить пользователям такой обмен, им нужно иметь возможность осуществлять на обеих цепочках два основных вида транзакций: пополнение счёта и снятие средств.
Обычно биржи засчитывают пополнение счёта после 3-х (или около того) подтверждений сети. Однако, когда возникает риск стирания той или иной цепочки, этого количества подтверждений недостаточно. Если пользовательский форк может превзойти по длине цепочку майнеров через 100 блоков, то некоторые операции пополнения счёта, имеющие до 100 подтверждений, могут оказаться недействительными! Принимая депозиты на форке майнеров, биржа будет принимать на себя значительный риск. Этот риск будет расти по мере того, как пользовательский форк будет догонять по длине форк майнеров.
Кроме того, в нормальной ситуации биржи производят вывод средств по запросам пользователей, не особенно задумываясь о риске атаки повторения. В отсутствие защиты от атак повторения, когда биржа выплачивает 5 BTC на пользовательском форке, может произойти также списание 5 BTC на тот же адрес и на форке майнеров. Это же произойти и другим образом, когда при выплате 5 BTC на форке майнеров, могут списаться и 5 BTC на форке пользователей. Эту проблему можно решить при помощи программного обеспечения, которое будет гарантировать, что транзакция, осуществляемая в одном форке, не будет действительна также и в другом, но реализовать такое решение может оказаться непросто, к тому же в программном обеспечении тоже могут быть ошибки. Coinbase, например, потеряла крупную сумму денег из-за атак повторения при разделении блокчейна Эфириума.
Таким образом, для того чтобы допустить торговлю монетами и пользовательского форка, и форка майнеров, биржам необходимо обезопасить себя от стирания той или иной цепочки и от атак повторения.
С этим есть проблема. Для того чтобы такая защита была возможна, форк между монетами должен стать перманентным. По крайней мере, исходя из того, что Биткойн представляет собой сегодня, нет никакой возможности предложить защиту от стирания транзакций или атак повторения без того, чтобы исключить также и возможность слияния цепочек в одну. Однако мы уже знаем по опыту, что люди будут требовать возможность торговать монетами обеих цепочек. Поэтому есть вероятность, что майнеры пойдут на хард-форк.
Этого можно достичь несколькими путями, но что-то вроде изменения версии транзакции (в настоящее время 1, но, посредством хард-форка, в цепочке майнеров её можно изменить на 2) будет работать достаточно хорошо. Кроме того, если уж майнеры будут выполнять хард-форк, то они вполне могут заодно увеличить максимальный размер блока до 2 МБ. Чёрт побери, они могут даже начать сигнализировать SegWit (немедленно, а не дожидаясь закрепления и активации), разбив таким образом последний аргумент в пользу форка пользователей.
Таким образом, мы можем увидеть странную ситуацию, когда на форке майнеров будет поддержка SegWit, а на пользовательском форке – нет (по причине того, что у них окажется менее 13% хэширующих мощностей, и SegWit не будет активирован в срок). Поговорим теперь о ещё более странных сценариях!
Майнеры атакуют форк пользователей
В этом сценарии мы предположим, что пользовательский форк будет иметь меньше 33% хэширующих мощностей и майнеры примут решение его атаковать. Цель атаки будет заключаться в том, чтобы сделать небезопасным осуществление транзакций на форке пользователей.
Самой простой может быть атака реорганизацией блоков, которая работает следующим образом: скажем, 1 августа, после полуночи, на форке пользователей формируется 10 блоков за 10 часов. Майнеры выделяют немного больше хэш-мощности, чем есть всего у форка пользователей, чтобы тайно сформировать 11 пустых блоков, сигнализирующих SegWit начиная с полуночи. Эти блоки не включаются в сеть и их формирование занимает меньше времени благодаря более высокой скорости хэширования. Как только в пользовательском форке формируется 10-й блок, майнеры выпускают 11 пустых блоков. Пользовательский форк немедленно реорганизуется, и 10 блоков транзакций внезапно возвращаются в пул памяти.
Это очень похоже на стирание, но только достигается посредством явной атаки. Биржи и предприниматели, получившие монеты на форке пользователей, могут обнаружить, что соответствующие операции пополнения и вывода средств более недействительны. Зная о проведении атаки, они могут заморозить любые операции на форке пользователей.
У пользовательского форка в этом случае есть два варианта. Они могут либо сохранить текущий Proof-of-Work и быть вынужденными защищаться от атак, либо изменить алгоритм Proof-of-Work. Это, по сути, разные сценарии, так что давайте рассмотрим каждый из них в отдельности.
Пользователи пытаются защититься от атак майнеров
В предыдущем сценарии, майнеры атаковали пользовательский форк при помощи пустых блоков. Для того чтобы защититься от этой атаки, пользовательский форк решает внести изменения в правила и запретить пустые блоки. Это можно реализовать через софт-форк и поможет избежать вышеописанной атаки.
Всем, кто использует пользовательский форк, понадобится обновить программное обеспечение, причём переход на новую версию должен осуществляться одновременно, чтобы предотвратить появление ещё большего количества цепочек помимо тех 2-х, что уже и без того существуют. Пользователи предпринимают титанические усилия, чтобы написать, протестировать, упаковать и распространить необходимое программное обеспечение. На это уходит 8 часов и пользовательский форк умудряется добавить это правило в 00:00 2 августа. Все экономически значимые ноды за эти несколько часов успели обновить своё программное обеспечение.
Майнеры видят это обновление (так как это ПО с открытым исходным кодом) и решают снова атаковать. Атака проводится точно таким же образом: втайне майнятся 11 блоков за то же время, какое занимает формирование 10 блоков в пользовательском форке, но на этот раз в каждый блок добавляется одна транзакция, что позволит обойти нововведённое правило. Таким образом, майнерам удаётся стереть 10 блоков с транзакциями на форке пользователей.
Пользователи могут реализовать ещё один софт-форк – на этот раз, запретив формирование блоков с менее чем 20 транзакциями. Майнеры, видя изменения, вносимые в программное обеспечение, могут провести очередную атаку, включив в каждый блок по 21 транзакции. Это может повторяться снова и снова и превратиться во что-то вроде игры «ударь крота».
До тех пор, пока используется программное обеспечение с открытым исходным кодом, основанное на алгоритме Proof-of-Work, и под контролем майнеров находится больше хэширующих мощностей, майнеры, за счёт большей скорости хэширования, всегда смогут найти возможность для атаки. Во время таких атак выполнение транзакций на форке пользователей оказывается сильно затруднённым, поскольку транзакции могут быть стёрты в любой момент. Важно отметить, что при реализации подобного сценария чрезвычайно опасно осуществлять любые транзакции на форке пользователей.
Пользователи изменяют алгоритм Proof-of-Work
В этом сценарии пользователи изменяют алгоритм Proof-of-Work, чтобы защититься от атак, основанных на хэширующей мощности.
Очевидно, что это намного более масштабное изменение, для реализации которого требуется хард-форк. Хард-форк очень трудно реализовать гладко – вот почему разработчики обычно запрашивают на это временные рамки от 6 до 18 месяцев. В этом же случае, необходимые изменения понадобится внести в течение нескольких дней или даже нескольких часов. Кроме того, хэширующая мощность в новом алгоритме должна обеспечиваться таким образом, чтобы значительно уменьшить вероятность атаки. Например, если новый PoW-алгоритм будет допускать майнинг только на CPU, то пользователям потребуется обеспечить защиту и для крупных CPU-ферм.
Стоит отметить, что это не гарантирует пользователям защиту. С большой вероятностью, они останутся уязвимыми для новых атак (в случае с CPU, майнеры, если будут ожидать именно такого изменения PoW, смогут приготовиться к этому заранее путём скупки бот-сетей).
В этом сценарии пользователи подвергаются атакам со стороны майнеров, однако вполне возможно, что и пользователи могут атаковать майнеров, если под их контролем окажется больше хэширующих мощностей. Цепочка, имеющая меньше хэширующих мощностей, может подвергаться атакам и будет менее стабильна, в меньшей степени пригодна для использования и в большей степени рискует допустить ошибку при внесении изменений в работу сети.
Что это означает для вас
Так что же всё это значит для вас?
Вам нужно соблюдать большую осторожность, проводя транзакции после 1 августа. Существуют сценарии развития событий, при реализации которых ваша транзакция будет стёрта независимо от того, какой форк вы выберете. Такой риск, в той или иной мере, существует в обеих цепочках, и я полагаю, что большинство людей не решатся что-то предпринимать до тех пор, пока не будет в той или иной форме опубликовано некое разрешение.
Заключение
Верьте или нет, но я считаю, что борьба будет даже более грязной, чем я здесь описал. Это лишь грубые вычисления первого порядка в теории игр. Вероятнее всего, будет намного больше ходов, каждый из которых будет порождать собственные сценарии в количестве и разнообразии не меньшем, чем те, что описаны в этой статье.
Невозможно проанализировать каждый вероятный сценарий, но можно получить некоторое представление о силе, которая имеется у каждой из сторон. Вот что будет иметь значение в предстоящем конфликте:
Если у вас есть вопросы о различных сценариях, вероятных атаках и т. п., вы можете задать их мне в комментариях. Позже на этой неделе я напишу отдельный пост, посвящённый ответам на ваши вопросы.
