Em outubro, o termo "TEE (Trusted Execution Environment)" começou a aparecer com frequência nos feeds X. Isso me surpreendeu, já que TEE tradicionalmente foi um tópico de nicho, discutido principalmente no meio acadêmico de segurança de sistemas. Como alguém que conduziu pesquisas em um laboratório de segurança de sistemas, fiquei satisfeito ao ver esse desenvolvimento. No entanto, fiquei curioso sobre por que TEE estava ganhando atenção repentinamente no espaço Web3. Também notei a falta de conteúdo acessível que explicasse os conceitos de TEE para o público em geral, o que me motivou a escrever este artigo.

TEE é um conceito complexo que pode ser desafiador de entender completamente sem um conhecimento de ciência da computação. Portanto, este artigo começa com conceitos básicos de TEE, explica por que o Web3 está interessado em utilizar TEE e, em seguida, discute projetos atuais do Web3 implementando TEE e suas limitações.

Em resumo, este artigo abordará os seguintes tópicos:

• Uma introdução aos conceitos de TEE e uma breve visão geral dos TEEs modernos
• Vários casos de implementação de TEE dentro do ecossistema Web3
• Limitações do TEE e perspectivas pessoais sobre essas limitações
• O futuro do TEE no ecossistema Web3

1. O que é TEE?

Eu acredito que a maioria dos leitores pode não ter o conhecimento de fundo necessário para entender completamente o que é exatamente o TEE. Como o TEE é um conceito bastante complexo quando explorado em profundidade, vou tentar explicá-lo da maneira mais simples possível.

Conceitos Básicos

A maioria dos servidores Web2 gerencia o acesso a dados por meio de configurações de autorização. No entanto, como essa abordagem é puramente baseada em software, ela essencialmente se torna ineficaz se privilégios de nível superior forem obtidos. Por exemplo, se um invasor obtiver privilégios no nível do kernel no sistema operacional do servidor, ele poderá acessar todos os dados controlados por permissão no servidor, incluindo chaves de criptografia. Em cenários tão extremos, praticamente não há como evitar o roubo de dados apenas por meio de métodos baseados em software. O TEE, ou Ambiente de Execução Confiável, tenta resolver fundamentalmente esse problema por meio da segurança baseada em hardware. Os TEEs são frequentemente chamados de "computação confidencial", mas este é um conceito mais amplo que inclui mecanismos de computação que garantem a privacidade dos dados do usuário, como ZK, MPC e FHE.

fonte: Jujutsu Kaisen

Para usar uma analogia simples, o TEE age como uma zona criptografada dentro da memória. Todos os dados dentro do TEE são criptografados, tornando impossível o acesso aos dados brutos de fora. Mesmo o kernel do sistema operacional não pode ler ou modificar esses dados em sua forma original. Assim, mesmo que um invasor obtenha privilégios de administrador no servidor, eles não podem descriptografar os dados dentro do TEE. Essa área criptografada é frequentemente chamada de "enclave".

Criar uma enclave e processar dados dentro dela requer conjuntos de instruções específicos, semelhantes aos opcodes. Essas instruções usam chaves de criptografia armazenadas em áreas protegidas por hardware para realizar cálculos em dados dentro da enclave. Como TEE é um módulo de segurança em nível de hardware, sua implementação varia de acordo com o fornecedor do chip da CPU. Por exemplo, a Intel suporta o SGX, a AMD suporta o SEV e a ARM suporta o TrustZone. De uma perspectiva mais ampla, essas implementações compartilham o conceito de "proteger a memória por meio de criptografia em nível de hardware".

1.1. Como os TEEs Protegem os Dados

Vamos primeiro examinar como os TEEs mais comuns — Intel SGX, AMD SEV e ARM TrustZone — operam e, em seguida, introduzir implementações mais recentes de TEE.

1.1.1. OG TEEs

Intel SGX

SGX cria e acessa enclaves no nível do processo. A seguinte imagem fornece uma representação clara de como um programa habilitado para SGX opera.

fonte: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction-between-pse-and-application-enclaves

Durante o desenvolvimento, os desenvolvedores devem distinguir entre código não confiável e código confiável. Variáveis ​​ou funções que requerem proteção pela enclave são designadas como código confiável, enquanto outras operações são categorizadas como código não confiável. Quando o código não confiável precisa inserir dados no código confiável, ou quando o código confiável precisa interagir com o código não confiável, são empregadas chamadas de sistema especiais chamadas ECALL e OCALL.

fonte: https://www.intel.com/content/www/us/en/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

Se os usuários precisarem interagir diretamente com dados dentro do enclave — por exemplo, fornecendo entrada ou recebendo saída — eles podem se comunicar por meio de canais seguros estabelecidos usando protocolos como SSL.

AMD SEV

Ao contrário do SGX, que cria enclaves no nível do processo, o SEV os cria no nível da máquina virtual. A memória alocada para as máquinas virtuais é criptografada e gerenciada com chaves independentes, protegendo os dados do sistema operacional do servidor ou de outras VMs. Embora as máquinas virtuais sejam geralmente consideradas seguras devido ao seu isolamento em sandbox, vulnerabilidades que comprometam esse isolamento não podem ser completamente descartadas. O SEV é projetado para fornecer segurança em tais cenários.

O SEV gera chaves de criptografia por meio de um processador de segurança que é fisicamente separado da CPU durante a criação da VM. Essas chaves são então usadas para criptografar a memória da VM. O diagrama a seguir ilustra a diferença entre SGX e SEV.

fonte: 10.1109/SRDS.2018.00042

A SGX exige que os desenvolvedores dividam explicitamente o código em segmentos confiáveis e não confiáveis. Em contraste, o SEV criptografa toda a memória da máquina virtual, exigindo relativamente menos esforço dos desenvolvedores em termos de implementação.

ARM TrustZone

Ao contrário da Intel e da AMD, que produzem principalmente CPUs para desktops e servidores, a ARM projeta chipsets para sistemas leves, como dispositivos móveis e embarcados. Como resultado, sua implementação Secure Enclave é ligeiramente diferente do SGX ou SEV usado em arquiteturas de nível superior.

TrustZone divide o sistema em um Mundo Seguro e um Mundo Normal no nível de hardware. Desenvolvedores que usam TrustZone devem implementar funções críticas de segurança no Mundo Seguro, enquanto funções gerais são executadas no Mundo Normal. As transições entre esses dois mundos ocorrem por meio de chamadas de sistema especiais conhecidas como Chamadas de Monitor Seguro, semelhantes ao SGX.

