Ethereum wstrzymuje fork Hoodi w ramach Glamsterdam. Co wykryli audytorzy?

Deweloperzy Ethereum wstrzymali fork testnetu Hoodi dla Glamsterdam, podczas gdy analizują wnioski dotyczące zachowania aplikacji, gdy transakcji brakuje gazu. Aktualizacja zmienia sposób, w jaki sieć pobiera opłaty za niektóre operacje dotykające stanu sieci lub go rozszerzające, a audytorzy odkryli, że nawet kontrakty napisane przed aktualizacją mogą zachowywać się inaczej w ramach proponowanych zasad.

Deweloperzy Ethereum mieli wykonać fork Hoodi 26 października. Przełożyli ten test, a 6 listopada deweloper Ethereum Foundation Marius van der Wijden poinformował, że pozostaje on w zawieszeniu, podczas gdy deweloperzy pracowali nad problemami zidentyfikowanymi w przeglądzie gazu.

Obawa koncentruje się na szczególe, z którym większość ludzi spotyka się tylko wtedy, gdy transakcja kończy się niepowodzeniem. Kontrakty mogą wywoływać inne kontrakty i decydować, co zrobić, jeśli te wywołania zakończą się niepowodzeniem. Kod podejmujący tę decyzję może wyglądać dokładnie tak samo po aktualizacji, a jednak obrać inną ścieżkę, ponieważ sieć pobiera teraz opłaty za części operacji w inny sposób.

Dlatego aktualizacja ukierunkowana na sposób rozliczania stanu przez Ethereum stała się kwestią zarówno dla deweloperów aplikacji, jak i dla zespołów piszących klientów Ethereum. Jedni i drudzy muszą wiedzieć, które stare założenia przetrwają zmianę.

Co Glamsterdam zmienia w kwestii gazu

EIP-8037 zmienia sposób, w jaki protokół rozlicza operacje tworzące stan. Stan Ethereum obejmuje zapisy, takie jak pamięć kontraktu. Zmiana może utrzymywać się między transakcjami, więc jej koszt ma znaczenie dla węzłów utrzymujących łańcuch po zakończeniu pierwotnej transakcji. Propozycja oddziela rozliczanie niektórych operacji tworzenia stanu od zwykłego gazu wykonawczego, z rezerwuarem, z którego można czerpać na kwalifikujące się operacje.

EIP-8038 zmienia ceny operacji uzyskujących dostęp do stanu. Obie propozycje wpływają na różne części ścieżki wykonania. Kontrakt może odczytać wartość, wykonać wywołanie zewnętrzne i zapisać wynik. Analiza samej proponowanej ceny końcowego zapisu pomija wpływ wcześniejszych odczytów i wywołań na budżet dostępny w momencie dotarcia wykonania do tego zapisu.

Znana aplikacja może zatem dać inny wynik, nawet gdy użytkownik poda te same dane wejściowe transakcji. Ważne pytanie brzmi, które różnice odzwierciedlają zamierzoną zmianę cen, a które ujawniają założenie, na którym opiera się klient lub kontrakt.

Jak nieudane wywołanie może zmienić końcowy wynik

Rozważmy kontrakt, który wywołuje drugi kontrakt, aby wykonać jeden krok w większej operacji. Jeśli drugi kontrakt zawiedzie, wywołujący może zatrzymać wszystko lub obsłużyć błąd i kontynuować. Procesor wsadowy może zapisać nieudany element i przejść dalej. Inna aplikacja może oczekiwać, że cała operacja zostanie wycofana, jeśli nieudane wywołanie zużyje wystarczająco dużo gazu.

Analiza ChainSecurity opisuje, jak nowe rozliczanie może wpłynąć na to rozróżnienie. Ethereum już ogranicza, ile gazu wywołujący może przekazać dalej zgodnie z regułą EIP-150. W odpowiednim przypadku u wywołującego może pozostać około jednej sześćdziesiątej czwartej. Problem polega na tym, ile wywołujący faktycznie ma dostępne po powrocie wykonania i ile kosztuje dokończenie instrukcji na tej ścieżce.

