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
- Fissare l’osservazione: rete,
chainId, regole del fork, numero e hash del blocco, timestamp e tag comepending,latest,safeofinalized. Lo stato vicino alla testa puo cambiare dopo una riorganizzazione; non unire dati di blocchi diversi senza etichettarli. - Leggere i campi protocollari:
nonce,balancenativo,storageRootecodeHash. 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. - 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.
- 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.
- 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.
- Applicare i confini di commit e rollback. Un frame riuscito conferma stato e log salvo successivo revert del genitore.
REVERTannulla 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 ricevutastatus = 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. - 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 ETHe nonce12; B con1 ETH. A invia1 ETHusando21,000 gas, base fee20 gwei, priority cap3 gweie max fee40 gwei. Il prezzo effettivo emin(40, 20 + 3) = 23 gwei; commissione totale21,000 × 23 gwei = 0.000483 ETH, di cui0.000420 ETHbruciati e0.000063 ETHpriority fee. Il requisito massimo alla firma e1 ETH + 21,000 × 40 gwei = 1.000840 ETH. Saldi finali: A3.999517 ETH, B2 ETH; nonce A13. - Transazione inclusa che va in revert. A parte con
2 ETHe nonce7. Chiama un contratto con0.50 ETH; l’esecuzione top-level va in revert dopo80,000 gasa25 gwei, quindi la commissione e80,000 × 25 gwei = 0.002000 ETH. Scritture, log e trasferimento di0.50 ETHvengono annullati, mentre A termina con1.998000 ETH, nonce8e ricevutastatus = 0. Un errore figlio catturato puo coesistere con ricevuta esternastatus = 1. - Il saldo token e storage contrattuale. Il contratto registra Alice
1,000 unitse Bob200 units. Un trasferimento di250 unitslascia Alice750 unitse Bob450 units, preservando1,200 units. Se la transazione usa60,000 gas × 20 gwei = 0.001200 ETH, l’ETH nativo di Alice diminuisce separatamente. Cambiano lostorageRootdel token e lostateRootglobale; 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
5per delegare a D. Il protocollo scrive l’indicatore di23-byte0xef0100 || 20-byte addresse incrementa il nonce di autorita di A a6. 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.