Hash, assinar, selar, compartilhar: os quatro níveis de uma prova CardanoWall

Uma prova CardanoWall tem quatro níveis práticos, e você decide até onde quer subir na escada:

• Hash prova que aqueles bytes exatos existiam até um determinado momento público.
• Assinar acrescenta uma afirmação respaldada por chave de que uma identidade específica respondeu pelo registro.
• Selar cifra o arquivo original para que ele possa ser preservado de forma privada junto com a prova.
• Compartilhar embrulha esse arquivo selado para destinatários específicos, de modo que eles possam depois descobri-lo e decifrá-lo com suas próprias chaves.

Cada nível se apoia no anterior, e o padrão por baixo de todos eles é o mesmo: o Label 309. Essa é a forma mais simples de entender o que é a CardanoWall: não apenas um lugar para colocar hashes em uma blockchain, mas uma maneira em camadas de tornar registros duráveis, privados e verificáveis — começando por um simples carimbo de tempo e adicionando só a proteção que cada situação de fato exige.

Nível 1: hash — provar que bytes exatos existiam até um determinado momento

O primeiro nível é a clássica Proof of Existence (prova de existência).

Você parte de um arquivo, uma mensagem, um conjunto de dados, um ativo de mídia, um artefato de build, um relatório ou um manifesto. A CardanoWall calcula um hash criptográfico dos bytes exatos e publica esse hash em um registro Label 309 na Cardano.

Depois, qualquer pessoa que tenha os mesmos bytes originais pode calcular o hash de novo. Se ele coincidir com o hash do registro, o verificador sabe que aqueles bytes exatos existiam, no máximo, até o block time da transação. A verificação roda contra a blockchain pública da Cardano — não precisa de uma conta CardanoWall e não confia em nenhum servidor da CardanoWall.

A parte útil: o arquivo em si nunca precisa ser público. Um contrato privado, um instantâneo de um conjunto de dados, um manifesto de lançamento de software ou um pacote de provas jurídicas — cada um deles pode carregar uma prova pública. O registro diz estes bytes existiam. Ele não precisa mostrar os bytes.

Para que servem as provas de hash?

As provas de hash são fortes quando a pergunta é sobre tempo e integridade. Elas respondem a coisas como:

• Este arquivo exato existia antes de um prazo?
• Este é o mesmo PDF que recebeu carimbo de tempo no mês passado?
• Este manifesto de lançamento já havia sido registrado antes do incidente?
• Este instantâneo do conjunto de dados existia antes de o modelo ser treinado com ele?
• Este arquivo de mídia existia antes de ser editado ou contestado?

Elas também são eficientes. Um arquivo de vários gigabytes se reduz a um único digest curto, e um arquivo privado vira um compromisso público sem revelar seu conteúdo.

A limitação importa tanto quanto: um hash não prova quem criou o arquivo, que o arquivo é verdadeiro, nem que alguém é dono dele. Ele prova que aqueles bytes exatos existiam até um determinado momento público — nada mais. Isso já basta para muitos fluxos de trabalho. Para os demais, a CardanoWall acrescenta as camadas seguintes.

Nível 2: assinar — anexar uma chave de identidade ao registro

O segundo nível acrescenta uma assinatura.

Uma assinatura permite que uma chave responda pelo registro. Em vez de apenas provar que bytes existiam, o registro também pode mostrar que uma chave de identidade específica assinou a prova. No Label 309 isso é uma assinatura COSE_Sign1 destacada e opcional sobre o corpo do registro, e a autoria nunca é exigida — um registro sem assinatura ainda é uma prova completa e totalmente verificável.

Essa opção muda o significado prático. Para um criador individual, um registro assinado pode conectar um produto de trabalho à identidade CardanoWall do criador. Para uma empresa, pode mostrar que uma chave aprovada respaldou um relatório, um manifesto de lançamento, um instantâneo de conformidade ou um compromisso sobre um conjunto de dados. Para um fluxo de trabalho automatizado, distingue "alguém carimbou este arquivo no tempo" de "nosso sistema assinou este registro como parte do processo".

A assinatura não substitui o hash; ela fica por cima dele.

• O hash diz: estes bytes exatos existiam.
• A assinatura diz: esta chave assinou o registro que faz essa afirmação.

O que uma assinatura não prova?

As assinaturas são poderosas, mas não fazem mágica.

Uma assinatura prova o controle de uma chave no momento da assinatura. Ela não prova, por si só, a identidade no mundo real da pessoa ou da empresa por trás dessa chave. Essa identidade vem do contexto: como a chave foi criada, como foi publicada, como uma organização a gerencia e como os outros passam a confiar nela.

