Vocês viram esses dias os textos curtos sobre o Newton Protocol? O principal argumento que eles têm martelado, o tempo todo, é a tal “camada descentralizada de automação verificável”. Soa bem pesado, bem Web3, não soa?
Tenho um hábito: quando vejo esse tipo de termo chique e sofisticado, eu gosto de ir “a fundo” na arquitetura técnica por baixo. Aí, seguindo a documentação de desenvolvimento deles, fui fuçando um bom tempo e, no final, eu fiquei literalmente de cara. Existe um ciclo lógico fundamental que não fecha aqui: a Newton fica o tempo todo gritando “descentralização”, mas no nível mais baixo a TEE (ambiente de execução confiável) roda toda na AWS (Amazon Cloud). Ou seja, você acha que está confiando na blockchain, mas na prática acaba entregando todas as chaves de segurança para a Amazon.
Hoje vamos conversar com palavras bem simples, sem nenhum filtro de jargão do setor, para falar sobre quantas “armadilhas” existem por trás desse suposto “automação descentralizada”.
I. O que chamam de “verificável” — na etapa final, ainda depende do humor da Amazon
Primeiro, todo mundo precisa entender a lógica do TEE. O código é realmente imutável, e os arquivos de prova gerados também realmente podem ser enviados para a cadeia para validação — parece tudo certo. Mas o problema é que o TEE usado pela Newton roda no AWS Nitro Enclaves da Amazon; no fim, a prova de medição/quantificação de “distância” (ou “medição remota”) é emitida pela própria AWS!
O que isso significa?
A AWS assume a responsabilidade; só aí sua validação é considerada válida.
Se a AWS não reconhecer, ou por algum motivo for obrigada a não reconhecer, suas operações automatizadas viram diretamente uma piada.
Isso não é exatamente uma “transferência de confiança”? Você só está trocando a confiança no time do projeto pela confiança no maior gigante tradicional da internet — a Amazon. Se isso ainda for chamado de descentralização, então nem brinquem de blockchain: desenvolvam diretamente com servidores do Web2.
II. Em caso de força maior, a Newton simplesmente não tem um Plano B
O que mais preocupa é que, quando revirei de cabo a rabo a documentação técnica oficial, não vi absolutamente nenhuma descrição sobre “solução de hardware reserva” ou “mecanismo de desastre com múltiplas clouds”.
Isso não é preocupação à toa da minha parte. Quem trabalha com tecnologia sabe: nesse tipo de arquitetura que depende fortemente de um único fornecedor de serviço, o risco não é algo que o código consegue resolver — ele é determinado pelos interesses comerciais por trás ou por fatores geopolíticos externos.
Vamos supor um cenário extremo: > Um certo dia, por exigências de conformidade de políticas ou algum outro fator de força maior, o governo dos EUA exige que a AWS coopere com uma auditoria. A AWS só precisa levantar a mão e parar a emissão de provas TEE rodando no Nitro Enclaves — e a capacidade de validação de toda a rede Newton entra em colapso instantaneamente.
Diante desse tipo de evento “cisne negro” com potencial de destruição enorme, aparentemente o projeto não tem nenhum plano de contingência até agora.
Alguém talvez venha rebater: “Ao menos com isolamento de hardware TEE, é melhor do que depender totalmente do projeto para fazer operações de caixa-preta?”
Não dá para dizer assim. Quando você transfere o ponto âncora da confiança do projeto para a Amazon, você troca um monstro gigantesco por outro — um que você entende menos e não consegue controlar. Você não tem como saber as políticas internas de operação da AWS, padrões de conformidade, nem mesmo o histórico de quedas. Na história da internet, quantas vezes a AWS teve grandes apagões? Em nenhuma delas faltou derrubar, junto, centenas de serviços de internet que dependiam dela? Se a AWS tiver uma falha, a prova do TEE nem sequer conseguirá ser gerada; as estratégias automatizadas do usuário travam no meio do caminho, em um beco sem saída.
III. A cadeia de confiança é esticada demais; no meio tudo vira um “boneco de hardware” das empresas americanas
Você acha que basta confiar na Amazon? Vamos desmontar com cuidado a cadeia de confiança desse TEE, e você vai perceber que tem um “matryoshka” dentro de outro, daqueles que assustam.
A segurança central do hardware TEE, no fim das contas, depende das chaves-mestre injetadas pelos fabricantes de chips na fábrica. Atualmente, o hardware mais comum no mercado é da Intel (Intel) e da AMD. Então, se quisermos completar uma suposta “negociação automatizada verificável”, o caminho real de confiança é, na verdade, assim:
Passo 1: envie seus comandos de negociação automatizada para o protocolo Newton.
Passo 2: a Newton entrega a estratégia para rodar nos servidores de nuvem da AWS.
Passo 3: o ambiente de execução do TEE da AWS depende de chaves de hardware (segredos) de criptografia dos chips Intel ou AMD para isolar a execução.
Passo 4: depois que a execução termina, um sistema de conformidade da AWS emite uma prova de medição remota.
Passo 5: envie as provas de volta para a cadeia da Newton e conclua a validação final on-chain.
Vamos contar: são nada menos do que cinco camadas de cadeia de confiança! Apenas a última — ou seja, a etapa em que a prova é validada na cadeia — é pública e transparente na blockchain. As quatro primeiras camadas (nós da Newton, plataforma cloud da AWS, chips Intel e chips AMD) são todas entidades centralizadas em 100%. No vai e vem de um monte de voltas, a gente saiu de “confiar no time da Newton” para “confiar também na Amazon + na Intel + na AMD”. Isso é realmente uma melhoria em termos de experiência para comunidades cripto que buscam descentralização?
IV. O chamado “no futuro haverá transição” é mais como uma promessa distante e sem prazo
Na verdade, bem cedo, já havia um pessoal na comunidade que identificou esse problema e questionou o projeto: “Já que a Newton se promove como uma camada de automação automatizada descentralizada, por que ela mesma não monta um cluster físico distribuído de TEE em vez de depender da AWS?”
Na época, a resposta oficial em linhas gerais foi: “Para eficiência de desenvolvimento e execução no início, priorizamos soluções de provedores de nuvem estabelecidos. No futuro, vamos fazer uma transição gradual para uma rede de hardware físico totalmente descentralizada.”
Isso fica bem interessante. “Futuro” vai ser quanto tempo? Três meses, um ano, ou até o projeto não conseguir mais continuar e ninguém ver? No seu roadmap oficial publicado, a Newton não escreveu nem um único marco temporal específico para este crucial “período de transição de descentralização de hardware”. Ou seja, antes disso, cada “estratégia verificável” que roda na rede e é promovida como algo fantástico, ainda mantém a “porta” que faz a última checagem — nas mãos firmes de um gigante centralizado.
Resumindo
Uma rede que, em alto e bom som, se diz descentralizada, mas seu módulo mais central de validação automática roda no maior servidor cloud centralizado do mundo — isso, por si só, é uma ironia enorme.
O TEE é, de fato, uma boa tecnologia e é muito útil para computação de privacidade. Mas todo mundo precisa estar plenamente consciente de uma coisa: a tecnologia TEE em si não resolve o problema de “desconfiança” do Web3; ela só transfere nossa confiança de “pessoas” para “gigantes de hardware” e “provedores de cloud”. Se você joga no mundo cripto buscando controle absoluto e resistência à censura, então a arquitetura técnica atual da Newton, que depende fortemente da AWS, é para você um risco que não dá para ignorar.
(Este artigo é uma tarefa da plataforma e não constitui nenhuma recomendação de investimento.)