Авторы BitMEX Research обсуждают устойчивость Ethereum к цензуре после активации The Merge в контексте недавнего решения OFAC (Управления по контролю за иностранными активами США) о наложении санкций на смарт-контракт микшера Tornado Cash.
Основное внимание уделяется техническим особенностям proof-of-stake системы и тому, как она может цензурировать транзакции и реагировать на эту цензуру, если стейкеры станут соблюдать санкции, полностью или частично. Поговорим также об изменениях в системе MEV-аукциона после The Merge и о том, как это может повлиять на устойчивость сети к цензуре. Вывод состоит в том, что с proof-of-stake сопряжено гораздо больше сложностей в том, что касается обеспечения цензуроустойчивости сети, нежели с proof-of-work. Важно также, что обновленная для The Merge архитектура MEV-аукциона существенно усугубляет эту проблему, хотя в будущих обновлениях ПО этот фактор может быть смягчен.
Обзор
Восьмого августа 2022 года Министерство финансов США объявило о внесении в санкционный список смарт-контракта микшера Tornado Cash, работающего на Ethereum. Мы здесь не будем сильно вдаваться в правомерность или неправомерность этого решения, хотя это очень богатая тема для обсуждения (санкции против ПО с открытым кодом и преследование его разработчика). Но мы сосредоточимся скорее на некоторых технических соображениях в отношении того, как именно может меняться Ethereum после активации The Merge и перехода на proof-of-stake (PoS).
Начать, наверное, нужно с того, что и в proof-of-work (PoW), и в PoS-системах выбор, встающий перед майнерами и стейкерами, оказавшихся перед лицом подобных санкций, не является простым и бинарным. Это не просто выбор между решением блокировать транзакции по требованию OFAC или игнорировать подобные требования. Здесь есть больше нюансов. Можно сказать, что базовых вариантов три:
- игнорировать правила OFAC;
- отказ от включения запрещенных OFAC транзакций в свои блоки;
- отказ от продолжения ветки блокчейна, включающей транзакции, запрещенные OFAC.
Вторую опцию можно назвать гораздо более консервативной и умеренной в сравнении с третьей. Многие считают также, что вариант 2 совершенно легитимен: в конце концов, создатели блоков должны иметь право включать в них любые транзакции по своему усмотрению. И если они хотят исключить те или иные транзакции, то это их свободный выбор.
Вариант 3, с другой стороны, представляется гораздо более экстремальным и многими расценивается как атака на сеть. Если те, кто придерживается третьего варианта, контролируют меньшую часть хешрейта, это, вероятно, станет неудачной попыткой цензуры и приведет к значительной потере капитала для потенциальных цензоров. Если же такой цензор (коллективный или нет) находится в большинстве и добивается успеха, это означает серьезнейший кризис для сети, возможно, даже экзистенциальный.
Сложности, связанные с proof-of-stake
Переходя к особенностям proof-of-stake системы Ethereum, нюансов появляется еще больше. Вместо трех базовых вариантов реакции на подобные регуляторные требования, мы нашли по меньшей мере восемь возможных вариантов. На самом деле можно было бы выделить и больше, но в такие дебри мы здесь углубляться не будем.
- Отказ от включения в свои блоки запрещенных OFAC транзакций.
- Отказ от подтверждения блоков, содержащих запрещенные OFAC транзакции.
- Создание и подтверждение блоков, соответствующих правилам OFAC, даже если они конфликтуют с блоками, не соответствующими этим правилам.
- Отказ от создания блоков поверх тех, что содержат запрещенные OFAC транзакции.
- Отказ от подтверждения блоков в блокчейне, содержащем запрещенные OFAC транзакции.
- Отказ от включения в свои блоки подтверждений блоков с запрещенными OFAC транзакциями.
- Отказ от включения в свои блоки подтверждений блоков в блокчейне, содержащем запрещенные OFAC транзакции.
- Игнорировать правила OFAC.
Многие участники сообщества Ethereum (и криптокомьюнити в целом) видят в перспективе такой цензуры серьезную проблему. В частности, значительная часть «стейка» (заблокированного для стейкинга капитала) Ethereum сосредоточена в крупных финансовых организациях, часто в юрисдикции США, таких как Coinbase. Поэтому многие высказываются в поддержку потенциального принятия экстренных мер — таких как UASF (активируемый пользователями софтфорк) или хардфорк — для удаления залога валидаторов, реализующих такую цензуру. Это даже преподносится как важное преимущество PoS.
Выход из пула валидаторов может занять много времени — по меньшей мере несколько месяцев, если речь идет о крупном участии. Это дает комьюнити Ethereum время на то, чтобы организовать изменение протокола и наказать провинившихся стейкеров. При PoW гораздо сложнее прицельно наказать только недобросовестных майнеров, и если комьюнити пойдет на подобное изменение протокола, то наказывать, скорее всего, придется всех майнеров, а не только вредоносных.
Вариант 1: Отказ от включения в свои блоки запрещенных OFAC транзакций
В любом случае, как мы уже обозначили, конкретные варианты реализации цензуры со стороны стейкеров имеют множество нюансов. Вариант 1 выглядит довольно мягким. На наш взгляд, выбор такой опции крупным стейкером едва ли может привести к пользовательскому софтфорку или хардфорку сети. Единственным реальным следствием в этом случае будет небольшая потеря прибыли для цензора, которая может привести к сокращении доли рынка. Даже если бы такие цензоры контролировали 50% общего стейка, это могло бы означать, что тем, кто взаимодействует с Tornado Cash, пришлось бы подождать включения своей транзакции в блок 24 секунды вместо 12 (при условии достаточной высокой комиссии). Это не выглядит как серьезное неудобство.
В то же время создатели блоков вольны включать в них всё, что сочтут правильным, если это не нарушает правил сети. Значит, такое поведение стейкеров можно рассматривать как легитимное, а ответный UASF или хардфорк — как неоправданный и неэтичный. С нашей точки зрения, именно такой подход (вар. 1) выглядит наиболее вероятным в краткосрочной и среднесрочной перспективе. И это, конечно, не более чем предположение, но кажется, что Coinbase и Минфин США могли бы прийти к компромиссу на этот счет и остановиться именно на таком варианте. Хотя объяснить все эти нюансы регуляторам может быть очень непросто.
Вариант 2: Отказ от подтверждения блоков, содержащих запрещенные OFAC транзакции
Это гораздо более сложный сценарий, который может иметь множество последствий. Во-первых, есть аргумент, что этот вариант теоретически некорректен. Хотя технически можно говорить, что, подтверждая блок, вы выбираете только один блок, верхний. Если в этом блоке есть транзакции, запрещенные OFAC, вероятно, это можно трактовать как нарушение правил OFAC.
С другой стороны, процесс стейкинга на самом деле работает не так. Стейкер голосует за исходный блок, целевой блок и верхний блок, и в теории стейкер фактически подтверждает все транзакции в диапазоне от последнего финализированного блока до верхнего. Тот факт, что в подтверждении упоминается верхний блок, лишь формальность
Представим, что три блока назад произошло разделение цепочки. Тогда есть возможность для существования двух конкурирующих цепочек равной длины, и валидатору нужно выбрать одну из них посредством выбора между двумя верхними блоками в одном слоте. В этом сценарии, почему OFAC должны заботить транзакции только в верхнем блоке? Разве их не должны интересовать также транзакции от момента разделения цепочки до верхнего блока? Ведь именно такой выбор в действительности делает стейкер. Мы сомневаемся, что чиновники Минфина США сейчас готовы разбираться с этими запутанными нюансами. Однако это показывает, что вариант 2 в теории имеет изъяны.
В остальном, решение стейкера следовать варианту 2, на первый взгляд, может показаться мягким выбором, как и вар. 1. Это действие не связано с реорганизацией блокчейна, к тому же стейкеры вольны выбирать, какие блоки они подтверждают, — это их свободный выбор. Поэтому такая форма цензуры может рассматриваться как легитимная, а ответный UASF или хардфорк — как несправедливая или чрезмерная реакция, как и в случае с вариантом 1.
Однако, если допустить, что большинство блоков содержат запрещенные OFAC транзакции, то последствия второго варианта могут быть довольно серьезными. Валидаторы, практикующие такой подход к цензуре, будут редко участвовать в сети и получать нулевой доход. На самом деле им пришлось бы еще и платить штрафы за бездействие. Это сделало бы стейкинг совершенно бессмысленным. Зачем просто сидеть и получать штрафы, если можно просто уйти?
Следовательно, на наш взгляд, UASF или хардфорк не будут ни этичным, ни необходимым ответом на угрозу выбора опции 2 небольшим количеством валидаторов. Стоит также заметить, что даже до активации The Merge вы можете выйти из стейкинг-пула и тем самым избежать штрафов за бездействие. Вы только не можете вывести свой залог обратно на уровень исполнения. Такой вывод может стать доступен примерно через 12 месяцев после активации первого The Merge, после так называемого второго мёрджа.
Если же пулы цензурирующих валидаторов будут достаточно велики, то вся сеть может оказаться неспособна финализировать блоки и, по сути, перестанет функционировать. Крупные неактивные пулы могут получать всё большие и большие штрафы, увеличивающиеся с течением времени. Поэтому, опять же, выбирать вариант 2 практически бессмысленно, так как вместо этого валидаторы могут просто выйти из системы.
С другой стороны, если эти пулы будут большими и также участвовать в цензуре по варианту 1, то ситуация может развиваться несколько более смутно и непонятно. В этом случае блоки, соответствующие правилам OFAC, будут появляться время от времени, и цензурирующие пулы могут подтверждать некоторые блоки при появлении такой возможности, если цензор входит в правильный комитет. Трудно определить, каким будет результат в этом случае. Это негативно скажется на доходах пулов цензурирующих валидаторов, однако в какие-то периоды они всё же смогут зарабатывать. А результат здесь будет зависеть от процентного соотношения между цензурирующими и нецензурирующими пулами.
Даже если цензурирующие пулы составляют значительное большинство, неясно, действительно ли пользователи Tornado Cash при этом существенно проигрывают: возможно, им просто придется чуть дольше подождать первого подтверждения, но финализация после этого должна произойти в те же сроки, что и для остальных. Поэтому сама цензура при этом всё ещё может быть в значительной степени неэффективной. Возможно, также, что сеть будет медленнее финализировать блоки, и это может быть проблемой. Поэтому вполне вероятно, что в таком случае разработчики и комьюнити Ethereum решат провести UASF или хардфорк. Но на наш взгляд, изменение протокола здесь всё же маловероятно, и мы не уверены, что проведение UASF или хардфорка будет оправдано.
Можно попробовать рассчитать некоторые базовые вероятности. Если 50% от общего стейка практикуют цензуру по вариантам 1 и 2, то ситуация может быть следующей:
- 50% («хороших») стейкеров участвуют в подтверждении 100% блоков.
- 50% цензурирующих стейкеров участвуют в подтверждении 50% блоков, только соответствующих правилам OFAC.
- Средний уровень участия в системе при этом равен 75%.
Если 100% валидаторов цензурируют транзакции, то все блоки соответствуют правилам OFAC и все валидные блоки могут быть подтверждены. Если 0% валидаторов цензурируют транзакции, то все валидные блоки могут быть подтверждены. Сценарий распределения 50:50 дает, наверное, наихудший результат, с потенциальным уровнем участия 75%. То есть 75% — это самый низкий средний уровень участия в подтверждении, который можно получить в этом сценарии. Поскольку 75% — это больше, чем 66,7%, блокчейн должен оставаться в целом жизнеспособным и продолжать двигаться вперед. Хотя, конечно, в этих расчетах есть много допущений, а на практике идеально ничто не работает. Похоже, что в этих сценариях, независимо от процентного распределения, до тех пор, пока значительная часть валидаторов работает честно, цензура будет не особенно эффективной.
Теоретический средний показатель участия в подтверждении блоков
Примечания: предполагается, что всегда есть доступная для включения в блок транзакция, которую бы цензор отверг. Предполагается, что цензоры: 1) никогда не включают в свои блоки запрещенные транзакции и 2) никогда не подтверждают блоки с запрещенными транзакциями.
График выше показывает, что есть вероятность точки равновесия, в середине, где сеть продолжает работать при некоторой цензуре. Если доля цензурирующих валидаторов слишком мала — например, менее 25%, — то штраф за бездействие будет слишком высоким, и цензоры будут вынуждены уйти из сети. Тогда 100% оставшихся валидаторов будут честными. Помимо этого сценария, можно ожидать, что сеть могла бы какое-то время существовать при такой ограниченной цензуре. Теоретически могло бы и не быть необходимости кому-то что-то исправлять. Однако цензоры всё равно будут зарабатывать меньше и в какой-то момент могут покинуть сеть.
Есть и аргумент в пользу победы цензуры. Если в сети есть цензурирующие стейкеры — даже меньшинство, — то создатели блоков могут быть обеспокоены тем, что у их блоков будет меньше шансов попасть в выигрышную цепочку, если они будут содержать транзакции, запрещенные OFAC. Поэтому, по логике типа «побеждает наименее толерантный», чтобы обезопасить себя и свою работу, многие создатели блоков могут добровольно соблюдать санкции и ограничения OFAC. Тогда эти санкции могут быть в какой-то степени эффективными.
Всё вышесказанное показывает, что вариант 2 выглядит довольно запутанным и потенциально может приводить к широкому спектру плохо предсказуемых последствий. Хотя его логическая вариация, вариант 5 (отказ от подтверждения блоков в блокчейне, содержащем запрещенные OFAC транзакции может быть, с последнего финализированного блока), — возможно, более прост. В варианте 5 цензурирующие пулы никогда не подтверждают блоки, получают большие штрафы и у них не остается иного выбора, кроме как покинуть сеть. В проведении UASF или хардфорка при этом тоже, скорее всего, нет необходимости.
Вариант 3: Создание и подтверждение блоков, соответствующих правилам OFAC, даже если они конфликтуют с не соответствующими этим правилам блоками
Это более экстремальный вариант, который, по-видимому, будет воспринят значительной частью сообщества Ethereum как атака на сеть. Он может привести к реорганизации блокчейна. Однако «слешинга» при этом всё ещё можно избежать. Этот сценарий может привести к изменению протокола через UASF или хардфорк и потере залога для стейкинга атакующими пулами. Это также может привести к постоянному разделению блокчейна, особенно если кастодианы стейблкойнов выберут версию, соответствующую правилам OFAC. В подробности углубляться не будем.
Заключение
У нас нет намерения рассмотреть здесь все возможные варианты применения цензуры в Ethereum. Основная мысль, которую мы хотим донести, заключается в том, что сценарии применения цензуры в proof-of-stake сложнее, чем в proof-of-work. И в этом отношении сложность может сыграть для Ethereum как положительную, так и очень отрицательную роль.
Потенциальный положительный момент состоит в том, что регуляторы могут не понимать, какие действия следует предпринять, и потому предпринимать меньше регуляторных мер. Потенциальный негатив — в том, что вариант 2 потенциально может вызвать к жизни множество проблем, даже притом, что это довольно умеренный и не подразумевающий реорганизаций выбор, который трудно квалифицировать как атаку на сеть.
Надо также заметить, что эти формы цензуры, вероятно, потребуют создания новых программ-клиентов и большой технической работы. Насколько нам известно, пока эта работа не была проделана.
Что касается общего влияния этой потенциальной цензуры и регулирующих действий, вероятнее всего, результаты в среднесрочной перспективе будут следующими:
Процесс MEV-аукциона / Flashbots
BitMEX Research рассказывали о MEV-аукционах и Flashbots в этом майском отчете. В то время не было четкого понимания того, что произойдет с MEV-аукционом после The Merge. За последние несколько месяцев в этом направлении был достигнут значительный прогресс и создана инфраструктура.
Первое, что следует отметить, это то, что после активации The Merge в Ethereum появится различие между клиентом уровня исполнения (например, Geth) и клиентом уровня консенсуса (например, Prysm). На сегодня клиент уровня исполнения делает всё: обрабатывает все транзакции и смарт-контракты, а также решает, какой ветке блокчейна следовать.
После мёрджа пользователям будет нужно запускать два клиента для отслеживания и проверки блокчейна: клиент исполнения для обработки транзакций и клиент консенсуса для создания блоков и определения ветки блокчейна с наибольшим стейком. Поэтому в преддверии мёрджа именно клиент исполнения (Geth) был адаптирован для добавления функциональности Flashbot. После активации обновления, поскольку блоки создаются на уровне консенсуса, именно клиентам этого уровня будет нужно добавить функциональность Flashbot.
Насколько мы можем судить, все пять конкурирующих клиентов уровня консенсуса уже внедрили систему типа Flashbots в качестве стандартной функции, используя систему под названием MEV-Boost. Это немного отличается от того, что мы имеем перед мёрджем. Чтобы запустить Flashbots до мёрджа, майнерам нужно было загрузить специальную версию Geth, называемую MEV-Geth. Теперь, похоже, MEV-Boost включен в стандартную комплектацию.
Надо иметь в виду, что система MEV-аукциона имеет доверенный централизованный сервер ретрансляции, поэтому можно утверждать, что включение MEV-Boost в комплектацию по умолчанию может повысить централизацию. Однако URL сервера ретрансляции Flashbots, по-видимому, не добавлен в качестве стандартного в рассмотренные нами клиенты уровня консенсуса; его необходимо настраивать вручную. Но URL-адрес сервера Flashbots включен в руководства пользователей и просмотренные нами инструкции по настройке клиентов уровня консенсуса. Поэтому определение того, насколько большое увеличение централизации это даст, остается открытым вопросом.
Надо также отметить, что, насколько мы можем судить, Flashbots указали, что сервер ретрансляции уже соответствует требованиям OFAC и цензурирует транзакции. Семнадцатого августа, чтобы смягчить эту проблему, Flahsbots объявили об ускорении разработки сервера ретрансляции с открытым исходным кодом. Это должно означать, что больше людей смогут запускать свои серверы ретрансляции, а майнеры/стейкеры смогут вручную выбирать сервер по своему усмотрению. Поэтому, если один сервер цензурирует транзакции, то у пользователей есть возможность переключиться на другой.
Однако, как упоминалось в майском отчете BitMEX, вокруг сервера ретрансляции возникают значительные централизующие силы: 1) он сложен в управлении и требует значительных ресурсов и экспертизы и 2) оператору сервера приходится доверять в отношении отсутствия фронт-раннинга или иных нечестных действий с его стороны. Поэтому прийти к ситуации разнообразного, динамичного и большого выбора серверов ретрансляции может оказаться непростой задачей. В частности, это вряд ли может произойти до мёрджа.
Новая архитектура MEV-Boost
В новой инфраструктуре MEV-аукциона есть нечто намного худшее с точки зрения централизации и устойчивости к цензуре, даже более серьезное, чем проблема с сервером ретрансляции. В майском отчете BitMEX о Flashbots авторы писали:
Майнеры, участвующие в системе Flashbots, также могут включать в свои блоки любые транзакции, не относящиеся к Flashbot, которые они могут получать из общедоступного пула памяти транзакций. Майнеры, которые подписываются на получение транзакций через Flashbot, должны запускать специальную модифицированную версию Geth — MEV-Geth. На наш взгляд, очень важно, чтобы майнинговые узлы также подключались к «обычному» пулу памяти и по возможности добавляли в блоки и эти транзакции. Это главный контраргумент против тех, кто утверждает, что, поскольку система Flashbots централизована и широко распространена среди майнеров, у Ethereum есть единая точка отказа.
Насколько мы можем судить, для новой инфраструктуры этот аргумент больше нерелевантен. Добавить к транзакциям и бандлам из системы MEV-аукциона транзакции из мемпула стало невозможно. Создателям блоков нужно наполнять блок с помощью системы MEV-аукциона полностью. С нашей точки зрения, это серьезный недостаток, увеличивающий риск централизации. Мы не уверены, почему было принято такое решение, но это не выглядит как недостаток, по умолчанию присущий PoS. Возможно, MEV-Boost разрабатывается ускоренными темпами, и разработчики еще просто не успели реализовать эту функцию. Так что в будущем эта функция может быть добавлена, и проблема будет исправлена. Но, опять же, насколько мы можем судить, это вряд ли произойдет до мёрджа.
БитНовости отказываются от ответственности за любые инвестиционные рекомендации, которые могут содержаться в данной статье. Все высказанные суждения выражают исключительно личное мнения автора и респондентов. Любые действия, связанные с инвестициями и торговлей на крипторынках, сопряжены с риском потери инвестируемых средств. На основании предоставленных данных, вы принимаете инвестиционные решения взвешенно, ответственно и на свой страх и риск.
Подписывайтесь