Glamsterdam może zagrozić tysiącom smart kontraktów Ethereum. Deweloperzy proponują dwa rozwiązania
Planowana aktualizacja Glamsterdam może doprowadzić do awarii części istniejących aplikacji działających w sieci Ethereum. Dwóch deweloperów przedstawiło konkurencyjne propozycje, które mają zachować kompatybilność starszych smart kontraktów z nowymi zasadami naliczania opłat za gaz.
Źródłem problemu są propozycje EIP-8037 i EIP-8038, które mają zostać uwzględnione w aktualizacji Glamsterdam. Pierwsza podnosi koszt tworzenia nowego stanu w sieci, w tym wdrażania smart kontraktów. Druga zmienia wycenę operacji związanych z odczytywaniem i modyfikowaniem danych zapisanych w blockchainie.
Zgodnie z EIP-8037 podstawowy koszt utworzenia kontraktu ma wzrosnąć z 32 000 do 183 600 jednostek gazu. Nie jest to jednak całkowity koszt wdrożenia, ponieważ dochodzą do niego między innymi opłaty za zapis kodu i jego wykonanie. Celem zmian jest lepsze dopasowanie opłat do obciążenia infrastruktury Ethereum i ograniczenie kosztów związanych z rozrostem stanu sieci. Szczegóły przedstawiono w oficjalnym wyjaśnieniu Ethereum Foundation dotyczącym EIP-8037 i EIP-8038.
O planowanych zmianach w cenniku operacji Ethereum i ich wpływie na użytkowników pisaliśmy już w tym artykule. Tym razem problem jest jednak poważniejszy, ponieważ nowe stawki mogą nie tylko zwiększyć koszty transakcji, ale również doprowadzić do awarii istniejących smart kontraktów.
Problem polega na tym, że część istniejących aplikacji została zaprogramowana przy założeniu, że określone operacje będą kosztować tyle samo co dotychczas. Niektóre kontrakty przekazują innym aplikacjom z góry ustaloną ilość gazu. Jeżeli po aktualizacji dana operacja będzie droższa, wywołanie może zakończyć się niepowodzeniem. Szczególnie trudna sytuacja dotyczy kontraktów, których nie można już zmodyfikować po wdrożeniu.
Skala zagrożenia pozostaje przedmiotem analiz. Anonimowy deweloper banteg wskazywał na około 200 000 potencjalnie dotkniętych kontraktów. Jednocześnie twierdził, że zastosowana metodologia ma niedociągnięcia i może pomijać kolejne zagrożone projekty. Ethereum Foundation informuje natomiast, że podczas analiz wykryto kilka projektów podatnych na zmiany. Według Fundacji większość zidentyfikowanych problemów można rozwiązać przez zwiększenie limitu gazu, a zdecydowana większość kontraktów nie powinna odczuć skutków aktualizacji.
Dwa pomysły na zachowanie kompatybilności
Dwie konkurencyjne propozycje przedstawiono 8 listopada. Pierwszą przygotował Leo Glisic. Projekt EIP-8488 dotyczący wersjonowania opkodów zakłada podział zestawu instrukcji Ethereum na dwie wersje. Istniejące smart kontrakty zachowałyby dotychczasowy harmonogram opłat, natomiast nowe aplikacje korzystałyby z instrukcji V2, uwzględniających podwyższone stawki wynikające z EIP-8037 i EIP-8038.
W praktyce oznaczałoby to, że aplikacje wdrożone przed zmianą nadal działałyby według reguł, na podstawie których zostały zaprogramowane. Nowe kontrakty od początku korzystałyby już z aktualnego modelu rozliczeń. Rozwiązanie ma ograniczyć ryzyko awarii bez rezygnowania z planowanej aktualizacji cennika operacji.
Projekt pozostaje jednak na etapie przeglądu. Wersjonowanie opkodów wymaga również uwzględnienia dodatkowych ograniczeń, między innymi dotyczących wywołań między kontraktami korzystającymi z różnych wersji instrukcji.
Inną koncepcję zaproponował Giulio Rebuffo. Jego projekt dotyczący oddzielnych liczników wykonania i rozliczania gazu przewiduje utrzymywanie dwóch równoległych liczników w ramach jednej transakcji. Pierwszy odpowiadałby za wykonanie kodu według dotychczasowych zasad, drugi naliczałby opłatę zgodnie z nowym harmonogramem.
Dzięki temu starsze kontrakty mogłyby nadal działać tak, jak oczekują tego ich twórcy, a użytkownicy płaciliby za transakcje według zaktualizowanych stawek. Rebuffo przyznaje jednak, że jego projekt nie przeszedł jeszcze implementacji w klientach wykonawczych ani testów konsensusu. To istotne ograniczenie, ponieważ rozwiązanie wymaga sprawdzenia nie tylko pod względem koncepcyjnym, ale również w praktycznym działaniu sieci.
Problemy już opóźniły testy aktualizacji
Obawy dotyczące kompatybilności nie są wyłącznie teoretyczne. Ethereum Foundation poinformowała 22 października o przełożeniu aktualizacji Glamsterdam na sieci testowej Hoodi, która pierwotnie miała nastąpić 26 października. Powodem była konieczność dokładniejszego zbadania wpływu EIP-8037 na istniejące kontrakty. Nowej daty aktywacji nie wyznaczono.
6 listopada Fundacja ponownie odniosła się do problemu. Poinformowała, że podczas testów Chainsecurity wykryła projekty, których działanie może zostać zakłócone przez zmiany wprowadzane przez EIP-8037 i EIP-8038. Deweloperzy postanowili wstrzymać dalszy proces aktualizacji na Hoodi do czasu wyjaśnienia tych kwestii.
Wcześniej badacze bezpieczeństwa zwracali uwagę, że zmiany w rozliczaniu gazu mogą prowadzić do nieoczekiwanych błędów podczas wykonywania kontraktów. Wśród krytyków obecnego kształtu aktualizacji znalazł się m.in. badacz pcaversaccio, który na platformie X argumentował, że Glamsterdam nie powinien zostać wdrożony w obecnej postaci.
Obie nowe propozycje pozostają na etapie projektów. Żadna nie ma jeszcze wyznaczonego terminu wdrożenia ani gwarancji włączenia do aktualizacji. Kolejny prywatny test Glamsterdam był wstępnie planowany na okres od 16 do 20 listopada, ale harmonogram ten ustalono jeszcze przed publikacją konkurencyjnych rozwiązań.
Dla Ethereum stawką jest nie tylko termin kolejnego hard forka, lecz także bezpieczeństwo aplikacji przechowujących środki użytkowników. Deweloperzy muszą znaleźć sposób na podniesienie opłat za operacje obciążające infrastrukturę bez naruszania logiki kontraktów, które od lat działają w sieci.
Przeczytaj również:
Zcash może przyspieszyć. Deweloperzy proponują bloki co 20 sekund
Chiny uderzają w Solanę. Nie chodzi już tylko o handel kryptowalutami
