State Trie

¿Qué es un State Trie en cripto?

Un state trie es una estructura de datos criptográfica que almacena el estado actual de una blockchain de forma que pueda actualizarse, verificarse y resumirse eficientemente mediante un único hash raíz.

En las blockchains de estilo Ethereum, el state trie es la estructura que asigna direcciones de cuentas a datos de cuenta, como saldos, nonces, raíces de almacenamiento de contratos inteligentes y hashes de código.

La documentación de Ethereum sobre Merkle Patricia Trie explica que Ethereum tiene un state trie global que se actualiza cada vez que un cliente procesa un bloque.

Este state trie global es una de las partes más importantes de la capa de ejecución de Ethereum porque representa el estado activo de la red después de aplicar las transacciones.

Un state trie no es lo mismo que una lista de transacciones históricas.

Las transacciones describen lo que ocurrió, mientras que el state trie describe el aspecto actual de la blockchain después de que esas transacciones modificaran saldos, almacenamiento de contratos y datos de cuentas.

Por ejemplo, si un usuario envía ETH de una cuenta a otra, la transacción se registra en un bloque, pero el state trie cambia porque se actualizan los saldos de dos cuentas.

Si un usuario llama a un contrato inteligente, la transacción se registra en un bloque, pero el state trie puede cambiar porque pueden actualizarse el almacenamiento del contrato, los saldos y los nonces de las cuentas.

En términos sencillos, el state trie es la base de datos autenticada del estado actual de las cuentas de la blockchain.

Por qué importa el State Trie

El state trie importa porque las blockchains necesitan una forma segura de demostrar cuál es el estado actual.

El estado de una blockchain puede incluir millones de cuentas, contratos inteligentes, saldos, entradas de almacenamiento y otros valores.

Los nodos deben coincidir en ese estado para decidir si las nuevas transacciones son válidas.

Si un remitente no tiene saldo suficiente, la transacción debe fallar.

Si una posición de almacenamiento de un contrato tiene un determinado valor, una llamada de contrato inteligente puede comportarse de forma diferente.

Si ya se ha utilizado un nonce, no debe aceptarse una transacción repetida.

El state trie proporciona a los clientes una estructura determinista para almacenar y comprobar estos valores.

También produce una única raíz de estado que puede incluirse en la cabecera de un bloque.

Si dos clientes procesan el mismo bloque y alcanzan la misma raíz de estado, tienen indicios sólidos de que coinciden en el estado resultante.

Esto convierte al state trie en un elemento central para el consenso blockchain, la verificación, las pruebas de clientes ligeros, la sincronización de nodos, la ejecución de contratos inteligentes y la integridad de los datos.

State Trie y State Root

La state root es el hash raíz del state trie después de procesar todas las transacciones de un bloque.

Las cabeceras de bloque de Ethereum incluyen un stateRoot, que representa un compromiso criptográfico con todo el estado global en ese bloque.

La documentación de Ethereum sobre Merkle Patricia Trie explica que las cabeceras de bloque de la capa de ejecución de Ethereum contienen raíces para el state trie, el transactions trie y el receipts trie.

La state root es importante porque representa un compromiso criptográfico compacto con una base de datos mucho mayor.

Un usuario no necesita descargar todos los valores de cuentas y almacenamiento de contratos para verificar una afirmación concreta si dispone de una prueba válida.

En su lugar, puede verificar que un valor pertenece al estado comprometido por la state root.

Si cambia cualquier saldo de cuenta, raíz de almacenamiento de contrato, nonce o hash de código, cambia la ruta de hashes que conduce a la raíz.

Esto significa que un estado diferente debe producir una state root diferente.

Por tanto, la state root es una huella del estado completo de la blockchain en un bloque concreto.

Ayuda a convertir una enorme base de datos de estado en un único valor verificable.

Cómo funciona el State Trie

El state trie de Ethereum utiliza un Merkle Patricia Trie modificado.

Un Merkle Patricia Trie combina ideas de árboles de Merkle, tries radiales y tries de Patricia.

Un trie es una estructura de clave-valor similar a un árbol, en la que la ruta a través del árbol se basa en la clave.

Un Patricia trie comprime rutas para que el árbol no desperdicie espacio en largas cadenas de nodos vacíos.

Un árbol de Merkle añade hashes criptográficos para que los datos puedan verificarse mediante rutas de hashes.

Ethereum combina estas características para que los clientes puedan almacenar el estado de las cuentas, actualizarlo eficientemente y verificarlo utilizando hashes raíz y pruebas de Merkle.

En el state trie de Ethereum, la ruta se basa en el hash Keccak-256 de la dirección de la cuenta.

El valor almacenado en esa ruta es el objeto de cuenta codificado con RLP.

La documentación oficial de Ethereum establece que un objeto de cuenta de Ethereum es una matriz de cuatro elementos que contiene nonce, balance, storageRoot y codeHash.

Este diseño hace que cada cuenta sea accesible a través de una ruta criptográfica determinista.

¿Qué datos se almacenan en el State Trie?

El state trie almacena objetos de cuenta en lugar de todos los valores de almacenamiento de contratos directamente dentro del trie global principal.

Cada objeto de cuenta de Ethereum contiene un nonce.

