Обновление Pectra: зум-встреча девелоперов Эфира

13 февраля 2025 года разработчики протоколов Ethereum встретились в Зуме для проведения All Core Developers Execution (ACDE) Call #205. 

Звонки ACDE — это серия встреч раз в две недели, на которых разработчики обсуждают и координируют изменения Ethereum. 

На этой встрече разработчики подтвердили график обновлений публичной тестовой сети Ethereum. Команды планируют выпустить программное обеспечение, активирующее обновление Pectra в тестовых сетях Holesky и Sepolia, 24 февраля и 5 марта соответственно. 

Затем разработчики обсудили предложение Бейко заморозить масштаб следующего обновления Ethereum, Fusaka, к моменту запуска Pectra в мейннете Ethereum.

Предполагая, что обновление в публичном тестнете пройдет успешно, разработчики планируют запустить Pectra в мейннете Ethereum 8 апреля. 

Представители команды Geth выступили против предложения Бейко, заявив, что сроки замораживания масштабов Fusaka слишком поспешны, а один из EIP, уже включенных в Fusaka, EOF, должен быть исключен из обновления. Чтобы успокоить разработчиков Geth, Бейко предложил более длительный срок чтобы решить, какие EIP должны быть включены в Fusaka. Вместо двух недель Бейко предложил дать месяц на предложение новых EIP для форка Fusaka. Кроме того, Бейко отметил, что обсуждение оптимальной области применения Fusaka может проходить в асинхронном формате, при этом мнениями могут делиться отдельные члены команды Geth, а не коллективно вся команда.

Другой инженер подтвердил, что Pectra Devnet 6 «работает очень хорошо», а показатель вовлеченности валидаторов близок к идеальному. После чего Бейко подтвердил план обновления публичных тестовых сетей Ethereum Holesky и Sepolia 24 февраля и 5 марта соответственно. В рамках подготовки к этим обновлениям он сообщил, что будет асинхронно взаимодействовать с командами, чтобы найти добровольца для развертывания системных контрактов Pectra на обеих тестовых сетях. Инженер EF DevOps «Pk910» сообщил, что разработчики планируют активировать обновление Pectra раньше — всего через несколько часов после созвона 13 февраля — на тестовой сети Ethereum Ephemery. Ephemery — это эфемерная тестовая сеть Ethereum, которая ежемесячно сбрасывается на свой генезисный блок. Все релизы клиентов, кроме клиента Grandine, готовы к тестированию на Ephemery. 

Pectra Retrospective Форум и Fusaka

Pectra Retrospective уже более 20 дней доступен для публичных комментариев. По словам Бейко, наиболее популярное предложение на форуме — ускорить темпы обновлений Ethereum. В качестве решения он предложил начинать работу над следующим обновлением сразу после развертывания предыдущего в основной сети.

Разработчик под псевдонимом «Дастин» отметил, что каждое обновление Ethereum имеет фиксированные затраты, которые не связаны с работой по внедрению или тестированию. Например, экосистеме Ethereum требуется не менее 30 дней с момента последнего обновления публичной тестовой сети до развертывания основной сети. Только на обновление публичной тестовой сети уходит от двух до трех недель. Эти постоянные затраты не являются проблемой при попытке сократить периодичность обновления с одного года до шести месяцев. Однако они становятся проблемой, если пытаться обновлять Ethereum быстрее, чем раз в полгода.

После продолжительной дискуссии Бейко предложил следующий график завершения работы над Fusaka: 

• 13 марта: крайний срок для предложения EIP в Fusaka;
• 27 марта: команды клиентов делятся своими предпочтениями относительно того, какие EIP следует рассмотреть для включения в Fusaka;
• 10 апреля: крайний срок для завершения работы над Fusaka.

Дитрих добавил, что оговоркой к графику Бейко должно быть изменение кода PeerDAS PeerDAS — часть решений по масштабированию, связанная с шардингом данных (Data Availability Sampling). Многие считают, что PeerDAS критически важен, и хотят активировать как можно скорее. Возражений не последовало.

