Glamsterdam znika z październikowego kalendarza Hoodi — Ethereum weryfikuje ryzyka kontraktowe

Test Hoodi z 26 października został odwołany, wraz z planowanym limitem gazu wynoszącym 200 milionów. Deweloperzy analizują propozycję zmiany cen w odniesieniu do kontraktów już działających w mainnecie.

Ethereum odwołało test, który miał się odbyć w najbliższy poniedziałek. Zawiadomienie Fundacji Ethereum z 22 października stwierdza, że Glamsterdam nie zostanie aktywowany na Hoodi o 17:42:48 UTC 26 października i nie wyznaczono nowej epoki. Towarzyszący wzrost limitu gazu do 200 milionów został również usunięty z harmonogramu testnetu. Jest to przełożenie przyszłej konfiguracji, a nie odwrócenie bloków już zapisanych przez Hoodi.

Deweloperzy podjęli decyzję o zbadaniu, jak EIP-8037, zmiana ceny tworzenia nowego stanu Ethereum, współdziała z kontraktami w mainnecie. Fundacja nie stwierdziła, że aktualizacja zepsuła mainnet. Nie wyznaczyła też daty forka produkcyjnego. Bezpośrednie ryzyko operacyjne dotyczy Hoodi: klienci lub niestandardowe konfiguracje wciąż zawierające stary czas aktywacji mogą nie zgadzać się ze zmienionym harmonogramem. Głębsze pytanie dotyczy tego, jak zmienić koszt pracy w transakcji bez zakłócania aplikacji, które zakodowały stare liczby w kodzie.

Fork Hoodi z 26 października znika z kalendarza

Ogłoszenie dotyczące Hoodi z 16 października określało epokę 132 352 i slot 4 235 264. Łączyło zmiany warstwy wykonawczej Amsterdam ze zmianami warstwy konsensusu Gloas oraz limitem gazu wynoszącym 200 milionów. Nowe zawiadomienie w pełni zastępuje te instrukcje. Operatorzy powinni przeczytać najnowsze informacje o wydaniu dla obu typów klientów; wcześniejsze wydanie opisane jako kompatybilne z Glamsterdam może nadal zawierać obecnie odwołaną aktywację Hoodi.

To więcej niż przypis do harmonogramu. Walidator musi przestrzegać tych samych reguł sieci co jego odpowiednicy. Jeśli część jego oprogramowania oczekuje nowych reguł wykonawczych lub obowiązków konsensusu w starej epoce, podczas gdy sieć tego nie robi, może utracić zdolność do podążania za łańcuchem kanonicznym. Infrastruktura budowniczych i walidatorów może mieć własną konfigurację. Dlatego Fundacja zaleca operatorom zweryfikowanie zmienionych wersji klientów i usunięcie nieaktualnych ustawień niestandardowych przed 26 października, zamiast zakładać, że nicnierobienie jest bezpieczne, ponieważ fork został opóźniony.

Sepolia aktywowała Glamsterdam 6 października i przetestowała limit gazu wynoszący 200 milionów, co odnotowano w relacji z tej aktywacji. Udana aktywacja w jednym testnecie jest przydatna, ale nie rozstrzygająca dla innego. Pozostała próba generalna Hoodi została przełożona właśnie dlatego, że dochodzenie w sprawie kontraktów wymaga czasu. Nie ma opublikowanego znacznika czasu zastępczego, który można by ekstrapolować na datę mainnetu.

Glamsterdam został aktywowany na Sepolii 6 października, gdzie deweloperzy przetestowali limit gazu wynoszący 200 milionów. Udany test nie rozstrzyga, jak EIP-8037 wpłynie na kontrakty już działające w mainnecie. Próba generalna Hoodi jest przełożona, podczas gdy deweloperzy badają te interakcje, i nie ogłoszono nowej daty.

Sekwencja zmieniła się w tym roku więcej niż raz. Wrześniowe doniesienia o planie dla Sepolii opisywały problemy z devnetem oraz problem z implementacją EIP-8037 przed przeprowadzeniem testu publicznego. Te wcześniejsze problemy nie są dowodem na tę samą przyczynę co październikowe zapytanie dotyczące kontraktu. Pokazują one, dlaczego daty były warunkowe, gdy zespoły klientów przechodzą od prób prywatnych do sieci publicznych. Odrębne obawy dotyczące zachowania builderów w testnetach dotyczą innej części Glamsterdam i nie należy ich mylić ze zmianą cen. Najnowsza informacja podaje jeden konkretny powód wstrzymania Hoodi: dalsze badanie interakcji EIP-8037 z kontraktami mainnetu.

