Cómo funciona Label 309

Label 309 define cómo se escribe un registro de prueba de existencia en los metadatos de una transacción de Cardano. En su núcleo, un registro fija un compromiso sobre uno o más hashes de contenido en Cardano bajo la etiqueta de metadatos 309. La hora del bloque de esa transacción se convierte en el testigo público de que esos bytes exactos existían a más tardar en ese instante. Todo lo demás que el registro puede llevar —firmas, URIs de almacenamiento, cargas cifradas, ranuras de claves de destinatario, raíces de Merkle, un puntero a un registro anterior— son metadatos opcionales sobre esa única afirmación.

El objetivo de diseño es fácil de enunciar: una prueba debe poder verificarse de forma independiente. Comprobar la afirmación básica no debería exigir confiar en CardanoWall, en el sitio web de quien publica, en una base de datos privada ni en una autoridad de certificación, sino solo en la cadena pública y, para las afirmaciones de contenido, en los bytes originales.

Label 309 es un estándar abierto. Se ha presentado al proceso CIP de Cardano como una propuesta de la categoría Metadata y está en revisión por los editores de CIP; la propia etiqueta de metadatos es el identificador duradero en la cadena, y la aplicación web, la CLI y los SDK son implementaciones de referencia de ella, no el estándar en sí. Si prefieres ver primero el panorama general, empieza por qué es realmente la prueba de existencia.

¿Qué se almacena en la blockchain bajo la etiqueta 309?

Un registro Label 309 vive en los metadatos de una transacción de Cardano bajo la etiqueta entera 309. Exactamente un registro por transacción; un verificador ignora cualquier otra etiqueta de metadatos.

El cuerpo del registro se codifica como CBOR canónico —un formato binario determinista—, de modo que dos implementaciones que expresan el mismo registro lógico emiten bytes idénticos. Cardano limita cualquier cadena de metadatos a 64 bytes, y un registro serializado suele ser más grande. Por eso el cuerpo se transporta como un único array CBOR de pequeños fragmentos de cadena de bytes cuya concatenación en orden es el cuerpo del registro. Un verificador concatena los fragmentos de nuevo antes de validar nada. Esa es la única fragmentación que realiza el formato.

Ese detalle de transporte importa a quien implementa, pero la idea de fondo es sencilla:

1. La transacción lleva la etiqueta de metadatos 309.
2. El valor bajo esa etiqueta se reensambla en un único registro Label 309.
3. El registro fija un compromiso sobre hashes de contenido, raíces de Merkle o ambos.
4. Los campos opcionales añaden firmas, material de carga cifrada, URIs de almacenamiento y un puntero de reemplazo.

No es un campo de notas libre. El registro tiene una forma estricta y cerrada, que es precisamente lo que permite a distintas implementaciones producir y verificar los mismos bytes.

¿Por qué el hash del contenido es la afirmación principal?

Porque la prueba de existencia es una afirmación sobre bytes exactos, y un hash es la huella de unos bytes exactos.

El hash del contenido es la afirmación principal en Label 309; todos los demás campos son metadatos sobre él. Para una prueba de archivo sencilla, un ítem lleva un mapa hashes que empareja un algoritmo de hash con nombre —por ejemplo sha2-256 o blake2b-256— con un digest crudo de 32 bytes. Para comprobar la prueba, un verificador recalcula el digest a partir del archivo original y lo compara con el digest del registro.

Si los bytes coinciden, la prueba pasa. Cambia un solo byte y el digest cambia, así que la prueba falla.

Por eso la afirmación se mantiene pequeña aunque el contenido sea grande o privado. El registro nunca necesita el archivo. Necesita la huella.

¿Qué son items, uris y enc?

Los items son los compromisos por contenido dentro de un registro. Cada ítem es una afirmación de contenido. La única parte obligatoria es un mapa hashes no vacío; el resto es opcional.

Un ítem puede llevar:

• hashes — el mapa obligatorio de algoritmo de hash a digest crudo;
• uris — ubicaciones direccionadas por contenido opcionales, como ar://… (Arweave) o ipfs://… (IPFS);
• enc — un sobre de cifrado opcional para un registro sellado (cifrado).

La idea clave es que las uris no son la prueba. El hash es la prueba. Una URI es una pista de recuperación o un compromiso de almacenamiento que ayuda a un verificador a encontrar los bytes que comprobar. Un registro solo con hash y sin URI es una prueba completa y válida. Un registro con una URI puede ayudar a recuperar contenido público o texto cifrado. Un registro sellado mantiene el texto plano cifrado fuera de la cadena sin dejar de demostrar cuándo existió.

¿Por qué solo ar:// e ipfs://?

Label 309 v1 restringe las URIs de almacenamiento a esquemas direccionados por contenido —Arweave e IPFS— y rechaza todo lo demás, incluido https://. Esa restricción es deliberada, no temporal.

Una URL https:// normal depende de DNS, TLS, el comportamiento del servidor, las redirecciones y de lo que sea que esté alojado en esa dirección más adelante. Una URI direccionada por contenido es distinta: la propia dirección se deriva del contenido (un CID de IPFS es un multihash de los bytes; un id de transacción de Arweave fija un compromiso sobre los datos bajo el consenso de Arweave). Así, un verificador puede confirmar que «los bytes que descargué son los bytes con los que se comprometió el productor» sin confiar en el gateway de almacenamiento, el DNS ni una autoridad de certificación. Los bytes descargados aún tienen que coincidir con el compromiso en la cadena; la capa de almacenamiento nunca es por sí sola una fuente de verdad.

¿Qué demuestran las firmas y qué no?

Un registro Label 309 puede llevar un array sigs opcional de nivel superior. Cada entrada es una firma COSE_Sign1 separada sobre el cuerpo del registro con el campo sigs eliminado. En términos simples, quien firma respalda todo el registro de una vez: cada ítem, cada hash, cada URI, cada sobre sellado, cada raíz de Merkle, el puntero de sustitución y cualquier campo de extensión.

Firmar es aditivo. Un registro sin firma sigue demostrando existencia. Un registro con una firma válida también muestra que una clave concreta respaldó el registro:

• solo con hash: estos bytes existían a más tardar en esta hora pública;
• firmado: estos bytes existían a más tardar en esta hora pública, y esta clave respaldó el registro.

La precisión importa, porque una firma demuestra menos de lo que la gente suele suponer. Una firma verificada no demuestra que la misma clave pagara o enviara la transacción de Cardano, que eligiera la hora del bloque ni que pertenezca a ninguna persona real con nombre. Demuestra que la clave firmó el cuerpo del registro, nada más. Exprésalo como «firmado por esta clave», nunca como «publicado por esta clave». Ese significado estrecho y honesto es lo que hace que una prueba firmada sea portable entre distintas aplicaciones y gateways. La autoría siempre es opcional, y una firma que un verificador no puede comprobar (un algoritmo no soportado, una clave que no se resuelve) nunca invalida la afirmación de existencia: las firmas fallan de forma blanda; la existencia no.

¿Qué es un registro sellado?

Un registro sellado mantiene el contenido confidencial sin dejar de demostrar cuándo existió.

