Em 2018, eu assisti a uma apresentação sobre uma solução de custódia “sem confiança” que acabou rodando em um único HSM em algum data center na Virgínia. “Sem confiança” era a palavra de destaque. Depois, você lia três páginas mais fundo na documentação e descobria a premissa real de confiança: confiar no hardware da Amazon, confiar na equipe do data center e confiar no processo de atualização do firmware. A palavra “sem confiança” estava fazendo um grande trabalho de marketing que a arquitetura, na prática, não conquistava. Eu nunca esqueci essa lição, porque custou muito caro para algumas pessoas muito inteligentes terem que reaprender isso em 2022.
Tive a mesma sensação lendo a descrição da pilha do Newton esta semana.
Newton combina TEE, ambientes de execução confiáveis — pense em Phala ou sistemas semelhantes baseados em Intel SGX — junto com ZKP para construir o que ele chama de automação verificável. No papel, isso soa como um time de segurança dos sonhos. Na prática, é um descompasso filosófico vendido como uma garantia unificada, e quase ninguém para para descompactar por que.
Aqui está a distinção real, e ela importa mais do que a maioria das discussões dá a entender. Provas de conhecimento zero são minimizadas em confiança. A segurança vem da matemática — da solidez criptográfica que vale independentemente de quem está executando o hardware ou se eles são maliciosos. Você não precisa confiar em uma parte; você verifica uma prova. TEEs são o oposto total do modelo. Elas se baseiam em confiança. Toda a garantia de segurança depende de acreditar que um pedaço específico de silício — geralmente Intel SGX ou um enclave equivalente — não foi comprometido fisicamente ou logicamente. Isso não é matemática; é fé em uma cadeia de suprimentos e na cadência de patches de firmware.
Agora junte tudo e faça a pergunta óbvia. Qual é o nível de segurança real do sistema combinado? A lógica básica de encadeamento diz que um sistema só é tão forte quanto seu elo mais fraco, e aqui o elo mais fraco não é sutil — é estrutural. O SGX tem um histórico documentado de exploits por canal lateral: Foreshadow, Plundervolt, SGAxe, e a lista vai longe. Cada um deles corroeu a premissa de que o enclave é genuinamente à prova de adulteração. Pesquisadores demonstraram extração de chaves a partir de enclaves SGX múltiplas vezes nos últimos anos, usando ataques de temporização via cache e manipulação de voltagem — métodos que não exigem quebrar qualquer prova criptográfica, apenas quebrar a premissa de hardware subjacente.
Então, quando um sistema se vende como automação verificável porque usa ZKP, isso é verdade em um sentido estreito: o componente ZK realmente é minimizado em confiança. Mas se a camada TEE fica a montante dessa geração de provas, alimentando-a com dados ou executando a lógica que está sendo provada, então o teto real de segurança do pipeline no mundo real fica limitado pela taxa histórica de exploits da TEE, e não pela solidez teórica da matemática ZK. Você pode ter uma prova de conhecimento zero perfeitamente sólida de uma computação que já tinha sido adulterada antes mesmo de a prova ser gerada. A prova verifica corretamente. A execução subjacente já estava comprometida. Ninguém percebe isso olhando apenas para a verificação da prova.
É esse tipo de nuance que separa pessoas que realmente leem diagramas de arquitetura de pessoas que veem a palavra zero-knowledge e param de fazer perguntas. Não é uma acusação: projetos híbridos de TEE com ZK são uma troca de engenharia legítima e pragmática. Ter ZK para cada computação costuma ser computacionalmente brutal, e TEEs oferecem ganhos reais de desempenho. O problema não é a escolha de arquitetura. O problema é quando o marketing apaga a distinção e faz as pessoas assumirem que toda a pilha herda as propriedades de confiança minimizada da camada ZK.
Se você está avaliando Newton ou qualquer coisa construída desse jeito, a pergunta de diligência real não é se usa ZKP. É o que especificamente é provado pela camada ZK, versus o que é apenas atestado pela TEE, e onde exatamente está o limite de confiança (trust boundary). Essa é a diferença entre ler um pitch deck e ler uma arquitetura.