Em outubro, o termo "TEE (Trusted Execution Environment)" começou a aparecer com frequência nos feeds X. Isso me surpreendeu, já que o TEE tem sido tradicionalmente um tópico de nicho, discutido principalmente na academia de segurança de sistemas. Como alguém que realizou pesquisas em um laboratório de segurança de sistemas, fiquei satisfeito em ver esse desenvolvimento. No entanto, eu estava curioso sobre por que a TEE estava de repente ganhando atenção no espaço Web3. Também notei uma falta de conteúdo acessível explicando 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 background em 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 os projetos atuais do Web3 que implementam 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 TEE dentro do ecossistema Web3
• Limitações do TEE e perspetivas pessoais sobre essas limitações
• O futuro do TEE no ecossistema Web3

1. O que é TEE?

Acredito que a maioria dos leitores possa não ter o conhecimento de fundo necessário para compreender plenamente o que é exatamente o TEE. Uma vez que o TEE é um conceito bastante complexo quando explorado em profundidade, tentarei explicá-lo da forma mais simples possível.

Conceitos Básicos

A maioria dos servidores Web2 gerencia o acesso aos dados por meio de configurações de autorização. No entanto, como essa abordagem é puramente baseada em software, ela se torna essencialmente ineficaz se privilégios de nível superior forem obtidos. Por exemplo, se um invasor obtiver privilégios de nível de kernel no sistema operacional do servidor, ele poderá potencialmente acessar todos os dados controlados por permissão no servidor, incluindo chaves de criptografia. Em cenários extremos como esses, praticamente não há como impedir o roubo de dados apenas por métodos baseados em software. TEE, ou Ambiente de Execução Confiável, tenta abordar fundamentalmente esse problema por meio de segurança baseada em hardware. TEEs são frequentemente chamados de "computação confidencial", mas esse é 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, 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. Nem mesmo o kernel do sistema operacional pode lê-lo ou modificá-lo 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. Esta área criptografada é frequentemente chamada de "enclave".

A criação de uma área protegida e o processamento de dados dentro dela requerem conjuntos de instruções específicos, semelhantes a opcodes. Essas instruções usam chaves de criptografia armazenadas em áreas protegidas por hardware para realizar cálculos nos dados dentro da área protegida. Como o TEE é um módulo de segurança de nível de hardware, sua implementação varia de acordo com o fornecedor do chip CPU. Por exemplo, a Intel suporta SGX, a AMD suporta SEV e a ARM suporta TrustZone. Do ponto de vista mais amplo, essas implementações compartilham o conceito de "proteger a memória por meio de criptografia de 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 depois introduzir implementações de TEE mais recentes.

1.1.1. OG TEEs

Intel SGX

A SGX cria e acede a enclaves ao nível do processo. A seguinte imagem fornece uma representação clara de como um programa SGX opera.

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

Durante o desenvolvimento, os programadores devem distinguir entre código não confiável e código confiável. Variáveis ou funções que requerem proteção pelo 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 deve interagir com o código não confiável, são utilizadas chamadas especiais do sistema chamadas ECALL e OCALL.

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

Se os utilizadores precisarem de interagir diretamente com os dados dentro da enclave - por exemplo, fornecendo entrada ou recebendo saída - podem comunicar através de canais seguros estabelecidos usando protocolos como SSL.

AMD SEV

Ao contrário do SGX, que cria enclaves ao nível do processo, o SEV cria-os ao nível da máquina virtual. A memória alocada às máquinas virtuais é encriptada e gerida com chaves independentes, protegendo os dados do sistema operativo do servidor ou de outras VMs. Embora as máquinas virtuais sejam geralmente consideradas seguras devido ao seu isolamento em sandbox, não se pode excluir completamente as vulnerabilidades que comprometem este isolamento. O SEV é projetado para fornecer segurança em tais cenários.

SEV gera chaves de criptografia através de um processador de segurança que está fisicamente separado da CPU durante a criação da VM. Estas chaves são então utilizadas para encriptar a memória da VM. O diagrama seguinte ilustra a diferença entre SGX e SEV.

origem: 10.1109/SRDS.2018.00042

