estava lendo a documentação do newton hoje e acabei ficando preso em uma página por mais tempo do que eu pretendia.
este é o guia do oráculo de dados de política, especificamente a parte depois das integrações de referência, onde eles explicam o que acontece quando as opções integradas não cobrem o que você precisa.
o protocolo newton envia, prontamente, uma dúzia de oráculos de referência prontos para uso. chainalysis para triagem de sanções, vaults.fyi para dados de rendimento, etherscan para preços de gas, veriff e persona para KYC. Faça um fork, configure suas chaves e pronto.
essa parte é simples.
no começo, foquei nesses oráculos de referência. a parte mais interessante é o que o Newton deixa você fazer fora deles.
você pode escrever seu próprio oráculo de dados, compilá-lo para um componente wasm e implantá-lo como um contrato de policydata. teste primeiro localmente com o newton-cli policy-data simulate, apontando para seu arquivo wasm e uma entrada de exemplo. uma vez que esteja implantado, sua policy rego lê a saída diretamente de data.wasm, algo como risk_score := data.wasm.risk_score.
é o modelo de leve seu próprio oráculo.
é isso que torna o Newton composable com qualquer fornecedor de compliance ou fonte de dados que um construtor queira, em vez de prender todos em uma lista fixa. mas isso também significa que cada operador na rede concorda em executar código arbitrário de outra pessoa em cada avaliação.
essa escolha de design acompanha isso.
os módulos wasm rodam em memória linear, sem acesso padrão ao sistema de arquivos do host ou à rede. um operador que executa seu oráculo não está confiando no seu código para não fazer algo malicioso; o limite da sandbox é o que impõe isso, independentemente do que você realmente escreveu.
até agora, vai tudo bem.
mas algo continuou me incomodando quanto mais eu pensava a respeito.
a sandbox protege a máquina dos operadores contra seu código. ela não diz nada sobre se seu código está retornando dados bons. um módulo wasm perfeitamente isolado ainda pode buscar de uma API desatualizada, hardcodar um número, ou manipular silenciosamente o que quer que alimente o risk_score — e a sandbox o contém tão limpidamente quanto conteria algo honesto.
então o limite da sandbox não remove a confiança do sistema.
apenas o realoca.
com um oráculo de referência como o chainalysis, essa confiança fica com um fornecedor conhecido, que tem reputação e um ritmo de atualização para proteger. com um oráculo wasm personalizado, isso fica com quem escreveu e enviou o módulo, e o sandboxing do Newton não tem nada a dizer sobre se eles fizeram isso bem.
o operador ainda fica exposto.
os operadores são economicamente vinculados e eles assinam uma atestação dizendo que uma transação cumpriu a policy. a execução contida não torna essa atestação menos errada se o número subjacente já estava ruim quando entrou.
o risco não desapareceu.
foi para outro lugar.
sandboxing ainda é o primeiro passo certo aqui. você não pode permitir que código de terceiros arbitrário fique perto do processo do host de um operador, independentemente do que ele retorne. a parte que eu ainda não resolvi completamente é se o Newton eventualmente precisa de alguma forma de atestação do próprio provedor de dados, e não apenas do isolamento do código que busca esses dados.
envolver a execução de um oráculo em uma sandbox wasm reduz de forma significativa o risco sistêmico no protocolo Newton, ou isso apenas garante que uma fonte de dados ruim falhe de maneira segura em vez de simplesmente ser interceptada?
@NewtonProtocol #Newt $NEWT $TLM $BIRB