5 postagens marcadas com "privacidade"

Blockchains públicas oferecem um livro-razão sincronizado e auditável, mas expõem todos os dados por padrão. Lançado na Sui Mainnet em 3 de setembro de 2025, o Seal resolve esse dilema ao combinar lógica de políticas on-chain com gerenciamento descentralizado de chaves, permitindo que builders decidam exatamente quem pode descriptografar cada payload.

Resumo​

• O que é: Seal é uma rede de gestão de segredos que permite aos contratos inteligentes da Sui aplicar políticas de descriptografia on-chain enquanto os clientes criptografam dados com criptografia baseada em identidade (IBE) e dependem de servidores de chaves com limiar para derivar as chaves.
• Por que importa: Em vez de backends personalizados ou scripts opacos fora da cadeia, privacidade e controle de acesso tornam-se primitivas de Move de primeira classe. Os desenvolvedores podem armazenar os cifrados em qualquer lugar—Walrus é o complemento natural—e ainda controlar quem pode ler.
• Quem se beneficia: Equipes que entregam conteúdo tokenizado, revelações com bloqueio temporal, mensagens privadas ou agentes de IA guiados por políticas podem integrar o SDK do Seal e focar na lógica do produto, não na infraestrutura criptográfica.

A lógica de políticas vive em Move​

Os pacotes do Seal incluem funções Move seal_approve* que definem quem pode solicitar chaves para um determinado identificador e em quais condições. As políticas podem combinar propriedade de NFT, listas de permissão, bloqueios temporais ou sistemas de papéis personalizados. Quando um usuário ou agente solicita descriptografia, os servidores de chaves avaliam essas políticas consultando o estado de um full node da Sui e só aprovam se a cadeia concordar.

Como as regras de acesso fazem parte do seu pacote on-chain, elas são transparentes, auditáveis e versionadas junto com o restante do código do contrato inteligente. Atualizações de governança podem ser implementadas como qualquer upgrade de Move, com revisão da comunidade e histórico on-chain.

Criptografia de limiar gerencia as chaves​

O Seal criptografa dados para identidades definidas pela aplicação. Um comitê de servidores de chaves independentes—escolhido pelo desenvolvedor—compartilha o segredo mestre de IBE. Quando a verificação de política é aprovada, cada servidor deriva uma fração de chave para a identidade solicitada. Quando o quórum de t servidores responde, o cliente combina as frações para obter uma chave de descriptografia utilizável.

Você controla o equilíbrio entre disponibilidade e confidencialidade ao escolher os membros do comitê (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One ou o serviço Enoki da Mysten) e definir o limiar. Precisa de mais disponibilidade? Selecione um comitê maior com limiar menor. Quer garantias de privacidade mais fortes? Endureça o quórum e privilegie provedores permissionados.

Experiência do desenvolvedor: SDK e chaves de sessão​

O Seal oferece um SDK TypeScript (npm i @mysten/seal) que cuida dos fluxos de criptografia/descriptografia, formatação de identidades e batching. Ele também emite chaves de sessão para evitar que carteiras recebam prompts constantes quando o app precisa de acesso repetido. Para fluxos avançados, contratos Move podem solicitar descriptografia on-chain em modos especiais, permitindo que lógicas como revelações em escrow ou leilões resistentes a MEV sejam executadas diretamente no código do contrato.

Como o Seal é agnóstico quanto ao armazenamento, as equipes podem combiná-lo com Walrus para blobs verificáveis, com IPFS ou até com repositórios centralizados quando o cenário operacional exigir. O limite de criptografia—e a aplicação das políticas—acompanha os dados independentemente de onde o cifrado esteja armazenado.

Boas práticas ao projetar com Seal​

• Modele o risco de disponibilidade: Limiares como 2-de-3 ou 3-de-5 se traduzem diretamente em garantias de uptime. Implantações em produção devem misturar provedores, monitorar telemetria e estabelecer SLA antes de delegar fluxos críticos.
• Atenção à variação de estado: A avaliação de políticas depende de chamadas dry_run em full nodes. Evite regras que dependam de contadores que mudam rapidamente ou da ordenação dentro do checkpoint para prevenir aprovações inconsistentes entre servidores.
• Planeje a higiene das chaves: As chaves derivadas residem no cliente. Implemente logs, gire chaves de sessão e considere criptografia envelope—use o Seal para proteger uma chave simétrica que cifra o payload maior—para limitar o impacto caso um dispositivo seja comprometido.
• Projete para rotação: O comitê usado em um cifrado fica fixo no momento da criptografia. Crie caminhos de upgrade que recriptografem os dados com novos comitês quando for necessário trocar provedores ou ajustar as hipóteses de confiança.

Próximos passos​

O roadmap do Seal aponta para servidores MPC operados por validadores, ferramentas de cliente no estilo DRM e opções de KEM pós-quântico. Para builders que exploram agentes de IA, conteúdo premium ou fluxos de dados regulados, a versão atual já oferece um plano claro: codifique sua política em Move, componha um comitê de chaves diversificado e entregue experiências criptografadas que respeitem a privacidade do usuário sem sair da zona de confiança da Sui.

Se estiver avaliando o Seal para seu próximo lançamento, comece prototipando uma política simples com NFT e um comitê aberto 2-de-3, depois evolua para a combinação de provedores e controles operacionais que correspondam ao perfil de risco do seu aplicativo.

1. Visão Geral da Tecnologia TEE​

Definição e Arquitetura: Um Ambiente de Execução Confiável (TEE) é uma área segura de um processador que protege o código e os dados carregados dentro dele em relação à confidencialidade e integridade. Em termos práticos, um TEE atua como um "enclave" isolado dentro da CPU – uma espécie de caixa preta onde computações sensíveis podem ser executadas, protegidas do resto do sistema. O código executado dentro de um enclave TEE é protegido de tal forma que mesmo um sistema operacional ou hipervisor comprometido não pode ler ou adulterar os dados ou o código do enclave. As principais propriedades de segurança fornecidas pelos TEEs incluem:

• Isolamento: A memória do enclave é isolada de outros processos e até mesmo do kernel do SO. Mesmo que um invasor obtenha privilégios de administrador completos na máquina, ele não pode inspecionar ou modificar diretamente a memória do enclave.
• Integridade: O hardware garante que o código executado no TEE não possa ser alterado por ataques externos. Qualquer adulteração do código do enclave ou do estado de tempo de execução será detectada, evitando resultados comprometidos.
• Confidencialidade: Os dados dentro do enclave permanecem criptografados na memória e são descriptografados apenas para uso dentro da CPU, de modo que dados secretos não são expostos em texto simples para o mundo exterior.
• Atestado Remoto: O TEE pode produzir provas criptográficas (atestados) para convencer uma parte remota de que é genuíno e que um código confiável específico está sendo executado dentro dele. Isso significa que os usuários podem verificar se um enclave está em um estado confiável (por exemplo, executando o código esperado em hardware genuíno) antes de provisioná-lo com dados secretos.

Diagrama conceitual de um Ambiente de Execução Confiável como um enclave seguro "caixa preta" para a execução de contratos inteligentes. Entradas criptografadas (dados e código do contrato) são descriptografadas e processadas dentro do enclave seguro, e apenas resultados criptografados saem do enclave. Isso garante que os dados sensíveis do contrato permaneçam confidenciais para todos fora do TEE.

Nos bastidores, os TEEs são habilitados por criptografia de memória baseada em hardware e controle de acesso na CPU. Por exemplo, quando um enclave TEE é criado, a CPU aloca uma região de memória protegida para ele e usa chaves dedicadas (gravadas no hardware ou gerenciadas por um coprocessador seguro) para criptografar/descriptografar dados em tempo real. Qualquer tentativa de software externo de ler a memória do enclave obtém apenas bytes criptografados. Essa proteção única no nível da CPU permite que até mesmo o código de nível de usuário defina regiões de memória privadas (enclaves) que malwares privilegiados ou até mesmo um administrador de sistema mal-intencionado não podem espionar ou modificar. Em essência, um TEE fornece um nível mais alto de segurança para aplicações do que o ambiente operacional normal, ao mesmo tempo que é mais flexível do que elementos seguros dedicados ou módulos de segurança de hardware.

Principais Implementações de Hardware: Existem várias tecnologias de TEE de hardware, cada uma com arquiteturas diferentes, mas com o objetivo semelhante de criar um enclave seguro dentro do sistema:

• Intel SGX (Software Guard Extensions): O Intel SGX é uma das implementações de TEE mais utilizadas. Ele permite que as aplicações criem enclaves no nível do processo, com criptografia de memória e controles de acesso impostos pela CPU. Os desenvolvedores devem particionar seu código em código "confiável" (dentro do enclave) e código "não confiável" (mundo normal), usando instruções especiais (ECALL/OCALL) para transferir dados para dentro e para fora do enclave. O SGX fornece um forte isolamento para enclaves e suporta atestado remoto através do Serviço de Atestado da Intel (IAS). Muitos projetos de blockchain – notavelmente a Secret Network e a Oasis Network – construíram funcionalidades de contratos inteligentes que preservam a privacidade em enclaves SGX. No entanto, o design do SGX em arquiteturas x86 complexas levou a algumas vulnerabilidades (ver §4), e o atestado da Intel introduz uma dependência de confiança centralizada.

• ARM TrustZone: O TrustZone adota uma abordagem diferente, dividindo todo o ambiente de execução do processador em dois mundos: um Mundo Seguro e um Mundo Normal. O código sensível é executado no Mundo Seguro, que tem acesso a certas memórias e periféricos protegidos, enquanto o Mundo Normal executa o SO e as aplicações regulares. As trocas entre os mundos são controladas pela CPU. O TrustZone é comumente usado em dispositivos móveis e IoT para coisas como interface de usuário segura, processamento de pagamentos ou gerenciamento de direitos digitais. Em um contexto de blockchain, o TrustZone poderia habilitar aplicações Web3 focadas em dispositivos móveis, permitindo que chaves privadas ou lógica sensível sejam executadas no enclave seguro do telefone. No entanto, os enclaves do TrustZone são tipicamente de granularidade maior (no nível do SO ou VM) e não são tão comumente adotados nos projetos Web3 atuais quanto o SGX.

• AMD SEV (Secure Encrypted Virtualization): A tecnologia SEV da AMD visa ambientes virtualizados. Em vez de exigir enclaves no nível da aplicação, o SEV pode criptografar a memória de máquinas virtuais inteiras. Ele usa um processador de segurança embutido para gerenciar chaves criptográficas e realizar a criptografia de memória, de modo que a memória de uma VM permaneça confidencial até mesmo para o hipervisor hospedeiro. Isso torna o SEV bem adequado para casos de uso em nuvem ou servidor: por exemplo, um nó de blockchain ou um trabalhador off-chain poderia ser executado dentro de uma VM totalmente criptografada, protegendo seus dados de um provedor de nuvem mal-intencionado. O design do SEV significa menos esforço do desenvolvedor para particionar o código (você pode executar uma aplicação existente ou até mesmo um SO inteiro em uma VM protegida). Iterações mais recentes como o SEV-SNP adicionam recursos como detecção de adulteração e permitem que os proprietários de VMs atestem suas VMs sem depender de um serviço centralizado. O SEV é altamente relevante para o uso de TEE em infraestrutura de blockchain baseada em nuvem.

Outras implementações de TEE emergentes ou de nicho incluem o Intel TDX (Trust Domain Extensions, para proteção semelhante a enclaves em VMs em chips Intel mais recentes), TEEs de código aberto como o Keystone (RISC-V) e chips de enclave seguro em dispositivos móveis (como o Secure Enclave da Apple, embora geralmente não aberto para código arbitrário). Cada TEE vem com seu próprio modelo de desenvolvimento e suposições de confiança, mas todos compartilham a ideia central de execução segura isolada por hardware.

2. Aplicações de TEEs na Web3​

Os Ambientes de Execução Confiáveis tornaram-se uma ferramenta poderosa para enfrentar alguns dos desafios mais difíceis da Web3. Ao fornecer uma camada de computação segura e privada, os TEEs possibilitam novas oportunidades para aplicações de blockchain em áreas de privacidade, escalabilidade, segurança de oráculos e integridade. Abaixo, exploramos os principais domínios de aplicação:

Contratos Inteligentes que Preservam a Privacidade​

Um dos usos mais proeminentes dos TEEs na Web3 é permitir contratos inteligentes confidenciais – programas que são executados em uma blockchain, mas que podem lidar com dados privados de forma segura. Blockchains como a Ethereum são transparentes por padrão: todos os dados de transação e o estado do contrato são públicos. Essa transparência é problemática para casos de uso que exigem confidencialidade (por exemplo, negociações financeiras privadas, votações secretas, processamento de dados pessoais). Os TEEs fornecem uma solução atuando como um enclave de computação que preserva a privacidade, conectado à blockchain.

Em um sistema de contrato inteligente alimentado por TEE, as entradas da transação podem ser enviadas para um enclave seguro em um nó validador ou trabalhador, processadas dentro do enclave onde permanecem criptografadas para o mundo exterior, e então o enclave pode produzir um resultado criptografado ou em hash de volta para a cadeia. Apenas as partes autorizadas com a chave de descriptografia (ou a própria lógica do contrato) podem acessar o resultado em texto simples. Por exemplo, a Secret Network usa o Intel SGX em seus nós de consenso para executar contratos inteligentes CosmWasm em entradas criptografadas, de modo que coisas como saldos de contas, valores de transação ou estado do contrato possam ser mantidos ocultos do público, mas ainda assim utilizáveis em computações. Isso permitiu aplicações de DeFi secreto – por exemplo, trocas de tokens privadas onde os valores são confidenciais, ou leilões secretos onde os lances são criptografados e revelados apenas após o fechamento do leilão. Outro exemplo é o Parcel da Oasis Network e o ParaTime confidencial, que permitem que os dados sejam tokenizados e usados em contratos inteligentes sob restrições de confidencialidade, possibilitando casos de uso como pontuação de crédito ou dados médicos em blockchain com conformidade de privacidade.

Contratos inteligentes que preservam a privacidade via TEEs são atraentes para a adoção empresarial e institucional da blockchain. As organizações podem aproveitar os contratos inteligentes enquanto mantêm a lógica de negócios e os dados sensíveis confidenciais. Por exemplo, um banco poderia usar um contrato habilitado para TEE para lidar com pedidos de empréstimo ou liquidações de negociação sem expor os dados do cliente na cadeia, mas ainda se beneficiar da transparência e integridade da verificação da blockchain. Essa capacidade aborda diretamente os requisitos de privacidade regulatórios (como GDPR ou HIPAA), permitindo o uso compatível da blockchain em saúde, finanças e outras indústrias sensíveis. De fato, os TEEs facilitam a conformidade com as leis de proteção de dados, garantindo que os dados pessoais possam ser processados dentro de um enclave com apenas saídas criptografadas, satisfazendo os reguladores de que os dados estão protegidos.

Além da confidencialidade, os TEEs também ajudam a impor a justiça nos contratos inteligentes. Por exemplo, uma exchange descentralizada poderia executar seu motor de correspondência dentro de um TEE para evitar que mineradores ou validadores vejam ordens pendentes e façam front-running injustamente. Em resumo, os TEEs trazem uma camada de privacidade muito necessária para a Web3, desbloqueando aplicações como DeFi confidencial, votação/governança privada e contratos empresariais que antes eram inviáveis em livros-razão públicos.

Escalabilidade e Computação Off-Chain​

Outro papel crítico para os TEEs é melhorar a escalabilidade da blockchain, descarregando computações pesadas para fora da cadeia em um ambiente seguro. As blockchains têm dificuldades com tarefas complexas ou computacionalmente intensivas devido a limites de desempenho e custos de execução na cadeia. A computação off-chain habilitada por TEE permite que essas tarefas sejam feitas fora da cadeia principal (não consumindo gás de bloco ou diminuindo o rendimento na cadeia), mantendo ainda as garantias de confiança sobre a correção dos resultados. Com efeito, um TEE pode servir como um acelerador de computação off-chain verificável para a Web3.

Por exemplo, a plataforma iExec usa TEEs para criar um mercado de computação em nuvem descentralizado onde os desenvolvedores podem executar computações off-chain e obter resultados confiáveis pela blockchain. Um dApp pode solicitar uma computação (digamos, uma inferência de modelo de IA complexa ou uma análise de big data) a ser feita pelos nós de trabalho do iExec. Esses nós de trabalho executam a tarefa dentro de um enclave SGX, produzindo um resultado juntamente com um atestado de que o código correto foi executado em um enclave genuíno. O resultado é então retornado na cadeia, e o contrato inteligente pode verificar o atestado do enclave antes de aceitar a saída. Essa arquitetura permite que cargas de trabalho pesadas sejam tratadas off-chain sem sacrificar a confiança, aumentando efetivamente o rendimento. A integração do iExec Orchestrator com o Chainlink demonstra isso: um oráculo Chainlink busca dados externos, depois entrega uma computação complexa para os trabalhadores TEE do iExec (por exemplo, agregando ou pontuando os dados), e finalmente o resultado seguro é entregue na cadeia. Os casos de uso incluem coisas como cálculos de seguro descentralizados (como o iExec demonstrou), onde muita análise de dados pode ser feita off-chain e de forma barata, com apenas o resultado final indo para a blockchain.

A computação off-chain baseada em TEE também sustenta algumas soluções de escalonamento de Camada 2. O protótipo inicial da Oasis Labs, Ekiden (o precursor da Oasis Network), usou enclaves SGX para executar transações off-chain em paralelo, e depois confirmar apenas as raízes de estado na cadeia principal, efetivamente semelhante às ideias de rollup, mas usando confiança de hardware. Ao fazer a execução de contratos em TEEs, eles alcançaram alto rendimento enquanto confiavam nos enclaves para preservar a segurança. Outro exemplo é o futuro L2 Op-Succinct da Sanders Network, que combina TEEs e zkSNARKs: os TEEs executam transações de forma privada e rápida, e então provas zk são geradas para provar a correção dessas execuções para a Ethereum. Essa abordagem híbrida aproveita a velocidade do TEE e a verificabilidade do ZK para uma solução L2 escalável e privada.

Em geral, os TEEs podem executar computações com desempenho quase nativo (já que usam instruções reais da CPU, apenas com isolamento), então são ordens de magnitude mais rápidos do que alternativas puramente criptográficas como criptografia homomórfica ou provas de conhecimento zero para lógica complexa. Ao descarregar o trabalho para enclaves, as blockchains podem lidar com aplicações mais complexas (como aprendizado de máquina, processamento de imagem/áudio, análises grandes) que seriam impraticáveis na cadeia. Os resultados retornam com um atestado, que o contrato na cadeia ou os usuários podem verificar como originários de um enclave confiável, preservando assim a integridade dos dados e a correção. Este modelo é frequentemente chamado de "computação off-chain verificável", e os TEEs são um pilar para muitos desses designs (por exemplo, o Trusted Compute Framework do Hyperledger Avalon, desenvolvido pela Intel, iExec e outros, usa TEEs para executar bytecode EVM off-chain com prova de correção postada na cadeia).

Oráculos Seguros e Integridade de Dados​

Oráculos conectam blockchains com dados do mundo real, mas introduzem desafios de confiança: como um contrato inteligente pode confiar que um feed de dados off-chain está correto e não foi adulterado? Os TEEs fornecem uma solução servindo como um sandbox seguro para nós de oráculo. Um nó de oráculo baseado em TEE pode buscar dados de fontes externas (APIs, serviços web) e processá-los dentro de um enclave que garante que os dados não foram manipulados pelo operador do nó ou por um malware no nó. O enclave pode então assinar ou atestar a veracidade dos dados que fornece. Isso melhora significativamente a integridade e a confiabilidade dos dados do oráculo. Mesmo que um operador de oráculo seja mal-intencionado, ele não pode alterar os dados sem quebrar o atestado do enclave (que a blockchain detectará).

Um exemplo notável é o Town Crier, um sistema de oráculo desenvolvido em Cornell que foi um dos primeiros a usar enclaves Intel SGX para fornecer dados autenticados a contratos Ethereum. O Town Crier recuperava dados (por exemplo, de sites HTTPS) dentro de um enclave SGX e os entregava a um contrato juntamente com uma evidência (uma assinatura do enclave) de que os dados vieram diretamente da fonte e não foram forjados. O Chainlink reconheceu o valor disso e adquiriu o Town Crier em 2018 para integrar oráculos baseados em TEE em sua rede descentralizada. Hoje, o Chainlink e outros provedores de oráculos têm iniciativas de TEE: por exemplo, o DECO e os Fair Sequencing Services do Chainlink envolvem TEEs para garantir a confidencialidade dos dados e a ordenação justa. Como observado em uma análise, "o TEE revolucionou a segurança dos oráculos ao fornecer um ambiente à prova de adulteração para o processamento de dados... até mesmo os próprios operadores de nós não podem manipular os dados enquanto estão sendo processados". Isso é particularmente crucial para feeds de dados financeiros de alto valor (como oráculos de preços para DeFi): um TEE pode impedir até mesmo adulterações sutis que poderiam levar a grandes explorações.

Os TEEs também permitem que os oráculos lidem com dados sensíveis ou proprietários que não poderiam ser publicados em texto simples em uma blockchain. Por exemplo, uma rede de oráculos poderia usar enclaves para agregar dados privados (como livros de ordens de ações confidenciais ou dados de saúde pessoais) e alimentar apenas resultados derivados ou provas validadas para a blockchain, sem expor as entradas sensíveis brutas. Dessa forma, os TEEs ampliam o escopo dos dados que podem ser integrados com segurança em contratos inteligentes, o que é crítico para a tokenização de ativos do mundo real (RWA), pontuação de crédito, seguros e outros serviços na cadeia intensivos em dados.

No tópico de pontes cross-chain, os TEEs melhoram de forma semelhante a integridade. As pontes muitas vezes dependem de um conjunto de validadores ou de uma multi-sig para custodiar ativos e validar transferências entre cadeias, o que as torna alvos principais para ataques. Ao executar a lógica do validador da ponte dentro de TEEs, pode-se proteger as chaves privadas e os processos de verificação da ponte contra adulteração. Mesmo que o SO de um validador seja comprometido, o invasor não deve ser capaz de extrair chaves privadas ou falsificar mensagens de dentro do enclave. Os TEEs podem impor que as transações da ponte sejam processadas exatamente de acordo com as regras do protocolo, reduzindo o risco de operadores humanos ou malware injetarem transferências fraudulentas. Além disso, os TEEs podem permitir que trocas atômicas e transações cross-chain sejam tratadas em um enclave seguro que completa ambos os lados ou aborta de forma limpa, evitando cenários onde os fundos ficam presos devido a interferência. Vários projetos de pontes e consórcios exploraram a segurança baseada em TEE para mitigar a praga de hacks de pontes que ocorreram nos últimos anos.

