EIP-7002: Лучший способ делать ставки на Ethereum

Переход Ethereum с Proof of Work (Pow) на Proof of Stake (PoS), также известный как The Merge, стал ключевым моментом в истории сети. Помимо предоставления Ethereum столь необходимого ребрендинга за счет сокращения его углеродного следа, Proof of Stake имел решающее значение для ключевой долгосрочной цели: снижения барьера для участия в консенсусе Ethereum. The Merge заменил вычислительные ресурсы (мощность майнинга) финансовым капиталом в качестве основы экономической безопасности Ethereum, открыв возможность для любого человека прибыльно и легко запустить узел валидатора, разместив 32 ETH на Beacon Chain.

Хотя Proof of Stake принес пользу, все еще есть много областей для улучшения. Вот некоторые из них:

• Сокращение централизации акций и картелизации валидаторов
• Минимизация операционных издержек для валидаторов и стимулирование индивидуального стейкинга
• Улучшение экономики ставок и пользовательского опыта (UX)
• Повышение простоты, безопасности и децентрализации делегированных и многосторонних операций по ставкам

EIP-7002: Execution Layer Triggerable Withdrawals — это новое предложение по улучшению Ethereum (EIP), которое устраняет некоторые из вышеупомянутых проблем. EIP вводит механизм для стейкеров для вывода валидаторов из Beacon Chain с использованием учетных данных вывода вместо того, чтобы полагаться на ключ подписи валидатора для запуска операций вывода — эффективно отделяя ключ подписи валидатора от ключа вывода.

Это «разделение задач» между ключами подписи валидатора и ключами вывода имеет решающее преимущество: снижение допущений доверия в делегированном стейкинге за счет включения учетных данных вывода для сохранения контроля над стейкингом ETH. Я рассмотрю, почему эта функция необходима в ходе этой статьи, и обсужу другие преимущества EIP-7002, особенно для стейкинга соло и стейкинга DVT (распределенная технология валидатора). В статье также будут рассмотрены некоторые потенциальные недостатки внедрения EIP-7002 на Ethereum.

Давайте начнем!

Подготовка к спектаклю: история о ключах, белых перчатках и горе(ях)

Если вы хотите сегодня сделать стейкинг ETH и подтвердить Beacon Chain, у вас есть два основных варианта: сольный стейкинг и делегированный стейкинг; есть и другие пути для стейкинга ETH, но эти более или менее быстрые выводы находятся в диапазоне между вышеупомянутыми вариантами. Индивидуальный стейкинг прост:

• Внесите 32 ETH в депозитный контракт Beacon Chain, чтобы активировать нового валидатора.
• Генерация ключей для выполнения обязанностей валидатора (проверка транзакций, подтверждение блоков, агрегация подтверждений и предложение блоков)
• Настройте узел валидатора и синхронизируйте клиент уровня выполнения (EL) и уровня консенсуса (CL)
• Поддерживайте работоспособность вашего валидатора в режиме онлайн, чтобы избежать штрафов

Есть еще шаги ( FAQ по валидатору на Staking Launchpad содержит отличный обзор для потенциальных валидаторов), но это примерно самые важные аспекты запуска валидатора. Важно то, что сольный стейкинг не требует посредника или контрагента и позволяет вам сохранять 100% вознаграждений, полученных от валидации (подтверждения блоков и предложения блоков) в Beacon Chain. Но это не бесплатный обед: вы несете ответственность за управление своим валидатором и вам потребуется определенный уровень технических знаний для запуска операции сольного стейкинга.

Если идея управления валидатором кажется сложной, вы можете пойти по пути делегированного стейкинга. Вы по-прежнему несете ответственность за предоставление 32 ETH для регистрации нового валидатора — только теперь вы делегируете ответственность за эксплуатацию валидатора третьей стороне. Оператор узла валидатора предоставляет то, что некоторые назвали бы «услугой в белых перчатках», и требует компенсации за эту услугу. Например, от вас может потребоваться разделить часть вознаграждений вашего валидатора с оператором узла в рамках первоначального соглашения.

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

Однако есть одно предостережение: делегированный стейкинг требует доверия к оператору узла, чтобы не подвергать ваши 32 ETH риску, совершая slashable правонарушение (например, подписывая два конфликтующих блока) или открыто крадя ваши средства. Это много, и определенно не для людей с проблемами доверия, но эта договоренность работает хорошо большую часть времени, когда операторы узлов честны.

Но Ethereum не был построен на основе этики web2 «доверься мне, братан», поэтому в разговорах на крипто-Twitter и Reddit часто встречаются выражения «не требующий доверия» и «не требующий доверия». Делегированный стейкинг в чистом виде противоречит этой этике, но есть обходной путь, основанный на способе генерации пар ключей в процессе активации нового валидатора.

У каждого валидатора есть два ключа: ключ вывода и ключ валидатора. Ключ вывода — это пара открытого и закрытого ключей, необходимая для частичного или полного вывода баланса валидатора Beacon Chain в зависимости от того, хотите ли вы «снять» (снять только вознаграждения) или «выйти» (снять 32 ETH-баланса + вознаграждения). Обратите внимание, что ключ вывода должен быть обновлен с учетных данных BLS по умолчанию ( 0x00 ) на учетные данные 0x01 , которые указывают на адрес Ethereum, чтобы обеспечить частичное или полное снятие баланса валидатора.

Ключ вывода генерируется во время внесения депозита через интерфейс, такой как Staking Launchpad , и хэшируется для создания идентификатора вывода, который включается в данные о депозите валидатора, что предоставляет Beacon Chain информацию о том, кто внес 32 ETH. Инфографика ниже от Protecting Withdrawal Keys by Attestant дает отличный обзор того, как ключ вывода интегрируется в процесс запроса депозита валидатора:

Ключ валидатора — это пара ключей «открытый-закрытый», необходимая для выполнения обязанностей, ожидаемых от каждого валидатора Ethereum, — в первую очередь, голосования за блоки и предложения блоков для голосования другими («голосование» и «подтверждение» используются взаимозаменяемо, но относятся к одной и той же концепции проверки транзакций и подтверждения действительности блоков). Открытый ключ валидатора служит его уникальной криптографической идентификацией в протоколе консенсуса Ethereum, в то время как закрытый ключ, как ожидается, будет скрыт и будет использоваться для подписи данных блока (ключи валидатора также описываются как ключи подписи по этой причине).

Теперь о главном различии между ключами валидатора (подписи) и ключами вывода:

Ключ подписи валидатора используется часто — подумайте каждые 6,5 минут или длительность интервала, в течение которого каждый валидатор будет выбран для подтверждения или предложения блока — и лучше всего хранить его в онлайн-месте с легким доступом, например, в горячем кошельке. Однако ключ вывода используется реже и может храниться в безопасном офлайн-месте, например, в холодном кошельке, пока стейкер не захочет вывести средства с адреса вывода, связанного с конкретным валидатором.

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

Соглашения о делегированном стейкинге, где стейкер держит ключ вывода, обычно описываются как «некастодиальные», чтобы отразить, что организация, управляющая узлом валидатора от имени стейкера, в конечном итоге не контролирует застейканные ETH. Это контрастирует с решениями по кастодиальному стейкингу, в которых служба стейкинга контролирует как ключи подписи, так и ключи вывода; «сервис белых перчаток на стероидах» является хорошей ментальной моделью для кастодиального стейкинга: стейкер просто предоставляет 32 ETH для финансирования валидатора и делегирует все остальное — включая инициирование запросов на депозит валидатора и хранение ключей вывода — службе стейкинга.