Cada objeto de cuenta de Ethereum contiene un saldo.

Cada objeto de cuenta de Ethereum contiene un storageRoot.

Cada objeto de cuenta de Ethereum contiene un codeHash.

El nonce ayuda a prevenir la repetición de transacciones y registra la actividad de la cuenta.

El saldo registra la cantidad de moneda nativa mantenida por la cuenta.

El storageRoot apunta a otro trie que almacena el almacenamiento del contrato inteligente de esa cuenta.

El codeHash representa un compromiso criptográfico con el bytecode del contrato inteligente asociado a una cuenta de contrato.

Las cuentas de propiedad externa suelen tener código vacío y almacenamiento de contrato vacío.

Las cuentas de contratos inteligentes pueden tener código y almacenamiento que afectan a su ejecución.

State Trie frente a Storage Trie

El state trie y el storage trie están relacionados, pero son diferentes.

El state trie es la estructura global que asigna direcciones de cuentas a objetos de cuenta.

Un storage trie es un trie independiente utilizado para el almacenamiento de una cuenta específica de contrato inteligente.

La documentación de Ethereum explica que existe un storage trie separado para cada cuenta que tiene almacenamiento de contrato.

El objeto de cuenta en el state trie almacena un storageRoot, que es la raíz del storage trie de esa cuenta.

Esto significa que el state trie global no contiene directamente cada slot de almacenamiento de cada contrato.

En su lugar, contiene objetos de cuenta y cada cuenta de contrato puede apuntar a su propio storage trie.

Por ejemplo, un contrato de token puede almacenar los saldos de los usuarios en su propio storage trie de contrato.

El state trie global almacena el objeto de cuenta del contrato de token, y ese objeto apunta a la raíz de almacenamiento del contrato de token.

Este diseño por capas ayuda a separar el estado de nivel de cuenta del almacenamiento de nivel de contrato.

State Trie frente a Transactions Trie

El state trie es diferente del transactions trie.

El state trie almacena el estado de cuenta resultante después de ejecutar las transacciones.

El transactions trie almacena las transacciones incluidas en un bloque específico.

Cada bloque tiene su propio transactions trie.

El transactions trie no se actualiza continuamente entre bloques de la misma forma que el state trie global.

El state trie evoluciona de bloque a bloque a medida que las transacciones modifican saldos de cuentas y almacenamiento de contratos.

Una transacción puede entenderse como una instrucción.

El state trie puede entenderse como el resultado después de aplicar las instrucciones.

Esta distinción es importante porque una blockchain no es solo un registro ordenado de transacciones.

También es una máquina de estados en la que cada transacción válida lleva el sistema de un estado al siguiente.

State Trie frente a Receipts Trie

El state trie también es diferente del receipts trie.

El receipts trie almacena los recibos de transacciones de un bloque.

Un recibo registra resultados de ejecución como el estado, el gas utilizado, los logs y los datos de eventos.

El state trie registra el estado final de las cuentas después de la ejecución.

Los recibos ayudan a las aplicaciones a entender qué ocurrió durante la ejecución de una transacción.

El state trie ayuda a los clientes a verificar cuál pasó a ser el estado de la blockchain después de la ejecución.

Por ejemplo, una transacción de contrato inteligente puede emitir un evento registrado en un recibo.

La misma transacción también puede modificar el almacenamiento del contrato registrado mediante el state trie y el storage trie.

Ambas estructuras son importantes, pero responden a preguntas diferentes.

El receipts trie responde qué produjo la transacción, mientras que el state trie responde cuál es ahora el estado de la cadena.

Nodos de Merkle Patricia Trie

El Merkle Patricia Trie modificado de Ethereum utiliza varios tipos de nodos.

La documentación oficial de Ethereum describe nodos de rama, nodos hoja, nodos de extensión y nodos vacíos.

Un nodo de rama puede apuntar a hasta 16 posibles rutas secundarias y también puede contener un valor.

Un nodo hoja almacena la ruta codificada final y el valor.

Un nodo de extensión comprime un segmento de ruta compartido para que el trie evite largas cadenas de nodos dispersos.

Este diseño resulta útil porque las claves de Ethereum son largas y dispersas.

Sin compresión de rutas, muchas búsquedas desperdiciarían pasos en rutas vacías o sin ramificaciones.

Mediante nodos de extensión y nodos hoja, Ethereum hace que el trie sea más compacto que un trie radial básico.

Mediante hashes, Ethereum hace que el trie sea criptográficamente verificable.

Esta combinación explica por qué la estructura se denomina Merkle Patricia Trie modificado.

Codificación RLP y hashing

Ethereum utiliza la codificación Recursive Length Prefix, conocida habitualmente como RLP, para serializar muchas estructuras de datos de la capa de ejecución.

En el state trie, los objetos de cuenta se codifican con RLP antes de colocarse como valores.

Los nodos del trie también se codifican antes de aplicarles hash o almacenarlos.

La documentación de Ethereum sobre Merkle Patricia Trie explica que, cuando un nodo hace referencia a otro, la referencia puede ser el hash Keccak-256 del nodo codificado con RLP, según la longitud codificada.

Esto importa porque todos los nodos deben codificarse de forma determinista.