Integridade de Dados e Verificabilidade Off-Chain​

Em todos os cenários acima, um tema recorrente é que os TEEs ajudam a manter a integridade dos dados mesmo fora da blockchain. Como um TEE pode provar qual código está executando (via atestado) e pode garantir que o código seja executado sem interferência, ele fornece uma forma de computação verificável. Usuários e contratos inteligentes podem confiar nos resultados vindos de um TEE como se tivessem sido computados na cadeia, desde que o atestado seja verificado. Essa garantia de integridade é o motivo pelo qual os TEEs são às vezes referidos como trazendo uma "âncora de confiança" para dados e computação off-chain.

No entanto, vale a pena notar que este modelo de confiança transfere algumas suposições para o hardware (ver §4). A integridade dos dados é tão forte quanto a segurança do TEE. Se o enclave for comprometido ou o atestado for forjado, a integridade pode falhar. No entanto, na prática, os TEEs (quando mantidos atualizados) tornam certos ataques significativamente mais difíceis. Por exemplo, uma plataforma de empréstimos DeFi poderia usar um TEE para calcular pontuações de crédito a partir dos dados privados de um usuário off-chain, e o contrato inteligente aceitaria a pontuação apenas se acompanhada por um atestado de enclave válido. Dessa forma, o contrato sabe que a pontuação foi computada pelo algoritmo aprovado em dados reais, em vez de confiar cegamente no usuário ou em um oráculo.

Os TEEs também desempenham um papel nos sistemas emergentes de identidade descentralizada (DID) e autenticação. Eles podem gerenciar com segurança chaves privadas, dados pessoais e processos de autenticação de uma forma que as informações sensíveis do usuário nunca sejam expostas à blockchain ou aos provedores de dApp. Por exemplo, um TEE em um dispositivo móvel poderia lidar com a autenticação biométrica e assinar uma transação de blockchain se a verificação biométrica for aprovada, tudo sem revelar a biometria do usuário. Isso fornece segurança e privacidade no gerenciamento de identidade – um componente essencial se a Web3 for lidar com coisas como passaportes, certificados ou dados de KYC de uma maneira soberana para o usuário.

Em resumo, os TEEs servem como uma ferramenta versátil na Web3: eles permitem confidencialidade para a lógica na cadeia, permitem escalonamento via computação segura off-chain, protegem a integridade de oráculos e pontes, e abrem novos usos (de identidade privada a compartilhamento de dados compatível). A seguir, veremos projetos específicos que aproveitam essas capacidades.

3. Projetos Web3 Notáveis que Utilizam TEEs​

Vários projetos de blockchain líderes construíram suas ofertas principais em torno de Ambientes de Execução Confiáveis. Abaixo, mergulhamos em alguns notáveis, examinando como cada um usa a tecnologia TEE e que valor único ela adiciona:

Secret Network​

A Secret Network é uma blockchain de camada 1 (construída no Cosmos SDK) que foi pioneira em contratos inteligentes que preservam a privacidade usando TEEs. Todos os nós validadores na Secret Network executam enclaves Intel SGX, que executam o código do contrato inteligente de modo que o estado do contrato e as entradas/saídas permaneçam criptografados até mesmo para os operadores dos nós. Isso torna a Secret uma das primeiras plataformas de contrato inteligente com privacidade em primeiro lugar – a privacidade não é um complemento opcional, mas uma característica padrão da rede no nível do protocolo.

No modelo da Secret Network, os usuários enviam transações criptografadas, que os validadores carregam em seu enclave SGX para execução. O enclave descriptografa as entradas, executa o contrato (escrito em um tempo de execução CosmWasm modificado) e produz saídas criptografadas que são escritas na blockchain. Apenas usuários com a chave de visualização correta (ou o próprio contrato com sua chave interna) podem descriptografar e visualizar os dados reais. Isso permite que as aplicações usem dados privados na cadeia sem revelá-los publicamente.

A rede demonstrou vários casos de uso inovadores:

• DeFi Secreto: por exemplo, SecretSwap (um AMM) onde os saldos das contas dos usuários e os valores das transações são privados, mitigando o front-running e protegendo as estratégias de negociação. Provedores de liquidez e traders podem operar sem transmitir todos os seus movimentos para os concorrentes.
• Leilões Secretos: Contratos de leilão onde os lances são mantidos em segredo até o final do leilão, evitando comportamento estratégico baseado nos lances de outros.
• Votação e Governança Privadas: Detentores de tokens podem votar em propostas sem revelar suas escolhas de voto, enquanto a contagem ainda pode ser verificada – garantindo uma governança justa e livre de intimidação.
• Mercados de dados: Conjuntos de dados sensíveis podem ser transacionados e usados em computações sem expor os dados brutos a compradores ou nós.

A Secret Network essencialmente incorpora TEEs no nível do protocolo para criar uma proposta de valor única: ela oferece privacidade programável. Os desafios que eles enfrentam incluem a coordenação do atestado de enclave em um conjunto de validadores descentralizado e o gerenciamento da distribuição de chaves para que os contratos possam descriptografar as entradas, mantendo-as secretas para os validadores. De todas as formas, a Secret provou a viabilidade da confidencialidade alimentada por TEE em uma blockchain pública, estabelecendo-se como líder no espaço.

Oasis Network​

A Oasis Network é outra camada 1 voltada para escalabilidade e privacidade, que utiliza extensivamente TEEs (Intel SGX) em sua arquitetura. A Oasis introduziu um design inovador que separa o consenso da computação em diferentes camadas chamadas de Camada de Consenso e Camada ParaTime. A Camada de Consenso lida com a ordenação e finalidade da blockchain, enquanto cada ParaTime pode ser um ambiente de tempo de execução para contratos inteligentes. Notavelmente, o ParaTime Emerald da Oasis é um ambiente compatível com EVM, e o Sapphire é um EVM confidencial que usa TEEs para manter o estado do contrato inteligente privado.

O uso de TEEs pela Oasis é focado na computação confidencial em escala. Ao isolar a computação pesada em ParaTimes paralelizáveis (que podem ser executados em muitos nós), eles alcançam alto rendimento, e ao usar TEEs dentro desses nós ParaTime, eles garantem que as computações possam incluir dados sensíveis sem revelá-los. Por exemplo, uma instituição poderia executar um algoritmo de pontuação de crédito na Oasis alimentando dados privados em um ParaTime confidencial – os dados permanecem criptografados para o nó (já que são processados no enclave), e apenas a pontuação sai. Enquanto isso, o consenso da Oasis apenas registra a prova de que a computação ocorreu corretamente.

Tecnicamente, a Oasis adicionou camadas extras de segurança além do SGX padrão. Eles implementaram uma "raiz de confiança em camadas": usando o Enclave de Cotação SGX da Intel e um kernel leve personalizado para verificar a confiabilidade do hardware e para isolar as chamadas de sistema do enclave. Isso reduz a superfície de ataque (filtrando quais chamadas de SO os enclaves podem fazer) e protege contra certos ataques conhecidos ao SGX. A Oasis também introduziu recursos como enclaves duráveis (para que os enclaves possam persistir o estado entre reinicializações) e logging seguro para mitigar ataques de rollback (onde um nó pode tentar reproduzir um estado antigo do enclave). Essas inovações foram descritas em seus artigos técnicos e são parte do motivo pelo qual a Oasis é vista como um projeto impulsionado pela pesquisa em computação de blockchain baseada em TEE.

De uma perspectiva de ecossistema, a Oasis se posicionou para coisas como DeFi privado (permitindo que bancos participem sem vazar dados de clientes) e tokenização de dados (onde indivíduos ou empresas podem compartilhar dados com modelos de IA de maneira confidencial e serem compensados, tudo através da blockchain). Eles também colaboraram com empresas em projetos piloto (por exemplo, trabalhando com a BMW em privacidade de dados, e outros em compartilhamento de dados de pesquisa médica). No geral, a Oasis Network mostra como a combinação de TEEs com uma arquitetura escalável pode abordar tanto a privacidade quanto o desempenho, tornando-a um player significativo em soluções Web3 baseadas em TEE.

Sanders Network​

A Sanders Network é uma rede de computação em nuvem descentralizada no ecossistema Polkadot que usa TEEs para fornecer serviços de computação confidenciais e de alto desempenho. É uma parachain na Polkadot, o que significa que se beneficia da segurança e interoperabilidade da Polkadot, mas introduz seu próprio tempo de execução inovador para computação off-chain em enclaves seguros.

A ideia central da Sanders é manter uma grande rede de nós de trabalho (chamados de mineradores Sanders) que executam tarefas dentro de TEEs (especificamente, Intel SGX até agora) e produzem resultados verificáveis. Essas tarefas podem variar desde a execução de segmentos de contratos inteligentes até computação de propósito geral solicitada pelos usuários. Como os trabalhadores são executados em SGX, a Sanders garante que as computações sejam feitas com confidencialidade (os dados de entrada são ocultados do operador do trabalhador) e integridade (os resultados vêm com um atestado). Isso efetivamente cria uma nuvem sem confiança onde os usuários podem implantar cargas de trabalho sabendo que o host não pode espiar ou adulterá-las.

Pode-se pensar na Sanders como análoga ao Amazon EC2 ou AWS Lambda, mas descentralizada: os desenvolvedores podem implantar código na rede da Sanders e tê-lo executado em muitas máquinas habilitadas para SGX em todo o mundo, pagando com o token da Sanders pelo serviço. Alguns casos de uso destacados:

• Análise Web3 e IA: Um projeto poderia analisar dados de usuários ou executar algoritmos de IA em enclaves Sanders, de modo que os dados brutos do usuário permaneçam criptografados (protegendo a privacidade) enquanto apenas insights agregados saem do enclave.
• Backends de jogos e Metaverso: A Sanders pode lidar com lógica de jogo intensiva ou simulações de mundo virtual off-chain, enviando apenas compromissos ou hashes para a blockchain, permitindo uma jogabilidade mais rica sem confiança em um único servidor.
• Serviços on-chain: A Sanders construiu uma plataforma de computação off-chain chamada Sanders Cloud. Por exemplo, ela pode servir como um back-end para bots, serviços web descentralizados, ou até mesmo um livro de ordens off-chain que publica negociações para um contrato inteligente de DEX com atestado TEE.

A Sanders enfatiza que pode escalar a computação confidencial horizontalmente: precisa de mais capacidade? Adicione mais nós de trabalho TEE. Isso é diferente de uma única blockchain onde a capacidade de computação é limitada pelo consenso. Assim, a Sanders abre possibilidades para dApps computacionalmente intensivas que ainda desejam segurança sem confiança. Importante, a Sanders não depende puramente da confiança no hardware; ela está se integrando com o consenso da Polkadot (por exemplo, staking e slashing para resultados ruins) e até explorando uma combinação de TEE com provas de conhecimento zero (como mencionado, seu próximo L2 usa TEE para acelerar a execução e ZKP para verificá-la sucintamente na Ethereum). Essa abordagem híbrida ajuda a mitigar o risco de qualquer comprometimento de um único TEE, adicionando verificação criptográfica por cima.

Em resumo, a Sanders Network aproveita os TEEs para entregar uma nuvem descentralizada e confidencial para a Web3, permitindo computação off-chain com garantias de segurança. Isso libera uma classe de aplicações de blockchain que precisam tanto de computação pesada quanto de privacidade de dados, preenchendo a lacuna entre os mundos on-chain e off-chain.

iExec​

O iExec é um mercado descentralizado para recursos de computação em nuvem construído na Ethereum. Diferente dos três anteriores (que são suas próprias cadeias ou parachains), o iExec opera como uma rede de camada 2 ou off-chain que se coordena com os contratos inteligentes da Ethereum. Os TEEs (especificamente o Intel SGX) são um pilar da abordagem do iExec para estabelecer confiança na computação off-chain.

A rede iExec consiste em nós de trabalho contribuídos por vários provedores. Esses trabalhadores podem executar tarefas solicitadas por usuários (desenvolvedores de dApp, provedores de dados, etc.). Para garantir que essas computações off-chain sejam confiáveis, o iExec introduziu uma estrutura de "Computação Off-chain Confiável": as tarefas podem ser executadas dentro de enclaves SGX, e os resultados vêm com uma assinatura de enclave que prova que a tarefa foi executada corretamente em um nó seguro. O iExec fez parceria com a Intel para lançar esse recurso de computação confiável e até se juntou ao Confidential Computing Consortium para avançar os padrões. Seu protocolo de consenso, chamado Proof-of-Contribution (PoCo), agrega votos/atestados de múltiplos trabalhadores quando necessário para alcançar um consenso sobre o resultado correto. Em muitos casos, o atestado de um único enclave pode ser suficiente se o código for determinístico e a confiança no SGX for alta; para maior garantia, o iExec pode replicar tarefas em vários TEEs e usar um consenso ou voto majoritário.

A plataforma do iExec permite vários casos de uso interessantes:

• Computação de Oráculo Descentralizada: Como mencionado anteriormente, o iExec pode trabalhar com o Chainlink. Um nó Chainlink pode buscar dados brutos, depois entregá-los a um trabalhador SGX do iExec para realizar uma computação (por exemplo, um algoritmo proprietário ou uma inferência de IA) nesses dados, e finalmente retornar um resultado na cadeia. Isso expande o que os oráculos podem fazer além de apenas retransmitir dados – eles agora podem fornecer serviços computados (como chamar um modelo de IA ou agregar muitas fontes) com o TEE garantindo a honestidade.
• IA e DePIN (Rede de Infraestrutura Física Descentralizada): O iExec está se posicionando como uma camada de confiança para aplicativos de IA descentralizados. Por exemplo, um dApp que usa um modelo de aprendizado de máquina pode executar o modelo em um enclave para proteger tanto o modelo (se for proprietário) quanto os dados do usuário que estão sendo inseridos. No contexto de DePIN (como redes IoT distribuídas), os TEEs podem ser usados em dispositivos de borda para confiar nas leituras de sensores e nas computações sobre essas leituras.
• Monetização Segura de Dados: Provedores de dados podem disponibilizar seus conjuntos de dados no mercado do iExec de forma criptografada. Os compradores podem enviar seus algoritmos para serem executados nos dados dentro de um TEE (de modo que os dados brutos do provedor de dados nunca sejam revelados, protegendo sua propriedade intelectual, e os detalhes do algoritmo também possam ser ocultados). O resultado da computação é retornado ao comprador, e o pagamento apropriado ao provedor de dados é tratado via contratos inteligentes. Este esquema, muitas vezes chamado de troca segura de dados, é facilitado pela confidencialidade dos TEEs.

No geral, o iExec fornece a cola entre os contratos inteligentes da Ethereum e a execução segura off-chain. Ele demonstra como "trabalhadores" TEE podem ser conectados em rede para formar uma nuvem descentralizada, completa com um mercado (usando o token RLC do iExec para pagamento) e mecanismos de consenso. Ao liderar o grupo de trabalho de Computação Confiável da Enterprise Ethereum Alliance e contribuir para padrões (como o Hyperledger Avalon), o iExec também impulsiona uma adoção mais ampla de TEEs em cenários de blockchain empresarial.

Outros Projetos e Ecossistemas​

Além dos quatro acima, há alguns outros projetos que valem a pena notar:

• Integritee – outra parachain da Polkadot semelhante à Sanders (na verdade, surgiu do trabalho de TEE da Energy Web Foundation). A Integritee usa TEEs para criar "parachain-como-um-serviço" para empresas, combinando processamento de enclave on-chain e off-chain.
• Automata Network – um protocolo de middleware para privacidade na Web3 que aproveita TEEs para transações privadas, votação anônima e processamento de transações resistente a MEV. A Automata funciona como uma rede off-chain que fornece serviços como um retransmissor de RPC privado e foi mencionada como usando TEEs para coisas como identidade protegida e transações privadas sem gás.
• Hyperledger Sawtooth (PoET) – no âmbito empresarial, o Sawtooth introduziu um algoritmo de consenso chamado Prova de Tempo Decorrido que dependia do SGX. Cada validador executa um enclave que espera por um tempo aleatório e produz uma prova; aquele com a menor espera "ganha" o bloco, uma loteria justa imposta pelo SGX. Embora o Sawtooth não seja um projeto Web3 per se (mais blockchain empresarial), é um uso criativo de TEEs para consenso.
• Cadeias Empresariais/Consórcios – Muitas soluções de blockchain empresarial (por exemplo, ConsenSys Quorum, IBM Blockchain) incorporam TEEs para permitir transações de consórcio confidenciais, onde apenas nós autorizados veem certos dados. Por exemplo, o blueprint do Trusted Compute Framework (TCF) da Enterprise Ethereum Alliance usa TEEs para executar contratos privados off-chain e entregar provas de Merkle on-chain.

Esses projetos coletivamente mostram a versatilidade dos TEEs: eles alimentam L1s inteiras focadas em privacidade, servem como redes off-chain, protegem peças de infraestrutura como oráculos e pontes, e até sustentam algoritmos de consenso. A seguir, consideramos os benefícios e desafios mais amplos do uso de TEEs em ambientes descentralizados.

4. Benefícios e Desafios dos TEEs em Ambientes Descentralizados​

A adoção de Ambientes de Execução Confiáveis em sistemas de blockchain vem com benefícios técnicos significativos, bem como desafios e trade-offs notáveis. Examinaremos ambos os lados: o que os TEEs oferecem para aplicações descentralizadas e quais problemas ou riscos surgem de seu uso.

Benefícios e Pontos Fortes Técnicos​

• Forte Segurança e Privacidade: O principal benefício são as garantias de confidencialidade e integridade. Os TEEs permitem que código sensível seja executado com a certeza de que não será espionado ou alterado por malware externo. Isso fornece um nível de confiança na computação off-chain que antes não estava disponível. Para a blockchain, isso significa que dados privados podem ser utilizados (melhorando a funcionalidade dos dApps) sem sacrificar a segurança. Mesmo em ambientes não confiáveis (servidores em nuvem, nós validadores operados por terceiros), os TEEs mantêm os segredos seguros. Isso é especialmente benéfico para gerenciar chaves privadas, dados de usuários e algoritmos proprietários dentro de sistemas cripto. Por exemplo, uma carteira de hardware ou um serviço de assinatura em nuvem pode usar um TEE para assinar transações de blockchain internamente, de modo que a chave privada nunca seja exposta em texto simples, combinando conveniência com segurança.

• Desempenho Quase Nativo: Ao contrário de abordagens puramente criptográficas para computação segura (como provas ZK ou criptografia homomórfica), a sobrecarga do TEE é relativamente pequena. O código é executado diretamente na CPU, então uma computação dentro de um enclave é aproximadamente tão rápida quanto a execução externa (com alguma sobrecarga para transições de enclave e criptografia de memória, tipicamente desacelerações de um dígito percentual no SGX). Isso significa que os TEEs podem lidar com tarefas computacionalmente intensivas de forma eficiente, permitindo casos de uso (como feeds de dados em tempo real, contratos inteligentes complexos, aprendizado de máquina) que seriam ordens de magnitude mais lentos se feitos com protocolos criptográficos. A baixa latência dos enclaves os torna adequados onde uma resposta rápida é necessária (por exemplo, bots de negociação de alta frequência protegidos por TEEs, ou aplicações interativas e jogos onde a experiência do usuário sofreria com altos atrasos).

• Escalabilidade Melhorada (via Descarregamento): Ao permitir que computações pesadas sejam feitas off-chain de forma segura, os TEEs ajudam a aliviar o congestionamento e os custos de gás nas cadeias principais. Eles permitem designs de Camada 2 e protocolos laterais onde a blockchain é usada apenas para verificação ou liquidação final, enquanto a maior parte da computação acontece em enclaves paralelos. Essa modularização (lógica computacionalmente intensiva em TEEs, consenso na cadeia) pode melhorar drasticamente o rendimento e a escalabilidade de aplicativos descentralizados. Por exemplo, uma DEX poderia fazer a correspondência de ordens em um TEE off-chain e apenas postar as negociações correspondidas na cadeia, aumentando o rendimento e reduzindo o gás na cadeia.

• Melhor Experiência do Usuário e Funcionalidade: Com TEEs, os dApps podem oferecer recursos como confidencialidade ou análises complexas que atraem mais usuários (incluindo instituições). Os TEEs também permitem transações sem gás ou meta-transações, executando-as com segurança off-chain e depois submetendo os resultados, como observado no uso de TEEs pela Automata para reduzir o gás para transações privadas. Além disso, armazenar o estado sensível off-chain em um enclave pode reduzir os dados publicados na cadeia, o que é bom para a privacidade do usuário e a eficiência da rede (menos dados na cadeia para armazenar/verificar).

• Composabilidade com Outras Tecnologias: Curiosamente, os TEEs podem complementar outras tecnologias (não estritamente um benefício inerente apenas aos TEEs, mas em combinação). Eles podem servir como a cola que une soluções híbridas: por exemplo, executar um programa em um enclave e também gerar uma prova ZK de sua execução, onde o enclave ajuda com partes do processo de prova para acelerá-lo. Ou usar TEEs em redes MPC para lidar com certas tarefas com menos rodadas de comunicação. Discutiremos comparações no §5, mas muitos projetos destacam que os TEEs não precisam substituir a criptografia – eles podem trabalhar em conjunto para reforçar a segurança (o mantra da Sanders: "a força do TEE está em apoiar os outros, não em substituí-los").

Suposições de Confiança e Vulnerabilidades de Segurança​

Apesar de seus pontos fortes, os TEEs introduzem suposições de confiança específicas e não são invulneráveis. É crucial entender esses desafios:

• Confiança no Hardware e Centralização: Ao usar TEEs, está-se inerentemente depositando confiança no fornecedor de silício e na segurança de seu design de hardware e cadeia de suprimentos. Por exemplo, usar o Intel SGX significa confiar que a Intel não tem backdoors, que sua fabricação é segura e que o microcódigo da CPU implementa corretamente o isolamento do enclave. Este é um modelo de confiança mais centralizado em comparação com a criptografia pura (que se baseia em suposições matemáticas distribuídas entre todos os usuários). Além disso, o atestado para o SGX historicamente depende do contato com o Serviço de Atestado da Intel, o que significa que se a Intel ficasse offline ou decidisse revogar chaves, os enclaves globalmente poderiam ser afetados. Essa dependência da infraestrutura de uma única empresa levanta preocupações: poderia ser um ponto único de falha ou até mesmo um alvo de regulamentação governamental (por exemplo, os controles de exportação dos EUA poderiam, em teoria, restringir quem pode usar TEEs fortes). O AMD SEV mitiga isso permitindo um atestado mais descentralizado (os proprietários de VMs podem atestar suas VMs), mas ainda assim é preciso confiar no chip e no firmware da AMD. O risco de centralização é frequentemente citado como algo antitético à descentralização da blockchain. Projetos como o Keystone (TEE de código aberto) e outros estão pesquisando maneiras de reduzir a dependência de caixas pretas proprietárias, mas ainda não são mainstream.

