#dusk $DUSK @Dusk
Comparei duas gerações da própria documentação da Citadel sob $DUSK #dusk @Dusk e encontrei uma mudança que eu não esperava. O design original de 2023 descreve a revogação de licença como algo imposto pela rede: um SP prova que uma licença deve ser removida e, com concordância do consenso, ela é removida da árvore de Merkle.
O repositório atual do GitHub — Citadel 2, a versão reconstruída — descreve o endpoint de forma diferente. Um usuário prova on-chain que uma licença existe e, em seguida, divulga um cookie de sessão para um Provedor de Serviço que aplica sua própria política para conceder ou negar acesso. A existência é provada on-chain. A decisão real é lida como estando do lado do SP.
O que mudou para mim: eu presumi que a geração mais nova empurraria mais do processo para o on-chain, e não menos. Pode ser que ainda funcione assim em outras partes da especificação — eu só tenho o enquadramento do README, não o documento completo do protocolo — então não estou chamando isso de regressão, apenas de uma diferença na linguagem entre versões que eu não esperava encontrar.
Vale checar diretamente: se a especificação do protocolo da Citadel 2 ainda implementa a revogação baseada em consenso do jeito que o artigo original fazia, ou se a política própria do SP agora é o gate final de acesso.
Comparei duas gerações da própria documentação da Citadel sob $DUSK #dusk @Dusk e encontrei uma mudança que eu não esperava. O design original de 2023 descreve a revogação de licença como algo imposto pela rede: um SP prova que uma licença deve ser removida e, com concordância do consenso, ela é removida da árvore de Merkle.
O repositório atual do GitHub — Citadel 2, a versão reconstruída — descreve o endpoint de forma diferente. Um usuário prova on-chain que uma licença existe e, em seguida, divulga um cookie de sessão para um Provedor de Serviço que aplica sua própria política para conceder ou negar acesso. A existência é provada on-chain. A decisão real é lida como estando do lado do SP.
O que mudou para mim: eu presumi que a geração mais nova empurraria mais do processo para o on-chain, e não menos. Pode ser que ainda funcione assim em outras partes da especificação — eu só tenho o enquadramento do README, não o documento completo do protocolo — então não estou chamando isso de regressão, apenas de uma diferença na linguagem entre versões que eu não esperava encontrar.
Vale checar diretamente: se a especificação do protocolo da Citadel 2 ainda implementa a revogação baseada em consenso do jeito que o artigo original fazia, ou se a política própria do SP agora é o gate final de acesso.
