Openstaande Ethereum-transacties uitgelegd: nonces, vervangen en annuleren

Nadat je een Ethereum-transactie hebt ondertekend, kan je wallet deze naar een uitvoeringsclient of transactiedienst sturen. Nodes die de transactie accepteren, kunnen haar doorgeven aan peers; een blokvoorsteller kan haar later in een blok opnemen. Tot dat moment heeft de transactie de canonieke ketentoestand niet veranderd. Het label “pending” in een wallet of block explorer betekent meestal dat die dienst de transactie kent, maar haar nog niet in een blok heeft waargenomen. Het verwijst niet naar één universele netwerkwachtrij. De transactiegids van Ethereum.org beschrijft de weg van ondertekenen en uitzenden tot opname in een blok.

Een transactie kan om verschillende redenen wachten. De fee-limieten voldoen mogelijk niet aan de voorwaarden voor een blok, een eerdere transactie van dezelfde account kan nog onopgelost zijn, een node heeft de transactie misschien niet ontvangen of de wallet toont verouderde of providerafhankelijke informatie. Voor elk van deze oorzaken zijn andere controles nodig. Een hogere fee herstelt geen verkeerde netwerkselectie; een tweede betaling versturen zonder de eerste te controleren kan tot een dubbele betaling leiden.

“Pending” is ook iets anders dan “confirmed”, “finalized” of “failed”. Een transactiehash kan zichtbaar zijn voordat er een receipt bestaat; na opname in een blok is een receipt beschikbaar. Daarna doorlopen Ethereum-blokken consensusstatussen. Wallets en block explorers gebruiken deze labels mogelijk verschillend. Controleer daarom de transactiehash, het blok, de receipt en de huidige ketentoestand in plaats van op één kort statuslabel te vertrouwen.

Een gewone extern beheerde Ethereum-account (externally owned account, EOA) heeft een nonce die de transacties ordent. De nonce is een teller, geen fee, tijdstempel of unieke transactiehash. Voor elke account accepteert de keten een transactie alleen als deze de volgende nonce gebruikt die op basis van de accountstatus wordt verwacht. Dezelfde account kan op de canonieke keten niet twee transacties met dezelfde nonce uitvoeren. De accountdocumentatie van Ethereum.org beschrijft de nonce als de transactieteller van de account en een mechanisme tegen replay-aanvallen.

Stel dat de eerstvolgende ongebruikte nonce van een account 41 is. De volgende geldige transactie gebruikt nonce 41; nadat die transactie is opgenomen en uitgevoerd, gebruikt de volgende transactie nonce 42. De nonce hoort bij de verzendende account, niet bij een bestemmingsadres. Twee verschillende accounts kunnen tegelijkertijd allebei een transactie met nummer 41 hebben, omdat elke account een eigen reeks heeft.

Je kunt een transactie ondertekenen met een nonce die hoger is dan de huidige on-chain nonce van de account, maar bij uitvoering kan de transactie de volgorde niet overslaan. De ontbrekende eerdere nonce moet eerst worden verbruikt. Een transactie met een nonce die de account al heeft verbruikt, is verouderd en kan niet meer als nieuwe transactie worden uitgevoerd. Dankzij deze volgorde kan het netwerk de transacties van elke account sequentieel verwerken, ook als ze op verschillende momenten worden uitgezonden of via verschillende nodes aankomen.

De nonceregel geldt voor gewone EOA-transacties op de Ethereum-uitvoeringslaag. Het is geen universele beschrijving van elke walletabstractie, rollup-sequencer of blockchain. Smart-accountsystemen kunnen eigen regels voor operaties en nonces toevoegen; die komen later in deze gids aan bod.

Ethereum heeft geen enkele gesynchroniseerde wachtruimte die elke wallet, node, block explorer en blokvoorsteller precies hetzelfde ziet. Elke uitvoeringsclient bewaart een lokale transactiepools met transacties die hij heeft ontvangen en op basis van eigen limieten en beleid geschikt acht. Een transactie kan in de pool van de ene node staan en ontbreken bij een andere. De RPC-documentatie voor txpool van Geth toont de lokale groepen pending en queued van die client en vermeldt dat meerdere transacties bij dezelfde afzender en nonce kunnen horen.

In de terminologie van Geth verwijst pending doorgaans naar transacties die vanaf de huidige accountstatus in noncevolgorde kunnen worden verwerkt; queued kan transacties met toekomstige nonces bevatten die wachten tot een gat is gedicht. Deze namen beschrijven een clientinterface, geen consensusstatussen die alle Ethereum-software moet weergeven. Een wallet kan de volledige lijst onbevestigde transacties “pending” noemen, terwijl een block explorer alleen transacties toont die zijn eigen dataproviders hebben waargenomen.

