Planowana aktualizacja Ethereum o nazwie Glamsterdam może sprawić, że część istniejących aplikacji przestanie działać prawidłowo. Problem dotyczy zmian w opłatach za operacje na danych, od których zależy działanie smart kontraktów. Dwóch deweloperów zaproponowało różne sposoby, by ograniczyć ryzyko dla starszych kontraktów.
Skąd bierze się ryzyko?
Glamsterdam ma obejmować m.in. propozycje EIP-8037 i EIP-8038, które podnoszą koszt gazu za tworzenie kontraktów oraz operacje na przechowywanych danych. Gaz określa, ile zasobów sieci zużywa wykonanie poszczególnych działań. Według EIP-8037 podstawowa opłata za utworzenie kontraktu miałaby wzrosnąć z 32 tys. do 183,6 tys. jednostek gazu, nie licząc kosztów przechowywania kodu i jego wykonania.
Część aplikacji zaprojektowano przy założeniu, że stawki pozostaną niezmienne. Jeśli kontrakt z góry określa limit gazu dla wywołania innej aplikacji, podwyżka może sprawić, że operacja zakończy się niepowodzeniem. Szczególnie narażone są rozwiązania, których nie da się już zaktualizować po wdrożeniu — a niektóre z nich przechowują środki użytkowników.
Zmiany w opłatach mogą mieć konsekwencje wykraczające poza sam koszt transakcji. Dla użytkowników kluczowe jest to, czy starsze aplikacje nadal będą działać bezpiecznie. Zaproponowane rozwiązania mają ograniczyć ryzyko, ale wymagają jeszcze dokładnych testów.
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.
Dwa pomysły na ochronę starszych kontraktów
Leo Glisic proponuje zachowanie dotychczasowych stawek dla kontraktów, które już działają w sieci. Nowe zasady gazowe obejmowałyby natomiast aplikacje wdrażane po aktualizacji. Wymagałoby to rozdzielenia zestawu instrukcji: starsze kontrakty korzystałyby z dotychczasowego schematu, a nowe — z instrukcji uwzględniających zmiany Glamsterdam.
Inną drogę wskazuje Giulio Rebuffo. Jego propozycja zakładałaby równoległe prowadzenie dwóch pomiarów gazu podczas transakcji: jednego według dawnych reguł, a drugiego według nowych. Opłata byłaby obliczana na podstawie zaktualizowanych stawek, ale starsze kontrakty mogłyby nadal wykonywać się tak, jak przed zmianą.
Na razie oba rozwiązania mają status projektów. W dokumencie Rebuffo zaznaczono, że nie przeprowadzono jeszcze implementacji w klientach wykonawczych ani testów konsensusu, dlatego propozycja wymaga dalszej weryfikacji.
Aktualizacja czeka na dalsze testy
Obawy o wpływ zmian na istniejące kontrakty wpłynęły już na harmonogram prac. Kolejną próbę Glamsterdam na sieci testowej, zaplanowaną wcześniej na koniec października, odłożono po zgłoszeniu zastrzeżeń przez badaczy bezpieczeństwa. Sieci testowe są kopiami blockchaina, na których deweloperzy sprawdzają zmiany przed ich wdrożeniem w głównej sieci.
Ani Glisic, ani Rebuffo nie wskazali terminu, w którym ich pomysły mogłyby zostać przyjęte. Kolejna prywatna runda testów aktualizacji była wstępnie przewidywana najwcześniej na 16–20 listopada, ale plan powstał, zanim opublikowano oba projekty. Ostateczny kształt Glamsterdam będzie więc zależał m.in. od tego, czy i jak uda się pogodzić nowe zasady naliczania gazu z kompatybilnością starszych aplikacji.
Tu nie chodzi tylko o „kompatybilnosc wsteczna”, tylko o to, czy ktoś po drodze nie zrobi sobie samobója na money-lego. Jeśli stary kontrakt liczył gas na sztywno, to podbicie kosztów tworzenia/wywołań potrafi go uciąć bez ostrzeżenia. Dziwi mnie, że takie ryzyko wychodzi dopiero na etapie testów, a nie wcześniej w symulacjach klienta.
Znowu klasyka: najpierw zmieniamy reguły gry, a potem wielkie zdziwienie, że stare rzeczy przestają działać. Jeśli to ma dotknąć kontrakty nieupgradeowalne, to „wystarczy przetestować” brzmi słabo. Przy takim ekosystemie każda zmiana gas schedule powinna mieć plan regresji, a nie łatanie po fakcie.
Z perspektywy praktyka to rozwiązanie z dwoma pomiarami gazu brzmi sensowniej niż utrzymywanie starych stawek dla wszystkich starszych kontraktów. Tylko pytanie o koszt wykonania i złożoność klienta. Podwójny accounting w EVM to nie jest za darmo, a jak dojdą edge case’y przy call depth i revertach, to będzie bałagan. Bez testów konsensusu to jeszcze nie propozycja, tylko szkic.
Mam wrażenie, że ten cały Glamsterdam robi się coraz bardziej ryzykowny dla usersów niż dla devów. Jak ktoś ma środki zamknięte w starym kontrakcie, to obietnica „dostosujemy gaz” niewiele daje, jeśli coś już jest na chainie i nie da się tego zmienić. Takie rzeczy powinny być rozważane zanim się zacznie pompować temat do mainnetu.
EIP-8037 i 8038 same w sobie nie są problemem, problemem jest założenie, że gas semantics można dowolnie przestawiać bez skutków ubocznych. Jeśli compiler / klient / execution layer nie gwarantują stabilności dla legacy bytecode, to każda podwyżka opłat staje się potencjalnym breaking change. Zresztą podobny błąd widzieliśmy już przy innych governance-driven zmianach w krypto: teoria piękna, a potem patchwork.
Ja chyba poczekam z jakimkolwiek używaniem nowych rzeczy w Ethereum, aż to naprawdę przejdzie testy. Raz już widziałem jak „niewielka zmiana” rozwaliła integracje w produkcji i potem wszyscy szukali winnego. Tu jeszcze dochodzi temat starych kontraktów bez możliwości update, więc ryzyko jest dość konkretne, nie akademickie.