W minionym tygodniu nieco ponad 100 głównych współtwórców Ethereum zebrało się za kołem podbiegunowym — w Longyearbyen na Svalbardzie — na Soldøgn Interop: tydzień intensywnej pracy nad aktualizacją sieci Glamsterdam.
Soldøgn nastąpił po zeszłorocznym Berlinterop, ale powrócił do formatu używanego przez Amphora 🏺, Edelweiss 🏔️ i Nyota ✨: jednotorowego tygodnia skoncentrowanego, wieloklientowego postępu w kierunku konkretnej aktualizacji — w tym przypadku wzmocnienia Glamsterdam.
Do piątku grupa zrealizowała swoje trzy główne cele: porozumienie w sprawie dolnego progu limitu gazu po Glamsterdam na poziomie 200M, stabilne implementacje ePBS działające z zewnętrznymi budowniczymi oraz ostateczne zatwierdzenie liczb dotyczących zmiany wyceny w EIP-8037. Znaczący postęp osiągnięto również w zakresie funkcji Hegotá, takich jak FOCIL i natywna abstrakcja konta, a także w wielu innych tematach.
Dlaczego Svalbard?
Svalbard to jedno z niewielu miejsc na Ziemi, gdzie każdy, niezależnie od narodowości, może mieszkać i pracować bez wizy. Znajduje się tam również Globalny Skarbiec Nasion (Global Seed Vault) oraz Arktyczne Światowe Archiwum (Arctic World Archive), dwa obiekty chłodnicze wydrążone w wiecznej zmarzlinie poza Longyearbyen. Przechowują one kopie zapasowe upraw, książek, filmów, rękopisów i kodu źródłowego, których ludzkość może potrzebować za tysiąc lat, w tym zrzut kodu źródłowego Ethereum. Co nie mniej ważne, od końca kwietnia do sierpnia słońce na Svalbardzie nie zachodzi. Ma czas działania (uptime) 24/7, podobnie jak Ethereum, co główni deweloperzy w pełni wykorzystali w ciągu tego tygodnia!
Wzmocnienie Glamsterdam, Skalowanie Ethereum
Celem tygodnia było wzmocnienie implementacji Glamsterdam i wyznaczenie celu dla dolnego progu limitu gazu po aktualizacji. Bezpieczne podniesienie limitu gazu to wielowymiarowy problem, a Glamsterdam rozwiązuje kilka z nich: jak bloki są budowane i proponowane, ile zapasu mają implementacje klientów pod obciążeniem oraz jak koszty tworzenia stanu skalują się wraz z przepustowością.
W praktyce oznaczało to zakończenie tygodnia ze stabilną, wieloklientową siecią deweloperską Glamsterdam, na której działa najnowsze ePBS, specyfikacje zmiany wyceny i list dostępu do bloków, wraz z danymi z testów wydajnościowych, aby oprzeć na nich wiarygodną propozycję limitu gazu.
Większość czasu spędzono w skupieniu na pisaniu kodu, często do wczesnych godzin porannych, co było przerywane sesjami w podgrupach, aby uzgodnić decyzje projektowe i omówić długoterminowe elementy mapy drogowej.
Trzy zespoły EF zapewniły infrastrukturę na ten tydzień: EthPandaOps dostarczyło ethIQ oraz serwer MCP panda, aby wspierać oparte na agentach przepływy pracy zespołów; Protocol Support skonfigurowało soldogn.xyz jako jedyne źródło prawdy dla celów interop, harmonogramu i notatek; a zespół EF Digital Studio uwiecznił ten tydzień na filmie. Spodziewajcie się pierwszego w historii filmu dokumentalnego o interop 🔜!
ePBS
Poza uporządkowaniem relacji proponujący/budowniczy, ePBS restrukturyzuje sloty, dodając terminy na budowę bloku, ujawnienie ładunku (payload) i atestacje. To wyraźnie określa, ile czasu można przeznaczyć na wykonanie, zwiększając zapas, jaki mamy na podniesienie limitu gazu.
Zespoły rozpoczęły tydzień z celem uruchomienia sieci deweloperskiej Glamsterdam w konfiguracji 4 EL × 4 CL do poniedziałkowego wieczoru. Pierwsze próby ujawniły wystarczająco dużo problemów, aby przesunąć ten cel na wtorek, kiedy to konfiguracja 4×3 działała na tyle stabilnie, że można było rozpocząć testy obciążeniowe.
Od tego momentu reszta tygodnia była cyklem wzmacniania ePBS: testy obciążeniowe, ujawnianie przypadków brzegowych, naprawa, powtórka. Wtorkowa poranna sesja w podgrupach dotycząca Builder API znacznie uprościła specyfikację wokół rejestracji walidatorów, przepływu ofert/nagłówków/zobowiązań, modelu zaufania dla płatności budowniczych oraz zachowania wyłącznika awaryjnego (circuit-breaker). Debugowanie w środku tygodnia skupiło się na przypadkach brzegowych między klientami — w szczególności wokół unieważniania żądań beacon przez żądania wykonania, gdzie nowy zestaw testów ujawnił lukę w każdej implementacji klienta. Do czwartku rano zespoły CL zgłaszały stabilne ePBS, podczas gdy ścieżki ofert po stronie EL były nadal debugowane; problemy te rozwiązano między czwartkiem a piątkiem. Dwa pytania pozostają autentycznie sporne dla ACD: czy podpis żądania powinien zobowiązywać do odbioru przez konkretnego budowniczego, oraz jak utrzymać projekt budowniczego ze stawką 1 ETH odpornym na ataki na żywotność (liveness) oparte na Sybil w sieci P2P.
Do piątku prawie wszyscy klienci działali razem na glamsterdam-devnet-2, a potok zewnętrznych budowniczych został przetestowany od początku do końca!
Optymalizacje BAL
Jeśli ePBS jest stroną warstwy konsensusu w historii skalowania Glamsterdam, to jej odpowiednik w warstwie wykonawczej ma dwa dominujące elementy: zmiany wyceny gazu oraz Listy Dostępu na Poziomie Bloku (Block-Level Access Lists - BAL). Dając klientom z góry wystarczająco dużo informacji o zestawie odczytu/zapisu bloku, BAL umożliwiają równoległe wykonanie, wsadowanie wejścia/wyjścia (I/O) oraz równoległe obliczanie korzenia stanu, co ostatecznie determinuje, jak duży blok klienci mogą swobodnie obsłużyć.
Ścieżka BAL na Soldøgn działała na własnych sieciach deweloperskich, oddzielnie od łańcuchów ePBS Glamsterdam, dzięki czemu testy wydajnościowe optymalizacji nie były powiązane z pracami nad stabilizacją warstwy konsensusu. Każda optymalizacja znajdowała się za własną flagą funkcji, dzięki czemu pomiary z tego tygodnia mogły porównywać je w izolacji, a nie jako pojedynczy pakiet. Pulpit nawigacyjny testów wydajnościowych BAL i tabela wyników ujawniły najgorsze scenariusze każdego klienta w całym zestawie testów — skupiając się najpierw na przyspieszeniu najwolniejszych ścieżek, zespoły mogły podnieść dolny próg limitu gazu dla wszystkich, a nie tylko dla najszybszej implementacji.
Zmiany Wyceny Gazu
Glamsterdam obejmuje szereg zmian wyceny gazu w warstwie wykonawczej (EL), kalibrując koszty, aby lepiej odpowiadały zużyciu zasobów przy wyższej przepustowości. EIP-8037, czyli wzrost kosztu gazu za tworzenie stanu, znajduje się w samym centrum: podnosi cenę zapisywania nowego stanu, aby wyższy limit gazu nie przekładał się na nieograniczony wzrost stanu.
Przed Soldøgn specyfikacja 8037 zakładała dynamiczną wycenę za bajt stanu powiązaną z limitem gazu bloku, co sprawiało, że testowanie było kombinatorycznie bolesne (jedna macierz fuzzingu na przedział limitu gazu), a testy wydajnościowe prawie niemożliwe do przeprowadzenia. Zespoły zgodziły się na początku tygodnia na porzucenie dynamicznej wyceny na rzecz stałej wartości cost_per_state_byte, a przyszłe zmiany wyceny będą obsługiwane na granicach rozwidleń, a nie w ramach jednego rozwidlenia.
Sam model rozliczeniowy przyjął bardziej iteracyjną ścieżkę. Poniedziałkowa sesja w podgrupach przeniosła rozliczanie gazu za stan ze środka wykonania na koniec ramki wywołania (call-frame); wtorkowa kontynuacja zamknęła kwestie kosztów tworzenia konta, kosztów depozytu kodu i wycofań (reverts) transakcji CREATE; środa ujawniła przypadki brzegowe zwrotu/uzupełnienia rezerwuaru, które wymusiły ponowne przemyślenie tematu. Czwartkowa sesja przywróciła rozliczanie do poziomu kodu operacji, dochodząc do wniosku, że prawdziwa złożoność tkwi w modelu rezerwuaru, a nie w obliczeniach rozliczeniowych. Do piątku specyfikacja ustabilizowała się na bal-devnet-6, a ścieżka BAL dostarczyła ostateczne liczby dotyczące zmiany wyceny.
Cały ten proces podkreśla jeden z najważniejszych aspektów interop: zdolność do rozwiązywania złożonych problemów ze specyfikacją, implementacją, testowaniem, debugowaniem i projektowaniem w ciągu godzin zamiast tygodni. W najlepszym wydaniu, tygodnie interop potrafią skompresować miesiąc asynchronicznego postępu w każdy pojedynczy dzień!
Do piątku te trzy wątki zbiegły się w główną liczbę tygodnia: wiarygodny dolny próg limitu gazu po Glamsterdam na poziomie 200M. Ten znaczący wzrost jest możliwy, ponieważ ePBS tak strukturyzuje slot, aby dać więcej czasu na wykonanie, optymalizacje BAL dają klientom zapas przepustowości w ramach tej struktury, a 8037 zapewnia, że wyższy limit gazu nie przełoży się na niekontrolowany wzrost stanu.
Inne Wątki Glamsterdam
Poza ePBS, BAL i zmianami wyceny, większość pozostałego zakresu Glamsterdam została omówiona podczas sesji w podgrupach.
Zespoły CL sfinalizowały decyzje dotyczące mniejszych EIP dla Glamsterdam: EIP-8061 (zwiększenie rotacji wyjść/konsolidacji) został włączony do glamsterdam-devnet-1; EIP-8080 (wyjścia przez kolejkę konsolidacji) został odrzucony; EIP-8045 (usunięcie obowiązków dla walidatora poddanego cięciu) został ograniczony tylko do obowiązków proponującego w oknie wyprzedzenia (look-ahead window); a EIP-7688 (stabilne kontenery SSZ) pozostaje w zakresie Glamsterdam, ale jest wstrzymany z glamsterdam-devnet-1, podczas gdy zespół pracuje nad ograniczonym rozmiarem wiadomości plotkowania (gossip) dla atestacji w ramach list progresywnych.
Środowa poranna sesja dotycząca architektury synchronizacji EL/CL odroczyła EIP-8237 z Glamsterdam na rzecz zachowania opcjonalności dla długoterminowej architektury "top-up sync" w przyszłym rozwidleniu. W jego miejsce zebrani zgodzili się przygotować projekt EIP, który normalizuje sekwencjonowanie forkchoiceUpdated / newPayload / getPayload, określa handshake inicjujący snap-sync i zacieśnia spójność valid/invalid między powierzchniami engine API.
Wzmacnianie było stałym motywem tego tygodnia. Czwartkowa sesja obejmowała frameworki do testowania zgodności wyboru rozwidlenia (fork-choice), repozytorium Diamond z powtarzalnymi scenariuszami przypadków brzegowych CL oraz buildoor, narzędzie PandaOps do testowania zewnętrznych budowniczych, zaprezentowane w połowie sesji na długim strumieniu scenariuszy ataków, które uczestnicy sugerowali na bieżąco.
Poza Glamsterdam
Kilka sesji w podgrupach spoglądało w stronę Hegotá i kolejnych rozwidleń.
Celowo niezależna od konkretnych propozycji sesja na temat natywnej abstrakcji konta rozpoczęła dyskusję, przepracowując wymagania i ograniczenia, które musi spełniać każdy przyszły projekt. Cele dotyczące zestawu funkcji, takie jak alternatywne schematy podpisów, agregacja, wsadowanie, odzyskiwanie, sponsorowanie gazu, elastyczne nonce i portfele typu magazyn kluczy, sąsiadowały z twardymi ograniczeniami dotyczącymi kompatybilności z publicznym mempool, bezstanowości i odporności na ataki DoS w warstwie 2 (L2).
Czwartkowa sesja o FOCIL skupiła się na aktualizacjach implementacji: wczesne prototypy były już funkcjonalne, a interop między wieloma klientami i dedykowana sieć deweloperska FOCIL to bezpośrednie kolejne kroki. Podjęto również dwie godne uwagi decyzje projektowe: wyłączenie FOCIL podczas braku ostateczności trwającego 2 epoki (odzwierciedlając zachowanie wyłącznika awaryjnego proposer-boost) oraz przyjęcie podejścia opartego na zakładkach z indeksem w celu zapewnienia kompatybilności z transakcjami ramkowymi / EIP-7702.
W dalszej perspektywie, długoterminowa ścieżka ETH P2P naszkicowała oparty na QUIC zamiennik dla libp2p z domyślną prywatnością i integracją świadomą slotów, obok prototypu transmisji z kodowaniem korekcyjnym (erasure-coded), który symulował ~6-krotnie szybszą propagację niż GossipSub przy ładunkach 2,4 MB. Ścieżka CL ujawniła również silne przekonanie o konieczności ostatecznego całkowitego wycofania konsolidacji — ogłaszając ostatnie rozwidlenie, które je obsługuje, a następnie wymuszając wyjście i ponowny depozyt — jako czystszą długoterminową odpowiedź na wzrost stanu zestawu walidatorów.
Proces ACD
W środę po południu Nixo i Ansgar, dwaj współprzewodniczący ACDE, poprowadzili sesję, aby zebrać opinie od głównych współtwórców na temat procesu ACD. Sesja powróciła do konstruktu headlinera, debatowała nad zaletami i wadami posiadania wstępnej mapy drogowej (strawmap) oraz sformalizowała kryteria EIP SFI. Zebrani w większości chcieli zachować headlinerów, ale rozluźnić sztywność na linii EIP-kontra-motyw, akceptując "motyw + kandydujący EIP" jako realny wzorzec. Przypisania lat do poszczególnych rozwidleń na wstępnej mapie drogowej po 2026 roku zostały uznane za zbytnio skanonizowane i prawdopodobnie zostaną złagodzone. Przedstawiono nową, czteropunktową definicję SFI, przy czym ACDT sygnalizuje gotowość, a ACDE/ACDC zachowują ostateczne zdanie. Nowy proces ustalania priorytetów — tworzony po decyzjach CFI i odzwierciedlony w meta-EIP — zastąpi dawną rolę SFI polegającą na kierowaniu włączaniem do sieci deweloperskiej, począwszy od Hegotá.
Ze strony koordynacji spotkań, Alex Stokes ogłosił, że od przyszłego tygodnia udaje się na trzymiesięczny urlop naukowy (sabbatical), a Pari przejmie w tym czasie moderację ACDC, natomiast Barnabas zastąpi go w ACDT. Podsumowując: Nixo i Ansgar przewodniczą ACDE, Pari tymczasowo prowadzi ACDC, a Mario, Barnabas i Danceratopz rotacyjnie moderują ACDT.
Wszystko Inne
Oprócz wszystkiego powyższego, zespoły wykorzystały czas spędzony osobiście na poczynienie postępów we wszystkim, od lepszych środowisk testowych (kompresja pętli sprzężenia zwrotnego Hive z godzin do minut), przez ulepszenia infrastruktury engine-API (deduplikacja gossip, wywołania wsadowe i odkrywanie głowy sterowane przez lekkiego klienta), po trudne kompromisy wokół różnorodności klientów i wiele innych tematów. Pełna lista notatek z sesji jest dostępna na stronie soldogn.xyz.
Następne Kroki
Od tego momentu zespoły wracają do domów, aby wziąć to, co zostało sprototypowane w ciągu tygodnia, i przygotować to do wdrożenia produkcyjnego. Spodziewajcie się, że przez kilka następnych tygodni będą w pełni skupieni na wzmacnianiu implementacji klientów pod kątem nowych specyfikacji, finalizowaniu pokrycia testami i przekształcaniu roboczych PR-ów z Soldøgn w scalony kod.
Jak zawsze, ostateczne decyzje dotyczące wartości takich jak cel limitu gazu na poziomie 200M i ostateczne liczby dotyczące zmiany wyceny zostaną podjęte i udostępnione publicznie podczas spotkań AllCoreDevs. Spodziewajcie się, że będą to główne tematy w przyszłym tygodniu!
Bardzo dziękujemy wszystkim, którzy przybyli aż na 78°N i sprawili, że ten tydzień był sukcesem! Specjalne podziękowania dla EthPandaOps za codzienne mobilizowanie grupy do działania oraz dla wszystkich, którzy pracowali w świetle słońca o północy, aby upewnić się, że osiągamy nasze codzienne cele — w tym dla ekipy Ethrex, która dołączyła do nas na swój pierwszy interop. To był niesamowicie produktywny tydzień i na szczęście będziemy mieli pełny film krótkometrażowy, aby go zapamiętać ☀️