Załóżmy, że aplikacja traktuje niepowodzenie wywołania jako zwykły wynik biznesowy. Jeśli ma wystarczająco dużo gazu, aby dokończyć obsługę błędu, może zapisać wynik lub kontynuować resztę transakcji. Jeśli zabraknie jej gazu podczas tego procesu, zewnętrzna transakcja zostanie wycofana. Te wyniki pozostawiają różne zapisy, mimo że wewnętrzne wywołanie zawiodło w obu przypadkach.

Audytor przyjrzał się również kontrolom opartym na gasleft(). Kontrakt może użyć tej instrukcji, aby porównać swój pozostały budżet wykonania z zakodowanym na stałe minimum. Próg skalibrowany w ramach jednego harmonogramu może stać się słabym predyktorem w innym, szczególnie gdy kontrakt napotyka operacje na stanie lub przekazuje gaz na inny adres. Kontrakt nie ma automatycznego sposobu na zrewidowanie liczby, którą jego deweloper osadził podczas wdrożenia.

Co muszą ustalić audytorzy

Listopadowa aktualizacja Fundacji opisuje osiem założeń podlegających przeglądowi. Istnieją co najmniej dwa odrębne pytania do przetestowania. Klienci, którzy wdrażają nowe reguły, muszą dojść do tego samego wyniku dla danej transakcji. Recenzenci aplikacji muszą również zidentyfikować przypadki, w których ten wspólny wynik różni się od tego, czego oczekują istniejące kontrakty.

Test pierwszego pytania może wykonać tę samą transakcję na kilku klientach i porównać wyniki stanu i gazu. Test drugiego musi podążać za własną logiką aplikacji. Istotne jest, czy kontrakt traktuje nieudane wywołanie zwrotne jako sygnał do kontynuowania, czy zapisuje zmianę stanu przed wywołaniem i czy potrafi odróżnić odrzucenie biznesowe od wywołania, które nigdy nie miało wystarczająco dużo gazu.

Te ścieżki mogą być łatwe do przeoczenia w konwencjonalnym teście wdrożenia. Typowy budżet transakcji może przeprowadzić wywołanie i jego obsługę przez oba harmonogramy. Celowo napięty budżet może ujawnić różnicę. Testy graniczne muszą zatem obejmować nieudane wywołania i przypadki bliskie ilości gazu wymaganej do wejścia lub dokończenia obsługi błędu.

Co może pokazać Hoodi

Glamsterdam dotarł już do testowej sieci Ethereum Sepolia, gdzie deweloperzy przetestowali limit 200 milionów gazu. Hoodi dałby deweloperom kolejne wspólne wdrożenie, w którym mogliby przećwiczyć zmienioną aktualizację.

Publiczne rozwidlenie sieci testowej daje zespołom klientów i operatorom aplikacji wspólne środowisko do przeprowadzania tych kontroli. Operatorzy mogą aktualizować klientów według wspólnego harmonogramu, porównywać swoje wyniki i testować narzędzia pod kątem reguł rozwidlenia. Zespoły aplikacji mogą sprawdzić, czy symulacja transakcji i szacowanie gazu uwzględniają te same zmiany, które widzą podczas wykonania.

Udane rozwidlenie Hoodi dałoby deweloperom dowody dotyczące wersji i transakcji, które przetestowali. Długoterminowe pytanie dotyczy tego, co robią reprezentatywne aplikacje na granicach swoich budżetów gazu. Nową datę rozwidlenia będzie łatwiej ocenić wraz z zapisem, które przypadki odtworzono, co zmieniono w odpowiedzi i jak zespoły to przetestowały.

Prace nad gazem przebiegają równolegle z innymi poprawkami. Deweloperzy Ethereum osobno zrewidowali specyfikację depozytu walidatora, podczas gdy trwał przegląd gazu Hoodi. Te poprawki wymagają własnych testów, ponieważ dotyczą innej części rozwidlenia.

Na razie najnowsza aktualizacja deweloperów dotycząca ryzyk związanych z gazem podaje powód wstrzymania i stwierdza, że prace nad Hegota są kontynuowane. Pozostawia timing następnego testu Glamsterdam do późniejszej decyzji.

Jak limity gazu i koszty stanu pasują do siebie

