O que é Proof of Existence?

Proof of Existence (prova de existência) é uma forma de mostrar que dados exatos existiam até um determinado momento, usando um carimbo de tempo público que qualquer pessoa pode verificar.

O método é simples. Calcule o hash dos dados, publique esse hash em um registro público com carimbo de tempo e, depois, deixe que qualquer pessoa que tenha os dados originais recalcule o hash e o compare com o registro. Se os dois hashes coincidirem, o verificador sabe que os mesmos bytes existiam até o momento daquele registro. Ninguém precisa confiar em você, no seu servidor ou na sua conta — apenas no registro público e na matemática.

O arquivo em si nunca precisa ser público. A prova pode ser pública enquanto o conteúdo permanece privado.

O que a Proof of Existence prova?

Ela prova uma única afirmação, restrita e útil:

Estes bytes exatos existiam até este momento público.

É só isso que a prova básica afirma — e a sua força vem justamente de quão específica ela é.

Quase tudo pode ser reduzido a um hash criptográfico: um documento, imagem, vídeo, conjunto de dados, arquivo de código-fonte, artefato de build, contrato, arquivo de log, saída de modelo ou manifesto. O hash é uma impressão digital curta de uma sequência de bytes exata. Mude um único byte e a impressão digital muda por completo.

Quando esse hash é ancorado em um registro público, o registro se torna uma testemunha do tempo. Depois, se você mostrar o arquivo original a alguém, essa pessoa calcula o hash dele de novo. Se o novo hash coincidir com o registrado, ela pode confirmar que o arquivo à sua frente são os mesmos dados que foram comprometidos antes — no carimbo de tempo do registro ou antes dele.

Isso torna a Proof of Existence valiosa sempre que o momento importa:

• mostrar que um arquivo existia antes de uma disputa;
• mostrar que um relatório existia antes de um prazo de auditoria;
• mostrar que um artefato de software existia no momento do lançamento;
• mostrar que o instantâneo de um conjunto de dados existia antes de ser modificado;
• mostrar que uma saída de IA, um conjunto de prompts ou um arquivo de mídia existia antes de ser contestado.

A prova não é uma descrição do arquivo. É um comprometimento criptográfico com os seus bytes exatos.

Por que o arquivo não precisa ser público?

Porque a afirmação pública é o hash, não o arquivo.

Uma boa função de hash funciona como uma impressão digital de mão única. Qualquer pessoa pode calcular o hash a partir do arquivo, mas quem vê apenas o hash não consegue reconstruir o arquivo a partir dele. É por isso que um documento privado pode carregar uma prova pública: o registro diz "alguém se comprometeu com estes bytes exatos neste momento" sem revelar os bytes.

Por exemplo, uma empresa pode calcular o hash do manifesto de um conjunto de dados confidencial e publicar apenas o hash. O conjunto de dados permanece privado. Depois, se a empresa precisar provar o que o instantâneo continha, ela pode revelar o manifesto completo, um subconjunto dele ou uma prova de inclusão de um único item — o que a situação exigir.

É também por isso que a Proof of Existence se encaixa bem com equipes jurídicas, de conformidade e de segurança: ela cria um carimbo de tempo externo sem colocar provas privadas em um banco de dados público. Para uma análise mais detalhada desse padrão, veja divulgação confidencial sem arquivos públicos.

Qual é o papel da blockchain?

A blockchain é a testemunha pública do tempo — a parte que ninguém, nem mesmo quem publica, pode reescrever discretamente.

Se um hash existe apenas no seu próprio banco de dados, a prova depende inteiramente do seu sistema. Quando o carimbo de tempo é questionado depois, alguém pode razoavelmente perguntar se o banco de dados foi reescrito, restaurado de um backup, editado por um administrador ou retroagido. Uma blockchain pública elimina essa dúvida. Uma vez confirmada a transação, o registro com carimbo de tempo fica visível para qualquer pessoa e deixa de estar sob o controle exclusivo de quem publica.

No CardanoWall, o registro de prova é ancorado nos metadados da transação Cardano sob o rótulo de metadados 309. Um verificador busca a transação em um explorador público de Cardano de sua escolha, lê o registro e confere o hash do conteúdo contra os bytes originais. Nenhum servidor do CardanoWall participa dessa verificação — a ideia central é justamente que a prova se sustenta sem nós.

A blockchain não entende o seu documento, e não precisa entender. Ela registra os dados da prova; o significado vem de um verificador que recalcula o hash e confirma que os bytes coincidem.

Qual é a prova mais simples?

A prova mais simples é a prova somente de hash.

