2026-10-06 timestamp git blockchain proof

Como Verificar o Carimbo de Tempo Bitcoin de um Repositório Git

Você tem um recibo .ots no seu repositório. Agora alguém — um advogado, um auditor, um adquirente fazendo due diligence técnica — faz a única pergunta que importa: como sabemos que isso é real?

Essa pergunta é o cerne da prior art criptográfica. Um carimbo de tempo que você não pode verificar de forma independente é apenas uma afirmação em um banco de dados. Um carimbo de tempo que qualquer pessoa pode verificar na blockchain do Bitcoin é evidência. Este artigo percorre o caminho de verificação para repositórios ancorados pelo Timestamp GIT, desde o selo no README até a prova de Merkle.

Por que a Verificação Importa para Carimbos de Tempo Git

O histórico do Git é surpreendentemente fácil de contestar. As datas de commit são definidas pela máquina que fez o commit, então podem ser retroativas com uma única variável de ambiente. O histórico hospedado vive em servidores que você não controla, e o histórico auto-hospedado vive em um banco de dados que alguém com direitos de administrador pode reescrever. Em uma auditoria legal, ambos são rotineiramente descartados como parciais.

A ancoragem criptográfica fecha essa lacuna — mas apenas se a prova puder ser verificada por um terceiro que não confia nem em você nem no fornecedor. Isso significa dois requisitos:

A verificação não deve exigir confiar no Timestamp GIT. A prova é uma cadeia de hashes SHA-256 que termina em um bloco do Bitcoin. Qualquer pessoa pode percorrer essa cadeia com ferramentas de código aberto.
A verificação não deve exigir expor seu código-fonte. O Timestamp GIT opera em um modelo de conhecimento zero: o serviço recebe hashes de commit, nunca o conteúdo dos arquivos. Não há nada para inspecionar além de hashes — que é exatamente o que um auditor quer, pois significa que a prova pode ser compartilhada sem compartilhar o código-fonte.

Por causa desse design, a verificação é um exercício criptográfico, não uma revisão de código. Auditores, advogados da parte contrária ou a equipe de engenharia de uma empresa adquirente podem todos validar o mesmo recibo e chegar à mesma conclusão.

Como é uma Prova do Timestamp GIT

Após a execução noturna de ancoragem, cada repositório monitorado recebe três artefatos:

Um manifesto diário (.txt) — a lista de hashes de commit agrupados naquele dia, um arquivo por repositório.
Uma raiz de Merkle — o único hash SHA-256 calculado a partir desse manifesto. Todos os hashes individuais se reduzem a um único valor.
Um recibo .ots — a prova OpenTimestamps que vincula a raiz de Merkle a um bloco específico do Bitcoin.

Esses artefatos são enviados de volta ao seu repositório em um branch dedicado de carimbos de tempo, ou em um repositório sombra separado, se você preferir manter o repositório de origem limpo. De qualquer forma, as provas são versionadas junto com o código que atestam, mas em sua própria ref — nada é jamais commitado nos seus branches de trabalho.

Duas coisas merecem ser ditas claramente:

A prova não contém nenhum código-fonte. Apenas hashes de commit e suas reduções criptográficas.
A prova não é proprietária. É um recibo OpenTimestamps padrão sobre uma transação Bitcoin, e permanece válido independentemente de o Timestamp GIT ainda existir.

Assim que o arquivo de recibo estiver no seu repositório, você tem tudo o que precisa para verificar — o resto é ferramenta.

Verificação Passo a Passo Usando as Ferramentas do Timestamp GIT

Passo 1 — Localize a prova

Abra o branch de carimbos de tempo (ou o repositório sombra) e encontre o manifesto para a data em questão, além do arquivo .ots correspondente. Se preferir não vasculhar branches, a página de status do repositório mostra as mesmas informações no navegador:

https://timestampgit.dev/status/{user}/{repo}

Passo 2 — Leia a página de status pública

A página de status é a verificação rápida mais ágil. Ela mostra:

Longevidade da prova e a data de ancoragem mais antiga
Regularidade diária (um mapa de calor em calendário dos dias ancorados)
O bloco e a transação do Bitcoin que carregam a âncora
Links para download do CSV de auditoria e do certificado em PDF

Para verificações automatizadas, os mesmos dados são expostos como JSON:

# Last anchored Bitcoin block
curl -s https://timestampgit.dev/api/statusLast/acme/payments-service

# Total number of stamped commits
curl -s https://timestampgit.dev/api/statusCount/acme/payments-service

# Combined summary (used by the Shields.io badges)
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service

Passo 3 — Verifique uma data específica no navegador

Para prova em nível de dia, use a página de verificação criptográfica:

https://timestampgit.dev/verification/{user}/{repo}/{date}

Esta página realiza a verificação completa da cadeia de Merkle em múltiplos níveis localmente no seu navegador. O hash do commit, o manifesto, o caminho de Merkle e o cabeçalho do bloco do Bitcoin são todos verificados na sua máquina — a página não faz upload do que você está verificando. Essa propriedade importa quando o repositório é privado ou está sob NDA: o auditor pode confirmar a prova sem que o fornecedor saiba qual data lhe interessava.

Passo 4 — Obtenha o livro-razão de auditoria ou o certificado em PDF

Equipes de compliance geralmente precisam de um artefato que possam arquivar. Ambos estão a uma requisição de distância:

# Full audit ledger as CSV
curl -fsSL https://timestampgit.dev/api/audit/acme/payments-service -o audit.csv

# PDF certificate for one day
curl -fsSL https://timestampgit.dev/api/report/acme/payments-service/2026-09-14 -o certificate.pdf

Passo 5 — Opcionalmente, incorpore um selo de verificação

O widget de selo em /connected/{user}/{repo} oferece uma pré-visualização ao vivo e um trecho de Markdown pronto para colar no seu README. Insira-o e qualquer pessoa — um cliente, um investidor, um possível adquirente — pode clicar e acessar a visualização pública de verificação:

<!-- Snippet copied from https://timestampgit.dev/connected/acme/payments-service -->
[![Bitcoin-timestamped](BADGE_IMAGE_URL)](VERIFY_LINK)

Cada passo acima funciona no fluxo de trabalho gerenciado do GitHub App. Você instala o app uma vez, e a verificação é um carregamento de página ou uma requisição HTTP — sem ferramentas de linha de comando, sem manipulação manual de protocolo, nada para manter nas máquinas dos desenvolvedores.

Interpretando Resultados de Verificação e Casos Extremos

Uma verificação bem-sucedida lhe diz algo restrito e poderoso: o hash do commit existia no momento ou antes do carimbo de tempo do bloco do Bitcoin referenciado pelo recibo, e a prova de Merkle vincula esse hash específico àquele bloco. Como os blocos do Bitcoin não podem ser reescritos sem refazer a prova de trabalho, o limite “no momento ou antes” é absoluto.

Algumas situações surgem regularmente:

Nenhuma prova para uma determinada data. Geralmente significa que não houve commits naquele dia — o manifesto é construído a partir de hashes pendentes, então um dia vazio não produz nada para ancorar. Verifique o mapa de calor na página de status para confirmar.
Confirmação pendente. A ancoragem é um processo em duas etapas. O worker cron noturno agrupa os hashes, constrói a árvore de Merkle e envia a raiz para os calendários públicos do OpenTimestamps; a confirmação em um bloco do Bitcoin leva então algumas horas — normalmente cerca de três. Uma prova escrita logo após a meia-noite pode, portanto, não ser final até mais tarde naquela manhã.
Repositórios privados. O acesso às páginas de status e verificação para repositórios privados exige um HMAC criptografado anexado à URL. O HMAC é específico da instância do servidor, então os links não podem ser reproduzidos em outra implantação.
Independência do fornecedor. Se você preferir não usar o verificador hospedado, baixe o arquivo .ots e execute-o com as ferramentas de código aberto do OpenTimestamps contra a blockchain do Bitcoin por conta própria. Esse é o caminho difícil, e é mais lento, mas existe — e sua existência é o que torna o caminho gerenciado crível.

Verificação em Ambientes Empresariais e Auto-Hospedados

Modo Enterprise ZK. Uma GitHub Action de 12 linhas é executada na sua própria infraestrutura e envia apenas hashes de commit para a API do Timestamp GIT. O serviço nunca tem acesso de leitura ao repositório de origem; você só precisa de acesso de leitura e escrita ao repositório de destino que recebe as provas. A verificação permanece inalterada — os mesmos arquivos .ots, os mesmos dados públicos do Bitcoin, as mesmas verificações de Merkle no navegador.