Dlaczego tworzenie stanu kosztuje więcej w propozycji

Transakcja może wykonywać obliczenia i może pozostawiać dane, które sieć musi przechowywać i do których musi później uzyskiwać dostęp. Utworzenie nowego konta, otwarcie nowego slotu pamięci masowej lub wdrożenie bajtkodu kontraktu zwiększa ten trwały stan. EIP-8037 proponuje pobieranie wyższych opłat za te operacje i oddzielne mierzenie części związanej z tworzeniem stanu. Celem jest zbliżenie ceny do dłużej trwającego obciążenia węzłów, zwłaszcza jeśli bloki mają być dozwolone do przenoszenia większej ilości pracy.

Ilustracyjna tabela propozycji określa składnik tworzenia stanu dla nowego konta na 183 600 gazu, w porównaniu z obecnymi 25 000; nowy slot pamięci masowej na 97 920, w porównaniu z 20 000; a wdrożenie 24 kilobajtów na 37 784 880, w porównaniu z 4 947 200. Tabela nie jest uniwersalną prognozą opłaty ETH, którą zapłaci użytkownik. Izoluje ona składnik przy proponowanej stałej, z innymi opłatami za wykonanie na wierzchu, a końcowy koszt w walucie zależy od ceny gazu w danym momencie. Skala zmiany wyjaśnia, dlaczego kontrakty z ciasnymi limitami zasługują na bliższe przyjrzenie się.

Powiązana propozycja dostępu do stanu, EIP-8038, zmienia ceny niektórych odczytów i zapisów. Przewodnik po wpływie na deweloperów Fundacji mówi, że te koszty gazu zostały ostatnio znacząco dostosowane w forku Berlin w 2021 roku, podczas gdy stan wzrósł. Planowana zmiana cen została zaprojektowana równolegle z pracami nad zwiększeniem przepustowości; zwiększanie bloków bez uwzględnienia kosztownych operacji na stanie mogłoby utrudnić walidację operatorom węzłów. Wstrzymanie dotyczy zatem zarówno kompatybilności aplikacji, jak i planu skalowania, chociaż ogłoszonym wyzwalaczem jest interakcja z EIP-8037.

Wywołanie zewnętrzne pokazuje, dlaczego może to być trudne do zauważenia z wyprzedzeniem. Wywołujący może celowo przekazać tylko tyle gazu, aby odbiorca wykonał ograniczoną czynność, zakładając, że wszelka dalsza praca zakończy się bezpiecznym niepowodzeniem. Jeśli konto lub dostęp do pamięci masowej o zmienionej cenie zużyje teraz ten przydział, odbiorca może ponieść porażkę podczas rutynowej płatności, nawet jeśli użytkownik dostarczył dużo gazu do transakcji zewnętrznej. Zmiana szacunku portfela nie przepisuje wewnętrznego przydziału. Deweloperzy muszą sprawdzić ścieżkę kodu i obsługę błędów wokół niej, ponieważ niektóre aplikacje traktują nieudane wywołanie zewnętrzne jako powód do wycofania, podczas gdy inne kontynuują i zapisują inny wynik.

Wzorce transfer i send w Solidity historycznie przekazują 2300 gazu jako dodatek. Wiele zespołów już odeszło od polegania na tym dodatku, ale wdrożone kontrakty mogą pozostawać w użyciu przez lata. Fundacja identyfikuje stałe dodatki jako jedną z kategorii ryzyka; nie twierdzi, że każde wywołanie ich używające zakończy się niepowodzeniem. Odbiorca, który wykonuje niewiele pracy, może pozostać w granicach przydziału, podczas gdy kontrakt, który dotyka stanu o nowej cenie, może go przekroczyć. Testowanie rzeczywistych kontrahentów ma większe znaczenie niż traktowanie samej obecności nazwy funkcji jako dowodu na awarię.

