Como o Label 309 funciona

O Label 309 define como um registro de Proof of Existence (prova de existência) é gravado nos metadados de uma transação Cardano. Em essência, um registro firma o compromisso com um ou mais hashes do conteúdo na Cardano sob o rótulo de metadados 309. O tempo de bloco dessa transação se torna a testemunha pública de que aqueles bytes exatos existiam, no máximo, até aquele momento. Todo o resto que o registro pode carregar — assinaturas, URIs de armazenamento, cargas cifradas, compartimentos de chave por destinatário, raízes Merkle, um ponteiro para um registro anterior — é metadado opcional sobre essa única afirmação.

O objetivo de projeto é simples de enunciar: uma prova deve ser verificável de forma independente. Conferir a afirmação básica não deveria exigir confiar na CardanoWall, no site de quem publica, em um banco de dados privado ou em uma autoridade certificadora — apenas na cadeia pública e, para afirmações sobre conteúdo, nos bytes originais.

O Label 309 é um padrão aberto. Ele foi submetido ao processo de CIP da Cardano como uma proposta da categoria Metadata e está em revisão pelos editores de CIP; o próprio rótulo de metadados é o identificador durável na cadeia, e o aplicativo web, a CLI e os SDKs são implementações de referência dele, não o padrão em si. Se você quiser primeiro o panorama mais amplo, comece por o que de fato é a Proof of Existence.

O que fica armazenado na blockchain sob o rótulo 309?

Um registro Label 309 vive nos metadados da transação Cardano sob o rótulo inteiro 309. Exatamente um registro por transação; um verificador ignora todos os demais rótulos de metadados.

O corpo do registro é codificado como CBOR canônico — um formato binário determinístico, de modo que duas implementações que expressam o mesmo registro lógico emitem bytes idênticos. A Cardano limita qualquer string de metadados a 64 bytes, e um registro serializado costuma ser maior do que isso. Por isso o corpo é transportado como um array CBOR de pequenos pedaços de string de bytes cuja concatenação em ordem é o corpo do registro. Um verificador concatena os pedaços de volta antes de validar qualquer coisa. Essa é a única fragmentação que o formato realiza.

Esse detalhe de transporte importa para quem implementa, mas a ideia por baixo é direta:

1. A transação carrega o rótulo de metadados 309.
2. O valor sob esse rótulo se remonta em um único registro Label 309.
3. O registro firma o compromisso com hashes do conteúdo, raízes Merkle, ou ambos.
4. Campos opcionais acrescentam assinaturas, material de carga cifrada, URIs de armazenamento e um ponteiro de substituição.

Isto não é um campo de anotação de forma livre. O registro tem uma forma estrita e fechada, que é exatamente o que permite a diferentes implementações produzir e verificar os mesmos bytes.

Por que o hash do conteúdo é a afirmação principal?

Porque a Proof of Existence é uma afirmação sobre bytes exatos, e um hash é a impressão digital de bytes exatos.

O hash do conteúdo é a afirmação principal no Label 309; todo outro campo é metadado sobre ele. Para uma prova de arquivo simples, um item carrega um mapa hashes que associa um algoritmo de hash nomeado — por exemplo sha2-256 ou blake2b-256 — a um digest bruto de 32 bytes. Para conferir a prova, um verificador recalcula o digest a partir do arquivo original e o compara com o digest no registro.

Se os bytes coincidem, a prova passa. Mude um byte e o digest muda, então a prova falha.

É por isso que a afirmação permanece pequena mesmo quando o conteúdo é grande ou privado. O registro nunca precisa do arquivo. Ele precisa da impressão digital.

O que são items, uris e enc?

items são os compromissos por conteúdo dentro de um registro. Cada item é uma afirmação de conteúdo. A única parte obrigatória é um mapa hashes não vazio; o resto é opcional.

Um item pode carregar:

• hashes — o mapa obrigatório de algoritmo de hash para digest bruto;
• uris — locais opcionais endereçados por conteúdo, como ar://… (Arweave) ou ipfs://… (IPFS);
• enc — um envelope de criptografia opcional para um registro selado (cifrado).

