---
title: "Modele d'etat fonde sur les comptes"
description: "Comprendre le modele Ethereum fonde sur les comptes par les champs du compte, racines d'etat et de stockage, execution ordonnee, gas et reverts, stockage des tokens, delegation EIP-7702, listes d'acces, traces et finalite."
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.

# Modele d'etat fonde sur les comptes

> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

<a id="answer"></a>

## Reponse directe

Un modele fonde sur les comptes represente l'etat d'execution par des donnees indexees par adresse. Dans la couche d'execution d'Ethereum, une feuille de compte contient `[nonce, balance, storageRoot, codeHash]`. Le `balance` natif est libelle en wei ; les donnees contractuelles se trouvent derriere le `storageRoot` du compte ; et le `stateRoot` apres execution du bloc engage l'etat global resultant. Portefeuille, fournisseur RPC ou explorateur lit et interprete cet etat, mais ne conserve pas le solde canonique pour l'utilisateur.

Soldes ERC-20, allowances, dette d'emprunt et collateral sont normalement des valeurs dans le stockage de contrats, non des champs supplementaires du compte protocolaire du detenteur. De meme, une "transaction interne" affichee par un explorateur est souvent un appel de message EVM reconstruit par trace, non une transaction Ethereum signee separement avec son propre hash et nonce.

La distinction traditionnelle entre compte externe (EOA) et compte contractuel reste utile, mais "un EOA a toujours un code vide" n'est plus absolu sur une chaine avec EIP-7702. Un EOA peut porter l'indicateur `0xef0100 || address` et executer le code delegue tout en conservant l'autorite d'initier des transactions. Il faut classifier selon les regles de la chaine et le code reel, non selon une ancienne etiquette d'interface.

<a id="mechanism"></a>

## Audit de la transition d'etat en sept etapes

1. Figer l'observation : reseau, `chainId`, regles du fork, numero et hash du bloc, timestamp et tag tel que `pending`, `latest`, `safe` ou `finalized`. L'etat proche de la tete peut changer apres reorganisation ; ne melangez pas des faits de blocs differents sans les etiqueter.
2. Lire les champs protocolaires : `nonce`, `balance` natif, `storageRoot` et `codeHash`. Si le code est un indicateur EIP-7702, resoudre le delegue selon le fork. Pour les proxies et comptes delegues, identifier separement implementation, controle de mise a niveau et organisation du stockage.
3. Localiser les soldes applicatifs. ETH modifie le solde natif ; ERC-20 modifie en general un mapping du contrat token ; allowances, dette, collateral et recompenses peuvent resider dans d'autres contrats et slots. Decimales et logs aident a interpreter mais ne sont pas des champs de la feuille.
4. Decoder et precontroler la transaction de premier niveau : type, domaine de chaine, signature, nonce de l'emetteur, destinataire ou creation, valeur, input, limite de gas, plafonds de frais et liste d'acces ou autorisations EIP-7702 facultatives. L'emetteur doit couvrir valeur et engagement maximal de frais. Une transaction rejetee n'est pas incluse et ne consomme pas de gas on-chain.
5. Executer les transactions dans l'ordre du bloc a partir de l'etat precedent. L'EVM traite appels de message imbriques et cadres de creation avec caller, callee, valeur, calldata, gas et statut propres. Lectures et ecritures partagees rendent le resultat dependant de l'ordre. Une liste EIP-2930 prechauffe comptes et slots et modifie la comptabilite du gas ; elle n'interdit pas les acces non declares et ne prouve pas un parallelisme sur.
6. Appliquer les limites de commit et rollback. Un cadre reussi confirme etat et logs, sauf revert ulterieur d'un parent. `REVERT` annule ecritures, transferts et logs du cadre echoue et restitue le gas inutilise ; un contrat externe peut intercepter l'echec enfant et reussir. Un echec de premier niveau inclus a une reception `status = 0`, mais incremente le nonce et paie le gas consomme. Les autorisations EIP-7702 ont leurs propres regles de persistance meme si l'execution ulterieure revert.
7. Reconciler l'etat final. Rapprocher variations natives et tokens, stockage, statut de reception, gas utilise, prix effectif, logs et traces du fournisseur avec les racines engagees du bloc. Traiter les traces comme des reconstructions, non des transactions de consensus. Attendre la finalite requise puis gerer remplacements, reorgs, revisions de l'indexeur, bridges, rollups et contrepassations comptables.

<a id="example"></a>

## Quatre exemples calcules

