Основные разработчики Ethereum спорят по поводу процесса и сроков Fusaka

Последняя встреча Ethereum All Core Devs была посвящена не только коду, но и процессу: обсуждалось, стоит ли придерживаться ранее заявленного 30-дневного окна между релизами клиента и первым форком тестовой сети, поскольку обновление Fusaka продвигается вперёд. Некоторые участники настаивали на подтверждении этого обязательства, чтобы инфраструктурные и прикладные команды имели время адаптироваться; другие выступали за гибкость, чтобы избежать задержек в более широком плане развития.

Дебаты развернулись на фоне смешанных результатов devnet. На Devnet-3 запланированное упражнение по нефинальности затянулось, по словам Barnabas Busa из команды Dev Ops. «Мы хотели провести примерно два дня, а сейчас уже пятый день», — отметил он, добавив, что участие сначала снизилось, а затем снова превысило 50%. Для достижения финальности требуется согласие более двух третей от общего эффективного стейка.

Для сравнения, отдельная тестовая сеть восстановилась быстро после координированного перезапуска: «Сеть восстановилась, думаю, за два часа», — сказал Busa. Это упражнение испытывает, как переменные взаимодействуют в реальном инциденте, что может помочь Ethereum восстановиться в кризисной ситуации.

Подробнее: Обновление Fusaka в Ethereum может быть отложено

С учетом исправлений, которые появятся в ближайшие дни, краткосрочный план — восстановить Devnet-3 до полного функционирования, повторно провести тест и затем запустить Devnet-5.

Однако главным камнем преткновения стала дисциплина планирования для публичных сетей. Lightclient подчеркнул существующее обещание: «Там сказано 30 дней до первого тестнета». Он предостерёг от изменения сроков ради удобства, основываясь на оценке core devs того, сколько времени нужно другим командам, не присутствующим на звонке.

Практический вопрос заключается в том, как улучшить ритм проведения хардфорков. Сокращение промежутков между тестами может ускорить форки, но увеличивает риск того, что последующие команды выпустят поспешные обновления. Контраргумент заключается в том, что затяжные процессы задерживают всё остальное в очереди, что может не понравиться более широкой сообществу Ethereum.

«Я не думаю, что мы должны выбирать сроки, исходя из того, чего хочет сообщество», — сказал Lightclient. — «Те, кто выпускает программное обеспечение, сказали, что им нужно 30 дней, чтобы предоставить качественное ПО, которым будет пользоваться сообщество».

Тем не менее, довольно напряжённый обмен мнениями склонился к соблюдению письменного процесса, если только заинтересованные стороны явно не попросят об изменении.

Также была выражена неудовлетворённость по поводу того, что один и тот же вопрос поднимается в каждом цикле. «Я считаю, что это очень плохой прецедент — постоянно менять решения», — сказал Lightclient, отметив, что разработчики приложений и L2 обычно не участвуют в core-звонках и рассчитывают на предсказуемые окна для планирования своих релизов.

На данный момент консенсус заключается в том, чтобы действовать так, будто 30-дневный буфер остаётся в силе, при этом активно собирая новые мнения, сказал координатор Tim Beiko. «Мы должны готовить расписание в соответствии с тем, что указано в [процессном] документе, и параллельно сверяться с заинтересованными сторонами, которых это касается». Если ускоренный вариант действительно получит широкую поддержку, группа формализует это письменно.