Wyższy limit gazu na blok daje Ethereum więcej miejsca na pracę w ramach jego systemu rozliczeniowego. Cena przypisana do pojedynczej operacji określa, jaką część tego miejsca zajmuje dana operacja. Zmiana limitu i zmiana cen mogą zatem wpływać na różne części tej samej transakcji.

Niektóre prace kończą się wraz z transakcją. Tworzenie stanu jest inne, ponieważ dane mogą trwać, pozostawiając operatorom węzłów coś do przechowywania i przetwarzania później. Nowy slot pamięci, konto lub kontrakt mogą zwiększyć to obciążenie, nawet jeśli aplikacja, która je utworzyła, otrzymuje później niewielki ruch.

EIP-8037 zmienia sposób rozliczania kosztu tworzenia określonego stanu. EIP-8038 zmienia ceny dostępu do stanu, co może obejmować operacje dotyczące już istniejących rekordów. Transakcja, która odczytuje wartość, wywołuje inny kontrakt i tworzy wpis w pamięci, może napotkać obie zmiany podczas jednego przebiegu.

Sam wyższy limit bloku nie mówi, czy ta sekwencja będzie kosztować więcej czy mniej. Opisuje on miejsce dostępne dla bloku jako całości. Ścieżka transakcji i cena każdej operacji określają, czy zmieści się ona w gazie dostarczonym przez nadawcę.

To rozróżnienie było już istotne, gdy Sepolia rozpoczęła testowanie Glamsterdam z limitem 200 milionów gazu. Test pokazał, co deweloperzy uruchamiali w tej sieci. Wstrzymanie na Hoodi dotyczy tego, czy reguły są gotowe na kolejną sieć testową, w tym zachowania aplikacji, które opierają się na wcześniejszych założeniach dotyczących gazu.

Osiem założeń pod przeglądem

Repozytorium audytora Fundacji Ethereum grupuje swoje przykłady według zmian cen operacji i zmian sposobu śledzenia gazu. Liczby w repozytorium pochodzą z przypiętej wersji proponowanej specyfikacji i mogą się zmienić, jeśli propozycje zostaną zrewidowane.

Pierwsza grupa obaw dotyczy stałych przydziałów i kosztu dokończenia pracy po wywołaniu. Deweloperzy mogli ustawić limit gazu dla operacji, która teraz kosztuje więcej. Rezerwa przeznaczona na opłacenie końcowego zapisu może już nie być wystarczająca. W innym przypadku niewielka część zatrzymana przez wywołującego może wystarczyć do ukończenia ścieżki błędu, którą aplikacja wcześniej oczekiwała jako wycofanie.

Zmiany w rozliczaniu wprowadzają inne możliwości. Jeśli odrębny rezerwuar może nadal finansować kwalifikujące się tworzenie stanu, wywołujący może zapisać rekord po nieudanym wywołaniu, nawet gdy jego zwykły budżet wykonania jest napięty. Końcowy wynik wywołującego może wtedy zależeć od tego, które operacje korzystają z tego odrębnego budżetu.

Wyczyszczenie slotu utworzonego wcześniej w tej samej transakcji może natychmiast zwrócić część gazu stanu w przeglądanej specyfikacji. Wywołanie kończące się wycofaniem może również zwrócić gaz stanu. Kod napisany przy założeniu, że cały gaz zużyty przed wycofaniem przepada, może zatem błędnie odczytać, co się stało.

Para pomiarów gasleft() może podobnie dawać niepełny obraz kosztu pracy. Kontrakt, który używa różnicy do obciążenia kogoś lub obliczenia zwrotu, opiera się na założeniach dotyczących tego, jak gaz zmienia się między tymi dwoma odczytami. Opłaty pobierane z odrębnej puli i gaz stanu zwracany podczas wykonania mogą zmienić tę zależność.

Ósmy przypadek dotyczy EIP-7702, który pozwala kontu autoryzować delegację do kodu kontraktu. Transakcja może zostać włączona, nawet gdy zawarta w niej autoryzacja nie zadziałała, ponieważ zabrakło jej gazu. Portfel lub usługa, która na podstawie samego włączenia transakcji wnioskuje, że delegacja zadziałała, może uznać niekompletną akcję za zakończoną.