Uma distinção fundamental é que o enclave da TrustZone se estende além da CPU ou memória; abrange todo o sistema, incluindo o barramento do sistema, periféricos e controladores de interrupção. A Apple também utiliza uma TEE chamada Secure Enclave em seus produtos, que é muito semelhante à TrustZone em um nível alto.

1.1.2. Advanced TEEs

Como discutiremos mais tarde, muitas TEEs originais, incluindo o Intel SGX, encontraram vulnerabilidades de canal lateral e desafios de desenvolvimento devido a problemas estruturais. Para enfrentar esses problemas, os fornecedores lançaram versões aprimoradas. Com a crescente demanda por computação em nuvem segura, plataformas como AWS / Azure / GCP começaram a oferecer seus próprios serviços de TEE. Recentemente, o conceito de TEE foi estendido também para GPUs. Alguns casos de uso do Web3 estão implementando essas TEEs avançadas, então vou explicá-las brevemente.

Cloud TEEs: AWS Nitro, Azure Confidential Computing, Google Cloud Confidential Computing

Com a crescente demanda por serviços de computação em nuvem, os provedores começaram a desenvolver suas próprias soluções TEE. O Nitro da AWS é um ambiente de computação em enclave que funciona ao lado de instâncias EC2. Ele alcança a separação física do ambiente de computação usando um chip de segurança Nitro dedicado para atestação e gerenciamento de chaves. O hipervisor Nitro protege as áreas de memória do enclave por meio de funções fornecidas pelo chip, protegendo efetivamente contra ataques de usuários e provedores de nuvem.

Azure suporta várias especificações de TEE, incluindo Intel SGX, AMD SEV-SNP e seu próprio isolamento baseado em virtualização. Essa flexibilidade na seleção do ambiente de hardware oferece aos usuários mais opções, mas pode aumentar a superfície de ataque quando o usuário utiliza vários TEEs.

O Google Cloud fornece serviços de computação confidencial que utilizam Ambientes de Execução Confiáveis (TEE), com foco em cargas de trabalho de AI/ML. Embora diferente do AWS Nitro, o Google Cloud, assim como o Azure, oferece isolamento baseado em virtualização usando infraestrutura TEE existente. Os principais diferenciais incluem suporte para aceleradores de CPU, como o Intel AMX, para lidar com tarefas intensivas de AI/ML, e computação confidencial baseada em GPU por meio da NVIDIA, que será detalhada posteriormente.

ARM CCA

ARM CCA, lançado no final de 2021, é adaptado para ambientes de nuvem, ao contrário do TrustZone, que foi projetado para ambientes embutidos ou móveis únicos. O TrustZone gerencia estaticamente regiões de memória segura pré-designadas, enquanto o CCA facilita a criação dinâmica de Reinos (enclaves seguros). Isso permite múltiplos ambientes isolados dentro de uma única configuração física.

CCA pode ser comparada a uma versão ARM do Intel SGX, embora com diferenças notáveis. Enquanto o SGX tem limitações de memória, o CCA oferece alocação flexível de memória. Além disso, o CCA emprega uma abordagem de segurança fundamentalmente diferente, criptografando toda a memória física, não apenas as regiões delimitadas do enclave como o SGX faz.

Intel TDX

A Intel introduziu o TDX, uma tecnologia que criptografa a memória no nível da VM, semelhante ao SEV da AMD. Este lançamento aborda o feedback sobre as limitações do SGX(v1), incluindo o limite de tamanho do enclave de 256MB e a complexidade aumentada de desenvolvimento devido à criação de enclaves no nível do processo. A diferença chave do SEV é que o TDX confia parcialmente no sistema operacional, especificamente no hipervisor, para gerenciamento de recursos da VM. Além disso, existem diferenças nos mecanismos de criptografia para cada VM.

AMD SEV-SNP

SEV-SNP aumenta a segurança do modelo SEV existente. O SEV original dependia de um modelo de confiança que deixava vulnerabilidades, permitindo que os hipervisores modificassem o mapeamento de memória. O SEV-SNP aborda isso adicionando um gerenciador de hardware para rastrear os estados de memória, evitando tais modificações.

Além disso, permite que os usuários realizem atestação remota diretamente, minimizando assim os pontos de confiança. SEV-SNP também introduziu uma Tabela de Mapeamento Reverso para monitorar os estados das páginas de memória e propriedade, fornecendo defesa contra modelos de ataque maliciosos do hipervisor.

GPU TEE: NVIDIA Confidential Computing

O desenvolvimento do TEE tem tradicionalmente se concentrado em CPUs devido à sua dependência de fornecedores de hardware. No entanto, a necessidade de lidar com cálculos complexos, como treinamento seguro de IA e proteção de dados de treinamento, destacou a necessidade de TEE para GPU. Em resposta, a NVIDIA introduziu recursos de Computação Confidencial para a GPU H100 em 2023.

NVIDIA Confidential Computing oferece instâncias de GPU com criptografia e gerenciamento independentes, garantindo segurança de ponta a ponta quando combinado com CPU TEE. Atualmente, isso é alcançado por meio da integração com AMD SEV-SNP ou Intel TDX para construir pipelines de computação confidenciais.

1.2. Como confiamos no TEE?

Ao examinar projetos Web3, você frequentemente verá afirmações de governança comunitária por meio de envios de código no GitHub. Mas como se pode verificar se o programa implantado no servidor realmente corresponde ao código do GitHub?

Blockchain oferece um ambiente onde os contratos inteligentes são sempre públicos e não modificáveis devido ao consenso contínuo. Em contraste, os servidores Web2 típicos permitem que os administradores atualizem programas a qualquer momento. Para verificar a autenticidade, os usuários precisam comparar os valores de hash dos binários construídos a partir de programas de código aberto em plataformas como o GitHub ou verificar a integridade através das assinaturas dos desenvolvedores.

O mesmo princípio se aplica a programas dentro de enclaves TEE. Para que os usuários confiem plenamente em programas implantados em servidores, eles devem verificar (atestar) que o código e os dados dentro do enclave permanecem inalterados. No caso do SGX, ele se comunica com o IAS (Intel Attestation Service) usando uma chave armazenada em um enclave especial. O IAS verifica a integridade do enclave e seus dados internos e, em seguida, retorna os resultados aos usuários. Em resumo, o TEE requer comunicação com servidores de atestação fornecidos pelo fabricante de hardware para garantir a integridade do enclave.

2. TEE no Web3

Por que usar TEE no Web3?

A ETE pode parecer desconhecida do público em geral, uma vez que seu conhecimento é tipicamente restrito a domínios especializados. No entanto, o surgimento da TEE se alinha bem com os princípios da Web3. A premissa fundamental do uso da ETE é "não confiar em ninguém". Quando implementado corretamente, o TEE pode proteger os dados do usuário do implementador do programa, do proprietário do servidor físico e até mesmo do kernel do sistema operacional.

