Vai al contenuto

Modello di stato basato su account

Comprendere il modello basato su account di Ethereum mediante campi dell'account, radici di stato e storage, esecuzione ordinata, gas e revert, storage dei token, delega EIP-7702, access list, trace e finalita.

Aggiornato

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

Risposta diretta

Un modello basato su account rappresenta lo stato di esecuzione come dati indicizzati per indirizzo. Nel livello di esecuzione di Ethereum, una foglia account contiene [nonce, balance, storageRoot, codeHash]. Il balance nativo e denominato in wei; i dati contrattuali si trovano dietro lo storageRoot dell’account; lo stateRoot successivo all’esecuzione del blocco impegna lo stato globale risultante. Wallet, provider RPC o explorer leggono e interpretano lo stato, ma non conservano il saldo canonico per l’utente.

Saldi ERC-20, allowance, debito di prestito e collaterale sono normalmente valori nello storage dei contratti, non campi aggiuntivi dell’account protocollare del titolare. Analogamente, una “transazione interna” dell’explorer e di solito una message call EVM ricostruita da un trace, non una transazione Ethereum firmata separatamente con hash e nonce propri.

La distinzione tradizionale tra externally owned account (EOA) e contract account rimane utile, ma “un EOA ha sempre codice vuoto” non e piu assoluto su una catena con EIP-7702. Un EOA puo contenere l’indicatore 0xef0100 || address ed eseguire il codice delegato mantenendo l’autorita a iniziare transazioni. La classificazione deve usare regole della catena e codice effettivo, non una vecchia etichetta UI.

Verifica della transizione di stato in sette passaggi

  1. Fissare l’osservazione: rete, chainId, regole del fork, numero e hash del blocco, timestamp e tag come pending, latest, safe o finalized. Lo stato vicino alla testa puo cambiare dopo una riorganizzazione; non unire dati di blocchi diversi senza etichettarli.
  2. Leggere i campi protocollari: nonce, balance nativo, storageRoot e codeHash. Se il codice e un indicatore EIP-7702, risolvere il delegato secondo il fork. Per proxy e account delegati, identificare separatamente codice di implementazione, controllo degli upgrade e layout dello storage.
  3. Localizzare i saldi applicativi. ETH cambia il saldo nativo; ERC-20 di solito modifica un mapping nel contratto token; allowance, debito, collaterale e reward possono risiedere in altri contratti e slot. Decimali e log aiutano l’interpretazione, ma non sono campi della foglia.
  4. Decodificare e prevalidare la transazione top-level: tipo, dominio della catena, firma, nonce del mittente, destinatario o creazione, valore, input, gas limit, limiti di commissione e access list o autorizzazioni EIP-7702 opzionali. Il mittente deve coprire valore e impegno massimo di commissione. Una transazione rifiutata non viene inclusa e non consuma gas on-chain.
  5. Eseguire le transazioni nell’ordine del blocco dallo stato precedente. L’EVM elabora message call annidate e frame di creazione, ognuno con caller, callee, valore, calldata, gas e stato di ritorno. Letture e scritture condivise rendono il risultato dipendente dall’ordine. Una access list EIP-2930 preriscalda account e slot e modifica il conteggio del gas; non vieta accessi non dichiarati ne dimostra parallelismo sicuro.
  6. Applicare i confini di commit e rollback. Un frame riuscito conferma stato e log salvo successivo revert del genitore. REVERT annulla scritture, trasferimenti e log del frame fallito restituendo il gas inutilizzato; un contratto esterno puo catturare un errore figlio e riuscire. Un errore top-level incluso ha ricevuta status = 0, ma incrementa il nonce e paga il gas consumato. Le autorizzazioni EIP-7702 hanno regole proprie di persistenza anche se l’esecuzione successiva va in revert.
  7. Riconciliare il post-stato. Confrontare variazioni native e token, storage, stato della ricevuta, gas usato, prezzo effettivo, log e trace del provider con le radici impegnate dal blocco. Trattare i trace come ricostruzioni, non transazioni di consenso. Attendere la finalita richiesta e gestire sostituzioni, reorg, revisioni dell’indexer, bridge, rollup e storni contabili.