Docker auto-hospedado. Para ambientes isolados (air-gapped), o Timestamp GIT é distribuído como uma imagem Docker que você mesmo executa. Uma configuração rápida de Docker Compose se parece com isto:

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

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

A instância fica disponível em http://localhost:8080, e um assistente de configuração na primeira inicialização orienta você na conexão do seu GitHub App e na configuração da implantação. A verificação funciona inteiramente dentro da sua rede: os arquivos .ots, os manifestos e o verificador local são tudo o que você precisa.

Uma licença de demonstração por tempo limitado para avaliação está disponível enviando o formulário de solicitação na página de licença Docker com seu nome, empresa, e-mail e telefone opcional; o arquivo de licença pode ser baixado imediatamente.

Automatizando a Verificação para Equipes de Compliance

A verificação manual é suficiente para uma auditoria. A conformidade contínua quer isso em um pipeline. A API REST cobre isso:

#!/usr/bin/env bash
set -euo pipefail

REPO="acme/payments-service"
BASE="https://timestampgit.dev/api"

# Merkle chain data for local verification of a specific day
curl -fsSL "$BASE/verify/$REPO/2026-09-14" -o "verify-2026-09-14.json"

# Monthly audit ledger
curl -fsSL "$BASE/audit/$REPO" -o "audit-$REPO.csv"

# PDF certificate per anchored day
curl -fsSL "$BASE/report/$REPO/2026-09-14" -o "certificate-2026-09-14.pdf"

Para dashboards, consulte os endpoints de status em vez do payload completo de verificação:

# Feed /api/statusLast and /api/statusCount into your monitoring system
curl -fsSL "$BASE/statusLast/$REPO"
curl -fsSL "$BASE/statusCount/$REPO"

Um padrão útil é tratar um statusLast desatualizado como condição de alerta: se o último bloco ancorado não se move há mais de um dia para um repositório com commits ativos, algo no pipeline precisa de atenção. Toda a computação de verificação acontece localmente no navegador ou dentro do seu próprio script — nenhum payload sensível sai do seu controle. Se você ainda está configurando o lado da ancoragem disso, veja Carimbo de Tempo Git Automatizado: Como um GitHub App Ancora Cada Commit; este artigo é deliberadamente sobre o que acontece depois.

FAQ

Preciso executar alguma ferramenta de linha de comando para verificar uma prova do Timestamp GIT? Não. O Timestamp GIT fornece uma página de verificação baseada na web que realiza todas as verificações criptográficas localmente no seu navegador. Você também pode baixar o arquivo .ots e usar as ferramentas padrão do OpenTimestamps, se preferir, mas o serviço gerenciado não exige uso de CLI.

Posso verificar um carimbo de tempo sem confiar no Timestamp GIT? Sim. A prova depende exclusivamente de hashes SHA-256 e dados de blocos do Bitcoin. Você pode verificar de forma independente o arquivo .ots contra a blockchain do Bitcoin usando ferramentas de código aberto do OpenTimestamps, garantindo a independência do fornecedor.

Quanto tempo leva para um carimbo de tempo se tornar verificável? Depois que o cron noturno ancora a raiz de Merkle em uma transação Bitcoin, normalmente leva cerca de 3 horas para a transação ser confirmada em um bloco do Bitcoin. Uma vez confirmada, a prova é imutável e verificável.

Posso verificar carimbos de tempo de repositórios privados? Sim, mas o acesso às páginas de status e verificação para repositórios privados exige um HMAC criptografado anexado à URL. Isso garante que apenas usuários autorizados possam ver os detalhes da prova.

Conclusão

A verificação é onde um carimbo de tempo deixa de ser uma promessa e se torna evidência. A cadeia é curta e verificável: hash do commit → manifesto diário → raiz de Merkle → bloco do Bitcoin. Quer você confirme na página de status, execute a verificação de Merkle no navegador ou obtenha o livro-razão CSV para um registro, a conclusão repousa na matemática do Bitcoin, e não na palavra de ninguém — incluindo a nossa.

Instale o GitHub App em um repositório, deixe a execução noturna fazer seu trabalho, e então verifique uma data você mesmo antes que alguém peça. Leva alguns minutos e é a diferença entre “achamos que podemos provar” e “aqui está a prova”.

Posts relacionados