Oczekujące transakcje Ethereum: nonce, zastępowanie i anulowanie

Po podpisaniu transakcji Ethereum portfel może wysłać ją do klienta wykonawczego lub usługi obsługi transakcji. Węzły, które ją zaakceptują, mogą przekazać ją innym węzłom, a proponujący blok może później umieścić ją w bloku. Do czasu włączenia transakcja nie zmieniła stanu łańcucha kanonicznego. Etykieta „pending” w portfelu lub eksploratorze zwykle oznacza, że dana usługa zna transakcję, ale nie zaobserwowała jej jeszcze w bloku; nie wskazuje jednej uniwersalnej kolejki sieciowej. Przewodnik po transakcjach Ethereum.org opisuje drogę od podpisania i rozgłoszenia transakcji do jej włączenia do bloku.

Transakcja może czekać z kilku powodów. Jej limity opłat mogą nie spełniać warunków włączenia do bloku, wcześniejsza transakcja z tego samego konta może pozostawać nierozstrzygnięta, węzeł mógł jej nie otrzymać albo portfel może wyświetlać nieaktualne lub zależne od dostawcy informacje. Każda z tych przyczyn wymaga innych kontroli. Podwyższenie opłaty nie naprawi wyboru niewłaściwej sieci, a wysłanie kolejnej płatności bez sprawdzenia pierwszej może doprowadzić do podwójnej płatności.

„Pending” różni się również od „confirmed”, „finalized” i „failed”. Hash transakcji może być widoczny, zanim pojawi się jej receipt; receipt staje się dostępny po włączeniu transakcji do bloku. Następnie bloki Ethereum przechodzą przez stany konsensusu. Portfele i eksploratory mogą różnie używać tych etykiet, dlatego sprawdź hash transakcji, blok, receipt i bieżący stan łańcucha, zamiast polegać na jednej krótkiej etykiecie statusu.

Zwykłe konto Ethereum kontrolowane zewnętrznie (externally owned account, EOA) ma nonce, który porządkuje jego transakcje. Nonce to licznik, a nie opłata, znacznik czasu ani unikatowy hash transakcji. Dla każdego konta łańcuch akceptuje transakcję tylko wtedy, gdy używa ona kolejnego nonce oczekiwanego na podstawie stanu konta. To samo konto nie może wykonać dwóch transakcji z tym samym nonce w łańcuchu kanonicznym. Dokumentacja kont Ethereum.org opisuje nonce jako licznik transakcji konta i mechanizm ochrony przed ponownym odtworzeniem transakcji.

Załóżmy, że kolejne niewykorzystane nonce konta to 41. Następna prawidłowa transakcja używa nonce 41; po jej włączeniu do bloku i zastosowaniu kolejna transakcja użyje nonce 42. Nonce jest powiązany z kontem nadawcy, a nie adresem odbiorcy. Dwa różne konta mogą mieć jednocześnie transakcję o numerze 41, ponieważ każde ma własną sekwencję.

Transakcję można podpisać z nonce wyższym niż bieżący nonce konta w łańcuchu, ale podczas wykonania nie da się przeskoczyć kolejności. Najpierw trzeba zużyć brakujące wcześniejsze nonce. Transakcja z nonce już zużytym przez konto jest nieaktualna i nie może zostać wykonana jako nowa transakcja. Dzięki tej kolejności sieć przetwarza transakcje każdego konta po kolei, nawet jeśli są rozgłaszane w różnym czasie lub trafiają do różnych węzłów.

Reguła nonce dotyczy zwykłych transakcji EOA w warstwie wykonawczej Ethereum. Nie opisuje uniwersalnie wszystkich abstrakcji portfeli, sekwencerów rollupów ani łańcuchów. Systemy smart kont mogą dodawać własne reguły operacji i nonce, o czym mowa w dalszej części tego przewodnika.

Ethereum nie ma jednej zsynchronizowanej poczekalni, którą każdy portfel, węzeł, eksplorator bloków i proponujący blok widzi dokładnie tak samo. Każdy klient wykonawczy utrzymuje lokalną pulę transakcji, które otrzymał i uznał za kwalifikujące się według własnych limitów i zasad. Transakcja może znajdować się w puli jednego węzła, a nie być dostępna w innym. Dokumentacja RPC txpool Geth udostępnia lokalne grupy pending i queued tego klienta oraz wskazuje, że z tym samym nadawcą i nonce może być powiązanych kilka transakcji.

W terminologii Geth pending oznacza na ogół transakcje, które można przetwarzać według kolejności nonce od bieżącego stanu konta; queued może obejmować transakcje z przyszłymi nonce, które czekają na zamknięcie luki. Są to nazwy elementów interfejsu klienta, a nie stany konsensusu, które musi pokazywać każde oprogramowanie Ethereum. Portfel może nazwać całą listę niepotwierdzonych transakcji „pending”, a eksplorator może wyświetlać tylko transakcje zaobserwowane przez jego dostawców danych.