Quattro esempi svolti

  • Trasferimento ETH EIP-1559. A parte con 5 ETH e nonce 12; B con 1 ETH. A invia 1 ETH usando 21,000 gas, base fee 20 gwei, priority cap 3 gwei e max fee 40 gwei. Il prezzo effettivo e min(40, 20 + 3) = 23 gwei; commissione totale 21,000 × 23 gwei = 0.000483 ETH, di cui 0.000420 ETH bruciati e 0.000063 ETH priority fee. Il requisito massimo alla firma e 1 ETH + 21,000 × 40 gwei = 1.000840 ETH. Saldi finali: A 3.999517 ETH, B 2 ETH; nonce A 13.
  • Transazione inclusa che va in revert. A parte con 2 ETH e nonce 7. Chiama un contratto con 0.50 ETH; l’esecuzione top-level va in revert dopo 80,000 gas a 25 gwei, quindi la commissione e 80,000 × 25 gwei = 0.002000 ETH. Scritture, log e trasferimento di 0.50 ETH vengono annullati, mentre A termina con 1.998000 ETH, nonce 8 e ricevuta status = 0. Un errore figlio catturato puo coesistere con ricevuta esterna status = 1.
  • Il saldo token e storage contrattuale. Il contratto registra Alice 1,000 units e Bob 200 units. Un trasferimento di 250 units lascia Alice 750 units e Bob 450 units, preservando 1,200 units. Se la transazione usa 60,000 gas × 20 gwei = 0.001200 ETH, l’ETH nativo di Alice diminuisce separatamente. Cambiano lo storageRoot del token e lo stateRoot globale; il capitale token non e mai stato saldo nativo di Alice.
  • Confine di persistenza EIP-7702. Uno sponsor invia una set-code transaction con autorizzazione di A al nonce 5 per delegare a D. Il protocollo scrive l’indicatore di 23-byte 0xef0100 || 20-byte address e incrementa il nonce di autorita di A a 6. Se l’esecuzione esterna successiva va in revert, indicatore e nonce gia elaborati restano. Non e lo stesso confine dello storage EVM ordinario scritto dalla chiamata fallita.

Rischi e controlli

  • Catena, fork, hash o tag del blocco errati producono uno snapshot incoerente.
  • Un RPC obsoleto o inaffidabile puo omettere o riportare male lo stato di testa.
  • Corse, lacune e sostituzioni del nonce pending invalidano le ipotesi in coda.
  • “Annullare” nel wallet e di solito sostituire la transazione, non cancellarla dal protocollo.
  • Saldo insufficiente per valore piu commissioni massime impedisce l’inclusione.
  • Movimento della base fee o errore nei cap ritarda l’inclusione o cambia il costo.
  • EIP-7702 puo far classificare male un EOA da vecchie euristiche.
  • Delegato malevolo, inizializzazione difettosa o replay compromettono un account EIP-7702.
  • Upgrade proxy e delegate call cambiano nel tempo l’interpretazione di codice e storage.
  • Errori di chiave, dominio o chain ID consentono furto o replay.
  • Reentrancy e ordine dello stato condiviso possono modificare saldi nell’esecuzione.
  • Una chiamata figlia puo fallire ed essere catturata mentre la transazione esterna riesce.
  • Revert top-level o out-of-gas consuma gas e incrementa il nonce.
  • Decimali, fee-on-transfer, rebasing e hook invalidano l’aritmetica semplice.
  • Allowance, debito, collaterale e reward possono mancare dalla riconciliazione.
  • I log possono mancare, essere annullati, fuorviare o non provare lo stato finale.
  • “Transazioni interne” e trace possono differire perche sono viste ricostruite.
  • Una access list puo essere incompleta, duplicata o antieconomica e non blocca il read/write set.
  • Ordine dello stato condiviso, priority fee e MEV possono cambiare i risultati.
  • Reorg, pruning, prove indisponibili, transizioni L2 e finalita dei bridge possono stornare o oscurare la contabilita.

Errori comuni

  • “Il wallet conserva il saldo on-chain.” Custodisce credenziali e presenta lo stato della rete.
  • “Ogni indirizzo e sempre un EOA senza codice o un contratto ordinario.” EIP-7702 cambia l’euristica.
  • “Ogni trasferimento visualizzato e una transazione Ethereum.” Eventi token e trace non sono transazioni top-level firmate.
  • “Una transazione fallita non cambia nulla e non costa nulla.” Se inclusa, puo consumare gas e incrementare il nonce.
  • “Il modello account o una access list garantisce piu parallelismo di UTXO.” Prestazioni e conflitti dipendono dal protocollo e dal carico.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...