En un registro Label 309 sellado, el ítem sigue fijando un compromiso sobre el hash del texto plano, nunca sobre el texto cifrado. El texto plano se cifra, y el texto cifrado vive en una URI direccionada por contenido (ar://… o ipfs://…), nunca en la cadena. El registro en la cadena lleva un sobre de cifrado que contiene el material que necesita un titular de clave elegido para recuperar la clave de cifrado del contenido. La cadena no contiene el texto plano, y no publica una lista de destinatarios.

Para un destinatario, la verificación añade unos pasos:

1. Obtén el registro de Cardano.
2. Obtén el texto cifrado del almacenamiento direccionado por contenido.
3. Intenta abrir localmente una ranura de clave que coincida.
4. Descifra el texto cifrado si se abre una ranura.
5. Recalcula el hash del texto plano y compáralo con el compromiso en la cadena.

Como el digest en la cadena vincula el texto plano, una prueba sellada preserva el archivo original exacto y lo mantiene privado. Eso viene con unos límites honestos: un registro sellado demuestra el momento y la integridad, no el anonimato, y un destinatario que descifra siempre puede optar por filtrar el texto plano después.

¿Cómo funcionan los destinatarios sin un campo de destinatario?

Los destinatarios funcionan mediante claves de recepción y descifrado de prueba, no con un campo de destinatario legible.

Si un remitente conoce la dirección de recepción de un destinatario (una clave pública X25519, opcionalmente una híbrida poscuántica), puede construir un registro sellado con una ranura de clave que ese destinatario pueda abrir. La clave pública del destinatario nunca aparece como un campo legible en el registro. El software del destinatario observa el flujo público de registros Label 309 e intenta descifrar localmente las ranuras candidatas; si una ranura se abre, el registro pertenece al Inbox de ese destinatario.

Por eso un Inbox de CardanoWall no es un buzón normal del lado del servidor. El gateway expone un feed de registros que no revela al destinatario; el cliente encuentra los que puede descifrar. El servidor nunca necesita saber quién es el destinatario ni descifrar nada en su nombre. (Consulta cómo recibir registros sellados para ver el lado del destinatario en la práctica.)

Aún hay límites de metadatos que conviene dejar claros. El registro nunca publica el texto plano ni una columna de destinatario, y el orden de las ranuras se mezcla antes de la publicación para que no transmita ninguna señal. Pero el número de ranuras es visible, y el momento, los rastros de pago y los errores operativos pueden revelar información que el propio formato del registro no puede ocultar.

¿Cómo cubre un solo registro miles de archivos?

Si necesitas demostrar que mil archivos existían, no deberías necesitar mil transacciones de Cardano. Label 309 admite la agrupación de Merkle: calcula el hash de los archivos, construye un árbol de Merkle sobre la lista ordenada de hashes y publica una única raíz de 32 bytes en el array merkle del registro. Junto a la raíz, el registro lleva un número de hojas, que vincula la raíz en la cadena al tamaño exacto de la lista fuera de la cadena.

Más adelante puedes demostrar que un archivo o evento concreto estaba en el lote mostrando:

• el archivo (o su hash de hoja);
• una prueba de inclusión: los hashes hermanos a lo largo del camino hasta la raíz;
• la raíz de Merkle anclada en el registro Label 309.

El verificador pliega la prueba de inclusión de vuelta hasta una raíz y la acepta solo si la raíz recalculada es igual a la raíz publicada, byte a byte. Cada hoja no revelada permanece privada: la raíz no revela nada sobre las hojas sobre las que se compromete.

Esta es la capa de escalado para artefactos de CI/CD, registros de cumplimiento, salidas de IA, manifiestos de conjuntos de datos, carpetas de publicación y paquetes de pruebas. Tiene su propio desarrollo en un registro para miles de archivos.

¿Qué hace el puntero supersedes?

supersedes es un puntero opcional de 32 bytes a un registro Label 309 anterior, por su hash de transacción. Permite que un registro más nuevo diga «esto reemplaza o actualiza aquel registro anterior».

El registro anterior no se elimina ni se invalida. Cardano solo añade (append-only), así que ambos registros siguen siendo verificables de forma independiente para siempre. El puntero es solo un enlace; no lleva un campo de motivo. El significado humano del reemplazo —una corrección, un manifiesto revisado, un paquete de pruebas actualizado— pertenece al nuevo contenido o a la capa de aplicación, no a los metadatos. El valor del puntero es que funciona sin ninguna fila de base de datos de un proveedor y sin ningún id de registro propietario.

¿Cómo funciona la verificación?

La verificación es por capas. Label 309 define tres roles de verificador, cada uno una extensión estricta del anterior:

• Validador estructural — una función pura sobre los bytes del registro. Confirma el CBOR canónico, la forma del esquema, los tipos de campo, los campos obligatorios, los identificadores de algoritmo y las reglas de URI. No realiza E/S de red, no verifica firmas y no descifra nada.
• Verificador público — parte de una referencia de transacción de Cardano. Obtiene la transacción cruda de un explorador que el propio verificador elige, vincula esos bytes al hash de transacción solicitado, confirma que la etiqueta 309 está presente, reensambla el registro, ejecuta la validación estructural, comprueba la profundidad de confirmación y verifica las firmas que soporta. Si hay bytes de contenido disponibles, puede recalcular los hashes del contenido público. No descifra.
• Verificador de destinatario — todo lo que hace el verificador público, más su propia clave privada para abrir cargas selladas y recalcular hashes del texto plano.

Un matiz mantiene honesta la verificación: un verificador público lee el CBOR crudo de la transacción, no la vista JSON de los metadatos de un explorador. Una proyección JSON pierde información —descarta el orden de las claves del mapa y la distinción entre bytes y texto—, así que volver a codificar a partir de ella rompería todas las firmas de un registro conforme. Y como la confirmación en Cardano es probabilística, un registro que solo tiene un bloque o dos de profundidad se reporta como pending en lugar de valid hasta que tiene suficientes confirmaciones detrás.

Esta estructura mantiene limpio el modelo de confianza. Un verificador básico no necesita ninguna cuenta de CardanoWall; una prueba pública se comprueba sin ningún servidor de quien publica; una prueba sellada se descifra localmente, en manos del titular de la clave. El recorrido verifica un registro Label 309 muestra el camino del verificador público de principio a fin.

¿Dónde encaja el gateway?

El gateway publica registros. No es la raíz de confianza.

Un gateway Label 309 se encarga de las partes que son genuinamente difíciles de ejecutar por cuenta propia: calcula el presupuesto, sube el texto cifrado al almacenamiento, construye y envía la transacción de Cardano, espera la confirmación, indexa registros, gestiona saldos y expone una API. CardanoWall usa este modelo de gateway para que publicar resulte práctico para usuarios y desarrolladores corrientes.

Pero una prueba no merece confianza porque un gateway diga que existe. La merece porque el registro está en la cadena, los bytes validan, las firmas se comprueban y los hashes se recalculan. Esa es la línea entre un servicio alojado y un estándar de prueba: el servicio te ayuda a publicar; el estándar permite que cualquiera verifique, con el gateway completamente fuera del camino de confianza.

El modelo mental mínimo

Piensa en Label 309 como un pequeño registro por capas:

1. items demuestra que ciertos bytes de contenido exactos existían a más tardar en una hora pública.
2. sigs permite que las claves respalden el registro, de forma opcional.
3. enc permite que el contenido cifrado permanezca privado pero recuperable.
4. las ranuras de claves de destinatario permiten que titulares de clave concretos abran contenido sellado.
5. merkle permite que un solo registro represente un lote muy grande.
6. la verificación se ejecuta sobre datos públicos y claves locales, nunca sobre la confianza en un proveedor.

Esa estratificación es la razón por la que CardanoWall puede ser una aplicación web, una API, una CLI, una aplicación de escritorio o un gateway autoalojado, sin que cambie el formato de la prueba. El producto puede cambiar; la prueba sigue siendo verificable.

Conviene ser honesto sobre una cosa en todo momento: una prueba Label 309 muestra que ciertos bytes existían a más tardar en una hora pública, y que no han cambiado desde entonces. No demuestra quién creó el contenido, quién lo posee ni si algo de lo que dice es cierto. Para ver dónde cae esa línea, consulta qué no demuestra una prueba.

Más lecturas

• ¿Qué es la prueba de existencia?
• Verifica un registro Label 309
• Un registro para miles de archivos
• Qué no demuestra una prueba
• El estándar Label 309: label309.org
• Los SDK y la CLI de código abierto: github.com/cardanowall
• La presentación al CIP de Cardano (en revisión): CIPs PR #1205