Jeśli na przykład węzeł zna transakcję z nonce 41 i kolejną z nonce 43, nie może wykonać 43 przed 42. Może przechować 43 w kolejce, dopóki nie dotrze 42 lub konto nie przesunie się naprzód w inny sposób. Inny węzeł, który nigdy nie otrzymał 43, w ogóle jej nie pokaże. Dlatego dwa eksploratory mogą różnić się w ocenie, czy transakcja jest pending czy jej nie znaleziono, a żaden z tych ekranów nie dowodzi, co widzieli wszyscy walidatorzy.

Niektóre klienty dopuszczają też więcej niż jedną niepotwierdzoną transakcję-kandydata dla tego samego nadawcy i nonce. To alternatywy konkurujące o ten sam slot sekwencji, a nie dwie transakcje, które mogą zostać zastosowane po kolei. Pojemność puli, czas przechowywania transakcji i zasady zastępowania to polityki implementacji, które mogą się zmieniać między wersjami oprogramowania. Na przykład konfigurowalne opcje puli transakcji Geth obejmują specyficzny dla klienta próg podwyżki ceny; nie należy traktować go jak uniwersalnej reguły opłat Ethereum. Zakres tych opcji opisuje dokumentacja poleceń Geth.

Wyobraź sobie, że kolejne nonce konta w łańcuchu to 41. Rozgłaszasz transakcję A z nonce 41, a potem transakcję B z nonce 42. Jeśli A pozostaje nierozstrzygnięta, B nie może zostać zastosowana jako pierwsza. B może czekać w lokalnej kolejce, pojawić się jako pending tylko w portfelu albo nie być widoczna w eksploratorze, który jej nie otrzymał. Znaczenie ma kolejność nonce, a nie kolejność, w jakiej portfel utworzył lub wyświetlił te dwie transakcje.

Jeśli A zostanie w końcu włączona do bloku, nonce konta przejdzie na 42, a B może stać się kwalifikująca do wykonania, zależnie od własnej poprawności, warunków opłat i zasad puli. Jeśli A zostanie zastąpiona inną prawidłową transakcją z nonce 41, zastępca zajmie to samo miejsce w sekwencji, o ile to on zostanie włączony. Jeśli nonce 41 zużyła inna transakcja z tego konta, stary kandydat z nonce 41 jest nieaktualny i nie może już zostać wykonany.

Dlatego wysłanie nowej transakcji z wyższym nonce nie jest uniwersalnym sposobem na odblokowanie transakcji. Dodaje kolejną transakcję za luką. Anulowanie B również nie rozwiąże problemu A, jeśli B jest transakcją późniejszą. Zanim cokolwiek zmienisz, sprawdź stan najwcześniejszego nierozstrzygniętego nonce konta.

Luka może być chwilowa albo utrzymywać się dłużej. Wcześniejsza transakcja mogła nie dotrzeć do sprawdzanego węzła, jej opłaty mogą być nieatrakcyjne lub niewystarczające w obecnych warunkach albo węzeł mógł usunąć ją ze swojej puli. Portfel może też pokazywać transakcję queued utworzoną na innym urządzeniu. Sam ekran nie wskazuje, co się wydarzyło; porównaj potwierdzone nonce konta, hashe transakcji i więcej niż jeden wiarygodny widok.

Kolejność nonce i kwalifikowalność opłat to osobne ograniczenia. Transakcja z prawidłowym kolejnym nonce może nadal czekać, jeśli jej parametry opłat nie spełniają warunków dla bloku. Transakcja z wyższym nonce nie przeskoczy kolejki tylko dlatego, że oferuje większy napiwek. Podwyższenie opłaty dla nonce 42 nie usuwa nonce 41.

W standardowej transakcji EIP-1559 maksymalna opłata musi wystarczyć na pokrycie base fee bloku, który ją włączy, a priority fee może wpływać na wybór proponującego blok. W czasie oczekiwania mogą się zmieniać zarówno base fee, jak i dostępne miejsce w bloku. Maksymalna opłata jest limitem; wyższy limit nie gwarantuje konkretnego czasu potwierdzenia. Przewodnik po opłatach za gas w Ethereum wyjaśnia te pola i sposób obliczania efektywnej opłaty.

Węzeł lub portfel może stosować dodatkowe zasady przekazywania lub zastępowania transakcji. Określają one, co dana usługa chce zaakceptować lub przekazać dalej; nie wszystkie są regułami konsensusu. Na przykład Geth udostępnia konfigurowalny próg podwyżki ceny przy zastępowaniu transakcji pending we własnej puli. Inny klient, dostawca, portfel lub wersja oprogramowania może działać inaczej. Nie traktuj zapamiętanego procentu ani stałego czasu oczekiwania jako gwarancji obowiązującej w całej sieci.