Si dos clientes codifican el mismo estado de forma diferente, podrían calcular raíces distintas y no llegar a un consenso.

Por tanto, la codificación determinista es un detalle crítico para el consenso.

El hashing también hace visible la manipulación, porque cambiar un valor cambia el hash del nodo y la ruta de hashes de vuelta a la raíz.

El resultado es una base de datos verificable de clave-valor, en la que un hash raíz representa un compromiso con todos los valores incluidos.

Esta es la base criptográfica de las pruebas de estado.

Pruebas de estado

Una prueba de estado es una prueba criptográfica de que una determinada cuenta o valor de almacenamiento existe en el estado comprometido por una state root concreta.

La propuesta EIP-1186 eth_getProof explica que el estado de Ethereum basado en árboles de Merkle permite verificar valores de cuentas y almacenamiento mediante pruebas de Merkle.

Una prueba suele contener los nodos necesarios para reconstruir la ruta desde el valor objetivo hasta la state root.

Si el hash reconstruido coincide con la state root de confianza, el valor puede verificarse sin confiar plenamente en el proveedor de datos.

Esto es útil para clientes ligeros, bridges, aplicaciones cross-chain, wallets móviles, auditores y sistemas de contratos inteligentes que necesitan verificar estado externo.

Por ejemplo, una prueba puede mostrar que una cuenta tenía un determinado saldo en un bloque concreto.

Una prueba también puede mostrar que un slot de almacenamiento de un contrato tenía un valor determinado en un bloque específico.

Las pruebas de estado son potentes porque permiten la verificación selectiva en lugar de descargar toda la base de datos de estado.

El state trie hace posibles estas pruebas.

Sin una estructura de estado autenticada, los usuarios necesitarían confiar mucho más en los proveedores RPC y los indexadores.

eth_getProof

eth_getProof es un método JSON-RPC de Ethereum diseñado para devolver valores de cuentas y almacenamiento junto con sus pruebas de Merkle.

EIP-1186 define eth_getProof como un método que devuelve valores de cuenta y valores de almacenamiento de una cuenta especificada junto con datos de prueba.

La prueba puede incluir datos accountProof que siguen la ruta desde la state root.

La prueba también puede incluir datos storageProof que siguen la ruta desde una raíz de almacenamiento de contrato.

Este método resulta útil cuando una aplicación quiere pruebas en lugar de solo una respuesta RPC sin procesar.

Por ejemplo, una wallet o bridge puede querer verificar un slot de almacenamiento frente a la state root de un bloque.

Una consulta de saldo sencilla solo comunica un valor.

Una consulta de prueba comunica el valor y los datos criptográficos necesarios para comprobarlo.

Esta distinción importa porque los proveedores RPC pueden ser incorrectos, estar censurados, tener errores o ser maliciosos.

Las pruebas de Merkle permiten a los usuarios reducir la confianza en el proveedor al comprobar la prueba frente a una cabecera de bloque de confianza.

State Trie y nodos completos

Los nodos completos necesitan el estado actual para verificar nuevos bloques y transacciones.

La documentación de Ethereum sobre nodos de archivo explica que los datos globales de cada cuenta y contrato se almacenan en una base de datos de tries denominada state.

Un nodo completo sigue el estado más reciente de la red para poder validar los bloques y transacciones entrantes.

Los nodos completos no suelen conservar indefinidamente todos los estados históricos.

Pueden conservar el estado más reciente y suficientes datos de estado recientes para gestionar reorganizaciones de cadena y el funcionamiento normal de la red.

Los estados históricos más antiguos a menudo pueden podarse porque no son necesarios para la verificación estándar de la punta más reciente de la cadena.

Por esta razón, consultar saldos antiguos o almacenamiento antiguo de contratos puede resultar difícil en un nodo completo normal.

El estado actual es necesario para el funcionamiento de la red.

Todos los estados intermedios históricos son útiles para análisis y pruebas, pero requieren mucho más almacenamiento.

Por tanto, el state trie afecta al hardware de los nodos, la sincronización, el almacenamiento y la descentralización.

State Trie y nodos de archivo

Un nodo de archivo almacena estados históricos en lugar de conservar solo el estado actual y los estados recientes.

La documentación de Ethereum sobre nodos de archivo explica que estos almacenan cada estado histórico creado después de cada bloque, a cambio de mayores requisitos de disco para consultas históricas rápidas.

Esto es importante para exploradores de blockchain, auditores, investigadores, equipos de seguridad, herramientas fiscales, proveedores de análisis y desarrolladores de dApps.

Por ejemplo, un usuario puede preguntar cuál era el saldo de una cuenta en un bloque de hace varios años.

Un nodo completo puede necesitar volver a ejecutar transacciones históricas para reconstruir ese estado.

Un nodo de archivo a menudo puede acceder directamente al estado histórico desde el disco.

Esta velocidad tiene como contrapartida requisitos de almacenamiento mucho mayores.

Por tanto, el historial del state trie es valioso, pero costoso.

Esta es la razón por la que muchos usuarios dependen de proveedores de infraestructura para consultas de estados históricos.

Sin embargo, depender de un proveedor puede añadir riesgos de confianza, disponibilidad y censura.

