Cómo verificar un registro Label 309

Verificas un registro Label 309 directamente desde la cadena pública de Cardano, partiendo de un único dato de entrada: una referencia de transacción de Cardano. Nada en la respuesta depende de CardanoWall, de quien publicó el registro ni de que ningún servidor siga en línea.

Un verificador obtiene los bytes en bruto de la transacción desde la infraestructura pública de Cardano, extrae la etiqueta de metadatos 309, reensambla el cuerpo del registro, comprueba el CBOR canónico y el esquema, verifica las firmas de autoría que haya y —cuando dispone de los bytes del contenido o de una carga cifrada— recalcula los hashes. Toda la comprobación es una secuencia de comparaciones criptográficas, no una petición a un servicio de confianza.

El gateway que publicó el registro no es la autoridad. El registro lo es. Esa es la idea del estándar: una prueba que verificas una vez sigue siendo verificable por cualquiera, para siempre, con cualquier herramienta Label 309 conforme.

¿Qué necesitas para verificar?

El dato de entrada mínimo es un hash de transacción de Cardano.

Solo con ese hash de transacción, un verificador puede responder:

• ¿hay un registro Label 309 en esta transacción?
• ¿el registro es estructuralmente válido?
• ¿la transacción está confirmada con suficiente profundidad?
• ¿las firmas a nivel de registro verifican, si las hay?
• ¿qué hashes, URIs de almacenamiento, raíces de Merkle y sobres sellados afirma el registro?

Para demostrar que un archivo concreto es el archivo que hay detrás del hash, el verificador necesita además los bytes del archivo o un objeto de almacenamiento atribuible referenciado por el registro.

Para descifrar un registro sellado, el verificador necesita la clave privada del destinatario. Esa clave se usa de forma local y nunca se envía de vuelta a quien publicó ni a CardanoWall — toda la construcción está pensada para que la verificación nunca se comunique con ningún servidor de origen.

¿Qué comprueba realmente un verificador?

Un buen verificador debería comprobar el registro por capas.

La primera capa es el validador estructural. Es una función pura sobre los bytes del registro. No hace llamadas de red, ni descifrado, ni verificación de firmas. Comprueba el CBOR canónico, los tipos de campo, el esquema cerrado, los nombres de algoritmo registrados, las reglas de URI y las restricciones entre campos, como «debe haber al menos un ítem o un compromiso de Merkle».

La segunda capa es el verificador público. Resuelve la transacción desde una fuente de datos de Cardano elegida por el verificador, vincula los bytes obtenidos al hash de la transacción, extrae la etiqueta 309, comprueba la profundidad de confirmación y verifica las firmas del registro. Esta es la capa que puede ejecutar una auditoría pública, un trabajo de CI o un explorador.

La tercera capa es el verificador de destinatario. Hace todo lo que hace el verificador público y, además, intenta descifrar los ítems sellados con la clave local del destinatario y recalcula los hashes del texto plano tras el descifrado.

Esa estratificación importa porque no toda prueba necesita todas las comprobaciones. Un registro de solo hash puede seguir siendo válido aunque no tenga ninguna carga cifrada. Un verificador público puede validar un registro firmado sin poder descifrar un archivo sellado.

¿Por qué verificar desde los bytes en bruto de la transacción y no desde una vista JSON?

La verificación Label 309 funciona a partir de los datos en bruto de la cadena, no de una cómoda proyección a JSON — y la diferencia no es cosmética.

El registro es CBOR canónico. Las firmas cubren un CBOR canónico exacto a nivel de byte. Los metadatos de las transacciones de Cardano tienen cadenas de bytes, cadenas de texto, arrays, mapas y reglas de orden que JSON no puede preservar sin pérdida.

Por eso un verificador debería obtener el CBOR en bruto de la transacción, recalcular el identificador de la transacción, vincular los datos auxiliares al cuerpo de la transacción y luego reensamblar el array de fragmentos de la etiqueta 309 en el cuerpo original del registro.

Un explorador puede ser una infraestructura útil. No debería convertirse en aquello en lo que confías. El verificador debería tratar las respuestas del explorador como datos que vincular, comprobar y contrastar.

¿Qué hay dentro de un registro de la etiqueta 309?

Un registro Label 309 se transporta bajo la etiqueta de metadatos 309 de las transacciones de Cardano.

