Alguns dias atrás, conversei com um amigo que trabalha com controle de risco on-chain. Foi uma frase dele que me deixou sem resposta.
Ele disse: “Por melhor que seja a sua estratégia, se os dados estiverem errados, todo o sistema na verdade está cometendo um erro de forma deliberada.”
Depois de ouvir, minha primeira reação foi que essa fala parecia um tanto exagerada, mas pensando com calma, era bastante real.
Nos últimos anos, o controle de risco em Web3 vem “brigando” por modelos, por regras e por parâmetros, mas quase ninguém resolve de forma séria um problema de base: de onde vêm os dados e se dá para confiar neles.
Foi ao analisar o mecanismo de sandbox do Newton Protocol que fui entendendo aos poucos o seu design.
Ele não é apenas integrar uma API, nem escolher uma “fonte de dados mais confiável”; ele faz exatamente o contrário: por padrão, todos os dados externos não são confiáveis.
Essa ideia é um pouco ousada.
No lado dos nós, ela executa diretamente o código do provedor de dados; o processo de obtenção de dados externo é colocado num ambiente de sandbox para ser executado. Cada nó busca os dados por conta própria, gera a assinatura, e então devolve o resultado para a agregação.
O foco não está em “quem está certo”, e sim em “cada um roda de forma independente”.
Se alguma fonte de dados cair ou retornar valores anômalos, ela não afeta o sistema global diretamente como nos sistemas tradicionais, porque os resultados de nós diferentes vão se separar claramente; no fim, a diferença converge por meio de estatística.
Em outras palavras, não é para evitar erros; é para impedir que os erros fiquem escondidos.
Um amigo meu ouviu e disse uma frase bem verdadeira: “Não é só desmontar o pote e fazer cada um carregar um pedacinho?”
Tem sim esse sentido, mas o ponto-chave é que ela adiciona três restrições: isolamento de rede, limites de recursos e acesso a caminhos privados.
Traduzindo: você pode entrar, mas não pode sair correndo à vontade, nem pode bisbilhotar os dados dos outros.
Nessa estrutura, a função de $NEWT também é bem direta; não é um token baseado em storytelling.
Ela cobra por computação, banda e número de consultas: quanto mais alguém usa, mais paga. No fundo, é basicamente um “combustível para a camada de execução”.
Isso é bem importante, porque muitos problemas de projetos são: eles têm um sistema, mas não existe um consumo real.
A Newton, pelo menos no design, incorpora “o custo de uso” na camada de protocolo.
Claro, o problema também não é inexistente.
Por exemplo, o sandbox garante que o ambiente de execução esteja limpo, mas não garante que “a própria fonte de dados não traga vieses”. Se a lógica upstream for contaminada, apenas entra no sistema de outro jeito.
Outro problema real é: nesse modelo de repetição de execução por múltiplos nós, essencialmente você troca recursos por confiabilidade; então o custo não vai ser baixo, com certeza.
Depois eu dei uma olhada, por conveniência, nas tendências dos dados na cadeia.
A cena social na verdade está esquentando menos; o interesse em discussão não é tão alto quanto no começo. Mas o interessante é que há outra curva:
As chamadas de execução cross-chain estão aumentando; a atividade de endereços relacionados a MPC também está subindo; e as taxas no lado do protocolo vão subindo devagar.
Isso é bem típico do estado de projetos de infraestrutura: por fora não está tão movimentado, mas por dentro está cada vez mais ocupado.
Quando pensei nessa estrutura pela primeira vez, não me veio à mente um projeto novo, mas sim aquelas coisas do início: oráculos antigos ou aquela leva de pontes cross-chain.
Na época em que a Chainlink começou, era igual: ninguém brigava no Twitter, mas cada vez havia mais integrações no protocolo.
Então, ao olhar para a Newton agora, eu prefiro tratá-la como um experimento de “camada de execução confiável”, e não apenas como um projeto de narrativa de DeFi ou de IA.
O problema que ela resolve não é “se os dados estão certos”, e sim “como fazer para que os dados na cadeia não sejam alterados silenciosamente”.
Se esse caminho funcionar, a importância pode ser maior do que o preço no curto prazo.
Mas se não funcionar, então ainda será apenas mais um sistema complexo.
No fim, ainda é o que eu disse: com projetos assim, não tire conclusões às pressas; primeiro olhe o volume de chamadas e o uso real.