← Todas las entradas

13 min de lectura

Lo que una prueba de existencia no demuestra

Una prueba de existencia demuestra que unos bytes exactos existían antes de una hora pública. Por sí sola no demuestra propiedad, ni verdad, ni autoría, ni quién fue primero, ni legalidad, ni admisibilidad.

Una prueba de existencia demuestra una sola cosa, muy concreta: que estos bytes exactos existían no más tarde de una hora pública. Eso es genuinamente útil, y también es toda la afirmación.

Una prueba válida no demuestra automáticamente que un archivo sea verdadero, original, propiedad de quien lo publica, legalmente utilizable, completo o admisible ante un tribunal. Cada una de esas cosas es una afirmación aparte que necesita sus propias pruebas. La forma más rápida de usar bien una prueba, y de no afirmar de más con ella, es entender exactamente dónde se detiene su garantía.

Este artículo recorre las afirmaciones que la gente suele suponer que cubre un sello de tiempo, dice claramente cuáles cubre y cuáles no, y muestra cómo añadir la capa que falta cuando necesitas más.

¿Qué demuestra realmente una prueba de existencia?

Demuestra un compromiso a nivel de bytes con un momento en el tiempo.

Alguien toma un archivo, un mensaje, un conjunto de datos, una imagen, un vídeo, un archivo comprimido o un manifiesto y calcula su hash criptográfico. Ese hash entra en un registro público con sello de tiempo. Más tarde, cualquiera que tenga los bytes originales vuelve a calcular el hash y lo compara con el registro. Si los dos coinciden, el verificador puede afirmar una sola cosa con seguridad:

Esta secuencia exacta de bytes existía no más tarde de la hora del registro público.

Con CardanoWall y el estándar abierto Label 309, ese registro público son los metadatos de una transacción de Cardano publicados bajo la etiqueta de metadatos 309. Para comprobarlo, el verificador lee la transacción desde un explorador público de Cardano, reconstruye el registro Label 309, valida su estructura y compara el hash (o, en el caso de registros agrupados, una prueba de inclusión de Merkle). Ningún servidor, dominio o cuenta de CardanoWall forma parte de esa comprobación. La prueba se sostiene solo sobre la cadena pública.

Ese compromiso es el cimiento. Todo lo que viene después es una pregunta distinta.

¿Una prueba demuestra que el archivo es verdadero?

No. Una afirmación falsa se puede sellar en el tiempo con la misma facilidad que una verdadera. Una factura falsificada, un informe equivocado, una imagen manipulada: todos ellos tienen su hash, y todos se pueden anclar.

Una prueba de existencia no juzga el contenido. Demuestra que un contenido concreto existía antes de una hora, no que el contenido sea correcto.

Aun así vale mucho. Si un informe se corrige más tarde, la prueba del informe original muestra qué existía antes de la corrección. Si se cuestiona una imagen, la prueba muestra que un archivo concreto existía antes de que empezara la disputa. Pero que la afirmación que hay dentro del archivo sea exacta es algo que viene de otro sitio completamente distinto: las pruebas que la rodean, el proceso de revisión, las fuentes de datos, los testigos, el contexto.

Una prueba fija cuándo y qué bytes. Nunca decide verdadero o falso.

¿Una prueba demuestra la propiedad?

No. Si un archivo es público, cualquiera puede calcular su hash. Poner un sello de tiempo a un PDF, una foto, un vídeo, un archivo fuente o un conjunto de datos públicos no te convierte en su propietario: solo deja constancia de que tenías esos bytes en esa hora.

Un sello de tiempo puede respaldar un relato de propiedad cuando va acompañado de otros hechos:

  • borradores e historial de ediciones;
  • registros firmados;
  • archivos fuente originales;
  • contratos y licencias;
  • registros de empleo o de encargo;
  • historial del repositorio;
  • comunicaciones con colaboradores.

La prueba es material probatorio sobre el momento. No es un título de propiedad y no establece derechos exclusivos.

¿Una prueba demuestra quién creó el archivo?

Por sí sola, no. Una prueba basada solo en el hash dice que unos bytes existían; no dice nada sobre quién los hizo. Si dos personas tienen el mismo archivo, cualquiera de las dos puede publicar el mismo hash.

Los registros Label 309 pueden llevar una firma opcional. Un registro firmado demuestra que una clave criptográfica concreta firmó el cuerpo del registro, lo cual es significativamente más fuerte que un hash a secas, porque ata la prueba a una clave y no a quien resulte que envió la transacción. En el estándar las firmas son siempre opcionales: quien publica y quiere mantenerse agnóstico respecto al emisor simplemente las omite.

Incluso con una firma, importa cómo se formula. Una firma demuestra que la clave firmó el registro. Por sí sola no demuestra quién es la persona real detrás de esa clave. Ese vínculo viene de cómo se estableció la clave: la incorporación, una clave pública publicada, una política de la organización, un contrato, la custodia del dispositivo u otro proceso ajeno a la prueba en sí.

