¿Qué es la prueba de existencia?

La prueba de existencia es una forma de demostrar que unos datos exactos existían a más tardar en un momento determinado, usando un sello de tiempo público que cualquiera puede comprobar.

El método es sencillo. Calcula el hash de los datos, publica ese hash en un registro público con sello de tiempo y, más adelante, deja que cualquiera que tenga los datos originales recalcule el hash y lo compare con el registro. Si los dos hashes coinciden, el verificador sabe que esos mismos bytes existían a más tardar en el momento de ese registro. No necesita confiar en ti, en tu servidor ni en tu cuenta: solo en el registro público y en las matemáticas.

El archivo en sí nunca tiene por qué ser público. La prueba puede ser pública mientras el contenido permanece privado.

¿Qué demuestra la prueba de existencia?

Demuestra una afirmación limitada pero útil:

Estos bytes exactos existían a más tardar en este momento público.

Eso es todo lo que afirma la prueba básica, y su fuerza nace precisamente de lo concreta que es.

Casi cualquier cosa puede reducirse a un hash criptográfico: un documento, una imagen, un vídeo, un conjunto de datos, un archivo de código fuente, un artefacto de compilación, un contrato, un fichero de registro, la salida de un modelo o un manifiesto. El hash es una huella corta de una secuencia exacta de bytes. Cambia un solo byte y la huella cambia por completo.

Cuando ese hash se ancla en un registro público, el registro se convierte en un testigo del tiempo. Más adelante, si le muestras a alguien el archivo original, vuelve a calcular su hash. Si el nuevo hash coincide con el registrado, esa persona puede confirmar que el archivo que tiene delante son los mismos datos que se fijaron antes, en el momento del registro o antes de él.

Eso hace que la prueba de existencia sea valiosa siempre que el momento importa:

• demostrar que un archivo existía antes de un litigio;
• demostrar que un informe existía antes del plazo de una auditoría;
• demostrar que un artefacto de software existía en el momento de la publicación;
• demostrar que la instantánea de un conjunto de datos existía antes de modificarse;
• demostrar que la salida de una IA, un conjunto de prompts o un archivo de medios existía antes de que se cuestionara.

La prueba no es una descripción del archivo. Es un compromiso criptográfico con sus bytes exactos.

¿Por qué no hace falta que el archivo sea público?

Porque lo que se hace público es el hash, no el archivo.

Una buena función de hash funciona como una huella de un solo sentido. Cualquiera puede calcular el hash a partir del archivo, pero quien solo ve el hash no puede reconstruir el archivo a partir de él. Por eso un documento privado puede llevar una prueba pública: el registro dice «alguien se comprometió con estos bytes exactos en este momento» sin revelar los bytes.

Por ejemplo, una empresa puede calcular el hash del manifiesto de un conjunto de datos confidencial y publicar solo el hash. El conjunto de datos sigue siendo privado. Más adelante, si la empresa necesita demostrar qué contenía la instantánea, puede revelar el manifiesto completo, un subconjunto o una prueba de inclusión de un único elemento, lo que mejor se ajuste a la situación.

Esto también explica por qué la prueba de existencia encaja con los equipos jurídicos, de cumplimiento y de seguridad: crea un sello de tiempo externo sin meter pruebas privadas en una base de datos pública. Para verlo más de cerca, consulta divulgación confidencial sin archivos públicos.

¿Qué papel juega la blockchain?

La blockchain es el testigo público del tiempo: la parte que nadie, ni siquiera quien publica, puede reescribir a escondidas.

Si un hash vive solo en tu propia base de datos, la prueba depende por completo de tu sistema. Cuando más adelante se cuestione el sello de tiempo, cualquiera puede preguntar con razón si la base de datos se reescribió, se restauró desde una copia de seguridad, la editó un administrador o se retrodató. Una blockchain pública elimina esa duda. Una vez que una transacción se confirma, el registro con sello de tiempo queda visible para cualquiera y deja de estar bajo el control exclusivo de quien lo publicó.

En CardanoWall, el registro de la prueba se ancla en los metadatos de la transacción de Cardano bajo la etiqueta de metadatos 309. Un verificador obtiene la transacción del explorador público de Cardano que prefiera, lee el registro y comprueba el hash del contenido contra los bytes originales. Ningún servidor de CardanoWall interviene en esa comprobación: el sentido mismo de todo esto es que la prueba se sostiene sin nosotros.

La blockchain no entiende tu documento, y no le hace falta. Registra los datos de la prueba; el significado lo aporta un verificador que recalcula el hash y confirma que los bytes coinciden.

¿Cuál es la prueba más simple?

La prueba más simple es la que usa solo el hash.

