Dwóch deweloperów Ethereum, Leo Glisic i Giulio Rebuffo, przedłożyło w niedzielę konkurujące ze sobą propozycje, które opisują odmienne strategie ochrony aplikacji już wdrożonych w sieci. Obie dotyczą potencjalnych skutków zmian wprowadzanych przez Ethereum Improvement Proposals EIP-8037 i EIP-8038, które zwiększyłyby ilość gazu wymaganego do niektórych operacji kontraktów inteligentnych. Spór stał się istotną kwestią dla Glamsterdam, ponieważ deweloperzy oceniają, czy proponowane zmiany cen można wprowadzić bez zakłócania działania kontraktów zaprojektowanych w oparciu o dotychczasowy harmonogram gazu Ethereum.

Zmiany gazu w Glamsterdam budzą obawy o kompatybilność

W centrum kontrowersji znajdują się EIP-8037 i EIP-8038 – dwie propozycje uwzględnione w planowanej aktualizacji Glamsterdam, które zmodyfikowałyby koszt tworzenia kontraktów i dostępu do zapisanych danych blockchainu. Gaz to jednostka, za pomocą której Ethereum mierzy zasoby obliczeniowe wymagane do wykonania transakcji i instrukcji kontraktów inteligentnych, a zmiany wyceny gazu mogą zmieniać zachowanie aplikacji, zwłaszcza gdy deweloperzy zaprogramowali kontrakty w oparciu o konkretne limity wykonania.

Aktualizacje Ethereum, takie jak Glamsterdam, łączą wiele EIP-ów w jedną skoordynowaną zmianę zasad sieci, a propozycje przechodzą zwykle przez przegląd głównych deweloperów, implementację klientów i testy na testnecie, zanim zapadnie decyzja o aktywacji. Obecny spór toczy się wewnątrz tego procesu: zastrzeżenia pojawiają się, gdy Glamsterdam jest wciąż na etapie oceny na testnecie, zanim cokolwiek dotrze do głównego blockchainu.

Zgodnie z EIP-8037 bazowa opłata gazowa za utworzenie kontraktu inteligentnego wzrosłaby z 32 000 do 183 600 gazu, a dodatkowe koszty związane z przechowywaniem kodu i wykonaniem byłyby naliczane osobno. Wzrost ten wzbudził obawy, ponieważ niektóre istniejące aplikacje Ethereum zostały opracowane w przekonaniu, że określone operacje będą nadal zużywać tę samą ilość gazu.

Niektóre kontrakty przydzielają stały limit gazu podczas interakcji z innymi aplikacjami. Jeśli koszt tych interakcji przekroczy przydzieloną ilość, operacje mogą się nie powieść. Szczególnie wysoka stawka dotyczy kontraktów inteligentnych, których nie można modyfikować po wdrożeniu, ponieważ takie aplikacje mogą nie mieć prostego mechanizmu dostosowania do zmienionego harmonogramu gazu.

Badacze bezpieczeństwa ostrzegają przed powszechnymi zakłóceniami kontraktów

Obawy wpłynęły już na harmonogram testów Glamsterdam. Choć aktualizacja została wdrożona na testowej sieci Ethereum, drugie ćwiczenie testowe zaplanowane na 26 października zostało przełożone po ostrzeżeniach badaczy bezpieczeństwa. Testowe sieci Ethereum pozwalają deweloperom ocenić zmiany protokołu, zanim trafią one do głównego blockchainu, gdzie aplikacje i transakcje obejmują rzeczywiste aktywa. Harmonogramy gazu były zmieniane również w poprzednich aktualizacjach Ethereum, dlatego propozycje repricingu są rutynowo sprawdzane pod kątem kontraktów napisanych w oparciu o starsze założenia kosztowe.

Badacz bezpieczeństwa pcaversaccio publicznie skrytykował proponowane zmiany wyceny gazu, argumentując, że Glamsterdam nie powinien być wdrażany w obecnej formie.

"imho Glamsterdam should not be shipped in its current form, period," napisał pcaversaccio na X.

Badacz powiedział, że zastrzeżenia zostały przedstawione głównym deweloperom Ethereum dwa tygodnie wcześniej.

Anonimowy deweloper banteg również zakwestionował zakres dotychczasowych ocen kompatybilności, wskazując na listę około 200 000 potencjalnie dotkniętych kontraktów w repozytorium ethereum/repricing-impact. Według bantega ograniczenia metodologiczne oceny mogą oznaczać, że w rzeczywistości dotkniętych jest znacznie więcej kontraktów niż wskazuje istniejąca lista. Deweloper ostrzegł ponadto, że proponowane zmiany mogą zakłócić wdrażanie i działanie kilku znaczących protokołów Ethereum, a nie tylko mniej popularnych aplikacji.