Embora os projetos atuais de blockchain tenham alcançado uma descentralização estrutural significativa, muitos ainda dependem de ambientes de servidor off-chain, como sequenciadores, relayers off-chain e bots de keeper. Protocolos que precisam processar informações sensíveis do usuário, como dados KYC ou biométricos, ou aqueles que visam suportar transações privadas, enfrentam o desafio de exigir confiança nos provedores de serviços. Esses problemas podem ser substancialmente mitigados por meio do processamento de dados dentro de enclaves.

Como resultado, TEE ganhou popularidade na segunda metade deste ano, alinhando-se a temas relacionados à IA, como privacidade de dados e agentes de IA confiáveis. No entanto, tentativas de integrar TEE no ecossistema Web3 existiam muito antes disso. Neste artigo, apresentaremos projetos em diversos campos que aplicaram TEE no ecossistema Web3, além do setor de IA.

2.1. Coprocessador Confidencial

Marlim

Marlin é um protocolo de computação verificável projetado para oferecer um ambiente de computação seguro usando tecnologia TEE ou ZK. Um de seus objetivos principais é desenvolver uma web descentralizada. Marlin gerencia duas sub-redes: Oyster e Kalypso, e Oyster funciona como o protocolo de coprocessamento baseado em TEE.

1) Oyster CVM

O Oyster CVM (Oyster para conveniência) atua como um mercado P2P TEE. Os usuários compram ambientes de computação AWS Nitro Enclave por meio do mercado off-chain da Oyster e implantam suas imagens de programa lá. Abaixo está uma estrutura abstrata do Oyster:

fonte:https://docs.marlin.org/oyster/protocol/cvm/workflow/

Oyster tem uma estrutura muito semelhante a Akash. No Oyster, o papel do blockchain é verificar se cada ambiente de computação TEE está operando corretamente, e isso é feito por meio de observadores chamados Provedores. Os provedores verificam continuamente a disponibilidade dos Enclaves em tempo real e relatam suas descobertas à rede Oyster. Eles apostam $PONDtokens, que estão em risco de serem cortados se se envolverem em atividades maliciosas. Além disso, uma rede descentralizada de entidades, chamadas de 'auditores', existe para supervisionar o corte do Provedor. A cada época, os auditores recebem suas tarefas e enviam solicitações de auditoria para enclaves que são escolhidos aleatoriamente por uma semente gerada dentro de um enclave.

No entanto, a Oyster implementou um contrato chamado NitroProverque verifica os resultados de atestação remota na cadeia, permitindo aos usuários verificar a integridade de sua TEE adquirida na cadeia.

As instâncias implantadas pelo usuário podem ser acessadas tanto através de smart contracts quanto de APIs Web2. Os resultados da computação podem ser integrados aos contratos, apresentando-os como oráculos. Conforme mostrado no painel, essa capacidade é adequada não apenas para smart contracts, mas também para descentralizar os serviços Web2.

Similar ao Akash, Oyster é suscetível a possíveis tomadas de controle por atacantes se houver vulnerabilidades no mercado fora da cadeia. Em tais cenários, embora os dados do enclave possam permanecer seguros, os dados brutos armazenados fora do enclave e os privilégios de operação de serviço podem ser comprometidos. No caso de dados sensíveis, que são armazenados em memória não confiável mas não devem ser expostos, os desenvolvedores devem criptografar esses dados e armazená-los separadamente. A Marlin atualmente fornece um armazenamento externo com uma chave persistente baseada em MPC para lidar com esses casos.

2) Oyster Serverless

Enquanto o Oyster CVM funciona como um mercado P2P de TEE, o Oyster Serverless se assemelha ao AWS Lambda (ou Função como Serviço) com TEE. Utilizando o Oyster Serverless, os usuários podem executar funções sem alugar instâncias, pagando sob demanda.

O fluxo de execução do Oyster Serverless seria o seguinte:

1. Os usuários criam solicitações para o contrato de retransmissão
2. O servidor de gateway off-chain observa as solicitações do usuário via evento
3. servidor gateway retransmite a solicitação do usuário para o Protocolo gateway
4. O Protocolo de Porta cria e atribui trabalho ao Protocolo Sem Servidor, com base no pedido do usuário
5. Servidores executor ouvem trabalhos atribuídos ao protocolo Serverless, executam o trabalho e enviam a resposta
6. Resposta - o resultado do pedido do usuário - é transmitida sequencialmente ao usuário

Com o Oyster Serverless, os usuários podem enviar solicitações de API web2 ou chamadas de contrato inteligente por meio de um contrato inteligente, enquanto a integridade da execução é garantida por meio do TEE. Os usuários também podem assinar o Serverless para execução periódica, o que seria particularmente útil para buscadores de oráculo.

Rede Phala

Phala, anteriormente discutido em nosso artigo AI X Crypto, mudou significativamente seu foco para coprocessadores de IA.

O design básico da Rede Phala inclui Trabalhadores e gatekeepers. Os Trabalhadores funcionam como nós regulares que executam cálculos para clientes. Os gatekeepers, por outro lado, gerenciam chaves que permitem que os Trabalhadores descriptografem e calculem valores de estado criptografados. Os Trabalhadores lidam com valores de estado de contrato criptografados via Intel SGX, o que exige chaves dos gatekeepers para ler ou escrever esses valores.

fonte: https://docs.phala.network/tech-specs/blockchain

Phala expandiu suas ofertas ao dar suporte a SDKs para VMs Confidenciais em ambientes Intel TDX. Recentemente, em colaboração com Flashbot, eles lançaram Dstack. Este produto apresenta uma API de atestação remota para verificar o status operacional de várias imagens de contêiner Docker implantadas em VMs Confidenciais. A atestação remota através do Dstack garante transparência por meio de um Explorador.

Outro desenvolvimento significativo é o seu produto de Inferência AI Confidencial, introduzido em resposta ao recente aumento de projetos de IA. A Phala Network agora suporta o relativamente novo cálculo confidencial da Nvidia, com o objetivo de aprimorar os serviços de inferência de IA usando ZK/FHE. Essa tecnologia anteriormente enfrentava desafios devido a altos custos indiretos, limitando sua praticidade.

origem: https://docs.phala.network/overview/phala-network/confidential-ai-inference

