Prueba de reservas con raíces de Merkle

Una raíz de Merkle puede facilitar mucho la verificación de una instantánea de prueba de reservas, pero por sí sola no demuestra la solvencia. Demuestra que un conjunto concreto de entradas quedó comprometido en un momento concreto. Si esas entradas suman un negocio solvente es otra cuestión.

El patrón es este. Un exchange, un custodio, una fintech, un marketplace, un emisor de stablecoins o un equipo de tesorería interno construye un árbol de Merkle sobre una instantánea de reservas o pasivos y luego ancla la única raíz de 32 bytes con un registro Label 309 en Cardano. Cada cliente, cartera o línea de saldo es una hoja. Más tarde, a cualquier participante se le puede entregar una prueba de inclusión breve que demuestra que su entrada formaba parte de la instantánea comprometida, sin que el conjunto de datos completo se publique nunca.

El sello de tiempo cumple una función precisa: fija cuándo existió ese compromiso, en una cadena pública y sin ningún servidor del emisor en el que confiar. La calidad de la instantánea en sí sigue dependiendo de la contabilidad, el alcance, la cobertura de pasivos, los controles de custodia y la revisión independiente.

¿Qué es una instantánea de prueba de reservas?

Una instantánea de prueba de reservas es material probatorio sobre los activos en un instante concreto.

Para las empresas cripto-nativas, suele significar demostrar que ciertas carteras en la cadena contenían ciertos activos a una altura de bloque o en un momento determinado. En un proceso más sólido, también conecta esos activos con los pasivos de los clientes, los libros contables internos, los controles de custodia y la revisión independiente.

Una instantánea puede incluir:

los saldos de las carteras de reserva;
los identificadores de los activos;
las alturas de bloque;
los saldos de los pasivos;
los compromisos de las cuentas de clientes;
las exclusiones y los ajustes;
los informes de auditoría;
el material de control;
los archivos de conciliación;
las declaraciones de la dirección.

La instantánea no es un balance vivo. Es un compromiso en un instante concreto.

¿Por qué usar una raíz de Merkle?

Porque la instantánea completa suele ser demasiado grande o demasiado sensible para publicarla.

Un árbol de Merkle permite a una empresa comprometerse con muchas entradas mediante una sola raíz de 32 bytes. Cada cliente, cuenta, cartera o línea de saldo se convierte en una hoja, las hojas se combinan mediante hash en un árbol y solo la raíz va a la cadena. La raíz no revela nada sobre las hojas con las que se compromete, y sin embargo queda ligada a todas ellas: cambia cualquier hoja, o el número de hojas, y la raíz deja de coincidir. Más tarde, un participante recibe una prueba de inclusión —una breve ruta de hermanos, del orden de log n hashes— que demuestra que su entrada formaba parte de la instantánea comprometida.

Eso es lo que hace posible la divulgación selectiva:

un solo cliente puede verificar únicamente su propia inclusión;
a un auditor se le puede entregar la lista de hojas completa y la correspondencia de cuentas;
el público solo ve la raíz con sello de tiempo;
los detalles sensibles de las cuentas nunca tienen que quedar expuestos.

Este es el mismo mecanismo de agrupación que hay detrás de anclar un registro para miles de archivos: la raíz es compacta, pero lo que de verdad importa es el proceso subyacente.

¿Qué aporta Label 309?

Aporta un sello de tiempo público e independiente que no controla ninguna parte en solitario.

Un informe de prueba de reservas suele vivir en una web o en un PDF, y la raíz de Merkle en una entrada de blog. Pero una web puede cambiar. Un PDF se puede sustituir. Un informe se puede actualizar en silencio, y con él puede desaparecer una raíz antigua.

Publicar la raíz de la instantánea en un registro Label 309 le da al compromiso, en cambio, un anclaje temporal público en Cardano. Cualquiera puede confirmar después que esa misma raíz existía antes del tiempo de bloque de la transacción, usando solo los metadatos de la transacción y un explorador público de Cardano, sin ningún servidor del emisor y sin confiar en el dominio ni en la infraestructura de CardanoWall.

El registro también puede incluir:

el hash de una declaración firmada;
los hashes de instantáneas de activos;
las raíces de instantáneas de pasivos;
las URI de los informes direccionadas por contenido;
los papeles de trabajo de auditoría sellados para destinatarios concretos;
un puntero de sustitución para informes corregidos.

¿Qué debe contener la instantánea?

Define la afirmación antes de construir el árbol.

La instantánea debe dejar claro qué está demostrando. Una instantánea de solo reservas no es lo mismo que una instantánea de reservas y pasivos. Una instantánea de solo carteras no es lo mismo que unos estados financieros auditados.

Entre los campos útiles puede haber:

el identificador de la instantánea;
el momento de la instantánea;
la cadena y el identificador del activo;
la altura de bloque o la referencia al libro contable;
la dirección de la cartera o el identificador de la cuenta interna;
el saldo;
el hash de la entrada de pasivo;
el hash del identificador del cliente o un identificador anonimizado;
el hash de la hoja de inclusión;
la referencia del auditor o revisor;
el hash del informe;
la declaración de alcance;
las exclusiones;
el índice de la hoja de Merkle.

El esquema debe ser determinista. Si la construcción de las hojas es ambigua, la verificación se vuelve frágil.

¿Cómo pueden los clientes verificar la inclusión?

La empresa entrega a cada cliente un paquete de prueba.

Ese paquete puede incluir:

la propia entrada de saldo del cliente;
el salt o el material de anonimización, si se usa;
la ruta de Merkle;
la raíz;
la referencia de transacción de Label 309;
el hash del informe;
las instrucciones de verificación.

