Todos os dias, as pessoas geram até 4,02 milhões de TB de dados sensíveis. À medida que os indivíduos se tornam cada vez menos dispostos a compartilhar dados amplamente, a demanda por cálculos privados desses dados cresce diariamente. Essas soluções dependem principalmente da infraestrutura da Amazon Web Services (AWS), que detém cerca de 30% do mercado global de computação em nuvem.
No entanto, a AWS apresenta várias desvantagens, principalmente devido à sua arquitetura centralizada. Mesmo com a introdução de computação segura aprimorada através do AWS Nitro Enclaves, ainda enfrenta desafios significativos na adoção por parte dos desenvolvedores, o que representa um obstáculo profundo para a segurança da blockchain e aplicações Web3.
Este artigo analisará a situação atual da AWS e apresentará uma solução de nuvem TEE descentralizada que não apenas resolve as deficiências da AWS, mas também supera as limitações de outros TEE existentes. No entanto, antes disso, precisamos investigar por que a AWS e seu produto Nitro Enclaves conseguiram obter tanta notoriedade e participação de mercado, bem como quais problemas ainda persistem por trás desses avanços.
AWS Nitro e TEE
AWS é atualmente a plataforma de computação em nuvem mais popular, oferecendo uma gama rica de ferramentas. Em resumo, a AWS é essencialmente uma infraestrutura em nuvem que atende a todas as necessidades computacionais dos desenvolvedores, incluindo serviços de computação, armazenamento e banco de dados. É bem conhecido que a AWS ocupa cerca de 30% do mercado de infraestrutura em nuvem, uma proporção bastante considerável. Entre engenheiros de software ou desenvolvedores, cerca de 48% usam a AWS de alguma forma, portanto a sua demanda é enorme.
Com a expansão da demanda e da base de clientes, incluindo grandes instituições financeiras, agências governamentais e startups que possuem dados altamente sensíveis, surgiram dúvidas sobre a segurança da AWS e se essas entidades podem armazenar e usar esses dados de forma segura através de computação confidencial.
Foi nesse contexto que a AWS surgiu a ideia de implementar TEE na sua plataforma para proteger os dados em uso, como complemento à criptografia de dados em repouso e em trânsito.
Esta nova solução de integração TEE é chamada de AWS Nitro Enclaves, que oferece um ambiente de execução isolado suportado por hardware. O TEE estabelece um ambiente seguro dentro das instâncias Amazon EC2, eliminando o acesso interativo, armazenamento persistente e conexões de rede externas. Este isolamento minimiza a superfície de ataque ao separar cargas de trabalho sensíveis das instâncias EC2 pai, seus operadores e outros softwares.
No entanto, os Nitro Enclaves são totalmente criados e geridos dentro do serviço EC2 da AWS, pertencendo a uma estrutura altamente centralizada. Desde a criação até a terminação, todos os aspectos geridos pelo Enclave são controlados pela infraestrutura da AWS, e dada a natureza da AWS como fornecedor de nuvem centralizado, isso é essencialmente centralizado.
Em resumo, o AWS Nitro Enclaves fornece um forte isolamento por meio de um ambiente de execução confiável baseado em hardware para proteger cargas de trabalho sensíveis. No entanto, sua arquitetura centralizada introduz algumas limitações e compensações.
Limitações fora da centralização AWS
Além das desvantagens da centralização, onde todos os componentes e dados dependem de um único sistema, o AWS Nitro Enclaves traz também mais desafios e novas considerações de segurança. A AWS conecta vários cartões Nitro (hardware personalizado) à CPU para executar cargas úteis TEE, o que gera um risco de segurança duplo: a CPU subjacente e o cartão Nitro podem apresentar vulnerabilidades.
Um problema significativo com os Nitro Enclaves é a falta de um mecanismo de criptografia de memória robusto. Ao contrário das soluções que integram a criptografia de memória diretamente no CPU, a natureza externa do cartão Nitro torna difícil garantir a criptografia de ponta a ponta dos dados na memória. Essa configuração pode expor informações sensíveis à manipulação durante o acesso à memória, uma vez que a criptografia depende da interação entre o CPU e os dispositivos externos.
Além disso, os desenvolvedores ainda precisam usar o Docker para criar e configurar uma imagem de máquina da Amazon (AMI) que contenha o software Enclave, o que pode ser difícil para aqueles que não estão familiarizados com a conteinerização. Eles também precisam usar o AWS CLI e o Nitro Enclaves CLI para iniciar instâncias e gerenciar Enclaves, navegar pela API do Nitro Enclaves e integrar com o serviço de gerenciamento de chaves da AWS, o que às vezes requer conhecimento sobre o processo de prova de criptografia.
A dependência do TEE em relação ao cartão Nitro levou a provas não verificáveis, uma vez que a medição da integridade do código provém do cartão Nitro, e não da própria CPU.
A AWS confia nos desenvolvedores e administradores para configurar políticas de identidade e acesso, o que pode permitir que eles acessem dados sensíveis. Os seus privilégios de acesso elevados geram riscos de ameaças internas, pois podem visualizar ou alterar dados.
Revisão da suposição de confiança do AWS Nitro
No entanto, a maior limitação é que a AWS não foi otimizada para aplicações e ecossistemas descentralizados, faltando suporte nativo para casos de uso Web3 ou sistemas de governança.
Por exemplo, a falta de armazenamento persistente nos AWS Nitro Enclaves. Embora esse isolamento seja benéfico para a segurança, limita casos de uso como agentes de IA que precisam armazenar dados de usuários em bancos de dados vetoriais.
A gestão de chaves também não se adequa ao cenário de "zero confiança". Embora o serviço de gestão de chaves da AWS (KMS) esteja disponível, ele foi projetado especificamente para o Web2, permitindo que administradores acessem chaves privadas. Isso entra em conflito com a exigência do Web3 de que as chaves devem ser completamente controladas por código e não expostas a ninguém (incluindo administradores).
Nitro Enclaves resolveu o problema da desconfiança dos desenvolvedores em relação à nuvem, mas o Web3 exige a implementação de soluções sem necessidade de confiança entre usuários, desenvolvedores e fornecedores. Não suporta upgrades de código seguros, requer propriedade descentralizada semelhante à governança de contratos inteligentes, e os desenvolvedores devem construir do zero, o que pode levar meses, e, se implementado de forma inadequada, o código pode ter vulnerabilidades.
Devido à falta de acesso à rede, a configuração de serviços Web é demorada e trabalhosa, forçando os desenvolvedores a escrever uma grande quantidade de código para adaptar as aplicações e garantir a segurança criptográfica, o que muitas vezes não é perfeito.
Por que o Web3 precisa de TEE?
Usamos o TEE porque não podemos confiar totalmente nos desenvolvedores ou administradores. Os participantes da Web3 têm filosofias diferentes e seguem sistemas sem confiança: se algo tem que ser confiável, não parece muito confiável. É por isso que os usuários confiam nos operadores de hardware para inspecionar e gerenciar aplicativos. Os aplicativos podem ser separados para evitar que interfiram, raspem ou alterem dados confidenciais durante o acesso à memória, já que a criptografia depende da colaboração suave entre a CPU e dispositivos externos. Os utilizadores e fornecedores de dados precisam de ter garantias claras e verificação das ações realizadas sobre os seus dados.
Ao desenvolver a Phala Network, o nosso objetivo era combinar as vantagens da AWS com a segurança do TEE, eliminando a complexidade através da descentralização, enquanto aumentamos a segurança. Esta abordagem visa atender às necessidades dos casos de uso do Web3. O resultado foi a proposta do conceito de nuvem TEE descentralizada, que oferece segurança e integração para aplicações descentralizadas.
Criar nuvem TEE descentralizada
Para entender o conceito de TEE cloud descentralizado, primeiro é necessário definir o que é uma cloud descentralizada. Então, o que é isso?
Uma nuvem descentralizada é um tipo de infraestrutura de computação na qual o armazenamento, processamento e gerenciamento de dados são distribuídos por uma rede de vários nós, em vez de serem centralizados em um único servidor central ou data center. Ao contrário dos sistemas de nuvem centralizados tradicionais, como a AWS, as nuvens descentralizadas não exigem uma única entidade controladora e, em vez disso, dependem do blockchain para funcionar.
Nuvem TEE descentralizada
Uma nuvem TEE descentralizada é uma infraestrutura de computação que combina TEE com uma rede de nós descentralizados para fornecer computação segura, privada e verificável. Cada nó é equipado com um TEE para proteger códigos e dados confidenciais contra acesso ou adulteração por operadores de nós.
A Phala Network é composta por uma rede descentralizada de nós de trabalho, cada um equipado com TEE. Esses nós executam tarefas computacionais para os usuários de acordo com as necessidades dos clientes, como a execução de contratos inteligentes ou o processamento de dados sensíveis.
O processo começa com o usuário a implementar a sua aplicação ou tarefa na rede. As tarefas de computação são executadas dentro da TEE desses nós, garantindo que o código e os dados permaneçam confidenciais, nem mesmo os operadores dos nós conseguem vê-los ou alterá-los.
Phala utiliza provas criptográficas para verificar se os cálculos dentro do TEE foram executados corretamente. Os operadores de nós são recompensados por fornecerem serviços honestos e seguros, mantendo a integridade da rede através de incentivos econômicos. Embora isso pareça simples, a implementação dessa solução é muito mais complexa do que parece.
Por que é tão difícil criar uma nuvem TEE descentralizada?
O TEE em si não é centralizado ou descentralizado; o grau de centralização depende da forma como é implementado e implantado no sistema. O TEE é uma área de isolamento seguro dentro do processador, destinada a proteger códigos e dados sensíveis contra acesso não autorizado pelo sistema operacional ou outros processos no mesmo dispositivo. O TEE opera em um modo centralizado ou descentralizado, dependendo da arquitetura do sistema mais amplo em que está inserido.
Historicamente, criar sistemas centralizados é mais simples do que criar sistemas descentralizados, pois os últimos enfrentam desafios na implementação e comunicação entre nós. Antes do Phala Cloud, já havíamos criado com sucesso a Phala Network 1.0 (SGX) totalmente descentralizada. Agora, estamos desenvolvendo o Phala Cloud com a mesma filosofia, embora isso leve tempo. O Phala é atualmente a única plataforma que combina TEE com total descentralização, diferente de provedores centralizados ou protocolos parcialmente descentralizados.
As vantagens da descentralização e do TEE são evidentes, mas ainda não são suficientes no desenvolvimento de produtos. Imagine que a Alibaba é a maior plataforma de comércio eletrônico do mundo, detendo uma enorme quota de mercado. Se um novo produto for lançado com o dobro da funcionalidade e a um preço mais baixo, ele ocupará todo o mercado? Infelizmente, não, porque as pessoas já estão acostumadas com os produtos existentes, mesmo que o novo produto seja melhor, elas terão preconceitos em relação a ele.
Este é um dos desafios que enfrentamos, mas não buscamos uma melhoria de duas vezes, mas sim garantir que o Phala seja dez vezes melhor e mais amigável do que os concorrentes. Além disso, como mencionado anteriormente, a AWS não é adequada para o ambiente Web3, e pretendemos preencher essa lacuna para aplicações e desenvolvedores Web3. Além da evidente vantagem da descentralização, também queremos destacar outras diferenças entre o Phala e a AWS.
Phala Cloud e AWS
Primeiro, o processo de configuração do AWS para Nitro Enclaves é complexo. Isso envolve várias etapas, incluindo a instalação do Nitro CLI, a conversão da imagem Docker em um arquivo Enclave e o manuseio da transferência de arquivos, tudo isso é muito demorado.
Em comparação, a Phala permite que os desenvolvedores "mudem e modifiquem" a implantação, e facilmente migrem os contêineres Docker existentes para um TEE seguro. Usando o Dstack SDK, os desenvolvedores precisam fazer apenas alterações mínimas para converter contêineres Docker em máquinas virtuais confidenciais (Confidential VM), e implantá-las através de uma interface Cloud amigável ao usuário, ao mesmo tempo em que ainda suportam templates e arquivos Docker Compose personalizados.
Em termos de segurança, a AWS depende da confiança nos desenvolvedores e administradores para configurar corretamente o controle de acesso e gerenciar recursos. Embora a AWS utilize TEE para computação isolada, sua infraestrutura centralizada exige confiança nas pessoas que administram a AWS e os sistemas, o que pode levar ao acesso a dados sensíveis. A Phala adota um modelo de zero confiança, não confiando por padrão em nenhuma das partes. Dados sensíveis são mantidos seguros dentro do TEE, e mesmo os operadores de nós não podem acessá-los, tornando-o adequado para aplicações Web3 que requerem operações sem necessidade de confiança.
Do ponto de vista do produto, a AWS atende principalmente clientes empresariais, uma vez que há um grande número de empresas no campo da TI tradicional. Portanto, não atende totalmente à proposta de valor das startups Web3 em termos de produtos e tecnologia. Em contraste, a Phala é construída especificamente para aplicações descentralizadas. Suporta nativamente agentes de IA que interagem com contratos inteligentes de blockchain e DApps que protegem a privacidade.
Além disso, a Phala está profundamente integrada no ecossistema blockchain através de parcerias com vários protocolos e da integração de DApps que desejam aproveitar a segurança do TEE.
A Phala é posicionada como a camada de execução da Web3 AI, permitindo que os desenvolvedores construam, lancem e lucrem com agentes de IA que podem entender e interagir de forma segura e privada com contratos inteligentes em blockchain. Fazemos isso aproveitando o TEE da NVIDIA GPU para executar grandes modelos de linguagem (LLM) em um ambiente seguro, verificável e focado na privacidade, apoiando plataformas de IA descentralizadas como NEAR AI e Sentient. Por exemplo, nossa parceria com a NOTAI destaca a execução de agentes de IA de confiança zero, onde fornecemos proteção de privacidade e confiança através do TEE e RA Explorer.
Nós também suportamos a integração de aplicações não relacionadas com IA através de Phat Contracts, que são contratos inteligentes de baixo custo e baixa latência com suporte nativo para pedidos HTTP.
No entanto, dado que muitas equipes nativas de criptografia também estão construindo TEEs e outros métodos de computação seguros, como o Phala se diferencia dessas soluções?
Phala Cloud e solução TEE
A Phala Network destaca-se como a única TEE em nuvem totalmente descentralizada, oferecendo computação segura, privada e verificável para DApps. Ao contrário do Oasis Protocol e do Secret Network, que se concentram na utilização de TEE para implementar contratos inteligentes com privacidade em suas respectivas blockchains, a Phala oferece uma plataforma de computação em nuvem descentralizada de computação offline que opera em múltiplas redes.
Phala é flexível e personalizável, aproveitando uma ampla gama de hardware TEE, incluindo Intel SGX, Intel TDX, AMD SEV e NVIDIA GPU TEE. O Marlin Protocol melhora o desempenho da rede Web3, mas não fornece recursos de computação ou privacidade, enquanto o Oasis e o Secret operam em um ecossistema de blockchain específico. A Phala está posicionada de forma única como a única nuvem TEE descentralizada com amplo suporte de hardware e ferramentas centradas no desenvolvedor, como o Dstack.
Phala é diferente porque oferece uma nuvem TEE descentralizada de uso geral, ao contrário do Oasis Protocol, Marlin e Secret Network, que se concentram em casos de uso específicos. O Phala permite que os desenvolvedores implantem qualquer aplicativo, como um modelo de IA, servidor web ou banco de dados, em um ambiente seguro. Isso é possível através de contratos Phat e Phala Cloud, que suporta implantações Dockerized e fornece acesso com um clique para CPU e GPU TEE.
Além disso, há muitas comparações sobre qual é mais adequado para casos de uso específicos, TEE ou computação multipartidária (MPC). Na nossa opinião, TEE e MPC não são concorrentes, mas sim parceiros complementares.
Phala integra TEE com MPC para criar um modelo descentralizado Root of Trust (DeRoT), uma abordagem avançada para proteger aplicativos baseados em TEE. O MPC opera dentro do TEE para reduzir o risco de conluio de nós, enquanto as provas de bloco TEE são enviadas com provas MPC para mitigar erros em implementações de provas de conhecimento zero (ZKP). Este sistema de atestado múltiplo é ainda melhorado pela exigência de que os nós MPC operem dentro do TEE. O modelo DeRoT usa TEE, MPC e ZKP para distribuir confiança na rede. Essa abordagem melhora a segurança dos DApps usando TEEs, abordando possíveis ameaças de hardware ou no nível do nó.
A possibilidade de TEE em nuvem descentralizada
Vamos escrever um artigo dedicado para explorar este tema, uma vez que já existem muitas aplicações a funcionar na Phala. Portanto, esta seção pode ser tão longa quanto o artigo inteiro. Mas esperamos esboçar os possíveis casos de uso da nuvem TEE descentralizada.
Primeiro, a Phala suporta a implantação de modelos de IA dentro de TEE, garantindo a segurança e a operação autônoma na interação com a rede blockchain. Isso inclui agentes de IA para aprimoramento de contratos inteligentes e interações entre agentes. Os desenvolvedores podem utilizar GPU TEE para cálculos de IA, alcançando verdadeira resistência à censura e proteção de privacidade.
Os desenvolvedores também podem migrar aplicativos herdados para um ambiente seguro e sem confiança para melhorar a segurança. A plataforma permite a análise de dados que preserva a privacidade por meio da Web3 e de ferramentas de análise tradicionais que podem analisar dados sem expor informações individuais do usuário. Além disso, ele pode melhorar os cálculos seguros do DeFi com recursos de privacidade, como posições de negociação confidenciais ou negociação em dark pool. Finalmente, as nuvens TEE descentralizadas podem implementar proteção MEV movendo construções de bloco para o TEE para ordenação e execução justas.
Existem muitos produtos que utilizam o Phala como parte da sua infraestrutura. Vamos explorar em um artigo separado como esses produtos usam o Phala e o que eles obtêm dessa integração.
Conclusão
Os modelos de confiança entre Web3 e Web2 apresentam diferenças fundamentais, o que leva a limitações em plataformas como a AWS. No Web3, os dados (incluindo os tokens que essencialmente pertencem aos dados) são realmente possuídos pelos usuários, enquanto os desenvolvedores de aplicações são considerados não confiáveis por padrão. Essa desconfiança decorre da possibilidade de os desenvolvedores tentarem acessar, modificar ou roubar dados dos usuários sem autorização.
Este paradigma explica várias práticas-chave no Web3:
O código do contrato inteligente deve ser rigorosamente auditado para eliminar portas dos fundos ou vulnerabilidades.
A propriedade (ou controle de gestão) dos contratos inteligentes é uma questão-chave, os usuários valorizam mais a transparência do que permitir que os desenvolvedores tenham controle irrestrito.
Idealmente, num ambiente Web3, os desenvolvedores devem escrever e implantar código de contratos inteligentes, e então abdicar de todo o controle, não mantendo mais nenhum privilégio sobre a aplicação.
Ao contrário dos contratos inteligentes, os TEEs podem impor princípios semelhantes de propriedade e controle dentro de uma gama mais ampla de procedimentos. No entanto, o AWS Nitro Enclaves é executado em uma estrutura Web2, onde os desenvolvedores mantêm a capacidade de fazer login, acessar e modificar dados e aplicativos. O TEE da Phala foi projetado com base nos princípios Web3 e suporta nativamente contratos inteligentes para gerenciar aplicativos baseados em TEE, alinhando-se com o modelo de confiança descentralizado.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
AWS não é adequado para Web3: a Descentralização TEE na nuvem pode aumentar a eficiência em 10 vezes.
Todos os dias, as pessoas geram até 4,02 milhões de TB de dados sensíveis. À medida que os indivíduos se tornam cada vez menos dispostos a compartilhar dados amplamente, a demanda por cálculos privados desses dados cresce diariamente. Essas soluções dependem principalmente da infraestrutura da Amazon Web Services (AWS), que detém cerca de 30% do mercado global de computação em nuvem.
No entanto, a AWS apresenta várias desvantagens, principalmente devido à sua arquitetura centralizada. Mesmo com a introdução de computação segura aprimorada através do AWS Nitro Enclaves, ainda enfrenta desafios significativos na adoção por parte dos desenvolvedores, o que representa um obstáculo profundo para a segurança da blockchain e aplicações Web3.
Este artigo analisará a situação atual da AWS e apresentará uma solução de nuvem TEE descentralizada que não apenas resolve as deficiências da AWS, mas também supera as limitações de outros TEE existentes. No entanto, antes disso, precisamos investigar por que a AWS e seu produto Nitro Enclaves conseguiram obter tanta notoriedade e participação de mercado, bem como quais problemas ainda persistem por trás desses avanços.
AWS Nitro e TEE
AWS é atualmente a plataforma de computação em nuvem mais popular, oferecendo uma gama rica de ferramentas. Em resumo, a AWS é essencialmente uma infraestrutura em nuvem que atende a todas as necessidades computacionais dos desenvolvedores, incluindo serviços de computação, armazenamento e banco de dados. É bem conhecido que a AWS ocupa cerca de 30% do mercado de infraestrutura em nuvem, uma proporção bastante considerável. Entre engenheiros de software ou desenvolvedores, cerca de 48% usam a AWS de alguma forma, portanto a sua demanda é enorme.
Com a expansão da demanda e da base de clientes, incluindo grandes instituições financeiras, agências governamentais e startups que possuem dados altamente sensíveis, surgiram dúvidas sobre a segurança da AWS e se essas entidades podem armazenar e usar esses dados de forma segura através de computação confidencial.
Foi nesse contexto que a AWS surgiu a ideia de implementar TEE na sua plataforma para proteger os dados em uso, como complemento à criptografia de dados em repouso e em trânsito.
Esta nova solução de integração TEE é chamada de AWS Nitro Enclaves, que oferece um ambiente de execução isolado suportado por hardware. O TEE estabelece um ambiente seguro dentro das instâncias Amazon EC2, eliminando o acesso interativo, armazenamento persistente e conexões de rede externas. Este isolamento minimiza a superfície de ataque ao separar cargas de trabalho sensíveis das instâncias EC2 pai, seus operadores e outros softwares.
No entanto, os Nitro Enclaves são totalmente criados e geridos dentro do serviço EC2 da AWS, pertencendo a uma estrutura altamente centralizada. Desde a criação até a terminação, todos os aspectos geridos pelo Enclave são controlados pela infraestrutura da AWS, e dada a natureza da AWS como fornecedor de nuvem centralizado, isso é essencialmente centralizado.
Em resumo, o AWS Nitro Enclaves fornece um forte isolamento por meio de um ambiente de execução confiável baseado em hardware para proteger cargas de trabalho sensíveis. No entanto, sua arquitetura centralizada introduz algumas limitações e compensações.
Limitações fora da centralização AWS
Além das desvantagens da centralização, onde todos os componentes e dados dependem de um único sistema, o AWS Nitro Enclaves traz também mais desafios e novas considerações de segurança. A AWS conecta vários cartões Nitro (hardware personalizado) à CPU para executar cargas úteis TEE, o que gera um risco de segurança duplo: a CPU subjacente e o cartão Nitro podem apresentar vulnerabilidades.
Um problema significativo com os Nitro Enclaves é a falta de um mecanismo de criptografia de memória robusto. Ao contrário das soluções que integram a criptografia de memória diretamente no CPU, a natureza externa do cartão Nitro torna difícil garantir a criptografia de ponta a ponta dos dados na memória. Essa configuração pode expor informações sensíveis à manipulação durante o acesso à memória, uma vez que a criptografia depende da interação entre o CPU e os dispositivos externos.
Além disso, os desenvolvedores ainda precisam usar o Docker para criar e configurar uma imagem de máquina da Amazon (AMI) que contenha o software Enclave, o que pode ser difícil para aqueles que não estão familiarizados com a conteinerização. Eles também precisam usar o AWS CLI e o Nitro Enclaves CLI para iniciar instâncias e gerenciar Enclaves, navegar pela API do Nitro Enclaves e integrar com o serviço de gerenciamento de chaves da AWS, o que às vezes requer conhecimento sobre o processo de prova de criptografia.
A dependência do TEE em relação ao cartão Nitro levou a provas não verificáveis, uma vez que a medição da integridade do código provém do cartão Nitro, e não da própria CPU.
A AWS confia nos desenvolvedores e administradores para configurar políticas de identidade e acesso, o que pode permitir que eles acessem dados sensíveis. Os seus privilégios de acesso elevados geram riscos de ameaças internas, pois podem visualizar ou alterar dados.
Revisão da suposição de confiança do AWS Nitro
No entanto, a maior limitação é que a AWS não foi otimizada para aplicações e ecossistemas descentralizados, faltando suporte nativo para casos de uso Web3 ou sistemas de governança.
Por exemplo, a falta de armazenamento persistente nos AWS Nitro Enclaves. Embora esse isolamento seja benéfico para a segurança, limita casos de uso como agentes de IA que precisam armazenar dados de usuários em bancos de dados vetoriais.
A gestão de chaves também não se adequa ao cenário de "zero confiança". Embora o serviço de gestão de chaves da AWS (KMS) esteja disponível, ele foi projetado especificamente para o Web2, permitindo que administradores acessem chaves privadas. Isso entra em conflito com a exigência do Web3 de que as chaves devem ser completamente controladas por código e não expostas a ninguém (incluindo administradores).
Nitro Enclaves resolveu o problema da desconfiança dos desenvolvedores em relação à nuvem, mas o Web3 exige a implementação de soluções sem necessidade de confiança entre usuários, desenvolvedores e fornecedores. Não suporta upgrades de código seguros, requer propriedade descentralizada semelhante à governança de contratos inteligentes, e os desenvolvedores devem construir do zero, o que pode levar meses, e, se implementado de forma inadequada, o código pode ter vulnerabilidades.
Devido à falta de acesso à rede, a configuração de serviços Web é demorada e trabalhosa, forçando os desenvolvedores a escrever uma grande quantidade de código para adaptar as aplicações e garantir a segurança criptográfica, o que muitas vezes não é perfeito.
Por que o Web3 precisa de TEE?
Usamos o TEE porque não podemos confiar totalmente nos desenvolvedores ou administradores. Os participantes da Web3 têm filosofias diferentes e seguem sistemas sem confiança: se algo tem que ser confiável, não parece muito confiável. É por isso que os usuários confiam nos operadores de hardware para inspecionar e gerenciar aplicativos. Os aplicativos podem ser separados para evitar que interfiram, raspem ou alterem dados confidenciais durante o acesso à memória, já que a criptografia depende da colaboração suave entre a CPU e dispositivos externos. Os utilizadores e fornecedores de dados precisam de ter garantias claras e verificação das ações realizadas sobre os seus dados.
Ao desenvolver a Phala Network, o nosso objetivo era combinar as vantagens da AWS com a segurança do TEE, eliminando a complexidade através da descentralização, enquanto aumentamos a segurança. Esta abordagem visa atender às necessidades dos casos de uso do Web3. O resultado foi a proposta do conceito de nuvem TEE descentralizada, que oferece segurança e integração para aplicações descentralizadas.
Criar nuvem TEE descentralizada
Para entender o conceito de TEE cloud descentralizado, primeiro é necessário definir o que é uma cloud descentralizada. Então, o que é isso?
Uma nuvem descentralizada é um tipo de infraestrutura de computação na qual o armazenamento, processamento e gerenciamento de dados são distribuídos por uma rede de vários nós, em vez de serem centralizados em um único servidor central ou data center. Ao contrário dos sistemas de nuvem centralizados tradicionais, como a AWS, as nuvens descentralizadas não exigem uma única entidade controladora e, em vez disso, dependem do blockchain para funcionar.
Nuvem TEE descentralizada
Uma nuvem TEE descentralizada é uma infraestrutura de computação que combina TEE com uma rede de nós descentralizados para fornecer computação segura, privada e verificável. Cada nó é equipado com um TEE para proteger códigos e dados confidenciais contra acesso ou adulteração por operadores de nós.
A Phala Network é composta por uma rede descentralizada de nós de trabalho, cada um equipado com TEE. Esses nós executam tarefas computacionais para os usuários de acordo com as necessidades dos clientes, como a execução de contratos inteligentes ou o processamento de dados sensíveis.
O processo começa com o usuário a implementar a sua aplicação ou tarefa na rede. As tarefas de computação são executadas dentro da TEE desses nós, garantindo que o código e os dados permaneçam confidenciais, nem mesmo os operadores dos nós conseguem vê-los ou alterá-los.
Phala utiliza provas criptográficas para verificar se os cálculos dentro do TEE foram executados corretamente. Os operadores de nós são recompensados por fornecerem serviços honestos e seguros, mantendo a integridade da rede através de incentivos econômicos. Embora isso pareça simples, a implementação dessa solução é muito mais complexa do que parece.
Por que é tão difícil criar uma nuvem TEE descentralizada?
O TEE em si não é centralizado ou descentralizado; o grau de centralização depende da forma como é implementado e implantado no sistema. O TEE é uma área de isolamento seguro dentro do processador, destinada a proteger códigos e dados sensíveis contra acesso não autorizado pelo sistema operacional ou outros processos no mesmo dispositivo. O TEE opera em um modo centralizado ou descentralizado, dependendo da arquitetura do sistema mais amplo em que está inserido.
Historicamente, criar sistemas centralizados é mais simples do que criar sistemas descentralizados, pois os últimos enfrentam desafios na implementação e comunicação entre nós. Antes do Phala Cloud, já havíamos criado com sucesso a Phala Network 1.0 (SGX) totalmente descentralizada. Agora, estamos desenvolvendo o Phala Cloud com a mesma filosofia, embora isso leve tempo. O Phala é atualmente a única plataforma que combina TEE com total descentralização, diferente de provedores centralizados ou protocolos parcialmente descentralizados.
As vantagens da descentralização e do TEE são evidentes, mas ainda não são suficientes no desenvolvimento de produtos. Imagine que a Alibaba é a maior plataforma de comércio eletrônico do mundo, detendo uma enorme quota de mercado. Se um novo produto for lançado com o dobro da funcionalidade e a um preço mais baixo, ele ocupará todo o mercado? Infelizmente, não, porque as pessoas já estão acostumadas com os produtos existentes, mesmo que o novo produto seja melhor, elas terão preconceitos em relação a ele.
Este é um dos desafios que enfrentamos, mas não buscamos uma melhoria de duas vezes, mas sim garantir que o Phala seja dez vezes melhor e mais amigável do que os concorrentes. Além disso, como mencionado anteriormente, a AWS não é adequada para o ambiente Web3, e pretendemos preencher essa lacuna para aplicações e desenvolvedores Web3. Além da evidente vantagem da descentralização, também queremos destacar outras diferenças entre o Phala e a AWS.
Phala Cloud e AWS
Primeiro, o processo de configuração do AWS para Nitro Enclaves é complexo. Isso envolve várias etapas, incluindo a instalação do Nitro CLI, a conversão da imagem Docker em um arquivo Enclave e o manuseio da transferência de arquivos, tudo isso é muito demorado.
Em comparação, a Phala permite que os desenvolvedores "mudem e modifiquem" a implantação, e facilmente migrem os contêineres Docker existentes para um TEE seguro. Usando o Dstack SDK, os desenvolvedores precisam fazer apenas alterações mínimas para converter contêineres Docker em máquinas virtuais confidenciais (Confidential VM), e implantá-las através de uma interface Cloud amigável ao usuário, ao mesmo tempo em que ainda suportam templates e arquivos Docker Compose personalizados.
Em termos de segurança, a AWS depende da confiança nos desenvolvedores e administradores para configurar corretamente o controle de acesso e gerenciar recursos. Embora a AWS utilize TEE para computação isolada, sua infraestrutura centralizada exige confiança nas pessoas que administram a AWS e os sistemas, o que pode levar ao acesso a dados sensíveis. A Phala adota um modelo de zero confiança, não confiando por padrão em nenhuma das partes. Dados sensíveis são mantidos seguros dentro do TEE, e mesmo os operadores de nós não podem acessá-los, tornando-o adequado para aplicações Web3 que requerem operações sem necessidade de confiança.
Do ponto de vista do produto, a AWS atende principalmente clientes empresariais, uma vez que há um grande número de empresas no campo da TI tradicional. Portanto, não atende totalmente à proposta de valor das startups Web3 em termos de produtos e tecnologia. Em contraste, a Phala é construída especificamente para aplicações descentralizadas. Suporta nativamente agentes de IA que interagem com contratos inteligentes de blockchain e DApps que protegem a privacidade.
Além disso, a Phala está profundamente integrada no ecossistema blockchain através de parcerias com vários protocolos e da integração de DApps que desejam aproveitar a segurança do TEE.
A Phala é posicionada como a camada de execução da Web3 AI, permitindo que os desenvolvedores construam, lancem e lucrem com agentes de IA que podem entender e interagir de forma segura e privada com contratos inteligentes em blockchain. Fazemos isso aproveitando o TEE da NVIDIA GPU para executar grandes modelos de linguagem (LLM) em um ambiente seguro, verificável e focado na privacidade, apoiando plataformas de IA descentralizadas como NEAR AI e Sentient. Por exemplo, nossa parceria com a NOTAI destaca a execução de agentes de IA de confiança zero, onde fornecemos proteção de privacidade e confiança através do TEE e RA Explorer.
Nós também suportamos a integração de aplicações não relacionadas com IA através de Phat Contracts, que são contratos inteligentes de baixo custo e baixa latência com suporte nativo para pedidos HTTP.
No entanto, dado que muitas equipes nativas de criptografia também estão construindo TEEs e outros métodos de computação seguros, como o Phala se diferencia dessas soluções?
Phala Cloud e solução TEE
A Phala Network destaca-se como a única TEE em nuvem totalmente descentralizada, oferecendo computação segura, privada e verificável para DApps. Ao contrário do Oasis Protocol e do Secret Network, que se concentram na utilização de TEE para implementar contratos inteligentes com privacidade em suas respectivas blockchains, a Phala oferece uma plataforma de computação em nuvem descentralizada de computação offline que opera em múltiplas redes.
Phala é flexível e personalizável, aproveitando uma ampla gama de hardware TEE, incluindo Intel SGX, Intel TDX, AMD SEV e NVIDIA GPU TEE. O Marlin Protocol melhora o desempenho da rede Web3, mas não fornece recursos de computação ou privacidade, enquanto o Oasis e o Secret operam em um ecossistema de blockchain específico. A Phala está posicionada de forma única como a única nuvem TEE descentralizada com amplo suporte de hardware e ferramentas centradas no desenvolvedor, como o Dstack.
Phala é diferente porque oferece uma nuvem TEE descentralizada de uso geral, ao contrário do Oasis Protocol, Marlin e Secret Network, que se concentram em casos de uso específicos. O Phala permite que os desenvolvedores implantem qualquer aplicativo, como um modelo de IA, servidor web ou banco de dados, em um ambiente seguro. Isso é possível através de contratos Phat e Phala Cloud, que suporta implantações Dockerized e fornece acesso com um clique para CPU e GPU TEE.
Além disso, há muitas comparações sobre qual é mais adequado para casos de uso específicos, TEE ou computação multipartidária (MPC). Na nossa opinião, TEE e MPC não são concorrentes, mas sim parceiros complementares.
Phala integra TEE com MPC para criar um modelo descentralizado Root of Trust (DeRoT), uma abordagem avançada para proteger aplicativos baseados em TEE. O MPC opera dentro do TEE para reduzir o risco de conluio de nós, enquanto as provas de bloco TEE são enviadas com provas MPC para mitigar erros em implementações de provas de conhecimento zero (ZKP). Este sistema de atestado múltiplo é ainda melhorado pela exigência de que os nós MPC operem dentro do TEE. O modelo DeRoT usa TEE, MPC e ZKP para distribuir confiança na rede. Essa abordagem melhora a segurança dos DApps usando TEEs, abordando possíveis ameaças de hardware ou no nível do nó.
A possibilidade de TEE em nuvem descentralizada
Vamos escrever um artigo dedicado para explorar este tema, uma vez que já existem muitas aplicações a funcionar na Phala. Portanto, esta seção pode ser tão longa quanto o artigo inteiro. Mas esperamos esboçar os possíveis casos de uso da nuvem TEE descentralizada.
Primeiro, a Phala suporta a implantação de modelos de IA dentro de TEE, garantindo a segurança e a operação autônoma na interação com a rede blockchain. Isso inclui agentes de IA para aprimoramento de contratos inteligentes e interações entre agentes. Os desenvolvedores podem utilizar GPU TEE para cálculos de IA, alcançando verdadeira resistência à censura e proteção de privacidade.
Os desenvolvedores também podem migrar aplicativos herdados para um ambiente seguro e sem confiança para melhorar a segurança. A plataforma permite a análise de dados que preserva a privacidade por meio da Web3 e de ferramentas de análise tradicionais que podem analisar dados sem expor informações individuais do usuário. Além disso, ele pode melhorar os cálculos seguros do DeFi com recursos de privacidade, como posições de negociação confidenciais ou negociação em dark pool. Finalmente, as nuvens TEE descentralizadas podem implementar proteção MEV movendo construções de bloco para o TEE para ordenação e execução justas.
Existem muitos produtos que utilizam o Phala como parte da sua infraestrutura. Vamos explorar em um artigo separado como esses produtos usam o Phala e o que eles obtêm dessa integração.
Conclusão
Os modelos de confiança entre Web3 e Web2 apresentam diferenças fundamentais, o que leva a limitações em plataformas como a AWS. No Web3, os dados (incluindo os tokens que essencialmente pertencem aos dados) são realmente possuídos pelos usuários, enquanto os desenvolvedores de aplicações são considerados não confiáveis por padrão. Essa desconfiança decorre da possibilidade de os desenvolvedores tentarem acessar, modificar ou roubar dados dos usuários sem autorização.
Este paradigma explica várias práticas-chave no Web3:
A propriedade (ou controle de gestão) dos contratos inteligentes é uma questão-chave, os usuários valorizam mais a transparência do que permitir que os desenvolvedores tenham controle irrestrito.
Ao contrário dos contratos inteligentes, os TEEs podem impor princípios semelhantes de propriedade e controle dentro de uma gama mais ampla de procedimentos. No entanto, o AWS Nitro Enclaves é executado em uma estrutura Web2, onde os desenvolvedores mantêm a capacidade de fazer login, acessar e modificar dados e aplicativos. O TEE da Phala foi projetado com base nos princípios Web3 e suporta nativamente contratos inteligentes para gerenciar aplicativos baseados em TEE, alinhando-se com o modelo de confiança descentralizado.