Recentemente, ao ver o Citadel 2, fiquei preso em um problema: já que as provas de conhecimento zero podem provar “que eu tenho um credencial válida”, por que o provedor de serviço precisa julgar novamente? Por que não apenas liberar diretamente se a verificação passar? Ao alinhar o fluxo oficial, descobri que essas duas camadas tratam de coisas totalmente diferentes.
Vou pensar nisso como um sistema de verificação de diploma. A plataforma de verificação consegue confirmar que o certificado foi emitido por uma determinada instituição e que não foi revogado. Mas quando uma empresa contrata, ainda cabe a ela decidir por conta própria: quais escolas aceitar, quais áreas exigir, se o diploma está vencido e se essa prova pode ser reutilizada. No Citadel 2, o License Provider é como a entidade que emite o diploma. O usuário usa uma prova de conhecimento zero para demonstrar que possui uma license registrada e com assinatura válida. Após a validação do contrato, é gerada uma session pública; porém, se o serviço será de fato oferecido, ainda depende das políticas do Service Provider.
Os limites dessa analogia também são bem claros: o Citadel não revela ao recrutador o conteúdo do diploma. No design oficial, a session na cadeia não expõe diretamente segredos como chaves da carteira do usuário, qual license específica foi usada, atributos de assinatura etc. Quando o serviço precisa de alguma condição, o usuário só divulga ou prova a parte exigida pela política.
No BTC, uma assinatura válida geralmente gira em torno da capacidade de controle de ativos, e não exige responder “se você atende a algum critério de identidade”.
No ETH, em abordagens comuns de token-gating, muitas barreiras dependem diretamente de um endereço público que detém certos ativos; as regras tendem a ser fáceis de entender, mas a privacidade fica mais frágil. O Citadel separa “se a credencial é verdadeira” de “se este serviço vai te aceitar”. Eu acho isso mais alinhado com a realidade: a criptografia prova, o lado do negócio define a política, e ninguém consegue decidir pela outra camada.
Para @Dusk , o que mais me importa não é quão chamativa é a tela de prova, mas se a interface consegue explicar qual regra do serviço não foi atendida quando a verificação é bem-sucedida, porém a solicitação ainda é rejeitada — e não fazer o usuário acreditar que a prova de conhecimento zero falhou. No momento, a documentação ainda diz que o completo JavaScript SDK será fornecido depois; então eu não vou descrever a experiência de integração como algo já maduro. Quando a comunidade/ecoistema de $DUSK surgirem com mais aplicações que exijam validação de qualificações, vou focar em verificar se “prova aprovada” e “autorização pelo negócio” podem ser distinguidas claramente por qualquer pessoa.
#dusk
Vou pensar nisso como um sistema de verificação de diploma. A plataforma de verificação consegue confirmar que o certificado foi emitido por uma determinada instituição e que não foi revogado. Mas quando uma empresa contrata, ainda cabe a ela decidir por conta própria: quais escolas aceitar, quais áreas exigir, se o diploma está vencido e se essa prova pode ser reutilizada. No Citadel 2, o License Provider é como a entidade que emite o diploma. O usuário usa uma prova de conhecimento zero para demonstrar que possui uma license registrada e com assinatura válida. Após a validação do contrato, é gerada uma session pública; porém, se o serviço será de fato oferecido, ainda depende das políticas do Service Provider.
Os limites dessa analogia também são bem claros: o Citadel não revela ao recrutador o conteúdo do diploma. No design oficial, a session na cadeia não expõe diretamente segredos como chaves da carteira do usuário, qual license específica foi usada, atributos de assinatura etc. Quando o serviço precisa de alguma condição, o usuário só divulga ou prova a parte exigida pela política.
No BTC, uma assinatura válida geralmente gira em torno da capacidade de controle de ativos, e não exige responder “se você atende a algum critério de identidade”.
No ETH, em abordagens comuns de token-gating, muitas barreiras dependem diretamente de um endereço público que detém certos ativos; as regras tendem a ser fáceis de entender, mas a privacidade fica mais frágil. O Citadel separa “se a credencial é verdadeira” de “se este serviço vai te aceitar”. Eu acho isso mais alinhado com a realidade: a criptografia prova, o lado do negócio define a política, e ninguém consegue decidir pela outra camada.
Para @Dusk , o que mais me importa não é quão chamativa é a tela de prova, mas se a interface consegue explicar qual regra do serviço não foi atendida quando a verificação é bem-sucedida, porém a solicitação ainda é rejeitada — e não fazer o usuário acreditar que a prova de conhecimento zero falhou. No momento, a documentação ainda diz que o completo JavaScript SDK será fornecido depois; então eu não vou descrever a experiência de integração como algo já maduro. Quando a comunidade/ecoistema de $DUSK surgirem com mais aplicações que exijam validação de qualificações, vou focar em verificar se “prova aprovada” e “autorização pelo negócio” podem ser distinguidas claramente por qualquer pessoa.
#dusk