Si quieres una prueba que además lleve autoría, la firmas de forma deliberada y gestionas la clave de firma con cuidado. El recorrido de calcular el hash, firmar, sellar y compartir explica cuándo vale la pena añadir cada uno de esos pasos.

¿Una prueba demuestra que quien publica fue el primero?

Por sí sola, normalmente no. Una prueba puede mostrar que quien publica tenía los bytes antes de cierta hora. No puede mostrar que nadie más los tuviera antes.

Esto importa sobre todo con los datos de entrenamiento de IA, los conjuntos de datos, las obras creativas y los secretos comerciales. Si una empresa pone un sello de tiempo hoy al manifiesto de un conjunto de datos, tiene pruebas sólidas de que el manifiesto existía hoy. Pero si otra parte presenta una prueba más antigua, un historial de repositorio o un registro firmado, la línea temporal se inclina hacia ella.

La lección práctica: publica pronto y de forma constante. Una prueba posterior sigue siendo útil, pero un compromiso público anterior siempre es el más fuerte. Cuanto antes ancles, más difícil será socavar tu línea temporal.

¿Una prueba demuestra que el archivo nunca se cambió?

Demuestra algo más preciso: que un archivo que tienes ahora coincide con los bytes que se comprometieron.

No demuestra que ninguna copia, en ningún lugar, se haya alterado jamás. No protege tu disco local y no impide que alguien edite una versión distinta del archivo. La pregunta de verificación que responde es concreta y acotada:

¿Coincide este archivo con el hash del registro público?

Si la respuesta es sí, el archivo que tienes delante es la secuencia exacta de bytes que se comprometió. Si es no, entonces o bien cambió el archivo, o se aportó el archivo equivocado, o se comprobó el hash equivocado, o el registro corresponde a otros bytes: la discrepancia por sí sola no te dice cuál de esas cosas pasó.

Para cualquier cosa que quizá tengas que defender más adelante, guarda tres cosas juntas: el archivo original, la referencia de transacción y cualquier manifiesto o prueba de inclusión de Merkle. Si el propio archivo original pudiera perderse, ese es exactamente el caso para una prueba sellada.

¿Una prueba conserva el archivo por ti?

Una prueba basada solo en el hash, no. Si publicas únicamente un hash y más tarde pierdes los bytes originales, puede que sigas teniendo pruebas de que alguna secuencia de bytes existió, pero quizá ya no puedas mostrar cuál era esa secuencia.

Por eso Label 309 admite registros sellados. Una prueba sellada se compromete con el hash del texto plano y almacena el texto cifrado en una ubicación direccionada por contenido, identificada con un URI ar:// (Arweave) o ipfs:// (IPFS). Quien tenga la clave adecuada podrá más tarde recuperar el texto cifrado, descifrarlo, recalcular el hash del texto plano y confirmar que coincide con el compromiso en la cadena, recuperando así tanto los bytes como la prueba que los ata a una hora.

El hash a secas basta cuando vas a conservar tú mismo el archivo. Sellar es la mejor opción cuando la recuperación, o la entrega a otra persona, forma parte del plan.

¿Una prueba demuestra legalidad o cumplimiento?

No. Una empresa puede sellar en el tiempo datos recopilados de forma indebida. Un creador puede sellar en el tiempo contenido que no tiene derecho a distribuir. Un equipo puede sellar en el tiempo un registro de cumplimiento que está incompleto. Un proveedor puede sellar en el tiempo el manifiesto de una versión de software que aún se publica con vulnerabilidades.

Una prueba de existencia puede respaldar un esfuerzo de cumplimiento al hacer que los registros sean a prueba de manipulaciones y queden anclados en el tiempo. No puede sustituir al programa de cumplimiento en sí.

El cumplimiento real viene de las políticas, los controles, la recopilación lícita de datos, los registros de acceso, las reglas de retención, las revisiones, las aprobaciones y, a veces, auditorías externas. Una prueba ayuda a mostrar qué existía y cuándo. No certifica que el proceso subyacente fuera correcto. Si estás anclando rastros de auditoría, registros de cumplimiento sin confiar en el proveedor trata exactamente de esa frontera.

¿Una prueba establece la cadena de custodia?

No. La cadena de custodia es un relato de proceso: quién recopiló un elemento, dónde se almacenó, quién accedió a él, cómo se movió, qué herramientas lo tocaron y qué controles impidieron su manipulación por el camino.

Una prueba Label 309 puede ser una pieza de ese relato. Puede mostrar que un archivo, una exportación, un registro o un manifiesto de pruebas existía antes de una hora pública y sigue coincidiendo después. No puede nombrar a cada custodio ni explicar cada paso de manipulación, salvo que esos hechos estén ellos mismos registrados —e idealmente comprometidos— en otra parte.

Para los flujos de trabajo con material probatorio, el patrón es poner un sello de tiempo al manifiesto y conservar los registros del proceso circundante a los que la prueba remite.

¿Una prueba garantiza la privacidad?

