--- title: "Racine d'état" description: "La racine d'état est l'engagement compact d'Ethereum envers l'état global après un bloc. Découvrez son calcul, ce que prouvent les preuves de compte et de stockage, et leurs limites." 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. # Racine d'état > À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes. ## Réponse directe Une racine d'état est un engagement cryptographique de 32 octets, inscrit dans l'en-tête d'un bloc Ethereum, envers l'état global après le traitement du bloc. L'état global associe des adresses à des comptes. Chaque compte engage son nonce, son solde, sa racine de stockage et le hash de son code ; la racine de stockage de chaque contrat engage à son tour les emplacements de stockage de ce compte. La racine est un condensé, pas un instantané téléchargeable. Elle permet aux nœuds de comparer des résultats calculés indépendamment et à un vérificateur de contrôler une preuve de compte ou de stockage par rapport à un bloc fiable. À elle seule, elle ne reconstitue pas l'état, ne prouve ni la disponibilité des données ni la finalité du bloc, et ne démontre pas la sécurité économique d'un contrat. La « racine d'état » dépend du protocole. Ethereum engage actuellement l'état de sa couche d'exécution avec un trie de Merkle-Patricia modifié. D'autres réseaux peuvent employer des modèles d'état, encodages, fonctions de hachage ou structures authentifiées différents ; un nom identique ne rend pas leurs racines ou preuves interchangeables. ## Fonctionnement Un client d'exécution part de l'état du bloc parent, valide et exécute le nouveau bloc selon les règles actives du protocole, puis applique les modifications de comptes et de stockage qui en résultent. Schématiquement : `S_n = Υ(S_(n-1), B_n)` Ici, `S_(n-1)` est l'état parent, `B_n` l'ensemble du traitement défini par le protocole pour le nouveau bloc, et `S_n` l'état obtenu. Le client encode cet état de façon déterministe dans le trie d'état et calcule son hash racine. Un en-tête valide doit contenir le même résultat ; toute divergence rend le bloc invalide pour ce client. Dans le trie d'état d'Ethereum, le chemin d'un compte dérive de son adresse et le compte encodé contient le nonce, le solde, la racine de stockage et le hash du code. Le code du contrat est référencé par son hash, et chaque contrat possède un trie de stockage distinct. Cette imbrication signifie qu'un emplacement modifié peut changer la racine de stockage du contrat, puis le compte encodé et enfin la racine d'état globale. La racine d'état est distincte des racines de transactions et de reçus du même en-tête. La première engage les données ordonnées des transactions ; la seconde engage les reçus d'exécution. Aucune ne remplace l'autre. EIP-1186 définit `eth_getProof`, qui peut renvoyer une preuve de compte et les preuves de stockage demandées pour un bloc donné. Le vérificateur a toujours besoin d'un hash de bloc ou d'une racine d'état authentifiés, des règles exactes du trie et de l'encodage, ainsi que d'une politique appropriée de confirmation ou de finalité. ## Exemple Supposons qu'une transaction transfère des ETH d'Alice à Bob. L'exécution correcte peut modifier le nonce et le solde d'Alice, le solde de Bob et celui du bénéficiaire des frais. Si la transaction appelle un contrat, des emplacements et la racine de stockage du contrat peuvent aussi changer. Ces mises à jour produisent une nouvelle racine d'état globale, même si la plupart des comptes restent intacts. Deux clients honnêtes partant du même état parent et traitant le même bloc valide selon les mêmes règles devraient calculer la même racine. Si l'un crédite un montant erroné ou utilise un mauvais encodage du trie, sa racine différera de l'en-tête et il devra rejeter le bloc plutôt que d'accepter silencieusement son état local. Pour vérifier le solde de Bob sans télécharger tout l'état global, on peut obtenir l'en-tête et une preuve de compte. Recalculer le chemin de preuve indique si le compte encodé correspond à la racine d'état de l'en-tête. Cela ne prouve pas que l'en-tête choisi est canonique ou finalisé ; cette conclusion vient des contrôles de chaîne et de finalité du vérificateur. ## Risques - **Racine non fiable :** Une preuve valide contre une racine choisie par un attaquant ou périmée prouve le mauvais point de référence. Liez la racine à un hash de bloc, un ID de chaîne et un numéro de bloc vérifiés. - **Réorganisations et finalité :** Une preuve peut être correcte pour un bloc qui quitte ensuite la chaîne canonique. Adaptez la profondeur de confirmation ou la finalité à la tolérance aux pertes de l'application. - **Erreurs d'encodage :** Hachage des adresses, RLP, chemins de nibbles, nœuds intégrés et clés de stockage doivent suivre exactement le protocole. Une bibliothèque générique de preuves de Merkle binaires ne suffit pas. - **Données manquantes :** La racine engage l'état, mais ne rend pas disponibles les nœuds du trie, l'état historique ou les services de génération de preuves. Les nœuds élagués peuvent ne pas fournir d'anciennes preuves. - **Garantie exagérée :** L'accord des racines détecte une exécution incohérente ; il n'audite pas les contrats, n'authentifie pas les oracles, ne sécurise pas un endpoint RPC, ne garantit pas la valeur d'un actif et n'empêche pas des clés compromises d'autoriser des transactions. ## Idées reçues - **La racine d'état stocke tous les soldes.** C'est un engagement de taille fixe envers un trie encodé ; les données sous-jacentes doivent être obtenues séparément. - **Des racines identiques prouvent des bases de données identiques.** Elles engagent le même état global logique selon le protocole, mais les clients peuvent le stocker, l'indexer, l'élaguer ou le mettre en cache différemment. - **Une racine différente désigne la transaction fautive.** Elle révèle un désaccord sur l'état final engagé, pas l'origine de la divergence ; il faut retracer l'exécution pour la diagnostiquer. - **Une preuve de compte valide démontre finalité et sécurité.** Elle ne prouve que la cohérence avec une racine. Sélection de chaîne, finalité, fraîcheur des données, comportement du contrat et risque économique restent des questions distinctes. ## Thèmes associés - [Modèle fondé sur les comptes](/fr/crypto/account-based-model/) - [Arbre de Merkle](/fr/crypto/merkle-tree/) - [Nœud complet](/fr/crypto/full-node/) - [Client léger](/fr/crypto/light-client/) - [Confirmation de bloc](/fr/crypto/block-confirmation/) ## Sources - [Ethereum Execution Specifications: Block Header](https://ethereum.github.io/execution-specs/src/ethereum/forks/frontier/blocks.py.html) - Ethereum Foundation (consulté le : 2026-08-21) - [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation (consulté le : 2026-08-21) - [EIP-1186: RPC-Method to get Merkle Proofs](https://eips.ethereum.org/EIPS/eip-1186) - Ethereum Improvement Proposals (consulté le : 2026-08-21) Source: https://wiki.fcontext.com/fr/crypto/state-root/index.mdx