A imagem ilustra a estrutura do sistema de inferência de IA confidencial da Phala Network. Este sistema utiliza Ambientes de Execução Confiável (TEEs) em nível de máquina virtual, como Intel TDX e AMD SEV, para implantar modelos de IA. Ele realiza inferência de IA através de computação confidencial da Nvidia e transmite os resultados de forma segura de volta ao enclave da CPU. Este método pode incorrer em sobrecarga significativa em comparação com modelos regulares, pois envolve duas rodadas de computação de enclave. No entanto, espera-se que ofereça melhorias de desempenho substanciais em relação aos métodos de inferência de IA baseados em TEE existentes que dependem inteiramente do desempenho da CPU. De acordo com o papelPublicado pela Phala Network, o overhead de inferência LLM baseado em Llama3 foi medido em cerca de 6-8%.

Outros

No domínio AI X Crypto, outros exemplos de uso de TEEs como coprocessadores incluem iExec RLC, PIN AI e Super Protocol. iExec RLC e PIN AI focam na proteção de modelos de IA e dados de treinamento por meio de TEEs, respectivamente. O Super Protocol está se preparando para lançar um mercado para negociação de ambientes computacionais TEE, semelhante ao Marlin. No entanto, informações técnicas detalhadas sobre esses projetos ainda não estão disponíveis publicamente. Forneceremos atualizações após o lançamento de seus produtos.

2.2. Contratos Inteligentes Seguros

Oasis (Prev. Rose)

Oasis, anteriormente conhecido como Rose, é um blockchain de Camada 1 projetado para proteger a privacidade do usuário durante as transações, executando seu cliente de execução dentro de um enclave SGX. Embora seja uma cadeia relativamente madura, o Oasis implementou de forma inovadora o suporte a multi-VM em sua camada de execução.

A camada de execução, chamada Paratime, inclui três componentes: Cipher, uma VM confidencial baseada em WASM; Sapphire, uma VM confidencial baseada em EVM; e Emerald, uma VM compatível com EVM padrão. O Oasis protege fundamentalmente contratos inteligentes e seus processos computacionais de modificações arbitrárias por nós, garantindo que o cliente de execução opere dentro de um enclave TEE. Essa estrutura é ilustrada no diagrama acompanhante.

origem: https://docs.oasis.io/general/oasis-network/

Quando os usuários enviam transações, eles criptografam os dados da transação usando uma chave efêmera gerada pelo gerenciador de chaves do nó Oasis dentro do enclave e transmitem para o módulo de computação. O módulo de computação recebe a chave privada para a chave efêmera do gerenciador de chaves, usa-a para descriptografar os dados dentro do enclave, executa o contrato inteligente e modifica os valores do estado do nó. Como os resultados da execução da transação também são entregues aos usuários na forma criptografada, nem o servidor que opera o cliente do nó Oasis nem entidades externas podem observar o conteúdo da transação.

A Oasis destaca sua força em facilitar a criação de DApps que lidam com informações pessoais sensíveis em blockchains públicos, usando seu Confidential Paratime. Essa funcionalidade permite o desenvolvimento de serviços que exigem verificação de identidade, como SocialFi, empréstimos de crédito, serviços de integração CEX e serviços baseados em reputação. Esses aplicativos podem receber e verificar com segurança informações biométricas ou KYC do usuário dentro de um enclave seguro.

Rede Secreta

A Secret Network é uma cadeia de camada 1 dentro do ecossistema Cosmos e se destaca como uma das blockchains baseadas em TEE mais antigas. Ela utiliza áreas seguras Intel SGX para criptografar os valores do estado da cadeia, oferecendo suporte a transações privadas para seus usuários.

Na Secret Network, cada contrato tem uma chave secreta única armazenada no enclave de cada nó. Quando os usuários chamam contratos via transações criptografadas com chaves públicas, os nós descriptografam os dados da transação dentro do TEE para interagir com os valores de estado do contrato. Esses valores de estado modificados são então registrados em blocos, permanecendo criptografados.

O contrato em si pode ser compartilhado com entidades externas em forma de bytecode ou código-fonte. No entanto, a rede garante a privacidade da transação do usuário ao impedir a observação direta dos dados de transação enviados pelo usuário e bloquear a observação externa ou a adulteração dos valores atuais do estado do contrato.

Como todos os valores de estado de contrato inteligente são criptografados, visualizá-los requer descriptografia. A Rede Secreta resolve isso introduzindo chaves de visualização. Essas chaves vinculam senhas de usuário específicas a contratos, permitindo que apenas usuários autorizados observem valores de estado do contrato.

Clique, Protocolo Quex

Ao contrário dos L1s baseados em TEE introduzidos anteriormente, o Protocolo Clique e Quex oferecem uma infraestrutura que permite que DApps gerais deleguem cálculos privados para um ambiente TEE off-chain. Esses resultados podem ser utilizados no nível do contrato inteligente. Eles são especialmente utilizados para mecanismos de distribuição de incentivos verificáveis, livro de pedidos off-chain, oráculos e proteção de dados KYC.

2.3. Sistema de Prova de Validade

Algumas cadeias ZK L2 empregam sistemas multi-prova para lidar com a instabilidade inerente de provas de conhecimento zero, muitas vezes incorporando provas TEE. Os mecanismos modernos de prova de conhecimento zero ainda não amadureceram o suficiente para serem totalmente confiáveis para sua segurança, e bugs relacionados à solidez em circuitos ZK exigem um esforço significativo para corrigir quando incidentes ocorrem. Como precaução, as cadeias que usam provas ZK ou ZK-EVMs estão adotando provas TEE para detectar possíveis bugs executando novamente blocos por meio de VMs locais dentro de enclaves. Atualmente, os L2s que utilizam sistemas multiprova, incluindo TEE, são Taiko, Scroll e Ternoa. Vamos examinar brevemente suas motivações para o uso de sistemas multiprova e suas estruturas.

Taiko

Taiko é atualmente a cadeia rollup mais proeminente (planejada) Baseada. Uma cadeia rollup delega a sequência aos proponentes de bloco Ethereum sem manter um sequenciador centralizado separado. De acordo com o diagrama de Based Rollup da Taiko, os pesquisadores L2 compõem pacotes de transações e os entregam ao L1 em lotes. Os proponentes de bloco L1 então reconstruem estes, juntamente com as transações L1, para gerar blocos L1 e capturar MEV.

fonte: https://docs.taiko.xyz/core-concepts/multi-proofs/

No Taiko, o TEE é utilizado não durante a etapa de composição de blocos, mas na etapa de geração de prova, que explicaremos. Taiko, com sua estrutura descentralizada, não requer verificação de mau funcionamento do sequenciador. No entanto, se houver bugs dentro do código do cliente do nó L2, uma configuração totalmente descentralizada não pode lidar com eles rapidamente. Isso torna necessária a prova de validade de alto nível para garantir a segurança, resultando em um design de desafio mais complexo em comparação com outros rollups.

