Skip to main content
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.

​
Tres representaciones

Estado del motormercados · cuentas · posiciones · libros · cámara de compensaciónpersiste entre bloques · reconstrucción
Conjunto de trabajomarcas · cuentas tocadas · ejecuciones · salidadura un bloque · un diario
Estado de la cadenaclave-valor versionado, autenticado por Merklela autoridad
El fallo que esto evitaUn 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.
el estado del motor debe poder derivarse del registro confirmado, nunca al revés
El estado del motor es lo que el 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. 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.

​
Claves

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

​
Versiones

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.

​
Qué acaba confirmado

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.

​
Qué leer a continuación

Almacenamiento y pruebas

Cómo se almacena físicamente el estado confirmado, cómo se autentica y cómo se poda.

Sincronización de estado

Cómo se pone al día un nodo que nunca ha visto la cadena.

IntentionKernel

Dónde viven el estado del motor y el conjunto de trabajo del bloque.

Indexador

Convertir el estado confirmado en algo consultable.