A SGX exige que os desenvolvedores dividam explicitamente o código em segmentos não confiáveis ​​e 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 incorporados. Como resultado, a implementação do Secure Enclave deles é 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. Os desenvolvedores que utilizam o TrustZone devem implementar funções críticas de segurança no Mundo Seguro, enquanto as 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 do 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 um TEE chamado Secure Enclave em seus produtos, que é muito semelhante ao TrustZone em um nível mais elevado.

1.1.2. TEEs avançados

Como discutiremos mais tarde, muitos TEEs originais, incluindo o Intel SGX, encontraram vulnerabilidades de canal lateral e desafios de desenvolvimento devido a problemas estruturais. Para resolver esses problemas, os fornecedores lançaram versões melhoradas. 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 agora implementando esses TEEs avançados, então vou explicá-los brevemente.

Cloud TEEs: AWS Nitro, Computação Confidencial Azure, Computação Confidencial do Google Cloud

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 de enclave que funciona ao lado das instâncias EC2. Ele alcança a separação física do ambiente de computação através da utilização de um chip de segurança Nitro dedicado para atestação e gerenciamento de chaves. O hipervisor Nitro protege á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.

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

O Google Cloud fornece serviços de computação confidenciais que utilizam Ambientes de Execução Confiáveis (TEE), com foco em cargas de trabalho de IA/ML. Embora diferente do AWS Nitro, o Google Cloud, assim como o Azure, oferece isolamento baseado em virtualização usando infraestrutura de TEE existente. Os principais diferenciais incluem suporte para aceleradores de CPU, como Intel AMX, para lidar com tarefas intensivas de IA/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 a CCA facilita a criação dinâmica de Realms (enclaves seguros). Isso permite múltiplos ambientes isolados dentro de uma única configuração física.

CCA pode ser comparado à 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 de enclave designadas, como faz o SGX.

Intel TDX

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

AMD SEV-SNP

SEV-SNP melhora 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 resolve esse problema adicionando um gerenciador de hardware para rastrear os estados de memória, impedindo tais modificações.

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

GPU TEE: Computação Confidencial NVIDIA

O desenvolvimento de TEE tem sido tradicionalmente focado em CPUs devido à sua dependência de fornecedores de hardware. No entanto, a necessidade de lidar com computações complexas como treinamento seguro de IA e proteção de dados de treinamento destacou a necessidade de TEE de GPU. Em resposta, a NVIDIA introduziu recursos de Computação Confidencial para a GPU H100 em 2023.

A NVIDIA Confidential Computing oferece instâncias de GPU criptografadas e gerenciadas de forma independente, garantindo segurança de ponta a ponta quando combinada com CPU TEE. Atualmente, isso é alcançado por meio da integração com a AMD SEV-SNP ou Intel TDX para construir pipelines de computação confidencial.

1.2. Como confiamos no TEE?

Ao examinar projetos Web3, frequentemente verá reivindicações de governança comunitária através do carregamento de código no GitHub. Mas como se pode verificar que o programa implantado no servidor corresponde realmente ao código do GitHub?

A 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, servidores típicos da Web2 permitem que os administradores atualizem os 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 GitHub ou verificar a integridade através de assinaturas de desenvolvedores.

O mesmo princípio se aplica a programas dentro de enclaves TEE. Para que os usuários confiem plenamente em programas implantados no servidor, devem verificar (atestado) que o código e os dados dentro do enclave permaneçam 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, TEE requer comunicação com servidores de atestado fornecidos pelo fornecedor de hardware para garantir a integridade do enclave.

2. TEE em Web3

Porque TEE na Web3?

TEE pode parecer desconhecido para o público em geral, pois seu conhecimento geralmente está limitado a domínios especializados. No entanto, o surgimento do TEE está alinhado com os princípios do Web3. A premissa fundamental do uso do TEE é 'não confiar em ninguém'. Quando implementado corretamente, o TEE pode proteger os dados do usuário do implantador 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 KYC ou dados biométricos, ou aqueles que visam suportar transações privadas, enfrentam o desafio de requerer 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 com temas relacionados com IA, como privacidade de dados e agentes de IA confiáveis. No entanto, as tentativas de integrar TEE no ecossistema Web3 existiam muito antes disso. Neste artigo, iremos apresentar projetos em vários campos que aplicaram TEE no ecossistema Web3, para além do setor de IA.

2.1. Coprocessador Confidencial

Marlin

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

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 do Oyster e implantam suas imagens de programa lá. Abaixo está uma estrutura abstrata do Oyster:

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

