---
title: "Modello di stato basato su account"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Modello di stato basato su account
> 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
- [Radice di stato](/it/crypto/state-root/)
- [Modello UTXO](/it/crypto/utxo-model/)
- [Account abstraction](/it/crypto/account-abstraction/)
## Fonti
- [Ethereum accounts](https://ethereum.org/developers/docs/accounts/)
- [Ethereum Yellow Paper: a formal specification of Ethereum, a programmable blockchain](https://ethereum.github.io/yellowpaper/paper.pdf)
- [Transactions](https://ethereum.org/developers/docs/transactions/)
- [Blocks](https://ethereum.org/developers/docs/blocks/)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/)
- [EIP-7702: Set Code for EOAs](https://eips.ethereum.org/EIPS/eip-7702)
- [EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/)
Source: https://wiki.fcontext.com/it/crypto/account-based-model/index.mdx