Разделение ключей подписи валидатора от ключей вывода теоретически решает проблему доверия в соглашениях о делегированном стейкинге. На практике отношения между оператором узла и стейкером в некастодиальной установке стейкинга все еще имеют элемент доверия из-за текущего механизма вывода валидатора и запуска полного или частичного вывода баланса валидатора на адрес вывода.

Чтобы вывести валидатора из Beacon Chain, необходимо отправить «Сообщение о добровольном выходе» (VEM), подписанное ключом валидатора, для обработки на уровне консенсуса. После включения в блок (каждый блок может включать максимум 16 операций запроса на вывод), сообщение о выводе добавляется в очередь запросов на вывод — с задержкой окончательного вывода, на которую влияют такие факторы, как количество выводов в очереди или скорость оттока валидатора.

Я подчеркнул необходимость подписывать добровольный запрос на вывод с помощью ключа подписи валидатора, чтобы подчеркнуть проблему с существующими «некастодиальными» решениями для стейкинга: стейкер должен полагаться на оператора узла, который контролирует ключ валидатора, необходимый для подписания VEM, для обработки запросов на вывод. Это фактически восстанавливает доверие в отношениях между операторами узлов и службами стейкинга; что еще хуже, это подвергает стейкеров риску быть «обиженными» злонамеренными операторами узлов.

При атаке грифинга цель злоумышленника — нанести убытки другой стороне, а не обязательно получить прямую выгоду. Чтобы поместить это в контекст, рассмотрим сценарий, в котором Алиса делегирует Бобу управление валидатором от ее имени, но решает позже снять свои 32 ETH. Боб может выполнить запрос Алисы и инициировать запрос на снятие, подписав сообщение о добровольном выходе (VEM)… или отказаться подписывать сообщение о запросе на снятие и остановить операцию Алисы по снятию. Боб не получит прямой выгоды от отклонения запроса Алисы — все, что он может сделать, это держать ETH Алисы «в заложниках», отказавшись помочь Алисе снять ее валидатор.

Ладно, это не на 100% точно; Боб может сделать много плохих вещей, чтобы причинить Алисе еще больше «горя»:

1. Уменьшить баланс валидатора Алисы, намеренно совершив сокращаемое нарушение или подвергнувшись штрафам. Индивидуальный штраф за невыполнение обязанностей валидатора (например, отсутствие подтверждений) или совершение сокращаемого нарушения (например, подписание двух конфликтующих блоков в одном слоте) обычно невелик, но увеличивается пропорционально количеству валидаторов, которые совершают аналогичные нарушения за тот же период. Например, отсутствие одного или двух подтверждений уменьшит баланс валидатора на небольшую долю, но это уменьшение увеличивается экспоненциально, если происходит утечка бездействия — когда несколько валидаторов находятся в автономном режиме.

   
   

В рамках текущего механизма злонамеренный Боб может уменьшить баланс валидатора Алисы в 32 ETH до 50 процентов, подвергаясь штрафам и сокращениям, пока валидатор не будет принудительно исключен из консенсуса Beacon Chain (после того, как его эффективный баланс упадет до 16 ETH). Если мы используем 1 ETH = 2000 долларов, то атака грифинга Боба обойдется Алисе как минимум в 32 000 долларов (16 ETH) в обычном случае (без коррелированных штрафов) и в 64 000 долларов (32 ETH) в худшем случае (т. е. когда весь баланс может быть сокращен из-за корреляционных штрафов).

Тот, кто может что-то разрушить, тот этим и управляет. — Пол Атрейдес (Дюна)

1. Потребовать выкуп от Алисы в обмен на несовершение слэшингового преступления. Это не совсем соответствует предыдущему определению грифинга, но учтите, что единственный выход Боба — сжечь ETH, если Алиса решит играть жестко. Таким образом, ситуация отличается от более распространенных типов атак, где целью (всегда) является прибыль с минимальными потерями.

Примечание: Боб (оператор узла) на самом деле может быть честен в этом сценарии, но злоумышленник может скомпрометировать ключ валидатора и взять ETH Алисы в заложники. Это объясняет «риск контрагента», который должны нести пользователи платформы стейкинга как услуги (SaaS), и является еще одной причиной, по которой сольный стейкинг — с его принципом «не доверяй никому, кроме себя» — считается золотым стандартом для стейкеров Ethereum.

Означает ли это, что каждая некастодиальная служба стейкинга на самом деле не является некастодиальной? Не совсем так. Простой обходной путь заключается в том, чтобы служба стейкинга заранее подписала сообщение о добровольном запросе на снятие средств — желательно после активации валидатора в Beacon Chain — которое стейкер может независимо отправить в узел консенсуса Ethereum, когда захочет снять средства.

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

Проблемы с предварительно подписанными запросами на вывод средств для некастодиального стейкинга

Сложность

Рабочие процессы предварительно подписанных запросов на вывод средств требуют большего общения между оператором службы ставок и делегатором ставок: вам нужно отправить запрос на сообщение запроса на вывод средств и дождаться, пока служба ставок отправит подписанные запросы на вывод средств. Также существует проблема безопасности при использовании и обмене предварительно подписанными запросами на вывод средств:

• Служба стейкинга должна принимать дополнительные меры предосторожности, например, шифровать сообщение с запросом на вывод средств и передавать его по защищенному (вне блокчейна) каналу связи, чтобы предотвратить попадание сообщений с запросом на вывод средств в чужие руки.
• Участнику стейкинга необходимо принять дополнительные меры предосторожности и сохранить сообщение с запросом на вывод средств в безопасном месте, поскольку потеря сообщения с запросом на вывод средств равносильна потенциальной потере возможности самостоятельно вывести баланс валидатора.

Кроме того, предварительно подписанные запросы на вывод средств в настоящее время действительны для двух форков Ethereum или ~12 месяцев — если вы ожидаете, что форки будут происходить примерно каждые шесть месяцев. Это означает, что стейкер должен повторно подать запрос на добровольный запрос на вывод средств оператору службы стейкинга несколько раз в течение календарного года. Однако это больше не будет иметь место, когда будет реализован EIP-7044 , и подписанные запросы на вывод средств валидатором станут действительными на неопределенный срок.

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

Но оператор узла валидатора не будет чувствовать себя комфортно, если предварительно подписанные запросы на вывод средств будут храниться на случайном сервере из-за риска того, что кто-то случайно/преднамеренно инициирует поддельные запросы на вывод средств, завладев подписанным сообщением о выходе. В худшем случае принудительные выходы, скорее всего, приведут к потерям для оператора узла валидатора (например, если вы взяли кредит под будущие вознаграждения Beacon Chain). Это означает, что пулы ставок должны принимать еще больше мер предосторожности и надежно хранить сообщения с запросами на вывод средств, особенно в мире после EIP 7044, где подписанные запросы на вывод средств имеют бесконечные сроки действия.