Você escolhe um arquivo. O software calcula um hash, como SHA-256 ou BLAKE2b-256. Esse hash vai para um registro publicado nos metadados de Cardano. Depois, um verificador repete o cálculo do hash no arquivo original e, se o digest coincidir, a prova passa.

Então o primeiro nível se reduz a três fatos:

1. O conteúdo existe.
2. Seu hash está ancorado na cadeia.
3. Qualquer pessoa com o conteúdo original pode verificar a correspondência.

Para muitos usos, isso basta. Um hash com carimbo de tempo é poderoso precisamente por ser simples — há pouco para configurar errado e nada em que confiar.

Quando um hash não é suficiente?

Um hash puro responde bem a uma pergunta, mas não a todas.

Ele não diz quem criou o arquivo. Mostra apenas que os bytes existiam. Se duas pessoas têm o mesmo PDF público, qualquer uma delas pode publicar um hash dele; o hash sozinho nada diz sobre autoria.

Ele não preserva o arquivo. Perca os bytes originais e você ainda terá um hash público, mas pode não restar nada para comparar com ele.

E ele não entrega o arquivo a ninguém. Se outra pessoa precisa dos dados originais, um hash puro não os entrega a ela.

É por isso que o formato de registro subjacente é em camadas. Um registro somente de hash é totalmente válido, mas o padrão também oferece suporte a assinaturas, cargas seladas (cifradas), entrega endereçada ao destinatário e agrupamento Merkle — cada um acrescentando uma capacidade sobre o carimbo de tempo.

Como uma assinatura muda a prova?

Uma assinatura adiciona uma declaração respaldada por uma chave.

Um registro assinado diz mais do que "estes bytes existiam até este momento". Ele também pode dizer "esta chave assinou este registro". Isso importa para autoria, aprovações, controles internos e fluxos de trabalho empresariais: uma organização pode usar uma chave de assinatura para mostrar que um sistema, equipe ou identidade específica avalizou um registro, e um criador pode assinar uma prova para associar a sua identidade a uma obra.

A formulação precisa permanecer exata, porém. Uma assinatura mostra que a chave assinou o registro — não quem, no mundo real, detém essa chave. Vincular uma chave a uma pessoa depende de um contexto estabelecido fora do registro. (O CardanoWall mantém as assinaturas opcionais por design; qualquer pessoa pode publicar, e os verificadores nunca precisam confiar em quem publica.)

Como o selamento muda a prova?

Uma prova selada adiciona preservação cifrada.

Em um registro selado, a prova na cadeia continua se comprometendo com o hash do texto claro. Mas o arquivo em si pode ser cifrado e armazenado em um local endereçado por conteúdo — um endereço ar:// (Arweave) ou ipfs:// — com apenas a sua referência no registro. A cadeia nunca vê o texto claro.

Isso importa quando perder o arquivo original tornaria o hash difícil de usar. Com uma prova selada, quem tem a chave certa pode depois buscar o texto cifrado armazenado, decifrá-lo, recalcular o hash do texto claro e confirmar que o arquivo decifrado é exatamente o conteúdo comprometido na cadeia. Como o endereço de armazenamento é derivado dos próprios bytes, o destinatário também consegue saber que um gateway de armazenamento devolveu os bytes certos sem precisar confiar nesse gateway.

A cadeia pública nunca precisa expor o texto claro. A carga cifrada viaja junto com a prova, enquanto a chave de decifração fica com quem deve detê-la.

Como a entrega ao destinatário muda a prova?

A entrega ao destinatário permite que um registro selado seja cifrado para outra pessoa.

Se você conhece o endereço de recebimento de um destinatário (uma chave pública que ele compartilhou), você pode publicar um registro selado que só ele consegue abrir com a própria chave. Vale notar que o registro não carrega nenhum campo dizendo "isto é para a Alice". Não há nenhum destinatário na cadeia. O software do destinatário varre os registros públicos e tenta decifrar discretamente os que podem estar endereçados às suas chaves, abrindo apenas os que de fato estão.

Isso transforma a Proof of Existence em algo mais do que um carimbo de tempo pessoal. Ela pode sustentar divulgação confidencial, troca de provas jurídicas, pacotes de conformidade privados e repasses de auditoria interna — fluxos de trabalho em que a linha do tempo deve ser pública, mas o conteúdo não pode ser. Antes de selar algo para alguém, porém, vale a pena confirmar que a chave realmente pertence a essa pessoa; veja verifique um destinatário antes de selar um arquivo.

Um limite honesto: a criptografia protege os bytes, não as pessoas. O selamento mantém o texto claro legível apenas pelos detentores da chave, mas não garante anonimato, e um destinatário sempre pode vazar o texto claro depois de decifrá-lo.

Como o agrupamento Merkle muda a prova?

