Inicialmente pensei que @NewtonProtocol era principalmente sobre conformidade programável. Depois de passar mais tempo com a arquitetura, percebi que eu prestava menos atenção a políticas individuais e mais atenção a onde essas políticas realmente residem. Essa mudança alterou a forma como eu enxergava o protocolo.

O design separa a autorização da execução da aplicação em vez de incorporar regras de negócio diretamente dentro de cada contrato inteligente. Políticas escritas em Rego definem a lógica de autorização, enquanto aplicações individuais fornecem suas próprias restrições operacionais por meio da configuração do PolicyClient. Limites de gasto, destinatários aprovados, restrições jurisdicionais e requisitos semelhantes se tornam uma configuração de tempo de execução estruturada, em vez de uma lógica de política permanentemente codificada.

Essa distinção parece mais relevante do que inicialmente aparenta. Uma única política pode continuar reutilizável enquanto aplicações diferentes operam dentro de limites de autorização distintos, simplesmente alterando a configuração. A política descreve o processo de decisão. A aplicação fornece o contexto. Essas responsabilidades foram intencionalmente mantidas independentes.

Mas algo continuava me incomodando.

A reutilização só funciona se a autorização continuar vinculada às suposições exatas que a produziram. Newton aborda isso gerando um novo identificador de política sempre que a configuração do PolicyClient muda. Atestações produzidas sob uma configuração anterior não se aplicam mais quando o identificador de política referenciado é alterado. Assim, a autorização fica vinculada não apenas à lógica da política, mas também à configuração precisa que existia quando a aprovação foi gerada.

O design altera o limite.

Em vez de modificar o código da aplicação sempre que os requisitos operacionais evoluem, os desenvolvedores ajustam políticas ou configuração preservando a lógica da aplicação. Isso pode simplificar a manutenção em várias aplicações, mas também desloca a responsabilidade para o gerenciamento de políticas. A configuração em si passa a fazer parte do modelo de segurança, em vez de ser apenas um detalhe de implantação. Informações externas introduzem outra camada de responsabilidade. As PolicyData Oracles executam como componentes WASM isolados, retornando dados estruturados em tempo de execução que as políticas avaliam de forma determinística. O tempo de execução restringe intencionalmente o acesso à rede, e falhas são tratadas de maneira diferente dependendo de onde ocorrem. Erros estruturados da aplicação permanecem visíveis para a avaliação da política, enquanto falhas de execução se tornam eventos do tipo DataProviderError que interrompem a autorização totalmente, em vez de produzir uma decisão normal.

Isso não remove a confiança. Apenas a realoca.

A expiração da atestação introduz outra decisão operacional. Janelas curtas de aprovação reduzem as oportunidades de replay, enquanto janelas mais longas dão aos usuários mais flexibilidade antes da execução. Nenhuma das escolhas é uma janela de expiração que equilibre resistência a replay com usabilidade. No fim das contas, os usuários interagem com atestações cuja validade reflete tanto a versão da política quanto o contexto de execução, e não apenas o estado do contrato.

Visto dessa forma, Newton parece menos focado em substituir a lógica do contrato inteligente do que em realocar onde a autorização evolui conforme os requisitos da aplicação mudam.

Levar a evolução da política para fora dos contratos implantados simplifica a segurança no longo prazo, ou apenas cria outra camada em que a complexidade operacional se acumula?

$NEWT #Newt $SUI $ETH