Todos falam sobre a camada de atestação do Sign. Poucos perguntam o que a parte de ZK está realmente a fazer por baixo do capô.

O Sign suporta atestações privadas e ZK como parte da Stack S.I.G.N. O caso de uso faz sentido no papel. Um governo emite credenciais verificáveis sem expor dados brutos dos cidadãos. Um banco confirma KYC sem transmitir registos pessoais. Um cidadão prova elegibilidade sem revelar rendimento. Limpo, soberano, privado.
E honestamente, o instinto técnico por trás disto é sólido.
Aqui é onde comecei a ler com mais cuidado. As atestações ZK no Sign são um modo em que você opta, não o comportamento padrão. A camada base é transparente. Os emissores assinam claims onchain e esses registos são consultáveis por padrão. ZK fica em cima para casos em que o cliente especificamente precisa de privacidade. O que significa que a garantia de privacidade real não está no protocolo. Está na decisão de implementação tomada por quem está a executar o nó.
O Sign não está errado em construir desta forma. A infraestrutura empresarial precisa de flexibilidade. Não consegue implementar um sistema de identidade nacional que force provas ZK antes do ministério compreender o que é uma prova.
Mas esse enquadramento muda ligeiramente o discurso de vendas. O Sign não está a vender um protocolo que preserva privacidade no sentido criptográfico rigoroso. Está a vender uma plataforma com capacidade de privacidade disponível para clientes prontos para a usar correctamente. Portanto, quando implementações soberanas no Quirguistão ou Serra Leoa são anunciadas, a questão que vale a pena fazer não é se o Sign tem ZK. É se essas implementações realmente estão a usá-lo.
@Sign $SIGN #SignDigitalSovereignInfra