Os blocos da Taiko passam por três estágios de confirmação: proposto, provado e verificado. Um bloco é considerado proposto quando sua validade é verificada pelo contrato L1 da Taiko (contrato de agrupamento). Ele atinge o estado provado quando verificado por provadores paralelos e o estado verificado quando seu bloco pai foi provado. Para verificar blocos, a Taiko usa três tipos de provas: prova TEE baseada em SGX V2, prova ZK baseada em Succinct/RiscZero e prova de Guardião, que depende de multisig centralizado.

Taiko emprega um modelo de contestação para verificação de blocos, estabelecendo uma hierarquia de segurança entre Provers: TEE, ZK, ZK+TEE e Guardian. Essa configuração permite que os desafiadores recebam recompensas maiores quando identificam provas incorretas geradas por modelos de níveis superiores. As provas necessárias para cada bloco são atribuídas aleatoriamente com as seguintes ponderações: 5% para SGX+ZKP, 20% para ZKP e o restante usando SGX. Isso garante que os provadores ZK possam sempre ganhar recompensas maiores ao enfrentar desafios bem-sucedidos.

Os leitores podem se perguntar como os provadores SGX geram e verificam provas. O papel principal dos provadores SGX é demonstrar que os blocos de Taiko foram gerados por meio de computação padrão. Esses provadores geram provas de mudanças de valor de estado e verificam o ambiente usando resultados da reexecução de blocos por meio de um VM local dentro do ambiente TEE, juntamente com os resultados da atestação do enclave.

Ao contrário da geração de prova ZK, que envolve custos computacionais significativos, a geração de prova baseada em TEE verifica a integridade computacional a um custo muito menor, sob suposições de segurança semelhantes. A verificação dessas provas envolve verificações simples, como garantir que a assinatura ECDSA usada na prova corresponda à assinatura do provador.

Em conclusão, as provas de validação baseadas em TEE podem ser vistas como um método para verificar a integridade da cadeia, gerando provas com níveis de segurança ligeiramente mais baixos, mas a um custo consideravelmente menor em comparação com as provas de ZK.

Rolar

Scroll é uma rollup notável que adota um sistema Multi-proof. Ele colabora com a Automata, uma camada de atestação a ser introduzida posteriormente, para gerar tanto provas ZK quanto provas TEE para todos os blocos. Essa colaboração ativa um sistema de disputa para resolver conflitos entre as duas provas.

fonte:https://scroll.io/blog/scaling-security

A Scroll planeja suportar diversos ambientes de hardware (atualmente apenas SGX), incluindo Intel SGX, AMD SEV e AWS Nitro, para minimizar dependências de hardware. Eles abordam possíveis problemas de segurança em TEE coletando provas de ambientes diversos usando assinaturas de limiar.

Ternoa

Ternoa prioriza a detecção de ações maliciosas por entidades centralizadas L2 em vez de lidar com bugs na própria Execução. Ao contrário de Taiko ou Scroll, que usam TEE Provers para complementar ZK Proofs existentes, Ternoa emprega Observers em ambientes baseados em TEE. Esses Observers detectam ações maliciosas por sequenciadores e validadores L2, focando em áreas que não podem ser avaliadas apenas a partir de dados de transação. Exemplos incluem nós RPC censurando transações com base no endereço IP, sequenciadores alterando algoritmos de sequenciamento ou falhando ao enviar dados de lote intencionalmente.

Ternoa opera uma rede L2 separada chamada Integrity Verification Chain (IVC) para tarefas de verificação relacionadas a entidades de rollup. O provedor de estrutura de rollup envia a imagem sequenciadora mais recente para o IVC. Quando um novo rollup solicita implantação, o IVC retorna imagens de serviço armazenadas em TEE. Após a implantação, os Observadores verificam regularmente se o rollup implantado usa a imagem sequenciadora como pretendido. Eles então enviam provas de integridade, incorporando seus resultados de verificação e relatórios de atestação de seu ambiente TEE, para confirmar a integridade da cadeia.

2.3. Segurança do Ethereum

2.3.1. Descentralização do Construtor de Blocos

Flashbots BuilderNet

Flashbots, amplamente reconhecido como um provedor de soluções MEV, tem consistentemente explorado a aplicação de Ambientes de Execução Confiável (TEE) na tecnologia blockchain. Esforços de pesquisa notáveis incluem:

• Investigando a execução do Geth dentro de um SGX Enclave e suas limitações
• Implementando um construtor de blocos baseado em SGX
• Construindo uma cadeia de coprocessador TEE baseada na execução REVM dentro de um Enclave SGX, complementada por uma camada de verificação Automata

Neste artigo, iremos esboçar brevemente o papel atual da Flashbots e discutir o BuilderNet, uma iniciativa recente voltada para a descentralização da construção de blocos. A Flashbots anunciou planos completos de migração para sua solução existente através do BuilderNet.

O Ethereum emprega um modelo de separação Proposer-Builder. Este sistema divide a criação de blocos em duas funções — 1) Construtores: Responsável pela criação de blocos e extração de MEV 2) Proponentes: Assinar e propagar blocos criados por Construtores para descentralizar os lucros do MEV. Essa estrutura levou a alguns aplicativos descentralizados em conluio com Builders off-chain para capturar lucros substanciais do MEV. Como resultado, alguns construtores, como Beaverbuild e Titan Builder, criam monopolisticamente mais de 90% dos blocos Ethereum. Em casos graves, esses construtores podem censurar transações arbitrárias. Por exemplo, transações regulamentadas, como as da Tornado Cash, são ativamente censuradas por grandes construtoras.

A BuilderNet aborda essas questões ao aprimorar a privacidade das transações e reduzir as barreiras para a participação dos construtores de blocos. Sua estrutura pode ser resumida como segue:

fonte: https://buildernet.org/docs/architecture

Os nós construtores, que recebem transações de usuários (Fluxo de Pedidos), são gerenciados por vários operadores de nós. Cada um opera instâncias de construtores de código aberto dentro de ambientes Intel TDX. Os usuários podem verificar livremente o ambiente TEE de cada operador e enviar transações criptografadas. Os operadores, então, compartilham seu fluxo de pedidos recebido, enviam blocos para o relé MEV-boost e distribuem recompensas de bloco para pesquisadores e outros envolvidos na criação de blocos após a submissão bem-sucedida.

Esta estrutura proporciona vários benefícios de descentralização:

• Verificabilidade: Cada instância do Builder opera dentro de um TEE, permitindo que os usuários verifiquem se os Builders não censuraram transações ou modificaram clientes arbitrariamente. A política de distribuição de recompensas para contribuidores de criação de blocos também é transparente dentro do TEE.
• Resistência à censura: No BuilderNet, os nós construtores são executados por vários operadores, cada um com diferentes políticas regulatórias. Essa diversidade significa que eles escolhem transações diferentes para excluir. Mesmo que alguns operadores censurem as transações, outros ainda podem selecioná-las. Teoricamente, se houver pelo menos um construtor não censurando, as transações do usuário podem ser incluídas nos blocos. BuilderNet também oferece uma solução para problemas de censura L2, mostrando que os L2s podem alcançar maior resistência à censura do que sequenciadores únicos, terceirizando a construção de blocos para o BuilderNet. (Nesse caso, o nível de resistência à censura pode ser afetado por componentes adicionais que filtram as transações antes do sequenciador, como firewall)
• Descentralização: Os atuais construtores de blocos enfrentam o desafio da dependência de infraestrutura centralizada. BuilderNet tem como objetivo resolver isso integrando vários construtores, começando com Beaverbuild. À medida que mais construtores de blocos se juntam ao BuilderNet, a estrutura PBS do Ethereum verá uma maior descentralização. Atualmente, apenas Beaverbuild, Flashbots e Nethermind fazem parte do BuilderNet. Outros construtores precisam de permissão para se juntar, mas há planos para tornar o deployment de operadores sem permissão e eliminar completamente a infraestrutura centralizada no futuro.

2.3.2. Proteção do Validador

Puffer Finance

Puffer Finance introduziu uma ferramenta Secure Signer projetada para reduzir o risco de validadores Ethereum serem reduzidos devido a erros ou bugs do cliente. Esta ferramenta utiliza um signatário com base em Enclave SGX para segurança aprimorada.

origem: https://docs.puffer.fi/technology/secure-signer/

O Secure Signer opera gerando e armazenando chaves de validadores BLS dentro do enclave SGX, acessando-os apenas quando necessário. Sua lógica é direta: junto com a segurança fornecida pelo Ambiente de Execução Confiável (TEE), ele pode detectar erros de validadores ou ações maliciosas. Isso é alcançado garantindo que os slots tenham aumentado estritamente antes de assinar blocos ou provas. A Puffer Finance destaca que essa configuração permite que os validadores atinjam níveis de segurança comparáveis às carteiras de hardware, superando as proteções típicas oferecidas por soluções de software.

2.4. Descentralização do Sequenciador L2

Unichain

Unichain, a cadeia de camada 2 (L2) da Ethereum da Uniswap programada para ser lançada no primeiro trimestre do próximo ano, compartilhou planos em seu whitepaper para descentralizar os mecanismos de construção de blocos L2 usando Ambientes de Execução Confiáveis (TEE). Embora as especificações técnicas detalhadas ainda não tenham sido divulgadas, aqui está um resumo de suas principais propostas:

• Separação de Construtor de Sequenciador: Para aprimorar as estruturas rollup existentes, onde a sequenciação e a geração de blocos L2 são tratadas por sequenciadores centralizados, a Unichain colaborou com a Flashbots. Essa parceria tem como objetivo separar os sequenciadores L2 dos construtores de blocos. Os construtores de blocos da Unichain operarão usando código aberto dentro do Intel TDX, garantindo transparência ao liberar publicamente os resultados de atestação para execução.
• Flashblock: Unichain identifica limitações de escalabilidade no processo atual de pré-confirmação fornecido por sequenciadores rollup, como serialização e geração de raiz de estado. Para enfrentar esses problemas, eles planejam introduzir os "Flashblocks", permitindo que os usuários recebam blocos pendentes imediatamente após a ordenação da transação por meio dos construtores TEE. Eles enfatizam que a sequenciação dentro do TEE garantirá que a ordenação da transação seja baseada exclusivamente em taxas de prioridade e tempo de envio, sem interferência do sequenciador, permitindo uma pré-confirmação mais rápida.

Além disso, a Unichain pretende desenvolver várias funcionalidades baseadas em TEE, incluindo uma mempool criptografada, transações agendadas e contratos inteligentes protegidos por TEE.

2.5. RPC Privado

Automata

Embora a blockchain tenha alcançado considerável descentralização em aspectos arquitetônicos, muitos elementos ainda não possuem resistência à censura suficiente devido à dependência dos operadores do servidor. Automata tem como objetivo fornecer soluções que minimizem a dependência dos operadores do servidor e a exposição de dados na arquitetura de blockchain com base em TEE. As implementações notáveis da Automata incluem open-source SGX Prover e Verificador, Compilação TEEque verifica correspondências entre executáveis implementados em TEE e código-fonte, eConstrutor TEEque adiciona privacidade aos mecanismos de construção de blocos através do mempool e construtor de blocos baseados em TEE. Além disso, Automata permite que o resultado de atestação remota do TEE seja postado na cadeia, o que permite que ele seja publicamente verificável e integrado em contratos inteligentes.

Automata atualmente opera o 1RPC, um serviço RPC baseado em TEE projetado para proteger informações identificadoras de submissões de transações, como detalhes de IP e dispositivo, por meio de enclaves seguros. A Automata destaca o risco de que, com a comercialização do UserOp devido ao desenvolvimento da abstração de conta, os serviços RPC possam inferir padrões de UserOp para usuários específicos por meio da integração de AI, comprometendo potencialmente a privacidade. A estrutura do 1RPC é direta. Ele estabelece conexões seguras com usuários, recebe transações (UserOp) no TEE e as processa com o código implantado dentro do enclave. No entanto, o 1RPC protege apenas os metadados do UserOp. As partes reais envolvidas e o conteúdo da transação permanecem expostos durante a interação com o Entrypoint na cadeia. Uma abordagem mais fundamental para garantir a privacidade da transação envolveria a proteção das camadas do mempool e do construtor de blocos com TEE. Isso poderia ser alcançado por meio da integração com o TEE Builder da Automata.

2.6. Agentes de IA

fonte: https://x.com/tee_hee_he

O que trouxe o TEE meta à proeminência em web3 foi o agente AI do Twitter baseado em TEE. Muitas pessoas provavelmente encontraram o TEE pela primeira vez quando um agente de IA chamado@tee_hee_heapareceu na X no final de outubro e lançou sua memecoin na Ethereum.@tee_hee_heé um agente de IA desenvolvido em conjunto pela Nous Research e pelo projeto Teleport da Flashbots. Surgiu em resposta às preocupações de que as contas de agentes de IA em alta no momento não pudessem provar que estavam realmente transmitindo resultados gerados por modelos de IA. Os desenvolvedores projetaram um modelo que minimiza a intervenção de entidades centralizadas em processos como configuração de conta no Twitter, criação de carteira de criptomoedas e transmissão de resultados de modelos de IA.