Repozytorium podaje, że wiele ustaleń otrzymanych przez jego autorów dotyczyło stałych kwot lub rezerw. Prosi deweloperów i audytorów o testowanie swoich aplikacji na przykładach i zgłaszanie problemów. Inwentarz identyfikuje wzorce wymagające przeglądu. Nie oznacza, że każda aplikacja używająca jednego z tych wzorców poniesie stratę.

Jak nieudane wywołanie może mimo to pozostawić udaną transakcję

Transakcja Ethereum może zawierać kilka wywołań. Kontrakt może zażądać, aby inny kontrakt wykonał krok, a następnie zdecydować, jak zareagować na wynik. Nieudane wywołanie wewnętrzne i nieudana transakcja to odrębne wyniki.

Procesor wsadowy stanowi użyteczny przykład. Jeśli jeden element zawiedzie, procesor może zapisać tę porażkę i przejść do następnego elementu. Jeśli zabraknie mu gazu, zanim zdąży zapisać wynik, zewnętrzna transakcja może zostać wycofana i cofnąć wcześniejsze zmiany. To samo wewnętrzne niepowodzenie pozostawia zatem inny stan końcowy w zależności od tego, co wywołujący może zrobić później.

Inna aplikacja może potraktować nieudane wywołanie jako powód do zmiany tego, kto może złożyć żądanie lub czy wolno je ponowić. Jeśli wywołujący może ukończyć ścieżkę, którą aplikacja spodziewała się wycofać, wynikowy stan może się utrzymać. Konsekwencja bezpieczeństwa zależy od tego, co ukończona ścieżka faktycznie zapisuje.

Podmiot może być w stanie wybrać, ile gazu dostarcza transakcja. Jeśli ta osoba może pozostawić wystarczająco dużo gazu, aby zewnętrzny kontrakt wszedł na ścieżkę, ale zbyt mało, aby wewnętrzne wywołanie się zakończyło, niepowodzenie może zostać wywołane przez budżet transakcji. Kontrakt, który działa na podstawie niepowodzenia, musi odróżnić ten przypadek od wywołania, które dotarło do wywoływanego i zgodnie z prawem zawiodło.

Limit przekazywania EIP-150 jest jedną z części tego zagadnienia. Wywołujący, który przekazuje tyle gazu, ile dozwolono, zachowuje około jednej sześćdziesiątej czwartej zgodnie z odpowiednią regułą. Zachowana kwota nadal musi pokryć instrukcje, które następują. To, czy te instrukcje się zakończą, zależy od harmonogramu i rozliczenia zastosowanego do nich.

Kontrakt może być podatny na wąski zakres budżetów. Daj wewnętrznemu wywołaniu wystarczająco dużo gazu, a zadziała normalnie. Daj całej transakcji zbyt mało, a zewnętrzna ścieżka zostanie wycofana. Problematyczny przedział to taki, w którym wewnętrzne wywołanie zawodzi, podczas gdy wywołujący nadal ma wystarczająco dużo, aby wykonać działanie, którego deweloper nie zamierzył dla tego niepowodzenia.

Dlaczego zmiana stałej liczby gazu może nie rozwiązać problemu

Zakodowany na stałe próg może dać kontraktowi prosty sposób sprawdzenia, czy ma wystarczająco dużo gazu przed wykonaniem wywołania. Deweloper mógł przetestować próg na typowych transakcjach i pozostawić bufor na pracę, która następuje. Liczba staje się zależnością od harmonogramu, w którym została wybrana.

Operacja może również kosztować różne kwoty w zależności od tego, czy aplikacja aktualizuje istniejący rekord, czy tworzy nowy. Przelew do kogoś, kto już ma saldo, może napotkać inną ścieżkę przechowywania niż przelew, który tworzy pierwsze saldo. Test obejmujący tylko powtarzających się odbiorców może pominąć droższą ścieżkę.

Miejsce, w którym kontrakt mierzy gaz, ma znaczenie. Odczyt bezpośrednio przed wywołaniem różni się od odczytu po kilku dostępie do stanu i samym wywołaniu. Kontrakt, który wnioskuje o przyczynie niepowodzenia z tego drugiego odczytu, zakłada, że rozumie, co mogło zostać naliczone lub zwrócone w międzyczasie.

