Вызов ACDE 205 для Ethereum: крупные обновления Ethereum состоятся 24 февраля, 5 марта и 8 апреля

Разработчики Ethereum завершили расписание предстоящих обновлений сети. Крупные изменения должны произойти 24 февраля, 5 марта и 8 апреля. Ключевые решения были приняты во время недавнего вызова All Core Developers Execution (ACDE) 205, состоявшегося 13 февраля 2025 года.

Двухнедельная встреча в Zoom обсуждения проходила под руководством Тима Бейко, руководителя группы поддержки протоколов Ethereum Foundation (EF). Разработчики подтвердили, что обновление Pectra будет активировано на тестовой сети Holesky 24 февраля. После этого тестовая сеть Sepolia будет запущена 5 марта.

Если оба развертывания пройдут гладко, основная сеть Ethereum получит обновление около 8 апреля. 

Бейко сказал, что будет координировать действия с командами для поиска добровольца для развертывания системных контрактов Pectra на обеих тестовых сетях.

Дебаты о будущих форках Ethereum и скорости обновлений

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

Этот график позволяет разработчикам начать работу над Fusaka, одновременно планируя следующий хардфорк Glamsterdam. 

Команда разработки Geth не хочет работать с этим графиком. Они утверждают, что закрепление масштаба Fusaka было преждевременным. Включение предложения по улучшению Ethereum (EIP) EOF в Fusaka вызвало значительные дебаты. Группа разработчиков выступает за его исключение из предстоящего обновления.

EOF (Ethereum Object Format) — это обновлением инициатива, направленная на улучшение способа структурирования и выполнения смарт-контрактов в блокчейне Ethereum.

Разработчик Geth Lightclient выступил против ускорения заморозки масштаба Fusaka. Разработчик утверждает, что приоритеты Ethereum могут измениться в течение следующих двух лет. Он отметил, что, хотя разработчики стремятся к шестимесячным циклам обновлений, реальные задержки могут растянуть их до восьми месяцев или дольше. Это означает, что важные улучшения могут не быть реализованы в течение многих лет. 

Lightclient выразил обеспокоенность по поводу включения EOF, отметив быстрый прогресс технологии руллетов с нулевым разглашением Ethereum (zkEVM). Разработчики остаются в неведении относительно взаимодействия этих изменений с виртуальной машиной.

Во время обсуждения разработчик Geth Мариус ван дер Вейден перечислил свой предпочтительный масштаб для Fusaka, который включал PeerDAS, FOCIL, EOF и верхние границы для modexp. Инженер по операциям разработки EF Паритош Джаянти возразил, заявив, что FOCIL не так готов к реализации, как PeerDAS и EOF.

Обновления тестовых сетей Pectra и отзывы сообщества

Разработчики перешли от разногласий по поводу Fusaka к выражению уверенности в ongoing развертывании Pectra. Инженер по разработке и операциям EF Паритош Джаянти сообщил, что Pectra Devnet 6 работает хорошо, с почти идеальными показателями участия валидаторов. 

Кроме того, тестовая сеть Ephemery Ethereum активировала обновление Pectra через несколько часов после вызова ACDE, позволив разработчикам провести дополнительное тестирование.

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

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

Предложенный Бейко график завершения масштаба обновления Fusaka гласит, что к 13 марта разработчики должны предложить EIP для включения в обновление. Две недели спустя, 27 марта, команды клиентов поделятся своими предпочтениями относительно того, какие EIP следует рассмотреть для Fusaka. Наконец, к 10 апреля масштаб обновления будет окончательно определен.

Однако исследователь EF Ансгар Дитрихс добавил исключение к этому графику. Он отметил, что улучшения кода PeerDAS, критического компонента обновления Pectra, должны быть загружены в основную сеть Ethereum сразу после завершения. Никто не возражал против этого требования.

Обеспокоенность по поводу стандартов тестирования EELS и EIP

Еще одним пунктом обеспокоенности во время вызова ACDE стало предложение инженера тестирования EF Марио Веги. Это касалось фреймворка тестирования уровня выполнения Ethereum. Вега предложил сделать EELS (Спецификации уровня выполнения Ethereum) и EEST (Тестовые случаи спецификаций уровня выполнения Ethereum) обязательными для любого EIP, включенного в хардфорк. 

Он предположил, что это улучшит рабочий процесс тестирования и стандартизирует оценку EIP перед принятием.

Однако несколько разработчиков выступили против предложения. Причина? Это требование может замедлить процесс обновления. Ван дер Вейден утверждал, что сопровождающие EELS могут стать де-факто контролерами включения EIP. Почему? Не все разработчики способны писать реализации своих предложений на Python. 

Вейден предложил альтернативный подход. У ETH должны быть реализации EELS которые могут быть поданы как не слитые pull-запросы. Это предотвращает наличие у команды EELS окончательной власти утверждения над обновлениями.

Джастин Флорентин с блокчейне клиентом Besu посоветовал сообществу рассмотреть возможность создания дополнительного языка скриптов. Это прояснило бы, может ли EIP быть включен без тестовых случаев EELS или EEST.