Jeśli transakcja czeka, bo nierozstrzygnięte jest niższe nonce, najpierw ustal, która transakcja je wykorzystuje. Jeśli czeka, bo limit opłaty nie pokrywa obecnych warunków base fee, przed jego zmianą poznaj znaczenie poszczególnych pól. Przewodnik po opłatach Ethereum pomaga w obliczeniach opłat; ten artykuł skupia się na odrębnym problemie kolejności.

Funkcja „przyspiesz” w portfelu zwykle tworzy nową transakcję z tego samego konta i tym samym nonce, ale ze zmienionymi parametrami opłat. Kandydaci są sprzeczni, ponieważ konto może wykonać tylko jedną transakcję z danym nonce. Jeśli zastępca zostanie zaakceptowany w odpowiednich pulach transakcji i włączony do bloku, może zająć ten slot nonce; oryginał nie może wtedy zostać wykonany w łańcuchu kanonicznym. Instrukcja MetaMask dotycząca transakcji pending opisuje przyspieszenie jako ponowne wysłanie z tym samym nonce i wyższą opłatą.

Zastępca może zachować pierwotny adres docelowy i działanie, a zmienić tylko pola opłat, ale sprawdź ekran podpisywania zamiast zakładać, że tak jest. Implementacja portfela może udostępniać inne pola albo inaczej opisywać tę funkcję. Przed podpisaniem zastępcy sprawdź konto nadawcy, nonce, adres docelowy, wartość i dane kontraktu. Jeśli zastępca zmienia działanie transakcji, nie jest to tylko nieszkodliwa korekta opłaty.

Nie ma gwarancji, że zastępca zostanie wszędzie zaakceptowany ani szybko włączony do bloku. Oryginał mógł już zostać włączony; węzeł może odrzucić zastępcę zgodnie ze swoją polityką; zastępca może nadal być nieatrakcyjny dla proponującego blok; usługa może też nie przekazać go węzłom, które monitorujesz. Jeśli oryginał został już potwierdzony, wysłanie kolejnej transakcji z zużytym nonce nie cofnie go i zwykle zakończy się odrzuceniem jako nieaktualnej.

„Zastępca” oznacza tu konkurencyjną transakcję z tego samego konta i tym samym nonce. Nie stosuj procedur Bitcoin RBF ani CPFP do Ethereum. Bitcoin korzysta z innego modelu transakcji, a jego mechanizmy podwyższania opłat nie są instrukcjami dla kont Ethereum.

Po rozgłoszeniu podpisanej transakcji Ethereum nie istnieje protokołowa komenda cofnięcia, która usunie ją ze wszystkich węzłów. Niektóre portfele oferują anulowanie, gdy transakcja jest jeszcze niepotwierdzona. Zazwyczaj próbuje ono opublikować inną transakcję z tego samego konta i tym samym nonce; częsty wzorzec w portfelach to transakcja o wartości zero na własny adres nadawcy. Jeśli kandydat anulujący zostanie zaakceptowany i włączony przed oryginałem, zużyje nonce, przez co oryginalnego kandydata nie będzie można wykonać później. Dokładna konstrukcja i dostępność zależą od portfela.

Oryginalna transakcja i kandydat anulujący mogą ze sobą rywalizować. Jeśli oryginał zostanie włączony jako pierwszy, później wysłane anulowanie nie cofnie jego skutków. Jeśli żaden kandydat nie zostanie zaakceptowany ani włączony, nonce może pozostać nierozstrzygnięte. Kliknięcie przycisku w portfelu ani komunikat o powodzeniu nie dowodzą, że anulowanie wygrało. Sprawdź wynikowy hash transakcji i status na łańcuchu kanonicznym. Instrukcje MetaMask wyraźnie ograniczają próbę anulowania do transakcji, która nadal jest pending, i wyjaśniają, że potwierdzonej transakcji nie można anulować.

Przed podpisaniem transakcji anulującej sprawdź, czy używa tego samego konta i nonce co transakcja, którą chcesz wyprzeć, oraz przejrzyj każde pole wyświetlane przez portfel. Jej włączenie może wymagać kolejnej opłaty sieciowej. Sama transakcja anulująca również może czekać lub nie zastąpić oryginału ze względu na zasady właściwej puli transakcji. Etykieta „anulowano” w portfelu nie dowodzi cofnięcia na poziomie protokołu; wynik uznaj za potwierdzony dopiero po sprawdzeniu, która transakcja zużyła nonce.

Jeśli transakcja wykonała już zatwierdzenie tokena, wywołanie kontraktu lub transfer, anulowanie późniejszej transakcji nie cofnie zakończonej zmiany stanu. Niektóre działania kontraktów mają osobne metody następcze, ale ich dostępność i skutki zależą od kontraktu. Nie podpisuj nieznanej transakcji tylko dlatego, że interfejs nazywa ją anulowaniem.