Druga klasa problemów leży w automatyzacji. Portfele, relayerzy i depozytariusze mogą przechowywać domyślne limity gazu dla regularnych zadań. Operacja, która działała pomyślnie przez lata, może zacząć kończyć się brakiem gazu, nawet jeśli sam kontrakt aplikacji jest solidny. Podniesienie szacunku we frontendzie może naprawić tę ścieżkę, ale zaplanowany agent lub klient korzystający ze starszego portfela może nadal przesyłać poprzedni limit. Deweloperzy muszą zatem zidentyfikować nie tylko dotknięty kod, ale także usługi, które konstruują dla niego transakcje.

Które kontrakty mogą napotkać problemy?

Fundacja odtworzyła historyczne transakcje z mainnetu według proponowanego harmonogramu. Większość nie miała istotnego problemu. Spośród oznaczonych przypadków wiele zakończyło się po podniesieniu limitu gazu; mniejsza grupa mogłaby zawieść nawet przy znacznie większej ilości gazu. Stały dodatek, zakodowana na stałe ilość gazu wysyłana do innego kontraktu lub gałąź oparta na wyniku gasleft() mogą zmienić ścieżkę, którą obiera transakcja. Wcześniejsze ostrzeżenie o kontraktach opisywało te kategorie, zanim Hoodi uzyskało swoją październikową datę. Obecne opóźnienie czyni nierozwiązane przypadki pilnymi, ale nie dowodzi, że wszystkie kontrakty Ethereum są podatne na zagrożenia.

Rozważmy aplikację, która wysyła środki do innego kontraktu, zapewniając stały przydział gazu. Kontrakt odbierający może potrzebować więcej gazu w nowym harmonogramie, aby uzyskać dostęp do pamięci. Jeśli przydział wywołującego jest osadzony w wdrożonym kodzie, samo podniesienie limitu transakcji najwyższego poziomu może nie dać wywołaniu odbierającemu więcej miejsca. Awaria mogłaby wtedy wymagać poprawki na poziomie kontraktu lub innej ścieżki dla użytkowników. Natomiast jeśli jedynym problemem jest to, że portfel oszacował transakcję przy użyciu starych cen, zaktualizowana estymacja i wyższy dostarczony limit mogą wystarczyć. Te dwa przypadki są operacyjnie odmienne.

Szczególnie nietypowy problem związany z EIP-8037 dotyczy kodu, który mierzy pracę, odejmując dwa odczyty pozostałego gazu. Propozycja wyjaśnia, że rezerwuar gazu stanowego może w pewnych okolicznościach powodować wzrost gasleft(). Obliczenie oczekujące nieujemnego spadku mogłoby zachowywać się inaczej, a niezmienne wdrożone kontrakty nie mogą być łatane w miejscu. Dokładny wpływ zależy od kodu i ścieżki transakcji, dlatego odtworzenie rzeczywistych historycznych transakcji ma większe znaczenie niż ogólne ostrzeżenie o wyższych opłatach.

Narzędzie wyszukiwania Fundacji pozwala twórcom badać dotknięte adresy kontraktów i powód oznaczonej rozbieżności. Zaleca testowanie na devnecie przy użyciu nowego harmonogramu i sprawdzanie kodu, który zakłada stałe limity, nawet gdy kontrakt nie pojawia się na liście. Odtworzenie historyczne to przesiew, a nie pełny inwentarz przyszłego zachowania: ścieżka, której żaden użytkownik nie wywołał w próbce, może nadal zawierać podatne założenie. Zespoły potrzebują własnych testów dla gałęzi, które obsługują.

Wynik odtworzenia zależy również od próbki transakcji. Kontrakt może zawierać stały przydział gazu w funkcji, która była rzadko wywoływana; jeśli ta ścieżka jest nieobecna w odtworzonej historii, narzędzie nie może wykazać jej awarii. Fundacja zaleca opiekunom sprawdzanie kodu, nawet gdy jego adres nie pojawia się na liście dotkniętych. Duża aplikacja może mieć kilka kontraktów, aktualizowalne frontendy i zautomatyzowanych agentów, z których każdy dostarcza inny limit gazu. Zespół musi testować operację tak, jak faktycznie wywołują ją użytkownicy, w tym portfel lub bota, który może przechowywać starą estymację w pamięci podręcznej.

