---
title: "Árbol de Merkle"
description: "Un árbol de Merkle compromete datos ordenados con un único hash raíz y permite pruebas compactas de inclusión sin transferir todo el conjunto."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Árbol de Merkle
> Solo con fines educativos; no es asesoramiento de inversión. Invertir puede causar pérdidas.
## Respuesta directa
Un árbol de Merkle convierte cada dato en una hoja mediante un hash, combina repetidamente los hashes vecinos y produce una raíz de Merkle. La raíz es un compromiso compacto de las hojas y de las reglas de ordenación y hash usadas para construir el árbol.
Una prueba de Merkle contiene el hash hermano de cada nivel para una hoja. El verificador recalcula el camino hasta la raíz y acepta la inclusión solo si coincide con una raíz confiable. No necesita las demás hojas ni el conjunto completo.
El compromiso describe la representación de los datos, no su verdad. Una raíz coincidente no demuestra que el origen sea correcto, que los datos sigan disponibles ni que un contrato, puente, oráculo o mercado sea seguro. El verificador debe obtener la raíz y la hoja mediante un protocolo autenticado y entender la separación de dominios, el orden y las reglas para hojas impares.
Los árboles de Merkle aparecen en distintos diseños. Bitcoin coloca la raíz de las transacciones del bloque en cada encabezado; Ethereum usa un Trie de Merkle-Patricia modificado para el estado y otras estructuras autenticadas. Comparten la idea de construcción, pero difieren en codificación, formato de prueba, actualizaciones y supuestos de seguridad.
## Cómo funciona
El sistema define una codificación determinista de hojas y una función hash. Luego hashea cada hoja, hashea pares de hijos para crear padres y repite hasta dejar una raíz. La prueba debe incluir la posición o dirección de la hoja cuando el protocolo no permite inferirla.
En un árbol binario equilibrado, una prueba para una de 1024 hojas necesita unos 10 hashes hermanos porque cada nivel duplica el rango cubierto. El tamaño exacto depende de la forma del árbol, la longitud del hash, la política de hojas duplicadas y el uso de pruebas múltiples o comprimidas.
La relación central puede escribirse como `parent = Hash(left || right)` y `root = fold(parent, leaves)`. Es una notación esquemática: los protocolos pueden anteponer prefijos, usar otra aridad o codificar claves en un trie. La prueba demuestra coherencia con la construcción indicada, pero no autentica una raíz que el verificador no haya confiado de forma independiente.
En una cadena de bloques, la raíz queda comprometida por un encabezado, un registro de estado o un contrato. Un cliente ligero puede pedir una hoja y su ruta, recalcular la raíz y aplicar las reglas de confirmación, finalidad, frescura y disponibilidad. Verificar hashes no sustituye esas reglas.
## Ejemplo
Supón un bloque con 1024 transacciones y un árbol binario. Una transacción puede llevar unos 10 hashes hermanos en vez de transmitir las otras 1023 transacciones. El verificador aún necesita el encabezado correspondiente y la regla de codificación y posición.
Si falla una prueba, revisa los bytes de la hoja, el orden de bytes, el relleno, el origen de la raíz y el estado del bloque antes de concluir que falta la transacción. Una prueba válida para una raíz sin finalidad o antigua puede ser técnicamente correcta y ya no representar el estado canónico.
En una aplicación que muestra saldo o recompensa, separa la validez de la prueba del resultado económico. Las comisiones, cambios de precio, deslizamiento, permisos del contrato, límites de retiro o una fuente no disponible aún pueden afectar el importe. La prueba verifica pertenencia a un compromiso, no un importe canjeable.
## Riesgos
Los riesgos técnicos principales son codificaciones ambiguas, uso incorrecto del hash, debilidades de segunda preimagen o colisión, orden incorrecto de hermanos y aceptar una raíz no confiable o antigua. La separación de dominios entre hojas y nodos internos evita ambigüedades estructurales si se implementa de forma coherente.
Los riesgos operativos están fuera del cálculo hash. Un puente, oráculo, secuenciador, exchange o administrador puede publicar, retrasar, censurar o sustituir la raíz; una falla de disponibilidad puede impedir obtener la hoja o la prueba; y una reorganización puede invalidar una prueba ligada a un bloque anterior.
Antes de confiar en una prueba, identifica quién autentica la raíz, cómo se comprueban frescura y finalidad, cómo se tratan hojas ausentes o impares y si los usuarios pueden recuperar sus datos. Limita autorización y exposición cuando no pueda acotarse la pérdida por una raíz errónea, un firmante comprometido, datos no disponibles o una actualización.
## Errores comunes
### Mito 1: Una raíz coincidente prueba que los datos son verdaderos
Solo prueba que la hoja suministrada es coherente con la raíz comprometida bajo esa construcción. Si un oráculo o operador comprometió un valor incorrecto, la prueba verificará fielmente el valor equivocado.
### Mito 2: Una prueba de Merkle vuelve confiable todo el sistema
El verificador aún confía en el hash, las reglas de codificación, la ruta de autenticación de la raíz y el sistema que entrega los datos. Consenso, finalidad, disponibilidad y gobernanza siguen siendo preguntas distintas.
### Mito 3: Todas las cadenas usan el mismo árbol de Merkle
Los árboles de transacciones de Bitcoin, el Trie de Merkle-Patricia de Ethereum y los árboles de aplicaciones tienen diseños y reglas de prueba diferentes. Un formato no se puede trasladar automáticamente a otro protocolo.
### Mito 4: Una prueba corta garantiza una transacción barata y segura
El tamaño reduce la transferencia, pero el gas de verificación, las lecturas, la congestión, los errores del contrato y los riesgos de retiro o liquidación aún pueden dominar el resultado.
## Temas relacionados
- [Blockchain](/es/crypto/blockchain/)
- [Hash criptográfico](/es/crypto/cryptographic-hash/)
- [Cliente ligero](/es/crypto/light-client/)
- [Ethereum](/es/crypto/ethereum/)
- [Disponibilidad de datos](/es/crypto/data-availability/)
## Fuentes
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulta: 2026-08-21)
- [Merkle Trees](https://developer.bitcoin.org/devguide/block_chain.html#merkle-trees) - Bitcoin.org (consulta: 2026-08-21)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation (consulta: 2026-08-21)
Source: https://wiki.fcontext.com/es/crypto/merkle-tree/index.mdx