Włączona transakcja ma blok i receipt. Jeśli zakończy się powodzeniem, zamierzone zmiany stanu mogły zostać zastosowane. Jeśli wykonanie EVM zakończy się revert, zmiany stanu z tego wykonania są wycofywane, ale transakcja nadal zużyła nonce konta i może wiązać się z opłatą za gas. Sprawdź receipt i status wykonania zamiast wnioskować o powodzeniu z powiadomienia portfela. Przeczytaj przewodnik po transakcjach Ethereum i przewodnik po gas, aby poznać różnicę między włączeniem do bloku a wynikiem wykonania.

Etykieta „dropped” lub „not found” często jest informacją z jednego portfela, eksploratora, dostawcy RPC albo lokalnej puli. Sama w sobie nie dowodzi, że protokół anulował transakcję ani że nonce jest wolne. Inny węzeł może nadal ją znać; portfel może ponownie rozgłosić podpisaną transakcję; późniejszy blok może też wykazać, że nonce konta już wzrosło. Z drugiej strony stara transakcja może nie być widoczna w sprawdzonych widokach, choć potwierdzone nonce konta się nie zmieniło.

Jeśli hash transakcji nie zostanie znaleziony, sprawdź, czy wybrano tę samą sieć i konto, z których ją utworzono. Porównaj najnowsze nonce konta w łańcuchu z nonce transakcji i sprawdź ostatnie transakcje tego nadawcy. Odpowiedź nonce too low sugeruje, że według danego endpointu nonce mogło już zostać zużyte; nie jest powodem do ponawiania tego samego żądania. Ustal, która transakcja je wykorzystała i czy blok nadal jest kanoniczny.

Włączona transakcja może również zostać dotknięta krótkotrwałą reorganizacją łańcucha, zanim łańcuch się ustabilizuje. Portfele i eksploratory mogą aktualizować etykiety wraz ze zmianą ich widoku. W przypadku ważnego transferu poczekaj zgodnie z polityką potwierdzeń usługi odbierającej, a w razie potrzeby także na silniejszą finalność konsensusu. „Widoczna w jednym bloku” i „nieodwracalna w każdych okolicznościach” to różne stwierdzenia.

Najpierw potwierdź łańcuch, konto nadawcy i hash transakcji. Wyszukaj hash w zaufanym eksploratorze dla właściwej sieci. Sprawdź, czy istnieje receipt, jakie nonce wykorzystano, czy wykonanie się powiodło i czy konto wysłało późniejszą transakcję. Nie ujawniaj ani nie wpisuj frazy seed, aby sprawdzić transakcję; do wyszukiwania w publicznym łańcuchu wystarczą publiczny adres i hash transakcji.

Jeśli hash nie jest widoczny, porównaj ostatnie potwierdzone nonce konta z wartością pokazywaną przez portfel. Programista lub operator węzła może wywołać eth_getTransactionCount z tagami bloków latest i pending. Dokumentacja JSON-RPC Ethereum.org definiuje te tagi: latest oznacza stan najnowszego bloku, a pending — stan pending. Wynik pending nadal zależy od widoku danego endpointu RPC; dwóch dostawców może zwrócić różne wartości. Większość użytkowników może uzyskać te same pierwsze wskazówki z aktywności konta w portfelu i zaufanego eksploratora, bez uruchamiania poleceń.

Następnie zacznij od najniższego nonce, które nie zostało zużyte. Jeśli oryginalna transakcja jest nadal widoczna, a portfel obsługuje zastępowanie, przed podpisaniem dokładnie sprawdź pola i ustawienia opłat zastępcy. Jeśli jej nie widać, zapytaj portfel lub dostawcę RPC, jak obsługuje ponowne wysyłanie i zastępowanie, zamiast zakładać, że transakcja zniknęła z sieci. Jeśli nonce jest już zużyte, najpierw ustal, jaka transakcja została włączona. Unikaj wielokrotnego wysyłania nowych transakcji z późniejszymi nonce; może to wydłużyć kolejkę, nie rozwiązując pierwszej luki.

Te kroki dotyczą standardowych transakcji Ethereum z kont zewnętrznych. Systemy abstrakcji kont mogą wysyłać UserOperation za pośrednictwem bundlerów, a smart konta mogą używać kluczy nonce i sekwencji wykraczających poza jeden prosty licznik. EIP-4337 definiuje strukturę nonce dla tych operacji, dlatego portfel korzystający z abstrakcji kont może działać inaczej niż przykłady EOA w tym artykule. Informacje o sieciach docelowych, adresach i statusie transferu znajdziesz w liście kontrolnej transferu krypto.