Потенциальным решением является шифрование подписанных запросов на снятие средств с помощью общего открытого ключа, сгенерированного с помощью протокола DKG (Distributed Key Generation) , и требование кворума общих ключей для восстановления закрытого ключа до того, как запрос на снятие средств может быть расшифрован. Это снижает допущение о доверии, которое возникает, когда одна сторона хранит запросы на снятие средств, при условии, что никто не контролирует достаточно общих ключей, чтобы в одностороннем порядке расшифровать предварительно подписанные запросы на снятие средств без участия других участников. Но возникает пограничный случай, если один или несколько общих ключей будут утеряны, утеряны или украдены, что затрудняет или делает совершенно невозможным расшифровку подписанного запроса на снятие средств, если возникает необходимость в инициировании снятия валидатором.

Соблюдение нормативных требований

Услуги по стейкингу подверглись пристальному вниманию со стороны множества регуляторов, в частности, Комиссии по ценным бумагам и биржам (SEC) во главе с врагом криптовалют № 1: Гэри Дженслером. Например, Kraken закрыла свою кастодиальную операцию по стейкингу как услуге в начале этого года и заплатила 30 миллионов долларов штрафа за «предложение незарегистрированных ценных бумаг через свою платформу стейкинга криптовалют».

Теоретически услуга по некастодиальному стейкингу вряд ли попадет под прицел SEC из-за некастодиального характера ее соглашения с владельцем доли:

1. Депозит в размере 32 ETH (или кратный 32 ETH) для активации валидатора поступает с адреса вывода, контролируемого стейкером, и протокол идентифицирует адрес вывода как владельца депозита в размере 32 ETH. Это означает, что некастодиальный стейкинговый сервис не может вывести баланс валидатора и «смешать деньги клиентов со своими», в чем Kraken обвиняла SEC.

На бирже типа Kraken баланс кошелька пользователя является «виртуальным», поскольку все средства клиентов хранятся в одном или нескольких кошельках, контролируемых биржей. Таким образом, если вы делаете ставку на 32 ETH через кастодиальный стейкинг-сервис, управляемый биржей, то на самом деле у вас есть долговая расписка от биржи, обещающая вернуть 32 ETH (плюс процент от вознаграждений валидаторов) всякий раз, когда вы захотите вывести средства.

1. Стейкеры могут самостоятельно выводить средства, отправляя предварительно подписанные выходы, не подвергаясь риску того, что мошеннический сервис стейкинга помешает выводу. Напротив, кастодиальный сервис стейкинга — особенно биржа вроде Kraken — контролирует активы стейкера и может блокировать вывод средств по произвольным причинам.

Эти два факта устраняют необходимость в «защите инвесторов»; я не эксперт по политике, поэтому прошу прощения за любые ошибки в этой цепочке рассуждений. Но все еще может быть небольшая загвоздка или две, если вы сегодня управляете институциональным, некастодиальным стейкинговым сервисом:

• В течение короткого (или, возможно, длительного) периода между активацией валидатора и отправкой предварительно подписанного добровольного выхода стейкеру, служба стейкинга контролирует 32 ETH, что делает ее «кастодиальной» в глазах регулятора. Еще больше усугубляют проблему короткие сроки действия предварительно подписанных выходов (pre-EIP 7044): между моментом подписания нового сообщения о выходе и отправкой стейкеру оператор узла валидатора имеет некоторый контроль над поставленным ETH.
• В то время как обычные сообщения о выходе транслируются в цепочке и могут быть публично проверены, предварительно подписанный выход должен быть зашифрован и передан вне цепочки в частном порядке между оператором узла и стейкером. Это затрудняет для третьей стороны, например регулятора, проверку того, что служба стейкинга действительно подписала намерение выйти как часть первоначального соглашения о депозите валидатора — или если обмен повторился после истечения срока действия исходного сообщения о выходе (т. е. до EIP 7004).

Вкратце: предварительно подписанные выходы смягчают некоторые проблемы с делегированным стейкингом, но их недостаточно, чтобы сделать стейкинг на Ethereum надежным, безопасным и децентрализованным. Чтобы вернуть «некастодиальный» стейкинг в некастодиальный, нам нужно лучшее решение, которое у нас теперь есть благодаря EIP-7002. В последующих разделах EIP-7002 будет подробно рассмотрен и затронуты различные преимущества EIP, а также потенциальные проблемы, связанные с его реализацией.

Обзор EIP-7002: снятие средств, инициируемое на уровне исполнения

EIP-7002 устраняет проблему принципала-агента в делегированном стейкинге, где стейкеры должны доверять операторам узлов валидатора предварительно подписывать запросы на снятие или выполнять будущие запросы на снятие, вводя новую добровольную операцию снятия, которая может быть запущена с помощью учетных данных снятия валидатора. Это позволяет стейкерам снимать застейканные ETH, не полагаясь на организацию, владеющую ключом подписи валидатора (т. е. службу стейкинга в настройке делегированного стейкинга), для обработки снятия.

Ключевой особенностью EIP-7002 является введение контракта запроса на снятие средств валидатора с сохранением состояния, который поддерживает очередь запросов на снятие средств валидатора, исходящих из уровня выполнения. С интервалами ряд запросов на снятие средств удаляется из очереди и добавляется в запрос на выполнение блока Beacon Chain. Это позволяет «вводить» запросы на снятие средств из уровня выполнения в уровень консенсуса и обрабатывать их как часть операций Beacon Chain — аналогично тому, как депозиты, исходящие из контракта на депозит, передаются из уровня выполнения в уровень консенсуса для обработки.

Запросы на вывод средств — это обычные транзакции Ethereum с адресом контракта валидатора в качестве цели, которые указывают на намерение отозвать валидатора (идентифицируемого по его открытому ключу). Сообщение о выводе средств валидатора является действительным, если (a) оно подписано адресом Ethereum, указанным в учетных данных вывода уровня выполнения валидатора ( 0x01 ), (b) валидатор, подлежащий выводу, активен в Beacon Chain. Эти проверки выполняются консенсусным уровнем после того, как запрос на вывод средств попадает в Beacon Chain; контракт запроса на вывод средств валидатора подтверждает только то, что транзакция запроса на вывод средств платит достаточно газа в момент вызова контракта запроса на вывод средств стейкером.

Все запросы на снятие средств на уровне исполнения обрабатываются так же, как и обычная операция добровольного запроса на снятие средств, инициированная с уровня консенсуса, что сохраняет инварианты вокруг максимально допустимых запросов на снятие средств из активных снятий валидатора. Механизм EIP-7002 в протоколе для передачи запросов на снятие средств между уровнями исполнения и консенсуса также устраняет необходимость в подключениях к консенсусному узлу для запуска запросов на снятие средств (что требуется для снятия валидаторов с предварительно подписанными запросами на снятие средств). Валидаторы теперь могут финансироваться и сниматься с одного и того же адреса уровня исполнения, что объясняет название EIP как «Снятия, инициируемые уровнем исполнения».

Увидев, как работает EIP-7002 на высоком уровне, теперь мы можем углубиться в более тонкие детали EIP. В следующем разделе будет рассмотрена текущая спецификация EIP-7002 и обсуждены ключевые аспекты механизма запроса на вывод средств валидатором. Если вы предпочитаете пропустить техническое обсуждение и изучить преимущества внедрения EIP-7002, вы можете перейти к следующему разделу, в котором освещаются некоторые улучшения пользовательского опыта (UX) стейкинга, которые обеспечивает EIP-7002.

Операции по запросу на снятие средств с валидатора