origem: @tee_hee_he/setting-your-pet-rock-free-3e7895201f46"">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

Eles implantaram o agente de IA em um ambiente Intel TDX, gerando email, senhas da conta X e tokens OAuth para acesso ao Twitter por meio de simulação do navegador e depois removeram todas as opções de recuperação.

Recentemente, TEE foi usado em um contexto semelhante para a AI-Pool, onde@123skelyconduziu com sucesso a angariação de fundos. Atualmente, após os contratos de meme de IA serem implantados e os endereços tornados públicos, os bots sniper tecnicamente superiores geralmente garantem a maior parte da liquidez e manipulam os preços. A AI-Pool tenta resolver esse problema ao ter a IA conduzir um tipo de pré-venda.

fonte:https://x.com/0xCygaar/status/1871421277832954055

Outro caso interessante é o DeepWorm, um agente de IA com uma rede neural biológica que simula o cérebro de uma minhoca. Semelhante aos outros agentes de IA, o DeepWorm faz upload da imagem do enclave de seu cérebro de minhoca para a Rede Marlin para proteger seu modelo e fornecer verificabilidade à sua operação.

fonte: https://x.com/deepwormxyz/status/1867190794354078135

Desde @tee_hee_hecom a abertura de todo o código necessário para implantação, a implantação de agentes de IA confiáveis e seguros baseados em TEE tornou-se bastante fácil. Recentemente, a Phala Network implantou Eliza da a16z em TEE. Como a a16z destacou em seu relatório de perspectivas de mercado cripto para 2025, espera-se que o mercado de agentes de IA baseados em TEE sirva como infraestrutura essencial no futuro mercado de memecoin de agentes de IA.

2.7. Jogo Social

Azuki Bobu

Azuki, um renomado projeto Ethereum NFT, colaborou com Flashbots em outubro passado para sediar um evento social único.

origem: https://x.com/Azuki/status/1841906534151864557

Isso envolveu delegar permissões de upload da conta do Twitter para Flashbots e Bobu, que então postaram tweets simultaneamente, semelhante a um flash mob. O evento foi um sucesso, como mostrado na imagem abaixo.

origem: https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

Projetado pela Flashbots e Azuki, a estrutura do evento foi a seguinte:

1. Gere chaves privadas e certificados TLS, assim como chaves privadas Ethereum, dentro de Gramin-SGX.
2. Os usuários criaram tokens OAuth com permissões limitadas para postar um único tweet e os enviaram para o TEE do Flashbots via TLS.
3. Um contrato foi criado no Arbitrum para gerenciar certificados de usuários, evitando gastos duplos e implementando saídas de eventos após uploads de tweets de usuários.

Azuki garantiu a confiabilidade do processo do evento publicando a imagem Docker do Enclave no Docker Hub. Eles também enviaram scripts de verificação de log de transparência de certificado e resultados de atestação remota para o ambiente TEE no GitHub. Embora a Flashbots tenha identificado dependências em nós RPC e blockchain como riscos remanescentes, esses poderiam ser mitigados por meio do uso de RPC TEE ou rollups baseados em TEE como Unichain.

Embora o projeto não tenha alcançado um avanço técnico, é digno de nota por conduzir um evento social confiável exclusivamente usando uma pilha TEE.

3. Segurança do TEE

TEE oferece segurança muito maior em comparação com soluções de software típicas, pois oferece segurança em nível de hardware que o software não pode comprometer diretamente. No entanto, o TEE tem sido lento em adotar produtos reais devido a várias limitações, que vamos apresentar.

1) Mecanismo de Attestação Centralizado

Como mencionado anteriormente, os usuários podem utilizar mecanismos de verificação remota para verificar a integridade de enclaves TEE e que os dados dentro dos enclaves não foram adulterados. No entanto, esse processo de verificação depende inevitavelmente dos servidores do fabricante do chipset. O grau de confiança varia ligeiramente por fornecedor - SGX / TDX depende completamente do servidor de atestação da Intel, enquanto o SEV permite que os proprietários de VM realizem atestação diretamente. Esse é um problema inerente à estrutura TEE, e os pesquisadores de TEE estão trabalhando para resolvê-lo por meio do desenvolvimento de um TEE de código aberto, que mencionaremos posteriormente.

2) Ataques de canal lateral

TEE nunca deve expor dados armazenados dentro de enclaves. No entanto, como TEE só pode criptografar dados dentro de enclaves, vulnerabilidades podem surgir de ataques que exploram informações secundárias, não os dados originais. Desde o lançamento público do Intel SGX em 2015, inúmeros ataques críticos de canal lateral foram destacados em conferências de segurança de sistemas de alto nível. Abaixo estão cenários potenciais de ataque em casos de uso de TEE, categorizados pelo impacto deles:

• Vazamento de Fluxo de Controle: Sistemas operacionais ou programas maliciosos podem recuperar dados explorando informações disponíveis. Por exemplo, eles podem aproveitar o fato de que o acesso aos dados da memória cache da CPU é muito mais rápido do que o acesso aos dados da DRAM. Isso permite que eles identifiquem padrões de execução de código de operação e inferir informações importantes do programa, como chaves RSA. Além disso, um ataque pode ocorrer quando um sistema operacional malicioso restringe o acesso à página de memória, fazendo com que falhas de página no código do enclave exponham padrões de acesso à memória. Manipular o Buffer de Destino do Ramo para prever e gerenciar ramos de código também pode revelar o fluxo de execução do código. Além disso, os invasores podem executar repetidamente o código do enclave em ataques de microscópio para inferir informações.
• Vazamento de dados: Vulnerabilidades que vazam dados da Enclave podem levar a ataques críticos, potencialmente minando a Attestation Remota. Notavelmente, chaves secretas dentro de uma Enclave foram vazadas criando aplicativos sombra que emulam o código e os dados da Enclave, executando ataques ROP neles (Dark-ROP). Vulnerabilidades adicionais surgem da execução especulativa de programas em CPUs Intel para otimização de desempenho (Foreshadow). Embora a memória da Enclave seja protegida por criptografia, dados acessados por instruções executadas especulativamente podem permanecer brevemente no cache. Isso pode ser explorado para ler dados da Enclave por meio de ataques de canal lateral de cache.
• Ataques DoS: Para SGX, quando as verificações de integridade de memória detectam adulteração, o sistema é interrompido. Essa vulnerabilidade tem sido explorada para ataques de DoS causando intencionalmente falhas nas verificações de integridade. Os atacantes podem interromper o sistema ao acessar repetidamente linhas específicas de DRAM para induzir falhas de bits em linhas adjacentes, potencialmente danificando a memória do enclave.

