В нашей предыдущей статье мы подробно рассмотрели жизненный цикл проверяющего Ethereum, обсудили несколько аспектов, связанных с предстоящим жестким разделением Electra. Теперь пришло время обратить внимание на изменения в предстоящих обновлениях Electra и Prague и подробно их объяснить.
История жесткого разделения Ethereum 2.0 «Proof of Stake» (PoS) сложна. Она началась с добавления маркерного уровня к существующему уровню исполнения, в то время как на маркерном уровне запускалось согласование PoS, уровень исполнения всё ещё поддерживал рабочее согласование (жесткое разделение Phase0 и Altair). Затем, в жестком разделении Bellatrix, PoS было полностью активировано (хотя вывод ещё не был включен). Затем в жестком разделении Capella был разрешен вывод, завершая жизненный цикл проверяющего. Последнее жесткое разделение Deneb (часть обновления Dencun (Deneb/Cancun)) незначительно изменяет параметры маркерной цепи, такие как временное окно подтверждения, обработка добровольного выхода и ограничение на замену проверяющего. Основные изменения в Dencun происходят на уровне исполнения, вводятся blob-транзакции, blob gas, KZG обязательства для blob и отменяется операция SELFDESTRUCT.
В настоящее время хардфорк Prague/Electra (т.е. Pectra) внес важные изменения в исполнение и консенсусный уровень. В качестве аудиторов проекта Lido мы в основном обращаем внимание на изменения в консенсусе и стейкинге в этом хардфорке. Однако мы не можем игнорировать изменения в исполнении в Prague, поскольку они включают важные особенности, влияющие на сеть Ethereum и валидаторов. Давайте подробнее рассмотрим эти изменения.
Общий обзор Pectra
Electra внесла множество функций в свой маяк. Основные обновления включают:
Разрешается изменение действительного остатка участника проверки между 32 и 2048 ETH (вместо фиксированных 32 ETH).
Валидаторы могут инициировать выход через вторичный «снятие» ведомости (не требуется ключ активного валидатора).
Изменен способ обработки депозитов Eth1 на уровне маяка (больше не разбирается событие из депозитного контракта).
Добавлена новая общая структура для обработки запросов от обычных Eth1 контрактов на уровне маяка (аналогично управлению предварительными депозитами Electra).
В то же время Прага внесла следующие изменения в исполнительный состав:
Новый предварительно скомпилированный контракт, поддерживающий кривую BLS12-381 для проверки доказательств zkSNARK (в дополнение к популярной кривой BN254).
Новый системный контракт для хранения и доступа к 8192 историческим хешам блоков (очень полезно для клиентов без сохранения состояния).
Увеличение затрат на calldata gas для уменьшения размера блока и поощрения проектов перенести calldata-интенсивные операции (например, rollup) во введенные в Dencun блобы.
Поддержка большего количества блобов в каждом блоке Eth1 с предоставлением API для чтения этого количества.
EOA (внешний аккаунт) может иметь свой собственный код аккаунта, что существенно расширяет возможности EOA для выполнения операций, таких как множественные вызовы или делегирование выполнения другому адресу.
Давайте обратимся к соответствующему улучшению Ethereum (EIP), чтобы продолжить обсуждение:
EIP-7251: Увеличено максимальное значение _EFFECTIVE _BALANCE
EIP-7002: Выход, который может быть вызван исполнительным слоем
EIP-6110: Предоставление депозита проверяющего лица на цепи
EIP-7549: удаление комиссии из индекса подтверждения
EIP-7685: Общий уровень исполнения запроса
EIP-2537: Предварительная компиляция операций на кривой BLS12-381
EIP-2935: Сохранение исторического хеша блока в состоянии
EIP-7623: Увеличение стоимости calldata
EIP-7691: увеличение пропускной способности блобов
EIP-7840: добавление расписания blob в файл конфигурации EL
EIP-7702: Настройка кода учетной записи EOA
Некоторые из этих EIP относятся к слою консенсуса (бэйсбин), в то время как другие связаны с исполнительным слоем. Некоторые пересекают оба слоя, поскольку некоторые операции (например, депозиты и снятие средств) требуют синхронных изменений между консенсусом и исполнительным слоем. Из-за этой взаимозависимости разделение Electra и Prague является неосуществимым, поэтому мы последовательно рассмотрим каждый EIP и определим затронутые компоненты Ethereum в каждом случае.
EIP-7251: увеличен MAX_EFFECTIVE_BALANCE
Ссылка: EIP-7251
С момента первого жесткого разделения фазы 0, для подготовки к доказательству доли Ethereum, до Electra, максимальный действительный баланс проверяющего был зафиксирован на уровне 32 ETH. Активация проверяющего требует как минимум spec.min_activation_balance (32 ETH). После активации проверяющий начинает с этого максимального действительного баланса, но может уменьшить его до spec.ejection_balance (16 ETH) и быть изгнанным, когда достигнет этого порога. Эта «минимальная» логика остается неизменной в Electra, но теперь spec.max_effective_balance увеличен до 2048 ETH. Таким образом, проверяющий может внести депозит от 32 до 2048 ETH для активации, и все эти суммы будут вносить вклад в его действительный баланс. Этот переход означает переход от «32ETH-доказательства доли» к «доказательству доли» :)
Этот изменяющийся доступный остаток будет использоваться для:
Увеличение вероятности стать предложителем блока пропорционально действительному остатку
Увеличение вероятности стать членом комитета синхронизации пропорционально остатку по счету
В качестве основы для расчета относительного сокращения и неактивной суммы штрафа
Первые два мероприятия - это наиболее выгодные действия для валидаторов. Следовательно, после Electra валидаторы с высокими ставками будут чаще участвовать в предложении блоков и комитете синхронизации, их частота будет пропорциональна их действительному остатку.
Еще одно влияние связано с сокращением. Все штрафы за сокращение пропорциональны действительному остатку средств проверяющего.
Уменьшение штрафов для мгновенного и отсроченного зачисления имеет больший эффект на высоко ставящих свои ставки валидаторов.
Существует также больший штраф за «задержку» сокращения узловых операторов с высокими ставками залога, потому что доля «сокращенных» в общем объеме залога становится больше.
Жалобщику, который докладывает о высоком остатке средств у проверяющего, начисляется большая доля урезанного залога.
Electra также предлагает изменение коэффициента сокращения, определяет часть остатка баланса сокращенного валидатора и передает его донесителю.
Далее идет влияние недействительности. Когда проверяющий находится в активном состоянии (доказательство или предложение), но офлайн, балл недействительности накапливается, что приводит к наложению наказания за недействительность на каждый период. Эти наказания также пропорциональны балансу проверяющего.
В связи со значительным увеличением доступного баланса изменяется также «ограничение замены» для валидаторов. В старой версии Ethereum до Electra валидаторы обычно имеют одинаковый доступный баланс, а ограничение замены определяется как «в течение одного периода можно выйти только с общей ставкой, которая не превышает 1/65536 (spec.churn_limit_quotient)». Это приводит к «фиксированному» количеству выходящих валидаторов с одинаковой ставкой. Однако после Electra возможно, что только небольшое количество «китов» будет выходить, так как они представляют собой значительную часть общей ставки.
Еще одним соображением является переключение многих ключей проверяющего на одном экземпляре проверяющего. В настоящее время крупные проверяющие вынуждены запускать тысячи ключей проверяющего на одном экземпляре, чтобы удовлетворить большой депозит, который разбивается на 32 ETH части. С Electra такое поведение не является обязательным. С финансовой точки зрения это изменение не оказывает большого влияния, поскольку вознаграждение и вероятность линейно масштабируются с суммой депозита. Таким образом, 100 проверяющих по 32 ETH эквивалентны одному проверяющему по 3200 ETH. Кроме того, несколько активных ключей проверяющего могут иметь один и тот же ETH1-чек, что позволяет извлекать все вознаграждения на один адрес ETH и избежать связанных с объединением вознаграждений затрат на газ. Однако управление большим количеством ключей приводит к дополнительным затратам на управление.
Способность к агрегации баланса проверяющего увеличена новым типом запроса исполнительного уровня. Ранее у нас были депозиты и снятия. Теперь появится еще один тип: агрегированный запрос. Он объединяет двух проверяющих в одного. Запрос на операцию будет включать открытый ключ исходного проверяющего и целевой ключ и будет обрабатываться аналогично депозитам и снятиям. Агрегация также будет иметь ограничения на ожидающие запросы и замену баланса, как и депозиты и снятия.
Подводя итог, следует отметить:
Для небольших независимых проверяющих Electra предлагает возможность автоматического увеличения их действительного баланса (и вознаграждения). Ранее любая прибыль свыше 32 ETH могла быть выведена, но с появлением Electra эта прибыль в конечном итоге будет добавлена к их действительному балансу. Однако действительный баланс может увеличиваться только кратно spec.effective_balance_increment (1 ETH), что означает, что увеличение происходит только после достижения следующего «порога 1 ETH».
Для крупных независимых валидаторов Electra предоставляет значительное упрощение управления, позволяя объединить несколько активных ключей валидатора в один. Хотя это не изменит правила игры, вести ставку 1x2048 безусловно намного проще, чем управлять 64x32 ставками.
Для поставщиков ликвидности, собирающих небольшие залоги от пользователей и распределяющих их между валидаторами, Electra добавляет больше гибкости в схему распределения залогов, но это также требует серьезной перестройки учета валидаторов на основе фиксированного остатка в 32 ETH.
Ещё одной важной темой являются исторические данные и оценка прибыли для валидаторов, особенно актуально для новых участников, которые пытаются оценить риски и вознаграждение. До появления Electra (на момент написания настоящей статьи) ограничение в 32 ETH (фактически, независимо от того, является ли это минимальным или максимальным значением) создавало однородность в исторических данных. Все валидаторы имели одинаковый остаток, награду, индивидуальные штрафы за уменьшение, частоту предложения блока и другие показатели. Эта однородность позволила Ethereum тестировать свой механизм согласия без статистических выбросов, собирая ценные данные о поведении сети.
После Electra произойдут значительные изменения в распределении ставок. Участие крупных валидаторов в блок-предложениях и комитете синхронизации будет более частым, они будут сталкиваться с более строгим наказанием в случае сокращения, а также будут оказывать большее влияние на очередь активации и очередь выхода. Хотя это может представлять вызовы для агрегации данных, консенсус Ethereum гарантирует, что нелинейные вычисления минимальны. Единственный нелинейный компонент использует sqrt(total_effective_balance) для расчета основной награды, что применимо ко всем валидаторам. Это означает, что оценка вознаграждения и сокращения валидаторов все так же может осуществляться на основе «каждого 1 ETH» (или, более точно, в соответствии с spec.effective_balance_increment, что может измениться в будущем).
Для получения более подробной информации обратитесь к нашей предыдущей статье о действиях валидаторов.
EIP-7002: Вызываемый выход исполнительного уровня
Ссылка: EIP-7002
У каждого проверяющего в Ethereum есть две пары ключей: активный ключ и ключ для снятия средств. Активный общедоступный ключ BLS используется в качестве основной идентификации проверяющего в цепи маяка; эта пара ключей используется для подписи блоков, доказательств, усечения, агрегации комитетов и (до этого EIP) добровольного выхода (чтобы запустить выход проверяющего из консенсуса после задержки). Вторая пара ключей («вытягиваемые») может быть другой парой ключей BLS или обычным счетом Eth1 (закрытый ключ и адрес). Теперь для извлечения средств на адрес ETH требуется сообщение о снятии, подписанное активным закрытым ключом BLS. Этот EIP был изменен.
На самом деле владельцы этих двух (активная и выводная) пар ключей могут быть разными. Активный ключ валидатора отвечает за проверочные обязанности: запуск сервера, поддержание его работоспособности и т. д., в то время как учетные данные для вывода обычно контролируются владельцем стейка, который получает вознаграждение и отвечает за средства. В настоящее время только владелец стейка, который контролирует учетные данные для вывода средств, не может инициировать вывод валидатора и может вывести только вознаграждение. Такая ситуация позволяет владельцу активного ключа валидатора эффективно удерживать баланс валидатора в качестве «заложника». Валидаторы могут «предварительно подписать» сообщение о выходе и передать его владельцу стейка, но этот обходной путь не идеален. Кроме того, как извлечение, так и вывод средств в настоящее время требуют взаимодействия с валидаторами уровня маяков через специальный API.
Лучшим решением является разрешение владельцам стейкинга вызывать операции выхода и снятия средств одновременно через обычный смарт-контракт. Это включает в себя стандартную проверку подписи Eth1, что существенно упрощает процесс.
Этот EIP позволяет владельцам ставок вызывать вывод и выход (подобно процессу депозита с использованием существующего контракта «депозит») путем отправки стандартной транзакции с их адреса ETH на специальный смарт-контракт.
Застраховавшийся отправляет запрос на снятие средств (запрос «in») в контракт системы.
Плата за контракт взимается в определенном размере (в ETH) для смягчения возможных злонамеренных атак и аналогична EIP-1559, при этом плата увеличивается при загруженности очереди запросов.
Договор сохраняет запрос на снятие / выход "in" в своем хранилище.
Когда блок предлагается на уровне маяка, запросы на снятие / выход из очереди "in" извлекаются из хранилища.
Слой маяка обрабатывает запросы 'in', взаимодействует с остатками активных проверяющих и устраивает их выход, а также формирует запросы на снятие 'out'.
Запрос на вывод из out обрабатывается на уровне выполнения, залогодатель получает свои ETH.
В то время как депозиты — это действие, запускаемое в блоке Eth1, а затем «перемещаемое» на уровень маяка через очередь «ожидающих» депозитов, снятие средств происходит по другой схеме. Они запускаются на уровне маяка (через CLI), а затем «перемещаются» в блок Eth1. Теперь обе схемы будут работать через один и тот же общий фреймворк (описанный ниже): создавать запросы на уровне ETH1, обрабатывать очередь «ожидания» ввода/вывода/слияния и обрабатывать их на уровне маяка. Для операций «вывода», таких как вывод средств, очередь вывода также обрабатывается, и результат «рассчитывается» в блоке Eth1.
Через этот EIP стейкеры могут извлекать и выводить своих валидаторов с помощью обычных транзакций ETH, не взаимодействуя напрямую с валидатором CLI или получая доступ к его инфраструктуре. Это значительно упрощает операции по стейкингу, особенно для крупных поставщиков стейкинга. Инфраструктура валидатора теперь может быть практически полностью изолирована, поскольку нужно только поддерживать ключи активных валидаторов, а все операции по стейкингу можно обрабатывать в другом месте. Оно устраняет необходимость независимым стейкерам ожидать действий активных валидаторов и значительно упрощает внешнюю часть службы, такую как Community Staking Module, в Lido.
Таким образом, этот EIP «завершает» операцию залога, полностью перенося его на уровень Eth1, что значительно снижает риск безопасности инфраструктуры и укрепляет децентрализацию независимой инициативы по залогу.
EIP-6110：Нацепить проверку депозита для проверяющего на цепи
Ссылка: EIP-6110
В настоящее время депозиты осуществляются через события в контракте «депозит», как было подробно рассмотрено в предыдущих статьях. Контракт принимает ETH и удостоверения валидаторов, инициирует событие «Deposit()», которые затем анализируются и преобразуются в запросы на депозит на уровне маяка. В этой системе есть много недостатков: она требует голосования за eth1data на уровне маяка, что существенно увеличивает задержку. Кроме того, маяковый уровень должен запрашивать выполнение, что еще больше усложняет процесс. Эти проблемы подробно обсуждаются в EIP. Более простой способ, избегающий многих этих проблем, - непосредственное включение запросов на депозит в блоки Eth1 в указанной точке. Этот механизм аналогичен описанному ранее процессу обработки снятия в EIP.
Изменения, предложенные в этом EIP, имеют большие перспективы. Обработка eth1data теперь может быть полностью удалена, не требуется голосование или длительная задержка между событиями на стороне Eth1 и сигнальным слоем для включения депозита (в настоящее время около 12 часов). Он также удаляет логику снимка контракта депозита. Этот EIP упрощает обработку депозитов и выравнивает ее с вышеуказанной схемой вывода.
Для залогодателей и валидаторов эти изменения значительно сокращают задержку между депозитом и активацией валидатора. Когда валидатор урезается, необходимые дополнения также происходят быстрее.
О данном EIP больше ничего сказать нечего, кроме того, что он удалил устаревшую логику, упростил процесс и создал лучший результат для всех заинтересованных сторон.
EIP-7685: Запросы универсального выполнения слоя
Ссылка: EIP-7685
Этот EIP должен был быть представлен до трех EIP, связанных с депозитами/снятием/слиянием, чтобы заложить основу для этих EIP. Однако здесь он представлен, чтобы подчеркнуть растущую потребность в перемещении специализированных данных между блоками (уровнями) Eth1 (исполнение) и битовыми (согласование) цепями. Этот EIP влияет на два уровня, что делает обработку запросов, инициируемых обычными транзакциями ETH, более эффективной. В настоящее время мы наблюдаем:
Событие депозита в блоке Eth1 «перемещается» для обработки в блок-сигнале.
Запрос на снятие средств из блока маяка (с использованием интерфейса командной строки) «перемещен» в блок Eth1 для обработки.
Слияние валидатора должно быть обработано, что также является запросом маяка ETH1->.
Эти три операции показывают необходимость последовательной обработки различных типов запросов при переходе между уровнем выполнения и уровнем маяка. Кроме того, нам необходимо иметь возможность запускать эти операции только на уровне Eth1, поскольку это позволит изолировать инфраструктуру валидаторов от инфраструктуры управления стейкингом и повысить уровень безопасности. Таким образом, универсальное решение для управления такими запросами является как практически необходимым, так и важным.
Этот EIP создает структуру для по крайней мере трех основных случаев: депозит, снятие и объединение. Поэтому ранние EIP вводили поля, такие как WITHDRAWAL_REQUEST_TYPE и DEPOSIT_REQUEST_TYPE, а теперь объединение добавит еще одно поле, CONSOLIDATION_REQUEST_TYPE. Кроме того, этот EIP может также включать общий механизм для ограничения таких запросов (см. константы: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Хотя подробности реализации этой структуры пока недоступны, она определенно будет включать ключевые типы запросов, механизмы целостности (например, хеширование и Меркельзация запросов) и обработку очереди и ограничение скорости.
Этот EIP имеет архитектурное значение, позволяя Eth1 запускать ключевые операции в слое маяка через единый фреймворк. Для конечных пользователей и проектов это означает, что все запросы, запущенные на уровне Eth1, будут более эффективно передаваться и обрабатываться в слое маяка.
EIP-2537: Предварительная компиляция операций на кривой BLS12-381
Ссылка: EIP-2537
Если вы не хотите погружаться в детали, вы можете рассматривать предварительную компиляцию BLS12-381 как сложную операцию шифрования "хэш", которую теперь можно использовать в смарт-контрактах. Для тех, кто заинтересован, давайте продолжим обсуждение.
Математические операции с эллиптическими кривыми, такими как BLS12-381 (а также соответствующая ей BN-254), в настоящее время осуществляются для двух целей:
Подпись BLS, в которой используется специальная операция, называемая 'сопряжение', для проверки этих подписей. Подписи BLS широко используются проверяющими, потому что они объединяют несколько подписей в одну. Проверяющие полагаются на подписи BLS на основе кривой BLS12-381 (хотя они также могут использовать любую реализацию кривой, поддерживающую сопряжение, такую как BN254).
Проверка доказательства zkSNARK, в которой используется пара для проверки доказательства. Кроме того, обещание KZG для больших блоков, введенное жестким разделением цепи Dencun, также использует пару для проверки обещания блока.
Если вы хотите проверить BLS подпись или zkSNARK доказательство в смарт-контракте, вам нужно выполнить эти «пары», что является очень дорогим с точки зрения вычислений. В Ethereum уже есть предварительный контракт для операций с кривой BN254 (EIP-196 и EIP-197). Тем не менее, кривая BLS12-381 (считается более безопасной и широко используемой сегодня) до сих пор не реализована как предварительный. Без такого предварительного контракта реализация пар и других операций с кривой в смарт-контракте требует большого количества вычислений, как показано здесь, и потребляет огромное количество газа (~10^5 до 10^6 газа).
Этот EIP открывает двери для множества потенциальных применений, особенно в дешевой проверке подписи BLS на основе кривой BLS12-381. Это делает возможным реализацию различных пороговых схем для различных целей. Как уже упоминалось, проверщики Ethereum уже используют подписи на основе BLS12-381. Через этот EIP стандартные смарт-контракты теперь могут эффективно проверять агрегированные подписи проверщиков. Это может упростить доказательства согласия и мосты для перехода между сетями, поскольку подписи BLS широко используются в блокчейне. Сам по себе пороговый подписи BLS позволяет строить множество эффективных пороговых схем для голосования, децентрализованной генерации случайных чисел, мультиподписей и т. д.
Более дешевая верификация доказательств zkSNARK открывает массу возможностей. Многие решения, основанные на zkSNARK, в настоящее время ограничены высокой стоимостью верификации доказательств, что делает некоторые проекты практически невозможными. Это EIP имеет потенциал изменить ситуацию.
EIP-2935：Сохранение хэша исторического блока в состоянии
Ссылка: EIP-2935
Это предложение EIP предлагает хранить 8192 (примерно 27,3 часа) исторических хэша блоков в состоянии блокчейна для расширения истории для клиентов без состояния (например, rollup) и смарт-контрактов. Оно предлагает сохранить текущее поведение операции BLOCKHASH, ограничиваясь 256 блоками, а также внедрить новый системный контракт, специально разработанный для хранения и извлечения исторических хэшей. Этот контракт выполняет операцию set() при обработке блоков на уровне исполнения. Метод get() доступен для любого, чтобы получить доступ к извлечению необходимых хэшей блоков из кольцевого буфера.
В настоящее время в EVM возможно ссылаться на исторический хэш блока, но доступ ограничен только к последним 256 блокам (примерно 50 минут). Однако в некоторых случаях доступ к более старым данным блоков является критически важным, особенно для межцепочных приложений (требуется доказательство данных предыдущих блоков) и безсостояничных клиентов, которым регулярно требуется доступ к хэшам более ранних блоков.
Этот EIP расширяет временной диапазон, доступный для использования rollup и межцепочных приложений, позволяя им напрямую обращаться к историческим данным в EVM, без необходимости их внешнего сбора. Таким образом, эти решения становятся более надежными и устойчивыми.
EIP-7623: увеличение стоимости calldata
Ссылка: EIP-7623
calldata регулирует доступный размер полезной нагрузки транзакции, что в некоторых случаях может быть значительным (например, при передаче в качестве параметра больших массивов или двоичных буферов). Значительное использование calldata в основном обусловлено rollup, которые отправляют полезную нагрузку, содержащую текущее состояние rollup.
Введение крупных и доказуемых двоичных данных в блокчейн критически важно для rollup. Обновление Dencun (Deneb-Cancun) внесло важное новшество для таких случаев использования - транзакции blob (EIP-4844). У транзакций blob есть свой специальный газ «blob», их основное тело временно хранится, но их криптографическое доказательство (обещание KZG) вместе с их хешем интегрируется на уровне консенсуса. Таким образом, по сравнению с использованием calldata для хранения данных, blob предоставляет лучшее решение для rollup.
Поощрение rollup перемещать свои данные в blob может быть достигнуто путем 'моркови и палки'. Уменьшенная плата за газ blob действует как 'морковь', а этот EIP, увеличивая стоимость calldata, действует как 'палка', тем самым подавляя избыточное хранение данных в транзакциях. Этот EIP дополняет следующий EIP-7691 (увеличение пропускной способности Blob), который увеличивает максимальное количество blob, разрешенное для каждого блока.
EIP-7691: пропускная способность BLOB-объектов увеличена.
Справка: EIP-7691
В предыдущем хардфорке Dencun был введен blob, и начальные значения максимального и целевого количества blob на "каждый блок" были консервативно оценены. Это связано с тем, что сложность передачи больших двоичных объектов между узлами-проверяющими в p2p сети предполагается. Предыдущая конфигурация показала себя хорошо, что делает это подходящим временем для тестирования новых значений. Ранее количество blob на каждый блок было установлено на 3/6. Эти ограничения были увеличены до 6/9.
Совмещение с EIP-7623 (увеличение стоимости calldata) дополнительно стимулирует rollup перемещать свои данные из calldata в blobs. Работа по поиску оптимальных параметров для blobs продолжается.
EIP-7840: добавление планирования блобов в файл конфигурации EL
Ссылка: EIP-7840
Этот EIP предлагает добавить цель и максимальное количество «блобов» на блок (как уже обсуждалось ранее), а также значение baseFeeUpdateFraction в конфигурационный файл исполнительного уровня (EL) Ethereum. Он также позволяет клиентам извлекать эти значения через API узла. Эта функция особенно полезна для задач, таких как оценка стоимости газа для блобов и т. д.
EIP-7702: Установка кода учетной записи EOA
Ссылка: EIP-7702
Это очень важный EIP, который принесет значительные изменения пользователям Ethereum. Как мы знаем, EOA (внешний аккаунт владельца) не может содержать никакого кода, но может предоставлять подпись транзакции (tx.origin). В отличие от этого, у смарт-контрактов есть байт-код, но они не могут активно предоставлять прямую подпись. Любое взаимодействие пользователя, требующее дополнительной, автоматической и проверяемой логики, в настоящее время может выполняться только путем вызова внешнего контракта для выполнения необходимых операций. Однако в этом случае внешний контракт становится msg.sender для последующего контракта, делая вызов "от контракта", а не от пользователя.
Этот EIP представляет новый тип транзакции SET_CODE_TX_TYPE=0x04 (ранее у нас были старые транзакции 0x1, новые транзакции 0x02 от Берлина и EIP-1559, а также транзакции blob 0x03, введенные в Dencun). Этот новый тип транзакции позволяет установить код для EOA-счета. Фактически, он позволяет EOA «в контексте своего собственного EOA-счета» выполнять внешний код. С точки зрения внешнего наблюдателя, в процессе транзакции EOA как будто бы «заимствует» код от внешнего контракта и выполняет его. Технически это достигается путем добавления специального кортежа разрешающих данных в хранилище «кода» адреса EOA (до этого EIP это хранилище «кода» для EOA всегда было пустым).
В настоящее время этот новый тип транзакции 0x04, предложенный в EIP, содержит массив:
Каждый элемент позволяет учетной записи использовать код из указанного адреса (из последнего действительного элемента авторизации). При обработке таких транзакций код EOA устанавливается в специальное значение 0xef0100 || адрес (23 байта), указывающий на контракт с необходимым кодом, || - это оператор объединения, 0xef0100 - это специальное магическое значение, которое обычный смарт-контракт не может содержать (согласно EIP-3541). Это магическое значение гарантирует, что эту EOA нельзя рассматривать как обычный контракт и ее нельзя вызывать как обычный контракт.
Когда этот EOA инициирует транзакцию, указанный адрес будет использоваться для вызова соответствующего кода в контексте этого EOA. Хотя полные детали реализации этого EIP пока не ясны, можно утверждать, что он принесет с собой значительные изменения.
Одним из основных влияний является возможность прямого выполнения множественных вызовов (multicall) из EOA. Множественные вызовы являются постоянным трендом в DeFi, и многие протоколы предоставляют эту функцию как мощный инструмент (например, Uniswap V4, Balancer V3 или Euler V2). С помощью этого EIP теперь можно выполнять множественные вызовы непосредственно из EOA.
Например, эта новая функция решает распространенную проблему в DeFi: низкую эффективность двух отдельных транзакций approve() + anything(). Этот EIP позволяет использовать общую «предварительную авторизацию», что позволяет завершить операцию типа approve(X) + deposit(X) в одной транзакции.
Еще одним преимуществом, которое предлагает возможность «представлять» выполнение делегированных транзакций EOA, является понятие спонсорства. Спонсорство - это особенность, которая часто обсуждается и высоко желаема, чтобы помочь новым пользователям вступить в мир Ethereum.
Программируемая логика, связанная с EOA, открывает множество возможностей, таких как установка безопасных ограничений, установка верхнего предела расходов, обязательное выполнение KYC и т. д.
Конечно, этот сдвиг также поднимает ряд вопросов к дизайну. Одной из проблем является использование chain_id, которая определяет, может ли одна и та же подпись быть действительной в нескольких сетях, в зависимости от того, включена она в подпись или нет. Еще одной сложностью является выбор между использованием адреса объектного кода и внедрением фактического байт-кода. Оба метода имеют свои уникальные особенности и ограничения. Кроме того, использование nonce играет ключевую роль в определении того, является ли разрешение «многоцелевым» или «одноцелевым». Эти элементы влияют на функциональность и безопасность, включая такие аспекты, как массовая аннулирование подписей и простота использования. Виталик поднял эти вопросы в дискуссии (здесь), которую стоит изучить подробнее.
Столом примечательно то, что эти изменения повлияют на один из механизмов безопасности Ethereum, tx.origin. Больше деталей о реализации этого EIP необходимо, но, по-видимому, изменится поведение require(tx.origin == msg.sender). Эта проверка всегда была надежным способом убедиться, что msg.sender - это EOA, а не контракт. Другие методы, такие как проверка EXTCODESIZE (для определения контракта), обычно не работают и могут быть обойдены (например, путем вызова конструктора или развертывания кода на предопределенный адрес после транзакции). Эти проверки не идеальны в предотвращении рекурсивных и молниеносных кредитов, так как они также мешают интеграции с внешними протоколами. После этого EIP даже надежная проверка require(tx.origin == msg.sender), кажется, устареет. Протоколы должны приспособиться, удалив эти проверки, так как различие между «EOA» и «контрактом» больше не будет действительным - теперь у каждого адреса может быть связанный код.
Разделение традиционного EOA и смарт-контракта продолжает смазываться. Этот EIP делает Ethereum ближе к дизайну, подобному TON, где каждый счет фактически является исполняемым кодом. По мере усложнения взаимодействия с протоколом использование программной логики для улучшения опыта конечного пользователя является естественным шагом в этом развитии.
Вывод
Обновление Prague / Electra (Pectra) запланировано на март 2025 года. Самые значительные изменения в плане включают:
Переменные разрешения действительны для залога, достигая максимума в 2048 ETH, что значительно изменит распределение залогов, график работы разрешений и упростит управление крупными поставщиками залогов за счет интеграции меньших залогов.
Улучшение взаимодействия между уровнем выполнения и уровнем согласования, упрощение обмена данными между блоками выполнения Eth1 и блоками цепочки маяка. Это значительно упростит процессы депозита, активации, извлечения и выхода, ускорит их выполнение и заложит основу для дальнейшего взаимодействия между уровнями согласования и выполнения.
Поддержка более дешевых BLS-подписей и zkSNARK-проверки с помощью нового предварительно скомпилированного «пары-дружественного» BLS12-381 в смарт-контракте
Поощрение Rollups через увеличение порога транзакций blob и увеличение стоимости calldata для принятия транзакций blob
Делает EOA функционировать как программируемый счет, предоставляя ему множественные вызовы, спонсирование и другие продвинутые функции
Как вы видите, Pectra окажет значительное влияние на опыт конечного пользователя в области стейкинга и консенсусного уровня, а также исполнительного уровня. Хотя мы не можем в настоящее время провести подробный анализ всех этих изменений через код, поскольку разработка все еще продолжается, мы рассмотрим эти обновления в будущих статьях.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Разбор грядущего хардфорка Ethereum - обновление Pectra
Введение
В нашей предыдущей статье мы подробно рассмотрели жизненный цикл проверяющего Ethereum, обсудили несколько аспектов, связанных с предстоящим жестким разделением Electra. Теперь пришло время обратить внимание на изменения в предстоящих обновлениях Electra и Prague и подробно их объяснить.
История жесткого разделения Ethereum 2.0 «Proof of Stake» (PoS) сложна. Она началась с добавления маркерного уровня к существующему уровню исполнения, в то время как на маркерном уровне запускалось согласование PoS, уровень исполнения всё ещё поддерживал рабочее согласование (жесткое разделение Phase0 и Altair). Затем, в жестком разделении Bellatrix, PoS было полностью активировано (хотя вывод ещё не был включен). Затем в жестком разделении Capella был разрешен вывод, завершая жизненный цикл проверяющего. Последнее жесткое разделение Deneb (часть обновления Dencun (Deneb/Cancun)) незначительно изменяет параметры маркерной цепи, такие как временное окно подтверждения, обработка добровольного выхода и ограничение на замену проверяющего. Основные изменения в Dencun происходят на уровне исполнения, вводятся blob-транзакции, blob gas, KZG обязательства для blob и отменяется операция SELFDESTRUCT.
В настоящее время хардфорк Prague/Electra (т.е. Pectra) внес важные изменения в исполнение и консенсусный уровень. В качестве аудиторов проекта Lido мы в основном обращаем внимание на изменения в консенсусе и стейкинге в этом хардфорке. Однако мы не можем игнорировать изменения в исполнении в Prague, поскольку они включают важные особенности, влияющие на сеть Ethereum и валидаторов. Давайте подробнее рассмотрим эти изменения.
Общий обзор Pectra
Electra внесла множество функций в свой маяк. Основные обновления включают:
В то же время Прага внесла следующие изменения в исполнительный состав:
Давайте обратимся к соответствующему улучшению Ethereum (EIP), чтобы продолжить обсуждение:
Некоторые из этих EIP относятся к слою консенсуса (бэйсбин), в то время как другие связаны с исполнительным слоем. Некоторые пересекают оба слоя, поскольку некоторые операции (например, депозиты и снятие средств) требуют синхронных изменений между консенсусом и исполнительным слоем. Из-за этой взаимозависимости разделение Electra и Prague является неосуществимым, поэтому мы последовательно рассмотрим каждый EIP и определим затронутые компоненты Ethereum в каждом случае.
EIP-7251: увеличен MAX_EFFECTIVE_BALANCE
Ссылка: EIP-7251
С момента первого жесткого разделения фазы 0, для подготовки к доказательству доли Ethereum, до Electra, максимальный действительный баланс проверяющего был зафиксирован на уровне 32 ETH. Активация проверяющего требует как минимум spec.min_activation_balance (32 ETH). После активации проверяющий начинает с этого максимального действительного баланса, но может уменьшить его до spec.ejection_balance (16 ETH) и быть изгнанным, когда достигнет этого порога. Эта «минимальная» логика остается неизменной в Electra, но теперь spec.max_effective_balance увеличен до 2048 ETH. Таким образом, проверяющий может внести депозит от 32 до 2048 ETH для активации, и все эти суммы будут вносить вклад в его действительный баланс. Этот переход означает переход от «32ETH-доказательства доли» к «доказательству доли» :)
Этот изменяющийся доступный остаток будет использоваться для:
Первые два мероприятия - это наиболее выгодные действия для валидаторов. Следовательно, после Electra валидаторы с высокими ставками будут чаще участвовать в предложении блоков и комитете синхронизации, их частота будет пропорциональна их действительному остатку.
Еще одно влияние связано с сокращением. Все штрафы за сокращение пропорциональны действительному остатку средств проверяющего.
Electra также предлагает изменение коэффициента сокращения, определяет часть остатка баланса сокращенного валидатора и передает его донесителю.
Далее идет влияние недействительности. Когда проверяющий находится в активном состоянии (доказательство или предложение), но офлайн, балл недействительности накапливается, что приводит к наложению наказания за недействительность на каждый период. Эти наказания также пропорциональны балансу проверяющего.
В связи со значительным увеличением доступного баланса изменяется также «ограничение замены» для валидаторов. В старой версии Ethereum до Electra валидаторы обычно имеют одинаковый доступный баланс, а ограничение замены определяется как «в течение одного периода можно выйти только с общей ставкой, которая не превышает 1/65536 (spec.churn_limit_quotient)». Это приводит к «фиксированному» количеству выходящих валидаторов с одинаковой ставкой. Однако после Electra возможно, что только небольшое количество «китов» будет выходить, так как они представляют собой значительную часть общей ставки.
Еще одним соображением является переключение многих ключей проверяющего на одном экземпляре проверяющего. В настоящее время крупные проверяющие вынуждены запускать тысячи ключей проверяющего на одном экземпляре, чтобы удовлетворить большой депозит, который разбивается на 32 ETH части. С Electra такое поведение не является обязательным. С финансовой точки зрения это изменение не оказывает большого влияния, поскольку вознаграждение и вероятность линейно масштабируются с суммой депозита. Таким образом, 100 проверяющих по 32 ETH эквивалентны одному проверяющему по 3200 ETH. Кроме того, несколько активных ключей проверяющего могут иметь один и тот же ETH1-чек, что позволяет извлекать все вознаграждения на один адрес ETH и избежать связанных с объединением вознаграждений затрат на газ. Однако управление большим количеством ключей приводит к дополнительным затратам на управление.
Способность к агрегации баланса проверяющего увеличена новым типом запроса исполнительного уровня. Ранее у нас были депозиты и снятия. Теперь появится еще один тип: агрегированный запрос. Он объединяет двух проверяющих в одного. Запрос на операцию будет включать открытый ключ исходного проверяющего и целевой ключ и будет обрабатываться аналогично депозитам и снятиям. Агрегация также будет иметь ограничения на ожидающие запросы и замену баланса, как и депозиты и снятия.
Подводя итог, следует отметить:
Ещё одной важной темой являются исторические данные и оценка прибыли для валидаторов, особенно актуально для новых участников, которые пытаются оценить риски и вознаграждение. До появления Electra (на момент написания настоящей статьи) ограничение в 32 ETH (фактически, независимо от того, является ли это минимальным или максимальным значением) создавало однородность в исторических данных. Все валидаторы имели одинаковый остаток, награду, индивидуальные штрафы за уменьшение, частоту предложения блока и другие показатели. Эта однородность позволила Ethereum тестировать свой механизм согласия без статистических выбросов, собирая ценные данные о поведении сети.
После Electra произойдут значительные изменения в распределении ставок. Участие крупных валидаторов в блок-предложениях и комитете синхронизации будет более частым, они будут сталкиваться с более строгим наказанием в случае сокращения, а также будут оказывать большее влияние на очередь активации и очередь выхода. Хотя это может представлять вызовы для агрегации данных, консенсус Ethereum гарантирует, что нелинейные вычисления минимальны. Единственный нелинейный компонент использует sqrt(total_effective_balance) для расчета основной награды, что применимо ко всем валидаторам. Это означает, что оценка вознаграждения и сокращения валидаторов все так же может осуществляться на основе «каждого 1 ETH» (или, более точно, в соответствии с spec.effective_balance_increment, что может измениться в будущем).
Для получения более подробной информации обратитесь к нашей предыдущей статье о действиях валидаторов.
EIP-7002: Вызываемый выход исполнительного уровня
Ссылка: EIP-7002
У каждого проверяющего в Ethereum есть две пары ключей: активный ключ и ключ для снятия средств. Активный общедоступный ключ BLS используется в качестве основной идентификации проверяющего в цепи маяка; эта пара ключей используется для подписи блоков, доказательств, усечения, агрегации комитетов и (до этого EIP) добровольного выхода (чтобы запустить выход проверяющего из консенсуса после задержки). Вторая пара ключей («вытягиваемые») может быть другой парой ключей BLS или обычным счетом Eth1 (закрытый ключ и адрес). Теперь для извлечения средств на адрес ETH требуется сообщение о снятии, подписанное активным закрытым ключом BLS. Этот EIP был изменен.
На самом деле владельцы этих двух (активная и выводная) пар ключей могут быть разными. Активный ключ валидатора отвечает за проверочные обязанности: запуск сервера, поддержание его работоспособности и т. д., в то время как учетные данные для вывода обычно контролируются владельцем стейка, который получает вознаграждение и отвечает за средства. В настоящее время только владелец стейка, который контролирует учетные данные для вывода средств, не может инициировать вывод валидатора и может вывести только вознаграждение. Такая ситуация позволяет владельцу активного ключа валидатора эффективно удерживать баланс валидатора в качестве «заложника». Валидаторы могут «предварительно подписать» сообщение о выходе и передать его владельцу стейка, но этот обходной путь не идеален. Кроме того, как извлечение, так и вывод средств в настоящее время требуют взаимодействия с валидаторами уровня маяков через специальный API.
Лучшим решением является разрешение владельцам стейкинга вызывать операции выхода и снятия средств одновременно через обычный смарт-контракт. Это включает в себя стандартную проверку подписи Eth1, что существенно упрощает процесс.
Этот EIP позволяет владельцам ставок вызывать вывод и выход (подобно процессу депозита с использованием существующего контракта «депозит») путем отправки стандартной транзакции с их адреса ETH на специальный смарт-контракт.
В то время как депозиты — это действие, запускаемое в блоке Eth1, а затем «перемещаемое» на уровень маяка через очередь «ожидающих» депозитов, снятие средств происходит по другой схеме. Они запускаются на уровне маяка (через CLI), а затем «перемещаются» в блок Eth1. Теперь обе схемы будут работать через один и тот же общий фреймворк (описанный ниже): создавать запросы на уровне ETH1, обрабатывать очередь «ожидания» ввода/вывода/слияния и обрабатывать их на уровне маяка. Для операций «вывода», таких как вывод средств, очередь вывода также обрабатывается, и результат «рассчитывается» в блоке Eth1.
Через этот EIP стейкеры могут извлекать и выводить своих валидаторов с помощью обычных транзакций ETH, не взаимодействуя напрямую с валидатором CLI или получая доступ к его инфраструктуре. Это значительно упрощает операции по стейкингу, особенно для крупных поставщиков стейкинга. Инфраструктура валидатора теперь может быть практически полностью изолирована, поскольку нужно только поддерживать ключи активных валидаторов, а все операции по стейкингу можно обрабатывать в другом месте. Оно устраняет необходимость независимым стейкерам ожидать действий активных валидаторов и значительно упрощает внешнюю часть службы, такую как Community Staking Module, в Lido.
Таким образом, этот EIP «завершает» операцию залога, полностью перенося его на уровень Eth1, что значительно снижает риск безопасности инфраструктуры и укрепляет децентрализацию независимой инициативы по залогу.
EIP-6110：Нацепить проверку депозита для проверяющего на цепи
Ссылка: EIP-6110
В настоящее время депозиты осуществляются через события в контракте «депозит», как было подробно рассмотрено в предыдущих статьях. Контракт принимает ETH и удостоверения валидаторов, инициирует событие «Deposit()», которые затем анализируются и преобразуются в запросы на депозит на уровне маяка. В этой системе есть много недостатков: она требует голосования за eth1data на уровне маяка, что существенно увеличивает задержку. Кроме того, маяковый уровень должен запрашивать выполнение, что еще больше усложняет процесс. Эти проблемы подробно обсуждаются в EIP. Более простой способ, избегающий многих этих проблем, - непосредственное включение запросов на депозит в блоки Eth1 в указанной точке. Этот механизм аналогичен описанному ранее процессу обработки снятия в EIP.
Изменения, предложенные в этом EIP, имеют большие перспективы. Обработка eth1data теперь может быть полностью удалена, не требуется голосование или длительная задержка между событиями на стороне Eth1 и сигнальным слоем для включения депозита (в настоящее время около 12 часов). Он также удаляет логику снимка контракта депозита. Этот EIP упрощает обработку депозитов и выравнивает ее с вышеуказанной схемой вывода.
Для залогодателей и валидаторов эти изменения значительно сокращают задержку между депозитом и активацией валидатора. Когда валидатор урезается, необходимые дополнения также происходят быстрее.
О данном EIP больше ничего сказать нечего, кроме того, что он удалил устаревшую логику, упростил процесс и создал лучший результат для всех заинтересованных сторон.
EIP-7685: Запросы универсального выполнения слоя
Ссылка: EIP-7685
Этот EIP должен был быть представлен до трех EIP, связанных с депозитами/снятием/слиянием, чтобы заложить основу для этих EIP. Однако здесь он представлен, чтобы подчеркнуть растущую потребность в перемещении специализированных данных между блоками (уровнями) Eth1 (исполнение) и битовыми (согласование) цепями. Этот EIP влияет на два уровня, что делает обработку запросов, инициируемых обычными транзакциями ETH, более эффективной. В настоящее время мы наблюдаем:
Эти три операции показывают необходимость последовательной обработки различных типов запросов при переходе между уровнем выполнения и уровнем маяка. Кроме того, нам необходимо иметь возможность запускать эти операции только на уровне Eth1, поскольку это позволит изолировать инфраструктуру валидаторов от инфраструктуры управления стейкингом и повысить уровень безопасности. Таким образом, универсальное решение для управления такими запросами является как практически необходимым, так и важным.
Этот EIP создает структуру для по крайней мере трех основных случаев: депозит, снятие и объединение. Поэтому ранние EIP вводили поля, такие как WITHDRAWAL_REQUEST_TYPE и DEPOSIT_REQUEST_TYPE, а теперь объединение добавит еще одно поле, CONSOLIDATION_REQUEST_TYPE. Кроме того, этот EIP может также включать общий механизм для ограничения таких запросов (см. константы: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).
Хотя подробности реализации этой структуры пока недоступны, она определенно будет включать ключевые типы запросов, механизмы целостности (например, хеширование и Меркельзация запросов) и обработку очереди и ограничение скорости.
Этот EIP имеет архитектурное значение, позволяя Eth1 запускать ключевые операции в слое маяка через единый фреймворк. Для конечных пользователей и проектов это означает, что все запросы, запущенные на уровне Eth1, будут более эффективно передаваться и обрабатываться в слое маяка.
EIP-2537: Предварительная компиляция операций на кривой BLS12-381
Ссылка: EIP-2537
Если вы не хотите погружаться в детали, вы можете рассматривать предварительную компиляцию BLS12-381 как сложную операцию шифрования "хэш", которую теперь можно использовать в смарт-контрактах. Для тех, кто заинтересован, давайте продолжим обсуждение.
Математические операции с эллиптическими кривыми, такими как BLS12-381 (а также соответствующая ей BN-254), в настоящее время осуществляются для двух целей:
Если вы хотите проверить BLS подпись или zkSNARK доказательство в смарт-контракте, вам нужно выполнить эти «пары», что является очень дорогим с точки зрения вычислений. В Ethereum уже есть предварительный контракт для операций с кривой BN254 (EIP-196 и EIP-197). Тем не менее, кривая BLS12-381 (считается более безопасной и широко используемой сегодня) до сих пор не реализована как предварительный. Без такого предварительного контракта реализация пар и других операций с кривой в смарт-контракте требует большого количества вычислений, как показано здесь, и потребляет огромное количество газа (~10^5 до 10^6 газа).
Этот EIP открывает двери для множества потенциальных применений, особенно в дешевой проверке подписи BLS на основе кривой BLS12-381. Это делает возможным реализацию различных пороговых схем для различных целей. Как уже упоминалось, проверщики Ethereum уже используют подписи на основе BLS12-381. Через этот EIP стандартные смарт-контракты теперь могут эффективно проверять агрегированные подписи проверщиков. Это может упростить доказательства согласия и мосты для перехода между сетями, поскольку подписи BLS широко используются в блокчейне. Сам по себе пороговый подписи BLS позволяет строить множество эффективных пороговых схем для голосования, децентрализованной генерации случайных чисел, мультиподписей и т. д.
Более дешевая верификация доказательств zkSNARK открывает массу возможностей. Многие решения, основанные на zkSNARK, в настоящее время ограничены высокой стоимостью верификации доказательств, что делает некоторые проекты практически невозможными. Это EIP имеет потенциал изменить ситуацию.
EIP-2935：Сохранение хэша исторического блока в состоянии
Ссылка: EIP-2935
Это предложение EIP предлагает хранить 8192 (примерно 27,3 часа) исторических хэша блоков в состоянии блокчейна для расширения истории для клиентов без состояния (например, rollup) и смарт-контрактов. Оно предлагает сохранить текущее поведение операции BLOCKHASH, ограничиваясь 256 блоками, а также внедрить новый системный контракт, специально разработанный для хранения и извлечения исторических хэшей. Этот контракт выполняет операцию set() при обработке блоков на уровне исполнения. Метод get() доступен для любого, чтобы получить доступ к извлечению необходимых хэшей блоков из кольцевого буфера.
В настоящее время в EVM возможно ссылаться на исторический хэш блока, но доступ ограничен только к последним 256 блокам (примерно 50 минут). Однако в некоторых случаях доступ к более старым данным блоков является критически важным, особенно для межцепочных приложений (требуется доказательство данных предыдущих блоков) и безсостояничных клиентов, которым регулярно требуется доступ к хэшам более ранних блоков.
Этот EIP расширяет временной диапазон, доступный для использования rollup и межцепочных приложений, позволяя им напрямую обращаться к историческим данным в EVM, без необходимости их внешнего сбора. Таким образом, эти решения становятся более надежными и устойчивыми.
EIP-7623: увеличение стоимости calldata
Ссылка: EIP-7623
calldata регулирует доступный размер полезной нагрузки транзакции, что в некоторых случаях может быть значительным (например, при передаче в качестве параметра больших массивов или двоичных буферов). Значительное использование calldata в основном обусловлено rollup, которые отправляют полезную нагрузку, содержащую текущее состояние rollup.
Введение крупных и доказуемых двоичных данных в блокчейн критически важно для rollup. Обновление Dencun (Deneb-Cancun) внесло важное новшество для таких случаев использования - транзакции blob (EIP-4844). У транзакций blob есть свой специальный газ «blob», их основное тело временно хранится, но их криптографическое доказательство (обещание KZG) вместе с их хешем интегрируется на уровне консенсуса. Таким образом, по сравнению с использованием calldata для хранения данных, blob предоставляет лучшее решение для rollup.
Поощрение rollup перемещать свои данные в blob может быть достигнуто путем 'моркови и палки'. Уменьшенная плата за газ blob действует как 'морковь', а этот EIP, увеличивая стоимость calldata, действует как 'палка', тем самым подавляя избыточное хранение данных в транзакциях. Этот EIP дополняет следующий EIP-7691 (увеличение пропускной способности Blob), который увеличивает максимальное количество blob, разрешенное для каждого блока.
EIP-7691: пропускная способность BLOB-объектов увеличена.
Справка: EIP-7691
В предыдущем хардфорке Dencun был введен blob, и начальные значения максимального и целевого количества blob на "каждый блок" были консервативно оценены. Это связано с тем, что сложность передачи больших двоичных объектов между узлами-проверяющими в p2p сети предполагается. Предыдущая конфигурация показала себя хорошо, что делает это подходящим временем для тестирования новых значений. Ранее количество blob на каждый блок было установлено на 3/6. Эти ограничения были увеличены до 6/9.
Совмещение с EIP-7623 (увеличение стоимости calldata) дополнительно стимулирует rollup перемещать свои данные из calldata в blobs. Работа по поиску оптимальных параметров для blobs продолжается.
EIP-7840: добавление планирования блобов в файл конфигурации EL
Ссылка: EIP-7840
Этот EIP предлагает добавить цель и максимальное количество «блобов» на блок (как уже обсуждалось ранее), а также значение baseFeeUpdateFraction в конфигурационный файл исполнительного уровня (EL) Ethereum. Он также позволяет клиентам извлекать эти значения через API узла. Эта функция особенно полезна для задач, таких как оценка стоимости газа для блобов и т. д.
EIP-7702: Установка кода учетной записи EOA
Ссылка: EIP-7702
Это очень важный EIP, который принесет значительные изменения пользователям Ethereum. Как мы знаем, EOA (внешний аккаунт владельца) не может содержать никакого кода, но может предоставлять подпись транзакции (tx.origin). В отличие от этого, у смарт-контрактов есть байт-код, но они не могут активно предоставлять прямую подпись. Любое взаимодействие пользователя, требующее дополнительной, автоматической и проверяемой логики, в настоящее время может выполняться только путем вызова внешнего контракта для выполнения необходимых операций. Однако в этом случае внешний контракт становится msg.sender для последующего контракта, делая вызов "от контракта", а не от пользователя.
Этот EIP представляет новый тип транзакции SET_CODE_TX_TYPE=0x04 (ранее у нас были старые транзакции 0x1, новые транзакции 0x02 от Берлина и EIP-1559, а также транзакции blob 0x03, введенные в Dencun). Этот новый тип транзакции позволяет установить код для EOA-счета. Фактически, он позволяет EOA «в контексте своего собственного EOA-счета» выполнять внешний код. С точки зрения внешнего наблюдателя, в процессе транзакции EOA как будто бы «заимствует» код от внешнего контракта и выполняет его. Технически это достигается путем добавления специального кортежа разрешающих данных в хранилище «кода» адреса EOA (до этого EIP это хранилище «кода» для EOA всегда было пустым).
В настоящее время этот новый тип транзакции 0x04, предложенный в EIP, содержит массив:
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
Каждый элемент позволяет учетной записи использовать код из указанного адреса (из последнего действительного элемента авторизации). При обработке таких транзакций код EOA устанавливается в специальное значение 0xef0100 || адрес (23 байта), указывающий на контракт с необходимым кодом, || - это оператор объединения, 0xef0100 - это специальное магическое значение, которое обычный смарт-контракт не может содержать (согласно EIP-3541). Это магическое значение гарантирует, что эту EOA нельзя рассматривать как обычный контракт и ее нельзя вызывать как обычный контракт.
Когда этот EOA инициирует транзакцию, указанный адрес будет использоваться для вызова соответствующего кода в контексте этого EOA. Хотя полные детали реализации этого EIP пока не ясны, можно утверждать, что он принесет с собой значительные изменения.
Одним из основных влияний является возможность прямого выполнения множественных вызовов (multicall) из EOA. Множественные вызовы являются постоянным трендом в DeFi, и многие протоколы предоставляют эту функцию как мощный инструмент (например, Uniswap V4, Balancer V3 или Euler V2). С помощью этого EIP теперь можно выполнять множественные вызовы непосредственно из EOA.
Например, эта новая функция решает распространенную проблему в DeFi: низкую эффективность двух отдельных транзакций approve() + anything(). Этот EIP позволяет использовать общую «предварительную авторизацию», что позволяет завершить операцию типа approve(X) + deposit(X) в одной транзакции.
Еще одним преимуществом, которое предлагает возможность «представлять» выполнение делегированных транзакций EOA, является понятие спонсорства. Спонсорство - это особенность, которая часто обсуждается и высоко желаема, чтобы помочь новым пользователям вступить в мир Ethereum.
Программируемая логика, связанная с EOA, открывает множество возможностей, таких как установка безопасных ограничений, установка верхнего предела расходов, обязательное выполнение KYC и т. д.
Конечно, этот сдвиг также поднимает ряд вопросов к дизайну. Одной из проблем является использование chain_id, которая определяет, может ли одна и та же подпись быть действительной в нескольких сетях, в зависимости от того, включена она в подпись или нет. Еще одной сложностью является выбор между использованием адреса объектного кода и внедрением фактического байт-кода. Оба метода имеют свои уникальные особенности и ограничения. Кроме того, использование nonce играет ключевую роль в определении того, является ли разрешение «многоцелевым» или «одноцелевым». Эти элементы влияют на функциональность и безопасность, включая такие аспекты, как массовая аннулирование подписей и простота использования. Виталик поднял эти вопросы в дискуссии (здесь), которую стоит изучить подробнее.
Столом примечательно то, что эти изменения повлияют на один из механизмов безопасности Ethereum, tx.origin. Больше деталей о реализации этого EIP необходимо, но, по-видимому, изменится поведение require(tx.origin == msg.sender). Эта проверка всегда была надежным способом убедиться, что msg.sender - это EOA, а не контракт. Другие методы, такие как проверка EXTCODESIZE (для определения контракта), обычно не работают и могут быть обойдены (например, путем вызова конструктора или развертывания кода на предопределенный адрес после транзакции). Эти проверки не идеальны в предотвращении рекурсивных и молниеносных кредитов, так как они также мешают интеграции с внешними протоколами. После этого EIP даже надежная проверка require(tx.origin == msg.sender), кажется, устареет. Протоколы должны приспособиться, удалив эти проверки, так как различие между «EOA» и «контрактом» больше не будет действительным - теперь у каждого адреса может быть связанный код.
Разделение традиционного EOA и смарт-контракта продолжает смазываться. Этот EIP делает Ethereum ближе к дизайну, подобному TON, где каждый счет фактически является исполняемым кодом. По мере усложнения взаимодействия с протоколом использование программной логики для улучшения опыта конечного пользователя является естественным шагом в этом развитии.
Вывод
Обновление Prague / Electra (Pectra) запланировано на март 2025 года. Самые значительные изменения в плане включают:
Как вы видите, Pectra окажет значительное влияние на опыт конечного пользователя в области стейкинга и консенсусного уровня, а также исполнительного уровня. Хотя мы не можем в настоящее время провести подробный анализ всех этих изменений через код, поскольку разработка все еще продолжается, мы рассмотрим эти обновления в будущих статьях.