Vai al contenuto
Financial Context Wiki

Namespace dei nonce nelle criptovalute

Guida pratica ai nonce degli account Ethereum, ai nonce applicativi anti-replay, alle lane key-sequence ERC-4337 e ai nonce di ricerca negli header Proof of Work.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

Un nonce è un valore il cui significato deriva da uno specifico namespace di protocollo. Non indica sempre un numero casuale o un valore universale «usato una sola volta». In Ethereum, lo state nonce di un externally owned account ordina e convalida le transazioni del mittente. Un contratto può conservare nonce applicativi separati nello storage per permit o intent firmati. Gli smart account ERC-4337 possono usare un nonce strutturato di UserOperation con lane parallele per chiave e sequenza. Nel Proof of Work di Bitcoin, il nonce dell’header è un campo di ricerca limitato usato per provare hash candidati.

Questi valori non sono intercambiabili. Un nonce di account Ethereum non protegge una firma arbitraria di typed data se l’applicazione non verifica il proprio dominio e campo anti-replay. Un nonce dell’header PoW non ordina le transazioni degli account. Lo stesso numero usato da mittenti, contratti, chain o lane diversi descrive stati diversi.

Come funziona

  1. Identificare il namespace prima di leggere il numero: transazione EOA, stato di contract account, storage applicativo, UserOperation ERC-4337 o uno specifico header PoW. Fissare chain ID, fork e versione, account o owner, contratto verificatore e dominio, EntryPoint o formato dell’header.
  2. Leggere lo stato autoritativo a un block tag esplicito. Separare nonce EOA canonico, conteggio pending del provider, valore nonces(owner) dell’applicazione, chiave e sequenza ERC-4337 e contatore locale di ricerca del miner. L’accordo tra RPC non sostituisce la verifica di ricevuta e stato canonici.
  3. Costruire la lineage firmata. Registrare mittente o owner, chain e dominio, nonce, payload, deadline, contratto verificatore, hash della transazione o del messaggio e ogni sostituzione. Per le transazioni Ethereum, regole come EIP-155 integrano il nonce; questo da solo non costituisce protezione completa dal replay cross-chain.
  4. Allocare nella lane corretta. Coordinare signer EOA concorrenti affinché ogni sequenza canonica sia assegnata una volta, conservando gap e lineage di sostituzione same-nonce. Per applicazioni o smart account, seguire regole atomiche di verifica, incremento e lane del contratto, non un presunto contatore globale.
  5. Inviare secondo le regole di ammissione corrette. Le politiche pending e di sostituzione degli execution client sono locali; i bundler ERC-4337 convalidano oggetti UserOperation secondo EntryPoint e account; una firma EIP-712 o permit può essere inoltrata nella transazione di un’altra persona. L’accettazione locale non prova l’inclusione canonica.
  6. Tracciare l’esito completo: rifiutata, pending, queued, sostituita, inclusa con successo, inclusa con status = 0, rimossa da una riorganizzazione o finalizzata. Una transazione Ethereum inclusa incrementa il nonce del mittente anche se la EVM esegue un revert; un nonce applicativo modificato nella chiamata viene ripristinato.
  7. Riconciliare prima di riprovare. Verificare ricevuta canonica, hash del blocco, nonce del mittente, storage applicativo, evento o ricevuta ERC-4337 e finalità. Per PoW verificare header completo e target, non solo nonce; esaurito il campo finito, i miner modificano altri dati che influiscono sull’header.

Esempi svolti

  • Un revert incluso consuma il nonce EOA. Il nonce canonico del mittente è 12. Una transazione con nonce 12 viene inclusa con status = 0, usa 50,000 gas a 30 gwei e costa 50,000 * 30 gwei = 0.0015 ETH. Le modifiche del contratto vengono ripristinate, ma il nonce passa a 13. Se una riorganizzazione rimuove il blocco, può tornare a 12; il wallet deve ricontrollare l’intera lineage.
  • Nonce applicativi e del relayer sono separati. Un owner ha nonce EOA 18; un token ERC-2612 riporta nonces(owner) = 7; il nonce EOA del relayer è 42. Un permit riuscito consuma il nonce applicativo 7, che diventa 8; l’inclusione porta il nonce del relayer a 43 e lascia quello dell’owner a 18. Se l’intera chiamata esegue revert, il relayer passa comunque a 43, mentre lo storage del token torna a 7.
  • Lane ERC-4337. Con l’espressione didattica nonce = (key << 64) | sequence, chiave 5 e sequenza 9 danno 5 * 2^64 + 9 = 92,233,720,368,547,758,089; la sequenza 10 dà 92,233,720,368,547,758,090. La chiave indipendente 6, sequenza 0, dà 110,680,464,442,257,309,696. L’uso parallelo dipende dalla validazione dello smart account ed è separato dal nonce EOA del bundler.
  • Nonce di ricerca PoW. Il nonce dell’header Bitcoin è di 32 bits, quindi offre 2^32 = 4,294,967,296 candidati numerici. A ipotetici 100 TH/s, la scansione richiede 4,294,967,296 / 100,000,000,000,000 = 0.00004294967296 seconds = 42.94967296 microseconds. I miner cambiano extraNonce della coinbase, tempo o insieme delle transazioni per cambiare la Merkle root e ottenere nuovi header; questo campo non è stato anti-replay di un account.

Rischi

  • Confondere namespace EOA, contratto, applicazione, ERC-4337 e PoW.
  • Leggere il nonce da chain, fork, contratto o EntryPoint errati.
  • Usare una risposta RPC obsoleta, incoerente o malevola.
  • Signer concorrenti che allocano lo stesso nonce EOA.
  • Gap di nonce che blocca candidate locali successive.
  • Trattare il nonce pending del provider come stato canonico.
  • Dimenticare che un revert incluso consuma nonce EOA e gas.
  • Non ripristinare nonce e lineage dopo una riorganizzazione.
  • Sostituzione same-nonce che non soddisfa la politica di commissione.
  • Presumere che la sostituzione abbia cancellato globalmente l’originale.
  • Correlare nonce numericamente uguali di mittenti o domini diversi.
  • Omettere chain ID o altro domain separator richiesto.
  • Non controllare e incrementare atomicamente un nonce applicativo.
  • Owner, deadline, domain separator o token ERC-2612 errati.
  • Replay di una firma tra chain, contratto o versione.
  • Interpretare lo state nonce di un contract account come contatore generico di chiamate.
  • Impacchettare chiave o larghezza della sequenza ERC-4337 errate.
  • Mescolare nonce EOA del bundler e nonce UserOperation dello smart account.
  • Upgrade del proxy o collisione dello storage modifica il comportamento.
  • Trattare nonce PoW finito come autorizzazione, stato anti-replay o prova isolata.

Falsi miti comuni

  • Ogni campo chiamato nonce ha lo stesso significato ed è usato globalmente una volta.
  • Un nonce maggiore rende una transazione più sicura, veloce o finale.
  • Una transazione Ethereum che esegue revert non consuma il nonce del mittente.
  • Un nonce da solo impedisce ogni replay cross-chain, cross-contract e di messaggi tipizzati.
  • Ogni smart account ERC-4337 ha un contatore lineare identico al nonce EOA.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...