Embora TEE não seja um sistema que neutraliza todos os vetores de ataque e pode vazar vários níveis de informações devido às suas características fundamentais, esses ataques requerem pré-requisitos fortes, como código do atacante e da vítima sendo executado no mesmo núcleo da CPU. Isso levou alguns a descrevê-lo como o modelo de segurança "Homem com Glock".

fonte: https://x.com/hdevalence/status/1613247598139428864

No entanto, uma vez que o princípio fundamental do TEE é "não confie em ninguém", acredito que o TEE deva ser capaz de proteger os dados mesmo dentro deste modelo para desempenhar plenamente seu papel como um módulo de segurança.

3) Real-world / Explorações recentes no TEE

Numeros bugs foram descobertos nas implementações de TEE, especialmente em SGX, e a maioria foi corrigida com sucesso. No entanto, a arquitetura de hardware complexa dos sistemas TEE significa que novas vulnerabilidades podem surgir a cada lançamento de hardware. Além da pesquisa acadêmica, houve explorações do mundo real que afetaram projetos Web3, o que justifica uma análise detalhada.

• Secret Network: Como uma das poucas vítimas de explorações genuínas da TEE, este projeto baseado na SGX sucumbiu ao ataque ÆPIC Leakage descoberto em 2022. O ataque teve como alvo o conjunto de instruções AVX (Advanced Vector Extensions) em CPUs Intel recentes. Ele explorou padrões de execução especulativa durante operações AVX para recuperar chaves de criptografia armazenadas em regiões de enclave. A Secret Network usou uma semente de consenso para validadores descriptografarem transações privadas. O invasor extraiu com êxito essa semente, permitindo a descriptografia de todas as transações privadas históricas na rede. Mais detalhes da vulnerabilidade são descritos em sgx.fail.
• SGX Root Key Exposure: Em agosto, o pesquisador de segurança Mark Ermolov anunciou a descriptografia bem-sucedida da Root Provisioning Key e da Root Sealing Key da SGX, componentes essenciais do modelo de confiança criptográfica da SGX. Essas chaves geralmente são protegidas por lógica complexa dentro de um dispositivo físico do Fuse Controller. No entanto, foi encontrada uma vulnerabilidade crítica em que cópias dessas chaves permaneciam em buffers internos durante as operações. Embora possuir essas duas chaves por si só não comprometa totalmente a SGX, a obtenção da Global Wrapping Key poderia potencialmente expor todo o sistema SGX a vulnerabilidades. Apesar do SGX ter sido preterido em CPUs Intel comerciais lançadas após 2021, ele continua sendo um vetor de ataque viável, já que vários projetos ainda o utilizam.
• Vulnerabilidade AMD SEV-SNP: O AMD SEV, uma implementação TEE relativamente nova com um amplo escopo de proteção no nível da máquina virtual, historicamente mostrou menos vulnerabilidades em comparação com a SGX. No entanto, a aceitação de um artigo no IEEE S&P 2025 discutindo "BadRAM", uma vulnerabilidade direcionada ao AMD SEV-SNP, destaca que mesmo as implementações modernas de TEE não estão imunes a falhas de segurança. O BadRAM explora módulos de memória DDR4 e DDR5 para criar aliasing de espaço de endereçamento na memória física. Usando um Raspberry Pi Pico, que custa cerca de US $ 10, os invasores podem modificar chips de memória para enganar a CPU sobre o tamanho da memória física. Isso efetivamente ignora o mecanismo de proteção RMP (Reverse Map Table) da AMD SEV-SNP. Mais detalhes da vulnerabilidade são descritos em badram.eu.

Esses casos indicam que um "TEE completamente seguro" é inatingível, e os usuários devem estar cientes das vulnerabilidades potenciais com novos lançamentos de hardware.

4. Conclusão: Open Source é o Futuro

Em novembro, Georgios Konstantopoulos da Paradigm delineou uma frameworkpara a evolução confidencial do hardware, classificando o hardware seguro em cinco níveis distintos:

• Nível 1: Oferece confidencialidade suficiente para aplicativos de oráculo e ponte, com segurança dependente da cadeia de suprimentos. Exemplos incluem SGX.
• Nível 2: Mantém a segurança do Nível 1 enquanto aprimora a experiência do desenvolvedor e suporta aplicativos avançados como a delegação de conta OAuth, como visto com o Teleport. O Gramine SGX exemplifica esse nível.
• Nível 3: Estende a segurança de nível 1 com suporte a GPU, permitindo aplicativos sofisticados, como aprendizado de máquina privado e verificável. Intel TDX + Nvidia Confidential Computing representa essa camada.
• Nível 4: Utiliza conjuntos de instruções de código aberto com processos de fabricação publicamente verificáveis, removendo dependências de fornecedores de hardware, como demonstrado pelo OpenTEE.
• Nível 5: Alcança um estado ideal onde vários OpenTEEs trabalham juntos através de FHE/MPC, mantendo a integridade mesmo se unidades de hardware individuais forem comprometidas.

Atualmente, projetos como a Inferência de IA Confidencial da Phala Network operam no Nível 3, enquanto a maioria dos serviços permanece no Nível 2 usando TEE em nuvem ou Intel TDX. Embora os projetos baseados em TEE da Web3 devam eventualmente progredir para o hardware do Nível 4, as limitações de desempenho atuais tornam isso impraticável. No entanto, com grandes VCs como Paradigm e equipes de pesquisa como Flashbots e Nethermind trabalhando para democratizar o TEE, e considerando a alinhamento do TEE com os princípios da Web3, é provável que se torne uma infraestrutura essencial para projetos da Web3.

Sobre ChainLight

O Ecosystem Explorer é o relatório da ChainLight que apresenta análises internas sobre projetos em destaque no ecossistema web3, sob uma perspectiva de segurança, escrito por nossos analistas de pesquisa. Com a missão de auxiliar pesquisadores de segurança e desenvolvedores a aprender, crescer e contribuir coletivamente para tornar o Web3 um local mais seguro, lançamos nosso relatório periodicamente, sem custo algum.

Para receber as últimas pesquisas e relatórios realizados por especialistas premiados:

👉 Seguir @ChainLight_io @c4lvin

Fundada em 2016, os especialistas premiados da ChainLight fornecem soluções de segurança personalizadas para fortalecer seu contrato inteligente e ajudá-lo a prosperar na blockchain.

Isenção de responsabilidade:

1. Este artigo é reproduzido de [Chainlight]. Todos os direitos autorais pertencem ao autor original [c4lvin*]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprendaequipe, e eles vão lidar com isso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem um conselho de investimento.
3. A equipe do Gate Learn traduziu o artigo para outros idiomas. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.