O Oyster tem uma estrutura muito semelhante à Akash. No Oyster, o papel do blockchain é verificar se cada ambiente de computação TEE está funcionando 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, denominadas 'auditores', existe para supervisionar o corte de provedores. 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 da atestação remota na cadeia, permitindo que os usuários verifiquem a integridade de sua TEE adquirida na cadeia.

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

Similar ao Akash, o Oyster é suscetível a possíveis tomadas de instância por atacantes se houver vulnerabilidades no mercado off-chain. 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 fornece atualmente 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 TEE, o Oyster Serverless se assemelha ao AWS Lambda (ou Function-as-a-Service) 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 do gateway off-chain observa as solicitações do usuário por meio de eventos
3. servidor de gateway retransmite solicitação do usuário para o Protocolo de gateway
4. Protocolo de gateway cria e atribui trabalho ao protocolo Serverless, com base no pedido do utilizador
5. Os servidores Executor ouvem os trabalhos atribuídos ao protocolo Serverless, executam o trabalho e enviam a resposta.
6. Resposta — o resultado do pedido do utilizador — é transmitido sequencialmente ao utilizador

Com o Oyster Serverless, os utilizadores podem enviar pedidos de API web2 ou chamadas de contratos inteligentes através de um contrato inteligente, enquanto a integridade da execução é garantida através do TEE. Os utilizadores também podem subscrever o Serverless para execução periódica, o que seria particularmente útil para os fetchers de oráculos.

Phala Network

Phala, anteriormente discutida no nosso artigo AI X Crypto, mudou significativamente o 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 os clientes. gatekeepers, por outro lado, gerenciam chaves que permitem aos Trabalhadores descriptografar e calcular valores de estado criptografados. Os Trabalhadores lidam com valores de estado de contrato criptografados via Intel SGX, o que torna necessário que os gatekeepers forneçam chaves para ler ou escrever esses valores.

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

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

Outro desenvolvimento significativo é o seu produto de Inferência de IA Confidencial, introduzido em resposta ao recente aumento de projetos de IA. A Phala Network agora suporta a computação confidencial relativamente nova da Nvidia, com o objetivo de aprimorar os serviços de inferência de IA usando ZK/FHE. Esta tecnologia enfrentou desafios devido a custos elevados, 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áveis (TEEs) ao nível da máquina virtual, como o Intel TDX e o AMD SEV, para implantar modelos de IA. Ele realiza inferência de IA através da computação confidencial da Nvidia e transmite os resultados de volta ao enclave da CPU de forma segura. Este método pode incorrer em uma sobrecarga significativa em comparação com modelos regulares, pois envolve duas rodadas de computação no enclave. No entanto, espera-se que ele ofereça melhorias substanciais de desempenho em relação aos métodos de inferência de IA baseados em TEE existentes que dependem exclusivamente do desempenho da CPU. De acordo com o papelpublicado pela Phala Network, o custo de inferência de 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 AI e dados de treinamento através de TEEs, respectivamente. O Super Protocol está se preparando para lançar um mercado para negociação de ambientes de computação TEE, similar 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 conhecida como Rose, é uma blockchain de Camada 1 projetada 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, a Oasis implementou de forma inovadora o suporte multi-VM em sua camada de execução.

A camada de execução, chamada de 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. Oasis protege fundamentalmente contratos inteligentes e seus processos computacionais de modificações arbitrárias pelos nós, garantindo que o cliente de execução opere dentro de uma enclave TEE. Essa estrutura é ilustrada no diagrama acompanhante.

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

Quando os utilizadores enviam transações, encriptam os dados da transação utilizando uma chave efémera gerada pelo gestor de chaves do nó Oasis dentro da enclave e transmitem-na para o módulo de computação. O módulo de computação recebe a chave privada para a chave efémera do gestor de chaves, utiliza-a para desencriptar os dados dentro da enclave, executa o contrato inteligente e modifica os valores de estado do nó. Uma vez que os resultados da execução da transação também são entregues aos utilizadores de forma encriptada, nem o servidor que opera o cliente do nó Oasis nem entidades externas podem observar o conteúdo da transação.

