¿Qué es la prueba de existencia para el código de software?

Para los desarrolladores y los equipos de cumplimiento, la “prueba de existencia” no consiste en demostrar la propiedad ni la autoría. Responde a una única pregunta concreta: ¿existió este código exacto en este momento concreto? En un mundo donde el historial de Git puede reescribirse, las marcas de tiempo de los archivos pueden modificarse y los registros internos suelen descartarse por considerarse interesados, la prueba de existencia para el código de software significa anclar una huella criptográfica de tu trabajo en un libro mayor público e inmutable.

Este artículo explica qué significa la prueba de existencia, cómo funciona internamente y cómo Timestamp GIT la convierte en un flujo de trabajo de GitHub sin configuración.

¿Qué significa “prueba de existencia” para el código?

La prueba de existencia para el código de software es la capacidad de demostrar que una pieza específica de código —o, más precisamente, un hash criptográfico de ese código— existió en un momento específico.

Ese último punto es importante. No necesitas publicar tu código fuente ni subirlo a un tercero. En su lugar, creas una huella unidireccional del estado del repositorio y registras esa huella en algún lugar público y resistente a manipulaciones.

Para entender la diferencia:

• La prueba de existencia demuestra que un estado de código determinado existió en una fecha determinada.
• La prueba de autoría demuestra quién creó o confirmó ese código.
• La prueba de propiedad es una conclusión jurídica basada en la autoría, los contratos laborales, las cesiones u otras pruebas.

Una marca de tiempo anclada a una cadena de bloques no demuestra que escribiste el código. Demuestra que el código existió en ese momento. En muchas disputas, esa distinción es suficiente, porque si tu implementación existió antes de la solicitud de patente o la reclamación de otra persona, la línea temporal queda matemáticamente anclada.

Así es como se ve la huella en Git:

# Git crea una huella única para el estado exacto del repositorio
git rev-parse HEAD
# 6f1ed002ab5595859012f3f9b6b4c2b1e1c9a2e5

Ese hash representa el estado completo del repositorio en el momento del commit. Cambia un solo byte y el hash cambia por completo. El hash en sí no puede invertirse para revelar tu código fuente.

Una analogía sencilla: el notario y la caja fuerte

Imagina que entras en una notaría con un sobre sellado. El notario no lo abre. En su lugar, registra la fecha, estampa un sello en el exterior y firma una entrada en el libro de actas. Años después, puedes abrir el sobre ante un tribunal y demostrar que el contenido existía en esa fecha porque el registro del notario es independiente y evidencia cualquier manipulación.

La prueba de existencia para el software funciona igual, salvo que el “sobre” es un hash criptográfico y el “notario” es la cadena de bloques de Bitcoin.

• Mantienes el código en privado. El notario —en este caso, el servicio de sellado de tiempo y el libro mayor público— solo ve la huella.
• El registro es independiente. La cadena de bloques de Bitcoin es un libro mayor público que ningún proveedor controla. Una vez que una transacción se confirma en un bloque, alterar ese registro es computacionalmente impracticable.
• La evidencia sobrevive al proveedor. Como la prueba está anclada en Bitcoin, puedes verificarla incluso si el servicio de sellado de tiempo desaparece.

Esta analogía ayuda a las partes interesadas no técnicas a entender por qué una marca de tiempo en la cadena de bloques es diferente de un registro interno de Git. Un registro interno vive en una infraestructura que controlas o alquilas. Una prueba anclada a Bitcoin es pública, inmutable y verificable de forma independiente.

Cómo funciona la prueba de existencia internamente

El proceso puede dividirse en tres pasos.

Paso 1: Huella

Git ya hace el primer paso por ti. Cada commit recibe un hash único —SHA-1 en versiones antiguas de Git, con soporte SHA-256 en repositorios más nuevos— que cubre el estado completo del repositorio en ese punto.

