Какие EIP будут включены в обновление Pectra? Усилит ли это инфляцию ETH?

Утверждённые EIP повысят программируемость аккаунтов, эффективность валидации Ethereum и оптимизацию стейкинга, а неутверждённые EIP сосредоточены на улучшении масштабируемости L2.

Автор: 0XNATALIE

Следующее обновление Ethereum — Pectra, его название происходит от сочетания Prague и Electra.

Prague означает обновление исполнительного уровня, названное в честь города Прага, где проходила конференция разработчиков Ethereum (Devcon 4), а Electra символизирует обновление уровня консенсуса, где названия звёзд используются в алфавитном порядке. На этот раз выбрана звезда Electra, соответствующая букве «E».

Обновление Pectra может стать самым масштабным хардфорком в истории Ethereum по количеству включённых Ethereum Improvement Proposals (EIP). Оно включает ряд предложений по улучшению работы валидаторов и производительности основной сети, а также предложения по оптимизации L2. Тестовая сеть Pectra Devnet 4 только что запущена, и на данный момент уже 8 EIP подтверждены для включения в обновление Pectra.

Подтверждённые EIP и их влияние

Эти 8 EIP повлияют на пользователей следующим образом: добавление возможности выполнения кода для EOA повысит гибкость аккаунтов, позволяя им выполнять более сложные операции; увеличение лимита стейкинга может повысить спрос на ETH; оптимизация процессов валидации повысит безопасность и эффективность, а также увеличит скорость и пропускную способность Ethereum.

1. EIP-2537 (поддержка BLS-подписей): внедрение ряда предкомпилированных контрактов (precompiles) для поддержки операций с кривой BLS12-381 в Ethereum, что позволяет реализовать верификацию BLS-подписей и агрегировать несколько подписей в одну, снижая сложность валидации. BLS-подписи — это криптографический алгоритм, позволяющий создавать компактные подписи и поддерживать их агрегацию. Это поможет L2, которым требуется массовая верификация подписей и данных, работать более эффективно.
2. EIP-2935 (сохранение хэшей исторических блоков в состоянии): хранение последних 8192 хэшей блоков в системном контракте для поддержки модели Stateless Clients и предоставления более гибкой функции запроса хэшей исторических блоков. Эти хэши можно запрашивать напрямую через контракт и использовать в качестве доказательств (witness) для Stateless Clients. Клиентам не нужно хранить всю историю блокчейна или большие объёмы данных — достаточно полагаться на хэши блоков, хранящиеся в состоянии, и соответствующие доказательства для проверки легитимности блоков и транзакций.
3. EIP-6110 (депозиты валидаторов на цепочке): обработка депозитов валидаторов переносится с уровня консенсуса на исполнительный уровень, где депозиты обрабатываются и верифицируются на цепочке, без необходимости дополнительного механизма голосования на уровне консенсуса для подтверждения валидности депозитов. Это повышает безопасность процесса депозита, снижает задержки и упрощает архитектуру уровня консенсуса и клиентов.
4. EIP-7002 (выход, инициируемый исполнительным уровнем): позволяет владельцам withdrawal credentials самостоятельно инициировать выход, не полагаясь на активный ключ валидатора (BLS-ключ), что увеличивает автономию пользователей. В настоящее время только активный ключ валидатора может инициировать выход, что означает, что если активный ключ утерян или валидатор делегирует задачи третьей стороне (например, стейкинговому сервису), владелец withdrawal credentials (фактический владелец средств) не может самостоятельно контролировать стейкинг ETH. Это предложение позволяет инициировать выход и вывод ETH через исполнительный уровень, используя withdrawal credentials, без необходимости активного ключа.
5. EIP-7251 (увеличение лимита стейкинга): увеличивает максимальный эффективный баланс валидатора, позволяя каждому валидатору держать более 32 ETH в стейкинге, при этом минимальный порог остаётся 32 ETH. Это позволит крупным операторам узлов объединять несколько валидаторов, уменьшая их общее количество в сети, что снизит нагрузку на P2P-сообщения, агрегацию подписей и хранение данных.
6. EIP-7549 (вынос индекса комитета из доказательства): вынос поля индекса комитета из сообщения Attestation (доказательства) для более эффективной агрегации голосов консенсуса. В текущем механизме консенсуса Ethereum каждый валидатор голосует с помощью: LMD GHOST-голосования (с корнем блока и слотом), Casper-FFG-голосования (с исходной и целевой информацией), индекса комитета (номер комитета валидатора). Поскольку индекс комитета включён в подписанное сообщение, даже если несколько валидаторов голосуют за один и тот же блок, их подписи различаются, что затрудняет агрегацию. Вынос индекса комитета из подписанного сообщения позволяет более эффективно агрегировать голоса, снижая затраты на валидацию и нагрузку на сеть.
7. EIP-7685 (универсальные запросы исполнительного уровня): определяет универсальную структуру для исполнительного уровня (EL) для хранения и обработки запросов, инициируемых смарт-контрактами. Эта структура поддерживает большее количество действий, инициируемых исполнительным уровнем, и позволяет обрабатывать различные типы запросов единообразно, упрощая добавление новых типов без изменения структуры блока исполнения.
8. EIP-7702 (добавление возможности выполнения кода для EOA): добавляет функцию выполнения кода для externally owned accounts (EOA), повышая их гибкость и программируемость. EOA могут с помощью авторизованной подписи назначать смарт-контракт для выполнения определённых операций, например, пакетных транзакций или контроля доступа. Это даёт EOA некоторые функции смарт-контрактов без необходимости превращаться в полноценный контрактный аккаунт.

