Todas las entradas

11 min de lectura

Prueba de existencia frente a OpenTimestamps: ¿qué sello de tiempo le conviene a tu trabajo?

OpenTimestamps es excelente para sellos de tiempo escuetos anclados en Bitcoin. Label 309 añade un registro de prueba nativo de Cardano con firmas, sellado, destinatarios y agrupación de Merkle. Así eliges.

Si lo único que necesitas es un sello de tiempo compacto y portátil que cualquiera pueda verificar contra una blockchain pública, OpenTimestamps es una opción excelente y muy enfocada. Si lo que necesitas es un registro de prueba en la cadena más completo —uno que también pueda llevar firmas, cargas selladas (cifradas), entrega a destinatarios, punteros de almacenamiento direccionado por contenido y agrupación de Merkle—, Label 309 está hecho para eso. Coinciden en la afirmación central («estos bytes existían antes del momento T») y divergen en todo lo demás.

Ambos prueban la existencia en el tiempo sin pedirte que confíes en el servidor de ninguna empresa. La diferencia está en la forma: OpenTimestamps produce un pequeño archivo de prueba externo; Label 309 publica un registro estructurado en Cardano. Este artículo expone dónde encaja cada uno.

¿Qué es OpenTimestamps?

OpenTimestamps es un protocolo y un conjunto de herramientas para sellar en el tiempo con una blockchain, anclando normalmente en Bitcoin. La idea es sencilla: calculas el hash de tus datos, construyes una prueba de sello de tiempo y, con el tiempo, el compromiso acaba en una transacción de Bitcoin. A partir de ahí, cualquiera puede comprobar que los datos existían antes de la hora de ese bloque.

Para mantener los costes bajos, OpenTimestamps usa servidores de calendario que agregan los hashes de muchos usuarios en una sola transacción de Bitcoin, de modo que no necesitas una transacción por archivo. El cliente produce un archivo de prueba .ots portátil que viaja junto a tus datos.

La verificación es donde se ve el modelo de confianza: verificas la prueba .ots contra el archivo original y una vista de la cadena de Bitcoin, sin ningún servidor de confianza de por medio. El cliente oficial advierte de que la verificación local necesita un nodo de Bitcoin Core; basta con un nodo podado.

Es un diseño elegante y maduro para sellos de tiempo mínimos y verificables de forma independiente.

¿Qué es Label 309?

Label 309 es un estándar abierto y neutral respecto al proveedor para registros de prueba de existencia en Cardano. El registro vive dentro de los metadatos de una transacción de Cardano, bajo la etiqueta de metadatos 309, y la hora del bloque de esa transacción es el testigo de que los bytes comprometidos existían a más tardar en ese momento. El estándar es el artefacto duradero; la aplicación web de CardanoWall, su herramienta de línea de comandos y sus SDK son implementaciones de referencia que se derivan de él.

El estándar se ha presentado al proceso CIP de Cardano y está en revisión por los editores de CIP como propuesta de la categoría Metadata (la pull request abierta aparece ahora mismo bajo un número provisional). Ten en cuenta que el identificador en la cadena —la etiqueta de metadatos 309— es independiente de cualquier número CIP que acabe asignándosele.

Para verificar una prueba Label 309, cualquiera obtiene la transacción de Cardano desde un explorador público, reensambla el registro canónico, valida su estructura, comprueba la profundidad de confirmación, verifica las firmas que haya y recalcula los hashes del contenido comprometido o las pruebas de inclusión de Merkle. En su nivel más simple responde a la misma pregunta que OpenTimestamps. Pero no es un único archivo de prueba: es un formato de registro en la cadena diseñado para llevar varias capas de prueba a la vez. Para un recorrido más completo, consulta cómo funciona Label 309 y qué va realmente en la blockchain.

¿Cuál es la diferencia real entre ambos?

OpenTimestamps está pensado expresamente para sellar en el tiempo. Label 309 está hecho para un registro de prueba de existencia completo.

OpenTimestamps encaja mejor cuando la pregunta es:

  • ¿Existía este archivo antes de esta hora atestiguada por Bitcoin?
  • ¿Puedo conservar un pequeño archivo de prueba y verificarlo más tarde?
  • ¿Puedo sellar en el tiempo sin revelar el contenido del archivo?
  • ¿Pueden los servidores de calendario agrupar muchas solicitudes para no pagar por archivo?

Label 309 encaja mejor cuando la pregunta es:

  • ¿Existía este archivo, manifiesto o raíz de Merkle a esta hora del bloque de Cardano?
  • ¿Firmó el registro una clave de identidad concreta?
  • ¿Puede sellarse (cifrarse) el propio archivo y recuperarse más tarde?
  • ¿Puede cifrarse el registro para destinatarios concretos?
  • ¿Puede un solo registro comprometerse con miles o millones de hojas a la vez?
  • ¿Puede el público verificarlo sin una cuenta de CardanoWall y sin acceso a nuestros servidores?