Согласно EIP-7002, запрос на снятие средств валидатором (определенный в псевдокоде как add_withdrawal_request() ) является CALL к адресу контракта запроса на снятие средств валидатором. Поле транзакции для вызовов контракта запроса на снятие средств валидатором имеет два значения:

• source_address : 20-байтовое значение, представляющее адрес вывода, который инициировал транзакцию.
• validator_pubkey : 48-байтовое значение, представляющее собой открытый ключ валидатора, из которого необходимо выйти.

После того, как стейкер вызывает контракт запроса на вывод средств с validator_pubkey в качестве входных данных, контракт запроса на вывод средств валидатора выполняет следующие операции (позже я рассмотрю ключевые части этой операции):

• Подтверждает, что транзакция оплачивает достаточно газа для покрытия EXIT_FEE
• Увеличивает счетчик выходов ( EXIT_COUNT ) на единицу для текущего блока
• Вставляет сообщение о выходе в очередь
• Увеличивает избыточные выводы для текущего блока ( EXCESS_EXITS ) на единицу
• Возврат средств звонящему, если он переплатил за бензин, путем пересылки компенсации в размере 2300 бензина ( EXCESS_RETURN_GAS_STIPEND )

Важная деталь: контракт запроса на вывод средств валидатора не проверяет, является ли source_address допустимым адресом вывода для валидатора, идентифицированного validator_pubkey , и не проверяет, является ли validator_pubkey . Это выявляет тонкую проблему безопасности, которая может возникнуть, если злоумышленник заполнит очередь сообщениями, которые обречены на провал; это в первую очередь атака с целью помешать обработке законных запросов на вывод средств. EIP-7002 решает эту проблему, взимая динамически корректируемую плату за транзакции запросов на вывод средств (механизм платы за вывод средств обсуждается позже).

Максимальный и целевой вывод средств за блок

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK

MAX_WITHDRAWAL_REQUESTS_PER_BLOCK — это количество запросов на вывод средств на уровне выполнения, которые могут быть включены в блок Beacon Chain. В настоящее время это значение установлено на 16, чтобы отразить аналогичные операции на Beacon Chain, такие как VoluntaryExit (операции выхода, запускаемые непосредственно из уровня консенсуса с помощью ключа валидатора стейкера).

В спецификации также отмечается, что установка MAX_WITHDRAWAL_REQUESTS_PER_BLOCK на 16 ограничивает размер полезных нагрузок выполнения и, соответственно, размер блоков Beacon Chain, а также снижает накладные расходы на обработку операций выхода на уровне консенсуса. Это полезно, поскольку можно ожидать, что некоторые участники продолжат выходить из валидаторов, используя текущий механизм запуска выходов из уровня консенсуса (т. е. через предварительно подписанные выходы или сообщения о добровольном выходе в реальном времени).

TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK

EIP-7002 теоретически позволяет включать в блок до 16 операций выхода на уровне выполнения, но нацелен на более консервативную оценку двух выходов на блок. Согласно спецификации , TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK был установлен на 2, чтобы ограничить скорость оттока валидаторов и сохранить инвариант максимально допустимых снятий за эпоху, определяемый функцией get_validator_churn_limit() Beacon Chain, даже в ситуациях, когда все ETH в обращении застейканы.

Очередь запросов на вывод средств валидатора

WITHDRAWAL_REQUEST_COUNT

WITHDRAWAL_REQUEST_COUNT — количество запросов на вывод средств, включенных в текущий блок. После каждого успешного вызова контракта запроса на вывод средств валидатора значение переменной WITHDRAWAL_REQUEST_COUNT , хранящейся в хранилище контракта валидатора, увеличивается на единицу (определено в псевдокоде как increment_count() ).

В любой момент времени значение WITHDRAWAL_REQUEST_COUNT будет находиться между TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK (2) и MAX_WITHDRAWAL_REQUESTS_PER_BLOCK (16) в зависимости от того, сколько операций запроса на вывод средств добавлено к полезной нагрузке выполнения блока. WITHDRAWAL_REQUEST_COUNT также является входными данными для функции, которая вычисляет сумму, подлежащую оплате новой операцией запроса на вывод средств ( MIN_WITHDRAWAL_REQUEST_FEE ).

ЗАПРОСЫ НА ИЗБЫТОЧНЫЙ ВЫВОД СРЕДСТВ

EXCESS_WITHDRAWAL_REQUESTS — это разница между MAX_WITHDRAWAL_REQUESTS_PER_BLOCK и TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK — количеством запросов на вывод средств, оставшихся неиспользованными текущим блоком. Как уже упоминалось, каждый блок может включать максимум 16 запросов на вывод средств, но в обычных ситуациях нацелен на два запроса на вывод средств, поэтому EXCESS_WITHDRAWAL_REQUESTS эквивалентно «разнице между тем, сколько запросов на вывод средств теоретически может потребить блок, и тем, сколько запросов на вывод средств фактически используется».

Счетчик превышения контракта запроса на вывод обновляется на основе использования последнего блока и является одним из факторов (среди прочих), определяющих комиссию, уплачиваемую транзакцией, которая вызывает контракт запроса на вывод валидатора. Это гарантирует, что комиссии за вывод оцениваются в соответствии с текущим использованием, что аналогично расчету EIP-1559 base_fee для нового блока, который рассчитывается на основе разницы между целевым лимитом газа и газом, использованным предыдущим блоком.

ОЧЕРЕДЬ_ЗАПРОСА_НА_ИСКЛЮЧЕНИЕ

WITHDRAWAL_REQUEST_QUEUE — это список всех ожидающих запросов на вывод средств (упорядоченных в порядке поступления), которые в настоящее время хранятся в WITHDRAWAL_REQUEST_QUEUE_STORAGE_SLOT контракта валидатора (как WITHDRAWAL_REQUEST_QUEUE_HEAD_STORAGE_SLOT и WITHDRAWAL_REQUEST_QUEUE_TAIL_STORAGE_SLOT ). Количество запросов на вывод средств в очереди может быть неограниченным, но переменная скорость MAX_WITHDRAWAL_REQUESTS_PER_BLOCK ограничивает количество ожидающих запросов на вывод средств, которые могут быть удалены из очереди в каждом блоке.

Очередь запросов на вывод средств поддерживает индексы «головы» и «хвоста» — оба просто ссылаются на набор запросов около начала и конца очереди — которые обновляются после каждого блока для учета обработки одного или нескольких запросов на вывод средств. Это очередь «первым пришел — первым вышел» (FIFO), поэтому запросы выполняются в соответствии с тем, когда они были добавлены в очередь — что имеет последствия для безопасности, особенно в отношении грифинга честных валидаторов.

Сборы за вывод средств валидатором

MIN_WITHDRAWAL_REQUEST_FEE — это сумма, которую адрес, вызывающий контракт запроса на вывод средств валидатора, должен заплатить в газе. Перед тем, как вставить запрос на вывод средств в очередь, контракт запроса на вывод средств валидатора проверяет, что комиссия за газ, прикрепленная к транзакции, равна или превышает текущее значение MIN_WITHDRAWAL_REQUEST_FEE — если после успешного выполнения транзакции у нее остался газ, на отправляющий адрес зачисляется ровно 2300 газа.

