Hoje à tarde, desmontei o protocolo Citadel de @Dusk e fiquei travado por um bom tempo na palavra “license”. No começo, pensei: ora, isso não é simplesmente enfiar a identidade diretamente na blockchain? Mas depois de reler os documentos várias vezes, entendi que não era bem assim.

O ponto principal é que, depois que o provedor de credenciais faz a verificação presencial, ele emite para você uma licença criptografada e registra isso no contrato. O que o usuário realmente envia é uma prova de conhecimento zero, que comprova “que eu tenho uma license válida”. Do lado do provedor de serviço, eles só verificam as sessões públicas para decidir se liberam ou não. No processo todo, há três tipos de participantes bem definidos: o usuário, o License Provider (provedor da licença) e o Service Provider (provedor do serviço).

Isso parece menos com a exigência de entregar cópia do documento de identidade em cada prédio que você entra, e mais com um hospital: eles conferem uma vez, te entregam um comprovante de “apto no exame”; a academia só checa se o comprovante é válido para te deixar entrar — eles nem veem o prontuário nem o endereço. Mas o fato de não divulgar muito não significa confiança zero. Quem pode emitir? Como revogar? Por quanto tempo expira? O provedor de serviço não vai coletar informações fora da cadeia? Essas questões é que realmente delimitam a fronteira de privacidade.

Também vi que o oficial diz que o SDK JavaScript completo ainda não está pronto; então protocolo e experiência de desenvolvimento são coisas bem diferentes. Ao reexaminar o modelo de transação: no Moonlight, a conta é pública — endereços de saldo e valores ficam totalmente transparentes. No Phoenix, com ofuscação de tickets e nullifier, os participantes do valor não são expostos, e ainda dá para fazer divulgação seletiva usando uma chave de visualização. Ambos operam na mesma blockchain: o usuário escolhe conforme o cenário.

Mas, ao integrar com exchanges, privacidade não é necessariamente “quanto mais, melhor”. Custódia, atribuição e auditoria precisam de suporte operacional correspondente; e, na prática, o fluxo mais comum de depósitos e saques ainda segue o caminho público. Se o usuário quer esconder algumas coisas, precisa fazer mais uma rodada de conversões — e o custo não é baixo.

Tomando o saque do Moonlight como exemplo: a transação fica esperando nos nós por cerca de meia hora e então desaparece do mempool. O oficial é bem direto: o tempo de expiração não fica escrito na transação; é uma estratégia de cada nó. O Rusk, por padrão, configura para três dias; alguns configuram para 30 minutos. O nó A não vê, e o nó B talvez nem sincronize. O “transactions/removed” só indica que saiu do pool local; o motivo pode ser ter entrado em bloco, ter sido substituída ou haver conflito. O “202 Accepted” só mostra que o nó aceitou a solicitação; não deve ser tratado como estado final. Antes de tentar de novo, é preciso checar o nonce e o resultado da execução; observar um único nó realmente não pode virar conclusão de toda a rede. #dusk

Com essa configuração de dupla rota atualmente ($DUSK ), qual uso vocês preferem mais?