A ideia central é que as uris não são a prova. O hash é a prova. Uma URI é uma pista de recuperação ou um compromisso de armazenamento que ajuda um verificador a encontrar bytes para conferir. Um registro somente de hash, sem URI, é uma prova completa e válida. Um registro com uma URI pode ajudar a recuperar conteúdo público ou texto cifrado. Um registro selado mantém o texto claro cifrado fora da cadeia e ainda assim prova quando ele existiu.

Por que apenas ar:// e ipfs://?

O Label 309 v1 restringe as URIs de armazenamento a esquemas endereçados por conteúdo — Arweave e IPFS — e rejeita todo o resto, inclusive https://. Essa restrição é deliberada, não temporária.

Uma URL https:// comum depende de DNS, TLS, comportamento do servidor, redirecionamentos e do que quer que esteja hospedado naquele endereço mais tarde. Uma URI endereçada por conteúdo é diferente: o próprio endereço é derivado do conteúdo (um CID de IPFS é um multihash dos bytes; um id de transação Arweave firma o compromisso com os dados sob o consenso da Arweave). Assim, um verificador pode confirmar “os bytes que busquei são os bytes com que o produtor se comprometeu” sem confiar no gateway de armazenamento, no DNS ou em uma autoridade certificadora. Os bytes buscados ainda precisam coincidir com o compromisso na cadeia; a camada de armazenamento nunca é, por si só, uma fonte de verdade.

O que as assinaturas provam — e o que não provam?

Um registro Label 309 pode carregar um array sigs opcional de nível superior. Cada entrada é uma assinatura COSE_Sign1 destacada sobre o corpo do registro com o campo sigs removido. Em termos simples, um signatário responde pelo registro inteiro de uma vez: cada item, cada hash, cada URI, cada envelope selado, cada raiz Merkle, o ponteiro de substituição e quaisquer campos de extensão.

Assinar é aditivo. Um registro sem assinatura ainda prova existência. Um registro com uma assinatura válida também mostra que uma chave específica respaldou o registro:

• somente de hash: estes bytes existiam até este tempo público;
• assinado: estes bytes existiam até este tempo público, e esta chave respondeu pelo registro.

A precisão importa, porque uma assinatura prova menos do que as pessoas costumam supor. Uma assinatura verificada não prova que a mesma chave pagou ou submeteu a transação Cardano, que ela escolheu o tempo de bloco, ou que pertence a uma pessoa real específica. Ela prova que a chave assinou o corpo do registro — nada mais. Apresente isso como “assinado por esta chave”, nunca como “publicado por esta chave”. Esse significado estreito e honesto é o que torna uma prova assinada portátil entre diferentes aplicativos e gateways. A autoria é sempre opcional, e uma assinatura que um verificador não consegue conferir (um algoritmo sem suporte, uma chave não resolvível) nunca invalida a afirmação de existência — assinaturas falham de forma suave; a existência não.

O que é um registro selado?

Um registro selado mantém o conteúdo confidencial e ainda assim prova quando ele existiu.

