Ralph C. Merkle es un criptógrafo cuyo trabajo contribuyó a los fundamentos de la criptografía moderna. Los rompecabezas de Merkle permiten compartir un secreto por una conexión intervenida; un Merkle Tree demuestra que un elemento pertenece a una lista sin descargarla entera. Son tareas distintas y ninguna determina por sí sola la validez de las transacciones de Bitcoin.
Quieres enviar un mensaje cifrado. El destinatario necesita una clave secreta para leerlo, pero ¿cómo entregársela si alguien observa toda la comunicación? En su artículo de 1978, Ralph Merkle describió un procedimiento sorprendente: el emisor prepara muchos rompecabezas cifrados; el receptor resuelve uno elegido al azar y devuelve públicamente el identificador oculto en su interior. Ambos conocen entonces una clave compartida. El espía también ve el identificador, pero no sabe qué rompecabezas lo contenía. En el modelo descrito, su trabajo crece de forma cuadrática con el tamaño del problema, mientras que el de los participantes crece linealmente. La diferencia es cuadrática, no exponencial. Este avance histórico no es una recomendación actual para cifrar mensajes. [1]
En el artículo de 1978 importa qué puede hacer el adversario. Puede escuchar, pero se sigue suponiendo que las alteraciones y falsificaciones son detectables. Imagina a alguien que lee cartas y a alguien que además las reescribe y firma con tu nombre. El segundo caso necesita otra protección: comprobar con quién estás hablando realmente. Una diferencia de trabajo computacional no resuelve esa cuestión. Los rompecabezas no garantizan, por tanto, la seguridad de cualquier comunicación a través de un intermediario activo. Muestran que es posible ponerse de acuerdo sin una clave secreta compartida previamente, bajo los supuestos indicados. [1]
El Merkle Tree aborda otro problema. Este árbol de autenticación aparece en la tesis de Merkle de 1979. Imagina un archivo de contratos: quieres verificar uno concreto sin descargar todo el archivo. De cada elemento se calcula un hash, una breve huella digital. Las huellas se combinan por parejas y se vuelven a procesar con hash hasta obtener una raíz común. El hash no cifra el contenido; permite comprobar coincidencias. Para que la comprobación tenga sentido, necesitas una raíz autenticada previamente: una huella verificada del archivo correcto. Si un estafador puede proporcionar tanto su documento como una raíz arbitraria, que coincidan no demuestra nada sobre el archivo original. [2]
Tomemos un árbol binario equilibrado con 8 elementos. Para verificar una hoja elegida hacen falta 3 hashes hermanos: una huella de la rama vecina en cada nivel. Partiendo de tu hoja y de esas huellas, calculas la raíz y la comparas con la raíz autenticada. La propia hoja y la raíz no cuentan entre esos hashes auxiliares. También hay que conocer la estructura y el orden de combinación: si cada vecino va a la izquierda o a la derecha. El ahorro no es un truco con datos ocultos. Las partes lejanas del archivo están representadas por sus huellas, por lo que sus documentos completos no hacen falta para esta comprobación. [2]
Un Merkle Tree acredita la relación entre un elemento y un conjunto de datos concreto. No convierte en verdadera una afirmación incorrecta. Nuestro archivo podría contener un contrato con un nombre equivocado; una prueba podría confirmar correctamente su inclusión sin detectar el error. Del mismo modo, una huella no acredita que el autor estuviera autorizado a crear el documento. Conviene separar las preguntas: ¿corresponde este elemento a esta raíz?, ¿de dónde conozco la raíz?, ¿con qué reglas acepto el contenido? Esta distinción explica qué puede hacer la misma técnica en Bitcoin y qué deben aportar otras partes del sistema. [2]
Bitcoin utiliza un Merkle Tree para vincular las transacciones con la cabecera del bloque, su registro compacto. La raíz forma parte de la cabecera; modificar las transacciones incluidas afecta a su huella conjunta. Satoshi Nakamoto describe la construcción en la sección 7 del whitepaper y cita el trabajo de Merkle. Eso documenta una influencia técnica, no la autoría de Bitcoin. El árbol no selecciona un historial válido ni verifica las firmas de las transacciones en lugar de los nodos. Bitcoin lo combina con otras reglas, como la verificación de transacciones y Proof of Work, una prueba de esfuerzo computacional. Entender un componente es más útil que atribuirle las capacidades de todo el sistema. [3]
La sección 8 del whitepaper describe SPV, la verificación simplificada de pagos. Un cliente ligero utiliza cabeceras de bloques y una rama que vincula una transacción con un bloque elegido. Ahorra datos, pero depende de supuestos sobre la cadena con mayor trabajo acumulado y el comportamiento de los mineros. La prueba de inclusión por sí sola no comprueba todas las reglas de las transacciones como lo hace un Full Node, un nodo que las valida íntegramente. Tampoco indica si una salida se gastó después: para ello hay que conocer lo ocurrido posteriormente. Para empezar, lo esencial es no confundir «este pago está en este bloque» con una comprobación completa de los fondos disponibles ahora. [3]
La tesis de 1979 utiliza además un árbol de autenticación para un conjunto finito de firmas digitales de un solo uso. Una firma digital permite comprobar que el titular de una clave secreta aprobó un mensaje; no es una imagen de una firma manuscrita. El árbol puede vincular muchos valores de verificación con una raíz conocida. Sin embargo, en esa construcción la cantidad de firmas es limitada y la raíz debe renovarse con el tiempo. No permite reutilizar indefinidamente la misma clave de un solo uso. Esta parte más avanzada del trabajo de Merkle ilustra una idea recurrente: verificar lo necesario con una prueba pequeña, teniendo claras las condiciones de las que depende. [2]
Para obtener la imagen más completa, lee esta entrada junto con David Chaum, Timothy May, Merkle Tree, Block Header. También enlazan con esta entrada David Chaum, Timothy May.