Одно сообщение о обновлении Ethereum Pectra: полная расшифровка всех EIP

?

Оригинал: Pectra: Следующее крупное обновление Ethereum

Автор ： Tanay Ved, Coin Metrics

Перевод ：GaryMa, 吴说区块链

Помимо перевода оригинала, в этой статье также представлены другие EIP Pectra, которые не были упомянуты в оригинале.

Ключевые моменты

Pectra — это следующее крупное обновление Ethereum, которое включает изменения в уровне исполнения (Prague) и уровне консенсуса (Electra). После ряда неудач с обновлением тестовой сети Pectra, окончательно решено активировать обновление основной сети Pectra около 10:05 UTC 7 мая.

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

Основные изменения включают: увеличение предела стейкинга для валидаторов, гибкие выводы стейка, улучшение абстракции аккаунтов и увеличение пропускной способности blob для повышения эффективности и безопасности сети.

Введение

С момента "Слияния" (The Merge) прошло 31 месяц, с момента обновления "Shapella" — 24 месяца, с момента обновления "Dencun" — 13 месяцев, и Ethereum готовится к следующему крупному обновлению — хардфорку Pectra.

Перед обновлением основной сети Pectra тестовая сеть прошла через множество испытаний.

Обновление Pectra тестовой сети Holesky было активировано 24 февраля в 21:55 UTC, однако было прервано из-за ошибки конфигурации клиентского программного обеспечения (неправильный адрес контракта депозита для Geth, Nethermind и Besu), что привело к разветвлению цепи. Разработчики обсудили планы по восстановлению сети через массовые штрафные события, направленные на ускорение выхода ошибочных валидаторов и достижение окончательности сети, что удалось реализовать только 11 марта.

Обновление Pectra тестовой сети Sepolia прошло по плану 5 марта, однако из-за проблем с конфигурацией пользовательского контракта депозита некоторые клиенты уровня исполнения (EL) столкнулись с аномалиями при включении транзакций в блоки, но проблема была быстро исправлена, и сеть достигла окончательности.

19 марта для тестирования выхода валидаторов была запущена новая тестовая сеть Hoodi, и 26 марта успешно активировано обновление сети Pectra.

Обновление тестовой сети Ethereum Pectra прошло через два месяца испытаний, подготовив путь для развертывания основной сети, окончательно решено активировать обновление основной сети Pectra около 10:05 UTC 7 мая.

Как и в предыдущих обновлениях Ethereum, Pectra включает изменения как в уровне исполнения (EL), так и в уровне консенсуса (CL). Его название отражает этот двойной акцент: Prague (Прага) представляет обновление уровня исполнения в честь места проведения Devcon 4; Electra (Электра) символизирует обновление уровня консенсуса.

Pectra является одним из хардфорков в истории Ethereum, который включает наибольшее количество EIP (Ethereum Improvement Proposals, предложения по улучшению Ethereum) — 11 EIP. Он дополнительно оптимизирует обновление Dencun прошлого года, направленное на улучшение пользовательского опыта (UX), оптимизацию работы валидаторов и продвижение масштабируемости второго уровня, что, как ожидается, окажет глубокое влияние на экосистему Ethereum.

В этой статье мы классифицируем и подробно анализируем каждое EIP по соответствующим областям.

Улучшения для валидаторов и механизма стейкинга

Pectra оптимизирует опыт работы валидаторов в системе PoS Ethereum с помощью трех основных EIP:

EIP-7251: Увеличение максимального эффективного баланса (MaxEB)

В настоящее время механизм стейкинга Ethereum ограничивает максимальный эффективный стейк для одного валидатора 32 ETH, что означает, что независимые стейкеры должны делать стейк в размере 32 ETH, а вознаграждения, превышающие этот лимит, не учитываются в эффективном стейке.

EIP-7251 предлагает увеличить максимальный эффективный баланс (MaxEB) до 2048 ETH, позволяя одному валидатору расширить диапазон стейка от 32 до 2048 ETH, что приведет к следующим последствиям:

· Повышение гибкости стейкинга: Стейкеры могут реинвестировать все доходы в эффективный баланс стейка, не ограничиваясь кратными 32 ETH. Например, валидатор, владеющий 33 ETH, теперь может получать вознаграждение за все 33 ETH, повышая эффективность и гибкость капитала.

· Снижение количества валидаторов: В настоящее время в Ethereum насчитывается 1,05 миллиона активных валидаторов, и этот EIP позволяет крупным операторам объединять своих валидаторов, снижая общее количество и уменьшая нагрузку на сеть.

· Снижение нагрузки на сеть: Хотя большее количество валидаторов способствует децентрализации, это также увеличивает нагрузку на полосу пропускания и вычисления. Увеличение MaxEB может оптимизировать пул валидаторов и снизить затраты на одноранговую связь.