Em um registro Label 309 selado, o item continua firmando o compromisso com o hash do texto claro — nunca do texto cifrado. O texto claro é cifrado, e o texto cifrado vive em uma URI endereçada por conteúdo (ar://… ou ipfs://…), nunca na cadeia. O registro na cadeia carrega um envelope de criptografia contendo o material de que um detentor de chave escolhido precisa para recuperar a chave de criptografia do conteúdo. A cadeia não contém o texto claro, e não publica uma lista de destinatários.

Para um destinatário, a verificação acrescenta alguns passos:

1. Buscar o registro na Cardano.
2. Buscar o texto cifrado no armazenamento endereçado por conteúdo.
3. Tentar abrir um compartimento de chave correspondente localmente.
4. Decifrar o texto cifrado se um compartimento abrir.
5. Recalcular o hash do texto claro e compará-lo com o compromisso na cadeia.

Como o digest na cadeia vincula o texto claro, uma prova selada preserva o arquivo original exato e o mantém privado. Alguns limites honestos vêm junto: um registro selado prova o momento e a integridade, não o anonimato, e um destinatário que decifra sempre pode optar por vazar o texto claro depois.

Como os destinatários funcionam sem um campo de destinatário?

Os destinatários funcionam por meio de chaves de recebimento e de decifração por tentativa, não de um campo de endereçado legível.

Se um remetente conhece o endereço de recebimento de um destinatário (uma chave pública X25519, opcionalmente uma híbrida pós-quântica), o remetente pode montar um registro selado com um compartimento de chave que esse destinatário consegue abrir. A chave pública do destinatário nunca aparece como um campo legível no registro. O software do destinatário observa o fluxo público de registros Label 309 e tenta decifrar localmente os compartimentos candidatos; se um compartimento abre, o registro pertence à Inbox daquele destinatário.

É por isso que uma Inbox da CardanoWall não é uma caixa de correio comum do lado do servidor. O gateway expõe um feed de registros cego ao destinatário; o cliente encontra os que consegue decifrar. O servidor nunca precisa saber quem é o destinatário nem decifrar nada em nome dele. (Veja como receber registros selados para o lado do destinatário na prática.)

Ainda há limites de metadados que vale deixar claros. O registro nunca publica texto claro nem uma coluna de destinatário, e a ordem dos compartimentos é embaralhada antes da publicação, de modo que não carrega nenhum sinal. Mas a quantidade de compartimentos fica visível, e o momento das ações, rastros de pagamento e erros operacionais podem revelar informações que o próprio formato do registro não consegue esconder.

Como um único registro cobre milhares de arquivos?

Se você precisa provar que mil arquivos existiam, não deveria precisar de mil transações Cardano. O Label 309 oferece agrupamento Merkle: calcule o hash dos arquivos, construa uma árvore Merkle sobre a lista ordenada de hashes e publique uma única raiz de 32 bytes no array merkle do registro. Junto da raiz, o registro carrega uma contagem de folhas, que vincula a raiz na cadeia ao tamanho exato da lista fora da cadeia.

Depois, você pode provar que um arquivo ou evento específico estava no lote mostrando:

• o arquivo (ou seu hash de folha);
• uma prova de inclusão — os hashes irmãos ao longo do caminho até a raiz;
• a raiz Merkle ancorada no registro Label 309.

O verificador recombina a prova de inclusão de volta até uma raiz e só a aceita se a raiz recalculada for igual à raiz publicada, byte a byte. Toda folha não revelada permanece privada — a raiz não revela nada sobre as folhas com que se compromete.

Esta é a camada de escala para artefatos de CI/CD, logs de conformidade, saídas de IA, manifestos de conjuntos de dados, pastas de lançamento e pacotes de evidências. Ela ganha tratamento próprio em um registro para milhares de arquivos.

O que o ponteiro supersedes faz?

supersedes é um ponteiro opcional de 32 bytes para um registro Label 309 anterior, pelo hash da sua transação. Ele permite que um registro mais novo diga “isto substitui ou atualiza aquele registro anterior”.

O registro anterior não é excluído nem invalidado. A Cardano é somente de acréscimo, então ambos os registros permanecem verificáveis de forma independente para sempre. O ponteiro é apenas um link; não carrega campo de motivo. O significado humano da substituição — uma correção, um manifesto revisado, um pacote de evidências atualizado — pertence ao novo conteúdo ou à camada de aplicação, não aos metadados. O valor do ponteiro está em funcionar sem nenhuma linha de banco de dados de fornecedor e sem nenhum id de registro proprietário.

Como funciona a verificação?

A verificação é em camadas. O Label 309 define três papéis de verificador, cada um uma extensão estrita do anterior:

• Validador estrutural — uma função pura sobre os bytes do registro. Ele confirma o CBOR canônico, a forma do esquema, os tipos de campo, os campos obrigatórios, os identificadores de algoritmo e as regras de URI. Não realiza I/O de rede, não verifica assinaturas e não decifra nada.
• Verificador público — parte de uma referência de transação Cardano. Ele busca a transação bruta em um explorador que o próprio verificador escolhe, vincula esses bytes ao hash de transação solicitado, confirma que o rótulo 309 está presente, remonta o registro, executa a validação estrutural, verifica a profundidade de confirmação e verifica as assinaturas que suporta. Se os bytes do conteúdo estiverem disponíveis, ele pode recalcular hashes de conteúdo público. Ele não decifra.
• Verificador do destinatário — tudo o que o verificador público faz, mais sua própria chave privada para abrir cargas seladas e recalcular hashes do texto claro.

Uma sutileza mantém a verificação honesta: um verificador público lê o CBOR bruto da transação, não a visão JSON dos metadados de um explorador. Uma projeção JSON é com perdas — ela descarta a ordem das chaves do mapa e a distinção entre bytes e texto —, então recodificar a partir dela quebraria toda assinatura de um registro em conformidade. E como a liquidação na Cardano é probabilística, um registro com apenas um ou dois blocos de profundidade é reportado como pending em vez de valid até ter confirmações suficientes atrás dele.

Essa estrutura mantém o modelo de confiança limpo. Um verificador básico não precisa de conta na CardanoWall; uma prova pública se confere sem o servidor de quem publica; uma prova selada se decifra localmente, nas mãos do detentor da chave. O passo a passo de verificar um registro Label 309 mostra o caminho do verificador público de ponta a ponta.

Onde o gateway se encaixa?

O gateway publica registros. Ele não é a raiz de confiança.

Um gateway Label 309 cuida das partes que são genuinamente difíceis de rodar por conta própria: ele cota o preço, envia o texto cifrado para o armazenamento, monta e submete a transação Cardano, espera a confirmação, indexa registros, gerencia saldos e expõe uma API. A CardanoWall usa esse modelo de gateway para tornar a publicação prática para usuários e desenvolvedores comuns.

Mas uma prova não é confiável porque um gateway diz que ela existe. Ela é confiável porque o registro está na cadeia, os bytes validam, as assinaturas conferem e os hashes recalculam. Essa é a linha entre um serviço hospedado e um padrão de prova: o serviço ajuda você a publicar; o padrão deixa qualquer um verificar, com o gateway totalmente fora do caminho de confiança.

O modelo mental mínimo

Pense no Label 309 como um registro pequeno e em camadas:

1. items provam que bytes de conteúdo exatos existiam até um tempo público.
2. sigs deixam chaves responderem pelo registro, opcionalmente.
3. enc deixa o conteúdo cifrado permanecer privado, mas recuperável.
4. compartimentos de chave por destinatário deixam detentores de chave específicos abrirem conteúdo selado.
5. merkle deixa um registro representar um lote muito grande.
6. a verificação roda sobre dados públicos e chaves locais — nunca sobre confiança em um fornecedor.

Essa divisão em camadas é o que permite que a CardanoWall seja um aplicativo web, uma API, uma CLI, um aplicativo desktop ou um gateway auto-hospedado — enquanto o formato da prova permanece o mesmo. O produto pode mudar; a prova continua verificável.

Vale deixar uma coisa clara o tempo todo: uma prova Label 309 mostra que bytes específicos existiam até um tempo público, e que não mudaram desde então. Ela não prova quem foi o autor do conteúdo, quem o possui, ou se algo que ele diz é verdadeiro. Para entender onde essa linha é traçada, veja o que uma prova não prova.

Leitura adicional

• O que é a Proof of Existence?
• Verificar um registro Label 309
• Um registro para milhares de arquivos
• O que uma prova não prova
• O padrão Label 309: label309.org
• Os SDKs e a CLI de código aberto: github.com/cardanowall
• A submissão do CIP na Cardano (em revisão): CIPs PR #1205