State Trie y contratos inteligentes

Los contratos inteligentes dependen en gran medida del state trie y los storage tries.

El objeto de cuenta de un contrato aparece en el state trie global.

El código del contrato se representa mediante un compromiso criptográfico a través del codeHash.

El almacenamiento persistente del contrato se representa mediante un compromiso criptográfico a través del storageRoot.

Cuando se ejecuta un contrato inteligente, puede leer y escribir slots de almacenamiento.

Esos cambios de almacenamiento actualizan el storage trie del contrato.

El nuevo storageRoot del contrato actualiza el objeto de cuenta en el state trie global.

El objeto de cuenta actualizado cambia la state root global.

Esto significa que incluso una pequeña actualización del almacenamiento de un contrato puede cambiar la state root final de un bloque.

Por tanto, el state trie forma parte de cómo los resultados de los contratos inteligentes se hacen visibles para el consenso.

State Trie y saldos de tokens

Muchos saldos de tokens se almacenan dentro del almacenamiento de contratos inteligentes, en lugar de directamente en el state trie global.

Por ejemplo, un contrato de token fungible puede almacenar una asignación de direcciones de usuario a saldos de tokens.

Esa asignación se encuentra dentro del storage trie del contrato de token.

El state trie global almacena el objeto de cuenta del contrato de token, incluido el storageRoot de ese contrato.

Esto significa que un saldo de moneda nativa y un saldo de token se almacenan de forma diferente.

Un saldo de moneda nativa forma parte de un objeto de cuenta en el state trie global.

Un saldo de token suele ser un valor de almacenamiento dentro del storage trie de un contrato de token específico.

Esta distinción importa para las pruebas y las auditorías.

Para probar un saldo de moneda nativa, normalmente basta la prueba de cuenta.

Para probar un saldo de token, una prueba puede requerir tanto la prueba de cuenta del contrato de token como la prueba de almacenamiento del slot de saldo relevante.

State Trie y clientes ligeros

Los clientes ligeros son clientes que verifican datos blockchain sin almacenar el estado completo.

Un state trie ayuda a los clientes ligeros porque permite pruebas compactas vinculadas a cabeceras de bloque.

Un cliente ligero puede confiar en una cabecera de bloque o verificarla y, después, utilizar pruebas de Merkle para comprobar valores de estado concretos.

Esto es mucho menos costoso que almacenar localmente todo el estado.

Por ejemplo, una wallet móvil puede querer verificar que existe un valor de almacenamiento de contrato sin ejecutar un nodo completo de ejecución.

Un bridge puede querer verificar que un evento de retirada o estado de cuenta se incluyó en el estado de otra cadena.

El state trie proporciona la estructura autenticada necesaria para estos flujos de trabajo.

Sin embargo, los tamaños de las pruebas y los costes de generación de pruebas pueden seguir siendo considerables.

Esta es una de las razones por las que los investigadores de Ethereum han explorado alternativas como los árboles de Verkle.

El objetivo es hacer que la verificación de estado sea más ligera y escalable con el tiempo.

State Trie y clientes sin estado

Los clientes sin estado son una idea de escalabilidad blockchain a largo plazo en la que los validadores o usuarios pueden verificar bloques sin almacenar localmente todo el estado.

En lugar de que cada validador almacene todo el estado, los bloques o transacciones incluirían testigos que prueban el estado que utilizan.

El state trie es relevante porque los testigos actuales de Merkle Patricia Trie pueden ser grandes.

Los testigos grandes pueden hacer que la verificación sin estado sea ineficiente.

El artículo de Ethereum Foundation sobre la estructura de árboles de Verkle explica que los árboles de Verkle funcionan de forma parecida a los árboles de Merkle, pero pueden producir testigos mucho más pequeños mediante compromisos vectoriales.

Por esta razón, los árboles de Verkle se han investigado como posible sustituto de la estructura actual de compromiso de estado de Ethereum.

El state trie actual es seguro y está ampliamente probado, pero no fue diseñado para los testigos sin estado más pequeños posibles.

La investigación sobre sistemas sin estado tiene como objetivo, en parte, reducir la carga que el state trie impone a los nodos.

Para los usuarios, la conclusión práctica es que el diseño de la estructura de datos de estado afecta a la escalabilidad futura.

Para los desarrolladores, significa que los patrones de acceso al estado y los sistemas de pruebas pueden evolucionar a medida que avance la investigación de protocolos.

State Trie y árboles de Verkle

Un árbol de Verkle es una estructura propuesta de compromiso de estado que utiliza compromisos vectoriales en lugar de únicamente enlaces hash.

Ethereum.org indica que Ethereum prevé migrar a una estructura de árbol de Verkle en el futuro, aunque los plazos de protocolo y los detalles de implementación pueden cambiar.

Los árboles de Verkle están diseñados para hacer que las pruebas sean más pequeñas que las pruebas de Merkle Patricia Trie.

El artículo de Ethereum Foundation explica que los diseños de árboles de Verkle también combinan los tries de cuentas y almacenamiento con una distribución diferente.

Esto supondría un cambio importante, ya que actualmente Ethereum utiliza un state trie global y storage tries por cuenta.