- **Transfert ETH EIP-1559.** A commence avec `5 ETH` et le nonce `12`, B avec `1 ETH`. A envoie `1 ETH` avec `21,000 gas`, base fee `20 gwei`, priority cap `3 gwei` et max fee `40 gwei`. Prix effectif : `min(40, 20 + 3) = 23 gwei` ; frais totaux : `21,000 × 23 gwei = 0.000483 ETH`, dont `0.000420 ETH` brules et `0.000063 ETH` de priorite. L'exigence maximale a la signature est `1 ETH + 21,000 × 40 gwei = 1.000840 ETH`. Soldes finaux : A `3.999517 ETH`, B `2 ETH` ; nonce d'A `13`.
- **Transaction incluse qui revert.** A commence avec `2 ETH` et nonce `7`. A appelle un contrat avec `0.50 ETH` ; l'execution de premier niveau revert apres `80,000 gas` a `25 gwei`, donc les frais sont `80,000 × 25 gwei = 0.002000 ETH`. Ecritures, logs et transfert de `0.50 ETH` sont annules, mais A termine avec `1.998000 ETH`, nonce `8` et reception `status = 0`. Un echec enfant intercepte peut coexister avec une reception externe `status = 1`.
- **Le solde token est du stockage contractuel.** Le contrat enregistre Alice `1,000 units` et Bob `200 units`. Un transfert reussi de `250 units` laisse Alice `750 units` et Bob `450 units`, soit toujours `1,200 units`. Si la transaction d'Alice utilise `60,000 gas × 20 gwei = 0.001200 ETH`, son ETH natif baisse separement. Le `storageRoot` du token et le `stateRoot` global changent ; le principal du token n'a jamais ete son solde natif.
- **Limite de persistance EIP-7702.** Un sponsor soumet une set-code transaction contenant une autorisation d'A au nonce `5` vers D. Le protocole ecrit l'indicateur de `23-byte` `0xef0100 || 20-byte address` et porte le nonce d'autorite d'A a `6`. Si l'execution externe ulterieure revert, l'indicateur et le nonce deja traites demeurent. Ce n'est pas la meme limite que le stockage EVM ordinaire ecrit par l'appel echoue.

<a id="risks"></a>

## Risques et controles

- Mauvaise chaine, fork, hash ou tag de bloc produit un instantane incoherent.
- Un RPC perime ou non fiable peut omettre ou mal rapporter l'etat de tete.
- Courses, trous et remplacements de nonce pending invalident les hypotheses en attente.
- "Annuler" dans un portefeuille signifie generalement remplacer la transaction, non la supprimer.
- Un solde insuffisant pour valeur et frais maximaux empeche l'inclusion.
- Mouvement de base fee ou erreur de plafond retarde l'inclusion ou change le cout.
- Le code EIP-7702 peut tromper les anciennes heuristiques de classification EOA.
- Delegue malveillant, mauvaise initialisation ou rejeu peut compromettre un compte EIP-7702.
- Mises a niveau proxy et delegate calls peuvent changer l'interpretation du code et du stockage.
- Erreurs de cle, domaine ou chain ID peuvent autoriser vol ou rejeu.
- Reentrancy et ordre de l'etat partage peuvent modifier les soldes dans une execution.
- Un appel enfant peut echouer et etre intercepte tandis que la transaction externe reussit.
- Revert de premier niveau ou out-of-gas consomme du gas et incremente le nonce.
- Decimales, fee-on-transfer, rebasing et hooks invalident une arithmetique simple.
- Allowances, dette, collateral et recompenses peuvent manquer a une reconciliation des seuls soldes.
- Des logs peuvent manquer, etre annules, trompeurs ou insuffisants pour prouver l'etat final.
- "Transactions internes" et traces peuvent differer car ce sont des vues reconstruites.
- Une liste d'acces peut etre incomplete, dupliquee ou non rentable et ne verrouille pas le read/write set.
- Ordre de l'etat partage, priority fees et MEV peuvent changer les resultats.
- Reorgs, pruning, preuves indisponibles, transitions L2 et finalite des bridges peuvent inverser ou masquer la comptabilite.

<a id="misconceptions"></a>

## Idees recues

- "Le portefeuille conserve le solde on-chain." Il conserve les moyens d'acces et presente l'etat du reseau.
- "Chaque adresse est toujours un EOA sans code ou un contrat ordinaire." EIP-7702 change cette heuristique.
- "Chaque transfert affiche est une transaction Ethereum." Evenements token et traces d'appels ne sont pas des transactions signees de premier niveau.
- "Une transaction echouee ne change rien et ne coute rien." Incluse, elle peut consommer du gas et avancer le nonce.
- "Le modele de compte ou une liste d'acces garantit plus de parallelisme qu'UTXO." Performance et conflits dependent du protocole et de la charge.

<a id="related"></a>

## Sujets connexes

- [Racine d'etat](/fr/crypto/state-root/)
- [Modele UTXO](/fr/crypto/utxo-model/)
- [Abstraction de compte](/fr/crypto/account-abstraction/)

<a id="sources"></a>

## Sources

- [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/fr/crypto/account-based-model/index.mdx