• Canais Laterais e Outras Vulnerabilidades: Um TEE não é uma bala de prata; ele pode ser atacado por meios indiretos. Ataques de canal lateral exploram o fato de que, mesmo que o acesso direto à memória seja bloqueado, a operação de um enclave pode influenciar sutilmente o sistema (através do tempo, uso de cache, consumo de energia, emissões eletromagnéticas, etc.). Nos últimos anos, vários ataques acadêmicos ao Intel SGX foram demonstrados: de Foreshadow (extração de segredos do enclave via vazamento de tempo do cache L1) a Plundervolt (injeção de falha de voltagem via instruções privilegiadas) a SGAxe (extração de chaves de atestado), entre outros. Esses ataques sofisticados mostram que os TEEs podem ser comprometidos sem a necessidade de quebrar proteções criptográficas – em vez disso, explorando comportamentos microarquiteturais ou falhas na implementação. Como resultado, é reconhecido que "pesquisadores identificaram vários vetores de ataque potenciais que poderiam explorar vulnerabilidades de hardware ou diferenças de tempo nas operações do TEE". Embora esses ataques não sejam triviais e muitas vezes exijam acesso local ou hardware malicioso, eles são uma ameaça real. Os TEEs também geralmente não protegem contra ataques físicos se um adversário tiver o chip em mãos (por exemplo, decapsular o chip, sondar barramentos, etc., pode derrotar a maioria dos TEEs comerciais).

  As respostas dos fornecedores às descobertas de canais laterais têm sido patches de microcódigo e atualizações do SDK do enclave para mitigar vazamentos conhecidos (às vezes ao custo de desempenho). Mas continua sendo um jogo de gato e rato. Para a Web3, isso significa que se alguém encontrar um novo canal lateral no SGX, um contrato DeFi "seguro" executado no SGX poderia potencialmente ser explorado (por exemplo, para vazar dados secretos ou manipular a execução). Portanto, confiar em TEEs significa aceitar uma superfície de vulnerabilidade potencial no nível do hardware que está fora do modelo de ameaça típico da blockchain. É uma área ativa de pesquisa para fortalecer os TEEs contra isso (por exemplo, projetando código de enclave com operações de tempo constante, evitando padrões de acesso à memória dependentes de segredos e usando técnicas como RAM alheia). Alguns projetos também aumentam os TEEs com verificações secundárias – por exemplo, combinando com provas ZK, ou tendo múltiplos enclaves executados em diferentes fornecedores de hardware para reduzir o risco de um único chip.

• Desempenho e Restrições de Recursos: Embora os TEEs sejam executados em velocidade quase nativa para tarefas vinculadas à CPU, eles vêm com algumas sobrecargas e limites. Entrar em um enclave (um ECALL) e sair (OCALL) tem um custo, assim como a criptografia/descriptografia de páginas de memória. Isso pode impactar o desempenho para cruzamentos de fronteira de enclave muito frequentes. Os enclaves também costumam ter limitações de tamanho de memória. Por exemplo, o SGX inicial tinha um Cache de Página de Enclave limitado e, quando os enclaves usavam mais memória, as páginas tinham que ser trocadas (com criptografia), o que diminuía massivamente o desempenho. Mesmo os TEEs mais recentes muitas vezes não permitem o uso de toda a RAM do sistema facilmente – há uma região de memória segura que pode ser limitada. Isso significa que computações ou conjuntos de dados em grande escala podem ser desafiadores de lidar inteiramente dentro de um TEE. Em contextos Web3, isso pode limitar a complexidade dos contratos inteligentes ou modelos de ML que podem ser executados em um enclave. Os desenvolvedores precisam otimizar para memória e possivelmente dividir as cargas de trabalho.

• Complexidade do Atestado e Gerenciamento de Chaves: Usar TEEs em um ambiente descentralizado requer fluxos de trabalho de atestado robustos: cada nó precisa provar aos outros que está executando um enclave autêntico com o código esperado. Configurar essa verificação de atestado na cadeia pode ser complexo. Geralmente envolve codificar a chave pública de atestado do fornecedor ou certificado no protocolo e escrever a lógica de verificação em contratos inteligentes ou clientes off-chain. Isso introduz sobrecarga no design do protocolo, e quaisquer alterações (como a Intel mudando seu formato de chave de assinatura de atestado de EPID para DCAP) podem causar ônus de manutenção. Além disso, gerenciar chaves dentro dos TEEs (para descriptografar dados ou assinar resultados) adiciona outra camada de complexidade. Erros no gerenciamento de chaves do enclave podem minar a segurança (por exemplo, se um enclave expor inadvertidamente uma chave de descriptografia através de um bug, todas as suas promessas de confidencialidade desmoronam). As melhores práticas envolvem o uso das APIs de selagem do TEE para armazenar chaves com segurança e rotacionar chaves se necessário, mas novamente isso requer um design cuidadoso por parte dos desenvolvedores.

• Negação de Serviço e Disponibilidade: Um problema talvez menos discutido: os TEEs não ajudam com a disponibilidade e podem até introduzir novas vias de DoS. Por exemplo, um invasor pode inundar um serviço baseado em TEE com entradas que são custosas para processar, sabendo que o enclave não pode ser facilmente inspecionado ou interrompido pelo operador (já que está isolado). Além disso, se uma vulnerabilidade for encontrada e um patch exigir atualizações de firmware, durante esse ciclo muitos serviços de enclave podem ter que pausar (por segurança) até que os nós sejam corrigidos, causando tempo de inatividade. No consenso de blockchain, imagine se um bug crítico do SGX fosse encontrado – redes como a Secret poderiam ter que parar até uma correção, já que a confiança nos enclaves estaria quebrada. A coordenação de tais respostas em uma rede descentralizada é desafiadora.

Composabilidade e Limitações do Ecossistema​

• Composabilidade Limitada com Outros Contratos: Em uma plataforma de contrato inteligente pública como a Ethereum, os contratos podem facilmente chamar outros contratos e todo o estado está aberto, permitindo os legos de dinheiro DeFi e uma rica composição. Em um modelo de contrato baseado em TEE, o estado privado não pode ser livremente compartilhado ou composto sem quebrar a confidencialidade. Por exemplo, se o Contrato A em um enclave precisa interagir com o Contrato B, e ambos mantêm alguns dados secretos, como eles colaboram? Ou eles devem fazer um protocolo complexo de computação multipartidária segura (o que nega parte da simplicidade dos TEEs) ou eles se combinam em um enclave (reduzindo a modularidade). Este é um desafio que a Secret Network e outros enfrentam: chamadas entre contratos com privacidade não são triviais. Algumas soluções envolvem ter um único enclave lidando com a execução de múltiplos contratos para que ele possa gerenciar internamente segredos compartilhados, mas isso pode tornar o sistema mais monolítico. Assim, a composabilidade de contratos privados é mais limitada do que a dos públicos, ou requer novos padrões de design. Da mesma forma, integrar módulos baseados em TEE em dApps de blockchain existentes requer um design de interface cuidadoso – muitas vezes apenas o resultado de um enclave é postado na cadeia, que pode ser um snark ou um hash, e outros contratos só podem usar essa informação limitada. Isso é certamente um trade-off; projetos como a Secret fornecem chaves de visualização e permitem o compartilhamento de segredos com base na necessidade, mas não é tão transparente quanto a composabilidade normal na cadeia.

• Padronização e Interoperabilidade: O ecossistema TEE atualmente carece de padrões unificados entre os fornecedores. Intel SGX, AMD SEV, ARM TrustZone todos têm modelos de programação e métodos de atestado diferentes. Essa fragmentação significa que um dApp escrito para enclaves SGX não é trivialmente portável para o TrustZone, etc. Na blockchain, isso pode vincular um projeto a um hardware específico (por exemplo, Secret e Oasis estão vinculados a servidores x86 com SGX no momento). Se no futuro eles quiserem suportar nós ARM (digamos, validadores em dispositivos móveis), isso exigiria desenvolvimento adicional e talvez uma lógica de verificação de atestado diferente. Existem esforços (como o CCC – Confidential Computing Consortium) para padronizar o atestado e as APIs de enclave, mas ainda não chegamos lá. A falta de padrões também afeta as ferramentas de desenvolvedor – pode-se achar o SDK do SGX maduro, mas depois precisar se adaptar a outro TEE com um SDK diferente. Este desafio de interoperabilidade pode retardar a adoção e aumentar os custos.

• Curva de Aprendizagem do Desenvolvedor: Construir aplicações que são executadas dentro de TEEs requer conhecimento especializado que muitos desenvolvedores de blockchain podem não ter. Programação de baixo nível em C/C++ (para SGX/TrustZone) ou compreensão de segurança de memória e codificação resistente a canais laterais são frequentemente necessários. Depurar código de enclave é notoriamente complicado (você não pode ver facilmente dentro de um enclave enquanto ele está em execução por razões de segurança!). Embora existam frameworks e linguagens de nível superior (como o uso de Rust pela Oasis para seu tempo de execução confidencial, ou até mesmo ferramentas para executar WebAssembly em enclaves), a experiência do desenvolvedor ainda é mais difícil do que o desenvolvimento típico de contratos inteligentes ou o desenvolvimento web2 off-chain. Essa curva de aprendizado íngreme e ferramentas imaturas podem deter os desenvolvedores ou levar a erros se não forem manuseadas com cuidado. Há também o aspecto de precisar de hardware para testar – executar código SGX precisa de uma CPU habilitada para SGX ou um emulador (que é mais lento), então a barreira de entrada é maior. Como resultado, relativamente poucos desenvolvedores hoje estão profundamente familiarizados com o desenvolvimento de enclaves, tornando as auditorias e o suporte da comunidade mais escassos do que, digamos, na bem trilhada comunidade solidity.

• Custos Operacionais: Executar uma infraestrutura baseada em TEE pode ser mais caro. O próprio hardware pode ser mais caro ou escasso (por exemplo, certos provedores de nuvem cobram um prêmio por VMs capazes de SGX). Há também sobrecarga nas operações: manter o firmware atualizado (para patches de segurança), gerenciar a rede de atestado, etc., o que projetos pequenos podem achar oneroso. Se cada nó deve ter uma certa CPU, isso pode reduzir o pool de validadores potenciais (nem todo mundo tem o hardware necessário), afetando assim a descentralização e possivelmente levando a um maior uso de hospedagem em nuvem.

Em resumo, embora os TEEs desbloqueiem recursos poderosos, eles também trazem trade-offs de confiança (confiança no hardware vs. confiança na matemática), potenciais fraquezas de segurança (especialmente canais laterais) e obstáculos de integração em um contexto descentralizado. Os projetos que usam TEEs devem projetar cuidadosamente em torno dessas questões – empregando defesa em profundidade (não assumir que o TEE é inquebrável), mantendo a base de computação confiável mínima e sendo transparentes sobre as suposições de confiança para os usuários (para que fique claro, por exemplo, que se está confiando no hardware da Intel além do consenso da blockchain).

5. TEEs vs. Outras Tecnologias de Preservação de Privacidade (ZKP, FHE, MPC)​

Ambientes de Execução Confiáveis são uma abordagem para alcançar privacidade e segurança na Web3, mas existem outras técnicas importantes, incluindo Provas de Conhecimento Zero (ZKPs), Criptografia Totalmente Homomórfica (FHE) e Computação Multipartidária Segura (MPC). Cada uma dessas tecnologias tem um modelo de confiança e perfil de desempenho diferentes. Em muitos casos, elas não são mutuamente exclusivas – podem se complementar – mas é útil comparar seus trade-offs em desempenho, confiança e usabilidade para o desenvolvedor:

Para definir brevemente as alternativas:

• ZKPs: Provas criptográficas (como zk-SNARKs, zk-STARKs) que permitem que uma parte prove a outras que uma declaração é verdadeira (por exemplo, "Eu conheço um segredo que satisfaz esta computação") sem revelar por que é verdadeira (ocultando a entrada secreta). Na blockchain, ZKPs são usadas para transações privadas (por exemplo, Zcash, Aztec) e para escalabilidade (rollups que postam provas de execução correta). Elas garantem privacidade forte (nenhum dado secreto é vazado, apenas provas) e integridade garantida pela matemática, mas gerar essas provas pode ser computacionalmente pesado e os circuitos devem ser projetados com cuidado.
• FHE: Esquema de criptografia que permite computação arbitrária em dados criptografados, de modo que o resultado, quando descriptografado, corresponda ao resultado da computação em textos simples. Em teoria, a FHE fornece a privacidade máxima – os dados permanecem criptografados o tempo todo – e você não precisa confiar em ninguém com os dados brutos. Mas a FHE é extremamente lenta para computações gerais (embora esteja melhorando com a pesquisa); ainda está principalmente em uso experimental ou especializado devido ao desempenho.
• MPC: Protocolos onde várias partes calculam conjuntamente uma função sobre suas entradas privadas sem revelar essas entradas umas às outras. Muitas vezes envolve o compartilhamento de segredos entre as partes e a realização de operações criptográficas para que a saída seja correta, mas as entradas individuais permaneçam ocultas. A MPC pode distribuir a confiança (nenhum ponto único vê todos os dados) e pode ser eficiente para certas operações, mas normalmente incorre em uma sobrecarga de comunicação e coordenação e pode ser complexa de implementar para redes grandes.

Abaixo está uma tabela de comparação resumindo as principais diferenças:

Tecnologia	Modelo de Confiança	Desempenho	Privacidade de Dados	Usabilidade para Desenvolvedor
TEE (Intel SGX, etc.)	Confiança no fabricante do hardware (servidor de atestado centralizado em alguns casos). Assume que o chip é seguro; se o hardware for comprometido, a segurança é quebrada.	Velocidade de execução quase nativa; sobrecarga mínima. Bom para computação em tempo real e grandes cargas de trabalho. Escalabilidade limitada pela disponibilidade de nós habilitados para TEE.	Os dados estão em texto simples dentro do enclave, mas criptografados para o mundo exterior. Confidencialidade forte se o hardware se mantiver, mas se o enclave for violado, os segredos são expostos (sem proteção matemática adicional).	Complexidade moderada. Muitas vezes pode reutilizar código/linguagens existentes (C, Rust) e executá-lo em um enclave com pequenas modificações. A barreira de entrada mais baixa entre estes – não há necessidade de aprender criptografia avançada – mas requer programação de sistemas e conhecimento específico do SDK do TEE.
ZKP (zk-SNARK/STARK)	Confiança em suposições matemáticas (por exemplo, dureza de problemas criptográficos) e, às vezes, uma configuração confiável (para SNARKs). Nenhuma dependência de qualquer parte única em tempo de execução.	A geração de provas é computacionalmente pesada (especialmente para programas complexos), muitas vezes ordens de magnitude mais lenta que a nativa. A verificação na cadeia é rápida (poucos ms). Não é ideal para grandes computações de dados devido ao tempo de prova. Escalabilidade: boa para verificação sucinta (rollups), mas o provador é o gargalo.	Privacidade muito forte – pode provar a correção sem revelar qualquer entrada privada. Apenas informações mínimas (como o tamanho da prova) vazam. Ideal para privacidade financeira, etc.	Alta complexidade. Requer aprender linguagens especializadas (circuitos, zkDSLs como Circom ou Noir) e pensar em termos de circuitos aritméticos. A depuração é difícil. Menos especialistas disponíveis.
FHE	Confiança na matemática (problemas de reticulado). Nenhuma parte confiável; a segurança se mantém enquanto a criptografia não for quebrada.	Muito lento para uso geral. As operações em dados criptografados são várias ordens de magnitude mais lentas do que em texto simples. Melhorando um pouco com melhorias de hardware e algoritmos melhores, mas atualmente impraticável para uso em tempo real em contextos de blockchain.	Privacidade máxima – os dados permanecem criptografados o tempo todo, mesmo durante a computação. Isso é ideal para dados sensíveis (por exemplo, médicos, análises entre instituições) se o desempenho permitisse.	Muito especializado. Os desenvolvedores precisam de conhecimento em criptografia. Existem algumas bibliotecas (como Microsoft SEAL, TFHE), mas escrever programas arbitrários em FHE é difícil e tortuoso. Ainda não é um alvo de desenvolvimento rotineiro para dApps.
MPC	Confiança distribuída entre várias partes. Assume que um limiar de partes é honesto (sem conluio além de um certo número). Nenhuma confiança em hardware necessária. Falha de confiança se muitas partes conspirarem.	Tipicamente mais lento que o nativo devido às rodadas de comunicação, mas muitas vezes mais rápido que a FHE. O desempenho varia: operações simples (soma, multiplicação) podem ser eficientes; lógica complexa pode explodir em custo de comunicação. A latência é sensível às velocidades da rede. A escalabilidade pode ser melhorada com sharding ou suposições de confiança parcial.	Privacidade forte se as suposições se mantiverem – nenhum nó único vê a entrada inteira. Mas algumas informações podem vazar através da saída ou se as partes caírem (além disso, falta a sucintidade do ZK – você obtém o resultado, mas nenhuma prova facilmente compartilhável dele sem executar o protocolo novamente).	Alta complexidade. Requer o projeto de um protocolo personalizado para cada caso de uso ou o uso de frameworks (como SPDZ, ou a oferta da Partisia). Os desenvolvedores devem raciocinar sobre protocolos criptográficos e muitas vezes coordenar a implantação de múltiplos nós. A integração em aplicativos de blockchain pode ser complexa (precisa de rodadas off-chain).

Citações: A comparação acima baseia-se em fontes como a análise da Sanders Network e outras, que destacam que os TEEs se destacam em velocidade e facilidade de uso, enquanto ZK e FHE se concentram na máxima ausência de confiança ao custo de computação pesada, e a MPC distribui a confiança, mas introduz sobrecarga de rede.

A partir da tabela, alguns trade-offs importantes se tornam claros:

• Desempenho: Os TEEs têm uma grande vantagem em velocidade bruta e baixa latência. A MPC muitas vezes pode lidar com complexidade moderada com alguma lentidão, o ZK é lento para produzir, mas rápido para verificar (uso assíncrono), e a FHE é atualmente a mais lenta de longe para tarefas arbitrárias (embora seja boa para operações limitadas como somas/multiplicações simples). Se sua aplicação precisa de processamento complexo em tempo real (como aplicações interativas, decisões de alta frequência), os TEEs ou talvez a MPC (com poucas partes em boas conexões) são as únicas opções viáveis hoje. ZK e FHE seriam lentos demais em tais cenários.

• Modelo de Confiança: ZKP e FHE são puramente sem confiança (confiam apenas na matemática). A MPC transfere a confiança para suposições sobre a honestidade dos participantes (que pode ser reforçada com muitas partes ou incentivos econômicos). O TEE deposita confiança no hardware e no fornecedor. Esta é uma diferença fundamental: os TEEs introduzem um terceiro confiável (o chip) no mundo geralmente sem confiança da blockchain. Em contraste, ZK e FHE são frequentemente elogiados por se alinharem melhor com o ethos descentralizado – nenhuma entidade especial para confiar, apenas dureza computacional. A MPC fica no meio: a confiança é descentralizada, mas não eliminada (se N de M nós conspirarem, a privacidade é quebrada). Portanto, para máxima ausência de confiança (por exemplo, um sistema verdadeiramente resistente à censura e descentralizado), pode-se inclinar para soluções criptográficas. Por outro lado, muitos sistemas práticos se sentem confortáveis assumindo que a Intel é honesta ou que um conjunto de grandes validadores não irá conspirar, trocando um pouco de confiança por grandes ganhos de eficiência.

• Segurança/Vulnerabilidades: Os TEEs, como discutido, podem ser minados por bugs de hardware ou canais laterais. A segurança de ZK e FHE pode ser minada se a matemática subjacente (digamos, curva elíptica ou problema de reticulado) for quebrada, mas esses são problemas bem estudados e os ataques provavelmente seriam notados (além disso, as escolhas de parâmetros podem mitigar riscos conhecidos). A segurança da MPC pode ser quebrada por adversários ativos se o protocolo não for projetado para isso (alguns protocolos MPC assumem participantes "honestos, mas curiosos" e podem falhar se alguém trapacear abertamente). No contexto da blockchain, uma violação de TEE pode ser mais catastrófica (todos os contratos baseados em enclave poderiam estar em risco até serem corrigidos), enquanto uma quebra criptográfica de ZK (como descobrir uma falha em uma função de hash usada por um rollup ZK) também poderia ser catastrófica, mas é geralmente considerada menos provável dada a suposição mais simples. A superfície de ataque é muito diferente: os TEEs precisam se preocupar com coisas como análise de energia, enquanto o ZK precisa se preocupar com avanços matemáticos.

• Privacidade de Dados: FHE e ZK oferecem as garantias de privacidade mais fortes – os dados permanecem criptograficamente protegidos. A MPC garante que os dados sejam compartilhados secretamente, de modo que nenhuma parte única os veja (embora algumas informações possam vazar se as saídas forem públicas ou se os protocolos não forem cuidadosamente projetados). O TEE mantém os dados privados do exterior, mas dentro do enclave os dados são descriptografados; se alguém de alguma forma ganhar o controle do enclave, a confidencialidade dos dados é perdida. Além disso, os TEEs normalmente permitem que o código faça qualquer coisa com os dados (incluindo vazá-los inadvertidamente através de canais laterais ou da rede se o código for malicioso). Portanto, os TEEs exigem que você também confie no código do enclave, não apenas no hardware. Em contraste, os ZKPs provam propriedades do código sem nunca revelar segredos, então você nem precisa confiar no código (além de ele realmente ter a propriedade provada). Se uma aplicação de enclave tivesse um bug que vazasse dados para um arquivo de log, o hardware do TEE não impediria isso – enquanto um sistema de prova ZK simplesmente não revelaria nada exceto a prova pretendida. Esta é uma nuance: os TEEs protegem contra adversários externos, mas não necessariamente contra bugs de lógica no próprio programa do enclave, enquanto o design do ZK força uma abordagem mais declarativa (você prova exatamente o que é pretendido e nada mais).