Ambos son sistemas de prueba arraigados en un consenso público. Su forma —y, por tanto, los flujos de trabajo que habilitan— es distinta.

¿Qué hace OpenTimestamps especialmente bien?

OpenTimestamps brilla en el sellado de tiempo público y mínimo construido en torno a un objeto de prueba externo. Sellas en el tiempo un archivo, conservas la prueba .ots junto a él y, más tarde, actualizas la prueba una vez que el compromiso se confirma en Bitcoin. El modelo de calendario permite que muchos usuarios compartan el coste del anclaje.

También tiene una sana estrechez de propósito. No intenta ser un sistema de entrega confidencial, un estándar de procedencia de medios, un ecosistema de firma de software ni una notaría legal. Sella en el tiempo, y hace ese único trabajo con limpieza. Para quien quiere sellos de tiempo respaldados por Bitcoin desde una herramienta probada a fondo, ese enfoque es una virtud.

¿Qué añade Label 309 por encima del sello de tiempo?

Label 309 envuelve estructura alrededor de la afirmación del sello de tiempo. Un solo registro puede incluir:

  • uno o varios hashes de contenido por ítem;
  • punteros de almacenamiento direccionado por contenido (ar:// para Arweave, ipfs:// para IPFS);
  • firmas opcionales a nivel de registro sobre el registro completo;
  • un sobre de cifrado para un ítem sellado, con el texto cifrado guardado fuera de la cadena;
  • ranuras de clave por destinatario que envuelven la clave del contenido para los destinatarios elegidos;
  • compromisos de Merkle que vinculan una raíz en cadena a una lista de hojas fuera de la cadena de tamaño arbitrario;
  • un puntero de sustitución a un registro anterior (de solo anexado: nunca revoca el registro previo);
  • claves de extensión con espacio de nombres reservadas para futuras especificaciones complementarias.

Esto importa en cuanto un flujo de trabajo necesita algo más que «tengo un archivo de prueba de sello de tiempo». Por ejemplo, un remitente puede sellar un archivo, dirigirlo a un destinatario, publicar el texto cifrado en una URI direccionada por contenido y, aun así, mantener el registro público verificable de forma independiente; consulta hashear, firmar, sellar, compartir. Un servicio de IA de gran volumen puede publicar una sola raíz de Merkle que represente muchas salidas generadas, y una canalización de CI/CD puede firmar un registro de pruebas de versión que cubra todo un conjunto de manifiestos; consulta un solo registro para miles de archivos. Esos flujos de trabajo necesitan un registro más rico del que lleva una prueba .ots escueta.

¿Cuál es más descentralizado?

Este no es lugar para eslóganes, así que conviene ser preciso sobre en qué te pide confiar cada modelo.

OpenTimestamps ancla en Bitcoin, cuyo historial de prueba de trabajo es una base muy sólida para sellar en el tiempo. La prueba se verifica de forma independiente en cuanto están disponibles los datos que necesita: una prueba .ots completa se verifica por entero contra un nodo local de Bitcoin, mientras que una incompleta todavía necesita un servidor de calendario que aporte la ruta hasta la cabecera del bloque.

Label 309 ancla en Cardano. Su verificación confía en la cadena pública de Cardano, en los bytes del registro y en el hash del contenido, y en nada más. Para la prueba central no exige confiar en CardanoWall ni en ningún servidor operado por quien publica; un verificador solo necesita la referencia de la transacción, opcionalmente los bytes del contenido y un explorador público que él mismo elija.

Ninguno es «más descentralizado» en abstracto. La pregunta práctica es qué cadena, herramientas, forma de prueba, modelo de coste y ecosistema encajan con tu flujo de trabajo.

¿Y la privacidad? ¿Alguno filtra el archivo?

Ambos pueden sellar en el tiempo sin publicar el archivo privado, y ambos tienen límites honestos.

Los servidores de calendario de OpenTimestamps reciben compromisos, no archivos en texto plano. Pero el proyecto es franco al señalar que sellar en el tiempo filtra metadatos: crear varios sellos de tiempo en rápida sucesión permite a un adversario relacionarlos, agrupar archivos en un mismo comando produce operaciones de compromiso casi idénticas que sugieren un autor común, y la API REST del calendario no intenta hoy por hoy ofrecer privacidad. Los nonces evitan que el calendario sepa qué se selló en el tiempo, pero los metadatos circundantes no quedan ocultos.

Label 309 mantiene el texto plano fuera de la cadena en las pruebas basadas solo en el hash y, en las pruebas selladas, cifra el texto plano y guarda únicamente el texto cifrado en una URI direccionada por contenido. Por diseño, la cadena no revela ninguna clave pública de destinatario: un destinatario reconoce un mensaje solo cuando logra descifrar una ranura a modo de prueba, así que no hay campo de destinatario que leer. Lo que sigue sin poder ocultar son el momento, el pago de la comisión, el acceso al gateway, el comportamiento de la cuenta y los errores operativos corrientes. Un registro sellado mantiene el texto plano legible solo para quienes poseen la clave; no garantiza el anonimato, y un destinatario siempre puede filtrar el texto plano después de descifrarlo.

En ambos sistemas, la privacidad es una propiedad de todo el flujo de trabajo, no solo del formato de la prueba.

¿Se pueden usar los dos a la vez?

Sí, y para registros de alto riesgo puede merecer la pena. Para obtener dos rutas de tiempo públicas e independientes, ancla el mismo manifiesto con ambos:

  1. Crea tu manifiesto de versión, conjunto de datos, medios o pruebas.
  2. Calcula el hash del manifiesto.
  3. Crea una prueba de OpenTimestamps para el hash o el archivo.
  4. Publica una prueba Label 309 para el mismo manifiesto, o para una raíz de Merkle que lo contenga.
  5. Conserva ambas referencias de prueba junto a las pruebas originales.

Eso te da una ruta orientada a Bitcoin y otra nativa de Cardano y estructurada con Label 309. Usa ambas cuando la redundancia adicional compense la carga operativa; para la mayoría del trabajo, con una basta.

¿Cuándo deberías elegir OpenTimestamps?

Elige OpenTimestamps cuando el trabajo sea sellar en el tiempo a secas y una prueba anclada en Bitcoin sea exactamente lo que quieres. Encaja bien para:

  • sellos de tiempo simples de archivos;
  • flujos de trabajo de sellado de tiempo con Git o PGP;
  • equipos que ya ejecutan y confían en la verificación de Bitcoin;
  • flujos de trabajo que prefieren llevar consigo un archivo de prueba .ots externo;
  • compromisos mínimos que no necesitan un registro en la cadena más rico.

Es deliberadamente enfocado, y ese enfoque es justo el punto.

¿Cuándo deberías elegir Label 309?

Elige Label 309 cuando el propio registro de prueba necesite algo más que un sello de tiempo. Encaja bien para:

  • prueba de existencia nativa de Cardano;
  • registros firmados que vinculan la autoría a la prueba;
  • archivos sellados (cifrados) comprometidos en la cadena;
  • entrega confidencial a destinatarios concretos;
  • agrupación de Merkle para conjuntos grandes o recurrentes;
  • punteros de almacenamiento direccionado por contenido;
  • las rutas web, API, CLI, SDK o de gateway autoalojado de CardanoWall;
  • protocolos de aplicación que quieran un formato de prueba compartido bajo la etiqueta de metadatos 309.

Todo el conjunto es de código abierto en github.com/cardanowall, así que nunca quedas atado a las herramientas de un único proveedor para leer o escribir un registro. Consulta Label 309 es de código abierto y cómo verificar un registro tú mismo.

¿Qué no prueba ninguno de los dos sistemas?

Ninguno prueba por sí solo la verdad, la propiedad, la autoría, la legalidad ni la calidad. OpenTimestamps prueba un compromiso con sello de tiempo. Label 309 prueba un compromiso con sello de tiempo más las capas opcionales que lleve un registro. En cualquier caso, una prueba muestra que esos bytes exactos existían antes de una hora pública; no quién tiene razón, quién es dueño de qué, ni si el contenido es lícito. Las afirmaciones que lo rodean todavía necesitan firmas, contexto de identidad, pruebas del proceso, análisis jurídico y criterio humano. Lo desgranamos en lo que una prueba no demuestra.

La versión corta

OpenTimestamps es un sistema de sellado de tiempo sólido, enfocado y anclado en Bitcoin. Label 309 es un formato de registro de prueba de existencia nativo de Cardano con espacio para firmas, conservación sellada, entrega a destinatarios, almacenamiento direccionado por contenido, agrupación de Merkle y futuras extensiones. Elige aquel cuya forma de prueba se ajuste a la pregunta que realmente necesitas responder, o usa los dos cuando la redundancia merezca la pena.

Si quieres el conjunto de comparaciones más amplio, consulta Prueba de existencia frente a una autoridad de sellado de tiempo y la base de todo: qué es la prueba de existencia.

Para seguir leyendo

proof-of-existenceopentimestampstimestamping