Quando comecei a olhar para a autorização programável, eu presumi que alterar uma regra significaria alterar o contrato inteligente que a impõe. Isso parecia inevitável.
Se um cofre reduzisse sua exposição máxima, adicionasse um endereço restrito, alterasse uma pontuação de risco aceitável ou introduzisse uma nova condição de conformidade, certamente o contrato que protege o cofre precisaria ser reescrito e implantado novamente.
Quanto mais eu investigava o @NewtonProtocolMainnet Beta, mais essa suposição começava a parecer invertida. A Newton separa a aplicação que está sendo protegida da política que decide o que a aplicação está autorizada a fazer.
Como uma Política da Newton Avalia uma Intenção de Transação
Uma política da Newton avalia uma intenção de transação usando três tipos diferentes de informação:
A própria transação
Valores configuráveis em "data.params
Informações em tempo real retornadas por oráculos de dados em "data.wasm"
Portanto, a política pode comparar a mesma ação solicitada com limites, allowlists, resultados de identidade, preços ou sinais de risco em mudança, sem empurrar toda essa lógica diretamente para o contrato da aplicação.
O que Permanece?
Essa distinção parece técnica. Na verdade, muda o que tem que permanecer permanente.
O limite de aplicação pode continuar conectado à aplicação enquanto as regras por trás desse limite continuam evoluindo. A documentação própria da Newton descreve políticas como atualizáveis sem exigir que o contrato protegido seja redeployado, enquanto o anúncio do Mainnet Beta fornece exemplos como um limite revisado ou um novo requisito de sanções entrando em vigor sem reescrever o contrato da aplicação.
O que chamou minha atenção é que Newton não está realmente escolhendo entre código imutável e política flexível. Ele está tentando dar a cada um uma função diferente:
O Contrato da Aplicação: define onde a autorização deve acontecer.
A Política: define quais condições precisam atualmente ser satisfeitas.
Dados do Oráculo: podem ser diferentes para cada transação.
Mas o oráculo, a política e o smart contract não precisam mudar todos juntos. O próprio smart contract pode permanecer no lugar por anos. Um limite de risco pode mudar no próximo mês. Um resultado de sanções ou um sinal de saúde do mercado pode mudar antes de a próxima transação chegar. Hardcodar os três no mesmo contrato tornaria a parte mais lenta do sistema responsável por informações que mudam muito mais rápido.
Newton separa isso. Isso pode importar mais do que parece à primeira vista.
Um Problema de Governança Mais Preciso
No design tradicional de smart contracts, a atualizabilidade costuma ser tratada como um problema no nível do contrato. Ou o contrato é fixo, ou alguém tem permissão para atualizá-lo.
A Newton introduz outra camada entre essas duas escolhas. A aplicação protegida pode permanecer estável enquanto as condições de autorização em torno de ações específicas são ajustadas separadamente.
Então a pergunta deixa de ser: Este contrato pode ser atualizado?
E passa a ser: quais partes do processo de autorização são permitidas mudar, quem controla essas mudanças e quais partes permanecem permanentemente conectadas à execução?
Esse é um problema de governança muito mais preciso.
O Trade-off da Flexibilidade
Flexibilidade nem sempre significa mais segurança. Uma política que se atualiza rapidamente pode se adaptar a novas leis, mudanças de mercado ou ameaças de segurança. Mas ela também pode mudar as regras que os usuários originalmente aceitaram.
Diminuir um limite de risco pode proteger o capital.
Expandir silenciosamente uma allowlist ou enfraquecer um requisito de segurança poderia fazer o oposto.
O perigo não desaparece porque a política é separada do contrato; ele se desloca para a governança da política.
Quem pode atualizar os parâmetros?
Quão visível é a mudança?
Os usuários conseguem inspecionar a política atualmente protegendo uma aplicação?
Versões anteriores ainda são compreensíveis depois que uma nova as substitui?
Essas perguntas se tornam tão importantes quanto a própria lógica do Rego. É essa parte que eu continuo retomando.
Conclusão: Permanência da Aplicação
Newton não torna regras financeiras permanentes. Requisitos reais de conformidade, tolerâncias de risco e condições de segurança mudam com rapidez demais para isso ser realista.
O que ele está tentando tornar permanente é o requisito de que ações protegidas precisam passar pela autorização em qualquer caso
A regra pode mudar
Os dados podem mudar.
O limite pode mudar.
Mas a aplicação não consegue parar silenciosamente de pedir permissão.
Para mim, isso é uma forma de consistência mais interessante do que ficar hardcodando cada regra para sempre. Newton não está congelando a política em vigor. Ele está fixando o ponto em que a política precisa importar.
