Перейти к основному содержанию

Последнее обновление страницы: 26 февраля 2026 г.

Pectra

Апгрейд сети Pectra последовал за Dencun и внес изменения как в уровень исполнения, так и в уровень консенсуса Ethereum. Сокращенное название Pectra — это сочетание названий Prague и Electra, которые являются соответствующими названиями для изменений в спецификациях уровня исполнения и уровня консенсуса. В совокупности эти изменения вносят ряд улучшений для пользователей, разработчиков и валидаторов Ethereum.

Этот апгрейд был успешно активирован в основной сети Ethereum в эпоху 364032, 7 мая 2025 года в 10:05 (UTC).

Улучшения в Pectra

Pectra содержит самое большое количество предложений по улучшению Ethereum (EIPopens in a new tab) из всех предыдущих апгрейдов! В нем много незначительных изменений, а также несколько значительных новых функций. Полный список изменений и технических подробностей можно найти в отдельных включенных EIP.

Код аккаунта EOA

EIP-7702opens in a new tab представляет собой важный шаг на пути к широкому распространению абстракции аккаунта. С помощью этой функции пользователи могут настроить расширение своего адреса () с помощью смарт-контракта. EIP вводит новый тип транзакции с определенной функцией — позволить владельцам адресов подписывать авторизацию, которая настраивает их адрес на имитацию выбранного смарт-контракта.

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

Подробнее о EIP-7702 читайте здесь

Увеличение максимального эффективного баланса

Текущий эффективный баланс валидатора составляет ровно 32 ETH. Это минимальная необходимая сумма для участия в консенсусе, но в то же время и максимальная сумма, которую может внести в стейкинг один валидатор.

EIP-7251opens in a new tab повышает максимально возможный эффективный баланс до 2048 ETH. Это означает, что один валидатор теперь может вносить в стейкинг от 32 до 2048 ETH. Вместо сумм, кратных 32, участники стейкинга теперь могут выбрать произвольное количество ETH для стейкинга и получать вознаграждение за каждый 1 ETH сверх минимума. Например, если баланс валидатора благодаря вознаграждениям вырастает до 33 ETH, дополнительный 1 ETH также считается частью эффективного баланса и приносит вознаграждение.

Но преимущество улучшенной системы вознаграждений для валидаторов — это лишь часть данного улучшения. Участники стейкинга (Stakers), управляющие несколькими валидаторами, теперь могут объединить их в одного, что упрощает работу и снижает нагрузку на сеть. Поскольку каждый валидатор в сети Beacon отправляет подпись в каждую эпоху, требования к пропускной способности растут с увеличением числа валидаторов и большого количества подписей для распространения. Объединение валидаторов снизит нагрузку на сеть и откроет новые возможности масштабирования при сохранении того же уровня экономической безопасности.

Подробнее о maxEB читайте здесь

Увеличение пропускной способности blob-объектов

Blob-объекты обеспечивают доступность данных для L2-решений. Они были введены в предыдущем апгрейде сети.

В настоящее время сеть нацелена на среднее значение в 3 blob-объекта на блок с максимумом в 6 blob-объектов. С EIP-7691opens in a new tab среднее количество blob-объектов будет увеличено до 6, с максимумом в 9 на блок, что приведет к увеличению пропускной способности для ролл-апов Ethereum. Этот EIP помогает сократить разрыв до тех пор, пока PeerDASopens in a new tab не обеспечит еще большее количество blob-объектов.

Увеличение стоимости calldata

До введения blob-объектов в апгрейде Dencun L2-решения использовали calldata для хранения своих данных в Ethereum. И blob-объекты, и calldata влияют на использование пропускной способности Ethereum. Хотя большинство блоков используют лишь минимальное количество calldata, блоки с большим объемом данных, которые также содержат много blob-объектов, могут нанести вред p2p-сети Ethereum.

Для решения этой проблемы EIP-7623opens in a new tab увеличивает стоимость calldata, но только для транзакций с большим объемом данных. Это ограничивает размер блока в худшем случае, стимулирует L2-решения использовать только blob-объекты и не затрагивает более 99% транзакций.

Запускаемые выходы на уровне исполнения

В настоящее время выход валидатора и вывод ETH из стейкинга — это операция на уровне консенсуса, которая требует активного ключа валидатора, того же ключа BLS, который валидатор использует для выполнения активных обязанностей, таких как аттестации. Учетные данные для вывода — это отдельный «холодный» ключ, который получает выведенную долю, но не может инициировать выход. Единственный способ для участников стейкинга выйти — это отправить специальное сообщение в сеть Beacon, подписанное с использованием активного ключа валидатора. Это создает ограничения в сценариях, когда учетные данные для вывода и ключ валидатора принадлежат разным сущностям или когда ключ валидатора утерян.

EIP-7002opens in a new tab вводит новый контракт, который можно использовать для запуска выхода с помощью учетных данных для вывода на уровне исполнения. Участники стейкинга смогут вывести своего валидатора, вызвав функцию в этом специальном контракте, без необходимости иметь ключ подписи валидатора или доступ к сети Beacon. Важно отметить, что включение вывода валидаторов в сети (onchain) позволяет создавать протоколы стейкинга с меньшими требованиями к доверию по отношению к операторам узлов.