Eliges un archivo. El software calcula un hash, por ejemplo SHA-256 o BLAKE2b-256. Ese hash entra en un registro publicado en los metadatos de Cardano. Más adelante, un verificador repite el cálculo del hash sobre el archivo original y, si el digest coincide, la prueba pasa.

Así, el primer nivel se reduce a tres hechos:

1. El contenido existe.
2. Su hash está anclado en la cadena.
3. Cualquiera que tenga el contenido original puede verificar la coincidencia.

Para muchos usos, con eso basta. Un hash con sello de tiempo es potente precisamente porque es simple: hay poco que configurar mal y nada en lo que confiar.

¿Cuándo no basta con un hash?

Un hash a secas responde bien a una pregunta, pero no a todas.

No dice quién creó el archivo. Solo muestra que los bytes existían. Si dos personas tienen el mismo PDF público, cualquiera de ellas puede publicar un hash de él; el hash por sí solo no dice nada sobre la autoría.

No conserva el archivo. Si pierdes los bytes originales, sigues teniendo un hash público, pero quizá no te quede nada con lo que cotejarlo.

Y no entrega el archivo a nadie. Si otra persona necesita los datos originales, un hash a secas no se los va a dar.

Por eso el formato de registro subyacente está organizado en capas. Un registro con solo el hash es totalmente válido, pero el estándar también admite firmas, cargas selladas (cifradas), entrega dirigida a un destinatario y agrupación de Merkle, cada una de las cuales añade una capacidad sobre el sello de tiempo.

¿Cómo cambia la prueba una firma?

Una firma añade una afirmación respaldada por una clave.

Un registro firmado dice más que «estos bytes existían a más tardar en este momento». También puede decir «esta clave firmó este registro». Eso importa para la autoría, las aprobaciones, los controles internos y los flujos de trabajo de negocio: una organización puede usar una clave de firma para mostrar que un sistema, equipo o identidad concretos respaldaron un registro, y un creador puede firmar una prueba para asociar su identidad con una obra.

Aun así, la formulación tiene que seguir siendo precisa. Una firma muestra que la clave firmó el registro, no quién, en el mundo real, posee esa clave. Vincular una clave a una persona depende de un contexto que se establece fuera del registro. (CardanoWall mantiene las firmas opcionales por diseño; cualquiera puede publicar, y los verificadores nunca tienen que confiar en quien publica.)

¿Cómo cambia la prueba el sellado?

Una prueba sellada añade conservación cifrada.

En un registro sellado, la prueba en la cadena sigue comprometiéndose con el hash del texto plano. Pero el archivo en sí puede cifrarse y almacenarse en una ubicación direccionada por contenido —una dirección ar:// (Arweave) o ipfs://— y dejar en el registro solo su referencia. La cadena nunca ve el texto plano.

Esto importa cuando perder el archivo original dificultaría el uso del hash. Con una prueba sellada, quien tenga la clave adecuada puede más adelante obtener el texto cifrado almacenado, descifrarlo, recalcular el hash del texto plano y confirmar que el archivo descifrado es exactamente el contenido comprometido en la cadena. Como la dirección de almacenamiento se deriva de los propios bytes, el destinatario también puede saber que un gateway de almacenamiento devolvió los bytes correctos sin confiar en ese gateway.

La cadena pública nunca tiene que exponer el texto plano. La carga cifrada viaja con la prueba, mientras que la clave de descifrado se queda con quien deba tenerla.

¿Cómo cambia la prueba la entrega a un destinatario?

La entrega a un destinatario permite cifrar un registro sellado para otra persona.

Si conoces la dirección de recepción de un destinatario (una clave pública que ha compartido), puedes publicar un registro sellado que solo esa persona pueda abrir con su propia clave. Es notable que el registro no lleva ningún campo que diga «esto es para Alicia». En la cadena no hay ningún destinatario en absoluto. El software del destinatario escanea los registros públicos e intenta descifrar de forma silenciosa los que podrían estar dirigidos a sus claves, y abre solo los que realmente lo están.

Eso convierte la prueba de existencia en algo más que un sello de tiempo personal. Puede servir para la divulgación confidencial, el intercambio de pruebas legales, los paquetes de cumplimiento privados y los traspasos de auditoría interna: flujos de trabajo en los que la línea de tiempo debe ser pública, pero el contenido no. Sin embargo, antes de sellar algo para alguien, conviene confirmar que la clave le pertenece de verdad; consulta verifica a un destinatario antes de sellar un archivo.

Un límite honesto: el cifrado protege los bytes, no a las personas. El sellado mantiene el texto plano legible solo para quienes tengan la clave, pero no garantiza el anonimato, y un destinatario siempre puede filtrar el texto plano una vez que lo ha descifrado.

¿Cómo cambia la prueba la agrupación de Merkle?

