Разработчики Ethereum завершили планирование предстоящих обновлений сети. Основные изменения запланированы на 24 февраля, 5 марта и 8 апреля. Ключевые решения были приняты во время недавней встречи All Core Developers Execution (ACDE) Call 205, состоявшейся 13 февраля 2025 года.
на встречах в Zoom, проводимых раз в две недели, Обсуждения вел Ethereum Foundation (EF). Разработчики подтвердили, что обновление Pectra будет активировано в тестовой сети Holesky 24 февраля. После этого, 5 марта, будет запущена тестовая сеть Sepolia.
Если оба этапа внедрения пройдут гладко, основная сеть Ethereumполучит обновление примерно 8 апреля.
Бейко заявил, что будет координировать действия с командами, чтобы найти добровольца для развертыванияtracсистемы Pectra в обеих тестовых сетях.
Дискуссии о будущих форках Ethereum и скорости обновления
Кроме того, команда разработчиков обсудила следующее запланированное обновление после Pectra и Fusaka. Бейко предложил заморозить масштабы Fusaka к моменту запуска Pectra в основной сети.
Этот график позволяет разработчикам начать работу над проектом Fusaka, одновременно планируя последующий хардфорк Glamsterdam.
Команда разработчиков Geth не хочет работать в рамках этого графика. Они утверждают, что было преждевременно определять масштабы Fusaka. Включение предложения по улучшению Ethereum (EIP) в EOF в Fusaka вызвало значительные дебаты. Часть разработчиков выступает за его исключение из предстоящего обновления.
EOF (Ethereum Object Format) — это обновление , направленное на улучшение структурыtracи исполнения смарт-контрактов в Ethereum .
Разработчик Geth, Lightclient, выступил против ускорения заморозки масштабов проекта Fusaka. Разработчик утверждает, что Ethereumмогут измениться в течение следующих двух лет. Он отметил, что, хотя разработчики стремятся к шестимесячным циклам обновления, реальные задержки могут растянуть их до восьми месяцев и более. Это означает, что важные улучшения могут быть внедрены только через несколько лет.
Компания Lightclient выразила обеспокоенность по поводу внедрения EOF, подчеркнув быстрый прогресс технологии роллапинга с нулевым разглашением (zkEVMs) в Ethereum. Разработчики по-прежнему не имеют представления о взаимодействии этих изменений с виртуальной машиной.
В ходе обсуждения разработчик Geth Мариус ван дер Вийден перечислил предпочтительные для Fusaka области применения, которые включали PeerDAS, FOCIL, EOF и верхние границы для modexp. Инженер по эксплуатации EF Паритош Джаянти возразил, заявив, что FOCIL не так готов к реализации, как PeerDAS и EOF.
Обновления тестовой сети программного обеспечения Pectra и отзывы сообщества
Разработчики уладили разногласия по поводу Fusaka и выразили уверенность в продолжающемся развертывании Pectra. Инженер по разработке и эксплуатации EF Паритош Джаянти сообщил, что сеть Pectra Devnet 6 работает хорошо, демонстрируя практически идеальный уровень участия валидаторов.
Кроме того, через несколько часов после звонка ACDE тестовая сеть EthereumEphemery активировала обновление Pectra, что позволило разработчикам провести дальнейшее тестирование.
Бейко попросил авторов Pectra EIP перенести свои предложения на этап «последнего звонка» в GitHub. Это сигнализирует о заключительных шагах перед внедрением в основную сеть. Он также изучил отзывы Ethereum . В связи с этим он отметил, что наиболее распространенным запросом было ускорение циклов обновления.
В ответ он предложил разработчикам Ethereum стремиться к завершению определения масштабов каждого обновления сразу после запуска предыдущего в основной сети.
компанией Beiko предложенному графику завершения работы над обновлением Fusaka, к 13 марта разработчики должны предложить пакеты EIP для включения в обновление. Две недели спустя, 27 марта, клиентские команды поделятся своими предпочтениями относительно того, какие пакеты EIP следует рассмотреть для Fusaka. Наконец, к 10 апреля объем обновления будет окончательно определен.
Однако исследователь EF Ансгар Дитрихс внес исключение в сроки. Он отметил, что улучшения кода PeerDAS, критически важный компонент обновления Pectra, должны быть загружены в основную сеть Ethereum сразу после их завершения. Никто не возражал против этого требования.
Обеспокоенность по поводу стандартов тестирования EELS и EIP
Ещё одним поводом для беспокойства во время обсуждения в рамках ACDE стало предложение инженера по тестированию EF Марио Веги. Оно касалось фреймворка тестирования уровня выполнения Ethereum . Вега предложил сделать обязательными EELS (спецификации уровня выполненияEthereum ) и EEST (тестовые примеры спецификаций выполненияEthereum ) для любого EIP, включенного в хардфорк.
Он предположил, что это улучшит процесс тестирования и стандартизирует оценку программ внедрения электронных знаний перед их принятием.
Однако несколько разработчиков выступили против этого предложения. Причина? Это требование может замедлить процесс обновления. Ван дер Вийден утверждал, что сопровождающие EELS могут стать фактическими привратниками включения EIP. Почему? Не все разработчики способны написать реализации их предложений на основе Python.
Вийден предложил альтернативный подход. В ETH должны быть реализации EELS , которые можно было бы отправлять в виде несовпадающих запросов на слияние. Это предотвратит предоставление команде EELS права окончательного утверждения обновлений.
Джастин Флорентин из компании Besu, работающей с Ethereum , посоветовал сообществу рассмотреть возможность создания дополнительного языка сценариев. Это позволило бы уточнить, можно ли включить EIP без тестовых примеров EELS или EEST.
