Pectra — крупнейшее обновление сети Ethereum в 2025 году. Оно объединяет изменения исполнительного слоя (ветка *Prague*) и консенсус-слоя (ветка *Electra*) в один «комбо-хардфорк». Цели апгрейда: улучшить повседневный UX через эволюцию аккаунтов, упростить жизнь валидаторам и стейкинг-провайдерам, увеличить «пропускную способность данных» для роллапов и подтянуть низкоуровневые части протокола к будущим этапам (PeerDAS, Verkle и др.).
Главные эффекты Pectra:
- Аккаунты: появилось *программируемое поведение* обычных кошельков (через новый тип транзакции), что приближает Account Abstraction к массовому UX без миграции на контракт-кошельки.
- Стейкинг/валидаторы: консолидация балансов и удалённые выходы через EL делают операции проще и дешевле, уменьшают «избыточный» набор валидаторов.
- Масштабирование L2: больше «блобов» на блок, дороже «тяжёлое» calldata → L2 активнее используют «блобы», снижая нагрузку на сеть и стоимость данных.
- Низкоуровневые улучшения: предкомпилы BLS12-381, длинное окно блокхэшей «из состояния», новые форматы EL↔CL-запросов и оптимизации аттестаций.
Карточка
| Параметр | Значение |
|---|---|
| Название | Pectra = *Prague* (EL) + *Electra* (CL) |
| Дата активации (mainnet) | 07.05.2025, 10:05 UTC (эпоха 364032) |
| Ключевые области | Аккаунты / Стейкинг / Роллапы (данные) / Низкоуровневые оптимизации |
| Часть роадмапа | После Dencun; готовит к PeerDAS и Verkle |
| Полезно кому | Пользователям, разработчикам dApp/L2, валидаторам и стейкинг-сервисам |
| Связанные темы | Account Abstraction — удобные кошельки на смарт-контрактах, Роллапсы — оптимистические и zk: как это работает, Zeroknowledge, Kzg, Verkle tree — компактные доказательства состояния для «stateless» Ethereum* |
\* — «перспективные» страницы, дополняются.
TL;DR (коротко)
- Кошельки-EOA теперь могут временно вести себя как контракт в рамках транзакции → батчинг, спонсорство газа, гибкое восстановление без развёртывания полноценного смарт-аккаунта.
- Валидаторы получают max effective balance до 2048 ETH, «удаляемые» через EL-контракт выходы, упрощённые депозиты.
- Для L2 выросла ёмкость «блобов» на блок, а тяжёлое calldata подорожало, стимулируя «правильную» публикацию данных.
- Появился BLS12-381 предкомпил, длинное окно блокхэшей в состоянии, универсальные EL-запросы к CL, оптимизация аттестаций.
Что именно вошло в Pectra: 11 ключевых EIP
Ниже — «человеческий» разбор без криптоспека, с примерами последствий и перелинковкой на базовые темы в нашей вики.
1) EIP-7702 — «код для EOA» (гибрид к аккаунт-абстракции)
Идея: обычный адрес (EOA) может на время транзакции действовать как контракт согласно авторизации владельца. Это даёт поведение смарт-аккаунтов без миграции кошельков и без лома совместимости. Что это даёт пользователю/бизнесу:
- Батчинг (несколько действий за один газовый контекст),
- спонсорство газа (когда платит другой субъект),
- кастомные политики доступа/восстановления в рамках одной транзакции.
Как это соотносится с ERC-4337: 7702 — не замена, а «мост»: позволяет «привкус AA» для EOA и снижает трение онбординга. Для продвинутых сценариев и «постоянного» смарт-аккаунта 4337 остаётся актуален.
2) EIP-7251 — max effective balance = 2048 ETH
До Pectra: эффективный баланс валидатора = 32 ETH (и это же верхняя граница для начисления вознаграждений). Теперь: верх поднят до 2048 ETH. Практика:
- Легальнее и проще консолидировать десятки/сотни валидаторов в меньшее число,
- Меньше сетевых подписей → ниже сетевые накладные,
- Удобнее «компаундить» награды, а не плодить валидаторов из-за потолка 32 ETH.
3) EIP-7691 — больше «блобов» для L2
До: цель ~3 «блоба»/блок (максимум 6). После: цель ~6 (максимум 9) на блок. Смысл: роллапы получают бóльшую пропускную способность публикации данных. Это мост к будущему PeerDAS.
4) EIP-7623 — подорожание «тяжёлого» calldata
Зачем: когда в блоке много «блобов» и много calldata, p2p-сеть страдает по худшему сценарию. Изменение: «тяжёлые» по данным транзакции с calldata становятся дороже, что подталкивает L2 хранить данные в блобах. Обычные транзакции затронуты минимально.
5) EIP-7002 — «выход» валидатора из EL
Проблема: выход из стейкинга был привязан к ключу валидатора (CL-операция). Решение: появился EL-контракт, который может триггерить выход по withdrawal-credentials (без доступа к «горячему» валидаторскому ключу). Важность: упрощает операции пулами и протоколами стейкинга, снижает доверие к операторам.
6) EIP-6110 — депозиты валидаторов «на цепи»
Раньше: депозиты CL «получал» из EL посредством опросов/прокладок времён до Merge. Теперь: депозиты идут по единому каналу EL→CL, быстрее, безопаснее, без «долгой инициализации» при истории. Полезно для будущей history expiry.
7) EIP-2537 — предкомпил для BLS12-381
Что это: системный «контракт-ускоритель» для операций на кривой BLS12-381 (подписи и др.). Практика: дешевле и стандартизированнее проверять валидаторские подписи, строить мосты/лайтклиенты, оптимизировать ZK-конструкции в приложениях.
8) EIP-2935 — «длинные» блокхэши из состояния
До: BLOCKHASH отдавал ~256 последних блоков. Теперь: системный контракт хранит 8192 хэша в слотах хранилища. Зачем: удобнее для статлесс-исполнения, будущих Verkle, а также для L2/мостов, которым нужен бóльший горизонт истории.
9) EIP-7549 — оптимизация аттестаций
Перенос *committee index* из подписываемого сообщения → проще агрегировать и верифицировать голоса валидаторов; бонус — дешевле ZK-циркуиты для доказательств консенсуса.
10) EIP-7840 — «расписание блобов» в конфиге EL
EL-клиенты получают явные параметры графика блобов (target/max и правило фи), проще координировать L1↔L2-настройки без лишнего риска рассинхронизаций.
11) EIP-7685 — «универсальные запросы» EL↔CL
Зачем: нужен стандартный способ запрашивать из EL действия на CL (и наоборот). Что даёт: единый формат запросов в заголовке блока (хэш запросов), который CL обрабатывает. Практика: унификация логики депозитов/выходов/консолидаций и будущих функций стейкинга; фундамент для «разумных» взаимоотношений dApp ↔ стейкинг-слой.
Аккаунты и UX: как EIP-7702 меняет «кошелёк по умолчанию»
Проблема до Pectra: чтобы получить удобства AA (батчинг, газ-спонсорство, социальное восстановление), нужно было мигрировать на контракт-кошелёк, платить за развёртывание и совместимость, или использовать «глубокую» схему ERC-4337. Сейчас: EOA может на время транзакции «встать под код» выбранного контракта, сохраняя привычность EOA-модели и давая 90% ценности AA-UX без миграции. Ограничения/remarks:
- Политики безопасности и UX сильно зависят от реализации кошелька/провайдера.
- 7702 дополняет, а не отменяет «чистые» смарт-аккаунты: сложные сценарии, «перманентная» логика, платёжные политики на уровне протокола — всё это по-прежнему естественно в 4337-мире.
Стейкинг и валидаторы: меньше узлов — больше эффективности
MaxEB 2048 ETH: крупным стейкерам/пулами больше не надо дробиться на множество валидаторов ради доходности сверх 32 ETH. Это:
- Снижает накладные сети (меньше подписей/сообщений),
- Упрощает операционный контур и экономику узлов,
- Дает возможность тонко настроить размер валидатора «под себя» (эффективная сумма считается кратно 1 ETH, начиная с минимума 32).
Выходы через EL (7002): больше не требуется подпись «горячим» ключом валидатора — достаточно прав на withdrawal-адрес. Это избавляет пулы от множества правовых/операционных «перехватов» и уменьшает риски с ключами.
Депозиты «на цепи» (6110): быстрее онбординг, меньше «техдолга», лучше будущая совместимость с history expiry.
Масштабирование L2 и данные: блобы против calldata
Почему блобы важны: после Dencun L2 публикуют данные транзакций в «блобах» — это дешевле и предсказуемее, чем «жечь» calldata в L1. Что делает Pectra:
- Повышает цель/потолок «блобов» на блок (7691),
- Делает тяжёлое calldata дороже (7623), чтобы стимулировать L2 использовать блобы,
- Вносит конфиг блобов прямо в EL (7840), упрощая координацию.
Практика для разработчиков L2/dApp:
- Планируйте миграцию данных и пересчёт «газовой экономики» под блобы,
- Проверьте обработку blob-fee и ретрофит скриптов,
- Если вы делаете мост/индексатор — учитывайте длинное окно блокхэшей (2935) и предкомпил BLS (2537) для ускоренной верификации.
Низкоуровневые улучшения и их ценность для экосистемы
- BLS12-381 предкомпил (2537): облегчает проверку подписей валидаторов, улучшает мосты/лайтклиенты, полезен для ZK-схем и cross-domain логики.
- Длинные блокхэши (2935): помогают стэйтлес-исполнению и будущему переходу на Verkle, уже сейчас полезны для L2/мостов/индексации.
- Аттестации (7549): экономят ресурсы клиентов и ускоряют агрегирование консенсусных данных (включая генерацию ZK-доказательств консенсуса).
Для кого и что делать: чек-листы
Пользователи:
- Обновите кошелёк/провайдера, чтобы видеть корректный UX 7702 (батчинг/спонсорство).
- Помните: ETH «апгрейдить» не нужно — балансы и адреса продолжают работать как прежде.
- Если пользуетесь L2 — комиссии/скорость могут постепенно снижаться за счёт большей «ёмкости блобов».
Валидаторы/стейк-сервисы:
- Пересчитайте структуру валидаторов: консолидация до 2048 ETH снижает накладные и упрощает оперирование.
- Проверьте опер-плейбуки «выходов» через EL-контракт (7002) и депозитный пайплайн (6110).
- Актуализируйте мониторинг: метрики выходов, очередь на выход/вход, баланс blob-нагрузки.
Разработчики dApp/L2:
- Пройдите по API/SDK: поддержка нового типа транзакции под 7702; стратегия «газ-спонсорства» и батчинга.
- Пересоберите «data-путь»: минимизируйте calldata, опирайтесь на блобы, обновите расчёт фи, ретраи и алерты.
- Для мостов/лайтклиентов — используйте BLS-предкомпил и 8192-окно блокхэшей.
Типичные вопросы (FAQ)
Нужно ли «обновлять ETH/кошелёк»? Нет. Ваши активы остаются на том же адресе; вам нужна лишь обновлённая версия клиента/кошелька.
7702 = полный Account Abstraction? Нет. Это гибридный подход, который приносит часть возможностей AA в EOA-мир. Полноценные смарт-аккаунты (например, ERC-4337) остаются актуальны для продвинутых сценариев.
Кто выигрывает от 7251 (maxEB 2048 ETH)? Крупные стейкеры и пулы: меньше валидаторов — меньше накладных и проще эксплуатация. Для сети это экономия на «шумовых» сообщениях и более элегантная масштабируемость.
Почему подорожало «тяжёлое» calldata? Чтобы смещать публикацию данных L2 в блобы — это дешевле и здоровее для сети. Для обычных транзакций изменений почти нет.
Это «всё» по масштабированию? Нет. Pectra — ступенька: впереди PeerDAS и Verkle, где мы ожидаем дальнейший рост пропускной и упрощение узлов. См. PeerDAS* и Verkle*.
Хронология (опорные точки)
| Дата/время | Сеть | Событие |
|---|---|---|
| 24.02.2025 | Holesky | Активация Pectra на тестовой сети |
| 05.03.2025 | Sepolia | Активация Pectra на тестовой сети |
| 07.05.2025, 10:05 UTC | Mainnet | Активация Pectra (эпоха 364032) |
*Даты по тестовым сетям и точное время активации полезны для аудит-трейлов и ретроспектив.*
Смежные материалы в 24k Wiki
- Аккаунты/безопасность: Account Abstraction — удобные кошельки на смарт-контрактах, Erc 4337, Self-custody vs биржа.