Skip to main content
El estado confirmado tiene que satisfacer dos exigencias que tiran en direcciones opuestas. La ejecución quiere el valor actual de una clave, rápido, millones de veces. La verificación quiere una prueba de que un valor era lo que la red dice que era en una versión concreta. Servir ambas desde una sola estructura significa hacer las dos cosas mal. Por eso el almacenamiento reparte el problema entre almacenes separados, cada uno con la forma de su propio patrón de acceso.

​
Tres almacenes

Bloque confirmado
Almacén del libro mayortransacciones · salidas · eventos · escrituras · acumuladores · metadatos
Reejecución y auditoría
Almacén KV de estadovalores actuales e históricos, dieciséis fragmentos, estado caliente en su nivel
Consultas y ejecución
Almacén Merkle de estadoun árbol Merkle disperso versionado y los índices de nodos reemplazados
Verificación — pruebas
Una lectura que solo necesita un valor no paga recorrer el árbol, y una prueba no se reconstruye desde un almacén optimizado para consultas puntuales.
El almacén del libro mayor guarda el historial de la cadena: transacciones, sus salidas y datos auxiliares, eventos, conjuntos de escrituras, metadatos de bloque y los acumuladores. Esto es lo que se reejecuta. El almacén KV de estado guarda los valores de estado, direccionados por clave y versión. Esto es lo que leen la ejecución y las consultas. Está fragmentado en dieciséis partes, de modo que las escrituras de un bloque se reparten entre dieciséis instancias independientes de RocksDB en vez de competir por una sola. El estado de acceso frecuente se mantiene además en su propio nivel, para que el conjunto de trabajo de un mercado activo no haya que buscarlo entre todo lo que la cadena ha almacenado alguna vez. El almacén Merkle de estado guarda la estructura autenticada: los nodos del árbol que permiten probar un valor, y los índices que registran qué nodos han quedado reemplazados. Separarlos significa que una lectura que solo necesita un valor no paga el recorrido del árbol, y que una prueba no tiene que reconstruirse desde un almacén optimizado para consultas puntuales.

​
Autenticación

Dos estructuras de Merkle hacen trabajos distintos.
Árbol Merkle disperso versionado
Acumuladores
Tu clave y su valor
hash hermano
hash hermano
Raíz de estado, confirmada por consenso
Tu transacción, o un evento
Acumulador de transacciones · de eventoscada uno fija todo lo incluido hasta ahí, y su orden
Raíz del libro mayor, confirmada por consenso
El árbol prueba cuál era un valor; los acumuladores prueban qué ocurrió y en qué orden. Juntos hacen demostrable “esta transacción está en la cadena en esta posición” sin guardar la cadena.
Un árbol de Merkle disperso y versionado autentica el estado. Cada clave tiene una posición determinada por su hash, y cada versión del árbol comparte los nodos que no cambiaron, así que escribir una clave en un bloque añade un camino, no un árbol. La prueba de una clave en una versión es el camino desde la hoja de esa clave hasta la raíz que la red confirmó. Los acumuladores autentican el orden. Uno acumula transacciones y otro acumula eventos, y cada uno produce una raíz que fija todo lo incluido hasta ese punto y su orden. Esto es lo que hace demostrable “esta transacción está en la cadena en esta posición” sin tener que guardar la cadena. Entre los dos: el árbol de estado prueba cuál era un valor, los acumuladores prueban qué ocurrió y en qué orden.

​
Estado especulativo

Los resultados de un bloque existen antes de confirmarse. En lugar de escribirlos en el árbol duradero y deshacerlo si el bloque no se confirma, el estado sin confirmar se mantiene en una capa Merkle dispersa en memoria sobre la última versión confirmada. La ejecución lee a través de esa capa y ve una vista consistente. Si el bloque se confirma, la capa se materializa. Si no, la capa se descarta y nunca se tocó nada duradero. Esto es lo que impide que la ejecución especulativa deje restos en el almacenamiento.

​
Cachés

Los nodos del árbol se cachean en dos niveles: una caché consciente de las versiones, que mantiene direccionables las versiones recientes, y una caché LRU por debajo. El patrón de acceso de una cadena de trading (un conjunto pequeño de claves calientes que se tocan en cada bloque, frente a una larga cola que se toca rara vez) es exactamente la forma para la que sirven.

​
Poda

Conservar todas las versiones para siempre es una elección, no un requisito. Tres podadores independientes se ejecutan sobre los tres almacenes, cada uno con su propia política de retención: uno sobre el libro mayor, uno sobre los valores de estado y otro sobre los nodos Merkle. Los podadores de Merkle y de valores de estado se guían por índices de obsolescencia que se escriben al mismo tiempo que los datos. Cuando una versión reemplaza un nodo o un valor, la entrada reemplazada se registra como obsoleta en esa versión. La poda es entonces un recorrido por rangos sobre un índice y no una búsqueda de basura: quien escribió ya dijo qué iba a ser recolectable y cuándo.
La retención es una decisión del operador con consecuencias reales. Un nodo podado de forma agresiva sirve el estado actual con eficiencia y no puede responder consultas históricas ni servir sincronización de estado a un nodo que arranque desde más atrás. Un nodo de archivo lo guarda todo y lo paga. Consulta Ejecutar un nodo.

​
Copias de seguridad y restauración

Los almacenes se pueden respaldar y restaurar de forma independiente del nodo en ejecución, que es lo que hace posible levantar un nodo desde una instantánea en lugar de reejecutar desde el génesis, y verificar el estado de un nodo restaurado contra las raíces confirmadas en lugar de confiar en la copia.

​
Qué leer a continuación

Sincronización de estado

Cómo se pone al día un nodo con la cadena sin reejecutarla entera.

Modelo de estado

Qué se está almacenando y qué representación tiene la autoridad.

Indexador

Reconstruir el historial a partir de registros confirmados.

Ejecutar un nodo

Los roles de nodo y cómo solicitar información para operar uno.