Oasis destaca sua capacidade de 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 é uma das blockchains baseadas em TEE mais antigas. Ela utiliza enclaves 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 possui uma chave secreta única armazenada no enclave de cada nó. Quando os usuários chamam contratos através de 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 próprio contrato pode ser compartilhado com entidades externas na forma de bytecode ou código-fonte. No entanto, a rede garante a privacidade das transações do usuário, impedindo a observação direta dos dados de transação enviados pelo usuário e bloqueando a observação externa ou a manipulação dos valores atuais do estado do contrato.

Uma vez que todos os valores de estado de contrato inteligente estão criptografados, visualizá-los exige descriptografia. A Secret Network resolve isso introduzindo chaves de visualização. Essas chaves vinculam senhas de usuário específicas a contratos, permitindo apenas que usuários autorizados observem os valores do estado do contrato.

Clique, Protocolo Quex

Ao contrário dos L1s baseados em TEE introduzidos anteriormente, o Protocolo Clique e Quex oferecem infraestrutura que permite que DApps gerais deleguem cálculos privados para um ambiente TEE fora da cadeia. Estes resultados podem ser utilizados ao nível do contrato inteligente. São usados especialmente para mecanismos de distribuição de incentivos verificáveis, livros de ordens fora da cadeia, oráculos e proteção de dados de KYC.

2.3. Sistema de Prova de Validade

Algumas cadeias ZK L2 utilizam sistemas de múltiplas provas para lidar com a instabilidade inerente das provas de conhecimento zero, muitas vezes incorporando provas TEE. Mecanismos modernos de prova de conhecimento zero ainda não amadureceram o suficiente para serem totalmente confiáveis em termos de segurança, e bugs relacionados à solidez em circuitos ZK exigem esforço significativo para correção quando ocorrem incidentes. Como precaução, cadeias que utilizam provas ZK ou ZK-EVMs estão adotando provas TEE para detectar bugs potenciais, reexecutando blocos por meio de VMs locais dentro de enclaves. Atualmente, L2s que utilizam sistemas de múltiplas provas, incluindo TEE, são Taiko, Scroll e Ternoa. Vamos examinar brevemente suas motivações para usar sistemas de múltiplas provas e suas estruturas.

Taiko

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

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

No Taiko, o TEE é utilizado não durante a fase de composição de blocos, mas na fase de geração de provas, que vamos explicar. O 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 resolvê-los rapidamente. Isso torna necessária a geração de provas de validade em alto nível para garantir a segurança, resultando em um desafio de design mais complexo em comparação com outros rollups.

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

Taiko utiliza um modelo de contestação para a verificação de blocos, estabelecendo uma hierarquia de segurança entre os Provers: TEE, ZK, ZK+TEE e Guardian. Esta configuração permite que os desafiadores ganhem recompensas maiores quando identificam provas incorretas geradas por modelos de nível superior. As provas necessárias para cada bloco são atribuídas aleatoriamente com os seguintes pesos: 5% para SGX+ZKP, 20% para ZKP e o restante usando SGX. Isso garante que os provadores ZK sempre possam ganhar recompensas mais altas ao desafiar com sucesso.

Os leitores podem se perguntar como os provas de SGX geram e verificam provas. O papel principal dos provadores de SGX é demonstrar que os blocos do 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 de reexecução de blocos por meio de uma VM local dentro do ambiente TEE, juntamente com os resultados de 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 validade 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 inferiores, mas a um custo consideravelmente menor em comparação com as provas de ZK.

Rolar

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

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

A Scroll planeia suportar vários 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 ao recolher provas de ambientes diversos usando assinaturas de limiar.

Ternoa

Ternoa prioriza a detecção de ações maliciosas por entidades centralizadas de 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 as Provas ZK existentes, Ternoa emprega Observers em ambientes baseados em TEE. Esses Observers detectam ações maliciosas por sequenciadores e validadores de L2, concentrando-se em áreas que não podem ser avaliadas apenas pelos dados de transação. Exemplos incluem nós RPC censurando transações com base no endereço IP, sequenciadores alterando algoritmos de sequenciamento ou deixando de enviar intencionalmente dados em lote.

Ternoa opera uma rede L2 separada chamada Integrity Verification Chain (IVC) para tarefas de verificação relacionadas com entidades de rollup. O fornecedor do framework de rollup submete a imagem sequenciadora mais recente para o IVC. Quando um novo rollup solicita implementação, o IVC devolve imagens de serviço armazenadas em TEE. Após a implementação, os Observers verificam regularmente se o rollup implementado usa a imagem sequenciadora conforme pretendido. Em seguida, submetem provas de integridade, incorporando os seus resultados de verificação e relatórios de atestação do 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 reconhecida como fornecedora de soluções MEV, tem consistentemente explorado a aplicação de Ambientes de Execução Confiáveis (TEE) na tecnologia blockchain. Os esforços de pesquisa notáveis incluem:

• Investigando a execução do Geth dentro de um Enclave SGX e suas limitações
• Implementar um construtor de blocos baseado em SGX
• Construindo uma cadeia de coprocessadores 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 destinada a descentralizar a construção de blocos. A Flashbots anunciou planos completos de migração para a sua solução existente através do BuilderNet.

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 de MEV. Esta estrutura levou a algumas aplicações descentralizadas em conluio com Builders off-chain para capturar lucros MEV substanciais. Como resultado, alguns Builders, 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 do Tornado Cash, são ativamente censuradas por grandes construtores.

BuilderNet aborda esses problemas, melhorando a privacidade das transações e reduzindo as barreiras à participação dos construtores de blocos. Sua estrutura pode ser resumida de forma ampla da seguinte forma:

origem: https://buildernet.org/docs/arquitetura

Nós de construção, que recebem transações de usuários (Orderflow), são gerenciados por vários operadores de nó. Cada um opera instâncias de Builder 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 compartilham então seu fluxo de pedidos recebidos, submetem blocos ao relé de impulso MEV e distribuem recompensas de bloco para os buscadores 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 construtor opera dentro de um TEE, permitindo aos usuários verificar que os construtores não censuraram transações ou modificaram clientes arbitrariamente. A política de distribuição de recompensas para os contribuidores da criação de blocos também é transparente dentro do TEE.
• Resistência à Censura: No BuilderNet, os nós construtores são operados por vários operadores, cada um com políticas regulatórias diferentes. Essa diversidade significa que eles escolhem transações diferentes para excluir. Mesmo que alguns operadores censurem transações, outros ainda podem selecioná-las. Teoricamente, se houver pelo menos um construtor não censurador, as transações do usuário podem ser incluídas em blocos. O BuilderNet também oferece uma solução para problemas de censura de L2, mostrando que os L2s podem alcançar maior resistência à censura do que sequenciadores únicos, terceirizando a construção do bloco 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, por exemplo, firewall)
• Descentralização: Os construtores de blocos atuais enfrentam o desafio da dependência da infraestrutura centralizada. O BuilderNet tem como objetivo resolver isso, integrando vários construtores, começando pelo Beaverbuild. À medida que mais construtores de blocos se juntarem ao BuilderNet, a estrutura PBS do Ethereum verá uma descentralização aumentada. Atualmente, apenas Beaverbuild, Flashbots e Nethermind fazem parte do BuilderNet. Outros construtores precisam de permissão para se juntar, mas há planos para tornar a implantação do operador sem permissão e eliminar completamente a infraestrutura centralizada no futuro.

2.3.2. Proteção do Validador

Puffer Finance

A Puffer Finance apresentou uma ferramenta Secure Signer projetada para reduzir o risco de validadores Ethereum serem penalizados devido a erros ou bugs do cliente. Essa ferramenta usa um assinador baseado em SGX Enclave para segurança aprimorada.

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

O Secure Signer opera gerando e armazenando chaves de validador BLS dentro do SGX enclave, acessando-as apenas quando necessário. Sua lógica é direta: juntamente com a segurança fornecida pelo Ambiente de Execução Confiável (TEE), ele pode detectar erros de validador 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 pelas soluções de software.

2.4. Descentralização do Sequenciador L2

Unichain

Unichain, a cadeia de Camada 2 (L2) da Uniswap Ethereum prevista para lançamento 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 propostas-chave:

• Separação do Construtor de Sequenciador: Para aprimorar as estruturas de 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 irão operar usando código aberto dentro do Intel TDX, garantindo transparência ao divulgar publicamente os resultados de atestação para execução.
• Flashblock: A Unichain identifica limitações na escalabilidade com o processo de pré-confirmação atual fornecido pelos sequenciadores de rollup, como a serialização e a geração de raiz de estado. Para abordar essas limitações, eles planejam introduzir os 'Flashblocks', permitindo que os usuários recebam blocos pendentes imediatamente após a ordenação da transação por meio de construtores TEE. Eles enfatizam que a sequência dentro do TEE garantirá que a ordenação da transação seja baseada apenas nas taxas de prioridade e no 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 encriptada, 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. A Automata tem como objetivo fornecer soluções que minimizem a dependência dos operadores do servidor e a exposição de dados na arquitetura da blockchain com base em TEE. As implementações notáveis da Automata incluem o open-sourceSGX Provere Verificador, Compilar TEEque verifica correspondências entre executáveis implantados em TEE e código-fonte, eConstrutor TEE que adiciona privacidade aos mecanismos de construção de blocos através do mempool baseado em TEE e do construtor de blocos. Além disso, o Automata permite que o resultado do atestado remoto da TEE seja postado onchain, o que permite que ele seja publicamente verificável e integrado em contratos inteligentes.

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

2.6. Agentes de IA

origem: https://x.com/tee_hee_he

O que acabou por trazer a TEE meta para destaque no web3 foi o agente de IA do Twitter baseado em TEE. Muitas pessoas provavelmente encontraram pela primeira vez a TEE quando um agente de IA chamado@tee_hee_heapareceu no 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 tendência na época não podiam provar que estavam realmente transmitindo resultados gerados por modelos de IA. Os desenvolvedores projetaram um modelo que minimizou 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 do modelo 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 num ambiente Intel TDX, gerando e-mails, senhas de conta X e tokens OAuth para acesso ao Twitter através de simulação de navegador, e depois removeram todas as opções de recuperação.

Recentemente, a TEE foi utilizada num contexto semelhante para a AI-Pool, onde @123skelyconduziu com sucesso a angariação de fundos. Atualmente, depois que as moedas AI meme implantam seus contratos e os endereços são tornados públicos, bots de sniper tecnicamente superiores normalmente garantem a maior parte da liquidez e manipulam os preços. A AI-Pool tenta resolver esse problema fazendo com que a AI realize 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 bio 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 a sua operação.

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

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

2.7. Jogo Social

Azuki Bobu

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

fonte: 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, bem como chaves privadas Ethereum, dentro do Gramin-SGX.
2. Os utilizadores criaram tokens OAuth com permissões limitadas para publicar um único tweet e submeteram-nos ao TEE da 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.

A Azuki garantiu a confiabilidade do processo do evento ao publicar 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 atestado remoto para o ambiente TEE no GitHub. Embora a Flashbots tenha identificado dependências em nós RPC e blockchain como riscos remanescentes, esses podem ser mitigados por meio do uso de RPC TEE ou rollups baseados em TEE como Unichain.

Embora o projeto não tenha alcançado uma grande inovação técnica, é digno de nota por realizar um evento social confiável usando exclusivamente 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, TEE tem sido lento em ser adotado em produtos reais devido a várias limitações, que vamos apresentar.

1) Mecanismo de Attestação Centralizada

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

2) Ataques de canal lateral

TEE nunca deve expor os dados armazenados dentro das enclaves. No entanto, como TEE só pode criptografar dados dentro das enclaves, podem surgir vulnerabilidades de ataques que exploram informações secundárias, e 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 potenciais cenários de ataque em casos de uso de TEE, categorizados pelo seu impacto:

• 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 a dados do cache da CPU é muito mais rápido do que o acesso a dados do DRAM. Isso lhes permite identificar padrões de execução do 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 na página ocorram no código da enclave, expondo padrões de acesso à memória. Manipular o Buffer de Destino do Ramo para prever e gerenciar os ramos do código também pode revelar o fluxo de execução do código. Além disso, os atacantes podem executar repetidamente o código da enclave em ataques de microscópio para inferir informações.
• Fuga de dados: Vulnerabilidades que expõem dados da Enclave podem levar a ataques críticos, minando potencialmente a Attestation Remota. Notavelmente, chaves secretas dentro de uma Enclave foram expostas pela criação de 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, os dados acessados por instruções executadas de forma especulativa 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 da memória detectam adulteração, o sistema é interrompido. Essa vulnerabilidade tem sido explorada para ataques DoS causando intencionalmente falhas nas verificações de integridade. Os atacantes podem interromper o sistema acessando repetidamente linhas de DRAM específicas para induzir inversões de bits em linhas adjacentes, potencialmente danificando a memória do enclave.

Embora o 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 do “Homem com a Pistola Glock”.

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

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

3) Explorações do mundo real / Recentes em TEE