W przypadku kontraktu, którego zachowanie się zmienia, naprawa interfejsu wysyłającego transakcje nie zawsze wystarcza. Jeśli przydział gazu wywołania wewnętrznego został skompilowany do niezmiennego kodu, jego właściciel może potrzebować migracji do nowego kontraktu. Taka migracja może obejmować przenoszenie sald, zatwierdzeń lub uprawnień użytkowników oraz komunikowanie nowego adresu. Trudność zależy od projektu produktu; nie ma dowodów, że każdy oznaczony kontrakt wymaga takiej pracy. Właśnie dlatego rozróżnienie między awarią możliwą do naprawy przez limit a potencjalnie zepsutym kontraktem ma znaczenie zarówno dla zespołu, jak i jego klientów.

Wskazówki dotyczące testowania są szczególnie istotne dla aplikacji, które używają abstrakcji konta lub wielu wywołań kontraktów do zakończenia jednej akcji użytkownika. Kasa może zatwierdzić aktywo, skierować swap i rozliczyć sprzedawcę w jednej sekwencji. Jeśli wewnętrzny krok używa zakodowanego na stałe przydziału, klient może zobaczyć nieudaną płatność, nie wiedząc, który kontrakt osiągnął limit. Odtworzenie całej sekwencji według proponowanych zasad jest bardziej informacyjne niż sprawdzanie publicznej metody każdego kontraktu w izolacji. Opiekunowie powinni zapisywać pierwszy nieudany krok i to, czy większy zewnętrzny limit gazu faktycznie zmienia wynik.

Kontrakty mogą również zachowywać się inaczej po nieudanym wywołaniu, zamiast po prostu się zatrzymywać. Fallback, który rejestruje zdarzenie, zasila wewnętrzne saldo lub próbuje drugiej ścieżki, może kontynuować działanie w warunkach, których jego pierwotni autorzy nigdy nie przewidzieli. Ta rozbieżność jest powodem, dla którego wynik testu opisany jedynie jako „transakcja zakończona sukcesem” może być niewystarczający. Stan wyjściowy i zdarzenia wymagają porównania ze starym wykonaniem. Kategoria Fundacji dotycząca udanego wykonania ze zmianami obejmuje tę możliwość, nie uznając jej automatycznie za szkodliwą.

Portfele, RPC i fabryki stoją przed różnymi zadaniami

Portfele i dostawcy zdalnego wywołania procedur szacują gaz potrzebny transakcji, zanim użytkownik ją podpisze. EIP-8037 mówi, że eth_estimateGas i oprogramowanie węzła muszą uwzględniać zarówno gaz wykonania, jak i nowy wymiar gazu stanu. Stara zapisana w pamięci podręcznej stała może zaniżać transakcję obciążającą stan. Użytkownicy mogą wtedy zobaczyć nieudane transakcje, nawet jeśli kontrakt działałby z prawidłowo oszacowanym limitem. Aktualizacje infrastruktury są zatem częścią kompatybilności, a nie jedynie udogodnieniem nałożonym na protokół.

Deterministyczne fabryki wdrożeń stanowią kolejny wąski przypadek. EIP-8037 omawia fabryki pierwotnie umieszczone pod standardowymi adresami przy użyciu wstępnie podpisanych transakcji z zakodowanymi na stałe limitami gazu. W nowej sieci, która przyjmuje nowy harmonogram, zanim fabryka istnieje, stare wstępnie podpisane wdrożenie może zabraknąć gazu. Propozycja wyraźnie stwierdza, że już wdrożone instancje w istniejącej sieci głównej i sieciach warstwy 2 nie są dotknięte tym konkretnym scenariuszem genezy. Zgłaszanie tego zastrzeżenia ma znaczenie: wprowadzające w błąd byłoby sugerowanie, że każda fabryka już używana w Ethereum wkrótce zniknie.