Stel bijvoorbeeld dat een node een transactie met nonce 41 kent en ook een met nonce 43. Dan kan de node 43 niet vóór 42 uitvoeren. De node kan 43 in de wachtrij houden totdat 42 aankomt of de account op een andere manier verdergaat. Een andere node die 43 nooit heeft ontvangen, toont deze helemaal niet. Daarom kunnen twee block explorers van mening verschillen over de vraag of een transactie pending of niet gevonden is, zonder dat een van beide schermen bewijst wat alle validators hebben gezien.

Sommige clients staan ook meer dan één onbevestigde transactiekandidaat toe voor dezelfde afzender en nonce. Dat zijn alternatieven die om dezelfde plek in de reeks concurreren, geen transacties die allebei op volgorde kunnen worden toegepast. Poolcapaciteit, de levensduur van transacties en vervangingsregels zijn implementatiebeleid en kunnen per softwareversie veranderen. De configureerbare transactiepoolopties van Geth bevatten bijvoorbeeld een clientspecifieke prijsverhogingsdrempel; dat is geen universele Ethereum-feeregel. Zie de Geth-opdrachtregelreferentie voor de reikwijdte van die opties.

Stel dat de volgende on-chain nonce van een account 41 is. Je zendt transactie A met nonce 41 uit en daarna transactie B met nonce 42. Zolang A onopgelost blijft, kan B niet eerst worden toegepast. B kan in een lokale wachtrij staan, alleen in de wallet als pending verschijnen of ontbreken bij een block explorer die de transactie niet heeft ontvangen. De noncevolgorde is bepalend, niet de volgorde waarin de wallet de twee transacties heeft aangemaakt of weergegeven.

Als A uiteindelijk wordt opgenomen, gaat de nonce van de account naar 42 en kan B daarna in aanmerking komen, afhankelijk van de eigen geldigheid, feevoorwaarden en poolregels. Wordt A vervangen door een andere geldige transactie met nonce 41, dan neemt de vervanger diezelfde plek in de reeks in als juist die transactie wordt opgenomen. Heeft een andere transactie van de account nonce 41 verbruikt, dan is de oude kandidaat met nonce 41 verouderd en kan die niet alsnog worden uitgevoerd.

Daarom is een nieuwe transactie met een hogere nonce geen algemene manier om een vastgelopen transactie los te krijgen. Je voegt alleen nog een transactie achter het gat toe. B annuleren lost A evenmin op als B de latere transactie is. Begin bij de vroegste onopgeloste nonce van de account en controleer de status voordat je iets wijzigt.

Een gat kan tijdelijk of hardnekkig zijn. De eerdere transactie heeft de node die je controleert misschien niet bereikt, de fee-instellingen zijn mogelijk onaantrekkelijk of ontoereikend voor de huidige omstandigheden, of de transactie is uit de pool van één node verwijderd. Een wallet kan ook een queued-transactie tonen die op een ander apparaat is aangemaakt. Het scherm vertelt niet welke situatie geldt. Vergelijk de bevestigde nonce van de account, de transactiehashes en meerdere betrouwbare weergaven.

Noncevolgorde en fee-geschiktheid zijn afzonderlijke voorwaarden. Een transactie met de juiste volgende nonce kan toch wachten als de feeparameters niet voldoen aan de voorwaarden voor een blok. Een transactie met een hogere nonce kan niet voorgaan door simpelweg een hogere fooi te bieden. De fee voor nonce 42 verhogen laat nonce 41 niet verdwijnen.

Bij een standaard EIP-1559-transactie moet de maximale fee de base fee kunnen dekken van het blok waarin de transactie wordt opgenomen. De priority fee kan de keuze van een blokvoorsteller beïnvloeden. Zowel de base fee als de beschikbare blokruimte kan veranderen terwijl een transactie wacht. De maximale fee is een limiet; een hogere limiet garandeert geen bepaalde bevestigingstijd. De Ethereum-gids voor gaskosten legt deze velden en de berekening van de effectieve fee uit.

Een node of wallet kan aanvullende doorstuur- of vervangingsregels toepassen. Dat beleid bepaalt wat die specifieke dienst wil accepteren of doorsturen; niet al deze regels zijn consensusregels. Geth biedt bijvoorbeeld een instelbare prijsverhogingsdrempel voor het vervangen van een pending-transactie in de eigen pool. Een andere client, provider, wallet of softwareversie kan zich anders gedragen. Vertrouw niet op een onthouden percentage of een vaste wachttijd als netwerkbrede garantie.

