O que uma Proof of Existence não prova

Uma Proof of Existence (prova de existência) prova uma única coisa, bem estreita: estes bytes exatos existiam, no máximo, até um momento público. Isso é genuinamente útil — e é também a afirmação inteira.

Uma prova válida não mostra automaticamente que um arquivo é verdadeiro, original, pertence a quem publicou, é legalmente utilizável, está completo ou é admissível em juízo. Cada uma dessas é uma afirmação separada que precisa das suas próprias provas. A forma mais rápida de usar bem uma prova — e de evitar afirmar mais do que ela permite — é entender exatamente onde a sua garantia termina.

Este artigo percorre as afirmações que as pessoas costumam supor que um carimbo de tempo cobre, diz com clareza quais ele cobre e quais não cobre, e mostra como acrescentar a camada que falta quando você precisa de mais.

O que uma Proof of Existence realmente prova?

Ela prova um compromisso, no nível dos bytes, com um momento no tempo.

Alguém pega um arquivo, mensagem, conjunto de dados, imagem, vídeo, arquivo compactado ou manifesto e calcula um hash criptográfico dele. Esse hash entra em um registro público com carimbo de tempo. Depois, qualquer pessoa que tenha os bytes originais recalcula o hash e o compara com o registro. Se os dois coincidem, o verificador pode afirmar uma coisa com confiança:

Esta sequência exata de bytes existia, no máximo, até o momento do registro público.

Com o CardanoWall e o padrão aberto Label 309, esse registro público são os metadados de uma transação Cardano publicados sob o rótulo de metadados 309. Para checá-lo, um verificador lê a transação em um explorador público de Cardano, remonta o registro Label 309, valida sua estrutura e compara o hash (ou, para registros agrupados, uma prova de inclusão Merkle). Nenhum servidor, domínio ou conta do CardanoWall faz parte dessa checagem. A prova se sustenta apenas na blockchain pública.

Esse compromisso é a base. Tudo o que vem depois é uma pergunta diferente.

Uma prova prova que o arquivo é verdadeiro?

Não. Uma afirmação falsa pode receber carimbo de tempo com a mesma facilidade que uma verdadeira. Uma fatura forjada, um relatório equivocado, uma imagem manipulada — todos eles geram algum hash, e todos podem ser ancorados.

Uma Proof of Existence não julga o conteúdo. Ela prova que um conteúdo específico existia até um momento, não que o conteúdo está correto.

Ainda assim, isso vale muito. Se um relatório for corrigido depois, a prova do relatório original mostra o que existia antes da correção. Se uma imagem for contestada, a prova mostra que um determinado arquivo existia antes de a disputa começar. Mas saber se a afirmação dentro do arquivo é precisa vem de um lugar completamente diferente: as provas ao redor, o processo de revisão, as fontes de dados, as testemunhas, o contexto.

Uma prova fixa o quando e os quais bytes. Ela nunca decide verdadeiro ou falso.

Uma prova prova propriedade?

Não. Se um arquivo é público, qualquer pessoa pode calcular o hash dele. Carimbar no tempo um PDF, foto, vídeo, arquivo-fonte ou conjunto de dados público não faz de você o proprietário — apenas registra que você tinha aqueles bytes até aquele momento.

Um carimbo de tempo pode sustentar uma narrativa de propriedade quando aparece ao lado de outros fatos:

• rascunhos e histórico de edições;
• registros assinados;
• arquivos-fonte originais;
• contratos e licenças;
• registros de vínculo empregatício ou de encomenda do trabalho;
• histórico do repositório;
• comunicações com colaboradores.

A prova é uma evidência sobre o tempo. Ela não é uma escritura de propriedade, e não estabelece direitos exclusivos.

Uma prova prova quem criou o arquivo?

Não por si só. Uma prova somente de hash diz que os bytes existiam; não diz nada sobre quem os criou. Se duas pessoas têm o mesmo arquivo, qualquer uma delas pode publicar o mesmo hash.

Registros Label 309 podem carregar uma assinatura opcional. Um registro assinado prova que uma chave criptográfica específica assinou o corpo do registro, o que é significativamente mais forte do que um hash puro, porque vincula a prova a uma chave, e não a quem por acaso submeteu a transação. As assinaturas são sempre opcionais no padrão — quem publica e quer permanecer agnóstico quanto ao emissor simplesmente as omite.

Mesmo com uma assinatura, a forma de dizer importa. Uma assinatura prova que a chave assinou o registro. Ela não prova, por si só, a pessoa do mundo real por trás dessa chave. Esse vínculo vem de como a chave foi estabelecida: o cadastro inicial, uma chave pública publicada, a política da organização, um contrato, a custódia do dispositivo ou outro processo externo à própria prova.

Se você quer uma prova que também carregue autoria, você a assina deliberadamente e gerencia a chave de assinatura com cuidado. O passo a passo em hash, assinar, selar, compartilhar cobre quando vale a pena acrescentar cada uma dessas etapas.