• Composabilidade e Integração: Os TEEs se integram razoavelmente bem em sistemas existentes – você pode pegar um programa existente, colocá-lo em um enclave e obter alguns benefícios de segurança sem mudar muito o modelo de programação. ZK e FHE muitas vezes exigem a reescrita do programa em um circuito ou forma restritiva, o que pode ser um esforço massivo. Por exemplo, escrever uma verificação simples de modelo de IA em ZK envolve transformá-la em uma série de operações aritméticas e restrições, o que está longe de apenas executar o TensorFlow em um TEE e atestar o resultado. A MPC, da mesma forma, pode exigir um protocolo personalizado por caso de uso. Portanto, do ponto de vista da produtividade e custo do desenvolvedor, os TEEs são atraentes. Vimos a adoção de TEEs mais rapidamente em algumas áreas precisamente porque você pode aproveitar os ecossistemas de software existentes (muitas bibliotecas são executadas em enclaves com pequenos ajustes). ZK/MPC exigem talento de engenharia especializado, que é escasso. No entanto, o outro lado da moeda é que os TEEs produzem uma solução que muitas vezes é mais isolada (você tem que confiar naquele enclave ou naquele conjunto de nós), enquanto o ZK lhe dá uma prova que qualquer um pode verificar na cadeia, tornando-o altamente componível (qualquer contrato pode verificar uma prova zk). Portanto, os resultados do ZK são portáteis – eles produzem uma pequena prova que qualquer número de outros contratos ou usuários pode usar para ganhar confiança. Os resultados do TEE geralmente vêm na forma de um atestado vinculado a um hardware específico e possivelmente não sucinto; eles podem não ser tão facilmente compartilháveis ou agnósticos à cadeia (embora você possa postar uma assinatura do resultado e ter contratos programados para aceitá-la se souberem a chave pública do enclave).

Na prática, estamos vendo abordagens híbridas: por exemplo, a Sanders Network argumenta que TEE, MPC e ZK brilham em áreas diferentes e podem se complementar. Um caso concreto é a identidade descentralizada: pode-se usar provas ZK para provar uma credencial de identidade sem revelá-la, mas essa credencial pode ter sido verificada e emitida por um processo baseado em TEE que verificou seus documentos de forma privada. Ou considere o escalonamento: os rollups ZK fornecem provas sucintas para muitas transações, mas a geração dessas provas poderia ser acelerada usando TEEs para fazer alguns cálculos mais rapidamente (e então apenas provar uma declaração menor). A combinação pode, às vezes, reduzir o requisito de confiança nos TEEs (por exemplo, usar TEEs para desempenho, mas ainda verificar a correção final através de uma prova ZK ou de um jogo de desafio na cadeia, para que um TEE comprometido não possa trapacear sem ser pego). Enquanto isso, a MPC pode ser combinada com TEEs, fazendo com que o nó de computação de cada parte seja um TEE, adicionando uma camada extra para que, mesmo que algumas partes conspirem, elas ainda não possam ver os dados umas das outras, a menos que também quebrem a segurança do hardware.

Em resumo, os TEEs oferecem um caminho muito prático e imediato para a computação segura com suposições modestas (confiança no hardware), enquanto ZK e FHE oferecem um caminho mais teórico e sem confiança, mas com alto custo computacional, e a MPC oferece um caminho de confiança distribuída com custos de rede. A escolha certa na Web3 depende dos requisitos da aplicação:

• Se você precisa de computação rápida e complexa em dados privados (como IA, grandes conjuntos de dados) – os TEEs (ou MPC com poucas partes) são atualmente a única maneira viável.
• Se você precisa de máxima descentralização e verificabilidade – as provas ZK brilham (por exemplo, transações de criptomoedas privadas favorecem o ZKP como no Zcash, porque os usuários não querem confiar em nada além da matemática).
• Se você precisa de computação colaborativa entre múltiplos stakeholders – a MPC é naturalmente adequada (como gerenciamento de chaves multipartidário ou leilões).
• Se você tem dados extremamente sensíveis e a privacidade a longo prazo é uma obrigação – a FHE poderia ser atraente se o desempenho melhorar, porque mesmo que alguém obtenha seus textos cifrados anos depois, sem a chave eles não aprendem nada; enquanto um comprometimento de enclave poderia vazar segredos retroativamente se os logs fossem mantidos.

Vale a pena notar que o espaço da blockchain está explorando ativamente todas essas tecnologias em paralelo. É provável que vejamos combinações: por exemplo, soluções de Camada 2 integrando TEEs para sequenciar transações e depois usando um ZKP para provar que o TEE seguiu as regras (um conceito sendo explorado em algumas pesquisas da Ethereum), ou redes MPC que usam TEEs em cada nó para reduzir a complexidade dos protocolos MPC (já que cada nó é internamente seguro e pode simular múltiplas partes).

Em última análise, TEEs vs ZK vs MPC vs FHE não é uma escolha de soma zero – cada um visa pontos diferentes no triângulo de segurança, desempenho e ausência de confiança. Como um artigo colocou, todos os quatro enfrentam um "triângulo impossível" de desempenho, custo e segurança – nenhuma solução única é superior em todos os aspectos. O design ideal muitas vezes usa a ferramenta certa para a parte certa do problema.

6. Adoção nos Principais Ecossistemas de Blockchain​

Os Ambientes de Execução Confiáveis têm visto níveis variados de adoção em diferentes ecossistemas de blockchain, muitas vezes influenciados pelas prioridades dessas comunidades e pela facilidade de integração. Aqui avaliamos como os TEEs estão sendo usados (ou explorados) em alguns dos principais ecossistemas: Ethereum, Cosmos e Polkadot, além de abordar outros.

Ethereum (e Camadas 1 em Geral)​

Na própria mainnet da Ethereum, os TEEs não fazem parte do protocolo principal, mas têm sido usados em aplicações e Camadas 2. A filosofia da Ethereum se apoia na segurança criptográfica (por exemplo, os emergentes ZK-rollups), mas os TEEs encontraram papéis em oráculos e execução off-chain para a Ethereum:

• Serviços de Oráculo: Como discutido, o Chainlink incorporou soluções baseadas em TEE como o Town Crier. Embora nem todos os nós do Chainlink usem TEEs por padrão, a tecnologia está lá para feeds de dados que exigem confiança extra. Além disso, a API3 (outro projeto de oráculo) mencionou o uso do Intel SGX para executar APIs e assinar dados para garantir a autenticidade. Esses serviços alimentam dados para contratos Ethereum com garantias mais fortes.

• Camada 2 e Rollups: Há pesquisas e debates contínuos na comunidade Ethereum sobre o uso de TEEs em sequenciadores ou validadores de rollup. Por exemplo, o conceito de "ZK-Portal" da ConsenSys e outros levantaram a possibilidade de usar TEEs para impor a ordenação correta em rollups otimistas ou para proteger o sequenciador da censura. O artigo da Medium que vimos até sugere que, até 2025, o TEE pode se tornar um recurso padrão em alguns L2s para coisas como proteção de negociação de alta frequência. Projetos como o Catalyst (uma DEX de negociação de alta frequência) e o Flashbots (para retransmissores de MEV) analisaram os TEEs para impor a ordenação justa de transações antes que elas cheguem à blockchain.

• Ethereum Empresarial: Em redes Ethereum de consórcio ou permissionadas, os TEEs são mais amplamente adotados. O Trusted Compute Framework (TCF) da Enterprise Ethereum Alliance era basicamente um blueprint para integrar TEEs em clientes Ethereum. O Hyperledger Avalon (anteriormente EEA TCF) permite que partes de contratos inteligentes da Ethereum sejam executadas off-chain em um TEE e depois verificadas on-chain. Várias empresas como IBM, Microsoft e iExec contribuíram para isso. Embora na Ethereum pública isso não tenha se tornado comum, em implantações privadas (por exemplo, um grupo de bancos usando Quorum ou Besu), os TEEs podem ser usados para que até mesmo os membros do consórcio não vejam os dados uns dos outros, apenas resultados autorizados. Isso pode satisfazer os requisitos de privacidade em um ambiente empresarial.

• Projetos Notáveis: Além do iExec, que opera na Ethereum, houve projetos como o Enigma (que originalmente começou como um projeto MPC no MIT, depois mudou para o uso de SGX; mais tarde se tornou a Secret Network no Cosmos). Outro foi o Decentralized Cloud Services (DCS) nas primeiras discussões da Ethereum. Mais recentemente, o OAuth (Oasis Ethereum ParaTime) permite que contratos solidity sejam executados com confidencialidade usando o backend TEE da Oasis, mas liquidando na Ethereum. Além disso, alguns DApps baseados em Ethereum, como compartilhamento de dados médicos ou jogos, experimentaram TEEs tendo um componente de enclave off-chain interagindo com seus contratos.

Portanto, a adoção da Ethereum é um tanto indireta – ela não mudou o protocolo para exigir TEEs, mas possui um rico conjunto de serviços opcionais e extensões que aproveitam os TEEs para aqueles que precisam deles. Importante, os pesquisadores da Ethereum permanecem cautelosos: propostas para criar um "shard apenas com TEE" ou para integrar profundamente os TEEs encontraram ceticismo da comunidade devido a preocupações com a confiança. Em vez disso, os TEEs são vistos como "coprocessadores" para a Ethereum, em vez de componentes principais.

Ecossistema Cosmos​

O ecossistema Cosmos é amigável à experimentação através de seu SDK modular e cadeias soberanas, e a Secret Network (abordada acima) é um excelente exemplo de adoção de TEE no Cosmos. A Secret Network é, na verdade, uma cadeia do Cosmos SDK com consenso Tendermint, modificada para exigir SGX em seus validadores. É uma das zonas Cosmos mais proeminentes depois do Cosmos Hub principal, indicando uma adoção significativa da tecnologia TEE naquela comunidade. O sucesso da Secret em fornecer privacidade interchain (através de suas conexões IBC, a Secret pode servir como um hub de privacidade para outras cadeias Cosmos) é um caso notável de integração de TEE na L1.

Outro projeto relacionado ao Cosmos é a Oasis Network (embora não construída no Cosmos SDK, foi projetada por algumas das mesmas pessoas que contribuíram para o Tendermint e compartilha um ethos semelhante de arquitetura modular). A Oasis é autônoma, mas pode se conectar ao Cosmos através de pontes, etc. Tanto a Secret quanto a Oasis mostram que, no mundo Cosmos, a ideia de "privacidade como um recurso" via TEEs ganhou tração suficiente para justificar redes dedicadas.

O Cosmos até tem um conceito de "provedores de privacidade" para aplicações interchain – por exemplo, um aplicativo em uma cadeia pode chamar um contrato na Secret Network via IBC para realizar uma computação confidencial e, em seguida, receber o resultado de volta. Essa composabilidade está surgindo agora.

Além disso, o projeto Anoma (não estritamente Cosmos, mas relacionado no sentido de interoperabilidade) falou sobre o uso de TEEs para arquiteturas centradas em intenções, embora seja mais teórico.

Em resumo, o Cosmos tem pelo menos uma grande cadeia abraçando totalmente os TEEs (Secret) e outras interagindo com ela, ilustrando uma adoção saudável nessa esfera. A modularidade do Cosmos poderia permitir mais cadeias desse tipo (por exemplo, pode-se imaginar uma zona Cosmos especializada em oráculos ou identidade baseados em TEE).

Polkadot e Substrate​

O design da Polkadot permite que as parachains se especializem, e de fato a Polkadot hospeda múltiplas parachains que usam TEEs:

• Sanders Network: Já descrita; uma parachain que oferece uma nuvem de computação baseada em TEE. A Sanders está ativa como uma parachain, fornecendo serviços para outras cadeias através do XCMP (passagem de mensagens cross-chain). Por exemplo, outro projeto Polkadot pode descarregar uma tarefa confidencial para os trabalhadores da Sanders e receber uma prova ou resultado de volta. A economia de tokens nativa da Sanders incentiva a execução de nós TEE, e ela tem uma comunidade considerável, sinalizando uma forte adoção.
• Integritee: Outra parachain focada em soluções empresariais e de privacidade de dados usando TEEs. A Integritee permite que as equipes implantem suas próprias side-chains privadas (chamadas Teewasms), onde a execução é feita em enclaves. Ela visa casos de uso como processamento de dados confidenciais para corporações que ainda desejam se ancorar na segurança da Polkadot.
• /Root ou Crust?: Havia ideias sobre o uso de TEEs para armazenamento descentralizado ou faróis de aleatoriedade em alguns projetos relacionados à Polkadot. Por exemplo, a Crust Network (armazenamento descentralizado) planejou originalmente uma prova de armazenamento baseada em TEE (embora tenha mudado para outro design mais tarde). E a parachain aleatória da Polkadot (Entropy) considerou TEEs vs VRFs.

A dependência da Polkadot da governança e atualizações on-chain significa que as parachains podem incorporar novas tecnologias rapidamente. Tanto a Sanders quanto a Integritee passaram por atualizações para melhorar sua integração com TEE (como suportar novos recursos do SGX ou refinar métodos de atestado). A Web3 Foundation também financiou esforços anteriores em projetos TEE baseados em Substrate, como o SubstraTEE (um protótipo inicial que demonstrou a execução de contratos off-chain em TEEs com verificação on-chain).

O ecossistema Polkadot, portanto, mostra várias equipes independentes apostando na tecnologia TEE, indicando uma tendência de adoção positiva. Está se tornando um ponto de venda para a Polkadot que "se você precisa de contratos inteligentes confidenciais ou computação off-chain, temos parachains para isso".

Outros Ecossistemas e Adoção Geral​

• Empresarial e Consórcios: Fora do cripto público, o Hyperledger e as cadeias empresariais têm adotado TEEs de forma constante para ambientes permissionados. Por exemplo, o Comitê de Basileia testou uma blockchain de financiamento comercial baseada em TEE. O padrão geral é: onde a privacidade ou a confidencialidade dos dados é uma obrigação, e os participantes são conhecidos (de modo que podem até investir coletivamente em módulos de segurança de hardware), os TEEs encontram um lar confortável. Isso pode não aparecer nas notícias de cripto, mas em setores como cadeia de suprimentos, consórcios bancários ou redes de compartilhamento de dados de saúde, os TEEs são frequentemente a escolha preferida (como uma alternativa a simplesmente confiar em um terceiro ou usar criptografia pesada).

• Camadas 1 fora da Ethereum: Algumas L1s mais novas têm experimentado TEEs. O NEAR Protocol teve um conceito inicial de um shard baseado em TEE para contratos privados (ainda não implementado). O Celo considerou TEEs para provas de cliente leve (suas provas Plumo agora dependem de snarks, mas eles analisaram o SGX para comprimir dados da cadeia para dispositivos móveis em um ponto). O Concordium, uma L1 de privacidade regulamentada, usa ZK para anonimato, mas também explora TEEs para verificação de identidade. O Dfinity/Internet Computer usa enclaves seguros em suas máquinas de nó, mas para inicializar a confiança (não para execução de contratos, já que sua criptografia "Chain Key" lida com isso).

• Bitcoin: Embora o próprio Bitcoin não use TEEs, houve projetos paralelos. Por exemplo, soluções de custódia baseadas em TEE (como sistemas Vault) para chaves de Bitcoin, ou certas propostas em DLC (Contratos de Log Discreto) para usar oráculos que podem ser protegidos por TEE. Geralmente, a comunidade Bitcoin é mais conservadora e não confiaria facilmente na Intel como parte do consenso, mas como tecnologia auxiliar (carteiras de hardware com elementos seguros) já é aceita.

• Reguladores e Governos: Uma faceta interessante da adoção: algumas pesquisas sobre CBDC (moeda digital de banco central) analisaram os TEEs para impor a privacidade, permitindo ao mesmo tempo a auditabilidade. Por exemplo, o Banco da França realizou experimentos onde usou um TEE para lidar com certas verificações de conformidade em transações de outra forma privadas. Isso mostra que até mesmo os reguladores veem os TEEs como uma forma de equilibrar privacidade com supervisão – você poderia ter uma CBDC onde as transações são criptografadas para o público, mas um enclave regulador pode revisá-las sob certas condições (isso é hipotético, mas discutido em círculos de políticas).

• Métricas de Adoção: É difícil quantificar a adoção, mas podemos olhar para indicadores como: número de projetos, fundos investidos, disponibilidade de infraestrutura. Nesse aspecto, hoje (2025) temos: pelo menos 3-4 cadeias públicas (Secret, Oasis, Sanders, Integritee, Automata como off-chain) usando explicitamente TEEs; grandes redes de oráculos incorporando-o; grandes empresas de tecnologia apoiando a computação confidencial (Microsoft Azure, Google Cloud oferecem VMs TEE – e esses serviços estão sendo usados por nós de blockchain como opções). O Confidential Computing Consortium agora inclui membros focados em blockchain (Ethereum Foundation, Chainlink, Fortanix, etc.), mostrando colaboração intersetorial. Tudo isso aponta para uma adoção crescente, mas de nicho – os TEEs ainda não são onipresentes na Web3, mas conquistaram nichos importantes onde a privacidade e a computação segura off-chain são necessárias.

7. Considerações de Negócios e Regulatórias​

O uso de TEEs em aplicações de blockchain levanta vários pontos de negócios e regulatórios que as partes interessadas devem considerar:

Conformidade com a Privacidade e Adoção Institucional​

Um dos impulsionadores de negócios para a adoção de TEEs é a necessidade de cumprir as regulamentações de privacidade de dados (como GDPR na Europa, HIPAA nos EUA para dados de saúde) enquanto se aproveita a tecnologia blockchain. As blockchains públicas, por padrão, transmitem dados globalmente, o que entra em conflito com regulamentações que exigem que dados pessoais sensíveis sejam protegidos. Os TEEs oferecem uma maneira de manter os dados confidenciais na cadeia e compartilhá-los apenas de maneiras controladas, permitindo assim a conformidade. Como observado, "os TEEs facilitam a conformidade com as regulamentações de privacidade de dados, isolando dados sensíveis do usuário e garantindo que sejam manuseados com segurança". Essa capacidade é crucial para trazer empresas e instituições para a Web3, pois elas não podem arriscar violar as leis. Por exemplo, um dApp de saúde que processa informações de pacientes poderia usar TEEs para garantir que nenhum dado bruto do paciente vaze na cadeia, satisfazendo os requisitos da HIPAA para criptografia e controle de acesso. Da mesma forma, um banco europeu poderia usar uma cadeia baseada em TEE para tokenizar e negociar ativos sem expor os detalhes pessoais dos clientes, alinhando-se com o GDPR.

Isso tem um ângulo regulatório positivo: alguns reguladores indicaram que soluções como TEEs (e conceitos relacionados de computação confidencial) são favoráveis porque fornecem aplicação técnica da privacidade. Vimos o Fórum Econômico Mundial e outros destacarem os TEEs como um meio de construir "privacidade por design" em sistemas de blockchain (essencialmente incorporando a conformidade no nível do protocolo). Assim, de uma perspectiva de negócios, os TEEs podem acelerar a adoção institucional removendo um dos principais bloqueadores (confidencialidade de dados). As empresas estão mais dispostas a usar ou construir em blockchain se souberem que há uma salvaguarda de hardware para seus dados.

Outro aspecto de conformidade é a auditabilidade e supervisão. As empresas muitas vezes precisam de registros de auditoria e da capacidade de provar aos auditores que estão no controle dos dados. Os TEEs podem realmente ajudar aqui, produzindo relatórios de atestado e logs seguros do que foi acessado. Por exemplo, o "logging durável" da Oasis em um enclave fornece um registro resistente a adulterações de operações sensíveis. Uma empresa pode mostrar esse registro aos reguladores para provar que, digamos, apenas código autorizado foi executado e apenas certas consultas foram feitas nos dados do cliente. Esse tipo de auditoria atestada poderia satisfazer os reguladores mais do que um sistema tradicional onde você confia nos logs do administrador de sistema.

Confiança e Responsabilidade​

Por outro lado, a introdução de TEEs muda a estrutura de confiança e, portanto, o modelo de responsabilidade nas soluções de blockchain. Se uma plataforma DeFi usa um TEE e algo dá errado devido a uma falha de hardware, quem é o responsável? Por exemplo, considere um cenário onde um bug do Intel SGX leva a um vazamento de detalhes de transações de swap secretas, fazendo com que os usuários percam dinheiro (front-run, etc.). Os usuários confiaram nas alegações de segurança da plataforma. A culpa é da plataforma ou da Intel? Legalmente, os usuários podem ir atrás da plataforma (que, por sua vez, pode ter que ir atrás da Intel). Isso complica as coisas porque você tem um provedor de tecnologia de terceiros (o fornecedor da CPU) profundamente no modelo de segurança. As empresas que usam TEEs precisam considerar isso em contratos e avaliações de risco. Algumas podem buscar garantias ou suporte dos fornecedores de hardware se usarem seus TEEs em infraestrutura crítica.

Há também a preocupação com a centralização: se a segurança de uma blockchain depende do hardware de uma única empresa (Intel ou AMD), os reguladores podem ver isso com ceticismo. Por exemplo, um governo poderia intimar ou coagir essa empresa a comprometer certos enclaves? Isso não é uma preocupação puramente teórica – considere as leis de controle de exportação: hardware de criptografia de alto grau pode estar sujeito a regulamentação. Se uma grande parte da infraestrutura cripto depende de TEEs, é concebível que os governos possam tentar inserir backdoors (embora não haja evidências disso, a percepção importa). Alguns defensores da privacidade apontam isso aos reguladores: que os TEEs concentram a confiança e, se algo, os reguladores deveriam examiná-los cuidadosamente. Por outro lado, os reguladores que desejam mais controle podem preferir TEEs em vez de privacidade baseada em matemática como ZK, porque com TEEs há pelo menos a noção de que a aplicação da lei poderia abordar o fornecedor de hardware com uma ordem judicial, se absolutamente necessário (por exemplo, para obter uma chave de atestado mestre ou algo assim – não que seja fácil ou provável, mas é uma via que não existe com ZK). Portanto, a recepção regulatória pode se dividir: os reguladores de privacidade (agências de proteção de dados) são pró-TEE para conformidade, enquanto a aplicação da lei pode ser cautelosamente otimista, já que os TEEs não estão "ficando no escuro" da mesma forma que a criptografia forte – há uma alavanca teórica (o hardware) que eles podem tentar puxar.

As empresas precisam navegar nisso, possivelmente engajando-se em certificações. Existem certificações de segurança como FIPS 140 ou Common Criteria para módulos de hardware. Atualmente, o SGX e outros têm algumas certificações (por exemplo, o SGX tinha certificação Common Criteria EAL para certos usos). Se uma plataforma de blockchain puder apontar que a tecnologia do enclave é certificada com um alto padrão, reguladores e parceiros podem se sentir mais confortáveis. Por exemplo, um projeto de CBDC pode exigir que qualquer TEE usado seja certificado FIPS para que confiem em sua geração de números aleatórios, etc. Isso introduz processos adicionais e possivelmente restringe a certas versões de hardware.

Considerações de Ecossistema e Custo​

