Минулого тижня трохи більше 100 основних контриб'юторів Етеріум зібралися за Полярним колом — у Лонг'їрі, Шпіцберген — на Soldøgn Interop: тиждень інтенсивної роботи над оновленням мережі Гламстердам.
Soldøgn відбувся після минулорічного Berlinterop, але повернувся до формату, який використовувався на Amphora 🏺, Edelweiss 🏔️ та Nyota ✨: однопотоковий тиждень цілеспрямованого мульти-клієнтського прогресу щодо конкретного оновлення — у цьому випадку, зміцнення Гламстердам.
До п'ятниці група досягла трьох своїх основних цілей: узгодження мінімального ліміту газу після Гламстердам на рівні 200M, стабільні реалізації 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 через запити на виконання, де новий набір тестів виявив прогалину в кожній реалізації клієнта. До ранку четверга команди CL повідомляли про стабільний ePBS, тоді як шляхи ставок на стороні EL все ще налагоджувалися; ці проблеми були вирішені з четверга на п'ятницю. Два питання залишаються дійсно спірними для ACD: чи повинен підпис запиту зобов'язувати до отримання будівельником, і як зберегти дизайн будівельника зі стейком в 1 ETH стійким до P2P-атак Сивілли на життєздатність (liveness).
До п'ятниці майже всі клієнти працювали разом на glamsterdam-devnet-2 з наскрізним тестуванням конвеєра зовнішніх будівельників!
Оптимізації BAL
Якщо ePBS — це частина історії масштабування Гламстердам на рівні консенсусу, то аналог на рівні виконання має дві основні складові: переоцінка газу та списки доступу на рівні блоку (Block-Level Access Lists, BAL). Надаючи клієнтам достатньо інформації про набір читання/запису блоку заздалегідь, BAL забезпечують паралельне виконання, пакетування вводу/виводу та паралельне обчислення кореня стану, що визначає, наскільки великий блок клієнти можуть комфортно обробляти.
Напрямок BAL на Soldøgn працював на власних девнетах, окремо від ланцюгів ePBS Гламстердам, тому бенчмарки оптимізації не перепліталися з роботою зі стабілізації рівня консенсусу. Кожна оптимізація знаходилася за власним прапорцем функції (feature flag), тому вимірювання протягом тижня могли порівнювати їх ізольовано, а не як єдиний пакет. Дашборд бенчмарків BAL та таблиця лідерів виявили найгірші сценарії кожного клієнта в усьому наборі тестів — зосередившись насамперед на прискоренні найповільніших шляхів, команди змогли підняти мінімальний ліміт газу для всіх, а не лише для найшвидшої реалізації.
Переоцінка газу
Гламстердам включає низку переоцінок газу на рівні виконання (EL), калібруючи витрати для кращої відповідності використанню ресурсів при вищій пропускній здатності. EIP-8037, збільшення вартості газу для створення стану, лежить в основі: воно підвищує ціну запису нового стану, щоб вищий ліміт газу не призводив до необмеженого зростання стану.
На початку Soldøgn специфікація 8037 містила динамічне ціноутворення за байт стану, прив'язане до ліміту газу блоку, що робило тестування комбінаторно болючим (одна матриця фаззингу на діапазон ліміту газу), а бенчмаркінг — майже неможливим. На початку тижня команди домовилися відмовитися від динамічного ціноутворення на користь фіксованого cost_per_state_byte, а майбутні переоцінки здійснювати на межах форків, а не всередині форку.
Сама модель обліку пішла більш ітеративним шляхом. На секційному засіданні в понеділок облік газу стану було перенесено з середини виконання на кінець фрейму виклику (call frame); у вівторок було закрито питання щодо витрат на створення акаунтів, витрат на депозит коду та скасування CREATE-транзакцій; у середу виявилися крайні випадки повернення/поповнення резервуару, які змусили переглянути підхід. На засіданні в четвер облік було повернуто на рівень опкодів, оскільки було зроблено висновок, що справжня складність полягає в моделі резервуару, а не в обчисленні обліку. До п'ятниці специфікація стабілізувалася на bal-devnet-6, а напрямок BAL надав остаточні цифри переоцінки.
Уся ця історія підкреслює один із найважливіших аспектів interop: здатність вирішувати складні питання специфікацій, реалізації, тестування, налагодження та дизайну за години замість тижнів. У найкращому випадку тижні interop можуть стиснути місяць асинхронного прогресу в кожен день!
До п'ятниці три напрямки зійшлися на головній цифрі тижня: надійний мінімальний ліміт газу після Гламстердам на рівні 200M. Це значне збільшення можливе завдяки тому, що 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 broadcast), який симулював приблизно в 6 разів швидше поширення, ніж GossipSub, на корисних навантаженнях розміром 2.4 МБ. Напрямок CL також виявив сильні настрої щодо остаточної відмови від консолідацій — оголошення фінального форку, який їх підтримує, а потім примусового виходу з подальшим повторним депозитом (exit-then-redeposit) — як більш чистої довгострокової відповіді на зростання стану набору валідаторів.
Процес 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. Загалом: Ніксо (Nixo) та Ансгар (Ansgar) головують на ACDE, Парі тимчасово виконує обов'язки на ACDC, а Маріо (Mario), Барнабас та Danceratopz по черзі модерують ACDT.
Усе інше
На додаток до всього вищезазначеного, команди використали час особистих зустрічей для досягнення прогресу в усьому: від кращих тестових середовищ (скорочення циклів зворотного зв'язку Hive з годин до хвилин) до покращень інфраструктури engine-API (дедуплікація gossip, пакетовані виклики та виявлення голови (head discovery), кероване легкими клієнтами), до складних компромісів щодо різноманітності клієнтів та багатьох інших тем. Повний список нотаток із сесій доступний на soldogn.xyz.
Наступні кроки
Звідси команди вирушають додому, щоб взяти те, що було спрототиповано протягом тижня, і підготувати це до продакшену. Очікуйте, що наступні кілька тижнів будуть присвячені зосередженій роботі над зміцненням реалізацій клієнтів відповідно до нових специфікацій, завершенню тестового покриття та перетворенню чорнових PR з Soldøgn на злитий код.
Як завжди, остаточні рішення щодо таких значень, як цільовий ліміт газу в 200M та остаточні цифри переоцінки, будуть прийняті та публічно оприлюднені на дзвінках AllCoreDevs. Очікуйте, що це будуть головні теми наступного тижня!
Велике дякую всім, хто приїхав аж на 78° північної широти і зробив цей тиждень успішним! Окрема подяка EthPandaOps за те, що щодня тримали групу в тонусі, і всім, хто працював під опівнічним сонцем, щоб переконатися, що ми досягаємо наших щоденних цілей — включаючи команду Ethrex, яка приєдналася до нас на свій перший interop. Це був неймовірно продуктивний тиждень, і, на щастя, у нас буде повноцінний короткометражний фільм, щоб згадувати про нього ☀️