Uma assinatura também não prova que o signatário pagou a taxa da transação nem que submeteu a transação à Cardano. No Label 309 a assinatura cobre o corpo do registro, não a transação Cardano inteira. Isso é deliberado, e é o que mantém os registros portáteis: um gateway, um sistema de automação ou qualquer terceiro pode publicar um registro assinado sem se tornar o autor do conteúdo. Uma assinatura verificada se lê como "assinado por esta chave" — nunca "esta chave submeteu a transação".

Em termos simples: assine quando quiser que a prova diga não apenas "isto existia", mas "esta identidade respaldou a prova".

Nível 3: selar — preservar uma cópia cifrada junto com a prova

O terceiro nível acrescenta a preservação cifrada.

Uma prova somente de hash tem uma fraqueza prática: o verificador ainda precisa dos bytes originais. Perca o arquivo, ou altere-o por um único byte, e você já não consegue produzir o conteúdo que coincide com o registro.

O selamento resolve isso cifrando o arquivo e mantendo a carga útil cifrada junto com a prova, em um local endereçado por conteúdo como Arweave ou IPFS. O registro na cadeia continua comprometido com o hash do texto claro — nunca com o texto cifrado — então a afirmação do carimbo de tempo permanece inalterada. O arquivo nunca é publicado às claras. Quem tiver a chave correta pode depois buscar o texto cifrado, decifrá-lo, recalcular o hash do texto claro e provar que este é o arquivo por trás do registro.

Isso muda a experiência. Com uma prova somente de hash, você guarda o arquivo original por conta própria. Com uma prova selada, você pode preservar uma cópia cifrada do original como parte do próprio fluxo de trabalho da prova.

Quando vale a pena selar?

Selar importa quando o arquivo original é importante o suficiente para que perdê-lo enfraqueça a prova. Pense em:

• pacotes de provas jurídicas e contratos assinados;
• relatórios de conformidade e registros de incidentes sensíveis;
• arquivos criativos originais e dados de pesquisa;
• manifestos de conjuntos de dados, prompts e saídas de IA e artefatos de lançamento.

Em cada caso, um hash é útil, mas os bytes originais são aquilo que você pode precisar produzir depois. A Sealed Proof of Existence permite manter esses bytes cifrados enquanto o carimbo de tempo permanece público. A cadeia prova a linha do tempo; a criptografia protege o conteúdo.

Nível 4: compartilhar — entregar um arquivo selado a destinatários específicos

O quarto nível acrescenta a entrega privada a destinatários.

Às vezes a prova não é só para você. Você pode precisar enviar provas cifradas a um advogado, um auditor, um parceiro, um jornalista, um cliente, um regulador ou uma equipe interna.

Se você conhece o endereço de recebimento do destinatário, a CardanoWall pode criar um registro selado que ele poderá abrir depois com sua própria chave. Esse registro ainda tem um carimbo de tempo público e ainda se compromete com o hash do texto claro. Ele ainda pode preservar um arquivo cifrado. Mas agora a carga útil cifrada pode ser aberta por destinatários específicos, não apenas pelo remetente. É aqui que a CardanoWall começa a parecer menos uma ferramenta de carimbo de tempo e mais um sistema seguro de entrega de registros.

Como funciona a entrega privada sem uma agenda pública?

A entrega a destinatários não precisa de uma agenda pública na cadeia, e nenhuma chave pública de destinatário é jamais escrita no registro como um campo legível.

Eis o fluxo. Um destinatário tem um endereço de recebimento. O remetente o obtém por fora — diretamente do destinatário, de um perfil, de uma página da empresa ou de outro canal confiável. Quando o remetente monta um registro selado, o envelope carrega compartimentos de chave cifrados por destinatário que apenas os destinatários pretendidos conseguem abrir.

Do lado de quem recebe, o software do destinatário varre os registros selados públicos e tenta decifrar — localmente, ele experimenta cada compartimento com suas próprias chaves. Quando um compartimento abre, o registro aparece na caixa de entrada daquele destinatário. O servidor nunca decifra a mensagem e não precisa saber quem é o destinatário. (Veja como receber registros selados para o lado do destinatário em detalhe.)

Isto não é uma promessa de anonimato perfeito. Tempo, fluxos de pagamento, metadados de rede, comportamento do navegador e erros operacionais ainda podem vazar informações, e um destinatário sempre pode compartilhar o texto claro depois de tê-lo decifrado. O que o design de fato oferece é mais estreito e real: o próprio registro Label 309 não publica nem o texto claro nem uma lista legível de destinatários — um observador vê apenas que um registro está selado e quantos compartimentos de chave ele carrega, nunca para quem.