Twórcy muszą również odróżnić niezmieniony kontrakt od niezmienionych kosztów. Transakcja może się powieść, ale zużyć inną ilość gazu. Firma, która grupuje wdrożenia lub tworzy wiele slotów pamięci, może stanąć w obliczu istotnie odmiennej struktury kosztów, nawet gdy żadna funkcja nie zawodzi. Jej produkt może wymagać innych wycen opłat, zmienionej polityki subsydiów lub zmiany sposobu przechowywania informacji. Kategorie odtwarzania Fundacji oddzielają identyczne wykonanie, zmienione, ale udane wykonanie, awarie możliwe do naprawienia przez limit oraz potencjalnie zepsute kontrakty właśnie z tego powodu.

Liczby w EIP-8037 zasługują na kolejne zastrzeżenie. Jego przykład przelicza proponowany gaz na ETH przy założonej opłacie bazowej wynoszącej 0,08 gwei. Jeśli opłata bazowa się zmieni, ETH płacone za ten sam gaz również się zmieni. Deweloper porównujący tabelę z istniejącym rachunkiem musi dodać opłaty za wykonanie i rzeczywiste warunki transakcji, zamiast przedstawiać siedmiokrotną zmianę kosztu stanu jako siedmiokrotny wzrost całkowitej płatności użytkownika. Celem propozycji jest przypisanie kosztów do zasobów; ostateczna opłata danej osoby zależy od mieszanki tych zasobów w transakcji.

Skalę proponowanej zmiany cen należy czytać wraz z celem dotyczącym przepustowości. Więcej miejsca na transakcje w bloku może sprawić, że sieć będzie droga w walidacji, jeśli te transakcje nieproporcjonalnie tworzą trwały stan. EIP-8037 przypisuje temu wzrostowi osobny licznik, aby koszt nie zniknął wewnątrz większego nagłówkowego limitu gazu. EIP-8038 dotyczy dostępu do istniejącego stanu. Rozwiązują one różne części kwestii zasobów, a sam działający konstruktor bloków nie może ustalić, że aplikacje prawidłowo obsługują zmianę cen.

Listy dostępu do bloków w Ethereum mają osobne zadanie. Informują klientów, których kont i lokalizacji pamięci dotyka blok, pomagając zorganizować część pracy walidacyjnej równolegle. Może to pozwolić na większą przepustowość w sprzyjających warunkach, ale nie usuwa trwałego magazynu dodanego przez nowe konta i sloty. Sieć testowa musi uruchomić połączoną aktualizację w realistycznej aktywności, ponieważ poprawa w jednym wymiarze może ujawnić ograniczenie w innym. Odroczenie pozostawia to połączone ćwiczenie na Hoodi na razie niewykonane.

Wielu użytkowników po raz pierwszy zetknie się z tymi zmianami pośrednio, poprzez cytowany przez ich portfel limit gazu lub szacowanie opłat przez aplikację. Transakcja, która nie tworzy nowego stanu, może mieć inny efekt niż ta wdrażająca pokaźny kontrakt. Interfejs handlowy, który obiecuje stały koszt transakcji, musiałby sprawdzić, czy jego obietnica nadal obejmuje wykonywane operacje. Uogólnienia, że wszystkie opłaty w Ethereum zmierzają w jednym kierunku, byłyby przedwczesne bez ostatecznego harmonogramu sieci głównej, zaobserwowanego popytu i ostatecznych parametrów.

Liczba 200 milionów była ustawieniem sieci testowej

Glamsterdam łączy więcej niż zmianę cen. Wpisane w protokół rozdzielenie proposera i buildera zmienia przekazywanie ładunku bloku, podczas gdy listy dostępu na poziomie bloku pomagają klientom zidentyfikować konta i pamięć, których blok dotknie. Deweloperzy planowali przetestować te zmiany z limitem gazu Hoodi wynoszącym 200 milionów, zgodnym z Sepolią. Liczba ta była parametrem sieci testowej. Nigdy nie była obietnicą, że sieć główna Ethereum natychmiast przyjmie ten sam limit lub że opłaty użytkowników spadną o określony procent.

Usunięcie harmonogramu limitu gazu Hoodi utrzymuje elementy odroczonego forka razem. Operatorzy nie będą testować zamierzonej wyższej przepustowości w ramach Glamsterdam w tej sieci w najbliższy poniedziałek. Deweloperzy mogą nadal używać Sepolii i specjalnie zbudowanych devnetów do badania skutków zmiany cen. Brakująca próba na Hoodi wpływa na kolejność, w jakiej zespoły klientów mogą nabierać pewności przed wyborem terminu mainnetu, ale Fundacja nie opublikowała zmienionego harmonogramu produkcyjnego.

