На встрече также обсуждались приоритеты изменений кода в Prague/Electra, следующем обновлении хард-форка после Dencun.
Автор: Кристин Ким, вице-президент по исследованиям Galaxy
Составлено: Цинь Цзинь, Carbon Chain Value
4 января 2024 года разработчики Ethereum собрались на телеконференцию № 178 Zoom для всех основных разработчиков (ACDE). Телеконференция ACDE, обычно проводимая руководителем протокола Ethereum Foundation Тимом Бейко, представляет собой серию встреч, проводимых раз в две недели, на которых разработчики обсуждают и координируют изменения в уровне выполнения Ethereum (EL). Встреча на этой неделе была организована анонимным разработчиком Geth EL под псевдонимом Lightclient. Разработчики подтвердили следующие три общедоступные даты активации тестовой сети для обновления Канкун/Денеб (Денкун). Они также обсудили приоритеты изменений кода (EIP) в Праге/Electra, следующем обновлении хард-форка после Dencun.
Обновление Денкуна
Никаких конкретных обновлений по обновлению Dencun во время праздников не было. С момента последнего звонка ACDE 21 декабря команда клиента готовила новую версию для тестовой сети Goerli. Из-за предыдущих задержек в тестировании обновлений, вызванных Prysm, разработчик Geth Мариус ван дер Вейден попросил клиентскую команду Prysm предоставить обновленную информацию о ходе работы над новой версией. Разработчик Prysm Теренс Цао подтвердил, что команда Prysm подготовит новую версию хард-форка Goerli на следующей неделе. Однако версия для Goerli будет «предварительной» версией, что означает, что это не будет версия Prysm, рекомендованная для использования в основной сети Ethereum. После хард-форка Goerli команда Prysm планирует выпустить еще одну версию с определенными изменениями и обновлениями, которые пользователям рекомендуется запускать в основной сети и тестировать в тестовых сетях Sepolia или Holesky.
Хотя Цао заявил, что команду Prysm устраивает дата активации хард-форка Goerli 17 января, как обсуждалось в ACDE № 177, он предложил, чтобы даты активации хард-форка Sepolia и Holesky были определены после хард-форка Goerli. Начиная с ACDE #177, Тим Бейко, руководитель службы поддержки протоколов в Ethereum Foundation, предложил время форка общедоступной тестовой сети для трех общедоступных тестовых сетей Ethereum: Goerli, Sepolia и Holesky. Рекомендуемое время активации вилки следующее:
- Гёрли — 17 января 2024 г. — эра 231680 — отметка времени 1705473120
- Сеполия — 30 января 2024 г. — эра 132608 — временная метка 1706655072
- Холески — 7 февраля 2024 г. — эра 29696 — временная метка 1707305664
Lightclient спросил другие клиентские команды за пределами Prysm, согласны ли они с предложенным Бейко временем активации хард-форка Goerli. Все клиентские команды, участвовавшие в телеконференции (включая Geth, Lodestar, Lighthouse, Teku и Besu), подтвердили, что, по их мнению, сейчас подходящее время для выпуска релиза для операторов узлов Goerli не позднее следующей недели. Команда клиента Lighthouse отметила, что, поскольку они все еще тестируют некоторые сетевые функции своего клиента, выпущенная ими версия может быть предварительной версией, такой как Prysm.
Расхождение во временной шкале Денкуна
Затем Lightclient обсудил рекомендуемое время активации для тестовых сетей Sepolia и Holesky. Разработчик Prysm (псевдоним) под онлайн-ником «Potuz» предложил отложить определение дат обновления для двух последних тестовых сетей перед основной сетью. «Мы должны постараться не назначать дату сейчас, потому что с Герли дела могут пойти не так хорошо, и вернуться оттуда будет проблемой. Было бы легко добавить новую версию с правильной эпохой и не вносить никаких изменений. Было бы проще удалить версию и исправить ошибки. Это проблема. Это гораздо дольше, чем несколько недель», — сказал Потуз.
Lightclient подчеркнул, что клиентская команда не обязана выпускать новую версию в течение недели после хард-форка Goerli, поэтому, если проблема с обновлением Goerli не будет обнаружена 24 января или после этой даты, новую версию не обязательно удалять. Разработчик Geth Мариус ван дер Вейден заявил, что не видит ничего плохого в назначении дат тестовых сетей Sepolia и Holesky, поскольку разработчики могут изменить даты в любое время, если возникнут проблемы с Goerli.
Инженер DevOps Ethereum Foundation Барнабас Буса написал в чате Zoom, что, по его мнению, выпускать обновления для Sepolia и Holesky необходимо только после подтверждения нормальной работы новой версии Goerli. Разработчик Lighthouse, известный в Интернете под ником «Шон», согласился с этой точкой зрения. Он сказал, что разработчики могут установить «предварительную» дату хард-форка Sepolia, но им следует сначала увидеть прогресс Goerli до 30 января.
Потуз предложил добавить неделю тестирования между активациями хард-форка Goerli и Sepolia, по сути давая две недели на анализ вместо трех. Он сказал, что добавление недели тестирования позволяет версии клиента «впитаться» в течение нескольких дней, прежде чем команде клиента потребуется снова вырезать новую версию для следующего обновления тестовой сети. “Две недели - это слишком близко. Именно на это я и обращаю внимание”, - Потуз добавил, что если дистрибутив клиента Goerli будет полностью проанализирован и протестирован, между активацией хард-форка Sepolia и Holesky может пройти не три дня. Время выполнения работ - еженедельное.
Взгляды Потуза вызвали споры. Ансгар Дитрихс из Ethereum Foundation сказал, что время между активацией первой общедоступной тестовой сети обновления и активацией обновленной основной сети обычно является «крайним сроком» для разработчиков. Однако Дитрихс также отметил, что разработчикам следует более серьезно обсуждать желание продлить время между обновлениями тестовой сети в контексте хард-форка, а не только обновления Dencun. Дитрихс сказал: «Если кто-то хочет более длительного процесса, то нам следует обсудить это, когда у нас будет время, а не перед хард-форком».
Лайтклиент согласен с Дитрихсом, что если бы обсуждения проводились уже в октябре, разработчики, вероятно, были бы более терпимы к продлению графика тестовой сети Dencun. Lightclient сказал: Я думаю, что отчасти это связано с тем, что мы хотели провести обновление прошлой осенью, поэтому теперь, когда мы действительно пытаемся этого добиться, я думаю, что наш график должен быть немного более агрессивным.
Придерживайтесь позитивного графика
Основываясь на мнениях, высказанных разработчиками в ходе телеконференции, инженер Ethereum Foundation DevOps Паритош Джаянти предложил отложить обновление хардфорка Sepolia примерно на неделю и назначить дату хардфорка Sepolia 25 января после звонка ACDE по обновлению Goerli на встрече. Мариус ван дер Вейден возражал против того, чтобы полностью полагаться на призыв ACDE для пересмотра даты активации обновления тестовой сети. «Чего я действительно хочу избежать, так это того, что нам не придется делать еще один звонок всем основным разработчикам, чтобы подтвердить дату», — сказал он, добавив: «Я ненавижу делать еще один звонок всем основным разработчикам, просто чтобы сказать: «Хорошо, Sepolia теперь доступна». Все началось». Теперь нам придется подождать две недели, прежде чем мы сможем реально начать внедрение Sepolia.
Чтобы успокоить эмоции всех сторон, разработчик Geth Гийом Баллет предложил создать два набора предварительных дат хардфорка Sepolia. Если результаты хардфорка Goerli будут положительными, разработчики могут придерживаться одной из дат; если Goerli Результаты хард-форка. Результат форка отрицательный, и разработчик может использовать другой набор дат. Однако и Лайтклиент, и Дитрихс выступают против этой идеи, поскольку необходимо оценить природу ошибок и проблем Goerli, прежде чем разработчики смогут установить новый график хард-форка Sepolia.
Кстати, разработчик под псевдонимом «Danceratopz» из команды тестирования Ethereum Foundation спросил, хотят ли разработчики подождать, чтобы оценить проблему с истечением срока действия больших двоичных объектов в тестовой сети Goerli, прежде чем обновлять Sepolia. В качестве фона истечение срока действия больших двоичных объектов означает удаление данных больших двоичных объектов из состояния Ethereum примерно через две недели.
Шон из Lighthouse и Джастин Флорентайн из команды Besu предпочли оценить срок действия больших двоичных объектов в одной из трех тестовых сетей перед активацией Dencun в основной сети. Флорентин подчеркнул, что ожидание истечения срока действия больших двоичных объектов в тестовой сети также поможет команде протокола второго уровня Rollup и разработчикам приложений подготовиться к обновлению Dencun. Шон из Lighthouse сказал, что, хотя наблюдать за истечением срока действия BLOB-объекта на Goerli нет необходимости, это может быть причиной продлить период тестирования между Sepolia и Holesky, чтобы разработчики и команды второго уровня могли пройти весь жизненный цикл BLOB-объекта на Sepolia. Во время разговора другие разработчики не согласились с предложением Шона.
Вместо этого Lightclient спросил разработчиков на телеконференции, будут ли они придерживаться предложенного Бейко графика обновления Sepolia 30 января и Holesky неделей позже, 7 февраля. Поскольку разногласий среди разработчиков больше нет, Лайтклиент заявил, что разработчики будут придерживаться первоначального графика. Потуз написал в чате Zoom, что надеется обновить тестовые сети Sepolia и Holesky 7 февраля, а не обновлять первую неделю назад. В сообщении Discord после звонка Lightclient подтвердил, что расписание тестовой сети Dencun на данный момент остается неизменным.
Прага/Электра
Далее разработчики обсудили, какие EIP должны быть приоритетными для следующего обновления после Dencun (Прага/Электра). Мариус ван дер Вейден сказал, что разработчикам следует сосредоточиться на завершении обновления дерева Меркла в Праге/Electra, а не на других EIP. Он добавил к этой точке зрения два предостережения, первое из которых — готовность дерева Меркель. Как обсуждалось в ACDE #177, разработчики планируют специальный вызов ACDE, чтобы углубиться в детали реализации деревьев Меркла и их готовность к хард-форк-обновлениям.
Второе замечание, упомянутое Ван дер Вейденом, — это возможность отделить обновления EL от уровня консенсуса (CL). Ван дер Вейден упомянул, что на CL есть несколько «высокоприоритетных и сверхсрочных» EIP, которые, возможно, потребуется реализовать быстрее, чем обновление дерева Меркла на EL. «Я думаю, важно, чтобы люди на уровне консенсуса обсудили, нужно ли им проводить хард-форк этих [чрезвычайных] изменений, можно ли это сделать без участия EL или требуется участие EL, что нам в любом случае нужно. Проведите совместный хард-форк и тогда я смогу жить с меньшим хард-форком». «Поэтому дерево Меркель определенно является приоритетом, и мы должны добиваться его реализации, принимая во внимание эти две вещи», — сказал ван дер Вейден.
Исследователь Ethereum Foundation Ансгар Дитрихс написал в чате Zoom, что он «категорически против» сосредоточения обновления Праги/Электры на дереве Меркла из-за опасений по поводу Меркла. Сложность необходимых изменений кода, вероятно, будет означать, что обновление будет отложено до тех пор, пока 2025. Разработчик клиента Nethermind Лукаш Розмей согласен с Дитрихсом. «Мой опыт подсказывает мне, что перепроектирование государства очень сложно и занимает очень много времени», — сказал Розмей, добавив: «Хотя я считаю, что деревья Меркла очень хороши и достигнут большой прогресс, я думаю, что если мы просто сосредоточимся на Меркель, Следующий хардфорк состоится как минимум через год, если не дольше. в тему."
В центре внимания Меркель
Разработчики разделились во мнениях относительно того, следует ли Праге/Электре сосредоточиться на Меркель или отдать предпочтение более мелким изменениям кода, которые можно будет выпустить быстрее, чем Меркель. Баллет подчеркнул, что, по его мнению, «не существует незначительных форков», и чем дольше разработчики будут ждать перед внедрением Merkle, тем сложнее будет реализовать обновления состояния Ethereum. Томаш К. Станчак, также разработчик клиента Nethermind, предложил амбициозный подход, взяв на себя обязательство использовать больше EIP, чем Прага/Electra могла бы включить. [Давайте] воспользуемся возможностями нашей команды, и в этом году мы должны доказать, что можем справиться с нашими самыми большими задачами. Если Меркель, наконец, даст сигнал команде, что к марту будет накапливаться все больше и больше трудностей, тогда люди могут снова поднять вопросы и сказать: «Хорошо, Меркель ушла». Но мы продолжим использовать довольно хороший набор других EIP, которые мы включим, сказал Станчак, уточнив, что помимо Меркель, некоторые другие важные EIP, которые Прага/Электр может включить, например, связанные со ставкой, повторной ставкой и EIP связан с абстракцией учетной записи.
В ответ на вопрос Станчака Лайтклиен сказал, что разработчикам может быть сложно продолжать обсуждение того, какие EIP следует включить в Прагу/Электру после принятия набора EIP, и что один из EIP (имеется в виду Меркель) «тот, который проект требует от 18 до 24 месяцев». Эндрю Ашихмин, разработчик клиента Erigon, предпочитал выпустить меньший EIP в форке Prague/Electra, одновременно разрабатывая Merkle для использования в последующих форках. Балет поддержал предложение Станчака сосредоточиться на развитии Меркель в Праге/Электре и исключить ее из обновления, если при ее реализации будут обнаружены серьезные проблемы, для решения которых потребуется больше времени.
Сосредоточьтесь на обновлении CL
Что касается вопроса разделения обновлений EL (уровень выполнения) и CL (уровень консенсуса), Потуз упомянул, что у Праги/Electra есть только одно предложение EIP, которое требует внесения изменений только в CL. «Единственное изменение — это удаление Совета по индексу сертификации… и все остальные изменения, даже те, которые, кажется, затрагивают только CL, такие как Max EB, зависят от других изменений в EL. Поэтому я думаю, что чисто форк CL — это “Этого не произойдет. По крайней мере, я не думаю, что это произойдет в этом году, а не в следующем. У нас недостаточно чистых предложений CL”, - сказал Потуз.
Тем не менее, Ансгар Дитрихс сказал, что некоторые EIP представляют собой в первую очередь обновления, ориентированные на CL, которые требуют лишь незначительных изменений в EL и могут быть легко выполнены клиентской командой EL. Эти EIP по-прежнему требуют, чтобы EL и CL координировали хард-форк. Позже Дитрихс добавил, что, по его мнению, выборка доступности данных (DAS) была самым важным изменением кода после EIP 4844 с точки зрения CL. У Дитрихса и Lightclient есть некоторые разногласия по поводу того, требует ли DAS реализации хард-форка.
Следите за EOF и другими EIP
Разработчик под псевдонимом с онлайн-ником «Родиазет» работает в команде Ipsilon Ethereum Foundation, которая занимается исследованием виртуальной машины Ethereum (EVM). В качестве фона EOF означает формат объекта EVM, серию улучшений EVM, которые изначально рассматривались для включения в обновление Канкун/Денеб.
Помимо Merkle, разработчики также предложили на рассмотрение некоторые другие EIP, такие как EIP 5920 (код операции PAY) и EIP 2537 (предварительная компиляция операций кривой BLS12-381). Полный список EIP-кандидатов Праги/Электры можно найти в мета-теме обновления на веб-сайте Ethereum Magician. Хотя большинство разработчиков выступают за то, чтобы Меркель в некоторой степени была приоритетной после Канкуна/Денеба, неясно, в какой степени Меркель должна быть приоритетной для Праги/Электры по сравнению с теми, которые будут реализованы в 2024 году. Малые EIP, которые можно реализовать быстрее и проще. Lightclient подчеркнул, что разработчикам не нужно принимать окончательные решения по контенту Праги/Электры во время телефонной конференции на этой неделе. Он предложил продолжить эту тему на предстоящей телеконференции ACDE.
Затем разработчики быстро коснулись EIP в ветке Прага/Electra, которые еще не обсуждались на телеконференции, включая, помимо прочего, следующие EIP:
- EIP-7002: Уровень выполнения может инициировать выход
- EIP-7549: Переместить индекс комитета за пределы сертификации
- EIP-3074: коды операций AUTH и AUTHCALL
- EIP-6110: Обеспечить депозиты валидатора в цепочке
- EIP-6913: команда SETCODE
- EIP-7377: Транзакции миграции
- EIP-4444: Данные истории привязки в клиенте выполнения
- EIP-6404: Корень транзакции SSZ
- EIP-6465: Извлечение корня SSZ
- EIP-6466: корень получения SSZ
- EIP-7212: Поддержка кривых для предварительно скомпилированного secp256r1
Подробный обзор мнений по поводу вышеупомянутого EIP можно найти в полной записи разговора, размещенной на YouTube.
Официально подтвержденный EIP 7587
Наконец, исследователь Ethereum Foundation Карл Бикхуизен вернулся к обсуждению EIP 7587, который зарезервирует набор предварительно скомпилированных адресов для использования протоколами второго уровня. Бикхуизен спросил разработчиков, как лучше всего формализовать EIP в информационный EIP, который создаст нормы для будущих процессов управления Ethereum. Разработчик Nethermind Ахмад Битар предложил включить EIP в документ EIP 1, в котором изложены руководящие принципы процесса EIP. Lightclient рекомендует дополнительно обсудить эту тему на веб-сайте Ethereum Magician и вернуться к ней по мере необходимости во время следующего звонка ACDE.
