Deweloperzy Ethereum wstępnie zaplanowali aktywację ulepszenia Glamsterdam w sieci Sepolia na 6 października 2026 r. o 13:53 UTC, ale przed kontynuowaniem forka publicznej sieci testowej konieczny jest jeszcze test innego prywatnego devnetu.
Podsumowanie
- Deweloperzy Ethereum wstępnie zaplanowali aktywację Glamsterdam w sieci Sepolia na 6 października dokładnie o 13:53 UTC.
- Glamsterdam nie zakończył stabilnej aktywacji w żadnym prywatnym devnecie, więc termin dla Sepolii pozostaje warunkowy.
- Deweloperzy planują teraz Devnet-11 na 14 września, zastępując wcześniejsze oczekiwania skupione na planach testowych Devnet-10.
- Testy devnetu ujawniły błędy konsensusu i wykonania, w tym problem implementacyjny związany z kodem EIP-8037.
- Nie potwierdzono żadnych dat dla Hoodi ani mainnetu, choć deweloperzy dyskutowali o możliwej aktywacji w grudniu.
Notatki ze spotkania ACDC #186 i późniejsze relacje badaczki protokołu Ethereum, Christine D. Kim, pokazują, że data pozostaje warunkowa. Deweloperzy nie ukończyli stabilnej aktywacji Glamsterdam w prywatnej sieci deweloperskiej, gdy wybrali harmonogram dla Sepolii.
Plan testów przesunął się od tego czasu o kolejną iterację. Kim powiedziała 11 września, że uwaga zwróciła się ku Glamsterdam-Devnet-11, którego uruchomienie oczekiwane jest w poniedziałek, 14 września. Wcześniejsze plany wskazywały Devnet-10 jako następny duży test.
Nie potwierdzono żadnych dat aktywacji dla testnetu Hoodi ani mainnetu Ethereum. Deweloperzy dyskutowali o możliwym wydaniu mainnetu w grudniu, ale wyniki testów zdecydują, czy ten harmonogram pozostanie praktyczny.
Data ulepszenia Ethereum Glamsterdam pozostaje wstępna
Podczas spotkania All Core Developers Consensus 3 września uczestnicy zgodzili się na epokę 351232 w Sepolii dla proponowanej aktywacji. Kim podała, że odpowiadający jej czas to 6 października o 13:53 UTC. Spotkanie odbyło się, zanim deweloperzy wykazali stabilne działanie w prywatnych sieciach testowych używanych dla Glamsterdam.
Wybór epoki daje zespołom klientów, operatorom infrastruktury i deweloperom aplikacji wspólny cel planistyczny. Nie czyni jednak aktywacji ostateczną. Deweloperzy mogą odłożyć fork, jeśli następna faza testów ujawni poważną usterkę lub jeśli zespoły klientów nie będą w stanie przygotować niezawodnych wydań.
Zastrzeżenie pozostaje istotne po tym, jak Devnet-9 doświadczył problemów z finalizacją. Zgodnie z materiałami ze spotkania sieć obejmowała około 1000 węzłów walidatorów, co czyniło ją największym devnetem Glamsterdam pod względem liczby walidatorów na tym etapie.
Finalizacja wymaga, aby wystarczająca liczba walidatorów zgodziła się co do stanu łańcucha. Gdy sieć testowa nie może sfinalizować, deweloperzy muszą ustalić, czy przyczyna dotyczy oprogramowania klienta, uczestnictwa walidatorów, konfiguracji sieci czy interakcji między oddzielnymi zmianami protokołu.
Devnet-11 przetestuje poprawki przed Sepolią
Pierwotny plan przewidywał Devnet-10 po pojawieniu się usterek podczas poprzednich prób. Najnowsza aktualizacja Kim wskazuje teraz Devnet-11 jako następny test, któremu przyglądają się deweloperzy, co sugeruje, że sekwencja prywatnych testów wykroczyła poza wcześniejszy plan.
Stabilny Devnet-11 dałby zespołom klientów Ethereum kolejne środowisko do testowania połączonych specyfikacji Glamsterdam. Zespoły warstwy 2, dostawcy stakingu i inni operatorzy infrastruktury potrzebują działających implementacji klientów, zanim będą mogli bezpiecznie przetestować swoje systemy względem proponowanego forka.
Różnorodność klientów komplikuje ten proces. Ethereum działa poprzez kilka niezależnie opracowanych klientów wykonawczych i konsensusu, a ulepszenie musi działać w różnych kombinacjach klientów. Usterka ograniczona do jednej implementacji może nadal przerwać sieć testową, gdy dotknięci walidatorzy mają wystarczającą wagę.
Agenda ACDC #186 odnotowuje prośby Lido i Optimism o co najmniej jeden stabilny dzień przed forkiem. Agenda wymieniała poprawki klientów i udaną interoperacyjność jako kwestie wymagające potwierdzenia przed Sepolią.
Nieudany lub niestabilny Devnet-11 nie anulowałby automatycznie aktywacji z 6 października. Deweloperzy musieliby ocenić przyczynę i czas potrzebny na naprawy. Poważny problem mógłby skłonić ich do ponownego rozważenia terminu podczas spotkania All Core Developers.
Błędy konsensusu i EIP-8037 wydłużyły testy
Wcześniejsze próby Glamsterdam ujawniły usterki po obu stronach architektury Ethereum. Inżynier operacji deweloperskich Fundacji Ethereum, Stefan Starflinger, poinformował, że Devnet-8 ujawnił problem warstwy konsensusu dotyczący bloków powtarzających hash rodzica.
„Można było zatrzymać całą sieć” — powiedział Starflinger, opisując scenariusz testowy.
Problem dotyczył systemu odpowiedzialnego za uzgadnianie bloków. Devnet-9 następnie doświadczył braku finalności, co skłoniło inżynierów do zbadania większej liczby przypadków brzegowych w większym zestawie walidatorów.
Po stronie wykonawczej badaczka Fundacji Ethereum, Maria Silva, zgłosiła problem implementacyjny dotyczący EIP-8037. Propozycja zmienia sposób, w jaki Ethereum pobiera opłaty za tworzenie nowego stanu, w tym nowych kont, kontraktów i wpisów pamięci.
EIP-8037 oddziela koszty tworzenia stanu od normalnych kosztów wykonania poprzez wielowymiarowy model gazu. Jej opublikowana specyfikacja mówi, że projekt ma na celu kontrolowanie wzrostu stanu, gdy Ethereum podnosi limit gazu bloku. Propozycja pozostaje w trakcie recenzji środowiskowej.
Odkryty problem wymagał od klientów wykonawczych zrewidowania ich implementacji i doprowadził do prac nad specyfikacją. Jak informował crypto.news w swoim omówieniu wcześniejszych postępów devnetu Glamsterdam, EIP-8037 był testowany wraz z innymi zmianami protokołu w ramach aktualizacji.
Testowanie służy innemu celowi niż indywidualne zatwierdzanie każdej propozycji. Deweloperzy muszą potwierdzić, że wszystkie wybrane zmiany działają razem w wielu klientach, konfiguracjach walidatorów i wzorcach transakcji.
Terminy Hoodi i mainnetu zależą od wyników testów
Deweloperzy odmówili zaplanowania Glamsterdam na Hoodi, dopóki Sepolia pozostaje warunkowa. Oczekuje się, że Hoodi posłuży jako drugi publiczny etap testnetu, dając operatorom stakingu i zespołom protokołu kolejne środowisko, które bliżej odzwierciedla warunki mainnetu.
Deweloper Teku, Enrico del Fante, poparł oczekiwanie przed ustaleniem daty Hoodi. Podczas ACDC #186 przytoczył niedawne problemy Devnet-9 i opowiedział się za pozwoleniem na więcej czasu na testy po decyzji dotyczącej Sepolii.
Aktywacja mainnetu w grudniu pozostaje możliwym celem, a nie potwierdzonym oknem uruchomienia. Zaplanowanie Sepolii na początek października zachowuje wystarczająco dużo czasu kalendarzowego na kolejną fazę publicznego testnetu i przygotowanie wydania klientów, pod warunkiem że testy przebiegają bez długich opóźnień.
Deweloperzy nie opublikowali epoki mainnetu, znacznika czasu aktywacji ani ostatecznego harmonogramu wydania klientów. Nie ogłoszono formalnego terminu podjęcia decyzji, czy 6 października pozostaje odpowiedni dla Sepolii.
Bezpośrednim wydarzeniem proceduralnym jest planowane uruchomienie Devnet-11 14 września. Zespoły klientów zbadają finalność, zachowanie między klientami oraz poprawki wprowadzone po wcześniejszych testach, zanim zdecydują, czy Sepolia może zostać uruchomiona zgodnie z obecnym harmonogramem.