Este hash no es tu código. Es un resumen matemático de tamaño fijo. No puedes reconstruir el código fuente a partir de él, y el mismo estado de código siempre produce el mismo hash.

Paso 2: Anclaje

El siguiente paso es anclar el hash en un libro mayor público. Timestamp GIT recopila los hashes de los commits y los agrupa en archivos de manifiesto diarios. Construye un árbol de Merkle a partir de esos hashes y crea pruebas OpenTimestamps. La raíz de Merkle se ancla entonces en una transacción de Bitcoin.

Una vez que esa transacción se confirma en un bloque de Bitcoin, la marca de tiempo se vuelve inmutable. No hay botón de borrar, ni anulación administrativa, ni base de datos propietaria que pueda editarse después.

El flujo es el siguiente:

hash del commit -> manifiesto diario -> árbol de Merkle -> transacción de Bitcoin -> recibo .ots

Paso 3: Prueba

El resultado es un recibo criptográfico, normalmente un archivo .ots. Ese recibo permite a cualquiera verificar la marca de tiempo contra la cadena de bloques de Bitcoin utilizando las herramientas estándar de OpenTimestamps.

Esto es importante: la prueba se basa en SHA-256 y en los datos de los bloques de Bitcoin. No hay dependencia del formato o la infraestructura de un único proveedor. Incluso si el proveedor SaaS dejara de existir, la prueba seguiría siendo verificable.

Hacer esto manualmente con las herramientas básicas de OpenTimestamps es posible, pero implica lidiar con calendarios, árboles de Merkle y la supervisión de las confirmaciones de Bitcoin por tu cuenta. Esa complejidad manual es exactamente lo que Timestamp GIT elimina al automatizar el proceso detrás de una GitHub App.

Por qué la prueba de existencia es importante para desarrolladores y cumplimiento

La prueba de existencia importa porque el tiempo suele ser la cuestión central en las disputas de propiedad intelectual.

• Trolls de patentes: Una defensa común contra una patente de software amplia es el estado de la técnica. Si puedes demostrar que tu código existía antes de la fecha de presentación, la reivindicación de la patente puede ser inválida. La prueba de existencia convierte tu repositorio privado en un registro de estado de la técnica fechado y verificable. Para más detalles, consulta Cómo demostrar que tu código existía antes de una solicitud de patente.
• Disputas con empleados y clientes: Cuando un desarrollador se va, o un cliente cuestiona cuándo se completó un hito, un hash de commit con marca de tiempo es más sólido que un historial de chat exportado o un historial de Git editado.
• Cumplimiento y gobernanza: Los equipos que necesitan pistas de auditoría para revisiones de seguridad, diligencia debida o gobernanza interna pueden mostrar un registro regular y verificable de cuándo existieron los estados del código.

También hay conceptos erróneos comunes que conviene aclarar.

• No es un registro de derechos de autor. Una marca de tiempo en la cadena de bloques no sustituye el registro de derechos de autor y, por sí sola, no demuestra la autoría.
• No demuestra quién escribió el código. Demuestra que un hash determinado existió en un momento determinado. La autoría sigue necesitando registros laborales, metadatos de commits u otras pruebas.
• No es “solo un registro interno”. El historial de Git puede reescribirse, forzarse con push o perderse. Una prueba anclada a Bitcoin es externa, pública y verificable matemáticamente.

Cómo Timestamp GIT hace que la prueba de existencia sea sencilla

Timestamp GIT es un SaaS gestionado y una GitHub App que automatiza todo el proceso de prueba de existencia. No necesitas ejecutar comandos de OpenTimestamps, gestionar calendarios ni interactuar directamente con Bitcoin.

El flujo de trabajo principal es:

1. Instala la GitHub App una vez.
2. Selecciona los repositorios que quieres supervisar.
3. Sigue haciendo commits con normalidad.