Un modelo de estado basado en Verkle podría hacer más prácticos los clientes sin estado.

Sin embargo, una migración desde un state trie utilizado durante mucho tiempo a una nueva estructura de compromiso es compleja.

Afecta a clientes, pruebas, wallets, nodos, reglas de ejecución, disposición del almacenamiento y supuestos de los desarrolladores.

Por tanto, el state trie es tanto la base actual como una importante área de investigación continua de protocolos.

Comprender el state trie ayuda a entender por qué importa la investigación sobre Verkle.

State Trie y crecimiento del estado

El crecimiento del estado significa que el estado activo de la blockchain aumenta y resulta más difícil de mantener.

El state trie crece cuando permanecen activos más cuentas, contratos, slots de almacenamiento y datos de aplicaciones.

Un estado grande aumenta el uso de disco, el tiempo de sincronización, la carga de trabajo de la base de datos y los requisitos de hardware.

Si ejecutar nodos se vuelve demasiado costoso, menos usuarios podrán verificar la red de manera independiente.

Esto puede debilitar la descentralización.

El crecimiento del estado es diferente del crecimiento del historial blockchain porque el estado activo es necesario para procesar nuevas transacciones.

Las transacciones históricas son importantes, pero los estados intermedios antiguos a veces pueden podarse o regenerarse.

El estado actual debe estar disponible para la validación.

Esto convierte el crecimiento del estado en uno de los problemas de escalabilidad más difíciles para las blockchains de contratos inteligentes.

El state trie es la estructura de datos en la que este crecimiento se hace visible para los clientes.

State Trie y costes de gas

Los costes de gas están diseñados en parte para asignar un precio a la computación y al acceso al estado.

Escribir almacenamiento persistente es caro porque aumenta o modifica el estado que los nodos deben mantener.

Leer desde el estado también puede conllevar costes porque el acceso al estado afecta al rendimiento de ejecución.

Cuando un contrato inteligente crea nuevo almacenamiento, es posible que el storage trie y la state root global deban actualizarse.

Cuando un contrato inteligente elimina almacenamiento, las normas de gas pueden proporcionar reembolsos o incentivos según las normas vigentes del protocolo.

Estos mecanismos de gas están relacionados con el state trie porque el estado persistente es un recurso de red compartido.

Si las escrituras de almacenamiento fueran demasiado baratas, las aplicaciones podrían inflar el state trie con datos de escaso valor.

Si las escrituras de almacenamiento fueran demasiado caras, podría resultar más difícil crear aplicaciones útiles.

Los diseñadores de protocolos deben equilibrar usabilidad, seguridad y sostenibilidad del estado.

El state trie se sitúa en el centro de esta contrapartida económica.

State Trie y proveedores RPC

Los proveedores RPC exponen métodos que permiten a las wallets y aplicaciones leer el estado blockchain.

Los métodos de estado habituales incluyen consultas de saldo, consultas de almacenamiento, consultas de código, consultas de recuento de transacciones y llamadas de contrato.

La documentación JSON-RPC de Ethereum describe los métodos de estado como métodos que informan de datos almacenados actuales, como saldos de cuentas, datos de contratos y estimaciones de gas.

Cuando una wallet solicita el saldo de una cuenta, el proveedor RPC lee datos de estado de un nodo.

Cuando una dApp solicita un valor de contrato, el proveedor RPC puede leer un slot de almacenamiento o simular una llamada frente al estado actual.

Los usuarios suelen depender de proveedores RPC sin pensar en el state trie que hay detrás de la respuesta.

Sin embargo, el state trie es lo que permite que dichos valores formen parte de un estado blockchain verificable.

Para aplicaciones que requieren un alto nivel de confianza, las respuestas RPC sin procesar pueden no ser suficientes.

Las pruebas de estado pueden proporcionar garantías más sólidas cuando se admiten y verifican correctamente.

Esto es importante para bridges, auditorías, herramientas de cumplimiento normativo y sistemas cross-chain.

State Trie y exploradores de blockchain

Los exploradores de blockchain utilizan datos de estado para mostrar saldos, tenencias de tokens, almacenamiento de contratos, efectos de transacciones e información histórica de cuentas.

Los exploradores suelen basarse en datos indexados en lugar de utilizar únicamente consultas directas al state trie.

La indexación hace que las búsquedas sean más rápidas y que las interfaces de usuario sean más fáciles de crear.

Sin embargo, los datos indexados proceden en última instancia del estado blockchain, las transacciones, los logs, los recibos y los resultados de ejecución.

Si un explorador muestra el saldo de una cuenta en un bloque concreto, esa información está vinculada al estado en ese bloque.

Si un explorador muestra saldos de tokens, a menudo los deriva de cambios en el almacenamiento de contratos y eventos.

Los nodos de archivo pueden ayudar a los exploradores a responder rápidamente a preguntas sobre estados históricos.

Sin acceso al estado histórico, un explorador puede necesitar reconstruir estados antiguos a partir del historial de transacciones.

El state trie no suele ser visible para los usuarios normales de exploradores.

Aun así, es una de las estructuras fundamentales que hacen verificables los datos de los exploradores a nivel de protocolo.

State Trie y bridges

Los bridges a menudo necesitan verificar estados o eventos de otro entorno blockchain.