O agrupamento Merkle permite que um único registro se comprometa com muitos itens de uma vez.

Em vez de uma transação por arquivo, um sistema pode calcular o hash de milhares ou milhões de itens, combinar esses hashes em uma árvore Merkle e publicar uma única raiz de 32 bytes. Depois, uma prova de inclusão mostra que um item específico fazia parte do lote comprometido. O verificador não precisa de todos os arquivos na cadeia: a raiz é o comprometimento público, e uma prova de inclusão curta — que cresce apenas com o logaritmo do tamanho do lote — liga um item individual de volta a essa raiz. Todos os demais itens do lote permanecem privados.

Isso se encaixa em fluxos de trabalho de alto volume:

• artefatos de CI/CD e manifestos de lançamento;
• logs de conformidade diários;
• conteúdo gerado por IA em escala;
• instantâneos de conjuntos de dados;
• pastas de evidências de auditoria;
• arquivos de mídia e publicação.

O modo Merkle mantém o registro na cadeia minúsculo enquanto deixa uma única prova cobrir um conjunto enorme de itens. Para um exemplo prático, veja um registro para milhares de arquivos.

O que a Proof of Existence não prova?

Esta é a seção que mantém a prova honesta. Um comprometimento com carimbo de tempo é forte porque é específico — e ser específico significa que há afirmações que ele simplesmente não faz.

Ela não prova que um documento é verdadeiro. Um documento falso pode receber carimbo de tempo com a mesma facilidade que um verdadeiro.

Ela não prova propriedade. Qualquer pessoa pode calcular o hash de um arquivo que não lhe pertence.

Ela não prova autoria por si só. A autoria precisa de assinaturas, gestão de chaves e contexto do mundo real acrescentados por cima.

Ela não prova que um build de software é seguro. Pode mostrar qual artefato, SBOM, log ou manifesto existia em um determinado momento, mas a segurança depende do processo de build e dos controles em torno dele.

Ela não prova que um conjunto de dados foi coletado ou usado de forma lícita. Pode mostrar que o comprometimento com um conjunto de dados existia — o que pode ser uma prova importante —, mas os direitos legais são uma questão à parte, que depende da sua jurisdição e do seu advogado.

Em resumo: a Proof of Existence dá a você momento e integridade, não verdade nem direitos. Qualquer afirmação adicional precisa ser construída com cuidado sobre essa base. O que uma prova não prova aprofunda exatamente onde fica essa linha.

Por que o CardanoWall se baseia no Label 309

Uma prova é útil apenas na medida em que é portátil. Uma que funciona somente dentro de um único site não é grande coisa como prova — uma prova séria deve poder ser lida por ferramentas independentes, verificada a partir de infraestrutura pública e compreendida por software que o serviço original nunca escreveu.

É por isso que o CardanoWall é construído sobre o Label 309, um padrão aberto e neutro quanto ao fornecedor para Proof of Existence em Cardano. O Label 309 — e não o aplicativo CardanoWall — é o artefato durável; o aplicativo web, a ferramenta de linha de comando e os SDKs são implementações de referência derivadas dele. O padrão define um formato de registro que escala desde um carimbo de tempo puro para cima:

• provas somente de hash, para existência simples;
• provas assinadas, para afirmações de autoria respaldadas por chave;
• provas seladas, para preservação cifrada;
• provas seladas para destinatário, para entrega privada;
• provas Merkle, para lotes de alto volume;
• identificadores de algoritmos nomeados, para que a criptografia possa evoluir ao longo do tempo sem quebrar registros mais antigos.

O formato também está passando por revisão pública: a Proof of Existence sob o rótulo de metadados 309 foi submetida ao processo de CIP de Cardano e está em análise pelos editores de CIP como uma proposta da categoria Metadata. (O rótulo de metadados 309 é o identificador na cadeia; o número do CIP é atribuído separadamente pelo processo.) O padrão completo, suas implementações de referência e todo o código aberto ficam publicamente em github.com/cardanowall sob licenças permissivas.

O CardanoWall é a interface. O Label 309 é o formato de registro. A prova foi projetada para sobreviver a ambos — à interface e à empresa que ajudou você a publicá-la.

Leituras adicionais

• Como o Label 309 funciona — o padrão por trás de toda prova do CardanoWall.
• O que vai para a blockchain — exatamente quais bytes são publicados e quais nunca saem do seu dispositivo.
• Verifique um registro Label 309 — verificando uma prova você mesmo, a partir apenas de infraestrutura pública.
• Como a Proof of Existence se compara a outros sistemas de carimbo de tempo e proveniência: versus OpenTimestamps, versus uma autoridade de carimbo de tempo e versus C2PA / Content Credentials.