Депозиты валидаторов в сети

Депозиты валидаторов в настоящее время обрабатываются с помощью опроса eth1dataopens in a new tab — это функция в сети Beacon, которая извлекает данные с уровня исполнения. Это своего рода технический долг со времен до Слияния (The Merge), когда сеть Beacon была отдельной сетью и должна была учитывать реорганизации на основе доказательства выполнения работы (proof-of-work).

EIP-6110opens in a new tab — это новый способ доставки депозитов с уровня исполнения на уровень консенсуса, который позволяет мгновенно обрабатывать их с меньшей сложностью реализации. Это более безопасный способ обработки депозитов, встроенный в объединенный Ethereum. Это также помогает обеспечить перспективность протокола, поскольку для начальной загрузки узла не требуются исторические депозиты, что необходимо для истечения срока хранения истории.

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

Предварительно скомпилированные контракты (precompiles) — это особый набор смарт-контрактов, встроенных непосредственно в виртуальную машину Ethereum (EVM). В отличие от обычных контрактов, предварительно скомпилированные контракты не развертываются пользователями, а являются частью самой реализации клиента, написанной на его собственном языке (например, Go, Java и т. д., а не Solidity). Предварительно скомпилированные контракты служат для широко используемых и стандартизированных функций, таких как криптографические операции. Разработчики смарт-контрактов могут вызывать предварительно скомпилированные контракты как обычные контракты, но с большей безопасностью и эффективностью.

EIP-2537opens in a new tab добавляет новые предварительно скомпилированные контракты для операций с кривой BLS12-381opens in a new tab. Эта эллиптическая кривая стала широко использоваться в криптовалютных экосистемах благодаря своим практическим свойствам. В частности, она была принята на уровне консенсуса Ethereum, где ее используют валидаторы.

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

Предоставление исторических хэшей блоков из состояния

В настоящее время EVM предоставляет опкод BLOCKHASH, который позволяет разработчикам контрактов получать хэш блока непосредственно на уровне исполнения. Однако это ограничение распространяется только на последние 256 блоков и в будущем может стать проблемой для клиентов без сохранения состояния (stateless clients).

EIP-2935opens in a new tab создает новый системный контракт, который может предоставлять хэши последних 8192 блоков в качестве ячеек хранения. Это помогает обеспечить перспективность протокола для выполнения без сохранения состояния и становится более эффективным при внедрении деревьев Verkle. Однако, помимо этого, ролл-апы могут извлечь выгоду из этого уже сейчас, поскольку они могут запрашивать контракт напрямую с более длинным историческим окном.

Перемещение индекса комитета за пределы аттестации

Консенсус сети Beacon основан на голосовании валидаторов за последний блок и финализированную эпоху. Аттестация включает 3 элемента: 2 из них — голоса, а третий — значение индекса комитета.

EIP-7549opens in a new tab выносит этот индекс за пределы подписанного сообщения об аттестации, что упрощает проверку и агрегацию голосов консенсуса. Это повысит эффективность каждого клиента консенсуса и может значительно улучшить производительность схем с 0-знанием для доказательства консенсуса Ethereum.

Добавление расписания blob-объектов в файлы конфигурации EL

EIP-7840opens in a new tab — это простое изменение, которое добавляет новое поле в конфигурацию клиента уровня исполнения. Оно настраивает количество блоков, позволяя динамически устанавливать целевое и максимальное количество blob-объектов на блок, а также корректировать комиссию за blob-объекты. При наличии непосредственно определенной конфигурации клиенты могут избежать сложности обмена этой информацией через Engine API.

Повлияет ли этот апгрейд на все узлы и валидаторы Ethereum?

Да, апгрейд Pectra требует обновлений как клиентов исполнения, так и клиентов консенсуса. Все основные клиенты Ethereum выпустят версии, поддерживающие хард-форк, помеченные как высокоприоритетные. Чтобы обеспечить синхронизацию с сетью Ethereum после обновления, операторы узлов должны убедиться, что используют поддерживаемую версию клиента. Обратите внимание, что со временем информация о выпусках клиентов теряет актуальность, поэтому пользователям рекомендуется ознакомиться с последним обновлениям, чтобы оставаться в курсе.

Как конвертировать ETH после хард-форка?

  • Никаких действий с вашими ETH не требуется: после апгрейда Pectra в сети Ethereum не нужно конвертировать или обновлять ваши ETH. Балансы ваших счетов останутся прежними, а ETH, который вы сейчас держите, останется доступным в существующей форме после хард-форка.
  • Остерегайтесь мошенничества! Любой, кто поручает вам «обновить» ваш ETH, пытается вас обмануть. Вам не нужно ничего делать в связи с этим апгрейдом. Он никак не затронет ваши активы. Помните, что оставаться в курсе новостей — лучшая защита от мошенничества.

Подробнее о распознавании и предотвращении мошенничества

Больше увлекаетесь визуализацией?

Что войдет в апгрейд Pectra?Кристин Ким

Апгрейд Pectra в Ethereum: что нужно знать участникам стейкинга — Blockdaemon

Дополнительные материалы

Последнее обновление страницы: 26 февраля 2026 г.

Была ли эта статья полезной?