A próxima superfície de ataque do cripto talvez não seja o código.
Pode ser uma configuração disfarçada de governança.
A arquitetura PolicyClient do Newton Protocol expõe uma questão de segurança mais difícil: não se a lógica de políticas está correta, mas quem possui a autoridade para definir o que essa lógica está autorizada a significar.
A política Rego pode continuar pública, determinística, reutilizável e inalterada. Ainda assim, seu perímetro de aplicação é reescrito por valores JSON planos passados por data.params, sem tocar no código.
Isso significa que o mesmo código de política pode produzir regimes de permissões radicalmente diferentes entre apps.
Um proprietário pode impor limiares de negociação estreitos, tetos de exposição rigorosos e listas de endereços cuidadosamente selecionadas. Outro pode implantar a mesma Rego com parâmetros permissivos e chamar o sistema de “política protegida”.
Mesma lógica. Soberania diferente.
O expireAfter não rotaciona, não renova e não invalida esses parâmetros. Ele apenas define a janela de execução de uma atestação.
Chamar setPolicy(PolicyConfig) cria um novo policyId. O ID anterior fica obsoleto, e a validação rejeita qualquer atestação cujo policyId não corresponda mais à configuração ativa do PolicyClient.
Isso torna mudanças de configuração criptograficamente visíveis.
Mas visibilidade não é compreensão.
O plano de controle saiu da lógica do contrato e foi para configurações controladas pelo proprietário, direitos de atualização e seleção de parâmetros.
Então a segurança configurável é realmente mais forte — ou a governança apenas foi comprimida em campos JSON que a maioria dos usuários, auditores e mercados jamais vai examinar?
@NewtonProtocol
#newt $NEWT
Pode ser uma configuração disfarçada de governança.
A arquitetura PolicyClient do Newton Protocol expõe uma questão de segurança mais difícil: não se a lógica de políticas está correta, mas quem possui a autoridade para definir o que essa lógica está autorizada a significar.
A política Rego pode continuar pública, determinística, reutilizável e inalterada. Ainda assim, seu perímetro de aplicação é reescrito por valores JSON planos passados por data.params, sem tocar no código.
Isso significa que o mesmo código de política pode produzir regimes de permissões radicalmente diferentes entre apps.
Um proprietário pode impor limiares de negociação estreitos, tetos de exposição rigorosos e listas de endereços cuidadosamente selecionadas. Outro pode implantar a mesma Rego com parâmetros permissivos e chamar o sistema de “política protegida”.
Mesma lógica. Soberania diferente.
O expireAfter não rotaciona, não renova e não invalida esses parâmetros. Ele apenas define a janela de execução de uma atestação.
Chamar setPolicy(PolicyConfig) cria um novo policyId. O ID anterior fica obsoleto, e a validação rejeita qualquer atestação cujo policyId não corresponda mais à configuração ativa do PolicyClient.
Isso torna mudanças de configuração criptograficamente visíveis.
Mas visibilidade não é compreensão.
O plano de controle saiu da lógica do contrato e foi para configurações controladas pelo proprietário, direitos de atualização e seleção de parâmetros.
Então a segurança configurável é realmente mais forte — ou a governança apenas foi comprimida em campos JSON que a maioria dos usuários, auditores e mercados jamais vai examinar?
@NewtonProtocol
#newt $NEWT