Zmiana dodatku może mieć własne konsekwencje. Może pozwolić ukończyć wcześniej zawodzącą ścieżkę, a także dać wywoływanemu wystarczająco dużo gazu, aby wykonał pracę, której nie mógł wykonać w ramach starego limitu. Deweloper musi wiedzieć, czemu limit miał zapobiegać, zanim go dostosuje.

Niektóre kontrakty można zmieniać w drodze procesu zarządzania lub administracji. Inne są niezmienne lub zależą od komponentów, których nie można zmienić w miejscu. Nawet gdy kontrakt można zrewidować, usługi, które szacują, sponsorują lub przekazują jego transakcje, mogą również potrzebować zaktualizować własne założenia.

Co musi pokazać przekonująca reprodukcja

Test może rozpocząć się od tej samej transakcji, stanu i limitu gazu w ramach starych i proponowanych reguł. Porównanie powinno wskazać, które wywołanie zwraca niepowodzenie, co wywołujący robi następnie i czy transakcja zapisuje jakiekolwiek zmiany, które wcześniej się nie utrzymywały.

Testowanie budżetów tuż powyżej i poniżej progu pomaga pokazać, czy efekt zajmuje wąski zakres. Może również wskazać, gdzie wykonanie się rozchodzi. Wczesne sprawdzenie salda, kwota przekazana wywoływanemu i zapis w procedurze obsługi niepowodzenia to różne punkty, w których zmiana może się ujawnić.

Recenzent musi następnie zapytać, kto może dotrzeć do tej ścieżki. Zmiana odtworzona w kontrakcie testowym ustala różnicę w wykonaniu. Prawdziwa aplikacja może wymagać autoryzacji, sprawdzać odrębny warunek lub umożliwiać ponowienie dotkniętej operacji. Te szczegóły określają, czy ktoś może wymusić niepożądany wynik.

Istnieje również osobny test dla zespołów klienckich. Wszystkie klienty wykonawcze powinny osiągnąć ten sam wynik dla transakcji w ramach tej samej konfiguracji forka. Niezgodność między klientami to inny problem niż sytuacja, w której wszystkie klienty konsekwentnie produkują wynik, którego aplikacja nie przewidziała.

Zestaw testów potrzebuje zarówno ścieżek sukcesu, jak i porażek. Wymuszanie wycofania każdego nieudanego wywołania może zapobiec jednej niepożądanej zmianie stanu, ale także usunąć uzasadnioną możliwość ukończenia reszty partii. Zamierzone zachowanie aplikacji określa, co poprawka musi zachować.

Dobra reprodukcja powinna ułatwiać sprawdzenie stanu końcowego. Jeśli zapis porażki pozostaje po jednym uruchomieniu i znika po innym, test może pokazać dokładną różnicę, zamiast opierać się na ogólnym raporcie o zużyciu gazu. To ułatwia ocenę zarówno ryzyka, jak i proponowanej zmiany.

Co publiczne sieci testowe wnoszą po lokalnej reprodukcji

Deweloper może przetestować przypadek brzegowy na lokalnym forku lub w kontrolowanym środowisku klienta. Publiczna sieć testowa pozwala następnie kilku operatorom uruchomić tę samą aktualizację i porównać jej zachowanie w warunkach współdzielonych. Daje także zespołom portfeli i infrastruktury miejsce do testowania własnego oprogramowania względem aktywnych reguł.

Sepolia i Hoodi służą różnym etapom tego procesu. Aktywacja na Sepolii pokazała, że deweloperzy mogli uruchomić planowany kod w tej sieci i zbadać jego działanie w ramach skonfigurowanego limitu gazu. Hoodi daje im kolejne wdrożenie po uwzględnieniu ustaleń, które stały się istotne podczas przeglądu.

Aplikacje, ruch i stan historyczny w sieci testowej różnią się od mainnetu. Płynny fork może dostarczyć dowodów na zgodność klientów i rutynowe transakcje, nie ćwicząc każdego wzorca kontraktu, na którym polegają użytkownicy. Ukierunkowana reprodukcja dostarcza dowodów na przypadek brzegowy, który może być nieobecny w zwykłym ruchu sieci testowej.