Ключевые EIP, находящиеся в рассмотрении

Ниже приведены некоторые активно рассматриваемые EIP, которые в основном оптимизируют работу с blob, повышая стабильность стоимости публикации данных L2, увеличивают пропускную способность L2 и эффективно снижают их издержки. Кроме того, изменение стоимости calldata может повлиять на объём сжигаемого ETH и увеличить инфляционное давление на ETH.

• EIP-7742 (разделение подсчёта blob между уровнем консенсуса и исполнительным уровнем): отделяет количество blob между уровнем консенсуса и исполнительным уровнем, упрощая процесс верификации blob, снижая избыточную сложность и повышая масштабируемость и гибкость протокола. В текущем протоколе оба уровня жёстко задают максимальное количество blob, что приводит к избыточной валидации. Это предложение отменяет проверку максимального значения blob на исполнительном уровне, вместо этого уровень консенсуса динамически предоставляет целевое значение blob исполнительному уровню. Это позволяет более гибко настраивать параметры blob для будущих потребностей масштабирования. EIP-7742 — одно из наименее спорных предложений, рассматриваемых для включения в обновление. Согласно последнему собранию уровня консенсуса, разработчики согласились начать реализацию EIP-7742 в pectra-devnet 5, однако его окончательное включение зависит от обратной связи исполнительного уровня на ACDE (All Core Developers Execution Layer Meeting).
• EIP-7762 (минимальная базовая комиссия за blob): увеличивает MIN_BASE_FEE_PER_BLOB_GAS с целью ускорить достижение разумного уровня цен на blob. В настоящее время минимальная базовая комиссия за blob установлена на уровне 1 wei, и когда спрос на blob превышает предложение, процесс формирования цены (определение справедливой стоимости blob Gas) слишком медленный, требуется много времени для достижения подходящего уровня комиссии. Повышение минимальной базовой комиссии за blob позволит быстрее корректировать цену и быстрее достичь рыночного равновесия, обеспечивая стабильность сети в периоды пикового спроса.
• EIP-7623 (увеличение стоимости calldata): увеличивает стоимость calldata в транзакциях, чтобы уменьшить максимальный размер блока и диапазон его изменений, обеспечивая более стабильную обработку транзакций сетью. В настоящее время максимальный размер блока составляет около 1,79 МБ, но из-за массовой публикации данных такими приложениями, как rollups, средний размер блока постоянно растёт. Увеличив стоимость calldata, которая в основном используется для транзакций, связанных с доступностью данных (DA), максимальный размер блока будет уменьшен до примерно 0,72 МБ, что освободит место для увеличения лимита Gas блока или большего количества blob в будущем. Стоимость обычных пользовательских транзакций не изменится, это изменение в первую очередь затронет транзакции, использующие Ethereum для массового хранения данных. Однако увеличение стоимости calldata может снизить конкурентоспособность Ethereum в сфере хранения данных. Кроме того, увеличение стоимости calldata и возможное снижение количества транзакций приведёт к уменьшению объёма ETH, сжигаемого по механизму EIP-1559, что усилит инфляционное давление на ETH.
• EIP-7782 (сокращение времени slot): сокращает время slot в Ethereum с 12 до 8 секунд, что позволит чаще создавать блоки и обрабатывать больше транзакций, рассматривается как альтернатива увеличению количества blob для повышения пропускной способности. Однако это может нарушить работу некоторых смарт-контрактов, где жёстко задано время slot в 12 секунд, а также ускорить проблему роста состояния Ethereum, увеличив нагрузку на хранение и вычисления.
• EIP-7783 (постепенное увеличение лимита Gas блока): более мягкая альтернатива EIP-7782, предусматривающая динамическую корректировку лимита Gas блока для постепенного увеличения количества транзакций в каждом блоке и повышения пропускной способности сети. В отличие от прямого сокращения времени slot, постепенная корректировка лимита Gas позволяет более плавно масштабировать сеть. Для этого предложения не требуется хардфорк, но оно может повлиять на состояние данных.

Поскольку обновление Pectra включает большое количество EIP, чтобы снизить сложность одного обновления и ускорить внедрение некоторых EIP, в мае инженерная команда Ethereum Foundation EthPandaOps предложила разделить Pectra на две части, но тогда опасались задержки обновления, поэтому предложение не было принято всерьёз. В сентябре исследователь Ethereum Alex Stokes вновь предложил разделение, и на этот раз разработчики поддержали идею, поскольку это поможет завершить первую часть обновления в течение шести месяцев:

• Первая часть: включает EIP, уже работающие в тестовой сети Pectra Devnet (то есть 8 утверждённых EIP), которые относительно легко реализовать и которые уже прошли множество тестов.
• Вторая часть: более сложные EIP (например, PeerDAS, предложения, связанные с EOF) и другие предложения, требующие большего времени на тестирование, будут реализованы на втором этапе. Эти предложения требуют дальнейшей разработки, аудита и тестирования, особенно если они затрагивают координацию между уровнем консенсуса и исполнительным уровнем.