Introducción
Qué es Label 309, los principios que garantiza y cómo cualquiera puede verificar un registro sin confiar en un servidor.
Label 309 es un estándar abierto de Prueba de Existencia (PoE) sobre la cadena de bloques de Cardano. Quien publica calcula un hash criptográfico de cierto contenido y lo ancla en una transacción de Cardano bajo la etiqueta de metadatos 309. A partir de ese momento, cualquiera que tenga la referencia de la transacción puede demostrar que el contenido existía en o antes del tiempo del bloque, usando únicamente la cadena de bloques pública, sin necesidad de confiar en el emisor, en un dominio ni en servidor alguno.
El estándar es deliberadamente reducido en su núcleo: el hash del contenido es la afirmación, y todo lo demás son metadatos opcionales sobre ella. Sobre ese núcleo define firmas de autoría opcionales y una carga útil cifrada («sellada») opcional dirigida a destinatarios concretos, sin que nada de esto requiera jamás un intermediario de confianza.
Los cinco invariantes
Todo en Label 309 se deriva de cinco principios innegociables:
- Centrado en el contenido. El hash del contenido es la afirmación primaria; todos los demás campos son metadatos sobre ella.
- Independiente del emisor. Cualquier billetera puede publicar un registro. Los verificadores nunca confían en quien publica.
- Independiente del almacenamiento. Las URI de almacenamiento son una lista
opcional y plural (
ar://,ipfs://); un registro que solo contiene el hash es plenamente válido. - Verificable de forma autónoma. A un verificador le bastan los metadatos de la transacción, opcionalmente los bytes del contenido, y un explorador público de la cadena de bloques. Nunca se requiere un servidor del emisor.
- Ágil en algoritmos. Los hashes, los AEAD, los KEM, los KDF y las firmas referencian todos identificadores con nombre tomados de registros de algoritmos extensibles. Migrar a algoritmos poscuánticos es una adición, no un cambio que rompa la compatibilidad.
Perfiles de conformidad
Un registro participa en uno de cuatro perfiles en capas, desde una simple marca de tiempo hasta una carga útil cifrada y dirigida a destinatarios. Cada perfil es un superconjunto estricto del anterior.
| Perfil | Añade | Responde |
|---|---|---|
| core | un hash del contenido bajo la etiqueta 309 | «este contenido existía para el tiempo T» |
| signed | una o más firmas de registro COSE_Sign1 | «...y esta clave responde por él» |
| sealed | una carga útil cifrada (frase de contraseña o destinatarios) | «...mantenido confidencial, pero con marca de tiempo» |
| recipient-sealed | ranuras de clave por destinatario (X25519 o X-Wing) | «...entregado a claves concretas, conservado en privado» |
La autoría y el cifrado son siempre opcionales. Un verificador que solo entiende
core aún puede validar la afirmación de marca de tiempo de cualquier registro.
La verificación, a vista de pájaro
Label 309 define tres roles de verificación, cada uno una extensión estricta del anterior:
- Validador estructural: una función pura sobre los bytes del registro. Sin red, sin comprobación de firmas, sin descifrado; solo confirma que el registro está bien formado conforme al esquema y a las reglas del estándar.
- Verificador público: obtiene la transacción de un explorador público, ejecuta la validación estructural, confirma que el registro está anclado en la cadena y verifica cualquier firma de autoría. No descifra.
- Verificador destinatario: un verificador público que, además, posee una clave privada, descifra una carga útil sellada dirigida a él y recalcula los hashes del texto plano.
Como cada rol opera a partir de datos públicos y de un explorador elegido por el propio verificador, la verificación nunca depende de la infraestructura de quien publica.
La propiedad fundamental
Una prueba de Label 309 es algo que usted mismo puede comprobar. Dada la referencia de una transacción y, para las afirmaciones sobre contenido, los bytes originales, cualquier implementación conforme llega al mismo veredicto a partir de la cadena pública por sí sola.
Cómo está organizada esta especificación
Los capítulos que siguen definen el formato de transmisión (el registro bajo la etiqueta 309), los registros de algoritmos, el modelo criptográfico de claves, las firmas de autoría, la entrega sellada (cifrada), el flujo de verificación y su catálogo de errores, el modelo de seguridad y el contrato de conformidad entre lenguajes. Cada página es autónoma y cita las constantes con nombre y las reglas que necesita quien implementa el estándar.