Un registro para miles de archivos: agrupación de Merkle

Un solo registro Label 309 puede probar que miles o millones de archivos existían en un momento dado.

En lugar de publicar una transacción de blockchain por archivo, calculas el hash de cada archivo, pliegas esos hashes en un árbol de Merkle y publicas una única raíz de Merkle de 32 bytes. Más tarde puedes probar que cualquier archivo formaba parte de ese lote con una pequeña prueba de inclusión, sin revelar el resto y sin poner cada elemento en la cadena.

Así es como la prueba de existencia escala de un único documento a un conjunto arbitrariamente grande.

¿Qué problema resuelve la agrupación de Merkle?

Las blockchains son malos lugares para guardar listas largas. Cada byte cuesta una comisión, y una transacción de Cardano tiene un techo de tamaño infranqueable.

Si un sistema genera un flujo constante de artefactos —registros, salidas de modelos, builds de release, facturas, informes, entradas de material probatorio—, publicar cada hash como su propio registro en cadena se vuelve caro y ruidoso muy rápido.

La agrupación de Merkle comprime una lista ordenada de hashes en un único compromiso raíz. La raíz tiene tamaño fijo (32 bytes), el lote puede ser ilimitado y la prueba de cualquier elemento concreto se mantiene pequeña: crece solo con el logaritmo del tamaño del lote. Eso hace que los compromisos periódicos resulten prácticos para flujos de gran volumen.

¿Qué es una raíz de Merkle?

Una raíz de Merkle es un único hash que se compromete con toda una lista ordenada.

Empiezas con una lista de hojas. En un flujo de prueba de existencia, cada hoja suele ser el hash de un archivo, de un evento o de una entrada de manifiesto. Las hojas se combinan por parejas subiendo un árbol binario, y el hash de la cima es la raíz de Merkle.

El compromiso es exacto en tres sentidos:

• si cambia cualquier hoja, cambia la raíz;
• si cambia el orden de las hojas, cambia la raíz;
• el compromiso también registra cuántas hojas hay, de modo que una lista de tamaño distinto no puede hacerse pasar por el mismo lote.

Publicar la raíz es como publicar una huella de toda la lista ordenada.

¿Qué va realmente a la cadena?

Solo la raíz. La lista completa de hojas se queda fuera de la cadena.

Un registro Label 309 lleva el compromiso en un campo merkle dedicado, separado de los hashes ordinarios por archivo. Cada compromiso es una estructura pequeña y fija:

• el algoritmo del compromiso (Label 309 v1 registra rfc9162-sha256: el Merkle Tree Hash de la RFC 9162 con SHA-256);
• la raíz de 32 bytes;
• el número de hojas, que vincula la raíz al tamaño de la lista fuera de la cadena;
• URIs opcionales direccionadas por contenido (ar:// o ipfs://) que apuntan al archivo con la lista de hojas.

El registro en cadena se mantiene minúsculo: una sola raíz se compromete con una lista ilimitada a un coste fijo de 32 bytes. El detalle vive fuera de la cadena, en la lista ordenada de hojas. (Para saber dónde vive el resto de un registro, consulta qué va a la blockchain.)

¿Cómo pruebas un archivo concreto más tarde?

Produces una prueba de inclusión.

Una prueba de inclusión es la breve lista de hashes hermanos a lo largo del camino que va de una hoja hasta la raíz. El verificador pliega la hoja y esos hermanos de nuevo hacia arriba en el árbol y acepta la prueba solo si la raíz recalculada coincide exactamente con la raíz publicada.

En la práctica, la comprobación tiene cuatro entradas:

1. el hash del archivo o elemento que estás probando;
2. la prueba de inclusión (el camino de hermanos);
3. la raíz de Merkle del registro Label 309;
4. el tiempo de bloque de Cardano de la transacción que la transportó.

Si el plegado reproduce la raíz publicada, el elemento estaba en la lista comprometida, y el tiempo de bloque atestigua cuándo existía esa lista. El verificador necesita ese único elemento y su prueba; nunca necesita los demás archivos del lote.

Dos detalles que conviene tener claros. La construcción es sensible al orden, así que las hojas deben mantenerse en la misma secuencia en que se publicaron. Y un «árbol» de una sola hoja no es un sello de tiempo útil: la raíz de un árbol de una hoja no es la hoja misma, así que para probar un único archivo publicas un hash de contenido simple, no un compromiso de Merkle de un solo elemento.

¿Por qué es una ventaja que construir y verificar sea totalmente offline?

Porque el único paso que toca un servidor es publicar la raíz.

Construir el árbol, derivar pruebas de inclusión y verificarlas es pura computación. Cualquiera que tenga la lista ordenada de hojas puede recalcular la raíz y volver a derivar cualquier prueba: sin cuenta, sin gateway, sin red y sin la colaboración de quien lo publicó originalmente. Quien publica nunca interviene en el momento de la verificación.

Eso importa para el material probatorio que debe sobrevivir a las herramientas y a los proveedores. Una prueba que puedes comprobar offline contra un explorador público de Cardano sigue funcionando mucho después de que cualquier servicio concreto haya desaparecido. Puedes verificar el compromiso de un lote igual que verificarías cualquier registro Label 309, y puedes conectar la comprobación de inclusión directamente en CI con la herramienta de línea de comandos de código abierto cardanowall (merkle-build para plegar una carpeta en una raíz, merkle-verify para confirmar que un elemento pertenece a ella).

¿Por qué resulta útil para flujos de gran volumen?

Porque muchas pruebas reales tienen forma de lote, no de archivo único. Un equipo puede necesitar mostrar:

• qué construyó un pipeline de CI/CD y qué artefactos se enviaron en un release;
• qué software bill of materials (SBOM) existía antes de que se divulgara una vulnerabilidad;
• qué salidas de IA se produjeron un día determinado;
• qué snapshot de un conjunto de datos existía antes de un entrenamiento;
• qué registros de cumplimiento existían antes de una auditoría;
• qué archivos de prueba legal se preservaron antes de una retención;
• a qué reservas se comprometía un balance en un momento dado.

Ninguno de estos encaja bien en un modelo de un archivo por transacción. La agrupación de Merkle te permite publicar un único compromiso por lote, sin exponer cada elemento privado y sin metadatos en cadena que crezcan linealmente con el tamaño del lote.

¿Puede la lista de hojas permanecer privada?

Sí. La raíz publicada no revela nada sobre las hojas con las que se compromete.

Puedes mantener la lista de hojas dentro de tu propio sistema de material probatorio, archivo de releases, sala de datos o repositorio de cumplimiento, y más tarde revelar solo lo que necesites:

• un archivo y su prueba de inclusión;
• una fila de un conjunto de datos, un documento o un artefacto de release;
• una entrada de un registro de auditoría;
• un subconjunto de la lista;
• o la lista de hojas completa.

Este es el patrón cuando quieres un compromiso público con sello de tiempo sin hacer públicos los datos subyacentes; está estrechamente relacionado con la divulgación confidencial sin archivos públicos y con la prueba de reservas con raíces de Merkle.

La contrapartida es la responsabilidad. Una raíz prueba que alguna lista de un tamaño conocido existía en un momento conocido; no permite, por sí sola, que nadie pruebe qué elementos concretos había en ella. Si mantienes privada la lista de hojas, debes preservarla. Pierde tanto la lista de hojas como cualquier prueba de inclusión guardada, y conservarás el sello de tiempo pero perderás la capacidad de probar que un elemento concreto estaba comprometido.

¿Qué debería ser una hoja?

Una hoja debería representar exactamente aquello que quizá necesites probar más tarde.

Para archivos, la hoja es el hash de los bytes del archivo. Para datos estructurados, suele ser el hash de una entrada de manifiesto canónica. Para CI/CD, una hoja podría ser el digest de un artefacto, el digest de un SBOM, el digest de un registro de build, una referencia de commit o una entrada de manifiesto de release firmada. Para la procedencia de IA, una hoja podría ser el hash de un archivo de salida, una entrada de manifiesto de prompt/salida, un compromiso sobre un elemento del conjunto de datos o el hash de un manifiesto de procedencia del contenido.

La disciplina que importa es la coherencia. Si las hojas se generan de maneras distintas entre ejecuciones, cuesta confiar en las pruebas de inclusión posteriores. Fija una vez la definición de hoja y la canonicalización, y aplícalas igual cada vez.

¿Deberías publicar la lista de hojas o mantenerla privada?

Depende de qué estés probando y de quién deba verlo.

Publicar la lista de hojas hace trivial la verificación por terceros: cualquiera puede obtener la lista, recalcular la raíz e inspeccionar el conjunto comprometido. Mantenerla privada te da confidencialidad y divulgación selectiva: revelas pruebas de inclusión solo cuando hace falta. Muchos flujos hacen ambas cosas: una lista de hojas pública para releases de código abierto, una privada para registros de cumplimiento internos y una sellada para material probatorio sensible.

La raíz es el compromiso público. La política sobre la lista de hojas es una decisión aparte que se superpone encima.

¿Con qué frecuencia deberías publicar raíces?

Ajusta la cadencia al flujo de trabajo.

Un sistema de CI/CD podría publicar una raíz por release, build o ventana de despliegue. Un sistema de cumplimiento podría publicar una raíz por hora, por día o por período de control. Una plataforma de IA podría publicar raíces por lote de contenido generado, por snapshot de entrenamiento o por evento de versión de modelo. Un sistema de prueba legal podría publicar una raíz por expediente, por ventana de admisión o por hito de cadena de custodia.

La cadencia adecuada equilibra el coste, la sencillez operativa y la precisión de la cronología que quizá necesites probar más tarde.

¿Qué no prueba una raíz de Merkle?

Una raíz de Merkle prueba el compromiso con una lista en un momento dado. No prueba las afirmaciones de negocio que envuelven a esa lista. Como cualquier prueba de existencia, muestra que ciertos bytes existían antes de un tiempo público, no que sean verdaderos, lícitos, escritos por alguien en particular o propiedad de nadie (consulta qué no prueba una prueba).

En concreto:

• no prueba que un build de software fuera seguro; puede probar qué artefactos o manifiestos se incluyeron en un release;
• no prueba que un conjunto de datos se recopilara de forma lícita; puede probar que un compromiso sobre un conjunto de datos existía antes de un tiempo dado;
• no prueba que una entrada de registro sea verdadera; puede probar que la entrada formaba parte de un lote comprometido;
• no prueba la autoría, a menos que el registro o el proceso que lo rodea añadan firmas y controles de identidad.

En Label 309, la autoría es opcional y explícita: un registro puede llevar firmas separadas, pero nunca son obligatorias, y un compromiso de Merkle por sí solo no afirma nada sobre quién produjo la lista. La raíz aporta el compromiso con sello de tiempo; el proceso que la rodea aporta el significado de negocio.

¿Cómo encaja Label 309?

Label 309 es el estándar abierto y neutral respecto al proveedor para la prueba de existencia en Cardano; se ha presentado al proceso CIP de Cardano y está bajo revisión de los editores del CIP como propuesta de la categoría Metadata. La agrupación de Merkle no es un producto aparte: es la capa de escalado integrada en el estándar.

El compromiso de un lote usa el mismo registro y la misma vía de verificación que una prueba de un único archivo. Un registro bajo la etiqueta de metadatos 309 puede llevar una raíz de Merkle y, junto a ella, las mismas piezas opcionales que admite cualquier registro: hashes ordinarios por archivo, URIs de almacenamiento direccionado por contenido, un puntero de sustitución a un registro anterior y firmas de autoría. Así, una prueba de lote hereda todo lo que tiene una prueba individual:

• un testigo de tiempo de bloque de Cardano;
• una estructura de registro estándar y cerrada;
• verificación autónoma y offline contra un explorador público;
• el mismo herramental, las mismas bibliotecas y la misma CLI de código abierto en todos los lenguajes.

Calcula el hash de cada elemento, construye un árbol de Merkle ordenado, publica una raíz en un registro Label 309 y conserva la lista de hojas y las pruebas que puedas necesitar. Más tarde, prueba que cualquier elemento concreto formaba parte del lote comprometido, sin poner cada elemento en la cadena. Eso es lo que hace que la prueba de existencia sea práctica para CI/CD, procedencia de IA, conjuntos de datos, cumplimiento, prueba legal y otros flujos de gran volumen.

Para seguir leyendo

• Cómo funciona Label 309: la estructura de registro en la que encaja el compromiso de un lote.
• Prueba los datos de entrenamiento sin revelarlos: divulgación selectiva a partir de una lista de hojas privada, de principio a fin.
• Cómo se compara Label 309 con OpenTimestamps: otro protocolo que agrega muchos hashes en un único anclaje.
• El estándar, los SDK y la CLI de código abierto, y el texto de la especificación: label309.org y github.com/cardanowall.
• RFC 9162: la construcción Merkle Tree Hash que Label 309 usa para los compromisos de lote.