Por que a criptografia pós-quântica faz parte da história do compartilhamento?

Registros selados podem durar muito tempo. Se o conteúdo cifrado é armazenado de forma permanente ou semipermanente, um atacante não precisa quebrá-lo hoje: ele pode guardar o texto cifrado agora e tentar mais tarde, com hardware melhor e melhor criptoanálise. Esse é o problema do "harvest now, decrypt later".

É por isso que o Label 309 leva a agilidade de algoritmos a sério. Os endereços de recebimento vêm em duas formas — um endereço clássico X25519 e um endereço híbrido pós-quântico opcional que combina X25519 com ML-KEM-768 (uma construção no estilo X-Wing). O híbrido mantém a segurança clássica do X25519 como piso e ainda acrescenta resistência a um futuro atacante quântico, então é o melhor padrão para conteúdo destinado a sobreviver às suposições criptográficas de hoje. A ideia não é afirmar segurança permanente — nada honesto pode fazer isso — mas evitar projetar um sistema de provas que suponha que o conforto criptográfico de hoje vai durar para sempre.

A versão voltada ao usuário permanece simples: proteja seu Identity Seed, prefira o endereço de recebimento híbrido pós-quântico quando o seu destinatário publicar um, e deixe o software cuidar da criptografia.

Como os quatro níveis funcionam juntos?

Os níveis não são produtos separados. São camadas sobre um único padrão:

• Publique uma prova de hash simples quando você só precisar de um carimbo de tempo.
• Acrescente uma assinatura quando quiser que uma chave de identidade responda pelo registro.
• Sele o arquivo quando preservar os bytes originais exatos for importante.
• Compartilhe o arquivo selado quando destinatários específicos precisarem de acesso privado.

Como o mesmo padrão subjacente sustenta todas as escolhas, você pode começar simples e recorrer a camadas mais fortes só quando a situação exigir.

Qual nível você deve usar?

• Hash quando o arquivo original é fácil de guardar e a única pergunta é se aqueles bytes existiam até um determinado momento.
• Assinar quando você quer uma identidade respaldada por chave por trás da prova.
• Selar quando os bytes originais são sensíveis ou importantes o bastante para preservar uma cópia cifrada junto com a prova.
• Compartilhar quando outra pessoa precisa receber o conteúdo cifrado e verificá-lo depois.

Há ainda uma quinta ferramenta que atravessa todas as quatro: agrupamento Merkle, para quando você tem hashes demais para publicar um a um — artefatos de CI/CD, logs diários, instantâneos de conjuntos de dados, mídia gerada ou qualquer fluxo de trabalho em que milhares de itens devam ser comprometidos sob um único registro e uma única raiz.

O que essas provas ainda não provam?

Mesmo com os quatro níveis, a Proof of Existence permanece precisa quanto às suas afirmações.

Ela pode provar que bytes exatos existiam, que uma chave assinou o registro, que conteúdo cifrado foi preservado, que o conteúdo foi entregue a chaves específicas e — com uma raiz Merkle — que um item pertencia a um lote comprometido.

Ela não prova, sozinha, que o conteúdo é verdadeiro, que alguém detém a propriedade legal, que um conjunto de dados foi coletado de forma lícita, nem que um processo frágil é sólido. Para mais sobre esses limites, veja o que uma prova não prova. A CardanoWall lhe dá uma camada de prova durável; o processo de negócio em torno dessa prova ainda importa.

A versão curta

• Hash é o carimbo de tempo.
• Assinar é a afirmação de identidade.
• Selar é a preservação cifrada.
• Compartilhar é a entrega privada.

Juntos, eles transformam a Proof of Existence de um simples hash numa cadeia em um fluxo de trabalho utilizável para arquivos, conjuntos de dados, provas, lançamentos de software, saídas de IA e registros confidenciais — e, como o Label 309 é um padrão aberto com ferramentas de código aberto, os mesmos quatro níveis funcionam pelo site, pela CLI ou pela implementação de qualquer outra pessoa.

Leitura adicional

• O que é Proof of Existence? — o nível do hash, em profundidade.
• Como receber registros selados — o lado do destinatário em "compartilhar".
• Um registro para milhares de arquivos — agrupamento Merkle nos quatro níveis.
• O que uma prova não prova — os limites a ter em mente.
• Label 309 — o padrão aberto, proposto ao processo CIP da Cardano e em análise pelos editores de CIP (PR #1205).
• github.com/cardanowall — os SDKs de código aberto e a CLI cardanowall.