acabei de verificar a arquitetura de atestação do Sign Protocol esta manhã e, honestamente, eu não esperava que a camada de esquema fosse a coisa que me mantivesse acordado 😂
a maioria das pessoas que lêem isso pulam direto para as declarações. as declarações assinadas, os registros on-chain, as provas ZK. e essas são interessantes. mas passei os últimos dois dias em algo mais tranquilo - o registro de esquema - e acho que é o componente mais carregado em toda a camada de evidências que ninguém está falando.
aqui está o que os esquemas realmente são neste sistema.
um esquema não é uma preferência de formatação
é um contrato legível por máquina entre o emissor e o verificador. ele define a estrutura de dados, os tipos de campo, as regras de validação e o versionamento de uma atestação antes que um único credencial seja emitido. quando uma agência governamental emite uma atestação de que um cidadão é elegível para um programa de benefícios, essa atestação está em conformidade com um esquema.
quando um verificador verifica aquela atestação
eles estão verificando isso contra o mesmo esquema. o esquema é o que torna a atestação interpretável entre diferentes sistemas, cadeias e ambientes, sem que ninguém precise chamar uma API ou negociar uma integração personalizada. e os quatro modos de colocação de atestação construídos sobre essa camada de esquema são genuinamente flexíveis.
totalmente on-chain para verificação pública
totalmente off-chain com um âncora verificável para cargas sensíveis
híbrido combinando ambos
ZK aprimorado para provas que preservam a privacidade, onde o verificador confirma uma propriedade sem ver os dados subjacentes. quatro opções reais, cada uma mapeada para uma sensibilidade e requisito de caso de uso diferentes. os emissores podem escolher com base no que o programa realmente precisa, em vez de serem forçados a um modelo.
O SignScan então agrega tudo isso - atestações através de cadeias, camadas de armazenamento, ambientes de execução - consultáveis via REST, GraphQL, SDK. a camada de indexação é o que torna as atestações operacionalmente úteis, em vez de apenas criptograficamente corretas. você pode emitir uma atestação perfeitamente válida e isso não significa nada se ninguém puder encontrá-la ou consultá-la quando a verificação for necessária.
mas aqui está o que não consigo resolver após dois dias nesta documentação. o versionamento de esquema é listado como uma propriedade dos esquemas. isso significa que os esquemas podem mudar. e se os esquemas podem mudar, as atestações existentes emitidas sob uma versão anterior de um esquema existem no registro enquanto o esquema atual avançou.
os documentos não descrevem o que acontece nesse ponto.
se um verificador consulta uma atestação emitida sob o esquema
versão 1 após o emissor ter migrado para o esquema
versão 2 - o caminho de verificação ainda funciona?
o SignScan retorna a atestação com uma bandeira de versão?
o verificador precisa manter compatibilidade com versões antigas de esquema?
existe um mecanismo de obsolescência que sinaliza aos verificadores que o esquema de uma atestação não é mais atual?
isso importa mais do que parece. em uma implementação soberana, as atestações não expiram rapidamente. uma atestação de título de propriedade, uma licença profissional, um credencial de elegibilidade - essas poderiam ser emitidas hoje e consultadas anos depois. se o versionamento de esquema não for tratado com garantias explícitas de compatibilidade retroativa, a camada de evidência acumula atestações órfãs que são criptograficamente válidas, mas praticamente não verificáveis porque o esquema que elas referenciam se desviou. o que o design acerta é a fundação. dados estruturados baseados em esquemas com validação legível por máquina, quatro modos de colocação mapeados para casos de uso reais, indexação omni-chain que torna as atestações consultáveis, independentemente de onde foram emitidas. essa é a arquitetura certa para um sistema que precisa operar entre agências, fornecedores e redes sem integração personalizada em cada junção.
o que não consigo encontrar é a especificação do ciclo de vida do esquema. como é a compatibilidade de versão. se as atestações antigas permanecem verificáveis após uma atualização de esquema ou se precisam ser reemitidas. se o registro de esquema mantém um histórico de versões anteriores ou apenas a atual.
É um projeto muito bem que parece RIO para mim
Não sei se o modelo de versionamento de esquema é um problema resolvido que simplesmente não está documentado neste nível de detalhe ou uma lacuna que surge silenciosamente anos após uma implementação, quando as atestações emitidas sob esquemas obsoletos param de ser verificáveis na prática?? 🤔#SignDigitalSovereignInfra @SignOfficial $SIGN