De uma perspectiva de negócios, usar TEEs pode afetar a estrutura de custos de uma operação de blockchain. Os nós devem ter CPUs específicas (que podem ser mais caras ou menos eficientes em termos de energia). Isso pode significar contas de hospedagem em nuvem mais altas ou despesas de capital. Por exemplo, se um projeto exige Intel Xeon com SGX para todos os validadores, isso é uma restrição – os validadores não podem ser qualquer pessoa com um Raspberry Pi ou um laptop antigo; eles precisam desse hardware. Isso pode centralizar quem pode participar (possivelmente favorecendo aqueles que podem pagar por servidores de ponta ou que usam provedores de nuvem que oferecem VMs SGX). Em extremos, isso pode levar a rede a ser mais permissionada ou a depender de provedores de nuvem, o que é um trade-off de descentralização e um trade-off de negócios (a rede pode ter que subsidiar os provedores de nós).

Por outro lado, algumas empresas podem achar isso aceitável porque querem validadores conhecidos ou têm uma lista de permissões (especialmente em consórcios empresariais). Mas em redes cripto públicas, isso causou debates – por exemplo, quando o SGX foi exigido, as pessoas perguntaram "isso significa que apenas grandes centros de dados executarão nós?". É algo que afeta o sentimento da comunidade e, portanto, a adoção de mercado. Por exemplo, alguns puristas de cripto podem evitar uma cadeia que exige TEEs, rotulando-a como "menos sem confiança" ou muito centralizada. Portanto, os projetos precisam lidar com relações públicas e educação da comunidade, deixando claro quais são as suposições de confiança e por que ainda é seguro. Vimos a Secret Network abordando o FUD explicando o monitoramento rigoroso das atualizações da Intel e que os validadores são penalizados se não atualizarem os enclaves, etc., basicamente criando uma camada social de confiança sobre a confiança no hardware.

Outra consideração são as parcerias e o suporte. O ecossistema de negócios em torno dos TEEs inclui grandes empresas de tecnologia (Intel, AMD, ARM, Microsoft, Google, etc.). Projetos de blockchain que usam TEEs muitas vezes fazem parceria com elas (por exemplo, iExec em parceria com a Intel, Secret Network trabalhando com a Intel em melhorias de atestado, Oasis com a Microsoft em IA confidencial, etc.). Essas parcerias podem fornecer financiamento, assistência técnica e credibilidade. É um ponto estratégico: alinhar-se com a indústria de computação confidencial pode abrir portas (para financiamento ou projetos piloto empresariais), mas também significa que um projeto cripto pode se alinhar com grandes corporações, o que tem implicações ideológicas na comunidade.

Incertezas Regulatórias​

À medida que as aplicações de blockchain que usam TEEs crescem, podem surgir novas questões regulatórias. Por exemplo:

• Jurisdição de Dados: Se os dados são processados dentro de um TEE em um determinado país, eles são considerados "processados naquele país" ou em lugar nenhum (já que estão criptografados)? Algumas leis de privacidade exigem que os dados dos cidadãos não saiam de certas regiões. Os TEEs podem borrar as linhas – você pode ter um enclave em uma região de nuvem, mas apenas dados criptografados entram/saem. Os reguladores podem precisar esclarecer como veem tal processamento.
• Controles de Exportação: A tecnologia de criptografia avançada pode estar sujeita a restrições de exportação. Os TEEs envolvem a criptografia de memória – historicamente, isso não tem sido um problema (já que CPUs com esses recursos são vendidas globalmente), mas se isso mudasse, poderia afetar o fornecimento. Além disso, alguns países podem proibir ou desencorajar o uso de TEEs estrangeiros devido à segurança nacional (por exemplo, a China tem seu próprio equivalente ao SGX, pois não confiam no da Intel, e podem não permitir o SGX para usos sensíveis).
• Compulsão Legal: Um cenário: um governo poderia intimar um operador de nó a extrair dados de um enclave? Normalmente, eles não podem, porque nem mesmo o operador pode ver lá dentro. Mas e se eles intimarem a Intel por uma chave de atestado específica? O design da Intel é tal que nem mesmo eles podem descriptografar a memória do enclave (eles emitem chaves para a CPU, que faz o trabalho). Mas se existisse um backdoor ou um firmware especial pudesse ser assinado pela Intel para despejar a memória, essa é uma hipótese que preocupa as pessoas. Legalmente, uma empresa como a Intel pode se recusar se for solicitada a minar sua segurança (provavelmente o faria, para não destruir a confiança em seu produto). Mas a mera possibilidade pode aparecer em discussões regulatórias sobre acesso legal. As empresas que usam TEEs devem se manter a par de quaisquer desenvolvimentos desse tipo, embora atualmente não exista nenhum mecanismo público para a Intel/AMD extrair dados de enclaves – esse é o ponto dos TEEs.

Diferenciação de Mercado e Novos Serviços​

No lado positivo para os negócios, os TEEs permitem novos produtos e serviços que podem ser monetizados. Por exemplo:

• Mercados de dados confidenciais: Como o iExec, o Ocean Protocol e outros notaram, as empresas detêm dados valiosos que poderiam monetizar se tivessem garantias de que não vazariam. Os TEEs permitem o "aluguel de dados", onde os dados nunca saem do enclave, apenas os insights. Isso poderia desbloquear novos fluxos de receita e modelos de negócios. Vemos startups na Web3 oferecendo serviços de computação confidencial para empresas, essencialmente vendendo a ideia de "obter insights de dados de blockchain ou entre empresas sem expor nada".
• DeFi Empresarial: As instituições financeiras muitas vezes citam a falta de privacidade como uma razão para não se envolverem com DeFi ou blockchain pública. Se os TEEs puderem garantir a privacidade de suas posições ou negociações, elas podem participar, trazendo mais liquidez e negócios para o ecossistema. Projetos que atendem a isso (como os empréstimos secretos da Secret, ou o AMM privado da Oasis com controles de conformidade) estão se posicionando para atrair usuários institucionais. Se bem-sucedido, isso pode ser um mercado significativo (imagine pools de AMM institucionais onde identidades e valores são protegidos, mas um enclave garante que verificações de conformidade como AML sejam feitas internamente – esse é um produto que poderia trazer muito dinheiro para o DeFi sob o conforto regulatório).
• Seguros e Gerenciamento de Risco: Com os TEEs reduzindo certos riscos (como manipulação de oráculos), podemos ver prêmios de seguro mais baixos ou novos produtos de seguro para plataformas de contratos inteligentes. Por outro lado, os TEEs introduzem novos riscos (como falha técnica de enclaves) que podem ser eventos seguráveis. Há uma área incipiente de seguros cripto; como eles tratarão os sistemas dependentes de TEE será interessante. Uma plataforma pode divulgar que usa TEEs para diminuir o risco de violação de dados, tornando mais fácil/barato segurá-la, dando-lhe uma vantagem competitiva.

Em conclusão, o cenário de negócios e regulatório da Web3 habilitada por TEE trata de equilibrar confiança e inovação. Os TEEs oferecem uma rota para cumprir as leis e desbloquear casos de uso empresariais (um grande ponto positivo para a adoção mainstream), mas também trazem uma dependência de provedores de hardware e complexidades que devem ser gerenciadas de forma transparente. As partes interessadas precisam se envolver tanto com gigantes da tecnologia (para suporte) quanto com reguladores (para clareza e garantia) para realizar plenamente o potencial dos TEEs na blockchain. Se bem feito, os TEEs podem ser um pilar que permite que a blockchain se integre profundamente com indústrias que lidam com dados sensíveis, expandindo assim o alcance da Web3 para áreas anteriormente fora dos limites devido a preocupações com a privacidade.

Conclusão​

Os Ambientes de Execução Confiáveis surgiram como um componente poderoso no conjunto de ferramentas da Web3, permitindo uma nova classe de aplicações descentralizadas que exigem confidencialidade e computação segura off-chain. Vimos que os TEEs, como o Intel SGX, ARM TrustZone e AMD SEV, fornecem uma "caixa segura" isolada por hardware para computação, e essa propriedade tem sido aproveitada para contratos inteligentes que preservam a privacidade, oráculos verificáveis, processamento off-chain escalável e muito mais. Projetos em todos os ecossistemas – desde os contratos privados da Secret Network no Cosmos, aos ParaTimes confidenciais da Oasis, à nuvem TEE da Sanders na Polkadot, e ao mercado off-chain do iExec na Ethereum – demonstram as diversas maneiras como os TEEs estão sendo integrados às plataformas de blockchain.

Tecnicamente, os TEEs oferecem benefícios convincentes de velocidade e forte confidencialidade de dados, mas vêm com seus próprios desafios: a necessidade de confiar nos fornecedores de hardware, potenciais vulnerabilidades de canal lateral e obstáculos na integração e composabilidade. Comparamos os TEEs com alternativas criptográficas (ZKPs, FHE, MPC) e descobrimos que cada um tem seu nicho: os TEEs brilham em desempenho e facilidade de uso, enquanto ZK e FHE fornecem máxima ausência de confiança a um alto custo, e a MPC distribui a confiança entre os participantes. Na verdade, muitas soluções de ponta são híbridas, usando TEEs ao lado de métodos criptográficos para obter o melhor dos dois mundos.

A adoção de soluções baseadas em TEE está crescendo constantemente. Os dApps da Ethereum aproveitam os TEEs para segurança de oráculos e computações privadas, Cosmos e Polkadot têm suporte nativo através de cadeias especializadas, e os esforços de blockchain empresarial estão abraçando os TEEs para conformidade. Do ponto de vista de negócios, os TEEs podem ser uma ponte entre a tecnologia descentralizada e a regulamentação – permitindo que dados sensíveis sejam manuseados na cadeia sob as salvaguardas da segurança de hardware, o que abre as portas para o uso institucional e novos serviços. Ao mesmo tempo, usar TEEs significa se envolver com novos paradigmas de confiança e garantir que o ethos de descentralização da blockchain não seja minado por silício opaco.

Em resumo, os Ambientes de Execução Confiáveis estão desempenhando um papel crucial na evolução da Web3: eles abordam algumas das preocupações mais prementes de privacidade e escalabilidade e, embora não sejam uma panaceia (e não sem controvérsia), eles expandem significativamente o que as aplicações descentralizadas podem fazer. À medida que a tecnologia amadurece – com melhorias na segurança do hardware e padrões para atestado – e à medida que mais projetos demonstram seu valor, podemos esperar que os TEEs (juntamente com a tecnologia criptográfica complementar) se tornem um componente padrão das arquiteturas de blockchain destinadas a desbloquear todo o potencial da Web3 de maneira segura e confiável. O futuro provavelmente reserva soluções em camadas, onde hardware e criptografia trabalham lado a lado para entregar sistemas que são tanto performáticos quanto comprovadamente seguros, atendendo às necessidades de usuários, desenvolvedores e reguladores.

Fontes: As informações neste relatório foram coletadas de uma variedade de fontes atualizadas, incluindo documentação oficial de projetos e blogs, análises da indústria e pesquisas acadêmicas, conforme citado ao longo do texto. Referências notáveis incluem o guia Metaschool 2025 sobre TEEs na Web3, comparações da Sanders Network, insights técnicos da ChainCatcher e outros sobre FHE/TEE/ZKP/MPC, e declarações sobre conformidade regulatória da Binance Research, entre muitos outros. Essas fontes fornecem mais detalhes e são recomendadas para leitores que desejam explorar aspectos específicos com maior profundidade.

Blockchains públicas oferecem transparência e integridade ao custo da privacidade – cada transação e estado de contrato são expostos a todos os participantes. Essa abertura cria problemas como ataques de MEV (Miner Extractable Value), copy-trading e vazamento de lógica de negócios sensível. A privacidade programável visa resolver esses problemas permitindo computações em dados privados sem revelar os próprios dados. Dois paradigmas criptográficos emergentes estão tornando isso possível: Máquinas Virtuais de Criptografia Totalmente Homomórfica (FHE-VM) e Coprocessadores de Conhecimento Zero (ZK). Essas abordagens permitem computação off-chain ou criptografada com verificação on-chain, preservando a confidencialidade enquanto mantêm a correção trustless. Neste relatório, mergulhamos fundo nas arquiteturas FHE-VM e ZK-coprocessor, comparamos seus trade-offs e exploramos casos de uso em finanças, identidade, saúde, mercados de dados e aprendizado de máquina descentralizado.

Máquina Virtual de Criptografia Totalmente Homomórfica (FHE-VM)​

A Criptografia Totalmente Homomórfica (FHE) permite computações arbitrárias em dados criptografados sem nunca descriptografá-los. Uma Máquina Virtual FHE integra essa capacidade em contratos inteligentes de blockchain, permitindo estado e lógica de contrato criptografados. Em uma blockchain habilitada para FHE (frequentemente chamada de fhEVM para designs compatíveis com EVM), todas as entradas, armazenamento de contrato e saídas permanecem criptografados durante toda a execução. Isso significa que os validadores podem processar transações e atualizar o estado sem aprender nenhum valor sensível, alcançando a execução on-chain com confidencialidade de dados.

Arquitetura e Design da FHE-VM​

Uma FHE-VM típica estende um tempo de execução de contrato inteligente padrão (como a Ethereum Virtual Machine) com suporte nativo para tipos de dados e operações criptografadas. Por exemplo, a FHEVM da Zama introduz inteiros criptografados (euint8, euint32, etc.), booleanos criptografados (ebool) e até mesmo arrays criptografados como tipos de primeira classe. Linguagens de contrato inteligente como Solidity são aumentadas por meio de bibliotecas ou novos opcodes para que os desenvolvedores possam realizar operações aritméticas (add, mul, etc.), lógicas e comparações diretamente em textos cifrados. Nos bastidores, essas operações invocam primitivas FHE (por exemplo, usando a biblioteca TFHE) para manipular bits criptografados e produzir resultados criptografados.

O armazenamento de estado criptografado é suportado para que as variáveis do contrato permaneçam criptografadas no estado da blockchain. O fluxo de execução é tipicamente:

1. Criptografia do Lado do Cliente: Os usuários criptografam suas entradas localmente usando a chave FHE pública antes de enviar transações. A chave de criptografia é pública (para criptografia e avaliação), enquanto a chave de descriptografia permanece secreta. Em alguns designs, cada usuário gerencia sua própria chave; em outros, uma única chave FHE global é usada (discutido abaixo).
2. Computação Homomórfica On-Chain: Mineradores/validadores executam o contrato com opcodes criptografados. Eles realizam as mesmas operações homomórficas determinísticas nos textos cifrados, para que o consenso possa ser alcançado sobre o novo estado criptografado. Crucialmente, os validadores nunca veem dados em texto claro – eles apenas veem texto cifrado "sem sentido", mas ainda podem processá-lo de forma consistente.
3. Descriptografia (Opcional): Se um resultado precisar ser revelado ou usado off-chain, uma parte autorizada com a chave privada pode descriptografar o texto cifrado de saída. Caso contrário, os resultados permanecem criptografados e podem ser usados como entradas para transações futuras (permitindo computações consecutivas em estado criptografado persistente).

Uma consideração de design importante é o gerenciamento de chaves. Uma abordagem é de chaves por usuário, onde cada usuário detém sua chave secreta e apenas eles podem descriptografar saídas relevantes para eles. Isso maximiza a privacidade (ninguém mais pode descriptografar seus dados), mas as operações homomórficas não podem misturar dados criptografados sob chaves diferentes sem protocolos complexos de múltiplas chaves. Outra abordagem, usada pela FHEVM da Zama, é uma chave FHE global: uma única chave pública criptografa todos os dados do contrato e um conjunto distribuído de validadores detém partes da chave de descriptografia de limiar. As chaves públicas de criptografia e avaliação são publicadas on-chain, para que qualquer pessoa possa criptografar dados para a rede; a chave privada é dividida entre os validadores que podem descriptografar coletivamente, se necessário, sob um esquema de limiar. Para evitar que a conivência de validadores comprometa a privacidade, a Zama emprega um protocolo FHE de limiar (baseado em sua pesquisa Noah’s Ark) com "inundação de ruído" para tornar as descriptografias parciais seguras. Apenas se um quórum suficiente de validadores cooperar, um texto claro pode ser recuperado, por exemplo, para atender a uma solicitação de leitura. Em operação normal, no entanto, nenhum nó único jamais vê o texto claro – os dados permanecem criptografados on-chain o tempo todo.

O controle de acesso é outro componente crucial. As implementações de FHE-VM incluem controles refinados para gerenciar quem (se houver alguém) pode acionar descriptografias ou acessar certos campos criptografados. Por exemplo, a fhEVM da Cypher suporta Listas de Controle de Acesso em textos cifrados, permitindo que os desenvolvedores especifiquem quais endereços ou contratos podem interagir ou recriptografar certos dados. Alguns frameworks suportam recriptografia: a capacidade de transferir um valor criptografado da chave de um usuário para a de outro sem expor o texto claro. Isso é útil para coisas como mercados de dados, onde um proprietário de dados pode criptografar um conjunto de dados com sua chave e, após a compra, recriptografá-lo para a chave do comprador – tudo on-chain, sem nunca descriptografar publicamente.

Garantindo Correção e Privacidade​

Alguém pode perguntar: se todos os dados são criptografados, como garantimos a correção da lógica do contrato? Como a cadeia pode impedir operações inválidas se não consegue "ver" os valores? A FHE por si só não fornece uma prova de correção – os validadores podem realizar os passos homomórficos, mas não podem inerentemente dizer se a entrada criptografada de um usuário era válida ou se um desvio condicional deveria ser tomado, etc., sem descriptografar. Provas de conhecimento zero (ZKPs) podem complementar a FHE para resolver essa lacuna. Em uma FHE-VM, tipicamente os usuários devem fornecer uma prova ZK atestando certas condições de texto claro sempre que necessário. O design da Zama, por exemplo, usa uma Prova ZK de Conhecimento de Texto Claro (ZKPoK) para acompanhar cada entrada criptografada. Isso prova que o usuário conhece o texto claro correspondente ao seu texto cifrado e que ele atende aos critérios esperados, sem revelar o próprio texto claro. Tais "textos cifrados certificados" impedem que um usuário mal-intencionado envie uma criptografia malformada ou um valor fora do intervalo. Da mesma forma, para operações que exigem uma decisão (por exemplo, garantir que o saldo da conta ≥ valor do saque), o usuário pode fornecer uma prova ZK de que essa condição é verdadeira nos textos claros antes que a operação criptografada seja executada. Dessa forma, a cadeia não descriptografa ou vê os valores, mas ganha confiança de que as transações criptografadas seguem as regras.

Outra abordagem em rollups FHE é realizar validação off-chain com ZKPs. A Fhenix (um rollup L2 usando FHE) opta por um modelo otimista onde um componente de rede separado chamado Rede de Serviço de Limiar pode descriptografar ou verificar resultados criptografados, e qualquer computação incorreta pode ser contestada com uma prova de fraude. Em geral, combinar FHE + ZK ou provas de fraude garante que a execução criptografada permaneça trustless. Os validadores ou descriptografam coletivamente apenas quando autorizados, ou verificam provas de que cada transição de estado criptografada foi válida sem precisar ver o texto claro.

Considerações de desempenho: As operações FHE são computacionalmente pesadas – muitas ordens de magnitude mais lentas que a aritmética normal. Por exemplo, uma simples adição de 64 bits no Ethereum custa ~3 gas, enquanto uma adição em um inteiro criptografado de 64 bits (euint64) na FHEVM da Zama custa aproximadamente 188.000 gas. Mesmo uma adição de 8 bits pode custar ~94k gas. Essa enorme sobrecarga significa que uma implementação direta em nós existentes seria impraticavelmente lenta e cara. Projetos de FHE-VM enfrentam isso com bibliotecas criptográficas otimizadas (como a biblioteca TFHE-rs da Zama para bootstrapping de portões binários) e modificações personalizadas na EVM para desempenho. Por exemplo, o cliente Geth modificado da Cypher adiciona novos opcodes e otimiza a execução de instruções homomórficas em C++/assembly para minimizar a sobrecarga. No entanto, alcançar uma taxa de transferência utilizável requer aceleração. O trabalho em andamento inclui o uso de GPUs, FPGAs e até mesmo chips fotônicos especializados para acelerar as computações FHE. A Zama relata que seu desempenho FHE melhorou 100x desde 2024 e está visando milhares de TPS com aceleração de GPU/FPGA. Servidores coprocessadores FHE dedicados (como o LightLocker Node da Optalysys) podem ser conectados a nós validadores para descarregar operações criptografadas para hardware, suportando >100 transferências ERC-20 criptografadas por segundo por nó. À medida que o hardware e os algoritmos melhoram, a lacuna entre FHE e computação em texto claro diminuirá, permitindo que contratos privados se aproximem de velocidades mais práticas.

Compatibilidade: Um objetivo chave dos designs de FHE-VM é permanecer compatível com os fluxos de trabalho de desenvolvimento existentes. As implementações fhEVM da Cypher e da Zama permitem que os desenvolvedores escrevam contratos em Solidity com mudanças mínimas – usando uma biblioteca para declarar tipos e operações criptografadas. O resto do conjunto de ferramentas do Ethereum (Remix, Hardhat, etc.) ainda pode ser usado, pois as modificações subjacentes estão principalmente no nível do cliente/nó. Isso diminui a barreira de entrada: os desenvolvedores não precisam ser especialistas em criptografia para escrever um contrato inteligente confidencial. Por exemplo, uma simples adição de dois números pode ser escrita como euint32 c = a + b; e a FHEVM cuidará dos detalhes específicos da criptografia nos bastidores. Os contratos podem até interoperar com contratos normais – por exemplo, um contrato criptografado poderia produzir um resultado descriptografado para um contrato padrão, se desejado, permitindo uma mistura de partes privadas e públicas em um ecossistema.

Projetos FHE-VM Atuais: Vários projetos são pioneiros neste espaço. A Zama (uma startup de FHE sediada em Paris) desenvolveu o conceito central da FHEVM e bibliotecas (TFHE-rs e uma biblioteca fhevm-solidity). Eles não pretendem lançar sua própria cadeia, mas sim fornecer infraestrutura para outros. A Inco é uma blockchain L1 (construída no Cosmos SDK com Evmos) que integrou a FHEVM da Zama para criar uma cadeia confidencial modular. Suas testnets (chamadas Gentry e Paillier) demonstram transferências ERC-20 criptografadas e outras primitivas DeFi privadas. A Fhenix é um rollup otimista de Camada 2 do Ethereum usando FHE para privacidade. Ela decidiu por uma abordagem otimista (prova de fraude) em vez de ZK-rollup devido ao alto custo de fazer FHE e ZK juntos para cada bloco. A Fhenix usa a mesma biblioteca TFHE-rs (com algumas modificações) e introduz uma Rede de Serviço de Limiar para lidar com descriptografias de forma descentralizada. Existem também equipes independentes como a Fhenix (agora rebatizada) e startups explorando híbridos MPC + FHE. Além disso, a Cypher (da Z1 Labs) está construindo uma rede de Camada 3 focada em IA e privacidade, usando uma fhEVM com recursos como cofres secretos e suporte a aprendizado federado. O ecossistema é nascente, mas está crescendo rapidamente, impulsionado por financiamento significativo – por exemplo, a Zama se tornou um "unicórnio" com mais de US$ 130 milhões arrecadados até 2025 para avançar a tecnologia FHE.

