Ethereum opóźnia test aktualizacji Glamsterdam. Powodem są zastrzeżenia ekspertów dotyczące zmian w rozliczaniu opłat za gaz, które mogą wpłynąć na działanie już istniejących smart kontraktów — zwłaszcza tych obsługujących nieudane operacje.
Test na Hoodi wstrzymany
Aktywacja Glamsterdam w sieci testowej Hoodi miała odbyć się 26 października. Programiści zdecydowali jednak o jej odłożeniu podczas czwartkowego spotkania zespołów odpowiedzialnych za rozwój Ethereum. Na razie nie podano nowego terminu.
Hoodi miało być kolejnym publicznym testem aktualizacji po jej wdrożeniu na Sepolii 6 października. Wraz z aktywacją planowano też zwiększyć limit gazu w bloku do 200 mln. Ten element również będzie musiał poczekać.
Zmiany w gazie mogą wpłynąć na istniejące kontrakty
Wątpliwości dotyczą propozycji EIP-8037, która zmienia sposób naliczania gazu za dodawanie nowych wpisów do bazy danych Ethereum. Jej celem jest ograniczenie tempa wzrostu tej bazy, gdy sieć będzie obsługiwać więcej transakcji. Analiza firmy ChainSecurity wskazała jednak, że w połączeniu z EIP-8038 nowe reguły mogą zmienić ilość gazu dostępną kontraktom w określonych sytuacjach.
Problem może pojawić się, gdy smart kontrakt wywołuje inny kontrakt, a ten kończy działanie z powodu braku gazu. Niektóre programy są zaprojektowane tak, by przechwycić taki błąd i kontynuować działanie — na przykład zapisać niepowodzenie lub spróbować innej ścieżki. Dotychczas pozostały gaz mógł być zbyt mały, by wykonać te czynności, co powodowało cofnięcie całej transakcji.
Według analizy ChainSecurity nowe zasady mogą w pewnych przypadkach przywracać gaz zużyty na zapis, jeśli zmiany zostaną cofnięte. Kontrakt mógłby więc otrzymać wystarczająco dużo gazu, by zapisać informację o błędzie, zamiast doprowadzić do wycofania całej operacji. To potencjalnie zmienia zachowanie istniejącego oprogramowania.
Opóźnienie testu pokazuje, jak ważne jest sprawdzanie zmian protokołu przed ich wdrożeniem. Nawet korekta dotycząca rozliczania gazu może mieć nieoczekiwany wpływ na istniejące kontrakty. Dodatkowe testy mogą pomóc wykryć takie problemy, zanim aktualizacja trafi do głównej sieci.
Więcej o zmianach w Ethereum przeczytasz w artykule: Ethereum wprowadza aktualizację Fusaka, by obniżyć koszty węzłów i przyspieszyć rozliczenia warstwy 2.
Możliwy jest też odwrotny efekt
Badacze zwrócili uwagę również na sytuację, w której wykonanie prawidłowej operacji może wymagać znacznie więcej gazu niż wcześniej. W ich wyliczeniach utworzenie nowego pola pamięci mogłoby kosztować 110 020 jednostek gazu po wyczerpaniu dodatkowego limitu, wobec 22 100 według dotychczasowych zasad. Kontrakty działające w oparciu o wcześniej zakładany budżet mogłyby wtedy nie ukończyć poprawnej operacji.
Opublikowane ustalenia opisują możliwe skutki proponowanych zmian, ale nie dowodzą, że duży protokół działający w sieci jest podatny na atak. Nie ma też informacji, by istniejące kontrakty były obecnie wykorzystywane za pomocą tych reguł — nie zostały one jeszcze wdrożone na głównej sieci.
Termin wdrożenia pozostaje nieznany
Glamsterdam obejmuje kilka zmian, w tym nowy system wyboru twórców bloków oraz rozwiązania mające umożliwić obsługę większych bloków. Opóźnienie testu na Hoodi daje zespołom czas na zbadanie wpływu nowych zasad gazu i ewentualne wprowadzenie poprawek.
Nie wyznaczono jeszcze kolejnej daty testu, a termin aktywacji Glamsterdam na głównej sieci Ethereum pozostaje niepotwierdzony.
Dobrze, że wstrzymali Hoodi. Zmiana zasad rozliczania gazu, która może zmienić zachowanie istniejących kontraktów, to nie jest detal do poprawiania już po wdrożeniu na mainnecie.
Czy dobrze rozumiem, że problem nie polega na tym, że kontrakty są teraz podatne, tylko że po EIP-8037/8038 niektóre mogą dostać inny budżet gazu przy obsłudze błędu? Brzmi jak coś, co trzeba sprawdzić na forkach z realistycznymi scenariuszami.
Kolejne opóźnienie, a konkretnych terminów nadal brak. Rozumiem ostrożność, ale dla osób budujących na Ethereum planowanie wdrożeń robi się przez to mało przewidywalne.
Warto zauważyć, że opis dotyczy interakcji dwóch EIP, a nie prostego „podniesienia kosztu gazu”. Cofnięcie zmian stanu i zwrot gazu po nieudanym wywołaniu mogą zmienić przepływ sterowania w kontrakcie, jeśli autor zakładał konkretny limit.
Te 110 tys. zamiast 22 tys. to spora różnica. Czy ktoś wie, czy popularne biblioteki albo audytorzy mają już testy, które łapią takie przypadki?
Dla mnie to argument za tym, żeby nie opierać logiki kontraktu na „zostało trochę gazu, więc zapis się uda”. Ale jeśli zmienia się zachowanie EVM, to nawet ostrożnie napisany stary kod może wymagać ponownej weryfikacji.