Instrukcje aktualizacji są kolejną częścią testu. Operator potrzebuje wydania, które implementuje zamierzoną konfigurację, oraz precyzyjnego punktu aktywacji. Aplikacja musi wiedzieć, kiedy jej symulacje powinny zacząć używać zmienionych reguł. Nowa data jest przydatna obok tych szczegółów.

Październikowe odroczenie i listopadowy raport o statusie opisują to samo wstrzymanie w różnych momentach. Pierwsze usunęło zaplanowaną datę dla Hoodi. Drugi wyjaśnił, że problemy wciąż muszą zostać rozwiązane. Kolejne zawiadomienie o wdrożeniu może pokazać, które zmiany są gotowe do przetestowania przez operatorów.

Jak portfele mogą zgłaszać sukces, gdy akcja kończy się niepowodzeniem

Portfele zwykle szacują gaz przed poproszeniem użytkownika o podpis. Szacunek zależy od stanu i reguł, które węzeł stosuje w swojej symulacji. Usługa korzystająca ze starszej konfiguracji forka może podać szacunek, który nie jest już odpowiedni dla transakcji wykonywanej przez bieżący łańcuch.

Transakcja, która zostaje wycofana, nadal może kosztować nadawcę gaz. Zewnętrzna transakcja, która kończy się po przechwyceniu wewnętrznego błędu, może być trudniejsza do zinterpretowania. Łańcuch może zapisać całą transakcję jako udaną, podczas gdy akcja w jej obrębie nie została wykonana. Portfel może potrzebować zdarzeń lub stanu aplikacji, aby wyjaśnić użytkownikowi tę różnicę.

Relayerzy i sponsorzy transakcji stoją przed pokrewnym problemem. Mogą wybierać budżet lub ponosić koszty transakcji, o którą prosi ktoś inny. Jeśli budżet nie obejmuje już zamierzonej ścieżki, sponsor może zapłacić za wykonanie, które nie dostarcza żądanej akcji.

Indeksery mogą zobaczyć efekt po wykonaniu. Ścieżka porażki, która teraz się kończy, może wygenerować logi lub zmiany stanu, których system niższego poziomu wcześniej nie widział. Indekser nadal podąża za rzeczywistym stanem łańcucha. Aplikacja, która polega na indekserze, może potrzebować zmiany sposobu interpretacji wynikowego zapisu.

Test end-to-end może porównać szacunek portfela, przesłany budżet relayera, wynik wykonania klienta i wyjaśnienie interfejsu. Każdy krok może zakończyć się sukcesem sam w sobie, podczas gdy użytkownik nadal otrzymuje mylący opis tego, które akcje zostały wykonane. Rozróżnienie to ma największe znaczenie tam, gdzie aplikacja traktuje wynik jako ostateczny.

Co rozwiązałoby wstrzymanie Hoodi

Fundacja prosi zespoły aplikacyjne o zidentyfikowanie założeń, których używają, i dostarczenie przypadków, które deweloperzy mogą odtworzyć. Niektóre problemy mogą zostać rozwiązane poprzez zmiany w proponowanych regułach gazu. Inne mogą wymagać od aplikacji lub dostawcy infrastruktury zmiany sposobu obsługi nowego zachowania.

Jeśli specyfikacje się zmienią, istotnym testem jest to, czy przypadek, który wcześniej się rozbiegał, osiąga teraz zamierzony wynik. Jeśli deweloperzy utrzymają zmianę zachowania, zespoły aplikacyjne potrzebują wystarczających szczegółów, aby ustalić, czy ich oprogramowanie polega na poprzednim wyniku. Oba wyniki zależą od opisania dotkniętego wywołania i tego, co po nim pozostaje.

Zmieniona specyfikacja musi również dotrzeć do kompilacji klienta, które uruchamiają operatorzy. Kompilacja, która obsługiwała wcześniejszą konfigurację Glamsterdam, może nie zawierać późniejszych zmian. Numery wydań w nowym zawiadomieniu Hoodi wskazywałyby, które wersje można testować razem.