Los state tries y las pruebas de Merkle pueden facilitar esta verificación.

Por ejemplo, un bridge puede necesitar una prueba de que un mensaje, valor de almacenamiento o estado de cuenta existía en un bloque determinado.

Si el bridge puede confiar en la cabecera de bloque y verificar la prueba, puede reducir la dependencia de un proveedor de datos centralizado.

Por esta razón, EIP-1186 señala que las pruebas de Merkle son importantes para las tecnologías Layer 2.

Las pruebas de estado pueden ayudar a los sistemas a verificar afirmaciones sobre saldos, slots de almacenamiento y estado de contratos.

Sin embargo, la seguridad de un bridge depende de mucho más que de la estructura de pruebas.

También depende de la verificación de cabeceras, los supuestos de finalidad, las pruebas de fraude, las pruebas de validez, los controles multisig, la seguridad de los contratos inteligentes y el diseño operativo.

Una prueba correcta de state trie es potente, pero solo es una parte de la seguridad de un bridge.

Los usuarios no deben asumir que un bridge es seguro solo porque mencione pruebas de Merkle.

State Trie y redes Layer 2

Las redes Layer 2 suelen utilizar state roots, pruebas y estructuras de compromiso para resumir la ejecución off-chain o en cadenas independientes.

Una Layer 2 puede publicar state roots en una cadena Layer 1.

Puede utilizar pruebas de fraude, pruebas de validez o mecanismos de disponibilidad de datos para demostrar que sus transiciones de estado son válidas.

El diseño exacto depende de la arquitectura de Layer 2.

El state trie de Ethereum ofrece un contexto importante porque muestra cómo una blockchain puede comprometerse con un estado grande mediante raíces compactas.

Los sistemas Layer 2 pueden utilizar estructuras de datos diferentes, pero el concepto es similar.

Un gran estado de ejecución se resume mediante un compromiso.

Los usuarios y contratos verifican después afirmaciones frente a ese compromiso.

Esta es una de las razones por las que los state tries no son solo un tema de bajo nivel para clientes.

También forman parte de la escalabilidad, el diseño de rollups y la verificación cross-chain.

State Trie y seguridad

El state trie mejora la seguridad al hacer detectable la manipulación del estado.

Si un nodo cambia el saldo de una cuenta sin seguir normas de transacción válidas, la state root resultante no coincidirá con la cabecera de bloque aceptada.

Si un proveedor miente sobre un valor de almacenamiento, una prueba de Merkle válida debe fallar frente a la state root de confianza.

Si dos clientes discrepan sobre las reglas de transición de estado, pueden calcular state roots diferentes y rechazar los bloques del otro.

Esto hace que el state trie sea crítico para el consenso.

Los errores en la implementación del state trie pueden ser graves porque pueden provocar desacuerdos entre clientes o una verificación incorrecta del estado.

Por esta razón, los clientes de ejecución deben implementar cuidadosamente la lógica del trie, la codificación, el hashing y las actualizaciones de estado.

La seguridad del state trie también depende de la resistencia de los hashes criptográficos.

Si los atacantes pudieran crear dos estados diferentes con la misma raíz, podrían quebrar la integridad de las pruebas.

Los state tries de las blockchains modernas se basan en supuestos criptográficos que hacen que esto sea prácticamente inviable en las condiciones actuales.

State Trie e implementaciones de clientes

Diferentes clientes de ejecución de Ethereum implementan las mismas reglas de estado, pero pueden utilizar diferentes bases de datos internas y optimizaciones.

El resultado crítico para el consenso debe ser la misma state root.

La forma en que un cliente almacena nodos del trie en disco puede variar.

La forma en que un cliente almacena en caché el estado puede variar.

La forma en que un cliente poda estados antiguos puede variar.

La forma en que un cliente ofrece consultas históricas puede variar.

Esto significa que el state trie es tanto un concepto de protocolo como un desafío de implementación.

A nivel de protocolo, los clientes deben coincidir en la raíz y las reglas de transición.

A nivel de base de datos, los equipos de clientes pueden optimizar la disposición del almacenamiento, la velocidad de acceso, la poda, las instantáneas y el comportamiento de sincronización.

Los usuarios suelen percibir estas diferencias como rendimiento del nodo, uso de disco, tiempo de sincronización y fiabilidad de RPC.

State Trie y depuración para desarrolladores

Los desarrolladores suelen encontrarse indirectamente con el state trie a través de slots de almacenamiento, pruebas de cuentas y consultas de estado histórico.

Un desarrollador de contratos inteligentes puede necesitar saber cómo se almacenan las asignaciones en el almacenamiento de contratos.

Un investigador de seguridad puede necesitar demostrar que un slot de almacenamiento tenía un valor específico en un bloque.

Un desarrollador de bridges puede necesitar verificar un valor de estado de contrato de otro entorno.

Un desarrollador de wallets puede necesitar explicar por qué una consulta de saldo depende de una etiqueta de bloque como latest o finalized.

Un desarrollador de dApps puede necesitar un nodo de archivo al depurar un estado antiguo de contrato.

Comprender el state trie ayuda a los desarrolladores a interpretar correctamente estos problemas.