Wacht je transactie omdat een lagere nonce onopgelost is, zoek dan eerst de transactie die die nonce gebruikt. Wacht ze omdat de fee-cap de huidige base-feevoorwaarden niet dekt, begrijp dan de feevelden voordat je ze aanpast. De Ethereum-feegids is geschikt voor fee-berekeningen; dit artikel gaat over het afzonderlijke volgordeprobleem.

De functie “versnellen” van een wallet maakt doorgaans een nieuwe transactie vanaf dezelfde account met dezelfde nonce en aangepaste feeparameters. De twee kandidaten botsen, omdat de account maar één transactie met die nonce kan uitvoeren. Als de vervanger door relevante transactiepools wordt geaccepteerd en opgenomen, kan deze de nonceplek innemen; de oorspronkelijke transactie kan dan niet ook op de canonieke keten worden uitgevoerd. De uitleg van MetaMask over pending-transacties beschrijft versnellen als opnieuw verzenden met dezelfde nonce en een hogere fee.

De vervanger kan de oorspronkelijke bestemming en actie behouden en alleen de feevelden aanpassen, maar controleer het ondertekeningsscherm in plaats van dat aan te nemen. Een walletimplementatie kan andere velden tonen of de actie anders noemen. Controleer vóór ondertekening van een vervanger de afzenderaccount, nonce, bestemming, waarde en contractgegevens. Verandert de vervanger wat de transactie doet, dan is het niet slechts een onschuldige fee-aanpassing.

Het is niet gegarandeerd dat een vervanger overal wordt geaccepteerd of snel wordt opgenomen. De oorspronkelijke transactie kan al zijn opgenomen, een node kan de vervanger volgens eigen beleid weigeren, de vervanger kan nog steeds niet aantrekkelijk genoeg zijn voor een blokvoorsteller of de dienst kan hem niet doorsturen naar de nodes die je volgt. Is de oorspronkelijke transactie al bevestigd, dan kan een nieuwe transactie met die verbruikte nonce haar niet ongedaan maken en wordt deze doorgaans als verouderd afgewezen.

Met “vervanger” bedoelen we hier een concurrerende transactie vanaf dezelfde account met dezelfde nonce. Pas Bitcoin-procedures voor RBF of CPFP niet toe op Ethereum. Bitcoin gebruikt een ander transactiemodel en de mechanismen om daar fees te verhogen zijn geen instructies voor Ethereum-accounts.

Nadat een ondertekende Ethereum-transactie is uitgezonden, bestaat er geen annuleringsopdracht op protocolniveau die haar bij alle nodes kan intrekken. Sommige wallets bieden een annuleerfunctie zolang een transactie nog niet is bevestigd. Die functie probeert doorgaans een andere transactie vanaf dezelfde account met dezelfde nonce te publiceren. Een veelgebruikte aanpak in wallets is een transactie met waarde nul naar het eigen adres van de afzender. Als de annuleringskandidaat vóór de oorspronkelijke transactie wordt geaccepteerd en opgenomen, verbruikt deze de nonce en kan de oorspronkelijke kandidaat later niet meer worden uitgevoerd. De precieze opzet en beschikbaarheid hangen af van de wallet.

De oorspronkelijke transactie en de annuleringskandidaat kunnen tegen elkaar racen. Wordt de oorspronkelijke transactie eerst opgenomen, dan kan een later verstuurde annulering de gevolgen niet ongedaan maken. Wordt geen van beide geaccepteerd of opgenomen, dan kan de nonce onopgelost blijven. Een klik op de walletknop of een succesmelding bewijst niet dat de annulering heeft gewonnen. Controleer de resulterende transactiehash en de status op de canonieke keten. De instructies van MetaMask beperken de annuleringspoging nadrukkelijk tot een transactie die nog pending is en leggen uit dat een bevestigde transactie niet kan worden geannuleerd.

Controleer vóór ondertekening van een annuleringstransactie of deze dezelfde account en nonce gebruikt als de transactie die je wilt verdringen. Bekijk ook elk veld dat de wallet toont. Bij opname kan opnieuw een netwerkfee verschuldigd zijn. De annuleringskandidaat zelf kan wachten of volgens het beleid van de betreffende transactiepools niet in staat zijn de oorspronkelijke transactie te vervangen. Het woord “geannuleerd” in een wallet bewijst geen terugdraaiing op protocolniveau. Beschouw de uitkomst pas als bevestigd nadat je hebt gecontroleerd welke transactie de nonce heeft verbruikt.

Heeft de transactie al een tokenmachtiging, contractaanroep of overdracht uitgevoerd, dan kan het annuleren van een latere transactie die voltooide statuswijziging niet terugdraaien. Sommige contractacties hebben aparte vervolgmethoden, maar de beschikbaarheid en gevolgen hangen van het contract af. Onderteken geen onbekende transactie alleen omdat een interface haar een annulering noemt.

