Introdução
O que é o Label 309, os princípios que ele garante e como qualquer pessoa pode verificar um registro sem precisar confiar em um servidor.
O Label 309 é um padrão aberto para prova de existência (PoE) na blockchain Cardano. Quem publica calcula o hash criptográfico de um conteúdo e o ancora em uma transação Cardano sob o rótulo de metadados label 309. A partir desse momento, qualquer pessoa que tenha a referência da transação pode provar que o conteúdo já existia até o horário do bloco, usando apenas a blockchain pública, sem precisar confiar em quem publicou, em um domínio ou em qualquer servidor.
O núcleo do padrão é propositalmente enxuto: a impressão digital do conteúdo (seu hash) é a afirmação em si, e todo o resto são metadados opcionais sobre ela. Sobre esse núcleo, o padrão define assinaturas de autoria opcionais e uma carga útil criptografada ("selada") opcional, endereçada a destinatários específicos, sem que nada disso jamais exija um intermediário de confiança.
As cinco invariantes
Tudo no Label 309 decorre de cinco princípios inegociáveis:
- Centrado no conteúdo. O hash do conteúdo é a afirmação principal; todos os demais campos são metadados sobre ele.
- Independente do emissor. Qualquer carteira pode publicar um registro. Os verificadores nunca confiam em quem publica.
- Independente do armazenamento. As URIs de armazenamento formam uma lista
opcional e plural (
ar://,ipfs://); um registro contendo apenas o hash é plenamente válido. - Verificável de forma independente. Para verificar, basta ter os metadados da transação, opcionalmente os bytes do conteúdo e um explorador público da blockchain. Nenhum servidor do emissor é necessário em momento algum.
- Ágil quanto a algoritmos. Hashes, AEADs, KEMs, KDFs e assinaturas remetem, todos, a identificadores nomeados, definidos em registros de identificadores extensíveis. Migrar para algoritmos pós-quânticos é algo aditivo, não uma mudança que quebra a compatibilidade.
Perfis de conformidade
Um registro se enquadra em um de quatro perfis em camadas, que vão de um simples carimbo de data e hora até uma carga útil criptografada e endereçada a um destinatário. Cada perfil é um superconjunto estrito do anterior.
| Perfil | Acrescenta | Responde a |
|---|---|---|
| core | um hash de conteúdo sob o label 309 | "este conteúdo já existia até o instante T" |
| signed | uma ou mais assinaturas COSE_Sign1 no registro | "...e esta chave o atesta" |
| sealed | uma carga útil criptografada (por frase secreta ou destinatários) | "...mantido confidencial, mas com data e hora" |
| recipient-sealed | slots de chave por destinatário (X25519 ou X-Wing) | "...entregue a chaves específicas, mantido em sigilo" |
A autoria e a criptografia são sempre opcionais. Um verificador que entenda apenas
o perfil core ainda consegue validar a afirmação de data e hora de qualquer
registro.
Verificação, em resumo
O Label 309 define três papéis de verificação, cada um uma extensão estrita do anterior:
- Validador estrutural — uma função pura sobre os bytes do registro. Sem rede, sem checagem de assinaturas, sem decifragem; ele apenas confirma que o registro está bem formado de acordo com o esquema e as regras do padrão.
- Verificador público — busca a transação em um explorador público, executa a validação estrutural, confirma que o registro está ancorado on-chain e verifica eventuais assinaturas de autoria. Ele não decifra nada.
- Verificador do destinatário — um verificador público que, além disso, possui uma chave privada, decifra uma carga útil selada endereçada a ele e recalcula os hashes do texto claro.
Como todos os papéis operam a partir de dados públicos e de um explorador escolhido pelo próprio verificador, a verificação nunca depende da infraestrutura de quem publicou.
A propriedade central
Uma prova do Label 309 é algo que você mesmo pode conferir. Dada uma referência de transação e — no caso de afirmações sobre conteúdo — os bytes originais, qualquer implementação em conformidade chega ao mesmo veredito usando apenas a blockchain pública.
Como esta especificação está organizada
Os capítulos a seguir definem o formato de serialização (o registro sob o label 309), os registros de identificadores de algoritmos, o modelo criptográfico de chaves, as assinaturas de autoria, a entrega selada (criptografada), o fluxo de verificação e seu catálogo de erros, o modelo de segurança e o contrato de conformidade entre linguagens. Cada página é autossuficiente e cita as constantes e regras nomeadas de que um implementador precisa.