Uma prova prova que quem publicou chegou primeiro?

Em geral, não por si só. Uma prova pode mostrar que quem publicou tinha os bytes até um certo momento. Ela não pode mostrar que ninguém mais os tinha antes.

Isso importa mais para dados de treinamento de IA, conjuntos de dados, obras criativas e segredos comerciais. Se uma empresa carimba no tempo o manifesto de um conjunto de dados hoje, ela tem provas fortes de que o manifesto existia hoje. Mas se outra parte apresentar uma prova mais antiga, um histórico de repositório ou um registro assinado, a linha do tempo pende para o lado dela.

A lição prática: publique cedo e de forma consistente. Uma prova posterior ainda é útil, mas um compromisso público anterior é sempre o mais forte. Quanto mais cedo você ancora, mais difícil fica derrubar a sua linha do tempo.

Uma prova prova que o arquivo nunca foi alterado?

Ela prova algo mais preciso: que um arquivo que você tem agora coincide com os bytes que foram registrados.

Ela não prova que nenhuma cópia, em lugar algum, jamais foi alterada. Ela não protege o seu disco local, e não impede que alguém edite uma versão diferente do arquivo. A pergunta de verificação que ela responde é estreita e concreta:

Este arquivo coincide com o hash no registro público?

Se sim, o arquivo à sua frente é a sequência exata de bytes que foi registrada. Se não, então ou o arquivo mudou, ou o arquivo errado foi fornecido, ou o hash errado foi checado, ou o registro pertence a outros bytes — a divergência, sozinha, não diz qual desses é o caso.

Para qualquer coisa que você possa precisar defender depois, mantenha três coisas juntas: o arquivo original, a referência da transação e qualquer manifesto ou prova de inclusão Merkle. Se o próprio arquivo original pode se perder, esse é exatamente o caso para uma prova selada.

Uma prova preserva o arquivo para você?

Uma prova somente de hash não preserva. Se você publica apenas um hash e depois perde os bytes originais, você ainda pode ter provas de que alguma sequência de bytes existia — mas talvez não consiga mais mostrar qual era essa sequência.

É por isso que o Label 309 oferece suporte a registros selados. Uma prova selada se compromete com o hash do texto claro enquanto armazena o texto cifrado em um local endereçado por conteúdo, identificado por uma URI ar:// (Arweave) ou ipfs:// (IPFS). Quem detém a chave certa pode, depois, buscar o texto cifrado, decifrá-lo, recalcular o hash do texto claro e confirmar que ele coincide com o compromisso na cadeia — recuperando tanto os bytes quanto a prova que os vincula a um momento.

Somente o hash basta quando você vai guardar o arquivo por conta própria. Selar é a melhor escolha quando a recuperação, ou a entrega a outra pessoa, faz parte do plano.

Uma prova prova legalidade ou conformidade?

Não. Uma empresa pode carimbar no tempo dados que foram coletados de forma indevida. Um criador pode carimbar no tempo um conteúdo que não tem direito de distribuir. Uma equipe pode carimbar no tempo um log de conformidade que está incompleto. Um fornecedor pode carimbar no tempo um manifesto de lançamento de um software que ainda é entregue com vulnerabilidades.

Uma Proof of Existence pode sustentar um esforço de conformidade ao tornar os registros à prova de adulteração e ancorados no tempo. Ela não pode substituir o próprio programa de conformidade.

A conformidade de verdade vem de políticas, controles, coleta lícita de dados, registros de acesso, regras de retenção, revisões, aprovações e, às vezes, auditorias externas. Uma prova ajuda a mostrar o que existia e quando. Ela não certifica que o processo subjacente estava correto. Se você está ancorando trilhas de auditoria, logs de conformidade sem confiança no fornecedor trata exatamente desse limite.

Uma prova estabelece a cadeia de custódia?

Não. A cadeia de custódia é uma narrativa de processo: quem coletou um item, onde ele foi guardado, quem o acessou, como ele se movimentou, quais ferramentas o tocaram e quais controles impediram adulterações ao longo do caminho.

Uma prova Label 309 pode ser uma peça dessa narrativa. Ela pode mostrar que um arquivo, uma exportação, um log ou um manifesto de evidências existia até um momento público e ainda coincide depois. Ela não pode nomear cada custodiante nem explicar cada etapa de manuseio, a menos que esses fatos sejam, eles próprios, registrados — e, idealmente, comprometidos — em outro lugar.

Para fluxos de evidências, o padrão é carimbar no tempo o manifesto e manter os registros de processo ao redor para os quais a prova aponta.

Uma prova garante privacidade?

Não, e vale ser específico sobre os limites.

Um registro somente de hash não revela o arquivo original em condições normais, mas ainda assim divulga que alguém comprometeu algo em um certo momento. E se o arquivo tem baixa entropia ou é adivinhável, um atacante pode calcular o hash de candidatos prováveis e checar cada um contra o registro até aparecer uma coincidência.