Een opgenomen transactie heeft een blok en een receipt. Bij succes kunnen de bedoelde statuswijzigingen zijn toegepast. Als de EVM-uitvoering revert, worden de statuswijzigingen uit die uitvoering teruggedraaid, maar heeft de transactie nog steeds de nonce van de account verbruikt en kunnen er gaskosten in rekening zijn gebracht. Gebruik de transactie-receipt en uitvoeringsstatus in plaats van succes af te leiden uit een walletmelding. Zie de Ethereum-transactiegids en de gasgids voor het verschil tussen opname en uitvoeringsresultaat.

Een label als “dropped” of “not found” is vaak een melding van één wallet, block explorer, RPC-provider of lokale pool. Op zichzelf bewijst het niet dat het protocol de transactie heeft geannuleerd of dat de nonce vrij is. Een andere node kan de transactie nog kennen, de wallet kan de ondertekende transactie opnieuw uitzenden of een later blok kan laten zien dat de nonce van de account al is verhoogd. Omgekeerd kan een oude transactie ontbreken in de weergaven die je hebt gecontroleerd terwijl de bevestigde nonce van de account niet is veranderd.

Als een transactiehash niet wordt gevonden, controleer dan of je dezelfde keten en account hebt geselecteerd als bij het aanmaken van de transactie. Vergelijk de nieuwste on-chain nonce van de account met de nonce van de transactie en bekijk recente transacties van die afzender. Een antwoord nonce too low is een aanwijzing dat de nonce volgens het endpoint mogelijk al is verbruikt, geen reden om hetzelfde verzoek te blijven herhalen. Controleer welke transactie de nonce gebruikte en of het blok canoniek is gebleven.

Een opgenomen transactie kan ook te maken krijgen met een kortdurende reorganisatie van de keten voordat deze is gestabiliseerd. Wallets en block explorers kunnen labels bijwerken wanneer hun weergave verandert. Volg voor een belangrijke overdracht het bevestigingsbeleid van de ontvangende dienst en, waar relevant, wacht op sterkere consensusfinaliteit. “In één blok gezien” en “onder alle omstandigheden onomkeerbaar” betekenen niet hetzelfde.

Bevestig eerst de keten, de afzenderaccount en de transactiehash. Zoek de hash op in een betrouwbare block explorer voor het juiste netwerk. Controleer of er een receipt is, welke nonce wordt gebruikt, of de uitvoering is geslaagd en of de account een latere transactie heeft gedaan. Geef je seed phrase niet prijs en voer haar nergens in om een transactie te controleren; voor openbare on-chain zoekopdrachten zijn een publiek adres en transactiehash voldoende.

Is de hash niet zichtbaar, vergelijk dan de nieuwste bevestigde nonce van de account met de nonce die je wallet toont. Een ontwikkelaar of nodebeheerder kan eth_getTransactionCount opvragen met de bloktags latest en pending. De Ethereum.org JSON-RPC-referentie definieert die tags: latest verwijst naar de toestand van het nieuwste blok en pending naar een pending-toestand. Het resultaat voor pending blijft afhankelijk van de weergave van het RPC-endpoint; twee providers kunnen verschillende waarden geven. De meeste gebruikers krijgen dezelfde eerste aanwijzingen uit de accountactiviteit van de wallet en een betrouwbare block explorer, zonder opdrachten uit te voeren.

Werk daarna vanaf de laagste nonce die nog niet is verbruikt. Is de oorspronkelijke transactie nog zichtbaar en ondersteunt de wallet vervanging, controleer dan vóór ondertekening de precieze velden en fee-instellingen van de vervanger. Is ze niet zichtbaar, vraag de wallet of RPC-provider dan hoe deze opnieuw verzenden en vervangen behandelt in plaats van aan te nemen dat de transactie uit het netwerk is verdwenen. Is de nonce al verbruikt, zoek dan eerst uit welke transactie is opgenomen. Verstuur niet steeds nieuwe transacties met hogere nonces; daarmee kun je de wachtrij verlengen zonder het eerste gat op te lossen.

Deze stappen gaan over standaard Ethereum-transacties van extern beheerde accounts. Accountabstractiesystemen kunnen UserOperations via bundlers versturen en smart accounts kunnen nonce-sleutels en reeksen gebruiken die verder gaan dan één eenvoudige teller. EIP-4337 definieert een nonce-structuur voor die operaties. Een wallet met accountabstractie kan zich daarom anders gedragen dan de EOA-voorbeelden in dit artikel. Raadpleeg voor doelnetwerken, adressen en de status van een overdracht de checklist voor crypto-overdrachten.