También les ayuda a evitar confundir el historial de transacciones con el estado actual.

Muchos errores provienen de asumir que los eventos, el almacenamiento, los saldos y el estado de cuenta son lo mismo.

El state trie aclara dónde reside cada dato.

State Trie y experiencia de usuario habitual

La mayoría de los usuarios cripto nunca interactúan directamente con un state trie.

Interactúan con wallets, dApps, exploradores y proveedores RPC.

Cuando una wallet muestra un saldo, está leyendo estado.

Cuando una dApp comprueba si un usuario aprobó un token, está leyendo el estado de almacenamiento del contrato.

Cuando una llamada de contrato inteligente tiene éxito o falla, depende del estado actual.

Cuando un explorador muestra un valor de contrato en un bloque, depende del acceso al estado o de datos indexados derivados del estado.

El state trie es una infraestructura oculta, pero afecta cada día a la actividad normal de los usuarios.

Si el acceso al estado es lento, las dApps pueden parecer lentas.

Si un proveedor RPC ofrece un estado incorrecto, los usuarios pueden ver saldos erróneos o transacciones fallidas.

Si el estado histórico no está disponible, los usuarios pueden tener dificultades para auditar actividad antigua.

State Trie y malentendidos habituales

Un malentendido habitual es que el state trie almacena todas las transacciones.

El state trie almacena el estado actual de las cuentas, mientras que las transacciones se almacenan por separado en bloques y transaction tries.

Otro malentendido es que el almacenamiento de contratos inteligentes se almacena directamente en el state trie global.

El state trie global almacena objetos de cuenta, y el almacenamiento de contratos se guarda en storage tries separados a los que se hace referencia mediante valores storageRoot.

Un tercer malentendido es que un nodo completo siempre almacena todos los estados históricos.

Muchos nodos completos conservan el estado actual y reciente mientras podan estados intermedios más antiguos.

Un cuarto malentendido es que una state root es el estado en sí mismo.

Una state root es un compromiso criptográfico compacto con el estado, no toda la base de datos de estado.

Un quinto malentendido es que una prueba de Merkle demuestra cualquier posible hecho sobre un contrato.

Una prueba de Merkle demuestra un valor específico de cuenta o almacenamiento frente a una raíz específica, no todo el significado empresarial de ese valor.

Ventajas del State Trie

La primera ventaja del state trie es la verificabilidad.

Los usuarios y clientes pueden verificar valores de estado mediante pruebas vinculadas a una state root.

La segunda ventaja es el determinismo.

Los clientes que procesan el mismo bloque válido deberían alcanzar la misma state root.

La tercera ventaja es una búsqueda eficiente.

Las rutas del trie permiten a los clientes encontrar datos de cuentas y almacenamiento mediante claves deterministas.

La cuarta ventaja es la evidencia de manipulación.

Cambiar un valor cambia la ruta de hashes y la raíz final.

La quinta ventaja es la compatibilidad con clientes ligeros.

Las pruebas selectivas pueden verificar datos sin descargar todo el estado.

La sexta ventaja es una estructura clara de transición de estado.

Cada bloque transforma el estado anterior en un nuevo estado con una nueva raíz.

Estas ventajas hacen que el state trie sea una base de las blockchains de contratos inteligentes basadas en cuentas.

Limitaciones del State Trie

La primera limitación es el crecimiento del almacenamiento.

A medida que se acumulan más cuentas y valores de almacenamiento de contratos, el estado se vuelve más pesado para los nodos.

La segunda limitación es el tamaño de las pruebas.

Las pruebas de Merkle Patricia Trie pueden ser mayores de lo deseable para clientes sin estado y verificación a gran escala.

La tercera limitación es la complejidad de implementación.

La codificación, el hashing, la poda, el almacenamiento en caché y el almacenamiento en base de datos de los tries son difíciles de implementar correctamente.

La cuarta limitación es el coste del estado histórico.

Conservar todos los estados históricos requiere mucho más espacio de disco que el funcionamiento normal de un nodo completo.

La quinta limitación es la confusión de los desarrolladores.

Muchos desarrolladores malinterpretan la diferencia entre estado, almacenamiento, transacciones, recibos, logs y datos indexados.

Estas limitaciones explican por qué la gestión del estado sigue siendo un área activa de investigación e ingeniería.

El state trie funciona, pero plantea desafíos reales de escalabilidad y usabilidad.

Buenas prácticas para desarrolladores

Comprende la diferencia entre el estado de cuenta y el almacenamiento de contratos antes de crear sistemas basados en pruebas.

Utiliza la documentación oficial de Ethereum al aprender los mecanismos de Merkle Patricia Trie.

Utiliza eth_getProof cuidadosamente al desarrollar sistemas que necesiten pruebas de cuentas o almacenamiento.

Verifica las pruebas frente a cabeceras de bloque de confianza en lugar de confiar ciegamente en las respuestas RPC.

Recuerda que los saldos de tokens suelen encontrarse en el almacenamiento de contratos, no directamente en el state trie global.

Utiliza nodos de archivo o proveedores de datos de archivo cuando necesites acceso rápido a estados históricos antiguos.

Diseña contratos inteligentes que minimicen el almacenamiento persistente innecesario.