No, y vale la pena ser específico sobre los límites.

Un registro basado solo en el hash no revela el archivo original en condiciones normales, pero aun así da a conocer que alguien comprometió algo en cierta hora. Y si el archivo es de baja entropía o adivinable, un atacante puede calcular el hash de candidatos probables y comparar cada uno con el registro hasta que aparezca una coincidencia.

Un registro sellado va más allá: el texto plano nunca llega a la cadena en claro —solo lo hacen su hash y un sobre sellado que oculta al destinatario, manteniendo el texto cifrado fuera de la cadena— y Label 309 está diseñado de forma deliberada para que las claves públicas de los destinatarios no aparezcan nunca en el registro. Pero la privacidad es algo más grande que el formato del registro. El momento, el pago de la comisión, los registros del gateway, las direcciones IP, el comportamiento del navegador, el acceso al almacenamiento, los nombres de archivo que viven fuera de la carga cifrada y los errores operativos de siempre pueden filtrar, cada uno, información que la criptografía nunca toca.

Los flujos de trabajo sensibles necesitan seguridad operativa en torno a la prueba, no solo cifrado. Cuando el objetivo es revelar algo a una parte concreta sin exponer nada en público, divulgación confidencial sin archivos públicos cubre el enfoque.

¿Una prueba garantiza el anonimato?

No. Un registro Label 309 sellado y sin firmar puede evitar meter la identidad de un remitente o una lista de destinatarios legible en el propio registro de la prueba: las ranuras que llevan las claves envueltas revelan cuántos destinatarios hay, nunca quiénes. Es una propiedad real y útil. No hace anónimo el proceso de publicación que la rodea.

La transacción de Cardano sigue teniendo entradas y paga una comisión. Un gateway alojado puede ver detalles de cuenta, de pago, de red o de tiempo. Recuperar el texto cifrado del almacenamiento puede dejar rastros. Un usuario puede reutilizar una dirección o revelar contexto en otro lugar.

Así que la afirmación honesta es acotada: el formato del registro puede omitir los campos legibles de remitente y destinatario. El anonimato pleno depende de todo el montaje operativo, no solo de los bytes, una distinción que importa sobre todo en las pruebas de un denunciante y en otros casos de alto riesgo similares.

No. Los tribunales, los reguladores, los árbitros y las contrapartes deciden cada uno qué pruebas aceptan según las reglas que les aplican. Una prueba criptográfica puede ser un material probatorio persuasivo de la integridad y del momento, pero no es un salvoconducto legal universal.

En algunas jurisdicciones o contratos puede exigirse un sello de tiempo cualificado, un notario, un servicio de confianza regulado o un método de firma concreto. En otras, una prueba sobre una blockchain pública puede tener peso real como parte de un paquete de pruebas más amplio. Cuál de las dos cosas aplica depende de la jurisdicción y del asunto.

Recurre a un abogado cuando una prueba vaya a tener importancia legal. Una prueba puede ayudar a establecer el momento y la integridad; no sustituye al asesoramiento jurídico, y este artículo no es asesoramiento jurídico. El papel práctico que una prueba de existencia suele desempeñar en las disputas se expone en prueba legal y e-discovery.

¿Cómo se hace más fuerte una prueba?

Añades la capa que se corresponde con la afirmación que realmente necesitas, y solo esa capa.

  • Si necesitas el momento. Publica un hash, o una raíz de Merkle para muchos archivos a la vez.
  • Si necesitas autoría o aprobación. Firma el registro Label 309 y gestiona la clave de firma como es debido.
  • Si necesitas recuperar los bytes. Sella el archivo y almacena el texto cifrado.
  • Si necesitas entrega confidencial. Cifra el archivo para la dirección de recepción del destinatario.
  • Si necesitas pruebas en gran volumen. Comprométete con una única raíz de Merkle y conserva la lista de hojas y las pruebas de inclusión; un solo anclaje puede valer por miles de archivos, como se explica en un registro para miles de archivos.
  • Si necesitas peso legal. Combina la prueba con políticas, contratos, servicios cualificados donde tu jurisdicción los exija y una cadena de custodia documentada.

Cada capa responde a una pregunta distinta. Apilarlas es la forma de que un simple sello de tiempo se convierta en una prueba que lleva exactamente la afirmación que pretendes.

La versión corta

Una prueba es más fuerte cuando dice solo lo que realmente puede demostrar.

Label 309 demuestra la existencia a nivel de bytes antes de una hora pública de Cardano. Sobre eso puede añadir firmas de autoría, conservación sellada, entrega confidencial y agrupación de Merkle. No sustituye a la verdad, ni a la propiedad, ni a la ley, ni a la identidad, ni a la seguridad operativa, ni al proceso, y no pretende hacerlo.

Esa honestidad no es una debilidad del diseño. Es lo que hace que la prueba sea fiable: siempre sabes exactamente qué respalda, y exactamente qué deja en manos del resto de tus pruebas.

Más lecturas

proof-of-existencetrustlabel-309