Um registro selado vai além: o texto claro nunca vai para a cadeia em claro — apenas o seu hash e um envelope selado que não revela o destinatário, com o texto cifrado mantido fora da cadeia — e o Label 309 foi deliberadamente projetado para que as chaves públicas dos destinatários nunca apareçam no registro. Mas a privacidade é maior do que o formato do registro. Tempo, pagamento da taxa, logs do gateway, endereços IP, comportamento do navegador, acessos ao armazenamento, nomes de arquivo que vivem fora do payload cifrado e erros operacionais comuns — cada um deles pode vazar informações que a criptografia nunca toca.

Fluxos sensíveis precisam de segurança operacional em torno da prova, não apenas de criptografia. Quando o objetivo é revelar algo a uma parte específica sem expor nada publicamente, divulgação confidencial sem arquivos públicos cobre a abordagem.

Uma prova garante anonimato?

Não. Um registro Label 309 selado e não assinado pode evitar colocar a identidade de um remetente ou uma lista legível de destinatários no próprio registro de prova — os compartimentos que carregam as chaves encapsuladas revelam quantos destinatários existem, nunca quem. Essa é uma propriedade real e útil. Ela não torna anônimo o processo de publicação ao redor.

A transação Cardano ainda tem entradas e paga uma taxa. Um gateway hospedado pode ver detalhes de conta, pagamento, rede ou tempo. Buscar o texto cifrado no armazenamento pode deixar rastros. Um usuário pode reutilizar um endereço ou revelar contexto em algum outro lugar.

Então a afirmação honesta é estreita: o formato do registro pode omitir campos legíveis de remetente e destinatário. O anonimato completo depende de toda a configuração operacional, não apenas dos bytes — uma distinção que importa mais em provas de denunciantes e casos semelhantes de alto risco.

Uma prova garante que será aceita como prova legal?

Não. Tribunais, reguladores, árbitros e contrapartes decidem, cada um, quais provas aceitam sob as regras que se aplicam a eles. Uma prova criptográfica pode ser uma evidência persuasiva de integridade e de tempo, mas não é um passe legal universal.

Em algumas jurisdições ou contratos, pode ser exigido um carimbo de tempo qualificado, um cartório, um serviço de confiança regulado ou um método específico de assinatura. Em outras, uma prova baseada em blockchain pública pode ter peso real como parte de um conjunto mais amplo de provas. Qual delas se aplica depende da jurisdição e do caso.

Consulte um advogado quando uma prova for relevante juridicamente. Uma prova pode ajudar a estabelecer tempo e integridade; ela não substitui o aconselhamento jurídico, e este artigo não é aconselhamento jurídico. O papel prático que uma Proof of Existence costuma desempenhar em disputas está descrito em provas legais e e-discovery.

Como você torna uma prova mais forte?

Você acrescenta a camada que corresponde à afirmação de que você realmente precisa — e apenas essa camada.

• Precisa de tempo. Publique um hash, ou uma raiz Merkle para muitos arquivos de uma só vez.
• Precisa de autoria ou aprovação. Assine o registro Label 309 e gerencie a chave de assinatura corretamente.
• Precisa recuperar os bytes. Sele o arquivo e armazene o texto cifrado.
• Precisa de entrega confidencial. Cifre para o endereço de recebimento do destinatário.
• Precisa de provas em alto volume. Comprometa uma única raiz Merkle e mantenha a lista de folhas e as provas de inclusão; uma âncora pode substituir milhares de arquivos, como mostra um registro para milhares de arquivos.
• Precisa de peso jurídico. Combine a prova com políticas, contratos, serviços qualificados onde a sua jurisdição os exigir e uma cadeia de custódia documentada.

Cada camada responde a uma pergunta diferente. Empilhá-las é como um simples carimbo de tempo se torna uma prova que carrega exatamente a afirmação que você pretende.

A versão curta

Uma prova é mais forte quando diz apenas aquilo que ela de fato consegue provar.

O Label 309 prova a existência no nível dos bytes até um momento público de Cardano. Sobre isso, ele pode acrescentar assinaturas de autoria, preservação selada, entrega confidencial e agrupamento Merkle. Ele não substitui verdade, propriedade, lei, identidade, segurança operacional ou processo — e não finge fazê-lo.

Essa honestidade não é uma fraqueza do projeto. É o que torna a prova confiável: você sempre sabe exatamente o que ela respalda, e exatamente o que ela deixa para o resto das suas provas.

Leitura adicional

• O que é Proof of Existence? — a ideia central cujos limites este artigo delimita.
• Hash, assinar, selar, compartilhar — as camadas opcionais (assinar, selar, entregar) e quando vale a pena acrescentar cada uma.
• Provas legais e e-discovery — como uma Proof of Existence se encaixa em uma disputa, e onde ela para.
• Proof of Existence vs uma autoridade de carimbo de tempo — ancorar no consenso público versus confiar na chave de uma autoridade nomeada.
• Proof of Existence vs C2PA — uma prova de tempo e integridade ao lado de uma camada completa de proveniência de conteúdo.