Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
Respuesta directa
Una raíz de estado es un compromiso criptográfico de 32 bytes incluido en la cabecera de un bloque de Ethereum y referido al estado global después de procesar ese bloque. El estado global asigna direcciones a cuentas. Cada cuenta compromete su nonce, saldo, raíz de almacenamiento y hash de código; la raíz de almacenamiento de cada contrato compromete a su vez las ranuras de almacenamiento de esa cuenta.
La raíz es un resumen, no una instantánea descargable. Permite a los nodos comparar resultados calculados de forma independiente y a un verificador comprobar una prueba de cuenta o almacenamiento frente a un bloque de confianza. Por sí sola no permite reconstruir el estado, demostrar la disponibilidad de los datos, establecer la finalidad del bloque ni acreditar la seguridad económica de un contrato.
“Raíz de estado” depende del protocolo. Ethereum compromete actualmente el estado de su capa de ejecución mediante un trie de Merkle-Patricia modificado. Otras redes pueden usar modelos de estado, codificaciones, funciones hash o estructuras autenticadas diferentes; compartir el término no hace intercambiables sus raíces ni sus pruebas.
Cómo funciona
Un cliente de ejecución parte del estado del bloque padre, valida y ejecuta el bloque nuevo según las reglas vigentes del protocolo y aplica los cambios de cuentas y almacenamiento resultantes. De forma esquemática:
S_n = Υ(S_(n-1), B_n)
Aquí, S_(n-1) es el estado padre, B_n es todo el procesamiento definido por el protocolo para el bloque nuevo y S_n es el estado resultante. El cliente codifica ese estado de forma determinista en el trie de estado y calcula su hash raíz. Una cabecera válida debe contener el mismo resultado; si no coincide, el cliente considera inválido el bloque.
En el trie de estado de Ethereum, la ruta de una cuenta deriva de su dirección y la cuenta codificada contiene nonce, saldo, raíz de almacenamiento y hash de código. El código del contrato se referencia mediante su hash y cada contrato tiene un trie de almacenamiento separado. Este anidamiento hace que una ranura modificada pueda cambiar la raíz de almacenamiento del contrato, luego la cuenta codificada y finalmente la raíz de estado global.
La raíz de estado es distinta de las raíces de transacciones y recibos de la misma cabecera. La primera de estas compromete los datos ordenados de las transacciones y la segunda los recibos de ejecución. Ninguna sustituye a otra.
EIP-1186 define eth_getProof, que puede devolver una prueba de cuenta y las pruebas de almacenamiento solicitadas para un bloque concreto. El verificador aún necesita un hash de bloque o raíz de estado autenticados, las reglas correctas del trie y la codificación, y una política apropiada de confirmación o finalidad.
Ejemplo
Supongamos que una transacción transfiere ETH de Alice a Bob. La ejecución correcta puede cambiar el nonce y el saldo de Alice, el saldo de Bob y el del receptor de la comisión. Si la transacción llama a un contrato, también pueden cambiar ranuras y la raíz de almacenamiento del contrato. Estas actualizaciones producen una raíz de estado global nueva aunque la mayoría de las cuentas no se hayan tocado.
Dos clientes honestos que partan del mismo estado padre y procesen el mismo bloque válido con las mismas reglas deberían calcular la misma raíz. Si uno acredita una cantidad incorrecta o usa una codificación errónea del trie, su raíz diferirá de la cabecera y deberá rechazar el bloque en lugar de aceptar silenciosamente su estado local.
Para verificar el saldo de Bob sin descargar todo el estado global, se pueden obtener la cabecera y una prueba de cuenta. Recalcular la ruta de la prueba muestra si la cuenta codificada concuerda con la raíz de estado de esa cabecera. No demuestra que la cabecera elegida sea canónica o final; eso depende de las comprobaciones de cadena y finalidad del verificador.
Riesgos
- Raíz no fiable: Una prueba válida contra una raíz elegida por un atacante o desactualizada acredita el punto de referencia equivocado. Vincule la raíz a un hash de bloque, ID de cadena y número de bloque verificados.
- Reorganizaciones y finalidad: Una prueba puede ser correcta para un bloque que después abandona la cadena canónica. Ajuste la profundidad de confirmación o la finalidad a la tolerancia de pérdida de la aplicación.
- Errores de codificación: El hash de direcciones, RLP, las rutas de nibbles, los nodos incrustados y las claves de almacenamiento deben seguir exactamente el protocolo. Una biblioteca genérica de pruebas de Merkle binarias no basta.
- Datos ausentes: La raíz compromete el estado, pero no hace disponibles los nodos del trie, el estado histórico ni los servicios de generación de pruebas. Los nodos podados pueden no servir pruebas antiguas.
- Garantías exageradas: La coincidencia de raíces detecta una ejecución incoherente; no audita contratos, autentica oráculos, protege un endpoint RPC, garantiza el valor de un activo ni impide que claves comprometidas autoricen operaciones.
Errores comunes
- La raíz de estado guarda todos los saldos. Es un compromiso de tamaño fijo con un trie codificado; los datos subyacentes se obtienen por separado.
- Raíces iguales demuestran bases de datos idénticas. Comprometen el mismo estado global lógico bajo el protocolo, pero los clientes pueden almacenarlo, indexarlo, podarlo o almacenarlo en caché de manera distinta.
- Una raíz distinta identifica la transacción errónea. Revela desacuerdo en el estado final comprometido, no dónde comenzó la divergencia; hay que rastrear la ejecución para diagnosticarla.
- Una prueba de cuenta válida demuestra finalidad y seguridad. Solo demuestra coherencia con una raíz. La selección de cadena, finalidad, actualidad de los datos, conducta del contrato y riesgo económico son cuestiones separadas.
Temas relacionados
Fuentes
- Ethereum Execution Specifications: Block Header - Ethereum Foundation (consultado: 2026-08-21)
- Merkle Patricia Trie - Ethereum Foundation (consultado: 2026-08-21)
- EIP-1186: RPC-Method to get Merkle Proofs - Ethereum Improvement Proposals (consultado: 2026-08-21)