Ten en cuenta los costes de gas al escribir en almacenamiento porque el estado persistente es caro.

Sigue la investigación de protocolos, como los árboles de Verkle, si tu sistema depende en gran medida de pruebas de estado.

No asumas que el formato de prueba actual seguirá siendo invariable para siempre tras futuras actualizaciones de protocolo.

Buenas prácticas para usuarios

Utiliza wallets y exploradores de confianza, pero recuerda que sus pantallas proceden de consultas de estado y datos indexados.

Comprueba los números de bloque al comparar saldos o valores de contratos entre distintas herramientas.

Comprende que el saldo actual y el saldo histórico pueden requerir un acceso a datos diferente.

Utiliza verificación basada en pruebas cuando necesites una alta garantía y la herramienta la admita.

No asumas que una respuesta RPC sencilla equivale a una prueba criptográfica.

Ten cuidado al utilizar bridges o aplicaciones que afirmen verificar estado desde otra cadena.

Revisa si una aplicación utiliza estado actual, estado histórico, logs o indexación off-chain.

Comprende que los cambios en el almacenamiento de contratos inteligentes pueden afectar al comportamiento de una aplicación incluso cuando no sean evidentes las transferencias de tokens.

Recuerda que la transparencia blockchain depende de estructuras de datos como el state trie.

El state trie es invisible para la mayoría de usuarios, pero ayuda a que los datos de cadenas públicas sean verificables.

Preguntas frecuentes

¿Qué significa state trie?

Un state trie es un árbol criptográfico de clave-valor que almacena el estado actual de una blockchain y produce un hash raíz que representa un compromiso con ese estado.

¿Qué es el state trie de Ethereum?

El state trie de Ethereum es el Merkle Patricia Trie modificado global que asigna direcciones de cuentas con hash a objetos de cuenta codificados con RLP.

¿Qué se almacena en un objeto de cuenta de Ethereum?

Un objeto de cuenta de Ethereum contiene nonce, balance, storageRoot y codeHash.

¿Qué es una state root?

Una state root es el hash raíz del state trie después de ejecutar las transacciones de un bloque.

¿El state trie es lo mismo que el storage trie?

No, el state trie almacena objetos de cuenta, mientras que los storage tries almacenan el almacenamiento de contratos de cuentas de contrato individuales.

¿El state trie es lo mismo que el historial de transacciones?

No, el state trie almacena el estado actual de las cuentas, mientras que el historial de transacciones registra las transacciones ordenadas incluidas en bloques.

¿Qué es una prueba de Merkle?

Una prueba de Merkle es un conjunto de nodos de trie que puede demostrar que un valor específico está incluido en el estado comprometido por un hash raíz.

¿Qué es eth_getProof?

eth_getProof es un método JSON-RPC de Ethereum que devuelve valores de cuentas y almacenamiento con datos de pruebas de Merkle.

¿Por qué importan los nodos de archivo para el state trie?

Los nodos de archivo importan porque almacenan estados históricos y pueden responder a consultas de estado antiguas más rápidamente que los nodos completos normales.

¿Ethereum utilizará siempre el state trie actual?

Ethereum utiliza actualmente Merkle Patricia Tries en su capa de ejecución, pero la investigación de Ethereum ha explorado los árboles de Verkle como futura estructura de compromiso de estado.

Conclusión

Un state trie es una de las estructuras de datos fundamentales de las blockchains de contratos inteligentes basadas en cuentas.

Almacena el estado actual de las cuentas y permite a los clientes resumir ese estado mediante una única raíz criptográfica.

En Ethereum, el state trie global asigna direcciones de cuentas con hash a objetos de cuenta que contienen nonce, balance, storageRoot y codeHash.

Después, cada contrato puede tener su propio storage trie, cuya raíz se almacena dentro del objeto de cuenta del contrato.

La state root de cada cabecera de bloque representa un compromiso con todo el estado resultante después de procesar todas las transacciones de ese bloque.

Esto hace que el state trie sea esencial para el consenso, la verificación, los clientes ligeros, las pruebas, la sincronización de nodos, la ejecución de contratos inteligentes y la integridad de los datos blockchain.

Los state tries también plantean desafíos porque el crecimiento del estado activo aumenta el almacenamiento de nodos, el tamaño de las pruebas, la complejidad de sincronización y los costes de datos históricos.

Estos desafíos explican por qué los nodos de archivo, la poda de estado, los costes de gas, el diseño de almacenamiento, eth_getProof y la investigación sobre árboles de Verkle están conectados con el mismo tema.

Para los usuarios, el state trie se oculta en gran medida detrás de wallets, exploradores y dApps.

Para desarrolladores y equipos de infraestructura, el state trie es un concepto crítico para comprender los saldos, el almacenamiento de contratos, las pruebas, las consultas históricas y los límites de escalabilidad.

En el contexto del glosario cripto, State Trie significa la base de datos de estado blockchain autenticada que registra el estado actual de las cuentas y produce la state root utilizada para verificar ese estado.

La idea clave es que el state trie convierte un estado blockchain masivo y en constante cambio en una estructura verificable en la que nodos, aplicaciones y usuarios pueden confiar mediante raíces y pruebas criptográficas.