На прошлой неделе чуть более 100 основных разработчиков Эфириума собрались за Полярным кругом — в Лонгйире, на Шпицбергене — на Soldøgn Interop: неделю интенсивной работы над обновлением сети Гламстердам.
Soldøgn последовал за прошлогодним Berlinterop, но вернулся к формату, использовавшемуся на Amphora 🏺, Edelweiss 🏔️ и Nyota ✨: однопоточная неделя сфокусированной работы над несколькими клиентами для достижения прогресса в конкретном обновлении — в данном случае, укреплении Гламстердам.
К пятнице группа достигла трех своих основных целей: согласование минимального лимита газа в 200 млн после обновления Гламстердам, стабильные реализации ePBS, работающие с внешними сборщиками, и окончательное утверждение цифр переоценки EIP-8037. Также был достигнут значительный прогресс в функциях Hegotá, таких как FOCIL и нативная абстракция учетной записи, а также во множестве других тем.
Почему Шпицберген?
Шпицберген — одно из немногих мест на Земле, где любой человек, независимо от гражданства, может жить и работать без визы. Здесь также находятся Всемирное семенохранилище (Global Seed Vault) и Арктический мировой архив (Arctic World Archive) — два хранилища холодного типа, прорубленные в вечной мерзлоте недалеко от Лонгйира. В них хранятся резервные копии сельскохозяйственных культур, книг, фильмов, рукописей и исходного кода, которые могут понадобиться человечеству через тысячу лет, включая снимок исходного кода Эфириума. И последнее, но не менее важное: с конца апреля по август на Шпицбергене не заходит солнце. У него аптайм 24/7, прямо как у Эфириума, чем основные разработчики и воспользовались по максимуму в течение недели!
Укрепление Гламстердам, масштабирование Эфириума
Целью недели было укрепление реализаций Гламстердам и определение целевого минимального лимита газа после обновления. Безопасное повышение лимита газа — это многомерная проблема, и Гламстердам решает несколько из них: как собираются и предлагаются блоки, какой запас производительности имеют реализации клиентов под нагрузкой, и как затраты на создание состояния масштабируются вместе с пропускной способностью.
На практике это означало завершение недели со стабильной мульти-клиентской сетью для разработчиков Гламстердам, работающей с новейшими спецификациями ePBS, переоценки и списков доступа к блокам, а также с данными бенчмаркинга для обоснования надежного предложения по лимиту газа.
Большую часть времени участники усердно писали код, часто до раннего утра, прерываясь на секционные заседания для согласования проектных решений и обсуждения пунктов долгосрочной дорожной карты.
Три команды Ethereum Foundation (EF) обеспечивали инфраструктуру в течение недели: EthPandaOps выпустили ethIQ и MCP-сервер panda для поддержки агентных рабочих процессов команд; Protocol Support настроили soldogn.xyz как единый источник достоверной информации о целях, расписании и заметках interop; а команда EF Digital Studio запечатлела неделю на видео. Ждите самый первый документальный фильм об interop 🔜!
ePBS
Помимо наведения порядка в отношениях между предлагающим и сборщиком, ePBS реструктурирует слоты, добавляя дедлайны для создания блоков, раскрытия полезной нагрузки и аттестаций. Это делает явным то, сколько времени может быть выделено на исполнение, увеличивая запас, который у нас есть для повышения лимита газа.
Команды начали неделю с целью запустить сеть для разработчиков Гламстердам с 4 клиентами уровня исполнения (EL) и 4 клиентами уровня консенсуса (CL) к вечеру понедельника. Первые попытки выявили достаточно проблем, чтобы перенести цель на вторник, когда конфигурация 4×3 заработала достаточно стабильно для начала стресс-тестирования.
С этого момента остаток недели представлял собой цикл укрепления ePBS: стресс-тест, выявление крайних случаев, исправление, повторение. Секционное заседание по Builder API во вторник утром существенно упростило спецификацию в части регистрации валидаторов, потока ставок/заголовков/обязательств, модели доверия для платежей сборщикам и поведения автоматического выключателя (circuit-breaker). Отладка в середине недели была сосредоточена на кросс-клиентских крайних случаях — в частности, на аннулировании запросов beacon chain запросами на исполнение, где новый набор тестов выявил пробел в каждой реализации клиента. К утру четверга команды CL сообщали о стабильном ePBS, в то время как пути ставок на стороне EL все еще отлаживались; эти проблемы были решены с четверга на пятницу. Два вопроса остаются по-настоящему спорными для звонков AllCoreDevs (ACD): должна ли подпись запроса фиксировать получающего сборщика, и как сохранить устойчивость дизайна сборщика со стейком в 1 ETH к атакам Сивиллы в P2P-сети, направленным на живучесть (liveness).
К пятнице почти все клиенты работали вместе на glamsterdam-devnet-2, а конвейер внешних сборщиков был протестирован от начала до конца!
Оптимизации BAL
Если ePBS — это часть истории масштабирования Гламстердам на уровне консенсуса, то аналог на уровне исполнения имеет две основные составляющие: переоценка газа и списки доступа на уровне блока (Block-Level Access Lists, BAL). Предоставляя клиентам достаточно информации о наборе чтения/записи блока заранее, BAL обеспечивают параллельное исполнение, пакетирование ввода-вывода и параллельное вычисление корня состояния, что в совокупности определяет, насколько большой блок клиенты могут комфортно обрабатывать.
Направление BAL на Soldøgn работало в собственных сетях для разработчиков, отдельно от цепочек ePBS Гламстердам, поэтому бенчмарки оптимизации не переплетались с работой по стабилизации уровня консенсуса. Каждая оптимизация находилась за собственным флагом функции, чтобы в ходе измерений на этой неделе их можно было сравнивать изолированно, а не в едином пакете. Дашборд бенчмарков BAL и таблица лидеров выявили наихудшие сценарии каждого клиента во всем наборе тестов — сосредоточившись на ускорении самых медленных путей в первую очередь, команды смогли поднять минимальный лимит газа по всем направлениям, а не только для самой быстрой реализации.
Переоценка газа
Гламстердам включает в себя ряд переоценок газа на уровне исполнения (EL), калибруя затраты для лучшего соответствия использованию ресурсов при более высокой пропускной способности. В основе лежит EIP-8037, увеличение стоимости газа для создания состояния: оно повышает цену записи нового состояния, чтобы более высокий лимит газа не приводил к неограниченному росту состояния.
Перед началом Soldøgn спецификация 8037 содержала динамическое ценообразование за байт состояния, привязанное к лимиту газа блока, что делало тестирование комбинаторно болезненным (одна матрица фаззинга на каждый диапазон лимита газа), а бенчмаркинг — почти невыполнимым. В начале недели команды договорились отказаться от динамического ценообразования в пользу фиксированного cost_per_state_byte, при этом будущая переоценка будет осуществляться на границах форков, а не внутри форка.
Сама модель учета пошла по более итеративному пути. На секционном заседании в понедельник учет газа состояния был перенесен с середины исполнения на конец фрейма вызова; во вторник были закрыты вопросы стоимости создания аккаунта, стоимости депозита кода и отмены транзакций CREATE; в среду всплыли крайние случаи возврата/пополнения резервуара, которые заставили переосмыслить подход. На заседании в четверг учет был возвращен на уровень кодов операций (opcode), поскольку был сделан вывод, что реальная сложность кроется в модели резервуара, а не в вычислении учета. К пятнице спецификация стабилизировалась на bal-devnet-6, а направление BAL предоставило окончательные цифры переоценки.
Вся эта история подчеркивает один из самых важных аспектов interop: способность решать сложные проблемы спецификаций, реализации, тестирования, отладки и проектирования за часы, а не за недели. В лучшем случае недели interop могут сжать месяц асинхронного прогресса в каждый день!
К пятнице три направления сошлись на главной цифре недели: надежном минимальном лимите газа в 200 млн после обновления Гламстердам. Это значительное увеличение возможно, потому что ePBS структурирует слот так, чтобы дать исполнению больше времени, оптимизации BAL дают клиентам запас пропускной способности в рамках этой структуры, а 8037 гарантирует, что более высокий лимит газа не приведет к неконтролируемому росту состояния.
Другие направления Гламстердам
Помимо ePBS, BAL и переоценок, большая часть оставшегося объема работ по Гламстердам была детально обсуждена на секционных заседаниях.
Команды CL окончательно утвердили решения по более мелким EIP для Гламстердам: EIP-8061 (увеличение оттока при выходе/консолидации) был включен в glamsterdam-devnet-1; EIP-8080 (выходы через очередь консолидации) был отклонен для включения; EIP-8045 (снятие обязанностей с валидаторов, подвергшихся слэшингу) был сужен только до обязанностей предлагающего в рамках окна предвидения (look-ahead window); а EIP-7688 (стабильные контейнеры SSZ) остается в рамках Гламстердам, но не включен в glamsterdam-devnet-1, пока команда прорабатывает ограниченный размер gossip-сообщений для аттестаций в условиях прогрессивных списков.
На утреннем заседании в среду по архитектуре синхронизации EL/CL было решено отложить EIP-8237 из Гламстердам в пользу сохранения возможности для более долгосрочной архитектуры «top-up sync» в будущем форке. Вместо этого участники договорились подготовить проект EIP, который нормализует последовательность forkchoiceUpdated / newPayload / getPayload, определяет рукопожатие (handshake) для инициации snap-синхронизации и ужесточает согласованность valid/invalid между поверхностями engine API.
Укрепление было постоянной темой недели. На сессии в четверг обсуждались фреймворки для тестирования соответствия правилам выбора форка (fork-choice), репозиторий Diamond с воспроизводимыми сценариями крайних случаев CL, а также buildoor — инструмент PandaOps для тестирования внешних сборщиков, который был продемонстрирован в середине сессии на длинном потоке сценариев атак, предложенных участниками прямо на месте.
За пределами Гламстердам
Несколько секционных заседаний были посвящены Hegotá и последующим форкам.
Начало положила намеренно независимая от конкретных предложений сессия по нативной абстракции учетной записи, на которой прорабатывались требования и ограничения, которым должен удовлетворять любой будущий дизайн. Цели набора функций, такие как альтернативные схемы подписи, агрегация, пакетирование, восстановление, спонсирование газа, гибкие nonce и кошельки-хранилища ключей, соседствовали с жесткими ограничениями, касающимися совместимости с публичным мемпулом, отсутствия состояния и устойчивости к DoS-атакам на уровне 2 (l2).
Заседание по FOCIL в четверг было сосредоточено на обновлениях реализации: ранние прототипы уже функционировали, а мульти-клиентский interop и выделенная сеть для разработчиков FOCIL стали ближайшими следующими шагами. Также были приняты два важных проектных решения: отключение FOCIL во время отсутствия финальности в течение 2 эпох (отражая поведение автоматического выключателя proposer-boost) и принятие подхода закладок на основе индексов для совместимости с транзакциями фреймов / EIP-7702.
Заглядывая дальше, долгосрочное направление ETH P2P наметило замену libp2p на базе QUIC с приватностью по умолчанию и интеграцией с учетом слотов, наряду с прототипом широковещательной рассылки с избыточным кодированием (erasure-coded), который смоделировал примерно в 6 раз более быстрое распространение, чем GossipSub, на полезных нагрузках в 2,4 МБ. Направление CL также выявило сильное желание в конечном итоге полностью отказаться от консолидаций — объявив финальный форк, который их поддерживает, а затем принудительно требуя выхода с последующим повторным депозитом — как более чистое долгосрочное решение проблемы роста состояния набора валидаторов.
Процесс ACD
В среду днем Никсо (Nixo) и Ансгар (Ansgar), два соруководителя ACDE, провели сессию для сбора мнений от основных разработчиков о процессе ACD. На сессии был пересмотрен конструкт хедлайнеров (headliner construct), обсуждались плюсы и минусы наличия черновой дорожной карты (strawmap) и были формализованы критерии EIP SFI. Аудитория в целом хотела сохранить хедлайнеров, но ослабить жесткость в отношении «EIP против темы», приняв «тема + кандидат EIP» как жизнеспособный паттерн. Распределение годов по форкам в черновой дорожной карте после 2026 года было отмечено как чрезмерно канонизированное и, вероятно, будет смягчено. Было выдвинуто новое определение SFI из четырех пунктов, при этом ACDT сигнализирует о готовности, а ACDE/ACDC оставляют за собой окончательное решение. Новый процесс определения приоритетов — создаваемый после решений CFI и отражаемый в мета-EIP — заменит старую роль SFI в стимулировании включения в сети для разработчиков, начиная с Hegotá.
Что касается координации звонков, Алекс Стоукс (Alex Stokes) объявил, что со следующей недели уходит в трехмесячный творческий отпуск (sabbatical), при этом Пари (Pari) временно возьмет на себя модерацию ACDC, а Барнабас (Barnabas) заменит его на ACDT. В итоге: Никсо и Ансгар председательствуют на ACDE, Пари временно исполняет обязанности на ACDC, а Марио (Mario), Барнабас и Danceratopz по очереди модерируют ACDT.
Все остальное
В дополнение ко всему вышесказанному, команды использовали время личных встреч для достижения прогресса во всем: от улучшения тестовых сред (сокращение циклов обратной связи Hive с часов до минут) до улучшений инфраструктуры engine-API (дедупликация gossip, пакетированные вызовы и обнаружение заголовков (head discovery), управляемое легкими клиентами), сложных компромиссов вокруг разнообразия клиентов и многих других тем. Полный список заметок с сессий доступен на soldogn.xyz.
Следующие шаги
Отсюда команды отправляются по домам, чтобы взять то, что было спрототипировано в течение недели, и довести это до готовности к продакшену. Ожидайте, что следующие несколько недель будут посвящены усердной работе над укреплением реализаций клиентов в соответствии с новыми спецификациями, завершению тестового покрытия и превращению черновых PR с Soldøgn в объединенный код.
Как всегда, окончательные решения по таким значениям, как целевой лимит газа в 200 млн и окончательные цифры переоценки, будут приняты и публично озвучены на звонках AllCoreDevs. Ожидайте, что это будут главные темы следующей недели!
Огромное спасибо всем, кто проделал весь этот путь до 78° с.ш. и сделал эту неделю успешной! Отдельная благодарность EthPandaOps за то, что каждый день держали группу в тонусе, и всем, кто работал под полуночным солнцем, чтобы убедиться, что мы достигаем наших ежедневных целей — включая команду Ethrex, присоединившуюся к нам на свой первый interop. Это была невероятно продуктивная неделя, и, к счастью, у нас будет полноценный короткометражный фильм, чтобы вспоминать о ней ☀️