> ## Documentation Index
> Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Modèle d’état

> Ce qui constitue l’état de la chaîne, comment il est adressé et versionné, et laquelle des trois représentations de l’état fait autorité.

Trois choses différentes reçoivent le nom d’« état » dans un moteur de trading, et c’est en les confondant qu’un système finit par donner des réponses qui dépendent de la personne interrogée. Cette page les sépare et dit laquelle fait autorité.

<h2 id="three-representations">
  Trois représentations
</h2>

<div className="dg" data-dg="state-model">
  <div className="dg-c" style={{aspectRatio:"720 / 288"}}>
    <svg className="dg-w" viewBox="0 0 720 288" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 215.00 90.00 L 243.60 90.00" />

      <path className="dg-head dg--blue" d="M 250.00 90.00 L 243.60 94.40 L 243.60 85.60 Z" />

      <path className="dg-wire dg--green" d="M 470.00 90.00 L 498.60 90.00" />

      <path className="dg-head dg--green" d="M 505.00 90.00 L 498.60 94.40 L 498.60 85.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 615.00 145.00 L 615.00 176.00 L 105.00 176.00 L 105.00 151.40" />

      <path className="dg-head dg--green" d="M 105.00 145.00 L 109.40 151.40 L 100.60 151.40 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"13.8889%",width:"29.1667%",height:"34.7222%"}}><span className="dg-t">État du moteur</span><span className="dg-s">marchés · comptes · positions · carnets · chambre de compensation</span><span className="dg-n">vit entre les blocs · une reconstruction</span></div>
    <div className="dg-b dg--yellow dg-dashed" style={{left:"35.4167%",top:"13.8889%",width:"29.1667%",height:"34.7222%"}}><span className="dg-t">Ensemble de travail</span><span className="dg-s">marquages · comptes touchés · exécutions · sortie</span><span className="dg-n">vit le temps d’un bloc · un journal</span></div>
    <div className="dg-b dg--green" style={{left:"70.8333%",top:"13.8889%",width:"29.1667%",height:"34.7222%"}}><span className="dg-t">État de la chaîne</span><span className="dg-s">clé-valeur versionné, authentifié Merkle</span><span className="dg-n">l’autorité</span></div>
    <div className="dg-b dg--orange dg-left" style={{left:"0.0000%",top:"72.9167%",width:"100.0000%",height:"23.6111%"}}><span className="dg-t">La défaillance évitée</span><span className="dg-s">Un moteur dont la vue en mémoire a dérivé de ce qui a été entériné continue de servir des réponses, toutes fausses d’une façon qui n’apparaît qu’au règlement.</span></div>
    <div className="dg-lbl" style={{left:"50.0000%",top:"61.1111%",width:"45.8333%",whiteSpace:"normal"}}>l’état du moteur doit être dérivable du registre entériné, jamais l’inverse</div>
  </div>
</div>

**L’état du moteur** est ce que le [noyau](/fr/protocol/architecture/kernel) conserve entre les blocs : métadonnées de marché, comptes, positions, carnets d’ordres, état des instruments, état de la chambre de compensation. C’est la représentation de travail — organisée selon les schémas d’accès réels de l’appariement et de la compensation, pas selon les besoins du stockage.

**L’ensemble de travail du bloc** n’existe que pendant l’exécution d’un bloc : les prix de marquage fixés au départ, les comptes et les ordres touchés, les exécutions produites, les sorties en cours d’assemblage. C’est un journal de ce qui s’est passé pendant ce bloc.

**L’état de la chaîne** est le résultat entériné : des entrées clé-valeur versionnées, authentifiées par une structure de Merkle, durables et rejouables. C’est ce qu’un nœud synchronise, ce contre quoi une preuve est établie, et ce que lit un [indexeur](/fr/protocol/architecture/indexer).