Cada noche, Timestamp GIT agrupa automáticamente los hashes de commits pendientes, construye un árbol de Merkle, crea pruebas OpenTimestamps y ancla la raíz de Merkle en la cadena de bloques de Bitcoin. Tras la confirmación de Bitcoin —normalmente en unas tres horas—, los archivos de manifiesto y los recibos .ots se envían a una rama de marcas de tiempo dedicada o a un repositorio espejo.

Características clave:

• Conocimiento cero por diseño. Timestamp GIT nunca ve, copia ni almacena tu código fuente. Solo procesa los hashes de los commits.
• Sin pasos manuales. No hay herramientas CLI que instalar en las máquinas de los desarrolladores ni transacciones de Bitcoin en bruto que crear.
• Despliegue flexible. El modo estándar utiliza la GitHub App y requiere acceso de lectura al repositorio de origen y acceso de lectura y escritura al repositorio de destino. El modo Enterprise ZK utiliza una GitHub Action en tu infraestructura para enviar solo el hash del commit a la API de Timestamp GIT, de modo que el servicio no necesita ningún acceso de lectura al repositorio de origen.
• Verificación pública. Puedes incrustar insignias de estado en tu README, consultar la página de estado pública, descargar CSV de auditoría o generar certificados PDF.
• Independencia del proveedor. El recibo .ots puede verificarse sin conexión con las herramientas estándar de OpenTimestamps, incluso si Timestamp GIT deja de funcionar.

Para entornos autoalojados o aislados, hay disponible una imagen de Docker:

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

También puedes consultar directamente los endpoints de estado público, por ejemplo:

curl https://timestampgit.dev/api/statusLast/your-org/your-repo

Ese endpoint devuelve información sobre el último bloque de Bitcoin anclado para un repositorio supervisado.

Preguntas frecuentes

¿La prueba de existencia está reconocida legalmente?

Las marcas de tiempo criptográficas se aceptan cada vez más en los tribunales como evidencia de estado de la técnica. Proporcionan un registro sólido y resistente a manipulaciones que puede verificarse de forma independiente. Sin embargo, el reconocimiento legal varía según la jurisdicción, y es recomendable consultar a un abogado para casos específicos.

¿La prueba de existencia revela mi código fuente?

No. La prueba de existencia utiliza hashes criptográficos, que son funciones unidireccionales. El código fuente real nunca se transmite ni se almacena. Solo el hash se ancla a la cadena de bloques, por lo que tu código permanece privado.

¿Cuánto cuesta poner una marca de tiempo a mi código?

Timestamp GIT ofrece un plan gratuito para repositorios públicos. Los planes de pago empiezan en 49 $/mes para repositorios privados, con un plan Enterprise ZK de 199 $/mes. También hay licencias Docker autoalojadas disponibles.

¿Puedo verificar la marca de tiempo sin depender de Timestamp GIT?

Sí. Las pruebas se basan en el protocolo OpenTimestamps y en la cadena de bloques de Bitcoin. Puedes descargar el recibo .ots y verificarlo con las herramientas estándar de OpenTimestamps, incluso si Timestamp GIT deja de existir.

Conclusión

La prueba de existencia para el código de software es una de las pocas herramientas para desarrolladores que es a la vez barata, matemáticamente rigurosa y útil tanto en contextos legales como de cumplimiento. No demuestra la autoría ni la propiedad, pero crea un punto fijo en el tiempo que es extremadamente difícil de rebatir.

La forma difícil es ejecutar el protocolo OpenTimestamps manualmente. La forma práctica es instalar la GitHub App de Timestamp GIT, conectar tus repositorios y dejar que el proceso de anclaje nocturno haga el resto. Empieza a poner marcas de tiempo a tus commits en Timestamp GIT.

Publicaciones relacionadas

• Cómo demostrar que tu código existía antes de una solicitud de patente
• Pon marcas de tiempo a los commits de Git para defenderte de los trolls de patentes
• Automatiza el sellado de tiempo del código con una GitHub App