Em resumo, uma FHE-VM permite contratos inteligentes que preservam a privacidade ao executar toda a lógica em dados criptografados on-chain. Este paradigma garante confidencialidade máxima – nada sensível é exposto em transações ou estado – enquanto aproveita o consenso de blockchain existente para integridade. O custo é o aumento da carga computacional sobre os validadores e a complexidade no gerenciamento de chaves e na integração de provas. A seguir, exploramos um paradigma alternativo que descarrega a computação totalmente off-chain e usa a cadeia apenas para verificação: o coprocessador de conhecimento zero.

Coprocessadores de Conhecimento Zero (ZK-Coprocessors)​

Um coprocessador ZK é um novo padrão de arquitetura de blockchain onde computações caras são realizadas off-chain, e uma prova de conhecimento zero sucinta de sua correção é verificada on-chain. Isso permite que contratos inteligentes aproveitem um poder computacional e dados muito maiores do que a execução on-chain permitiria, sem sacrificar a natureza trustless. O termo coprocessador é usado por analogia aos coprocessadores de hardware (como um coprocessador matemático ou GPU) que lidam com tarefas especializadas para uma CPU. Aqui, a "CPU" da blockchain (a VM nativa como a EVM) delega certas tarefas a um sistema de prova de conhecimento zero que atua como um coprocessador criptográfico. O coprocessador ZK retorna um resultado e uma prova de que o resultado foi calculado corretamente, que o contrato on-chain pode verificar e então usar.

Arquitetura e Fluxo de Trabalho​

Em uma configuração típica, um desenvolvedor de dApp identifica partes da lógica de sua aplicação que são muito caras ou complexas para execução on-chain (por exemplo, grandes computações sobre dados históricos, algoritmos pesados, inferência de modelos de ML, etc.). Eles implementam essas partes como um programa off-chain (em uma linguagem de alto nível ou DSL de circuito) que pode produzir uma prova de conhecimento zero de sua execução. O componente on-chain é um contrato inteligente verificador que verifica as provas e disponibiliza os resultados para o resto do sistema. O fluxo pode ser resumido como:

1. Requisição – O contrato on-chain aciona uma requisição para que uma certa computação seja feita off-chain. Isso pode ser iniciado por uma transação de usuário ou por um contrato chamando a interface do coprocessador ZK. Por exemplo, um contrato DeFi pode chamar “provarTaxaDeJuros(estadoAtual)” ou um usuário chama “consultarDadosHistoricos(consulta)”.
2. Execução e Prova Off-Chain – Um serviço off-chain (que pode ser uma rede descentralizada de provadores ou um serviço confiável, dependendo do design) pega a requisição. Ele reúne todos os dados necessários (estado on-chain, entradas off-chain, etc.) e executa a computação em uma Máquina Virtual ZK (ZKVM) especial ou circuito. Durante a execução, um traço de prova é gerado. No final, o serviço produz uma prova sucinta (por exemplo, um SNARK ou STARK) atestando que “Computar a função F na entrada X resulta na saída Y” e, opcionalmente, atestando a integridade dos dados (mais sobre isso abaixo).
3. Verificação On-Chain – A prova e o resultado são retornados para a blockchain (geralmente por meio de uma função de callback). O contrato verificador verifica a validade da prova usando verificação criptográfica eficiente (verificações de emparelhamento, etc.). Se válida, o contrato pode agora confiar na saída Y como correta. O resultado pode ser armazenado no estado, emitido como um evento ou alimentado em lógica de contrato adicional. Se a prova for inválida ou não for fornecida dentro de algum tempo, a requisição pode ser considerada falha (e potencialmente alguma lógica de fallback ou timeout é acionada).

Figura 1: Arquitetura de um Coprocessador ZK (exemplo do RISC Zero Bonsai). Off-chain, um programa é executado em uma ZKVM com entradas da chamada do contrato inteligente. Uma prova de execução é retornada on-chain por meio de um contrato de retransmissão, que invoca um callback com os resultados verificados.

Criticamente, o custo de gas on-chain para verificação é constante (ou cresce muito lentamente), independentemente de quão complexa foi a computação off-chain. Verificar uma prova sucinta pode custar na ordem de algumas centenas de milhares de gas (uma fração de um bloco do Ethereum), mas essa prova pode representar milhões de passos computacionais feitos off-chain. Como um desenvolvedor brincou, “Quer provar uma assinatura digital? ~$15. Quer provar um milhão de assinaturas? Também ~$15.”. Essa escalabilidade é uma grande vitória: dApps podem oferecer funcionalidades complexas (análise de big data, modelos financeiros elaborados, etc.) sem sobrecarregar a blockchain.

Os principais componentes de um sistema de coprocessador ZK são:

• Ambiente de Geração de Prova: Pode ser uma ZKVM de propósito geral (capaz de executar programas arbitrários) ou circuitos personalizados adaptados a computações específicas. As abordagens variam:

  • Alguns projetos usam circuitos feitos à mão para cada consulta ou função suportada (maximizando a eficiência para essa função).
  • Outros fornecem uma Linguagem Específica de Domínio (DSL) ou uma DSL Embutida que os desenvolvedores usam para escrever sua lógica off-chain, que é então compilada em circuitos (equilibrando facilidade de uso e desempenho).
  • A abordagem mais flexível é uma zkVM: uma máquina virtual (geralmente baseada em arquiteturas RISC) onde programas podem ser escritos em linguagens padrão (Rust, C, etc.) e automaticamente provados. Isso sacrifica o desempenho (simular uma CPU em um circuito adiciona sobrecarga) pela máxima experiência do desenvolvedor.

• Acesso e Integridade de Dados: Um desafio único é alimentar a computação off-chain com os dados corretos, especialmente se esses dados residem na blockchain (blocos passados, estados de contrato, etc.). Uma solução ingênua é fazer com que o provador leia de um nó de arquivo e confie nele – mas isso introduz suposições de confiança. Em vez disso, os coprocessadores ZK normalmente provam que quaisquer dados on-chain usados eram de fato autênticos, vinculando-se a provas de Merkle ou compromissos de estado. Por exemplo, o programa de consulta pode pegar um número de bloco e uma prova de Merkle de um slot de armazenamento ou transação, e o circuito verificará essa prova contra um hash de cabeçalho de bloco conhecido. Existem três padrões:

  1. Dados Inline: Colocar os dados necessários on-chain (como entrada para o verificador) para que possam ser verificados diretamente. Isso é muito caro para grandes volumes de dados e mina todo o propósito.
  2. Confiar em um Oráculo: Ter um serviço de oráculo alimentando os dados para a prova e atestando por eles. Isso é mais simples, mas reintroduz a confiança em um terceiro.
  3. Provar a Inclusão de Dados via ZK: Incorporar provas de inclusão de dados no histórico da cadeia dentro do próprio circuito de conhecimento zero. Isso aproveita o fato de que cada cabeçalho de bloco do Ethereum se compromete com todo o estado anterior (via raiz de estado) e histórico de transações. Ao verificar provas de Merkle Patricia dos dados dentro do circuito, a prova de saída garante ao contrato que “esta computação usou dados genuínos da blockchain do bloco N” sem necessidade de confiança adicional.

  A terceira abordagem é a mais trustless e é usada por coprocessadores ZK avançados como Axiom e Xpansion (aumenta o custo de prova, mas é preferível por segurança). Por exemplo, o sistema da Axiom modela a estrutura de blocos do Ethereum, a trie de estado e a trie de transações dentro de seus circuitos, para que possa provar declarações como “a conta X tinha saldo Y no bloco N” ou “uma transação com certas propriedades ocorreu no bloco N”. Ele aproveita o fato de que, dado um hash de bloco confiável recente, pode-se provar recursivamente a inclusão de dados históricos sem confiar em nenhuma parte externa.

• Contrato Verificador: Este contrato on-chain contém a chave de verificação e a lógica para aceitar ou rejeitar provas. Para SNARKs como Groth16 ou PLONK, o verificador pode fazer alguns emparelhamentos de curva elíptica; para STARKs, pode fazer alguns cálculos de hash. Otimizações de desempenho como agregação e recursão podem minimizar a carga on-chain. Por exemplo, o Bonsai da RISC Zero usa um wrapper STARK-para-SNARK: ele executa uma VM baseada em STARK off-chain para velocidade, mas depois gera uma pequena prova SNARK atestando a validade do STARK. Isso reduz o tamanho da prova de centenas de kilobytes para algumas centenas de bytes, tornando a verificação on-chain viável e barata. O verificador Solidity então apenas verifica o SNARK (que é uma operação de tempo constante).

Em termos de implantação, os coprocessadores ZK podem funcionar como redes semelhantes a camada-2 ou como serviços puramente off-chain. Alguns, como a Axiom, começaram como um serviço especializado para o Ethereum (com o apoio da Paradigm), onde os desenvolvedores enviam consultas para a rede de provadores da Axiom e obtêm provas on-chain. O slogan da Axiom era fornecer aos contratos do Ethereum “acesso trustless a todos os dados on-chain e computação expressiva arbitrária sobre eles.” Ele efetivamente atua como um oráculo de consulta onde as respostas são verificadas por ZKPs em vez de confiança. Outros, como o Bonsai da RISC Zero, oferecem uma plataforma mais aberta: qualquer desenvolvedor pode enviar um programa (compilado para uma ZKVM compatível com RISC-V) e usar o serviço de prova do Bonsai por meio de um contrato de retransmissão. O padrão de retransmissão, como ilustrado na Figura 1, envolve um contrato que media requisições e respostas: o contrato do dApp chama o retransmissor para pedir uma prova, o serviço off-chain escuta isso (por exemplo, via evento ou chamada direta), computa a prova, e então o retransmissor invoca uma função de callback no contrato do dApp com o resultado e a prova. Este modelo assíncrono é necessário porque a prova pode levar de segundos a minutos, dependendo da complexidade. Ele introduz uma latência (e uma suposição de liveness de que o provador responderá), enquanto as computações FHE-VM acontecem sincronicamente dentro de um bloco. Projetar a aplicação para lidar com esse fluxo de trabalho assíncrono (possivelmente semelhante às respostas de Oráculo) faz parte do uso de um coprocessador ZK.

Projetos Notáveis de Coprocessador ZK​

• Axiom: A Axiom é um coprocessador ZK adaptado para o Ethereum, focado originalmente em provar consultas de dados on-chain históricos. Ele usa o framework de prova Halo2 (um SNARK do tipo Plonk) para criar provas que incorporam as estruturas criptográficas do Ethereum. No sistema da Axiom, um desenvolvedor pode consultar coisas como “qual era o estado do contrato X no bloco N?” ou realizar uma computação sobre todas as transações em um intervalo. Nos bastidores, os circuitos da Axiom tiveram que implementar a lógica de estado/trie do Ethereum, até mesmo realizando operações de curva elíptica e verificação de SNARK dentro do circuito para suportar recursão. A Trail of Bits, em uma auditoria, notou a complexidade dos circuitos Halo2 da Axiom modelando blocos e estados inteiros. Após a auditoria, a Axiom generalizou sua tecnologia em uma OpenVM, permitindo que código Rust arbitrário fosse provado com a mesma infraestrutura baseada em Halo2. (Isso reflete a tendência de passar de circuitos específicos de domínio para uma abordagem ZKVM mais geral.) A equipe da Axiom demonstrou consultas ZK que o Ethereum nativamente não pode fazer, permitindo acesso sem estado a quaisquer dados históricos com integridade criptográfica. Eles também enfatizaram a segurança, capturando e corrigindo bugs de circuito sub-restringidos e garantindo a solidez. Embora o produto inicial da Axiom tenha sido descontinuado durante sua mudança de foco, sua abordagem permanece um marco nos coprocessadores ZK.

• RISC Zero Bonsai: A RISC Zero é uma ZKVM baseada na arquitetura RISC-V. Sua zkVM pode executar programas arbitrários (escritos em Rust, C++ e outras linguagens compiladas para RISC-V) e produzir uma prova STARK de execução. O Bonsai é o serviço em nuvem da RISC Zero que fornece essa prova sob demanda, atuando como um coprocessador para contratos inteligentes. Para usá-lo, um desenvolvedor escreve um programa (digamos, uma função que realiza matemática complexa ou verifica uma resposta de API off-chain), o envia para o serviço Bonsai e implanta um contrato verificador correspondente. Quando o contrato precisa dessa computação, ele chama o retransmissor Bonsai, que aciona a geração da prova e retorna o resultado via callback. Uma aplicação de exemplo demonstrada foi a computação de governança off-chain: a RISC Zero mostrou uma DAO usando o Bonsai para contar votos e computar métricas de votação complexas off-chain, e então postar uma prova para que o contrato Governor on-chain pudesse confiar no resultado com custo mínimo de gas. A tecnologia da RISC Zero enfatiza que os desenvolvedores podem usar paradigmas de programação familiares – por exemplo, escrever uma função em Rust para computar algo – e o trabalho pesado de criação de circuitos é tratado pela zkVM. No entanto, as provas podem ser grandes, então, como observado anteriormente, eles implementaram uma compressão SNARK para verificação on-chain. Em agosto de 2023, eles verificaram com sucesso provas da RISC Zero na testnet Sepolia do Ethereum, custando na ordem de 300k de gas por prova. Isso abre as portas para que dApps do Ethereum usem o Bonsai hoje como uma solução de escalabilidade e privacidade. (O Bonsai ainda está em alfa, não pronto para produção, e usa uma configuração SNARK temporária sem uma cerimônia.)

• Outros: Existem vários outros players e iniciativas de pesquisa. A Expansion/Xpansion (como mencionado em um blog) usa uma abordagem de DSL embutida, onde os desenvolvedores podem escrever consultas sobre dados on-chain com uma linguagem especializada, e ela lida com a geração de provas internamente. O Cairo da StarkWare e o zkEVM da Polygon são VMs de ZK-rollup mais gerais, mas sua tecnologia poderia ser reaproveitada para uso semelhante a coprocessadores, verificando provas dentro de contratos L1. Também vemos projetos no domínio ZKML (ZK Machine Learning), que efetivamente atuam como coprocessadores para verificar a inferência de modelos de ML ou resultados de treinamento on-chain. Por exemplo, uma configuração zkML pode provar que “uma inferência de rede neural em entradas privadas produziu a classificação X” sem revelar as entradas ou fazer a computação on-chain. Estes são casos especiais do conceito de coprocessador aplicado à IA.

Suposições de confiança: Os coprocessadores ZK dependem da solidez das provas criptográficas. Se o sistema de prova for seguro (e qualquer configuração confiável for feita honestamente), então uma prova aceita garante que a computação foi correta. Nenhuma confiança adicional no provador é necessária – mesmo um provador mal-intencionado não pode convencer o verificador de uma declaração falsa. No entanto, existe uma suposição de liveness: alguém deve realmente realizar a computação off-chain e produzir a prova. Na prática, isso pode ser uma rede descentralizada (com incentivos ou taxas para fazer o trabalho) ou um único operador de serviço. Se ninguém fornecer a prova, a requisição on-chain pode permanecer não resolvida. Outro aspecto sutil de confiança é a disponibilidade de dados para entradas off-chain que não estão na blockchain. Se a computação depende de alguns dados privados ou externos, o verificador não pode saber se esses dados foram fornecidos honestamente, a menos que medidas adicionais (como compromissos de dados ou assinaturas de oráculo) sejam usadas. Mas para computações de dados puramente on-chain, os mecanismos descritos garantem uma natureza trustless equivalente à própria cadeia (a Axiom argumentou que suas provas oferecem "segurança criptograficamente equivalente ao Ethereum" para consultas históricas).

Privacidade: Provas de conhecimento zero também suportam inerentemente a privacidade – o provador pode manter as entradas ocultas enquanto prova declarações sobre elas. Em um contexto de coprocessador, isso significa que uma prova pode permitir que um contrato use um resultado que foi derivado de dados privados. Por exemplo, uma prova pode mostrar “a pontuação de crédito do usuário > 700, então aprove o empréstimo” sem revelar a pontuação de crédito real ou os dados brutos. O caso de uso da Axiom era mais sobre dados publicamente conhecidos (histórico da blockchain), então a privacidade não era o foco lá. Mas a zkVM da RISC Zero poderia ser usada para provar asserções sobre dados secretos fornecidos por um usuário: os dados permanecem off-chain e apenas o resultado necessário vai para on-chain. Vale a pena notar que, ao contrário da FHE, uma prova ZK geralmente não fornece confidencialidade contínua do estado – é uma prova única. Se um fluxo de trabalho precisa manter um estado secreto entre transações, pode-se construí-lo fazendo com que o contrato armazene um compromisso com o estado e cada prova mostrando uma transição de estado válida do compromisso antigo para o novo, com os segredos ocultos. É essencialmente assim que os zk-rollups para transações privadas (como Aztec ou Zcash) funcionam. Portanto, os coprocessadores ZK podem facilitar máquinas de estado totalmente privadas, mas a implementação não é trivial; muitas vezes eles são usados para computações únicas onde a entrada ou a saída (ou ambas) podem ser privadas conforme necessário.

Experiência do desenvolvedor: Usar um coprocessador ZK geralmente requer o aprendizado de novas ferramentas. Escrever circuitos personalizados (opção (1) acima) é bastante complexo e geralmente feito apenas para fins específicos. Opções de nível superior como DSLs ou zkVMs facilitam a vida, mas ainda adicionam sobrecarga: o desenvolvedor deve escrever e implantar código off-chain e gerenciar a interação. Em contraste com a FHE-VM, onde a criptografia é principalmente tratada nos bastidores e o desenvolvedor escreve código de contrato inteligente normal, aqui o desenvolvedor precisa particionar sua lógica e possivelmente escrever em uma linguagem diferente (Rust, etc.) para a parte off-chain. No entanto, iniciativas como as DSLs Noir, Leo, Circom ou a abordagem da RISC Zero estão melhorando rapidamente a acessibilidade. Por exemplo, a RISC Zero fornece modelos e integração com o Foundry para que um desenvolvedor possa simular seu código off-chain localmente (para correção) e depois conectá-lo perfeitamente a testes em Solidity por meio do callback do Bonsai. Com o tempo, podemos esperar frameworks de desenvolvimento que abstraiam se uma parte da lógica é executada via prova ZK ou on-chain – o compilador ou as ferramentas podem decidir com base no custo.

FHE-VM vs Coprocessador ZK: Comparação​

Tanto as FHE-VMs quanto os coprocessadores ZK permitem uma forma de “computação em dados privados com garantia on-chain”, mas diferem fundamentalmente em arquitetura. A tabela abaixo resume as principais diferenças:

Aspecto	FHE-VM (Execução Criptografada On-Chain) -	Coprocessador ZK (Prova Off-Chain) -
Onde a computação acontece	Diretamente on-chain (todos os nós executam operações homomórficas em textos cifrados). -	Off-chain (um provador ou rede executa o programa; apenas uma prova é verificada on-chain). -
Confidencialidade dos dados	Criptografia total: os dados permanecem criptografados o tempo todo on-chain; os validadores nunca veem o texto claro. Apenas os detentores das chaves de descriptografia podem descriptografar as saídas. -	Conhecimento zero: as entradas privadas do provador nunca são reveladas on-chain; a prova não revela segredos além do que está nas saídas públicas. No entanto, quaisquer dados usados na computação que devam afetar o estado on-chain devem ser codificados na saída ou no compromisso. Os segredos permanecem off-chain por padrão. -
Modelo de confiança	Confiança na execução por consenso e na criptografia: se a maioria dos validadores seguir o protocolo, a execução criptografada é determinística e correta. Nenhuma confiança externa é necessária para a correção da computação (todos os nós a recomputam). Deve-se confiar na segurança do esquema FHE (geralmente baseada na dificuldade de problemas de reticulado) para a privacidade. Em alguns designs, também se confia que não ocorrerá conluio de validadores suficientes para usar indevidamente as chaves de limiar. -	Confiança na segurança do sistema de prova (solidez do SNARK/STARK). Se a prova for verificada, o resultado é correto com certeza criptográfica. Os provadores off-chain não podem enganar a matemática. Há uma suposição de liveness sobre os provadores para realmente fazerem o trabalho. Se estiver usando uma configuração confiável (por exemplo, SRS de SNARK), deve-se confiar que ela foi gerada honestamente ou usar sistemas transparentes/sem configuração. -
Custo on-chain e escalabilidade	Alto custo por transação: As operações homomórficas são extremamente caras computacionalmente, e cada nó deve realizá-las. Os custos de gas são altos (por exemplo, mais de 100k de gas para uma única adição de 8 bits). Contratos complexos são limitados pelo que cada validador pode computar em um bloco. A taxa de transferência é muito menor do que a de contratos inteligentes normais, a menos que hardware especializado seja empregado. A escalabilidade é melhorada por criptografia mais rápida e aceleração de hardware, mas fundamentalmente cada operação aumenta a carga de trabalho da cadeia. -	Baixo custo de verificação: Verificar uma prova sucinta é eficiente e de tamanho constante, então o gas on-chain é modesto (centenas de milhares de gas para qualquer tamanho de computação). Isso desvincula a complexidade dos limites de recursos on-chain – grandes computações não têm custo extra on-chain. Assim, ele escala em termos de carga on-chain. Off-chain, o tempo de prova pode ser significativo (minutos ou mais para tarefas enormes) e pode exigir máquinas poderosas, mas isso não desacelera diretamente a blockchain. A taxa de transferência geral pode ser alta, desde que as provas possam ser geradas a tempo (potenciais redes de provadores paralelas). -
Latência	Os resultados estão disponíveis imediatamente na mesma transação/bloco, já que a computação ocorre durante a execução. Sem viagens de ida e volta adicionais – operação síncrona. No entanto, um tempo de processamento de bloco mais longo pode aumentar a latência da blockchain se as operações FHE forem lentas. -	Inerentemente assíncrono. Geralmente requer uma transação para solicitar e uma transação posterior (ou callback) para fornecer a prova/resultado. Isso introduz um atraso (possivelmente de segundos a horas, dependendo da complexidade da prova e do hardware de prova). Não é adequado para finalidade instantânea de uma única transação – mais como um modelo de trabalho assíncrono. -
Garantias de privacidade	Forte: Tudo (entradas, saídas, estado intermediário) pode permanecer criptografado on-chain. Você pode ter um estado criptografado de longa duração que várias transações atualizam sem nunca revelá-lo. Apenas ações de descriptografia autorizadas (se houver) revelam saídas, e estas podem ser controladas por chaves/ACLs. No entanto, considerações de canal lateral como uso de gas ou logs de eventos devem ser gerenciadas para que não vazem padrões (designs de fhEVM buscam execução alheia aos dados com gas constante para operações para evitar vazamentos). -	Seletiva: A prova revela o que quer que esteja nas saídas públicas ou seja necessário para verificar (por exemplo, um compromisso com o estado inicial). Os designers podem garantir que apenas o resultado pretendido seja revelado, e todas as outras entradas permaneçam ocultas com conhecimento zero. Mas, ao contrário da FHE, a blockchain normalmente não armazena o estado oculto – a privacidade é alcançada mantendo os dados totalmente off-chain. Se um estado privado persistente for necessário, o contrato pode armazenar um compromisso criptográfico com ele (para que as atualizações de estado ainda revelem um novo compromisso a cada vez). A privacidade é limitada pelo que você escolhe provar; você tem flexibilidade para provar, por exemplo, que um limiar foi atingido sem revelar valores exatos. -
Aplicação da integridade	Por design, todos os validadores recomputam o próximo estado homomorficamente, então se um ator mal-intencionado fornecer um resultado de texto cifrado errado, outros detectarão uma incompatibilidade – o consenso falha a menos que todos obtenham o mesmo resultado. Assim, a integridade é aplicada por execução redundante (como na blockchain normal, apenas em dados criptografados). Provas ZK adicionais são frequentemente usadas para aplicar regras de negócio (por exemplo, o usuário não pôde violar uma restrição) porque os validadores não podem verificar diretamente as condições de texto claro. -	A integridade é aplicada pelo contrato verificador que verifica a prova ZK. Desde que a prova seja verificada, o resultado é garantido como consistente com alguma execução válida do programa off-chain. Nenhuma suposição de maioria honesta é necessária para a correção – mesmo um único verificador honesto (o próprio código do contrato) é suficiente. O contrato on-chain simplesmente rejeitará qualquer prova falsa ou ausente (semelhante a como rejeitaria uma assinatura inválida). Uma consideração: se o provador abortar ou atrasar, o contrato pode precisar de lógica de fallback (ou os usuários podem precisar tentar novamente mais tarde), mas não aceitará resultados incorretos. -
Experiência do desenvolvedor	Prós: Pode usar em grande parte linguagens de contrato inteligente familiares (Solidity, etc.) com extensões. A confidencialidade é tratada pela plataforma – os desenvolvedores se preocupam principalmente com o que criptografar e quem detém as chaves. A composição de contratos criptografados e normais é possível, mantendo a composabilidade do DeFi (apenas com variáveis criptografadas). Contras: Deve entender as limitações da FHE – por exemplo, sem saltos condicionais diretos em dados secretos sem tratamento especial, profundidade de circuito limitada (embora o bootstrapping em TFHE permita computação de comprimento arbitrário ao custo de tempo). Depurar lógica criptografada pode ser complicado, pois não se pode inspecionar facilmente os valores em tempo de execução sem a chave. Além disso, o gerenciamento de chaves e permissões adiciona complexidade ao design do contrato.	Prós: Potencialmente usar qualquer linguagem de programação para a parte off-chain (especialmente com uma zkVM). Aproveitar código/bibliotecas existentes no programa off-chain (com ressalvas para compatibilidade com ZK). Nenhuma criptografia personalizada necessária pelo desenvolvedor se estiver usando uma ZKVM geral – eles escrevem código normal e obtêm uma prova. Além disso, a computação pesada pode usar bibliotecas (por exemplo, código de aprendizado de máquina) que nunca seriam executadas on-chain. Contras: Os desenvolvedores devem orquestrar a infraestrutura off-chain ou usar um serviço de prova. Lidar com fluxos de trabalho assíncronos e integrá-los com a lógica on-chain requer mais trabalho de design (por exemplo, armazenar um estado pendente, esperar por um callback). Escrever circuitos eficientes ou código zkVM pode exigir o aprendizado de novas restrições (por exemplo, sem ponto flutuante, usar ponto fixo ou primitivas especiais; evitar ramificações pesadas que aumentam o tempo de prova; otimizar para contagem de restrições). Há também o fardo de lidar com falhas de prova, timeouts, etc., que não são preocupações no Solidity regular. O ecossistema de ferramentas está crescendo, mas é um novo paradigma para muitos.