Обновления EOF 

Феррин рассказал о последних достижениях в области EOF. EOF — комплекс улучшений для виртуальной машины EVM, который позволит легче в будущем вносить изменения в байткод. Однако часть разработчиков считает, что введение EOF сейчас неоправданно, ведь zkEVM-решения стремительно развиваются, и неясно, насколько масштабная модификация EVM нужна в данный момент.

Lightclient написал несколько комментариев в чате, указывающих на то, что команда Geth придерживается мнения об удалении EOF из Fusaka.

«Мы не согласны с тем, что EOF вообще должен поставляться в мейннет, наша позиция заключается в том, чтобы EOF не было в форке», — написал Lightclient.  

Ван дер Вейден позже написал, что лично он не против EOF в Fusaka. Красюк отметил, что разработчики уже обсуждали включение EOF в Fusaka «множество раз». Однако Geth-команда высказывает возражения против включения EOF в Fusaka, потому что у них есть новые идеи, которыми они могут поделиться, но пока не сформулировали до конца единую позицию.

Требования к узлу валидатора 

Прикладной исследователь EF Кеваундрей Уэддерберн поделился новостями о своих усилиях по формализации требований к работе валидатора Ethereum. По словам Уэддерберна, все клиентские команды EL поддерживают идею создания флага, который позволит локальным блокчейн-конструкторам настраивать максимальное количество блобов, которые они будут включать в блок. Эта идея также была представлена командам по созданию блоков на последнем собрании Rollcall. Дитрихс сказал, что команды роллапов считают этот флаг «в меру удобным», но разумным, поскольку он помогает локальным блокчейн-конструкторам сохранять производительность на Ethereum. Далее Уэддерберн уточнил, что этот флаг будет использоваться только теми валидаторами, которые не согласны использовать сторонние блокчейн-конструкторы через ретрансляторы MEV-Boost. В связи с ограниченным временем разговора Уэддерберн сказал, что поднимет тему требований к локальным блокчейнам для обсуждения на следующем ACD-звонке.

Итог и дальнейшие шаги

Pectra:

• Holesky: 24 февраля.
• Sepolia: 5 марта.
• Mainnet (предварительно): 8 апреля.

Fusaka:

• Предложено приблизительно: до 13 марта внести EIP, до 10 апреля согласовать финальный список.

EOF:

• Оппоненты: часть команды Geth считает, что EOF стоит убрать или доработать, чтобы учесть влияние zkEVM.
• Сторонники: ряд разработчиков, которые хотят сделать EVM гибче.

Роль EELS/EEST:

• Идут споры, чтобы добавлять EIP только при наличии реализаций в Python (EELS) и соответствующих тестов (EEST).
• Автор инициативы (Вега) доработает Pull Request с учётом возражений, чтобы у команды EELS не было права «вето».

Финансирование и приоритеты:

Сообщество просит «ускорить апгрейды», но многие указывают на неизбежные логистические и временные затраты.

Таким образом, основной вектор предстоящих недель — успешный запуск Pectra на публичных тестовых сетях и подготовка к релизу на основной сети. Параллельно разработчики должны урегулировать спор по поводу включения EOF и PeerDAS в следующий апгрейд Fusaka, а также утвердить возможные новшества в процедуре добавления EIP (через EELS/EEST).

Ключевой вопрос: удастся ли согласовать компромисс между стремлением быстро выпускать обновления и необходимостью тщательно протестировать сложные EIP? Судя по накалу дискуссий, некоторые хотят форсировать события, в то время как другие считают подход «быстрее не значит лучше» более безопасным. Тем не менее, уверенное движение к Pectra на mainnet и активная работа над планом Fusaka подтверждают, что Ethereum не сбавляет оборотов в развитии своей Execution Layer.