Vários 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 afetam projetos Web3, o que justifica um exame detalhado.

• Rede Secreta: Como uma das poucas vítimas de ataques genuínos de TEE, este projeto baseado em SGX sucumbiu ao ataque de Vazamento ÆPIC descoberto em 2022. O ataque visou 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 do enclave. A Secret Network usava uma semente de consenso para validadores descriptografarem transações privadas. O atacante conseguiu extrair com sucesso essa semente, possibilitando a descriptografia de todas as transações privadas históricas na rede. Mais detalhes sobre a vulnerabilidade são descritos em sgx.fail.
• Exposição da Chave Raiz SGX: Em agosto, o pesquisador de segurança Mark Ermolov anunciou a bem-sucedida descriptografia da Chave de Provisionamento Raiz e da Chave de Selagem Raiz da SGX, componentes essenciais do modelo de confiança criptográfica da SGX. Essas chaves são geralmente protegidas por lógica complexa dentro de um dispositivo controlador de fusível físico. No entanto, foi encontrada uma vulnerabilidade crítica em que cópias dessas chaves permaneceram em buffers internos durante as operações. Embora possuir apenas essas duas chaves não comprometa completamente a SGX, obter a Chave de Envoltório Global poderia potencialmente expor todo o sistema SGX a vulnerabilidades. Apesar da SGX ser obsoleta em CPUs comerciais da Intel lançadas após 2021, ela ainda é um vetor de ataque viável, pois vários projetos ainda a utilizam.
• Vulnerabilidade AMD SEV-SNP: O AMD SEV, uma implementação de TEE relativamente nova com uma ampla proteção no nível da máquina virtual, mostrou historicamente menos vulnerabilidades em comparação com o SGX. No entanto, a aceitação de um artigo na IEEE S&P 2025 discutindo o “BadRAM”, uma vulnerabilidade direcionada ao AMD SEV-SNP, destaca que até mesmo as implementações modernas de TEE não são imunes a falhas de segurança. O BadRAM explora os módulos de memória DDR4 e DDR5 para criar a aliasização do espaço de endereço na memória física. Usando um Raspberry Pi Pico, que custa cerca de $10, os atacantes podem modificar os 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) do AMD SEV-SNP. Mais detalhes sobre a vulnerabilidade são descritos embadram.eu.

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

4. Conclusão: O código aberto é o futuro

Em novembro, Georgios Konstantopoulos da Paradigm delineou um estrutura Para a evolução confidencial do hardware, categorizando o hardware seguro em cinco níveis distintos:

• Nível 1: Oferece confidencialidade suficiente para aplicações 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 melhora a experiência do desenvolvedor e suporta aplicações avançadas 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 do Nível 1 com suporte para GPU, permitindo aplicações sofisticadas como aprendizado de máquina privado e verificável. O Intel TDX + Nvidia Confidential Computing representa esse nível.
• Nível 4: Utiliza conjuntos de instruções de código aberto com processos de fabrico publicamente verificáveis, eliminando dependências de fornecedores de hardware, como demonstrado pelo OpenTEE.
• Nível 5: Atinge um estado ideal onde vários OpenTEEs trabalham juntos através de FHE/MPC, mantendo a integridade mesmo se as unidades de hardware individuais estiverem comprometidas.

Atualmente, projetos como a Inferência de IA Confidencial da Rede Phala 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 do Web3 devam eventualmente progredir para hardware do Nível 4, as limitações de desempenho atuais tornam isso impraticável. No entanto, com grandes VCs como a Paradigm e equipes de pesquisa como Flashbots e Nethermind trabalhando rumo à democratização do TEE, e considerando a alinhamento do TEE com os princípios do Web3, é provável que se torne uma infraestrutura essencial para projetos do Web3.

Sobre ChainLight

O Explorador do Ecossistema é o relatório da ChainLight que apresenta uma análise interna dos projetos em tendência do ecossistema web3 em uma perspectiva de segurança, escrito pelos nossos analistas de pesquisa. Com a missão de ajudar pesquisadores de segurança e desenvolvedores a aprender, crescer e contribuir coletivamente para tornar o Web3 um lugar mais seguro, lançamos periodicamente nosso relatório, gratuitamente.

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

👉 Seguir @ChainLight_io @c4lvin

Estabelecida 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.

Aviso Legal:

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