Listopadowa aktualizacja Fundacji mówi, że prace nad Hegota są kontynuowane równolegle. Oznacza to, że wstrzymanie wcześniejszego forka nie obejmuje każdej decyzji rozwojowej dotyczącej następnego. W przypadku Glamsterdam następnym istotnym kamieniem milowym jest zmieniony harmonogram Hoodi z konfiguracją, którą deweloperzy są gotowi uruchomić publicznie.

Udany fork dałby zespołom wspólny zapis do zbadania przed decyzją dotyczącą mainnetu. Przypadki, które spowodowały opóźnienie, pozostają najjaśniejszymi testami tego, czy zmienione zasady są gotowe. Te testy muszą pokazać, co się dzieje, gdy wywołanie zawodzi blisko swojego limitu gazu, a zewnętrzna transakcja wciąż ma pracę do wykonania.

Co proponowane liczby dotyczące gazu pokazują o różnych ścieżkach

Repozytorium Fundacji podaje konkretny przykład różnicy między tworzeniem stanu a jego aktualizacją. Zgodnie z jej przypiętą specyfikacją Glamsterdam, zimny zapis, który tworzy nowy slot, jest dzielony między koszty wykonania a znacznie większą opłatę za stan. Zapis do istniejącego slotu jest również wyceniany na nowo, ale podlega innej kalkulacji.

Różnica może dotyczyć dwóch użytkowników składających pozornie to samo żądanie aplikacji. Jeden użytkownik mógł wcześniej korzystać z usługi, więc kontrakt aktualizuje istniejący wpis. Inny może potrzebować nowego rekordu. Limit gazu, który działa dla pierwszego użytkownika, może zawieść dla drugiego.

Repozytorium mówi również, że w testowanej konfiguracji osobny rezerwuar jest dostępny tylko powyżej określonego limitu gazu transakcji. W mniejszych transakcjach koszty stanu pochodzą zamiast tego ze zwykłego budżetu. Ten próg sprawia, że ważne jest testowanie kilku budżetów, zamiast zakładać, że rezerwuar zachowuje się tak samo dla każdego wywołania.

Kod, który odczytuje pozostały gaz, może zatem w niektórych przypadkach zaobserwować tylko część zasobów transakcji. Odczytane dane są nadal istotne dla budżetu, który ujawnia instrukcja. Zmienia się to, jaki wniosek aplikacja może wyciągnąć na temat całkowitych zużytych lub pozostałych zasobów.

Przykłady dotyczące gazu są powiązane z proponowaną konfiguracją. Nie dają jednego mnożnika, który można zastosować do istniejących szacunków portfela. Pierwszy zapis do pamięci, wywołanie wykorzystujące stały dodatek i nieudana delegacja wymagają osobnego sprawdzenia, ponieważ napotykają różne części zasad.

To także dlatego zmieniona data Hoodi byłaby bardziej użyteczna wraz z rewizją specyfikacji i listą przypadków objętych wydaniem. Te szczegóły pozwoliłyby zespołom ponownie uruchomić testy odpowiadające ich aplikacjom, zanim wyciągną wnioski z ogólnej stabilności testnetu.

Na co zwrócić uwagę

• Harmonogram Hoodi: Zmieniona data rozwidlenia powinna wskazywać wersje klientów i konfigurację rozwidlenia, których operatorzy mają używać.
• Zgodność klientów: Testy międzyklienckie mogą pokazać, czy klienci wykonawczy osiągają ten sam stan i te same wyniki zużycia gazu wokół nowych granic.
• Zachowanie kontraktu: Reprodukcje powinny pokazać, kiedy nieudane wywołanie zewnętrzne pozostawia wywołującemu wystarczająco dużo gazu, aby zakończyć działanie, oraz co rejestruje transakcja zewnętrzna.
• Zmiany w propozycjach: Zmiany w EIP-8037 lub EIP-8038 pomogą pokazać, które ustalenia z przeglądu wymagały zmiany protokołu.
• Narzędzia aplikacyjne: Wyniki symulacji i szacowania gazu mogą pokazać, czy portfele i dostawcy infrastruktury prawidłowo odzwierciedlają zasady rozwidlenia.

Najczęściej zadawane pytania