Ekonomia jest mniej prosta niż slogan o tańszym gazie. Pobieranie wyższych opłat za tworzenie trwałego stanu może sprawić, że konkretna transakcja będzie droższa przy tej samej cenie gazu. Większa bezpieczna przepustowość, jeśli zostanie później przyjęta i wykorzystana, mogłaby złagodzić zatory w innych warunkach. Popyt określa, ile miejsca w bloku użytkownicy licytują, a ostateczne ustawienia protokołu decydują, które operacje stają się droższe lub tańsze. Ani pauza, ani udany test nie rozstrzygnęłyby samodzielnie tych zmiennych rynkowych.

Publiczna koordynacja ma koszty, ale kontynuowanie z znaną niepewnością może mieć większe. Operatorzy przygotowali oprogramowanie dla starej epoki i teraz muszą usunąć ten harmonogram; deweloperzy aplikacji muszą kontynuować testowanie wobec propozycji, której ostateczny kształt może się zmienić. Koszt tego resetu jest widoczny. Reguła mainnetu, która spowodowałaby awarię powszechnie używanego kontraktu, byłaby trudniejsza do odwrócenia, a skutki mogłyby obejmować fundusze lub zależne aplikacje. Zawiadomienie z 22 października nie kwantyfikuje takiego ryzyka, ale jasno pokazuje, że deweloperzy uznali tę interakcję za wystarczająco ważną, by wstrzymać próbę na Hoodi.

Zmieniona propozycja mogłaby zachować cel pobierania opłat za stan, zmieniając sposób działania rezerwuaru gazu lub zasady przejścia dla istniejących kontraktów. Mogłaby zamiast tego zachować specyfikację i wymagać ukierunkowanych poprawek aplikacji. W zawiadomieniu o odroczeniu nie pojawia się żadna publiczna decyzja między tymi ścieżkami. Czytelnicy powinni powstrzymać się od traktowania dochodzenia jako ostatecznego wyboru projektu. Precyzyjne poprawki, jeśli w ogóle będą, będą miały większe znaczenie niż to, ile dni Hoodi czeka.

Dlaczego deweloperzy zdecydowali się czekać

Proces Ethereum pozwala zespołom klientów dostosować plan przed aktywacją publicznego testnetu. Decyzja z 22 października podjęta podczas All Core Devs Execution call 248 następuje po wcześniejszych ostrzeżeniach i kontakcie z dotkniętymi budowniczymi. Publiczne zawiadomienie wskazuje obszar objęty dochodzeniem, ale nie publikuje ostatecznej liczby kontraktów zagrożonych, nowej wersji EIP-8037 ani daty zakończenia dochodzenia. Nazywanie opóźnienia potwierdzoną wadą we wszystkich wdrożonych kontraktach wykraczałoby poza treść komunikatu; nazywanie go rutynowym przetasowaniem kalendarza pomijałoby podaną przyczynę.

Stara konfiguracja musi zostać wycofana w obu warstwach. Klienci wykonawczy przetwarzają transakcje i stan, podczas gdy klienci konsensusu koordynują walidatorów i harmonogram forka. Sieć może testować aktualizację tylko wtedy, gdy ci klienci zgadzają się co do zasad i terminu. Operatorzy Hoodi, którzy zainstalowali wydania specjalnie na 26 października, muszą poszukać zmienionych informacji o wydaniu. Fundacja twierdzi, że będzie dodawać linki do nowych wersji klientów w miarę ich potwierdzania, zamiast traktować swoją pierwotną tabelę zgodności jako aktualną.

Jest też lekcja w kolejności dowodów. Odtwarzanie historii ujawniło niewielką dotkniętą grupę; publiczne testnety ujawniają zachowanie klientów i aplikacji w środowisku na żywo; mainnet wystawia ostateczne zasady na gospodarcze wykorzystanie na skalę. Każdy etap odpowiada na coś, czego poprzedni nie może. Krótkie opóźnienie na Hoodi może kupić czas na prace nad kontraktami, ale samo w sobie nie dowodzi, że ostateczne zasady są bezpieczne. Decyzja o kontynuacji powinna wynikać z wyników testów i jasnych instrukcji dla operatorów.