Te ostrzeżenia zintensyfikowały kontrolę nad tym, jak deweloperzy Ethereum zamierzają wdrożyć repricing gazu, zachowując jednocześnie funkcjonalność kontraktów już działających w sieci.

EIP-8488 proponuje oddzielne zasady gazu dla istniejących i nowych kontraktów

Propozycja Glisica, oznaczona jako EIP-8488, wprowadza mechanizm kompatybilności, który rozróżniałby kontrakty inteligentne wdrożone przed aktualizacją i te utworzone po niej. Istniejące kontrakty nadal działałyby według obecnych zasad wyceny gazu Ethereum, podczas gdy nowo wdrażane kontrakty korzystałyby ze zmienionego zestawu instrukcji odzwierciedlającego wyższe koszty gazu wprowadzone przez EIP-8037 i EIP-8038.

Propozycja faktycznie podzieliłaby zestaw instrukcji Ethereum na dwie wersje, pozwalając starszym aplikacjom zachować ustalone koszty wykonania, a nowym aplikacjom wymagając stosowania zaktualizowanej struktury cen.

"Existing contracts keep the legacy schedule," stwierdza projekt EIP-8488.

Nowe kontrakty musiałyby korzystać z opkodów V2 związanych ze zmienionym harmonogramem gazu. Podejście to ma na celu ograniczenie ryzyka kompatybilności dla aplikacji, których nie można zaktualizować, jednocześnie pozwalając Ethereum wprowadzić planowane zmiany wyceny gazu dla przyszłych wdrożeń.

Alternatywna propozycja wprowadza podwójną księgowość gazu

Rebuffo zaproponował inny mechanizm, który stosowałby nowy harmonogram wyceny gazu do rozliczania transakcji, zachowując dotychczasowe zachowanie wykonania starszych kontraktów inteligentnych. Zamiast utrzymywać oddzielne zestawy instrukcji dla starych i nowych aplikacji, projekt wprowadziłby dwa mechanizmy księgowania gazu w każdej transakcji. Jeden licznik śledziłby wykonanie kontraktu według istniejących zasad gazu, a drugi obliczałby opłaty transakcyjne według zaktualizowanego harmonogramu cen.

W tej strukturze nowy harmonogram określałby opłatę transakcyjną, ale starsze aplikacje nadal wykonywałyby się w oparciu o założenia ustanowione przez poprzednie zasady gazu. Propozycja ma na celu oddzielenie obliczania kosztów transakcji od warunków wykonania, od których zależą istniejące kontrakty inteligentne.

Projekt przyznaje jednak, że konstrukcja pozostaje nietestowana na poziomie implementacji.

"no execution-client implementation or consensus tests have been run for this design," stwierdza propozycja.

Deweloperzy stoją przed decyzjami dotyczącymi zmian gazu w Glamsterdam

Konkurujące propozycje ukazują odmienne podejścia do rozwiązania tego samego problemu kompatybilności. EIP-8488 Glisica zachowałby dotychczasową wycenę gazu dla wcześniej wdrożonych kontraktów, wprowadzając zmieniony harmonogram poprzez nowe instrukcje. Alternatywa Rebbufa stosowałaby zaktualizowane rozliczanie transakcji, zachowując dotychczasowe zachowanie wykonania. Oba podejścia mają zapobiec zakłóceniu działania aplikacji opierających się na obecnych kosztach wykonania Ethereum przez planowany repricing gazu.

Kwestia przyciągnęła uwagę, ponieważ dotknięte kontrakty mogą obejmować ugruntowane protokoły, które nie mogą łatwo modyfikować swojego wdrożonego kodu. Po tym, jak testy zostały już przełożone po ostrzeżeniach dotyczących bezpieczeństwa, propozycje przedstawiają potencjalne rozwiązania techniczne dla deweloperów oceniających ryzyko kompatybilności Glamsterdam.

Kamienie milowe, które przesunęłyby debatę naprzód, są konkretne: przełożona runda testów na testnecie przeprowadzona z wdrożonym mechanizmem kompatybilności, a jeśli którykolwiek z projektów ma zostać rozwinięty – implementacje w klientach wykonania i wyniki testów konsensusu, aby je ocenić. Dopóki te kroki nie nastąpią, kwestia kompatybilności pozostaje otwarta, gdy Glamsterdam przechodzi przez swój cykl rozwojowy.

Dostępne informacje nie przesądzają, czy któraś z propozycji zostanie przyjęta. Projekt Rebbufa nadal nie ma implementacji w klientach wykonania ani wyników testów konsensusu, co pozostawia jego wykonalność techniczną pod dalszą oceną.

Źródło: CoinDesk

Pierwsza publikacja: Hokanews