26 / 736MRKL

Merkle Tree

árbol de Merkle

Una forma de resumir transacciones en una huella y comprobar la inclusión de un pago sin descargar todo el bloque.

Un Merkle Tree combina paso a paso huellas criptográficas de datos hasta obtener un único resultado. En Bitcoin produce el Merkle root guardado en la cabecera del bloque. Unas pocas huellas adicionales permiten comprobar que una transacción corresponde a esa raíz sin transmitir todas las demás.

La cartera indica que un pago se incluyó en un bloque. ¿Cómo comprobarlo sin descargar todo su contenido? Aquí ayuda el Merkle Tree. Primero se representan las transacciones mediante hashes, breves huellas criptográficas. Se combinan progresivamente hasta obtener una huella común, la raíz. La cabecera contiene este Merkle root y vincula así el bloque con sus transacciones. La raíz no es un archivo del que se puedan reconstruir todos los pagos: sirve para verificar datos presentados. [1] [2]

Imagine cuatro transacciones A, B, C y D. Tomamos sus huellas, unimos A con B y calculamos un nuevo hash AB. Hacemos lo mismo con C y D para obtener CD. Por último combinamos las huellas AB y CD y calculamos la raíz. Las letras solo nombran transacciones y resultados intermedios; no son hashes reales. El proceso parece un árbol invertido: muchas hojas confluyen por ramas hasta una raíz. Más transacciones añaden niveles, pero el principio sigue siendo el mismo. [3]

Para verificar B, tiene sus datos y calcula su huella. Solo necesita la huella de A y la huella conjunta CD, con su orden correcto. Forma AB a partir de A y B; después calcula la raíz con AB y CD y la compara con la de la cabecera. Este camino complementario se llama Merkle proof. No necesita el contenido de A, C ni D. En un árbol equilibrado de 1024 transacciones, el camino tiene 10 hashes hermanos. Por tanto, la prueba crece mucho más despacio que la lista completa de transacciones. [2] [3]

Que la prueba coincida con la raíz no permite confiar ciegamente en la cabecera recibida. También hay que verificar su Proof of Work: ¿el resultado del cálculo de minería cumple la dificultad exigida? Además, la cabecera debe estar conectada con la cadena correspondiente. Incluso así, un Merkle proof no comprueba todas las firmas y reglas de todas las transacciones del bloque. Eso lo hace un Full Node. La verificación simplificada de pagos SPV, descrita en el whitepaper, tiene por ello supuestos de seguridad distintos de la validación completa. Además, una reorganización puede sacar el bloque de la rama activa: su contenido sigue siendo demostrable, pero la posición del pago en la historia actual puede cambiar. [2]

En el árbol ordinario de Bitcoin, las hojas son los identificadores txid en el orden de las transacciones del bloque, comenzando por la Coinbase Transaction, la transacción especial con la que el minero reclama la recompensa del bloque. Los pares se unen como bytes y se procesan dos veces con SHA-256. Si un nivel termina con un hash sin pareja, se duplica para ese cálculo; no se crea otro pago. Si solo hay una transacción, su txid es directamente la raíz. Esta duplicación exige comprobar cuidadosamente los duplicados en la implementación. La mejora del protocolo SegWit separa además los datos witness, como las firmas. Otra huella criptográfica, guardada en la Coinbase Transaction, vincula estos datos con el bloque. Esta huella se llama witness commitment. El árbol txid ordinario no debe confundirse con el árbol witness. [3] [4]

Para obtener la imagen más completa, lee esta entrada junto con Block, Transacción, Block Header. También enlazan con esta entrada Block Header, Hash, SHA-256, Confirmación.

DOC · 001Bitcoin Developer Guide — Merkle TreesDocumentación DOC · 002Bitcoin whitepaper — Simplified Payment VerificationFuente primaria DOC · 003Bitcoin Core — Merkle tree implementationFuente primaria DOC · 004BIP141: witness commitmentFuente primaria
Revisado: Fuentes primero · No es asesoramiento financiero