**L’état de la chaîne fait autorité.** L’ensemble de travail du bloc est un journal qui sert à construire une sortie déterministe — pas une source de vérité. L’état du moteur est une reconstruction de l’état de la chaîne optimisée pour l’exécution ; il doit être dérivable du registre entériné, jamais l’inverse.

Prendre cela à l’envers produit une défaillance précise et reconnaissable : un moteur dont la vue en mémoire a dérivé de ce qui a été entériné continuera de servir des réponses, et chacune d’elles sera fausse d’une façon qui n’apparaît qu’au règlement.

<h2 id="keys">
  Clés
</h2>

L’état de la chaîne est adressé par clé. L’état de trading est regroupé dans des espaces de noms identifiés et explicitement versionnés — par exemple la configuration des frais, l’index des contrats perpétuels, la table des paliers de levier, la liste des rôles administratifs.

Le suffixe de version n’est pas décoratif. Quand la forme d’une configuration change, elle passe à une nouvelle version de sa clé, et la clé précédente est conservée pour que l’état écrit sous l’ancien schéma reste lisible pendant la migration. Un lecteur qui code une version en dur et ne revérifie jamais lira silencieusement une configuration périmée après une migration ; un lecteur qui résout la clé courante, non.

<Note>
  C’est pourquoi la configuration devrait être lue sur la chaîne plutôt que figée dans le code client. Le [service de paliers de frais](/fr/protocol/architecture/programs) lit la configuration des frais en direct à chaque cycle exactement pour cette raison — une table de paliers figée dans un client est une table qui finira par diverger de celle que le réseau applique.
</Note>

## Versions

Chaque bloc entériné fait avancer une version. Les valeurs d’état sont stockées avec la version à laquelle elles ont été écrites, ce qui signifie que le magasin n’est pas seulement « l’état courant » mais « l’état à n’importe quelle version ».

Cette propriété rend plusieurs choses possibles à la fois :

* **Les preuves** peuvent être produites contre une version précise, et pas seulement contre le présent.
* **Le rejeu** peut partir de n’importe quelle version, pas seulement de la genèse.
* **Les lectures** peuvent être historiques — un indexeur qui reconstruit l’historique d’une position demande d’anciennes versions, il ne parcourt pas un journal.
* **L’élagage** devient une décision de politique sur la profondeur à conserver, plutôt qu’une limite structurelle.

<h2 id="what-ends-up-committed">
  Ce qui finit entériné
</h2>

L’exécution du noyau produit deux choses par bloc. Chaque transaction porte ses propres écritures et événements, qui lui sont liés. Les effets qui n’appartiennent à aucune transaction utilisateur en particulier — flux de financement, mouvements du fonds d’assurance, compteurs au niveau du bloc — vont vers un canal système distinct.

Entre les deux, rien n’est perdu. Il n’existe pas d’effet d’exécution à l’intérieur du noyau qui soit absent à la fois de la sortie d’une transaction et du canal système. Cette exhaustivité est ce qui permet de traiter le registre entériné comme l’histoire complète plutôt que comme un résumé, et c’est la raison pour laquelle un événement peut être rattaché à la transaction qui l’a causé, même quand l’appariement s’est fait par lots.

<h2 id="where-to-go-next">
  Pour aller plus loin
</h2>

<CardGroup cols={2}>
  <Card title="Stockage et preuves" href="/fr/protocol/architecture/state/storage">
    Comment l’état entériné est physiquement stocké, authentifié et élagué.
  </Card>

  <Card title="Synchronisation d’état" href="/fr/protocol/architecture/state/sync">
    Comment un nœud qui n’a jamais vu la chaîne la rattrape.
  </Card>

  <Card title="IntentionKernel" href="/fr/protocol/architecture/kernel">
    Où vivent l’état du moteur et l’ensemble de travail du bloc.
  </Card>

  <Card title="Indexeur" href="/fr/protocol/architecture/indexer">
    Transformer l’état entériné en quelque chose d’interrogeable.
  </Card>
</CardGroup>