> ## 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.

# Modelo de estado

> Qué constituye el estado de la cadena, cómo se direcciona y se versiona, y cuál de las tres representaciones del estado tiene la autoridad.

En un motor de trading se llaman “estado” tres cosas distintas, y confundirlas es la vía por la que los sistemas acaban dando respuestas que dependen de a quién preguntes. Esta página las separa y dice cuál tiene la autoridad.

<h2 id="three-representations">
  Tres representaciones
</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">Estado del motor</span><span className="dg-s">mercados · cuentas · posiciones · libros · cámara de compensación</span><span className="dg-n">persiste entre bloques · reconstrucción</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">Conjunto de trabajo</span><span className="dg-s">marcas · cuentas tocadas · ejecuciones · salida</span><span className="dg-n">dura un bloque · un diario</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">Estado de la cadena</span><span className="dg-s">clave-valor versionado, autenticado por Merkle</span><span className="dg-n">la autoridad</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">El fallo que esto evita</span><span className="dg-s">Un motor cuya vista en memoria se ha desviado de lo confirmado sigue sirviendo respuestas, y todas están mal de una forma que solo aparece en la compensación.</span></div>
    <div className="dg-lbl" style={{left:"50.0000%",top:"61.1111%",width:"45.8333%",whiteSpace:"normal"}}>el estado del motor debe poder derivarse del registro confirmado, nunca al revés</div>
  </div>
</div>

**El estado del motor** es lo que el [kernel](/es/protocol/architecture/kernel) mantiene entre bloques: metadatos de mercado, cuentas, posiciones, libros de órdenes, estado de los instrumentos, estado de la cámara de compensación. Es la representación de trabajo, dispuesta para los patrones de acceso que la casación y la compensación realmente tienen, no para el almacenamiento.

**El conjunto de trabajo del bloque** existe solo mientras el bloque se ejecuta: los precios de marca fijados al inicio, qué cuentas y qué órdenes se tocaron, las ejecuciones producidas, las salidas que se están ensamblando. Es un diario de lo que ocurrió durante este bloque.

**El estado de la cadena** es el resultado confirmado: entradas clave-valor versionadas, autenticadas por una estructura de Merkle, duraderas y reejecutables. Es lo que un nodo sincroniza, aquello contra lo que se hace una prueba, y lo que lee un [indexador](/es/protocol/architecture/indexer).

**El estado de la cadena es la autoridad.** El conjunto de trabajo del bloque es un diario que sirve para construir salida determinista, no una fuente de verdad. El estado del motor es una reconstrucción del estado de la cadena optimizada para la ejecución; tiene que poder derivarse del registro confirmado, nunca al revés.

Invertir esto produce un fallo concreto y reconocible: un motor cuya vista en memoria se ha desviado de lo que se confirmó seguirá sirviendo respuestas, y todas ellas estarán mal de una forma que solo aparece en la compensación.

<h2 id="keys">
  Claves
</h2>

El estado de la cadena se direcciona por clave. El estado de trading se agrupa en espacios de nombres propios y con versión explícita: la configuración de comisiones, el índice de perpetuos, la tabla de tramos de apalancamiento o la lista de roles administrativos.

El sufijo de versión no es decoración. Cuando cambia la forma de una configuración, esta pasa a una nueva versión de su clave, y la clave anterior se conserva para que el estado escrito con el esquema antiguo se pueda seguir leyendo durante la migración. Un lector que fije una versión en el código y no vuelva a comprobarla leerá configuración obsoleta sin avisar después de una migración; un lector que resuelva la clave actual, no.

<Note>
  Por esto la configuración debería leerse de la cadena y no fijarse en el código del cliente. El [servicio de niveles de comisiones](/es/protocol/architecture/programs) lee la configuración de comisiones vigente en cada ciclo exactamente por esta razón: una tabla de niveles empotrada en un cliente es una tabla que con el tiempo dejará de coincidir con la que la red está aplicando.
</Note>

<h2 id="versions">
  Versiones
</h2>

Cada bloque confirmado avanza una versión. Los valores de estado se almacenan asociados a la versión en la que se escribieron, lo que significa que el almacén no es solo “el estado actual” sino “el estado en cualquier versión”.

Esa propiedad es lo que hace posibles varias cosas a la vez:

* **Las pruebas** pueden producirse contra una versión concreta y no solo contra el presente.
* **La reejecución** puede empezar desde cualquier versión, no solo desde el génesis.
* **Las lecturas** pueden ser históricas: un indexador que reconstruye el historial de una posición está pidiendo versiones antiguas, no recorriendo un log.
* **La poda** pasa a ser una decisión de política sobre cuánto histórico conservar, y no una limitación estructural.

<h2 id="what-ends-up-committed">
  Qué acaba confirmado
</h2>

La ejecución del kernel produce dos cosas por bloque. Cada transacción lleva sus propias escrituras y sus propios eventos, ligados a ella. Los efectos que no pertenecen a ninguna transacción de usuario concreta (flujos de financiación, movimientos del fondo de seguro, contadores a nivel de bloque) van a un canal de sistema aparte.

Entre los dos, no se pierde nada. No hay ningún efecto de ejecución dentro del kernel que falte a la vez en la salida de una transacción y en el canal de sistema. Esa completitud es lo que permite tratar el registro confirmado como la historia entera y no como un resumen de ella, y es la razón por la que un evento se puede rastrear hasta la transacción que lo causó incluso cuando la casación se ejecutó por lotes.

<h2 id="where-to-go-next">
  Qué leer a continuación
</h2>

<CardGroup cols={2}>
  <Card title="Almacenamiento y pruebas" href="/es/protocol/architecture/state/storage">
    Cómo se almacena físicamente el estado confirmado, cómo se autentica y cómo se poda.
  </Card>

  <Card title="Sincronización de estado" href="/es/protocol/architecture/state/sync">
    Cómo se pone al día un nodo que nunca ha visto la cadena.
  </Card>

  <Card title="IntentionKernel" href="/es/protocol/architecture/kernel">
    Dónde viven el estado del motor y el conjunto de trabajo del bloque.
  </Card>

  <Card title="Indexador" href="/es/protocol/architecture/indexer">
    Convertir el estado confirmado en algo consultable.
  </Card>
</CardGroup>