Ambas as abordagens estão sendo ativamente aprimoradas, e até vemos convergência: como observado, ZKPs são usados dentro de FHE-VMs para certas verificações e, inversamente, alguns pesquisadores propõem o uso de FHE para manter as entradas do provador privadas em ZK (para que um provador na nuvem não veja seus dados secretos). É concebível que sistemas futuros as combinem – por exemplo, realizando FHE off-chain e depois provando a correção disso para a cadeia, ou usando FHE on-chain, mas provando com ZK para clientes leves que as operações criptografadas foram feitas corretamente. Cada técnica tem seus pontos fortes: a FHE-VM oferece privacidade contínua e interação em tempo real ao custo de computação pesada, enquanto os coprocessadores ZK oferecem escalabilidade e flexibilidade ao custo de latência e complexidade.

Casos de Uso e Implicações​

O advento da privacidade programável desbloqueia uma riqueza de novas aplicações de blockchain em várias indústrias. Abaixo, exploramos como FHE-VMs e coprocessadores ZK (ou híbridos) podem capacitar vários domínios, permitindo contratos inteligentes que preservam a privacidade e uma economia de dados segura.

DeFi Confidencial e Finanças​

Em finanças descentralizadas, a privacidade pode mitigar o front-running, proteger estratégias de negociação e satisfazer a conformidade sem sacrificar a transparência onde necessário. O DeFi Confidencial poderia permitir que os usuários interagissem com protocolos sem revelar suas posições para o mundo.

• Transações Privadas e Saldos Ocultos: Usando FHE, pode-se implementar transferências de tokens confidenciais (saldos e transações ERC-20 criptografados) ou pools blindados em uma L1 de blockchain. Nenhum observador pode ver quanto de um token você possui ou transferiu, eliminando o risco de ataques direcionados com base em participações. Provas ZK podem garantir que os saldos permaneçam sincronizados e que não ocorra gasto duplo (semelhante ao Zcash, mas em plataformas de contrato inteligente). Um exemplo é um AMM (Criador de Mercado Automatizado) confidencial onde as reservas do pool e as negociações são criptografadas on-chain. Arbitragistas ou front-runners não podem explorar o pool porque não conseguem observar o slippage de preço até que a negociação seja liquidada, reduzindo o MEV. Apenas após algum atraso ou por meio de um mecanismo de controle de acesso, alguns dados podem ser revelados para auditoria.

• Leilões e Negociações Resistentes a MEV: Mineradores e bots exploram a transparência das transações para fazer front-run em negociações. Com criptografia, você poderia ter um mempool criptografado ou leilões em lote onde as ordens são enviadas em texto cifrado. Apenas depois que o leilão é concluído, as negociações são descriptografadas. Este conceito, às vezes chamado de Fluxo de Ordens Justo, pode ser alcançado com descriptografia de limiar (vários validadores descriptografam coletivamente o lote) ou provando os resultados do leilão via ZK sem revelar lances individuais. Por exemplo, um coprocessador ZK poderia pegar um lote de lances selados off-chain, computar o preço de compensação do leilão e produzir apenas esse preço e os vencedores com provas. Isso preserva a justiça e a privacidade dos lances perdedores.

• Empréstimos e Derivativos Confidenciais: Em empréstimos DeFi, os usuários podem não querer revelar o tamanho de seus empréstimos ou garantias (isso pode afetar o sentimento do mercado ou convidar à exploração). Uma FHE-VM pode manter um livro de empréstimos criptografado onde os detalhes de cada empréstimo são criptografados. A lógica do contrato inteligente ainda pode aplicar regras como condições de liquidação, operando em fatores de saúde criptografados. Se a proporção de garantia de um empréstimo cair abaixo do limiar, o contrato (com a ajuda de provas ZK) pode sinalizá-lo para liquidação sem nunca expor valores exatos – ele pode apenas produzir um sinalizador sim/não em texto claro. Da mesma forma, posições secretas de derivativos ou opções poderiam ser gerenciadas on-chain, com apenas métricas de risco agregadas reveladas. Isso poderia impedir o copy trading e proteger estratégias proprietárias, incentivando mais participação institucional.

• Privacidade em Conformidade: Nem todos os contextos financeiros desejam anonimato total; às vezes, a divulgação seletiva é necessária para regulamentação. Com essas ferramentas, podemos alcançar a privacidade regulamentada: por exemplo, as negociações são privadas para o público, mas uma bolsa regulamentada pode descriptografar ou receber provas sobre certas propriedades. Poder-se-ia provar via ZK que “esta negociação não envolveu um endereço na lista negra e ambas as partes são verificadas por KYC” sem revelar identidades para a cadeia. Esse equilíbrio poderia satisfazer as regras de Combate à Lavagem de Dinheiro (AML), mantendo as identidades e posições dos usuários confidenciais para todos os outros. A FHE poderia permitir que um contrato de oficial de conformidade on-chain examinasse transações criptografadas em busca de sinais de risco (com uma chave de descriptografia acessível apenas sob ordem judicial, por exemplo).

Identidade Digital e Dados Pessoais​

Os sistemas de identidade têm muito a ganhar com a tecnologia de privacidade on-chain. Atualmente, colocar credenciais ou atributos pessoais em um livro-razão público é impraticável devido às leis de privacidade e à relutância do usuário. Com FHE e ZK, a identidade auto-soberana pode ser realizada de forma a preservar a privacidade:

• Credenciais de Conhecimento Zero: Usando provas ZK (já comuns em alguns projetos de identidade), um usuário pode provar declarações como “Tenho mais de 18 anos”, “Tenho uma carteira de motorista válida” ou “Ganho acima de $50k (para pontuação de crédito)” sem revelar nenhuma outra informação pessoal. Os coprocessadores ZK podem aprimorar isso lidando com verificações mais complexas off-chain, por exemplo, provando que a pontuação de crédito de um usuário está acima de um limiar, consultando um banco de dados de crédito privado de maneira semelhante à Axiom, produzindo apenas um sim/não para a blockchain.

• KYC Confidencial em DeFi: Imagine um protocolo DeFi que, por lei, deve garantir que os usuários sejam verificados por KYC. Com a FHE-VM, as credenciais de um usuário podem ser armazenadas criptografadas on-chain (ou referenciadas via DID), e um contrato inteligente pode realizar uma computação FHE para verificar se as informações de KYC atendem aos requisitos. Por exemplo, um contrato poderia verificar homomorficamente se nome e CPF em um perfil de usuário criptografado correspondem a uma lista de usuários sancionados (também criptografada), ou se o país do usuário não é restrito. O contrato obteria apenas um "aprovado/reprovado" criptografado que pode ser descriptografado por limiar pelos validadores da rede para um sinalizador booleano. Apenas o fato de o usuário ser permitido ou não é revelado, preservando a confidencialidade das PII e alinhando-se com os princípios do GDPR. Essa divulgação seletiva garante conformidade e privacidade.

• Acesso Baseado em Atributos e Divulgação Seletiva: Os usuários poderiam manter um conjunto de credenciais verificáveis (idade, cidadania, habilidades, etc.) como atributos criptografados. Eles podem autorizar certos dApps a executar computações sobre eles sem divulgar tudo. Por exemplo, um DApp de recrutamento descentralizado poderia filtrar candidatos realizando pesquisas em currículos criptografados (usando FHE) – por exemplo, contar anos de experiência, verificar uma certificação – e somente se uma correspondência for encontrada, contatar o candidato off-chain. Os detalhes privados do candidato permanecem criptografados, a menos que ele escolha revelar. As provas ZK também podem permitir que os usuários provem seletivamente que possuem uma combinação de atributos (por exemplo, mais de 21 anos e dentro de um determinado CEP) sem revelar os valores reais.

• Verificação de Identidade Multi-Partes: Às vezes, a identidade de um usuário precisa ser verificada por várias partes (digamos, verificação de antecedentes pela empresa A, verificação de crédito pela empresa B). Com ferramentas homomórficas e ZK, cada verificador poderia contribuir com uma pontuação ou aprovação criptografada, e um contrato inteligente pode agregá-las a uma decisão final sem expor as contribuições individuais. Por exemplo, três agências fornecem bits "aprovado/reprovado" criptografados, e o contrato produz uma aprovação se todos os três forem aprovados – o usuário ou a parte interessada só vê o resultado final, não qual agência específica pode tê-lo reprovado, preservando a privacidade do registro do usuário em cada agência. Isso pode reduzir o viés e o estigma associados, por exemplo, a uma verificação falha revelando um problema específico.

Saúde e Compartilhamento de Dados Sensíveis​

Os dados de saúde são altamente sensíveis e regulamentados, mas a combinação de dados de várias fontes pode desbloquear um valor imenso (para pesquisa, seguros, medicina personalizada). A blockchain poderia fornecer uma camada de confiança para a troca de dados se a privacidade for resolvida. Contratos inteligentes confidenciais poderiam permitir novos ecossistemas de dados de saúde:

• Troca Segura de Dados Médicos: Os pacientes poderiam armazenar referências a seus registros médicos on-chain de forma criptografada. Um contrato habilitado para FHE poderia permitir que uma instituição de pesquisa executasse análises em um coorte de dados de pacientes sem descriptografá-los. Por exemplo, um contrato poderia calcular a eficácia média de um medicamento em resultados de pacientes criptografados. Apenas resultados estatísticos agregados saem descriptografados (e talvez apenas se um número mínimo de pacientes for incluído, para evitar a reidentificação). Os pacientes poderiam receber micropagamentos por contribuir com seus dados criptografados para pesquisa, sabendo que sua privacidade é preservada porque até mesmo a blockchain e os pesquisadores só veem texto cifrado ou provas agregadas. Isso fomenta um mercado de dados para a saúde que respeita a privacidade.

• Processamento de Sinistros de Seguro Preservando a Privacidade: O processamento de sinistros de seguro de saúde poderia ser automatizado por meio de contratos inteligentes que verificam condições em dados médicos sem expor os dados à seguradora. Um sinistro poderia incluir um código de diagnóstico criptografado e um custo de tratamento criptografado; o contrato, usando FHE, verifica as regras da apólice (por exemplo, cobertura, franquia) nesses dados criptografados. Ele poderia produzir uma aprovação e um valor de pagamento sem nunca revelar o diagnóstico real para a blockchain da seguradora (apenas o paciente e o médico tinham a chave). Provas ZK poderiam ser usadas para mostrar que os dados do paciente vieram dos registros de um hospital certificado (usando algo como a Axiom para verificar a assinatura ou a inclusão de registro de um hospital) sem revelar o registro em si. Isso garante a privacidade do paciente enquanto previne fraudes.

• Computação de Dados Genômicos e Pessoais: Dados genômicos são extremamente sensíveis (são literalmente o projeto do DNA de uma pessoa). No entanto, a análise de genomas pode fornecer insights valiosos sobre a saúde. As empresas poderiam usar a FHE-VM para realizar computações em genomas criptografados enviados pelos usuários. Por exemplo, um contrato inteligente poderia executar um modelo de risco gene-ambiente em dados genômicos criptografados e dados ambientais criptografados (de wearables, talvez), produzindo uma pontuação de risco que apenas o usuário pode descriptografar. A lógica (talvez um algoritmo de pontuação de risco poligênico) é codificada no contrato e executada homomorficamente, para que os dados genômicos nunca apareçam em texto claro. Dessa forma, os usuários obtêm insights sem fornecer às empresas dados brutos de DNA – mitigando preocupações tanto de privacidade quanto de propriedade de dados.

• Epidemiologia e Saúde Pública: Durante situações como pandemias, o compartilhamento de dados é vital para modelar a propagação de doenças, mas as leis de privacidade podem dificultar o compartilhamento de dados. Coprocessadores ZK poderiam permitir que autoridades de saúde pública enviassem consultas como “Quantas pessoas na região X testaram positivo nas últimas 24h?” para uma rede de dados de hospitais por meio de provas. Cada hospital mantém os registros de teste dos pacientes off-chain, mas pode provar ao contrato da autoridade a contagem de positivos sem revelar quem. Da mesma forma, o rastreamento de contatos poderia ser feito combinando trilhas de localização criptografadas: os contratos podem computar interseções de históricos de localização criptografados de pacientes para identificar focos, produzindo apenas as localizações dos focos (e talvez uma lista criptografada de IDs afetados que apenas o departamento de saúde pode descriptografar). As trilhas de localização brutas dos indivíduos permanecem privadas.

Mercados de Dados e Colaboração​

A capacidade de computar dados sem revelá-los abre novos modelos de negócios em torno do compartilhamento de dados. Entidades podem colaborar em computações sabendo que seus dados proprietários não serão expostos:

• Mercados de Dados Seguros: Vendedores podem disponibilizar dados de forma criptografada em um mercado de blockchain. Compradores podem pagar para executar análises específicas ou modelos de aprendizado de máquina no conjunto de dados criptografado por meio de um contrato inteligente, obtendo o modelo treinado ou resultados agregados. Os dados brutos do vendedor nunca são revelados ao comprador ou ao público – o comprador pode receber apenas um modelo (que ainda pode vazar algumas informações nos pesos, mas técnicas como privacidade diferencial ou controle da granularidade da saída podem mitigar isso). Provas ZK podem garantir ao comprador que a computação foi feita corretamente sobre o conjunto de dados prometido (por exemplo, o vendedor não pode trapacear executando o modelo em dados falsos porque a prova o vincula ao conjunto de dados criptografado comprometido). Este cenário incentiva o compartilhamento de dados: por exemplo, uma empresa poderia monetizar dados de comportamento do usuário permitindo que algoritmos aprovados sejam executados neles sob criptografia, sem entregar os próprios dados.

• Aprendizado Federado e IA Descentralizada: No aprendizado de máquina descentralizado, várias partes (por exemplo, diferentes empresas ou dispositivos) querem treinar conjuntamente um modelo em seus dados combinados sem compartilhar dados entre si. As FHE-VMs se destacam aqui: elas podem permitir o aprendizado federado, onde as atualizações do modelo de cada parte são agregadas homomorficamente por um contrato. Como as atualizações são criptografadas, nenhum participante aprende as contribuições dos outros. O contrato poderia até mesmo realizar partes do ciclo de treinamento (como passos de descida de gradiente) on-chain sob criptografia, produzindo um modelo atualizado que apenas partes autorizadas podem descriptografar. O ZK pode complementar isso provando que a atualização de cada parte foi computada seguindo o algoritmo de treinamento (impedindo que um participante mal-intencionado envenene o modelo). Isso significa que um modelo global pode ser treinado com total auditabilidade on-chain, mas os dados de treinamento de cada contribuinte permanecem privados. Os casos de uso incluem o treinamento conjunto de modelos de detecção de fraude entre bancos ou a melhoria de assistentes de IA usando dados de muitos usuários sem centralizar os dados brutos.

• Análises Interorganizacionais: Considere duas empresas que desejam encontrar sua interseção de clientes para uma campanha de parceria sem expor suas listas completas de clientes uma à outra. Elas poderiam criptografar suas listas de IDs de clientes e enviar um compromisso. Um contrato habilitado para FHE pode computar a interseção nos conjuntos criptografados (usando técnicas como interseção de conjuntos privados via FHE). O resultado poderia ser uma lista criptografada de IDs de clientes comuns que apenas um terceiro mutuamente confiável (ou os próprios clientes, por algum mecanismo) pode descriptografar. Alternativamente, uma abordagem ZK: uma parte prova à outra em conhecimento zero que “temos N clientes em comum e aqui está uma criptografia desses IDs” com uma prova de que a criptografia de fato corresponde a entradas comuns. Dessa forma, eles podem prosseguir com uma campanha para esses N clientes sem nunca trocar suas listas completas em texto claro. Cenários semelhantes: calcular métricas da cadeia de suprimentos entre concorrentes sem revelar detalhes de fornecedores individuais, ou bancos coletando informações de crédito sem compartilhar dados completos de clientes.

• Computação Segura Multi-Partes (MPC) em Blockchain: FHE e ZK essencialmente trazem conceitos de MPC para on-chain. Lógicas de negócios complexas abrangendo várias organizações podem ser codificadas em um contrato inteligente de forma que as entradas de cada organização sejam compartilhadas secretamente ou criptografadas. O contrato (como um facilitador de MPC) produz saídas como divisões de lucro, cálculos de custo ou avaliações de risco conjuntas em que todos podem confiar. Por exemplo, suponha que várias empresas de energia queiram liquidar um mercado de negociação de energia. Elas poderiam alimentar seus lances e ofertas criptografados em um leilão de contrato inteligente; o contrato calcula os preços de compensação e as alocações em lances criptografados, e produz a alocação e o custo de cada empresa apenas para essa empresa (via criptografia para sua chave pública). Nenhuma empresa vê os lances das outras, protegendo informações competitivas, mas o resultado do leilão é justo e verificável. Essa combinação de transparência de blockchain e privacidade de MPC poderia revolucionar consórcios e consórcios empresariais que atualmente dependem de terceiros confiáveis.

Aprendizado de Máquina Descentralizado (ZKML e FHE-ML)​

Trazer o aprendizado de máquina para blockchains de forma verificável e privada é uma fronteira emergente:

• Inferência de ML Verificável: Usando provas ZK, pode-se provar que “um modelo de aprendizado de máquina f, quando recebe a entrada x, produz a saída y” sem revelar x (se forem dados privados) ou o funcionamento interno de f (se os pesos do modelo forem proprietários). Isso é crucial para serviços de IA em blockchain – por exemplo, um oráculo de IA descentralizado que fornece previsões ou classificações. Um coprocessador ZK pode executar o modelo off-chain (já que os modelos podem ser grandes e caros de avaliar) e postar uma prova do resultado. Por exemplo, um oráculo poderia provar a declaração “A imagem de satélite fornecida mostra pelo menos 50% de cobertura arbórea” para apoiar um contrato de crédito de carbono, sem revelar a imagem de satélite ou possivelmente até mesmo o modelo. Isso é conhecido como ZKML e projetos estão trabalhando na otimização de redes neurais amigáveis a circuitos. Isso garante a integridade das saídas de IA usadas em contratos inteligentes (sem trapaças ou saídas arbitrárias) e pode preservar a confidencialidade dos dados de entrada e dos parâmetros do modelo.

• Treinamento com Privacidade e Auditabilidade: Treinar um modelo de ML é ainda mais intensivo em computação, mas se alcançável, permitiria mercados de modelos baseados em blockchain. Vários provedores de dados poderiam contribuir para o treinamento de um modelo sob FHE para que o algoritmo de treinamento seja executado em dados criptografados. O resultado pode ser um modelo criptografado que apenas o comprador pode descriptografar. Durante o treinamento, provas ZK poderiam ser fornecidas periodicamente para provar que o treinamento estava seguindo o protocolo (impedindo que um treinador mal-intencionado insira um backdoor, por exemplo). Embora o treinamento de ML totalmente on-chain esteja longe, dada os custos, uma abordagem híbrida poderia usar computação off-chain com provas ZK para partes críticas. Poder-se-ia imaginar uma competição descentralizada do tipo Kaggle, onde os participantes treinam modelos em conjuntos de dados privados e enviam provas ZK da precisão do modelo em dados de teste criptografados para determinar um vencedor – tudo sem revelar os conjuntos de dados ou os dados de teste.

