O guia dos Policy Packs vende a composição com um exemplo leve e rápido: adicione um pack de risco de cofre, adicione um pack de descolagem (depeg) e pronto, você já conectou uma política. Clique em outro guia, vá para a página sobre como de fato encadear mais de um oráculo, e o tom muda tanto que parece que foi escrito por outro time — ironicamente admitindo, em alguns parágrafos adiante, exatamente como essas mesmas peças podem sobrescrever silenciosamente umas às outras.
Newton é uma camada de política que verifica uma transação em relação a regras antes que ela seja liquidada, escrita em Rego e avaliada com base em dados obtidos de oráculos do PolicyData: uma classificação de risco do Vaults.fyi para um cofre, uma triagem da Chainalysis contra endereços sancionados, o quanto um feed de preços da RedStone se desviou de sua própria referência. Todo o restante não importa: decida com base em um único oráculo e pronto. Mas decida com base em mais de um, que é exatamente a proposta de encadear pacotes de política, e a rede executa o WASM de cada oráculo referenciado; em seguida, faz um shallow-merge (mesclagem superficial) da saída JSON de cada um em um único objeto antes mesmo de o Rego avaliá-lo. Esse é o passo de que ninguém se preocupa — até ler o que acontece quando dois desses objetos querem a mesma chave.
A correção em si é bem construída, nos seus próprios termos. Cada oráculo envolve a saída inteira dele sob uma única chave, o id do pack; assim, uma avaliação do Vaults.fyi publica sob data.wasm.vaultsfyi e uma checagem de desancoragem da Webacy publica sob data.wasm.webacy, e um curador escreve um conjunto de regras de deny que lê os dois namespaces sem que um toque no outro. Existe até uma etapa de simulação, pelo dashboard ou diretamente pelo newt_simulatePolicy, que mostra o objeto mesclado antes de qualquer coisa ser implantada. Mas essa etapa é construída para confirmar que suas próprias referências são resolvidas, e não para auditar se algum outro pack teve o cuidado de aninhar o próprio. Você teria que já desconfiar de uma colisão para sair procurando uma em uma saída que, na maior parte do tempo, só vai parecer correta.
Quem teria adivinhado que toda a segurança de uma política multi-oráculo se resume a um engenheiro lembrar de aninhar uma chave? Nada no protocolo verifica se ele fez isso.
E todo o modelo é construído para continuar adicionando oráculos feitos por pessoas que nunca falaram entre si. A Newton não controla quem pode publicar um pack: qualquer provedor de dados ou empresa de risco pode enviar um, e hoje essa lista tem quatro nomes, todos com namespaces corretos, sem colisões até agora. Honestamente, fico indo e voltando nisso: talvez quatro packs, construídos por um único time prestando atenção, seja cedo demais para chamar isso de um risco real. Mas a proposta inteira de uma biblioteca aberta é que quatro viram quarenta, construídos por quarenta times que nunca revisaram os esquemas uns dos outros, e ninguém volta para reauditar os primeiros quatro sempre que aparece um quadragésimo primeiro.
Siga quem realmente arca com o custo e a forma fica mais clara, eu acho. A função de um autor de oráculo termina no momento em que os próprios dados dele resolvem corretamente para o caso de uso dele, e ninguém envia um oráculo de conformidade se preocupando com o nome de um campo que algum time de risco de um cofre completamente não relacionado escolheu meses antes. Pular o wrapper não custa nada para esse autor. Nenhuma verificação em tempo de execução jamais rastrearia uma colisão até eles também, porque, quando duas chaves colidem, a falha aparece dentro da política de outra pessoa, com uma intenção que essa pessoa enviou, não a do oráculo. Isso é um problema de coordenação sem um responsável: todo mundo que poderia impedir individualmente não ganha nada fazendo isso, e a parte posicionada para aplicar a regra fica deliberadamente neutra sobre quem pode publicar um pack, a mesma escolha que elimina qualquer um que poderia rejeitar um wrapper ruim antes que ele seja enviado.
As ferramentas de implantação têm o mesmo hábito. O newton-cli hoje só aceita um único --policy-data-address, então qualquer pessoa que rode mais de um oráculo é encaminhada para o dashboard, que monta corretamente a matriz de dados de política on-chain por sua conta. Monte essa matriz você mesmo e a documentação te alerta para não fazer isso, de forma direta, porque a ordem pode sair de sincronia com o que está registrado na cadeia. O que a documentação nunca deixa bem claro é o que acontece depois se você fizer mesmo assim, o mesmo instinto da mesclagem: avise o desenvolvedor sobre o movimento arriscado, nunca descreva a falha que espera do outro lado.
Nada disso é design descuidado. O padrão deny-set é realmente a escolha certa: empilhar regras de negação independentes em um conjunto, em vez de um único valor, significa que duas condições de falha de dois oráculos diferentes jamais brigam pelo controle de uma única variável; elas apenas caem no conjunto e a política falha fechada, independentemente. Espera-se que os oráculos também identifiquem em namespaces próprios os próprios erros: um provedor que não consegue buscar dados nega por padrão, em vez de passar silenciosamente um vazio. Alguém passou tempo real tratando modos de falha aqui. Eles resolveram os que vivem no namespace próprio de um oráculo, não o que fica na lacuna entre dois deles.
Todo pack na biblioteca hoje aninha a saída dele exatamente do jeito que deveria: isso é o que uma convenção parece quando está simplesmente funcionando, ou é só o que se parece imediatamente antes do primeiro pack que não funciona?