El valor en la cadena no es un objeto JSON suelto. El cuerpo del registro se serializa una sola vez como CBOR canónico y después se transporta como un array de fragmentos de cadena de bytes, porque en los metadatos de Cardano las cadenas de bytes y las de texto tienen un límite de 64 bytes.

Tras el reensamblado, el cuerpo del registro es un único mapa CBOR. Sus claves de nivel superior son:

• v, la versión del esquema (actualmente 1);
• items, un array opcional de compromisos por contenido — cada ítem lleva un mapa hashes obligatorio y, opcionalmente, su propia lista uris para almacenamiento direccionado por contenido (ar://, ipfs://) y un sobre enc para contenido sellado;
• merkle, compromisos de lista opcionales que vinculan una raíz en la cadena a una lista de hojas fuera de la cadena — la forma de anclar lotes grandes;
• sigs, firmas de autoría a nivel de registro opcionales;
• supersedes, un puntero de sustitución opcional y de solo anexado a un registro anterior;
• crit más claves de extensión con espacio de nombres, para añadidos compatibles hacia delante.

Un registro conforme debe comprometerse al menos con una entrada de items o con un compromiso de merkle. Las URIs de almacenamiento y el sobre sellado viven dentro de un ítem, no en el nivel superior — un detalle que conviene acertar cuando analizas el registro por tu cuenta.

La afirmación central siempre pone el contenido primero: estos hashes, o esta raíz de Merkle, se anclaron en esta transacción no más tarde de la hora del bloque.

¿Qué veredictos debería esperar la automatización?

La verificación no debería reducir todo problema a «válido» o «inválido».

El modelo de verificador de Label 309 usa cuatro veredictos legibles por máquina:

• valid: pasaron todas las comprobaciones obligatorias.
• failed: el propio registro falló una comprobación estructural, de firma o de integridad atribuible.
• unverifiable: una comprobación obligatoria no pudo completarse por motivos no atribuibles al registro, como infraestructura no disponible o contenido que no se pudo obtener.
• pending: la transacción está en la cadena pero por debajo del umbral de confirmación del verificador.

Esa distinción es importante en los sistemas reales.

Si un gateway de almacenamiento está caído, no se debería condenar el registro. Si los bytes obtenidos son atribuibles a una URI comprometida y su hash no coincide, el registro debería fallar. Si la transacción solo tiene una confirmación, el verificador debería decir que está pendiente en lugar de fingir que la finalidad ya se ha producido.

La CLI de código abierto cardanowall mapea esos estados directamente sobre códigos de salida, de modo que el veredicto sobrevive en un script de shell sin analizar ningún JSON:

cardanowall verify <tx-hash> --json

Esa distinción es justo lo que quieres en integración continua: el script puede distinguir «la prueba es mala» (salida 1, y que un explorador con mal comportamiento nunca puede fabricar) de «inténtalo más tarde» (salida 2). El mismo verificador se incluye en los SDK de TypeScript, Python y Rust, así que una aplicación puede leer el informe estructurado completo en lugar de un código de salida. Para los patrones de integración de esto en una canalización, consulta cómo usar la CLI en la automatización.

¿Cómo verificas un archivo?

Para una prueba de archivo sencilla, el flujo de trabajo es:

1. Toma el hash de la transacción.
2. Obtén y verifica el registro Label 309.
3. Identifica el algoritmo de hash y el digest comprometidos.
4. Calcula el hash de los bytes del archivo de forma local.
5. Compara tu digest con el digest del registro.
6. Comprueba la profundidad de confirmación y la hora del bloque.
7. Comprueba las firmas del registro, si las hay.

Si el archivo difiere en un solo byte, el hash será distinto.

Esa es la fortaleza de una prueba basada en el hash del contenido. No demuestra que el archivo sea verdadero, legal, original ni valioso. Demuestra que los bytes exactos que coinciden con el hash existían no más tarde de la hora del bloque anclado, sujeto a la política de finalidad del verificador.

¿Cómo verificas un registro sellado?

Un registro sellado añade contenido cifrado.

El registro público sigue comprometiéndose con el hash del texto plano. El texto cifrado puede almacenarse fuera de la cadena, por ejemplo a través de Arweave o IPFS. El sobre en la cadena contiene la información necesaria para que un destinatario previsto recupere la clave del contenido de forma local.

El verificador de destinatario debería:

1. Ejecutar primero la ruta de verificación pública.
2. Probar la clave privada suministrada contra las ranuras selladas.
3. Si una ranura se abre, descifrar el texto cifrado.
4. Recalcular el hash del texto plano.
5. Compararlo con el compromiso de hash en la cadena.

Esa comprobación final del hash es el puente entre «descifré algo» y «este es el contenido exacto que se selló en el tiempo». Descifrar los bytes no basta por sí solo; el hash del texto plano recalculado tiene que coincidir con el compromiso que el registro hizo antes de que se cifrara nada.

La clave del destinatario se queda en local. La verificación no necesita ninguna cuenta de CardanoWall de confianza, ningún servidor del emisor ni ninguna llamada de vuelta a la persona que publicó el registro. Un registro sellado mantiene su texto plano confidencial para quienes poseen las claves — pero ten en cuenta sus límites: no garantiza el anonimato y, una vez que un destinatario descifra el contenido, puede hacer lo que quiera con el texto plano.

¿Cómo verificas un compromiso de Merkle?

Los compromisos de Merkle son para lotes.

En lugar de publicar miles de hashes directamente en un solo registro, un productor puede publicar una sola raíz de Merkle y mantener la lista ordenada de hojas y las pruebas de inclusión fuera de la cadena.

Para verificar un ítem del lote:

1. Calcula el hash del ítem u obtén el digest de la hoja comprometida.
2. Verifica la prueba de inclusión contra la raíz de Merkle.
3. Comprueba que la raíz y leaf_count están en el registro Label 309.
4. Verifica la transacción de Cardano y la profundidad de confirmación.

La raíz no basta por sí sola. El productor o el archivo deben preservar la lista de hojas y las pruebas de inclusión. Label 309 da al lote un anclaje público; las pruebas operativas en torno al lote aún hay que conservarlas. Así es como un solo registro demuestra miles de archivos a un coste fijo en la cadena.

¿En qué no se debería confiar?

No confíes en el sitio web de quien publica como fuente de verdad.

No confíes en una captura de pantalla de una transacción.

No confíes en una vista de explorador en JSON como entrada criptográfica.

No confíes en un gateway de almacenamiento solo porque devolvió bytes.

No confíes en distintivos de «verificado» que no dicen qué se comprobó.

El verificador debería poder generar un informe: hash de la transacción, fuentes de datos de Cardano utilizadas, profundidad de confirmación, hora del bloque, digest del registro, resultados de las firmas, resultados de los hashes del contenido, resultados de la obtención del almacenamiento, comprobaciones de Merkle y cualquier comprobación omitida.

Ese informe es lo que hace que la prueba sea utilizable en auditorías y automatización.

¿Qué no demuestra la verificación?

La verificación es precisa. No se debería sobrevender.

Un registro Label 309 válido no demuestra, por sí solo:

• la propiedad legal del contenido ni los derechos exclusivos sobre él;
• que el contenido sea verdadero;
• que quien publica tuviera permiso para publicarlo;
• que una persona del mundo real controle una clave de firma;
• que un tribunal, un regulador o un cliente acepten la prueba sin material probatorio de apoyo — la admisibilidad depende de la jurisdicción, y una prueba puede sustentar un caso pero no sustituye al asesor legal;
• que el almacenamiento fuera de la cadena vaya a seguir disponible para siempre, salvo que la durabilidad del almacenamiento se mantenga por separado.

Demuestra la afirmación que el registro hace realmente: un hash o una raíz de Merkle se anclaron en Cardano, las firmas que hubiera sobre el registro verificaron, y las comprobaciones de contenido o descifrado que hubiera coincidieron con los compromisos. Dicho de otro modo, establece el momento y la integridad — no la verdad, la propiedad ni los derechos.

Esa afirmación más acotada es justo lo que la hace útil. Para conocer todo el límite de lo que un sello de tiempo puede y no puede hacer, consulta qué no demuestra una prueba.

Lecturas adicionales

• El estándar Label 309, incluida la canalización de verificación completa, los estados de veredicto y el catálogo tipado de errores: label309.org.
• El verificador de código abierto — la CLI cardanowall más los SDK de TypeScript, Python y Rust, que todos ejecutan las mismas comprobaciones: github.com/cardanowall.
• Label 309 está presentado al proceso CIP de Cardano y en revisión por los editores de CIP como propuesta de la categoría Metadata: la pull request abierta.