• IA Personalizada e Propriedade de Dados: Com essas tecnologias, os usuários poderiam manter a propriedade de seus dados pessoais e ainda se beneficiar da IA. Por exemplo, o dispositivo móvel de um usuário poderia usar FHE para criptografar seus dados de uso e enviá-los para um contrato de análise que computa um modelo de IA personalizado (como um modelo de recomendação) apenas para ele. O modelo é criptografado e apenas o dispositivo do usuário pode descriptografá-lo e usá-lo localmente. A plataforma (talvez uma rede social) nunca vê os dados brutos ou o modelo, mas o usuário obtém o benefício da IA. Se a plataforma quiser insights agregados, ela poderia solicitar provas ZK de certos padrões agregados do contrato sem acessar dados individuais.

Áreas Adicionais​

• Jogos: Jogos on-chain muitas vezes lutam para esconder informações secretas (por exemplo, mãos de cartas ocultas, névoa de guerra em jogos de estratégia). A FHE pode permitir jogos de estado oculto onde a lógica do jogo é executada em estado criptografado. Por exemplo, um contrato de jogo de pôquer poderia embaralhar e distribuir cartas criptografadas; os jogadores recebem as descriptografias de suas próprias cartas, mas o contrato e os outros só veem texto cifrado. A lógica de apostas pode usar provas ZK para garantir que um jogador não esteja blefando sobre uma ação (ou para revelar a mão vencedora no final de forma verificavelmente justa). Da mesma forma, sementes aleatórias para cunhagem de NFT ou resultados de jogos podem ser geradas e provadas justas sem expor a semente (impedindo manipulação). Isso pode aprimorar muito os jogos em blockchain, permitindo que suportem a mesma dinâmica dos jogos tradicionais.

• Votação e Governança: DAOs poderiam usar tecnologia de privacidade para votações secretas on-chain, eliminando a compra de votos e a pressão. A FHE-VM poderia contar votos que são lançados de forma criptografada, e apenas os totais finais são descriptografados. Provas ZK podem garantir que cada voto foi válido (veio de um eleitor elegível, que não votou duas vezes) sem revelar quem votou em quê. Isso fornece verificabilidade (todos podem verificar as provas e a contagem) enquanto mantém os votos individuais secretos – crucial para uma governança imparcial.

• Cadeia de Suprimentos Segura e IoT: Em cadeias de suprimentos, os parceiros podem querer compartilhar provas de certas propriedades (origem, métricas de qualidade) sem expor detalhes completos aos concorrentes. Por exemplo, um sensor IoT em uma remessa de alimentos poderia enviar continuamente dados de temperatura criptografados para uma blockchain. Um contrato poderia usar FHE para verificar se a temperatura permaneceu em uma faixa segura durante todo o trânsito. Se um limiar foi excedido, ele pode acionar um alerta ou penalidade, mas não precisa revelar todo o registro de temperatura publicamente – talvez apenas uma prova ou um agregado como “temperatura do 90º percentil”. Isso constrói confiança na automação da cadeia de suprimentos, respeitando a confidencialidade dos dados do processo.

Cada um desses casos de uso aproveita a capacidade central: computar ou verificar dados sem revelar os dados. Essa capacidade pode mudar fundamentalmente como lidamos com informações sensíveis em sistemas descentralizados. Ela reduz o trade-off entre transparência e privacidade que tem limitado a adoção da blockchain em áreas que lidam com dados privados.

Conclusão​

A tecnologia blockchain está entrando em uma nova era de privacidade programável, onde a confidencialidade dos dados e a funcionalidade dos contratos inteligentes andam de mãos dadas. Os paradigmas de FHE-VM e coprocessadores ZK, embora tecnicamente distintos, ambos se esforçam para expandir o escopo das aplicações de blockchain, desvinculando o que podemos computar de o que devemos revelar.

As Máquinas Virtuais de Criptografia Totalmente Homomórfica mantêm as computações on-chain e criptografadas, preservando a descentralização e a composabilidade, mas exigindo avanços em eficiência. Os coprocessadores de Conhecimento Zero transferem o trabalho pesado para off-chain, permitindo computação virtualmente ilimitada sob garantias criptográficas, e já estão provando seu valor na escalabilidade e aprimoramento do Ethereum. A escolha entre eles (e seus híbridos) dependerá do caso de uso: se a interação em tempo real com estado privado for necessária, uma abordagem FHE pode ser mais adequada; se uma computação extremamente complexa ou integração com código existente for necessária, um coprocessador ZK pode ser o caminho a seguir. Em muitos casos, eles são complementares – de fato, vemos provas ZK reforçando a integridade da FHE, e a FHE potencialmente ajudando o ZK ao lidar com dados privados para provadores.

Para os desenvolvedores, essas tecnologias introduzirão novos padrões de design. Pensaremos em termos de variáveis criptografadas e verificação de provas como elementos de primeira classe da arquitetura de dApps. As ferramentas estão evoluindo rapidamente: linguagens de alto nível e SDKs estão abstraindo os detalhes criptográficos (por exemplo, as bibliotecas da Zama tornando os tipos FHE tão fáceis quanto os tipos nativos, ou os modelos da RISC Zero para solicitações de prova). Em alguns anos, escrever um contrato inteligente confidencial poderá parecer quase tão simples quanto escrever um regular, apenas com a privacidade "embutida" por padrão.

As implicações para a economia de dados são profundas. Indivíduos e empresas estarão mais dispostos a colocar dados ou lógica on-chain quando puderem controlar sua visibilidade. Isso pode desbloquear colaborações interorganizacionais, novos produtos financeiros e modelos de IA que antes eram inviáveis devido a preocupações com a privacidade. Os reguladores também podem vir a abraçar essas técnicas, pois permitem verificações de conformidade e auditorias por meios criptográficos (por exemplo, provar que os impostos são pagos corretamente on-chain sem expor todas as transações).

Ainda estamos nos primeiros dias – os protótipos atuais de FHE-VM têm limites de desempenho, e as provas ZK, embora muito mais rápidas do que antes, ainda podem ser um gargalo para tarefas extremamente complexas. Mas a pesquisa e os esforços de engenharia contínuos (incluindo hardware especializado, como evidenciado por empresas como a Optalysys impulsionando a aceleração óptica de FHE) estão rapidamente erodindo essas barreiras. O financiamento que está sendo injetado neste espaço (por exemplo, o status de unicórnio da Zama, o investimento da Paradigm na Axiom) ressalta uma forte crença de que os recursos de privacidade serão tão fundamentais para a Web3 quanto a transparência foi para a Web1/2.

Em conclusão, a privacidade programável via FHE-VMs e coprocessadores ZK anuncia uma nova classe de dApps que são trustless, descentralizadas e confidenciais. De negociações DeFi que não revelam detalhes, a pesquisas de saúde que protegem os dados dos pacientes, a modelos de aprendizado de máquina treinados em todo o mundo sem expor dados brutos – as possibilidades são vastas. À medida que essas tecnologias amadurecem, as plataformas de blockchain não mais forçarão o trade-off entre utilidade e privacidade, permitindo uma adoção mais ampla em indústrias que exigem confidencialidade. O futuro da Web3 é um onde usuários e organizações podem transacionar e computar com confiança dados sensíveis on-chain, sabendo que a blockchain verificará a integridade enquanto mantém seus segredos seguros.

Fontes: As informações neste relatório são extraídas da documentação técnica e de blogs de pesquisa recentes de projetos líderes neste espaço, incluindo a documentação da FHEVM da Cypher e da Zama, análises detalhadas da Trail of Bits sobre os circuitos da Axiom, guias de desenvolvedor e postagens de blog da RISC Zero, bem como artigos da indústria destacando casos de uso de tecnologia de blockchain confidencial. Essas e outras fontes foram citadas ao longo do texto para fornecer leitura adicional e evidências para as arquiteturas e aplicações descritas.

Uma das promessas centrais da tecnologia de blockchain como o Ethereum é um certo grau de anonimato. Os participantes, conhecidos como validadores, deveriam operar sob um véu de pseudônimos criptográficos, protegendo sua identidade no mundo real e, por extensão, sua segurança.

Entretanto, um artigo de pesquisa recente intitulado “Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue”, elaborado por pesquisadores da ETH Zurich e outras instituições, revela uma falha crítica nessa suposição. Eles demonstram um método simples e de baixo custo para ligar o identificador público de um validador diretamente ao endereço IP da máquina onde ele está rodando.

Em resumo, os validadores do Ethereum não são tão anônimos quanto muitos acreditam. As descobertas foram tão relevantes que renderam aos pesquisadores uma recompensa de bug da Ethereum Foundation, reconhecendo a gravidade do vazamento de privacidade.

Como a Vulnerabilidade Funciona: Uma Falha no Gossip​

Para entender a vulnerabilidade, precisamos primeiro de uma visão básica de como os validadores do Ethereum se comunicam. A rede consiste em mais de um milhão de validadores que constantemente “votam” sobre o estado da cadeia. Essas votações são chamadas de attestations e são transmitidas por uma rede ponto‑a‑ponto ($P2P$) para todos os demais nós.

Com tantos validadores, fazer com que todos transmitam cada voto para todos seria insustentável e sobrecarregaria a rede imediatamente. Para resolver isso, os projetistas do Ethereum implementaram uma solução de escalabilidade inteligente: a rede é dividida em 64 canais de comunicação distintos, conhecidos como subnets.

• Por padrão, cada nó (o computador que executa o software do validador) se inscreve em apenas dois desses 64 subnets. Sua principal tarefa é retransmitir diligentemente todas as mensagens que vê nesses dois canais.
• Quando um validador precisa emitir um voto, sua attestation é aleatoriamente atribuída a um dos 64 subnets para ser broadcast.

É aqui que a vulnerabilidade se manifesta. Imagine um nó cuja função é gerenciar o tráfego dos canais 12 e 13. Durante o dia inteiro, ele encaminha fielmente mensagens apenas desses dois canais. De repente, ele lhe envia uma mensagem que pertence ao canal 45.

Isso é uma pista poderosa. Por que um nó trataria de uma mensagem de um canal que não lhe cabe? A conclusão mais lógica é que o próprio nó gerou aquela mensagem. Isso implica que o validador que criou a attestation para o canal 45 está rodando exatamente naquela máquina.

Os pesquisadores exploraram esse princípio exato. Ao configurar seus próprios nós de escuta, monitoraram os subnets dos quais seus pares enviavam attestations. Quando um par enviava uma mensagem de um subnet ao qual não estava oficialmente inscrito, eles podiam inferir, com alta confiança, que o par hospedava o validador de origem.

O método provou ser surpreendentemente eficaz. Usando apenas quatro nós ao longo de três dias, a equipe localizou os endereços IP de mais de 161.000 validadores, representando mais de 15 % de toda a rede Ethereum.

Por Que Isso Importa: Os Riscos da Desanonimização​

Expor o endereço IP de um validador não é algo trivial. Isso abre a porta para ataques direcionados que ameaçam tanto os operadores individuais quanto a saúde da rede Ethereum como um todo.

1. Ataques Direcionados e Roubo de Recompensas O Ethereum anuncia qual validador está programado para propor o próximo bloco alguns minutos antes. Um atacante que conheça o endereço IP desse validador pode lançar um ataque de negação de serviço (DDoS), inundando-o de tráfego e tirando-o do ar. Se o validador perder a janela de quatro segundos para propor o bloco, a oportunidade passa para o próximo validador na fila. Caso o atacante seja esse próximo validador, ele pode então reivindicar as recompensas do bloco e as taxas de transação valiosas (MEV) que deveriam ter ido para a vítima.

2. Ameaças à Liveness e à Safety da Rede Um atacante bem financiado poderia executar esses ataques de “sniping” repetidamente, fazendo a blockchain inteira desacelerar ou parar (um ataque de liveness). Em um cenário mais grave, o atacante poderia usar essa informação para lançar ataques sofisticados de particionamento da rede, potencialmente fazendo com que diferentes partes da rede discordem sobre o histórico da cadeia, comprometendo sua integridade (um ataque de safety).

3. Revelando uma Realidade Centralizada A pesquisa também trouxe à luz algumas verdades desconfortáveis sobre a descentralização da rede:

• Concentração Extrema: A equipe encontrou pares hospedando um número impressionante de validadores, incluindo um endereço IP que executava mais de 19.000. A falha de uma única máquina poderia ter um impacto desproporcional na rede.
• Dependência de Serviços de Nuvem: Aproximadamente 90 % dos validadores localizados rodam em provedores de nuvem como AWS e Hetzner, e não nos computadores de stakers individuais. Isso representa um ponto significativo de centralização.
• Dependências Ocultas: Muitos grandes pools de staking afirmam que seus operadores são independentes. Contudo, a pesquisa encontrou casos em que validadores de pools diferentes e concorrentes estavam rodando na mesma máquina física, criando riscos sistêmicos ocultos.

Mitigações: Como os Validadores podem se Proteger?​

Felizmente, existem formas de se defender contra essa técnica de desanonimização. Os pesquisadores propuseram várias mitigações:

• Criar Mais Ruído: Um validador pode optar por se inscrever em mais de dois subnets — ou até em todos os 64. Isso dificulta muito para um observador distinguir entre mensagens retransmitidas e mensagens geradas internamente.
• Usar Múltiplos Nós: Um operador pode separar as funções de validação em máquinas diferentes, cada uma com IP distinto. Por exemplo, um nó pode lidar com attestations enquanto outro nó privado é usado apenas para propor blocos de alto valor.
• Peering Privado: Validadores podem estabelecer conexões confiáveis e privadas com outros nós para retransmitir suas mensagens, ofuscando sua origem verdadeira dentro de um pequeno grupo de confiança.
• Protocolos de Broadcast Anônimos: Soluções mais avançadas como o Dandelion, que ofusca a origem de uma mensagem ao encaminhá‑la por um “stem” aleatório antes de divulgá‑la amplamente, poderiam ser implementadas.

Conclusão​

Esta pesquisa ilustra de forma contundente o trade‑off inerente entre desempenho e privacidade em sistemas distribuídos. Na busca por escalabilidade, a rede $P2P$ do Ethereum adotou um design que comprometeu o anonimato de seus participantes mais críticos.

Ao trazer essa vulnerabilidade à luz, os pesquisadores forneceram à comunidade Ethereum o conhecimento e as ferramentas necessárias para abordá‑la. Seu trabalho representa um passo crucial rumo à construção de uma rede mais robusta, segura e verdadeiramente descentralizada para o futuro.

A indústria de blockchain enfrenta um ponto de inflexão crítico em 2024. Enquanto o mercado global para tecnologia blockchain está projetado para alcançar US$469,49 bilhões até 2030, a privacidade permanece um desafio fundamental. Os Trusted Execution Environments (TEEs) surgiram como uma solução potencial, com o mercado de TEE esperado para crescer de US$ 1,2 bilhão em 2023 para US$ 3,8 bilhões em 2028. Mas essa abordagem baseada em hardware realmente resolve o paradoxo de privacidade das blockchains, ou introduz novos riscos?

A Base de Hardware: Entendendo a Promessa dos TEEs​

Um Trusted Execution Environment funciona como o cofre de um banco dentro do seu computador — mas com uma diferença crucial. Enquanto um cofre bancário simplesmente armazena ativos, um TEE cria um ambiente de computação isolado onde operações sensíveis podem ser executadas completamente protegidas do restante do sistema, mesmo que esse sistema esteja comprometido.

O mercado é atualmente dominado por três implementações principais:

1. Intel SGX (Software Guard Extensions)

   • Participação de mercado: 45 % das implementações de TEE em servidores
   • Desempenho: até 40 % de overhead para operações criptografadas
   • Recursos de segurança: criptografia de memória, atestação remota
   • Usuários notáveis: Microsoft Azure Confidential Computing, Fortanix

2. ARM TrustZone

   • Participação de mercado: 80 % das implementações de TEE em dispositivos móveis
   • Desempenho: < 5 % de overhead para a maioria das operações
   • Recursos de segurança: boot seguro, proteção biométrica
   • Aplicações chave: pagamentos móveis, DRM, autenticação segura

3. AMD SEV (Secure Encrypted Virtualization)

   • Participação de mercado: 25 % das implementações de TEE em servidores
   • Desempenho: 2‑7 % de overhead para criptografia de VMs
   • Recursos de segurança: criptografia de memória de VM, proteção de tabelas de página aninhadas
   • Usuários notáveis: Google Cloud Confidential Computing, AWS Nitro Enclaves

Impacto no Mundo Real: Os Dados Falam​

Vamos examinar três aplicações chave onde o TEE já está transformando blockchains:

1. Proteção MEV: Estudo de Caso Flashbots​

A implementação de TEE pelos Flashbots demonstrou resultados notáveis:

• Pré‑TEE (2022):

  • Média diária de extração de MEV: US$ 7,1 M
  • Extratores centralizados: 85 % do MEV
  • Perdas de usuários com ataques sandwich: US$ 3,2 M diários

• Pós‑TEE (2023):

  • Média diária de extração de MEV: US$ 4,3 M (‑39 %)
  • Extração democratizada: nenhuma entidade única > 15 % do MEV
  • Perdas de usuários com ataques sandwich: US$ 0,8 M diários (‑75 %)

Segundo Phil Daian, co‑fundador da Flashbots: “O TEE mudou fundamentalmente o cenário de MEV. Estamos vendo um mercado mais democrático e eficiente, com redução significativa de danos aos usuários.”

2. Soluções de Escala: A Revolução Scroll​

A abordagem híbrida da Scroll, combinando TEE com provas de conhecimento zero, alcançou métricas impressionantes:

• Throughput de transações: 3.000 TPS (comparado aos 15 TPS da Ethereum)
• Custo por transação: US$0,05 (vs. US$ 2‑20 na mainnet Ethereum)
• Tempo de validação: 15 s (vs. minutos para soluções puras ZK)
• Garantia de segurança: 99,99 % com verificação dupla (TEE + ZK)

A Dra. Sarah Wang, pesquisadora de blockchain na UC Berkeley, observa: “A implementação da Scroll mostra como o TEE pode complementar soluções criptográficas ao invés de substituí‑las. Os ganhos de desempenho são significativos sem comprometer a segurança.”

3. DeFi Privado: Aplicações Emergentes​

Vários protocolos DeFi estão agora aproveitando o TEE para transações privadas:

• Secret Network (usando Intel SGX):
  • Mais de 500 mil transações privadas processadas
  • US$ 150 M em transferências de tokens privados
  • Redução de 95 % em front‑running

A Realidade Técnica: Desafios e Soluções​

Mitigação de Ataques por Canal Lateral​

Pesquisas recentes revelaram vulnerabilidades e contramedidas:

1. Ataques de Análise de Energia

   • Vulnerabilidade: taxa de sucesso de 85 % na extração de chaves
   • Solução: atualização mais recente do SGX da Intel reduz taxa para < 0,1 %
   • Custo: 2 % de overhead adicional de desempenho

2. Ataques de Timing de Cache

   • Vulnerabilidade: taxa de sucesso de 70 % na extração de dados
   • Solução: tecnologia de particionamento de cache da AMD
   • Impacto: reduz a superfície de ataque em 99 %

Análise de Risco de Centralização​

A dependência de hardware introduz riscos específicos:

• Participação de mercado dos fornecedores de hardware (2023):
  • Intel: 45 %
  • AMD: 25 %
  • ARM: 20 %
  • Outros: 10 %

Para mitigar preocupações de centralização, projetos como a Scroll implementam verificação de TEE multi‑fornecedor:

• Acordo necessário de 2 + fornecedores diferentes de TEE
• Validação cruzada com soluções não‑TEE
• Ferramentas de verificação de código aberto

Análise de Mercado e Projeções Futuras​

A adoção de TEEs em blockchain mostra forte crescimento:

• Custos atuais de implementação:

  • Hardware TEE de nível servidor: US$ 2.000‑5.000
  • Custo de integração: US$ 50.000‑100.000
  • Manutenção: US$ 5.000/mês

• Redução de custos projetada:

  • 2024: ‑15 %
  • 2025: ‑30 %
  • 2026: ‑50 %

Especialistas da indústria preveem três desenvolvimentos chave até 2025:

1. Evolução de Hardware

   • Processadores específicos para TEE
   • Redução de overhead de desempenho (< 1 %)
   • Proteção aprimorada contra canais laterais

2. Consolidação de Mercado

   • Emergência de padrões
   • Compatibilidade cross‑platform
   • Ferramentas de desenvolvimento simplificadas

3. Expansão de Aplicações

   • Plataformas de contratos inteligentes privados
   • Soluções de identidade descentralizada
   • Protocolos de privacidade cross‑chain

O Caminho a Seguir​

Embora o TEE ofereça soluções atraentes, o sucesso depende da abordagem de várias áreas críticas:

1. Desenvolvimento de Padrões

   • Grupos de trabalho da indústria se formando
   • Protocolos abertos para compatibilidade entre fornecedores
   • Estruturas de certificação de segurança

2. Ecossistema de Desenvolvedores

   • Novas ferramentas e SDKs
   • Programas de treinamento e certificação
   • Implementações de referência

3. Inovação de Hardware

   • Arquiteturas de TEE de próxima geração
   • Redução de custos e consumo energético
   • Recursos de segurança avançados

Panorama Competitivo​

O TEE enfrenta concorrência de outras soluções de privacidade:

Solução	Desempenho	Segurança	Descentralização	Custo
TEE	Alto	Médio‑Alto	Médio	Médio
MPC	Médio	Alto	Alto	Alto
FHE	Baixo	Alto	Alto	Muito Alto
Provas ZK	Médio‑Alto	Alto	Alto	Alto

Conclusão​

O TEE representa uma abordagem pragmática para a privacidade em blockchain, oferecendo benefícios imediatos de desempenho enquanto trabalha para mitigar preocupações de centralização. A rápida adoção da tecnologia por projetos de destaque como Flashbots e Scroll, combinada com melhorias mensuráveis em segurança e eficiência, indica que o TEE desempenhará um papel crucial na evolução das blockchains.

Entretanto, o sucesso não é garantido. Os próximos 24 meses serão críticos à medida que a indústria lida com dependências de hardware, esforços de padronização e o desafio constante dos ataques por canal lateral. Para desenvolvedores e empresas de blockchain, a chave está em compreender os pontos fortes e limitações do TEE, implementando‑o como parte de uma estratégia de privacidade abrangente, e não como uma solução milagrosa.