Warto doprecyzować zakres zawiadomienia dla operatorów. Zwykły posiadacz mainnetu nie musi zmieniać portfela, ponieważ harmonogram Hoodi został wycofany. Operator węzła Hoodi, który przygotował się do forka, musi ponownie przejrzeć informacje o wydaniu. Inżynier protokołu badający EIP musi ustalić, czy zachowanie kontraktu znalezione w odtworzeniach jest akceptowalne, możliwe do naprawienia za pomocą narzędzi, czy stanowi powód do zmiany propozycji. Zespół aplikacji musi przetestować własne ścieżki wykonania. To różne grupy odbiorców z różnymi terminami, a pojedynczy alert „aktualizacja opóźniona” nie daje każdej z nich właściwej instrukcji.

Następny post Fundacji może również rozstrzygnąć, w jaki sposób deweloperzy będą komunikować się z dotkniętymi zespołami. Jej sierpniowy przewodnik mówił, że rozpoczęto bezpośredni kontakt, ale sama liczba kontaktów nie ustaliłaby, że kontrakt został naprawiony. Możliwym do przetestowania dowodem jest zaktualizowany kontrakt, zmieniona konfiguracja gazu lub udokumentowany plan awaryjny dla konkretnego produktu. Niektóre niezmienne kontrakty mogą wymagać migracji użytkowników, co rodzi odrębny problem komunikacyjny i bezpieczeństwa: klienci muszą wiedzieć, gdzie znajduje się legalny zamiennik, i unikać oszukańczych adresów. Nie ogłoszono masowej migracji, więc pozostaje to rozwiązaniem awaryjnym dla zespołów, których kodu nie można zmienić w miejscu.

Co poprzedza inną datę

Zrewidowany harmonogram powinien określać, które zasady EIP-8037 będą testowane, co się zmieniło, jeśli propozycja zostanie zmieniona, oraz które wersje klientów zgadzają się co do nowej epoki Hoodi. Opiekunowie aplikacji potrzebują czasu na przeprowadzenie wyszukiwań w dotkniętych kontraktach, aktualizację estymatorów, podniesienie limitów tam, gdzie to wystarczy, oraz zbadanie zakodowanych na stałe wewnętrznych limitów wywołań tam, gdzie to nie wystarczy. Jeśli potencjalnie uszkodzony wdrożony kontrakt nie ma bezpośredniej ścieżki aktualizacji, jego zespół może potrzebować wyjaśnić, w jaki sposób użytkownicy dotrą do zamiennika przed jakimkolwiek forkiem mainnetu.

Publiczne dowody obejmowałyby metodologię odtwarzania i zaktualizowane ustalenia dotyczące dotkniętych kontraktów, wyniki z devnetów z ostatecznym harmonogramem gazu, aktywację Hoodi z różnorodnymi klientami w zgodzie oraz osobne ogłoszenie dotyczące mainnetu. Nawet czysta aktywacja Hoodi byłaby próbą generalną, a nie gwarancją konkretnej ceny ETH lub ostatecznej opłaty transakcyjnej. Praktyczna historia dla użytkowników jest taka, że nie ogłoszono żadnego działania w mainnecie na 26 października. Natychmiastowe działanie należy do operatorów Hoodi i zespołów, których aplikacje przyjmują założenia dotyczące gazu.

Na co uważać

• Wydania klientów: Aktualizacje wykonawcze i konsensusu, które wyraźnie usuwają starą aktywację Hoodi z 26 października.
• Wyniki EIP-8037: Nowe wyniki odtwarzania, zmiany w proponowanych regułach gazu oraz traktowanie kontraktów z zakodowanymi na stałe limitami lub logiką gasleft().
• Zastępcza epoka: Datowany plan Hoodi, który przywraca testowalną konfigurację po zakończeniu dochodzenia.
• Poprawki aplikacji: Raporty od dotkniętych deweloperów wyjaśniające, czy wyższe limity wystarczą, czy wdrożony kod wymaga innej drogi.
• Komunikat dotyczący mainnetu: Odrębny harmonogram produkcyjny od Fundacji po sekwencji testnetu i koordynacji klientów.

FAQ