EIP-7002: Вывод средств, инициируемый уровнем исполнения

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

В настоящее время у валидаторов есть два ключа:

1. Активный ключ, используемый для выполнения валидационных обязанностей;

2. Ключ вывода, используемый для доступа и управления стейковыми средствами.

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

· Большему контролю над средствами: Валидаторы могут напрямую управлять средствами, не полагаясь на операторов узлов.

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

EIP-6110: Хранение депозитов валидаторов в цепи

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

EIP-6110 позволяет уровню исполнения напрямую передавать информацию о депозитах на уровень консенсуса, сокращая дополнительные шаги валидации и уменьшая время активации валидаторов с примерно 9 часов до около 13 минут.

Увеличение возможностей масштабирования второго уровня: увеличение пропускной способности Blob

EIP-7691: Увеличение пропускной способности Blob

В прошлом году обновление Dencun ввело Blobs как эффективный способ хранения данных для rollup второго уровня. В настоящее время ежедневно на Ethereum подается около 21 000 Blobs, но емкость уже близка к пределу, что приводит к росту цен и ограничивает пропускную способность.

В настоящее время целевое количество Blobs на блок Ethereum составляет 3, максимум — 6. EIP-7691 предлагает увеличить целевое значение до 6, а максимальное значение до 9, чтобы увеличить емкость хранения данных и повысить пропускную способность и масштабируемость. Это снизит затраты на хранение данных, что, в свою очередь, уменьшит транзакционные сборы L2.

EIP-7623: Увеличение стоимости calldata

Перед введением механизма Blob L2 в основном использовал calldata для хранения данных и в некоторых случаях все еще использует его, так как это может быть более экономически выгодно.

EIP-7623 увеличивает стоимость calldata, чтобы стимулировать L2 в основном использовать blob для хранения данных, тем самым повышая эффективность транзакций rollup.

Улучшение пользовательского опыта (UX)

EIP-7702: Установка кода аккаунта EOA

Основная идея: временно наделить EOA функциями смарт-контракта

EIP-7702 вводит новый тип транзакции (обозначенный как 0x04), который позволяет внешним обладаемым аккаунтам (EOA) временно получать функции смарт-контракта в процессе выполнения транзакции. То есть, хотя традиционно EOA не имеет кода и может использоваться только для подписания транзакций, с помощью этого предложения EOA может "загрузить" код в одной транзакции, выполняя сложные операции, как смарт-контрактный кошелек.

Основные преимущества

1. Пакетные операции: Пользователи могут выполнять несколько операций в одной транзакции (например, комбинация approve + deposit), избегая неэффективности, связанной с необходимостью множества транзакций.

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

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

Возможные вызовы

· Проблемы совместимости с экосистемой: Поскольку EOA традиционно считается не имеющим кода, некоторые существующие смарт-контракты или проверки безопасности (например, require(tx.origin == msg.sender)) могут потребовать корректировок для адаптации к этому механизму временного наделения кодом.

· Увеличение сложности структуры транзакций: Введение нового типа транзакции потребует значительных изменений в кошельках и клиентах, чтобы гарантировать, что при обработке новых авторизационных кортежей и временной настройки кода не возникнет уязвимостей безопасности или дополнительных высоких затрат.

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

Другие EIP

EIP-7685: Универсальные запросы уровня исполнения

Контекст и цель

В настоящее время между Eth1 (уровень исполнения) и Beacon Chain (уровень консенсуса) необходимо обрабатывать три основных типа запросов:

1. Депозиты: События депозитов, инициируемые пользователями, изначально появляются в блоках Eth1, но в конечном итоге должны обрабатываться на Beacon Chain.

2. Выводы: Запросы на вывод, отправленные с Beacon Chain (обычно через инструменты командной строки), должны обрабатываться на Eth1.

3. Объединение валидаторов: Такие запросы также необходимо передавать между Eth1 и Beacon Chain.

Почему это предложение необходимо

В настоящее время различные типы операций передаются между двумя уровнями, что может привести к путанице. Единая обработка, предложенная EIP-7685, направлена на:

· Обработку всех этих запросов стандартным способом, что делает процесс более ясным и эффективным;

· Инициирование этих операций только с помощью Eth1, что позволяет разделить среду выполнения валидаторов и управление стейком, повышая безопасность.

Основные моменты

1. Идентификация типа запроса: Для каждого типа операции определены специфические идентификаторы, такие как уже существующие типы запросов на депозит и вывод, теперь добавляется также тип запроса на объединение.

2. Гарантия целостности: Будут использоваться некоторые механизмы (например, хэширование, меркелизация данных) для обеспечения целостности и безопасности данных запросов.