Согласно спецификации, эта конструкция следует ныне устаревшей функции в Solidity, где вызов функции fallback() в контракте назначения или отправка ETH через transfer() или send() пересылает стипендию в размере 2300 газа получателю. Изменения в стоимости газа (начиная с форка Berlin/Istanbul) снизили полезность этой функции (см. Stop Using Solidity's transfer() Now для некоторого контекста), но изначальная идея простой системы учета газа по-прежнему полезна. В контексте EIP-7002 отправка фиксированного возврата в размере 2300 газа упрощает механизм платы для контракта запроса на вывод средств валидатора.

Альтернативой является разработка специального механизма, который позволяет контракту запроса на вывод средств возвращать максимальное количество газа, оставшееся после транзакции. Это имело бы смысл, особенно в случаях, когда адресом вывода является EOA — смарт-контракты могут вычислять точные значения для MIN_WITHDRAWAL_REQUEST_FEE , проверяя состояние контракта, но EOA, скорее всего, будут отправлять больше газа для каждого вызова контракта запроса на вывод средств. Этот маршрут добавляет больше сложности к конструкции EIP-7002 по сравнению с использованием простого CALL для пересылки фиксированного количества газа в качестве возврата; хотя авторы EIP-7002 предполагают, что эта функция может быть включена в окончательную спецификацию в зависимости от отзывов заинтересованных сторон.

Расчет MIN_WITHDRAWAL_REQUEST_FEE — вот где все становится интересным. Комиссия за запрос на вывод средств является динамической и предназначена для реагирования на условия сети, аналогично базовой комиссии, введенной EIP-1559, и является функцией трех переменных:

• Минимальная (базовая) комиссия за вывод средств: MIN_WITHDRAWAL_REQUEST_FEE
• Количество избыточных снятий в текущем блоке: EXCESS_WITHDRAWAL_REQUESTS
• Формула обновления комиссии за запрос на вывод средств: WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION

Как и base_fee EIP-1559, комиссия за выход контракта на вывод средств валидатора является механизмом ограничения скорости: в среднем случае (два запроса на блок) любой, кто вызывает контракт запроса на вывод средств валидатора, может ожидать уплаты минимальной комиссии за вывод средств, но стоимость операции по выводу средств постепенно увеличивается по мере включения большего количества запросов на вывод средств в блок. Это можно вывести из формальной спецификации EIP-7002 для обновления комиссии за запрос на вывод средств : withdrawal_request_fee = MIN_WITHDRAWAL_REQUEST_FEE * e**(excess_withdrawal_requests / WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) .

Объяснение механизма взимания платы за запрос на вывод средств из спецификации:

«Поведение от блока к блоку примерно следующее: если блок N обрабатывает X запросов на вывод средств, то в конце блока N excess_withdrawal_requests увеличиваются на X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK , и поэтому комиссия за_вывод_запроса в блоке N + 1 увеличивается в e**((X - TARGET_WITHDRAWAL_REQUESTS_PER_BLOCK) / (WITHDRAWAL_REQUEST_FEE_UPDATE_FRACTION) раз. Следовательно, он имеет аналогичный эффект существующему EIP-1559, но более «стабилен» в том смысле, что он реагирует одинаково на одно и то же общее количество запросов на вывод средств независимо от того, как они распределены с течением времени».

Постепенно увеличивая плату за запрос на вывод средств в соответствии с использованием контракта запроса на вывод средств валидатора, EIP-7002 снижает риск того, что злоумышленник намеренно заполнит очередь запросов на вывод средств, чтобы помешать другим валидаторам выводить средства. Сообщения отзыва в очереди запросов на вывод средств выводятся из очереди и в стиле «первым пришел — первым ушел» (FiFo), в отличие, скажем, от «последним пришел — первым ушел» (LiFo) или порядка «сверхвыгодная транзакция — первой». Хотя мы можем предположить, что цены на газ предотвратят ненужные вызовы контракта запроса на вывод средств, злонамеренный злоумышленник может быть готов заплатить больше газа, чтобы «заполнить» очередь запросов на вывод средств и переместить запрос на вывод средств другого валидатора в конец очереди.

Проблема еще больше усугубляется централизацией построения блоков в Ethereum после Merge. Если злоумышленник интегрирован с одним или несколькими доминирующими строителями (для контекста: 80-90% блоков на сегодняшний день в Ethereum были созданы 4-5 строителями ) и готов платить за включение в топ-блок, он может эффективно опережать запросы на вывод средств от одного или нескольких стейкеров и предотвращать своевременный вывод средств валидаторами из Beacon Chain.

И зачем кому-то проходить через весь этот стресс? Возможной мотивацией может быть то, что злоумышленник хочет навредить стейкерам, которые хотят вывести валидаторы, используя учетные данные для вывода. Если использовать предыдущую версию Боба, оператора (вредоносного) узла, и Алисы, стейкера: Алиса может быстро вывести своего валидатора, чтобы остановить атаку Боба, вызвав контракт запроса на вывод валидатора с учетными данными для вывода, но Боб все еще может позволить себе больше, чтобы утечь баланс валидатора Алисы, спамя контракт запроса на вывод валидатора и задерживая запрос Алисы на вывод.

Структура блока и валидность

EIP-7002 немного изменяет структуру и проверку блоков Beacon, требуя, чтобы запросы на снятие средств были помещены в фактическое тело блока (и полезную нагрузку выполнения в уровень консенсуса). Запросы должны быть встроены в полезную нагрузку выполнения таким образом, чтобы всякий раз, когда уровень консенсуса недостижим, уровень консенсуса все еще имел необходимые данные для полного выполнения части консенсуса функции перехода состояния.

EIP-7002 также добавляет новые условия действительности для блоков. Во-первых, список запросов на снятие средств ( withdrawal_requests_list ) не может превышать MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Во-вторых, список запросов на снятие средств должен соответствовать количеству запросов на снятие средств, выведенных из очереди WITHDRAWAL_REQUEST_QUEUE , когда такие запросы упорядочены в порядке «первым пришел — первым вышел» (FiFO).

EIP-7002 имеет функцию ( expected_exit ) для подтверждения того, что блок не включает больше запросов на снятие, чем результат вычисления NUM_WITHDRAWAL_REQUESTS_IN_QUEUE - MAX_WITHDRAWAL_REQUESTS_PER_BLOCK . Кроме того, консенсусный узел, повторно выполняющий блок, будет независимо вычислять кодировку запросов на снятие, итерируя request_type и request_data по сравнению с обязательством хэша списка запросов на снятие.

Почему EIP-7002? Аргументы в пользу снятия средств, инициируемых на уровне исполнения

Снижение допущений о доверии при делегированном стейкинге

Во введении я отметил, как зависимость от ключа подписи валидатора для инициирования выходов валидатора привела к проблеме доверия; я не включил определение доверия, но это определение из статьи Виталика «Модели доверия» хорошо резюмирует это: «Доверие — это любое предположение(я), которое вы делаете относительно поведения других людей». Регистрируясь на услугу стейкинга, зная, что злонамеренный оператор узла может заморозить вывод средств, стейкер по сути доверяет оператору узла в том, что он будет действовать добросовестно.

EIP-7002 не полностью устраняет элемент доверия в делегированном стейкинге — вам все равно придется доверять оператору узла, чтобы он не выполнил атаку грифинга, — но предоставление стейкерам возможности вывода средств с использованием учетных данных вывода в некоторой степени снижает бремя доверия. Например, пользователю не нужно «верить», что оператор узла подпишет сообщение о добровольном выходе, как только он его запросит.

Тонкий момент в «недоверии» заключается в том, что речь идет не обязательно об избегании необходимости доверять, а о ненужности доверять, потому что (a) существуют сильные стимулы для всех сторон действовать честно (b) честные стороны имеют некоторую степень защиты от действий нечестных сторон. Возможность отозвать валидатор с помощью учетных данных для отзыва является примером последнего: Боб может попытаться огорчить Алису, но теперь у Алисы есть агентство, чтобы отозвать своего валидатора, надеюсь, до того, как Боб нанесет еще больше вреда.

Лучшее управление рисками для пулов ставок

В настоящее время пулы ставок не имеют возможности заставить оператора узла-валидатора выйти из игры, что ставит вкладчиков пула в неудобное положение, поскольку они доверяют операторам узлов, действуя честно. Некоторые децентрализованные пулы ставок требуют, чтобы операторы узлов предоставляли залог, но, учитывая возможность того, что злонамеренный оператор будет обрезан до 0 ETH, безопасность залога может быть недостаточной в глазах не склонного к риску стейкера.

При наличии EIP-7002 пулы ставок могут значительно снизить предположения о доверии, дополняя безопасность от угрозы сокращения залога оператора узла процедурами принудительного отзыва некорректно работающего оператора через отзыв на уровне исполнения. Возможность указания учетных данных для отзыва на адрес смарт-контракта (вместо EOA) также открывает новые конструкции реагирования на инциденты для пулов ставок — например, смарт-контракт может автоматически отправлять запрос на отзыв, если оператор подвергается штрафам выше среднего в течение определенного временного окна. Однако для этого требуется доверять оракулу для отслеживания производительности валидатора и сети хранителей для запуска смарт-контракта.

Другим гипотетическим преимуществом для пула ставок от внедрения EIP-7002 является устранение необходимости запрашивать и хранить предварительно подписанные сообщения о снятии средств, что сопряжено с рисками, как я уже объяснял ранее (например, несанкционированный доступ к сообщениям о снятии средств может привести к неожиданным снятиям валидатором). Это также способствует достижению цели проектирования пулов ставок без доверия: в отличие от использования предварительно подписанных запросов на снятие средств, хранящихся несколькими (доверенными) лицами, смарт-контракт, назначенный в качестве адреса снятия средств, может контролироваться управлением, что позволяет сообществу принимать решения об отзыве оператора узла публично и прозрачно.

Лучшее управление рисками для установок DVT

Технология распределенной валидации (DVT) считается важнейшей частью инфраструктуры стейкинга Ethereum по многим причинам:

• DVT снижает барьеры для индивидуального стейкинга: несколько индивидуальных стейкеров могут объединить средства для совместной активации валидатора без необходимости доверять каждой другой стороне. Схемы многосторонних вычислений (MPC) могут допускать до ⅓ неисправных узлов — поэтому, если гипотетический распределенный валидатор требует 3 из 5 общих ключей для восстановления ключа подписи валидатора, подписание может произойти, если два узла DVT находятся в автономном режиме.
• DVT повышает отказоустойчивость и устойчивость для институциональных/индивидуальных стейкинговых установок: как упоминалось выше, ключ подписи валидатора может быть разделен на разные общие ключи и реконструирован только тогда, когда требуются данные блока подписи. Это снижает риск того, что хакер скомпрометирует ключ подписи валидатора или стейкер потеряет доступ к средствам из-за повреждения устройства, на котором хранится ключ подписи.

Однако настройки DVT все еще несут определенный риск для стейкеров из-за того, как в настоящее время работают снятия и выходы в Beacon Chain. Если некоторые узлы DVT теряют общие ключи или отказываются участвовать в схеме пороговой подписи, выход из валидатора становится невозможным, особенно когда:

• Общие ключи для каждого участника в настройке DVT генерируются во время активации валидатора и не могут быть «обновлены» после первоначальной церемонии DKG (обратите внимание, что «участником» может быть просто другой EOA, принадлежащий тому же стейкеру); некоторые протоколы DVT позволяют генерировать новые общие ключи, хотя для этого может потребоваться, чтобы оставшиеся общие ключи соответствовали кворуму подписей, необходимому для обычного подписания.
• Порог кворума — количество ключей, необходимых для совместной генерации действительной подписи для распределенного валидатора — не может быть изменен после того, как (распределенный) валидатор активен.

Без EIP-7002, предоставляющего возможность отзыва валидатора с использованием ключа отзыва, преимущество запуска настройки DVT — независимо или совместно с другими валидаторами — было бы значительно уменьшено (например, баланс валидатора мог бы быть заблокирован навсегда). EIP-7002 предоставляет резервный вариант безопасности для распределенных валидаторов: если реконструкция ключа подписи невозможна, валидатор можно отозвать из цепочки Beacon, отправив запрос на отзыв, подписанный ключом отзыва, восстановленным из общих ключей.

Лучшее соблюдение нормативных требований: размещение «некастодиальных» активов в некастодиальных ставках

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

Я подчеркнул «любой момент времени», поскольку до EIP 7044 оператор узла временно берет на себя управление балансом валидатора после истечения срока действия предварительно подписанного выхода. И даже с постоянно действительными подписанными выходами EIP-7044 операторы узлов по-прежнему хранят 32 ETH, депонированных для валидатора, на короткий период между активацией валидатора и получением стейкером подписанного сообщения о выходе от оператора службы стейкинга. EIP-7002 устраняет эти неудобные области и гарантирует, что стейкеры имеют (доказуемое) хранение средств на протяжении всего жизненного цикла валидатора — от входа в Beacon Chain для вывода и отправки средств на адрес вывода стейкера.

Лучший пользовательский опыт (UX) для всех

Хорошая ментальная модель для EIP-7002 — думать о нем как о « абстракции учетной записи для инфраструктуры стейкинга». Для контекста, ключ валидатора (или ключ подписи) всегда является EOA и поставляется с тем же набором ограничений относительно безопасности и использования закрытого ключа, который влияет на обычные EOA Ethereum сегодня:

• Ключи валидатора (подписи) подвержены более высокому риску компрометации. В отличие от ключей вывода, хранящихся в холодном (офлайн) хранилище, ключи валидатора хранятся в горячих кошельках, подключенных к Интернету, что делает их уязвимыми для фишинговых атак. Если ключ подписи валидатора скомпрометирован, стейкеры и поставщики делегированного стейкинга подвержены векторам мошенничества, описанным во введении, без какого-либо запасного плана — помимо «подождать, пока баланс упадет до 16 ETH, и валидатор будет принудительно отозван протоколом».
• Ключи валидатора имеют ограниченные возможности для схем восстановления (потеряешь один раз = потеряешь навсегда). Разделение ключа валидатора на несколько общих ключей с помощью технологии распределенного валидатора (DVT) может снизить этот риск, но запуск индивидуальной настройки стекинга DVT нетривиален; плюс, как я уже объяснял ранее, DVT не является панацеей, поскольку общие ключи могут быть утеряны, что усложнит обновление общих ключей.
• Ключи валидатора не могут поддерживать более гибкие конструкции ставок. Различные службы ставок развили автоматизированные/гибкие рабочие процессы для финансирования валидаторов из-за преимущества указания учетных данных снятия на смарт-контракты. Однако снятие валидатора является ручным процессом, который требует подписания сообщения о добровольном запросе на снятие — этот процесс может быть автоматизирован смарт-контрактом, который хранит запросы на снятие до подписи, но это связано с определенными предположениями о доверии и соображениями безопасности, которые были объяснены ранее.

Мы можем решить большинство — или, по крайней мере, некоторые — из этих проблем, как только ключи вывода смогут выходить из валидаторов. Чтобы это сработало, стейкеру (или пулу ставок) необходимо будет выполнить одноразовое изменение с учетных данных вывода 0x0 на учетные данные вывода 0x01 — в то время как учетные данные 0x0 являются ключом BLS (EOA) по умолчанию, учетные данные 0x01 могут указывать на любой адрес Ethereum, включая смарт-контракты и EOA. Установка смарт-контракта в качестве адреса вывода для валидатора отлично подходит для улучшения пользовательского опыта (UX) стекинга:

1. Ключи вывода могут иметь гибкие механизмы восстановления, такие как социальное восстановление. У стейкера будет один или несколько «опекунов», которые могут авторизовать новый ключ для управления смарт-контрактом запроса на вывод, если исходный ключ украден или утерян — опекунами могут быть друзья, родственники, коллеги-стейкеры или специализированная сторонняя служба. Гибкость в механизмах восстановления может особенно принести пользу соло-стейкерам; у вас может быть переключатель мертвеца , который активирует выход EL и отправляет средства на указанный адрес, если ваш валидатор прекращает проверку на заранее определенный период (например, потому что вы «перешли в Великий Запределье»).

2. Могут возникнуть гибкие схемы стейкинга. Например, стейкер, не склонный к риску, может предпочесть контракт на вывод средств с мультиподписью 2-из-2 — с стейкером и оператором узла, владеющими одним из двух ключей, необходимых для одобрения запросов на вывод средств — вместо того, чтобы хранить весь ключ вывода. Он по-прежнему некастодиальный (оператор узла не может выйти из валидатора без одобрения), хотя и требует доверия к оператору узла, чтобы он не блокировал выход валидатора, отказываясь подписывать транзакции запросов на вывод средств, предложенные стейкером.

Для пулов ставок гибкость в дизайне ставок может означать реализацию контрактов на снятие средств с произвольной логикой для обновления или передачи права собственности на валидаторы. При отсутствии EIP-7002 единственный реальный способ, которым пул ставок может управлять правом собственности на валидаторы, — это перемещать предварительно подписанные запросы на снятие средств, что сопряжено с различными рисками и пограничными случаями.

3. Вывод средств валидаторами может быть безопасно автоматизирован. В отличие от хранения предварительно подписанных запросов на вывод средств в смарт-контракте, контракты на вывод средств могут иметь сложные правила, регулирующие запросы на вывод средств валидаторами; идея «безумной науки» — это «пул ставок на основе времени», где операторы узлов безнадежно меняются. Или подумайте, хочет ли крупный пул ставок, такой как Lido, децентрализоваться: управление может принять решение об отзыве некоторых валидаторов, контролируемых крупным оператором узла, и перераспределить средства среди более мелких операторов (или индивидуальных стейкеров), чтобы сократить количество узких мест у оператора узла, контролирующего значительное количество валидаторов.

Это лишь некоторые из ранних возможностей, которые открывает EIP-7002, но я уверен, что появятся и другие приложения — точно так же, как продолжают появляться новые функции и варианты использования для смарт-кошельков на Ethereum. Если вы читаете это и у вас есть более конкретные идеи по применению EIP-7002 в проектах стейкинга, не стесняйтесь давать комментарии!

Есть ли какие-либо недостатки при внедрении EIP-7002?

Потенциальные критические изменения в существующих конструкциях стоек

В проекте EIP авторы EIP-7002 признают потенциальные опасения относительно включения учетных данных снятия для запуска снятия валидатором, но продолжают говорить: «мы не знаем ни об одной схеме стейкинга, которая опирается на эту функцию [т. е. невозможность снятия с учетными данными снятия]». Это кажется разумным — даже мне было трудно рассуждать о какой-либо схеме делегированного стейкинга, которая потребовала бы этой функции. Но то, что это не кажется очевидным, не означает, что этого нет.

«Прислушайтесь к этим тихим, терзающим сомнениям. Если вы не знаете, вы не знаете, чего вы не знаете, вы не знаете, как много вы не знаете, и вы не знаете, как много вам нужно было знать». — Элиезер Юдковски

Чтобы предоставить некоторый контекст, я включу скриншоты разговора вокруг раннего предложения по внедрению выходов, одобренных учетными данными снятия, через обобщенную шину сообщений (GMB) . GMB — это системный смарт-контракт, события которого считываются и обрабатываются клиентами, как и текущий депозитный контракт, и который способен передавать сообщения из уровня исполнения в уровень консенсуса. Хотя автор(ы) намекали на более общие типы сообщений EL-to-CL, основным предлагаемым вариантом использования шины сообщений EL-to-CL было предоставление способа инициировать выходы из уровня исполнения с помощью учетных данных снятия 0x01.

Из этого обмена мы уже имеем пример отношений стейкер-оператор узла, построенных на предположении, что стейкер не может выйти и вывести валидатор с помощью ключа вывода. Другой пример потенциального пограничного случая внедрения EIP-7002 исходит из разговора о планах децентрализации Lido в подкасте Lido Community Staking, который вы можете посмотреть на YouTube . (EIP-7002 упоминается только кратко (с 28:55 до 30:00) в видео).

Для справки: Lido описывается как «систематическая угроза для Ethereum», поскольку он контролирует около 33,3% валидаторов Beacon Chain и может поставить под угрозу консенсус Ethereum; например, если Lido DAO заставит операторов узлов цензурировать транзакции или отменять ранее финализированные блоки (в статье Майка Нойдера «Масштабы и направления векторов атак Lido» эта угроза описана более подробно).

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

С EIP-7002 динамика власти существенно меняется: контракты на отзыв, регулируемые DAO, могут отзывать оператора против его желаний, давая DAO рычаги воздействия на операторов узлов. Этот тип рычагов полезен для защиты протокола стейкинга от вредоносного набора операторов, как я уже объяснял ранее. Но его также можно использовать не по назначению в следующих сценариях:

• Протокол стейкинга подвергается атаке на управление, и DAO принимает вредоносное предложение, чтобы инициировать выход валидатора из контракта на вывод
• Злоумышленник захватывает контроль над одним или несколькими валидаторами, перехватывая право собственности на контракт запроса на вывод средств, и реализует успешную стратегию шантажа.

Это еще один пример того, как EIP-7002 может изменить существующие предположения в дизайнах стекинга — на этот раз для операторов узлов, проверяющих от имени пула стекинга, такого как Lido. Тем не менее, этот вектор атаки можно легко смягчить с помощью различных методов, таких как использование безопасных, строго проверенных и, возможно, необновляемых контрактов на запрос на снятие средств или следование передовым практикам для безопасного управления DAO .

Чтобы учесть пограничный случай, когда оператор узла терпит убытки из-за принудительного вывода средств после отказа злоумышленнику нарушить правила протокола, пулы ставок могут позаимствовать опыт компаний, занимающихся недвижимостью, для защиты операторов узлов:

• Перед подписанием договора аренды арендаторы обязаны внести «залоговый депозит». Депозит хранится на банковском счете, находящемся вне контроля компании, занимающейся недвижимостью.
• Если арендатор съезжает из квартиры, но оставляет после себя значительный ущерб, риэлторская компания имеет право использовать залог для покрытия расходов на ремонт.
• Если на момент выезда арендатора квартира находится в хорошем состоянии, залог возвращается арендатору в полном объеме.

Протокол стейкинга может использовать аналогичный подход к защите операторов узлов, оформляя полис «страхового фонда оператора узла» через Nexus Mutual , Tidal Finance или любую другую крипто-нативную страховую платформу. Если валидатор оператора отзывается законно, страховой фонд возвращается в DAO; если верно обратное (например, отзыв валидатора вызван вредоносным предложением или ошибкой контракта отзыва), страховой полис выплачивает убытки оператору узла. Обратите внимание, что этот подход можно обобщить на любые существующие отношения, которые полагаются на текущие спецификации для выхода из валидатора.

Отсутствие поддержки более сложных сообщений EL-to-CL

Контракт запроса на снятие валидатора EIP-7002 предоставляет одну функциональность: отправка запроса на снятие с уровня исполнения Ethereum на уровень консенсуса для снятия валидатора. Однако некоторые предложили реализовать общую структуру обмена сообщениями (например, предварительную компиляцию SendMessageToConsensusLayer или контракт системного уровня Generalized Message Bus (GMB), упомянутый ранее) для передачи общих типов сообщений между уровнем исполнения и уровнем консенсуса. Это может иметь такие преимущества, как разблокировка новых способов активации валидаторов в Beacon Chain, особенно если разрешено присоединение ETH к сообщениям EL-to-CL.

Однако, как объясняет Дэнни Райан (один из авторов EIP-7002) в комментарии , трата ценного инженерного времени на общую структуру обмена сообщениями EL → CL является «крупным начинанием с неясным ценностным предложением». Для иллюстрации, авторы предложения GMB (General Message Bus) определили только один другой вариант использования шины сообщений между EL и CL: ротация учетных данных снятия для валидатора с учетных данных 0x0 на учетные данные 0x01 .

Это означает, что мы, скорее всего, увидим контракт запроса отзыва валидатора, прежде чем основные разработчики заговорят о внедрении общей шины сообщений EL-CL, если это когда-либо произойдет. Не то чтобы сохранение простоты когда-либо вредило.

Простота — необходимое условие надежности. — Эдсгер В. Дейкстра

Новые векторы риска для существующих участников

Я подробно рассказал о преимуществах включения учетных данных для снятия средств для запуска снятия средств по большей части, но есть некоторые пограничные случаи, связанные с этой функцией. Идея выглядит так (h/t к этому комментарию на GitHub ):

• Если ключ подписи валидатора скомпрометирован, хакер может потребовать выкуп или попытаться уменьшить баланс валидатора, но он не сможет вывести средства ни при каком сценарии. Начнется игра ожидания: уничтожит ли злоумышленник весь баланс или стейкер сможет вывести часть ставки после того, как валидатор будет принудительно выведен?
• Однако после внедрения EIP-7002 хакер из предыдущего сценария может выйти из валидатора и снять баланс (после внедрения EIP-7002) вместо того, чтобы довольствоваться атакой с целью обмана/шантажа.

Короче говоря, индивидуальным стейкерам и сервисам стекинга потребуется более надежная защита учетных данных для вывода средств после EIP 7002. Вот почему принятие социального восстановления, многофакторной аутентификации (MFA) и ротации ключей считается критически важным для повышения безопасности индивидуальных/делегированных операций стекинга.

Выбор механизма ограничения скорости

Функциональность контракта запроса на вывод средств валидатора add_withdrawal_request() не выполняет никаких дополнительных проверок, кроме проверки прикрепленной платы за запрос на вывод средств, что потенциально позволяет злоумышленнику засорить очередь сообщений недействительными запросами на вывод средств (например, сообщения о выходе для несуществующего валидатора или неактивного валидатора будут признаны недействительными во время проверок действительности на уровне консенсуса). EIP-7002 использует динамически оцениваемую плату за вывод средств для ограничения частоты запросов на вывод средств и делает такие атаки дорогостоящими, подобно тому, как EIP-1559 препятствует спам-атакам и блокирует стаффинг, корректируя цены на газ в зависимости от сетевой активности.

Альтернативный дизайн заключается в ограничении вызовов контракта запроса на вывод средств валидатором фактическими валидаторами, например, путем проверки того, что validator_pubkey соответствует открытому ключу активного валидатора Beacon Chain. Это может упростить дизайн EIP-7002, устранив необходимость в сложном механизме ценообразования в стиле EIP-1559 и, потенциально, снизить плату за запрос на вывод средств, поскольку спам в очереди поддельными запросами может быть менее серьезной проблемой.

Однако для этого требуется, чтобы уровень выполнения мог получить доступ к информации о консенсусном уровне без доверия — для проверки validator_pubkey по реестру валидаторов Beacon Chain — функция, которая зависит от реализации EIP-4788. Это добавляет больше сложности EIP-7002 и вводит новую зависимость между двумя EIP, что может иметь последствия для будущих улучшений дизайна, как отмечено в этом разделе обоснования EIP-7002 .

Даже если EIP-4788 был интегрирован с EIP-7002, нам все равно понадобятся дополнительные механизмы для предотвращения других форм спама, которые включают законных валидаторов; примером является отправка нескольких запросов на снятие средств для одного и того же валидатора за очень короткий период. Это, в свою очередь, требует добавления (и применения) нового правила, например, «вы можете отправить только один запрос на снятие средств на одного валидатора каждые 3-4 месяца», что может потребовать еще больших изменений в контракте запроса на снятие средств валидатора.

Напротив, текущий механизм ограничения скорости прост в обосновании и гарантирует достаточную защиту от большинства проблем безопасности, связанных с выводами на уровне выполнения. Например, комиссия за запрос на вывод может автоматически корректироваться в сторону увеличения, чтобы предотвратить грифинг (попытки помешать честным валидаторам выводить средства), спам и атаки DOS (попытки перегрузить Beacon Chain, заставив консенсусные узлы тратить ресурсы на фильтрацию недействительных операций по выводу средств).

Заключение: EIP-7002 и будущее стейкинга на Ethereum

Делегированный стейкинг подвергся серьезной критике в последние месяцы, но можно с уверенностью предположить, что индустрия стейкинга как услуги останется. Если это так, то снижение риска для лиц, делегирующих стейкинг — будь то ликвидный стейкинг-пул или институциональная некастодиальная служба стейкинга — важно. EIP-7002 достигает этой цели, делая учетные данные для снятия 0x01 способными выходить из валидаторов и снимать стейкинг, а также уменьшая необходимость для стейкеров доверять честности оператора узла.

EIP-7002 также имеет другие положительные побочные эффекты. В частности, повышение устойчивости и безопасности операций индивидуального стейкинга и распределенных валидаторов — путем обеспечения лучшего восстановления после потери ключа валидатора или общих ключей DVT — должно снизить барьер для индивидуального стейкинга и уменьшить централизацию стейкинга на Ethereum.

Как обычно, я закончу просьбой к вам поделиться этой статьей с тем, кто может найти ее информативной, и, что еще важнее, подписаться на Ethereum 2077 для более глубокого погружения во все, что касается исследований и разработок Ethereum. Вы также можете связаться со мной в Twitter, чтобы поделиться комментариями или отзывами по этой статье.