La agrupación de Merkle permite que un solo registro se comprometa con muchos elementos a la vez.

En lugar de una transacción por archivo, un sistema puede calcular el hash de miles o millones de elementos, plegar esos hashes en un árbol de Merkle y publicar una única raíz de 32 bytes. Más adelante, una prueba de inclusión muestra que un elemento concreto formaba parte del lote comprometido. El verificador no necesita todos los archivos en la cadena: la raíz es el compromiso público, y una prueba de inclusión corta —que crece solo con el logaritmo del tamaño del lote— enlaza un elemento individual con esa raíz. Todos los demás elementos del lote siguen siendo privados.

Esto encaja con los flujos de trabajo de alto volumen:

• artefactos de CI/CD y manifiestos de publicación;
• registros de cumplimiento diarios;
• contenido generado por IA a gran escala;
• instantáneas de conjuntos de datos;
• carpetas de pruebas de auditoría;
• archivos de medios y publicaciones.

El modo Merkle mantiene minúsculo el registro en la cadena y deja que una sola prueba cubra un conjunto enorme de elementos. Para un ejemplo trabajado, consulta un registro para miles de archivos.

¿Qué no demuestra la prueba de existencia?

Esta es la sección que mantiene la prueba honesta. Un compromiso con sello de tiempo es fuerte porque es concreto, y ser concreto significa que hay afirmaciones que sencillamente no hace.

No demuestra que un documento sea verdadero. Un documento falso puede sellarse en el tiempo con la misma facilidad que uno verdadero.

No demuestra la propiedad. Cualquiera puede calcular el hash de un archivo que no le pertenece.

No demuestra la autoría por sí sola. La autoría necesita firmas, gestión de claves y contexto del mundo real superpuestos.

No demuestra que una compilación de software sea segura. Puede mostrar qué artefacto, SBOM, registro o manifiesto existía en un momento dado, pero la seguridad depende del proceso de compilación y de los controles que lo rodean.

No demuestra que un conjunto de datos se recopilara o usara de forma lícita. Puede mostrar que existía un compromiso con un conjunto de datos —lo que puede ser una prueba importante—, pero los derechos legales son una cuestión aparte que depende de tu jurisdicción y de tu asesor.

En resumen: la prueba de existencia te aporta cronología e integridad, no verdad ni derechos. Cualquier afirmación adicional tiene que construirse con cuidado sobre esa base. Lo que una prueba no demuestra profundiza en dónde está exactamente la línea.

Por qué CardanoWall se construye sobre Label 309

Una prueba solo es tan útil como portable sea. Una que solo funciona dentro de un único sitio web no es gran prueba: una seria debería poder leerse con herramientas independientes, verificarse desde infraestructura pública y entenderse con software que el servicio original nunca escribió.

Por eso CardanoWall se construye sobre Label 309, un estándar abierto y neutral respecto al proveedor para la prueba de existencia en Cardano. Label 309 —no la aplicación CardanoWall— es el artefacto duradero; la aplicación web, la herramienta de línea de comandos y los SDK son implementaciones de referencia derivadas de él. El estándar define un formato de registro que escala desde un sello de tiempo a secas hacia arriba:

• pruebas con solo el hash para la existencia simple;
• pruebas firmadas para afirmaciones de autoría respaldadas por una clave;
• pruebas selladas para la conservación cifrada;
• pruebas selladas para un destinatario, para la entrega privada;
• pruebas de Merkle para lotes de alto volumen;
• identificadores de algoritmo con nombre, para que la criptografía pueda evolucionar con el tiempo sin romper los registros más antiguos.

El formato también se está sometiendo a revisión pública: la prueba de existencia bajo la etiqueta de metadatos 309 se ha presentado al proceso CIP de Cardano y los editores de CIP la están revisando como propuesta de la categoría Metadata. (La etiqueta de metadatos 309 es el identificador en la cadena; el número de CIP lo asigna el proceso por separado.) El estándar completo, sus implementaciones de referencia y todo el código abierto están disponibles públicamente en github.com/cardanowall bajo licencias permisivas.

CardanoWall es la interfaz. Label 309 es el formato de registro. La prueba está diseñada para sobrevivir a ambos: a la interfaz y a la empresa que te ayudó a publicarla.

Para seguir leyendo

• Cómo funciona Label 309: el estándar que hay detrás de cada prueba de CardanoWall.
• Qué va a la blockchain: exactamente qué bytes se publican y cuáles nunca salen de tu dispositivo.
• Verifica un registro Label 309: cómo comprobar una prueba por tu cuenta, solo desde infraestructura pública.
• Cómo se compara la prueba de existencia con otros sistemas de sellado de tiempo y de procedencia: frente a OpenTimestamps, frente a una autoridad de sellado de tiempo y frente a C2PA / Content Credentials.