3. Очередь обработки и ограничение скорости: Для ожидающих обработки запросов будут установлены некоторые ограничения (например, количество одновременно ожидающих запросов на депозит, вывод или объединение), чтобы предотвратить перегрузку системы.

Конечное значение

Для обычных пользователей и разработчиков это означает, что в будущем инициировать операции по депозитам, выводам или объединению валидаторов можно будет быстрее и безопаснее через единый, стандартизированный процесс. Это не только повысит эффективность системы, но и поможет снизить общий риск.

EIP-2537: Предварительная компиляция для операций с кривой BLS12--381

Основная цель

Это предложение добавляет встроенные функции (называемые предварительными компиляциями) в Ethereum, специально предназначенные для обработки математических операций на кривой BLS12--381.

Почему нужна эта предварительная компиляция

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

· Более высокая безопасность: В отличие от используемой в настоящее время кривой BN254 (с безопасностью около 80 бит), кривая BLS12--381 предлагает безопасность около 120 бит, что делает криптографические операции более безопасными.

Основные применения

· Проверка подписей BLS: Подписи BLS позволяют агрегировать несколько подписей в одну, что значительно снижает вычислительные затраты на проверку.

· Проверка доказательств zkSNARK: В некоторых схемах защиты конфиденциальности и масштабируемости необходимо проверять доказательства zkSNARK, которые также зависят от сложных вычислений эллиптической кривой.

Практическое значение

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

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

EIP-2935: Сохранение хешей исторических блоков в состоянии

Текущая проблема

В Ethereum Virtual Machine (EVM) с помощью операции BLOCKHASH можно получить только хеши последних 256 блоков (примерно за 50 минут), что недостаточно для некоторых приложений, таких как кросс-цепочные приложения, требующие доказательства данных более ранних блоков, или безстатусные клиенты (например, rollup).

Суть предложения

EIP-2935 предлагает дополнительно сохранить хеши 8192 блоков в состоянии блокчейна (примерно за 27,3 часа), что значительно расширяет диапазон исторических данных блоков, доступных для запроса.

Как это реализовать

Помимо сохранения существующей операции BLOCKHASH, которая может получать доступ только к последним 256 блокам, предложение также введет новый системный контракт:

· Метод set(): При обработке каждого блока новый контракт автоматически сохранит хеш текущего блока в кольцевом буфере.

· Метод get(): Любой человек или смарт-контракт могут использовать этот метод для запроса хешей исторических блоков, хранящихся в кольцевом буфере.

Практические преимущества

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

EIP-7840: Добавление планирования blob в конфигурационный файл EL

Основная цель

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

Конкретные действия

· Добавление в конфигурационный файл настроек "целевое количество blob" и "максимальное количество blob".

· Одновременно добавление параметра baseFeeUpdateFraction для регулирования скорости обновления базовой комиссии.

· Клиенты могут запрашивать эти параметры через API узла, чтобы узнать текущее состояние сети по blob.

Почему это полезно

Эта информация поможет разработчикам и операторам узлов более точно оценить стоимость газа для blob, а также поможет сети лучше управлять планированием и обработкой больших данных в блоках.

В целом, EIP-7840 добавляет в уровень исполнения Ethereum набор настраиваемых параметров планирования blob, что делает сеть более эффективной и прозрачной при обработке больших данных (blob).

EIP-7549: Удаление индекса комитета из доказательства

Основная идея

В настоящее время сообщения о голосовании на подтверждение (Attestation) содержат три части:

· Голосование LMD GHOST (включает корень блока и временной интервал)

· Голосование Casper-FFG (включает source и target)

· Индекс комитета (index)

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

Решение, предложенное EIP-7549, заключается в том, чтобы удалить индекс комитета из подписанных сообщений голосования. Таким образом, только основное содержание голосования (голосование LMD GHOST и Casper-FFG) будет участвовать в вычислении подписи, позволяя нескольким валидаторам с одинаковым голосованием генерировать одинаковые корни подписей, что позволяет агрегировать их.

Основные преимущества

· Значительное снижение рабочей нагрузки для валидации: В существующих условиях для достижения консенсуса 2/3 может потребоваться проверить 1366 голосований. Удаление индекса комитета позволяет проверить только около 22 голосований (экономия примерно 62 раза в вычислениях), что значительно повышает эффективность процесса валидации, особенно для клиентов Casper FFG, основанных на нулевых знаниях.

· Повышение эффективности хранения данных на цепи: Поскольку информацию о голосовании можно более эффективно агрегировать, в каждом блоке можно упаковать больше голосований. В настоящее время блок может содержать только голосования за 2 временных интервала, после улучшения можно будет достичь максимума в 8 временных интервалов, даже если в сети онлайн только 1/8 предложителей, все голосования могут быть включены в блок.

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

Заключение

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

Ссылки для справки:

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7600.md