Árboles de Merkle en la prueba de reservas: cómo un hash bloquea millones de saldos

Un árbol de Merkle permite a un exchange publicar un único valor corto que lo compromete de una vez con cada saldo de usuario. Cada usuario se convierte en una hoja, las hojas se hashean por pares hacia arriba hasta que queda una raíz, y cualquier cambio en cualquier punto por debajo produce una raíz completamente distinta. Por eso una raíz publicada es un compromiso y no una promesa, y por eso puedes probar tu inclusión sin ver los datos de nadie más.

Qué problema resuelve un árbol de Merkle

Un exchange quiere decir algo sobre millones de saldos sin publicarlos. Publicar la lista expondría a cada cliente; publicar un total no prueba nada, porque un total puede armarse con cualquier conjunto de números.

Hace falta un valor lo bastante corto para publicarlo, derivado de cada saldo e imposible de conciliar con otro conjunto de saldos. Entonces el exchange se compromete públicamente con el conjunto entero y cada usuario verifica por separado que su fila formó parte de aquello con lo que se comprometió.

Esa es justamente la tarea de un árbol de Merkle, y explica por qué se usa esta estructura y no un simple hash de una lista concatenada. Un hash plano también cambiaría si cambian los datos, pero te obligaría a tener cada saldo para comprobarlo, lo cual destruye el requisito de privacidad.

Las partes, con nombre

Lee dos veces la segunda fila. Una hoja es el hash de una cadena concreta, y si la cadena se construye de otro modo el hash es otro: por eso la versión del algoritmo debe publicarse junto con la raíz.

Cómo se construye una hoja

Una hoja es el hash de un texto corto que describe una cuenta en el momento de la instantánea. Ese texto nombra la versión del algoritmo, el identificador de la divulgación a la que pertenece, un identificador de registro para la cuenta y los saldos en los activos cubiertos.

Dos reglas de formato hacen más trabajo del que parece. Los saldos se escriben con un número fijo de decimales, de modo que la misma cantidad siempre produce el mismo texto, y los activos aparecen en un orden fijo en lugar del que un sistema emitiera por casualidad. Sin cualquiera de las dos, dos implementaciones hashearían la misma cuenta de forma distinta y la verificación independiente fallaría por razones ajenas a la honestidad.

La cuenta se identifica mediante un identificador de registro y no mediante nada sobre ti. Eso es lo que permite publicar la estructura del árbol sin informar sobre quién está dentro. Los campos publicados alrededor se tratan en cómo leer un informe de prueba de reservas.

Cómo crece el árbol hacia arriba

Las hojas se combinan por pares. Dos hashes se unen en una cadena y esa cadena se hashea, produciendo un nodo un nivel más arriba; esos nodos se emparejan igual y el proceso se repite hasta que queda un único valor.

El orden importa en cada unión, y ese es el detalle que hace tropezar a quien implementa un verificador. Cada paso tiene un lado izquierdo y uno derecho, y hashearlos en el orden equivocado da otro resultado. Por eso un archivo de prueba registra no solo qué hash hermano usar en cada nivel, sino de qué lado está, y tu verificador debe respetar esa instrucción en vez de ordenar los dos valores.

Como el árbol se reduce a la mitad en cada nivel, el camino desde cualquier hoja hasta la raíz es corto. Un conjunto de millones de cuentas produce una prueba de unas pocas decenas de hashes, y por eso esta comprobación corre al instante en un teléfono sin descargar el conjunto entero.

Por qué la manipulación se detecta

Las funciones hash tienen la propiedad de que un cambio pequeño en la entrada produce una salida sin relación. Cambia un saldo en la menor cantidad representable y su hash de hoja cambia por completo, cambia su nodo padre, y con él cada nodo del camino hasta la raíz.

Eso es lo que convierte la publicación en compromiso. Una vez pública la raíz, el exchange no puede revisar un saldo, insertar una cuenta ni eliminar una sin producir una raíz distinta. No puede hacerlo en silencio ni hacerlo para un usuario sin romper la verificación de todos aquellos cuyo camino pasa por la misma rama.

El compromiso solo obliga si la raíz se publicó antes de que a alguien le conviniera que estuviera mal, por lo que el momento y el registro público de la raíz pesan tanto como las matemáticas. Cómo hacer la comparación tú mismo está en cómo verificar la prueba de reservas.

Por qué tus vecinos siguen siendo privados

Tu camino de prueba contiene hashes de otras partes del árbol, y un hash no es reversible a los datos de los que salió. Sabes que existe un hermano y cuál es su hash; no sabes de quién son los saldos que hay debajo ni cuánto valen.

Esa asimetría es justamente lo que hace que la estructura encaje con el problema. Cada usuario confirma su propia inclusión y ninguno aprende nada de otro, sin que el exchange tenga que confiar en nadie ni publicar una lista de clientes.

Las implementaciones suelen reforzarlo aún más ejecutando la comprobación en local en lugar de devolver tus datos a un servidor. Aquí el argumento de privacidad y el de verificabilidad apuntan en la misma dirección, algo poco común y digno de notarse.

Dónde la estructura deja de ayudar

Un árbol de Merkle demuestra pertenencia a un conjunto. Dice que tu fila estaba en el árbol cuya raíz se publicó, y no dice absolutamente nada sobre si ese conjunto era el conjunto correcto.

De ahí se siguen tres límites. El árbol no puede decirte si se incluyeron todas las cuentas, porque una cuenta omitida no deja rastro para quienes quedan. No puede decirte si los activos existen, que es una afirmación en cadena aparte y no una propiedad de la estructura. Y no dice nada de los pasivos más allá de los saldos que entraron, que es de lo que trata prueba de reservas y pasivos.

Nada de eso es un defecto de la criptografía. Es el límite de lo que puede pedirse a una prueba de pertenencia, y conocer el límite es lo que evita que la estructura se venda por más de lo que vale.

En resumen

Un árbol de Merkle convierte millones de saldos en un valor publicable y da a cada usuario un camino corto que prueba que su fila está debajo. Las hojas son hashes de registros de formato fijo, los nodos son hashes de pares, y el orden de concatenación en cada nivel es parte de la especificación, no un detalle.

Su fuerza es que la manipulación posterior a la publicación no puede ocultarse y que la inclusión puede probarse sin exponer a nadie. Su límite es que solo prueba pertenencia: si el conjunto estaba completo, si los activos existen y cuánto suman los pasivos quedan fuera del árbol. Sigue leyendo más contenidos de Bitbase Academy.

Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.

Fuentes

[1] Bitbase, Prueba de reservas: divulgación mensual, raíz de Merkle y verificador de código abierto www.bitbase.com