El cliente verifica que su entrada produce, mediante hash, la hoja correspondiente; que la ruta de Merkle se pliega hasta la raíz publicada; y que esa raíz coincide con la que figura en el registro Label 309 en la cadena. Nada de esto requiere que los servidores de la empresa estén en línea ni sean honestos: las herramientas de Label 309 de código abierto, incluida la herramienta de línea de comandos cardanowall, pueden verificar un registro y comprobar pruebas de inclusión de forma independiente.

Esto demuestra la inclusión en esa instantánea. No demuestra que todas las demás cuentas se hayan tratado correctamente, que es justamente por lo que importa la perspectiva del auditor que viene a continuación.

¿Cómo pueden aprovechar esto los auditores?

Los auditores pueden inspeccionar el conjunto de pruebas completo.

Puede que el público solo vea la raíz y un informe. A un auditor o a un regulador se le puede entregar el manifiesto completo, la lista de hojas, la correspondencia de cuentas, las pruebas de las carteras, los archivos de conciliación y los papeles de trabajo sellados.

Label 309 puede ayudar anclando:

la raíz pública;
el hash del manifiesto privado completo;
las pruebas de saldo de las carteras;
los archivos de pasivos;
las exportaciones de conciliación;
los borradores del informe de auditoría;
el informe final firmado.

Eso hace más difícil reescribir el rastro de auditoría a posteriori.

¿Y las correcciones?

Las correcciones deben ser visibles, no ocultarse.

Si la empresa descubre un error en una instantánea, debe publicar un registro corregido en lugar de sustituir el informe antiguo en silencio. Label 309 tiene un mecanismo integrado para esto: un puntero supersedes lleva el hash de transacción del registro anterior y crea un vínculo de solo anexado desde la corrección hacia aquello que reemplaza.

Conviene entender dos cosas sobre ese vínculo. Primero, la sustitución no elimina ni invalida el registro anterior: la cadena solo añade (append-only), así que la raíz original permanece en la cadena y se puede verificar de forma independiente para siempre. El nuevo registro se sitúa junto a ella y apunta hacia atrás; quien lee puede ver ambos. Segundo, para que el vínculo sea fiable, los dos registros deben estar firmados con la misma clave. Cualquiera puede publicar un registro que afirme sustituir al tuyo, así que se espera que los verificadores y las herramientas respeten un vínculo de sustitución solo cuando el registro que sustituye está firmado con una clave que también esté presente en el original. Si tienes intención de emitir correcciones, firma tus instantáneas.

Eso es mucho mejor que fingir que la primera raíz no existió nunca.

¿Qué no demuestra esto?

Por sí solo no demuestra la solvencia.

No demuestra que se incluyeran todos los pasivos.

No demuestra que los activos estén libres de cargas.

No demuestra que las claves se controlen de forma segura.

No demuestra que los activos no se tomaran prestados temporalmente para la instantánea.

No sustituye a una auditoría, a la revisión de un regulador, a los controles contables ni a la conciliación de los pasivos con los clientes.

Lo que sí demuestra es algo concreto y genuinamente útil: que un compromiso específico existió en un momento público, y que se puede probar que entradas individuales están dentro de él. Como ocurre con cualquier prueba de existencia, es prueba de cronología e integridad, no de verdad ni de derechos.

¿Dónde puede ser útil esto fuera de los exchanges cripto?

El mismo patrón funciona en cualquier sitio donde una instantánea tenga muchas entradas privadas.

Ejemplos:

las reservas de stablecoins;
los informes de activos tokenizados;
los saldos de los vendedores de un marketplace;
los saldos de custodia de una fintech;
las instantáneas de tesorería interna;
los libros de equity de empleados;
los pasivos por puntos de fidelidad;
los inventarios de créditos de carbono;
las reservas para siniestros de seguros;
los libros de depósitos de clientes.

La idea compartida es sencilla: comprometerse con muchas entradas, revelar de forma selectiva y conservar el sello de tiempo.

La versión corta

Las raíces de Merkle hacen que las instantáneas de prueba de reservas sean escalables. Label 309 hace que la raíz tenga sello de tiempo y sea verificable de forma independiente contra una cadena pública.

Usa la raíz para comprometerte con la instantánea. Usa pruebas de inclusión para clientes y auditores. Usa registros sellados para las pruebas sensibles. Usa la sustitución —con firmas— para las correcciones.

Y luego sé honesto sobre el límite: una raíz de Merkle con sello de tiempo no es solvencia. Es una pieza fuerte y con evidencia de manipulación dentro de un proceso de prueba más amplio. El propio Label 309 es un estándar abierto y neutral respecto al proveedor, presentado al proceso CIP de Cardano y actualmente en revisión por los editores de CIP como propuesta de la categoría Metadata; los mecanismos de agrupación, hash y sustitución descritos arriba están definidos en el estándar, no en ningún producto concreto.

Más lecturas

El estándar y la especificación de Label 309: el formato de transmisión de los registros, los compromisos de Merkle, las firmas y la sustitución.
Código abierto, SDK y el CLI cardanowall: verifica registros y pruebas de inclusión sin confiar en ningún servidor concreto.
La propuesta CIP de Label 309: la presentación cuya revisión avanza en el proceso CIP de Cardano.
Un registro para miles de archivos: el mecanismo de agrupación con más detalle.
Registros de cumplimiento sin confiar en el proveedor: el mismo patrón de comprometer y anclar aplicado a los registros de auditoría y de eventos.
Qué demuestra —y qué no demuestra— una prueba.