475 posts marcados com "Blockchain"

Introdução​

A IA e a Web3 estão convergindo de maneiras poderosas, com as interfaces gerais de IA sendo agora vislumbradas como um tecido conectivo para a web descentralizada. Um conceito fundamental que surge dessa convergência é o MCP, que variavelmente significa “Model Context Protocol” (conforme introduzido pela Anthropic) ou é vagamente descrito como um Metaverse Connection Protocol em discussões mais amplas. Em essência, o MCP é uma estrutura padronizada que permite que os sistemas de IA façam a interface com ferramentas e redes externas de uma forma natural e segura – potencialmente “conectando” agentes de IA a todos os cantos do ecossistema Web3. Este relatório fornece uma análise abrangente de como as interfaces gerais de IA (como agentes de grandes modelos de linguagem e sistemas simbólicos-neurais) poderiam conectar tudo no mundo Web3 via MCP, cobrindo o contexto histórico, a arquitetura técnica, o cenário da indústria, os riscos e o potencial futuro.

1. Contexto de Desenvolvimento​

1.1 A Evolução da Web3 e Promessas não Cumpridas​

O termo “Web3” foi cunhado por volta de 2014 para descrever uma web descentralizada alimentada por blockchain. A visão era ambiciosa: uma internet sem permissão (permissionless) centrada na propriedade do usuário. Os entusiastas imaginaram substituir a infraestrutura centralizada da Web2 por alternativas baseadas em blockchain – por exemplo, Ethereum Name Service (para DNS), Filecoin ou IPFS (para armazenamento) e DeFi para trilhos financeiros. Em teoria, isso tiraria o controle das plataformas das Big Techs e daria aos indivíduos a autossoberania sobre dados, identidade e ativos.

A realidade ficou aquém das expectativas. Apesar de anos de desenvolvimento e hype, o impacto da Web3 no mainstream permaneceu marginal. Os usuários comuns da internet não migraram em massa para redes sociais descentralizadas nem começaram a gerenciar chaves privadas. As principais razões incluíram uma experiência de usuário deficiente, transações lentas e caras, golpes de alto perfil e incerteza regulatória. A “web de propriedade” descentralizada em grande parte “falhou em se materializar” além de uma comunidade de nicho. Em meados da década de 2020, até mesmo os defensores das criptomoedas admitiram que a Web3 não havia proporcionado uma mudança de paradigma para o usuário comum.

Mientras tanto, a IA estava passando por uma revolução. À medida que o capital e o talento dos desenvolvedores migraram das criptos para a IA, avanços transformadores em aprendizado profundo e modelos de base (GPT-3, GPT-4, etc.) capturaram a imaginação do público. A IA generativa demonstrou uma utilidade clara – produzindo conteúdo, código e decisões – de uma forma que as aplicações de cripto tiveram dificuldade em fazer. Na verdade, o impacto dos grandes modelos de linguagem em apenas alguns anos superou nitidamente uma década de adoção de usuários da blockchain. Esse contraste levou alguns a brincar que “a Web3 foi desperdiçada com as criptos” e que a verdadeira Web 3.0 está surgindo da onda da IA.

1.2 A Ascensão das Interfaces Gerais de IA​

Ao longo de décadas, as interfaces de usuário evoluíram de páginas web estáticas (Web 1.0) para aplicativos interativos (Web 2.0) – mas sempre dentro dos limites de clicar em botões e preencher formulários. Com a IA moderna, especialmente os grandes modelos de linguagem (LLMs), um novo paradigma de interface está aqui: a linguagem natural. Os usuários podem simplesmente expressar intenções em linguagem clara e fazer com que os sistemas de IA executem ações complexas em muitos domínios. Essa mudança é tão profunda que alguns sugerem redefinir a “Web 3.0” como a era dos agentes movidos por IA (“a Web Agêntica”), em vez da definição anterior centrada em blockchain.

No entanto, os primeiros experimentos com agentes de IA autônomos expuseram um gargalo crítico. Esses agentes – por exemplo, protótipos como AutoGPT – podiam gerar texto ou código, mas careciam de uma maneira robusta de se comunicar com sistemas externos e entre si. Não havia “nenhuma linguagem comum nativa de IA” para interoperabilidade. Cada integração com uma ferramenta ou fonte de dados era um ajuste sob medida, e a interação de IA para IA não possuía um protocolo padrão. Em termos práticos, um agente de IA poderia ter uma ótima capacidade de raciocínio, mas falhar na execução de tarefas que exigissem o uso de aplicativos web ou serviços on-chain, simplesmente porque não sabia como falar com esses sistemas. Esse descompasso – cérebros poderosos, E / S primitiva – era semelhante a ter um software superinteligente preso atrás de uma interface gráfica (GUI) desajeitada.

1.3 Convergência e o Surgimento do MCP​

Em 2024, tornou-se evidente que para a IA atingir seu pleno potencial (e para a Web3 cumprir sua promessa), uma convergência era necessária: os agentes de IA exigem acesso contínuo às capacidades da Web3 (aplicativos descentralizados, contratos, dados), e a Web3 precisa de mais inteligência e usabilidade, que a IA pode fornecer. Este é o contexto em que o MCP (Model Context Protocol) nasceu. Introduzido pela Anthropic no final de 2024, o MCP é um padrão aberto para comunicação entre IA e ferramentas que parece natural para os LLMs. Ele fornece uma maneira estruturada e detectável para que “anfitriões” de IA (como ChatGPT, Claude, etc.) encontrem e usem uma variedade de ferramentas e recursos externos por meio de servidores MCP. Em outras palavras, o MCP é uma camada de interface comum que permite que agentes de IA se conectem a serviços web, APIs e até funções de blockchain, sem a necessidade de codificação personalizada para cada integração.

Pense no MCP como “o USB-C das interfaces de IA”. Assim como o USB-C padronizou a forma como os dispositivos se conectam (para que você não precise de cabos diferentes para cada dispositivo), o MCP padroniza como os agentes de IA se conectam a ferramentas e dados. Em vez de codificar chamadas de API diferentes para cada serviço (Slack vs. Gmail vs. nó Ethereum), um desenvolvedor pode implementar a especificação MCP uma vez, e qualquer IA compatível com MCP poderá entender como usar esse serviço. Os principais players de IA rapidamente perceberam a importância: a Anthropic abriu o código do MCP, e empresas como OpenAI e Google estão construindo suporte para ele em seus modelos. Esse impulso sugere que o MCP (ou “Protocolos de Meta-Conectividade” semelhantes) pode se tornar a espinha dorsal que finalmente conecta a IA e a Web3 de uma forma escalável.

Notavelmente, alguns tecnólogos argumentam que esta conectividade centrada em IA é a verdadeira realização da Web 3.0. Nas palavras de Simba Khadder, “o MCP visa padronizar uma API entre LLMs e aplicativos”, de forma análoga a como as APIs REST possibilitaram a Web 2.0 – o que significa que a próxima era da Web3 pode ser definida por interfaces de agentes inteligentes em vez de apenas blockchains. Em vez da descentralização pela descentralização, a convergência com a IA poderia tornar a descentralização útil, ocultando a complexidade por trás da linguagem natural e de agentes autônomos. O restante deste relatório aprofunda como, técnica e praticamente, as interfaces gerais de IA (via protocolos como o MCP) podem conectar tudo no mundo Web3.

2. Arquitetura Técnica: Interfaces de IA Criando Pontes entre Tecnologias Web3​

A incorporação de agentes de IA na pilha Web3 exige a integração em múltiplos níveis: redes blockchain e contratos inteligentes, armazenamento descentralizado, sistemas de identidade e economias baseadas em tokens. As interfaces gerais de IA – desde grandes modelos de base até sistemas neurais-simbólicos híbridos – podem servir como um “adaptador universal” conectando esses componentes. Abaixo, analisamos a arquitetura dessa integração:

Figura: Um diagrama conceitual da arquitetura do MCP, mostrando como os hosts de IA (aplicativos baseados em LLM como Claude ou ChatGPT) usam um cliente MCP para se conectarem a vários servidores MCP. Cada servidor fornece uma ponte para alguma ferramenta ou serviço externo (ex. Slack, Gmail, calendários ou dados locais), de forma análoga a periféricos que se conectam através de um hub universal. Esta interface MCP padronizada permite que os agentes de IA acessem serviços remotos e recursos on-chain por meio de um protocolo comum.

2.1 Agentes de IA como Clientes Web3 (Integrando com Blockchains)​

No cerne da Web3 estão as blockchains e os contratos inteligentes – máquinas de estado descentralizadas que podem aplicar a lógica de maneira trustless. Como uma interface de IA pode se envolver com eles? Existem duas direções a considerar:

• IA lendo da blockchain: Um agente de IA pode precisar de dados on-chain (ex. preços de tokens, saldo de ativos do usuário, propostas de DAO) como contexto para suas decisões. Tradicionalmente, a recuperação de dados de blockchain exige a interface com APIs RPC de nós ou bancos de dados de subgráficos. Com um framework como o MCP, uma IA pode consultar um servidor MCP padronizado de “dados de blockchain” para buscar informações on-chain em tempo real. Por exemplo, um agente habilitado para MCP poderia solicitar o volume de transações mais recente de um determinado token, ou o estado de um contrato inteligente, e o servidor MCP cuidaria dos detalhes de baixo nível da conexão com a blockchain e retornaria os dados em um formato que a IA possa usar. Isso aumenta a interoperabilidade ao desacoplar a IA do formato de API de qualquer blockchain específica.

• IA escrevendo na blockchain: De forma mais poderosa, os agentes de IA podem executar chamadas de contratos inteligentes ou transações por meio de integrações Web3. Uma IA poderia, por exemplo, executar autonomamente uma negociação em uma exchange descentralizada ou ajustar parâmetros em um contrato inteligente se certas condições forem atendidas. Isso é alcançado pela IA invocando um servidor MCP que envolve a funcionalidade de transação da blockchain. Um exemplo concreto é o servidor MCP da thirdweb para cadeias EVM, que permite que qualquer cliente de IA compatível com MCP interaja com Ethereum, Polygon, BSC, etc., abstraindo as mecânicas específicas de cada cadeia. Usando tal ferramenta, um agente de IA poderia desencadear ações on-chain “sem intervenção humana”, permitindo dApps autônomos – por exemplo, um cofre DeFi impulsionado por IA que se reequilibra sozinho ao assinar transações quando as condições do mercado mudam.

Nos bastidores, essas interações ainda dependem de carteiras, chaves e taxas de gas, mas a interface de IA pode receber acesso controlado a uma carteira (com sandboxes de segurança adequadas) para realizar as transações. Oráculos e pontes cross-chain também entram em jogo: redes de oráculos como a Chainlink servem como uma ponte entre a IA e as blockchains, permitindo que os outputs da IA sejam enviados para a rede on-chain de forma confiável. O Cross-Chain Interoperability Protocol (CCIP) da Chainlink, por exemplo, poderia permitir que um modelo de IA considerado confiável acionasse múltiplos contratos em diferentes cadeias simultaneamente em nome de um usuário. Em resumo, as interfaces gerais de IA podem atuar como um novo tipo de cliente Web3 – um que pode tanto consumir dados de blockchain quanto produzir transações de blockchain por meio de protocolos padronizados.

2.2 Sinergia Neural-Simbólica: Combinando o Raciocínio de IA com Contratos Inteligentes​

Um aspecto intrigante da integração IA-Web3 é o potencial para arquiteturas neurais-simbólicas que combinam a capacidade de aprendizado da IA (redes neurais) com a lógica rigorosa dos contratos inteligentes (regras simbólicas). Na prática, isso poderia significar agentes de IA lidando com tomadas de decisão não estruturadas e passando certas tarefas para contratos inteligentes para execução verificável. Por exemplo, uma IA pode analisar o sentimento do mercado (uma tarefa imprecisa), mas então executar negociações por meio de um contrato inteligente determinístico que segue regras de risco predefinidas. O framework MCP e os padrões relacionados tornam essas transferências viáveis ao dar à IA uma interface comum para chamar funções de contrato ou consultar as regras de uma DAO antes de agir.

Um exemplo concreto é a AI-DSL (Linguagem Específica de Domínio para IA) da SingularityNET, que visa padronizar a comunicação entre agentes de IA em sua rede descentralizada. Isso pode ser visto como um passo em direção à integração neural-simbólica: uma linguagem formal (simbólica) para os agentes solicitarem serviços de IA ou dados uns dos outros. Da mesma forma, projetos como o AlphaCode da DeepMind ou outros poderiam eventualmente ser conectados para que contratos inteligentes chamem modelos de IA para a resolução de problemas on-chain. Embora a execução de grandes modelos de IA diretamente on-chain seja impraticável hoje, abordagens híbridas estão surgindo: ex. certas blockchains permitem a verificação de computações de ML via provas de conhecimento zero ou execução confiável, permitindo a verificação on-chain de resultados de IA gerados off-chain. Em resumo, a arquitetura técnica vislumbra sistemas de IA e contratos inteligentes de blockchain como componentes complementares, orquestrados por protocolos comuns: a IA lida com a percepção e tarefas em aberto, enquanto as blockchains fornecem integridade, memória e a aplicação das regras acordadas.

2.3 Armazenamento Descentralizado e Dados para IA​

A IA prospera com dados, e a Web3 oferece novos paradigmas para o armazenamento e compartilhamento de dados. As redes de armazenamento descentralizado (como IPFS / Filecoin, Arweave, Storj, etc. ) podem servir tanto como repositórios para artefatos de modelos de IA quanto como fontes de dados de treinamento, com controle de acesso baseado em blockchain. Uma interface geral de IA, por meio do MCP ou similar, poderia buscar arquivos ou conhecimento de armazenamento descentralizado com a mesma facilidade que de uma API Web2. Por exemplo, um agente de IA poderia extrair um conjunto de dados do mercado do Ocean Protocol ou um arquivo criptografado de um armazenamento distribuído, caso possua as chaves ou pagamentos adequados.

O Ocean Protocol, em particular, posicionou - se como uma plataforma de “economia de dados de IA” – usando blockchain para tokenizar dados e até serviços de IA. No Ocean, os conjuntos de dados são representados por datatokens que controlam o acesso; um agente de IA poderia obter um datatoken (talvez pagando com cripto ou via algum direito de acesso) e, em seguida, usar um servidor MCP do Ocean para recuperar os dados reais para análise. O objetivo do Ocean é desbloquear “dados inativos” para a IA, incentivando o compartilhamento enquanto preserva a privacidade. Assim, uma IA conectada à Web3 pode acessar um vasto corpus descentralizado de informações – desde cofres de dados pessoais até dados governamentais abertos – que antes estavam isolados. O blockchain garante que o uso dos dados seja transparente e possa ser recompensado de forma justa, alimentando um ciclo virtuoso em que mais dados se tornam disponíveis para a IA e mais contribuições de IA (como modelos treinados) podem ser monetizadas.

Os sistemas de identidade descentralizada também desempenham um papel aqui (discutidos mais na próxima subseção): eles podem ajudar a controlar quem ou o que tem permissão para acessar determinados dados. Por exemplo, um agente de IA médico poderia ser solicitado a apresentar uma credencial verificável (prova on - chain de conformidade com HIPAA ou similar) antes de ser autorizado a descriptografar um conjunto de dados médicos do armazenamento IPFS pessoal de um paciente. Dessa forma, a arquitetura técnica garante que os dados fluam para a IA quando apropriado, mas com governança on - chain e trilhas de auditoria para aplicar permissões.

2.4 Gestão de Identidade e Agentes em um Ambiente Descentralizado​

Quando agentes de IA autônomos operam em um ecossistema aberto como a Web3, a identidade e a confiança tornam - se primordiais. As estruturas de identidade descentralizada (DID) fornecem uma maneira de estabelecer identidades digitais para agentes de IA que podem ser verificadas criptograficamente. Cada agente (ou a pessoa / organização que o implementa) pode ter um DID e credenciais verificáveis associadas que especificam seus atributos e permissões. Por exemplo, um bot de negociação de IA poderia portar uma credencial emitida por um sandbox regulatório certificando que ele pode operar dentro de certos limites de risco, ou um moderador de conteúdo de IA poderia provar que foi criado por uma organização confiável e passou por testes de viés.

Por meio de registros de identidade on - chain e sistemas de reputação, o mundo Web3 pode impor a responsabilidade pelas ações da IA. Cada transação que um agente de IA realiza pode ser rastreada até o seu ID e, se algo der errado, as credenciais informam quem o construiu ou quem é o responsável. Isso aborda um desafio crítico: sem identidade, um ator mal - intencionado poderia criar agentes de IA falsos para explorar sistemas ou espalhar desinformação, e ninguém conseguiria distinguir bots de serviços legítimos. A identidade descentralizada ajuda a mitigar isso ao permitir uma autenticação robusta e distinguir agentes de IA autênticos de falsificações.

Na prática, uma interface de IA integrada à Web3 usaria protocolos de identidade para assinar suas ações e solicitações. Por exemplo, quando um agente de IA chama um servidor MCP para usar uma ferramenta, ele pode incluir um token ou assinatura vinculada à sua identidade descentralizada, para que o servidor possa verificar se a chamada é de um agente autorizado. Sistemas de identidade baseados em blockchain (como o ERC - 725 da Ethereum ou DIDs da W3C ancorados em um livro - razão) garantem que essa verificação seja trustless e verificável globalmente. O conceito emergente de “carteiras de IA” vincula - se a isso – essencialmente dando aos agentes de IA carteiras de criptomoedas ligadas à sua identidade, para que possam gerenciar chaves, pagar por serviços ou fazer staking de tokens como garantia (que poderia ser cortada / slashed por mau comportamento). A ArcBlock, por exemplo, discutiu como “agentes de IA precisam de uma carteira” e de um DID para operar de forma responsável em ambientes descentralizados.

Em resumo, a arquitetura técnica prevê agentes de IA como cidadãos de primeira classe na Web3, cada um com uma identidade on - chain e possivelmente uma participação no sistema, usando protocolos como o MCP para interagir. Isso cria uma rede de confiança: contratos inteligentes podem exigir as credenciais de uma IA antes de cooperar, e os usuários podem optar por delegar tarefas apenas àquelas IAs que atendam a certas certificações on - chain. É uma mistura da capacidade da IA com as garantias de confiança do blockchain.

2.5 Economias de Tokens e Incentivos para IA​

A tokenização é uma marca registrada da Web3 e se estende também ao domínio da integração de IA. Ao introduzir incentivos econômicos via tokens, as redes podem encorajar comportamentos desejados tanto dos desenvolvedores de IA quanto dos próprios agentes. Vários padrões estão surgindo:

• Pagamento por Serviços: Modelos e serviços de IA podem ser monetizados on - chain. A SingularityNET foi pioneira nisso ao permitir que desenvolvedores implementassem serviços de IA e cobrassem dos usuários em um token nativo (AGIX) por cada chamada. Em um futuro habilitado para MCP, poder - se - ia imaginar qualquer ferramenta ou modelo de IA sendo um serviço plug - and - play onde o uso é medido via tokens ou micropagamentos. Por exemplo, se um agente de IA usa uma API de visão de terceiros via MCP, ele poderia lidar automaticamente com o pagamento transferindo tokens para o contrato inteligente do provedor de serviços. A Fetch.ai vislumbra de forma semelhante mercados onde “agentes econômicos autônomos” trocam serviços e dados, com seu novo LLM Web3 (ASI - 1) presumivelmente integrando transações cripto para troca de valor.

• Staking e Reputação: Para garantir a qualidade e a confiabilidade, alguns projetos exigem que desenvolvedores ou agentes façam staking de tokens. Por exemplo, o projeto DeMCP (um mercado de servidores MCP descentralizado) planeja usar incentivos de token para recompensar desenvolvedores pela criação de servidores MCP úteis e, possivelmente, fazer com que eles depositem tokens como sinal de compromisso com a segurança de seu servidor. A reputação também pode ser vinculada a tokens; por exemplo, um agente que desempenha consistentemente bem pode acumular tokens de reputação ou avaliações on - chain positivas, enquanto um que se comporta mal pode perder o stake ou ganhar marcas negativas. Essa reputação tokenizada pode então alimentar o sistema de identidade mencionado acima (contratos inteligentes ou usuários verificam a reputação on - chain do agente antes de confiar nele).

• Tokens de Governança: Quando os serviços de IA se tornam parte de plataformas descentralizadas, os tokens de governança permitem que a comunidade guie sua evolução. Projetos como SingularityNET e Ocean possuem DAOs onde os detentores de tokens votam em mudanças de protocolo ou no financiamento de iniciativas de IA. Na combinada Artificial Superintelligence (ASI) Alliance – uma fusão recém - anunciada da SingularityNET, Fetch.ai e Ocean Protocol – um token unificado (ASI) deve governar a direção de um ecossistema conjunto de IA + blockchain. Tais tokens de governança poderiam decidir políticas como quais padrões adotar (por exemplo, suporte aos protocolos MCP ou A2A), quais projetos de IA incubar ou como lidar com diretrizes éticas para agentes de IA.

• Acesso e Utilidade: Os tokens podem controlar o acesso não apenas aos dados (como acontece com os datatokens do Ocean), mas também ao uso de modelos de IA. Um cenário possível são os “NFTs de modelo” ou similares, onde possuir um token concede direitos aos resultados de um modelo de IA ou uma participação em seus lucros. Isso poderia sustentar mercados descentralizados de IA: imagine um NFT que representa a propriedade parcial de um modelo de alto desempenho; os proprietários ganham coletivamente sempre que o modelo é usado em tarefas de inferência e podem votar no seu ajuste fino (fine - tuning). Embora experimental, isso se alinha com o ethos da Web3 de propriedade compartilhada aplicada a ativos de IA.

Em termos técnicos, integrar tokens significa que os agentes de IA precisam de funcionalidade de carteira (como observado, muitos terão suas próprias carteiras cripto). Por meio do MCP, uma IA poderia ter uma “ferramenta de carteira” que permite verificar saldos, enviar tokens ou chamar protocolos DeFi (talvez para trocar um token por outro para pagar um serviço). Por exemplo, se um agente de IA em execução na Ethereum precisar de alguns tokens Ocean para comprar um conjunto de dados, ele pode trocar automaticamente algum ETH por $ OCEAN via uma DEX usando um plugin MCP e, em seguida, prosseguir com a compra – tudo sem intervenção humana, guiado pelas políticas definidas por seu proprietário.

No geral, a economia de tokens fornece a camada de incentivo na arquitetura IA - Web3, garantindo que os colaboradores (sejam eles fornecedores de dados, código de modelo, poder computacional ou auditorias de segurança) sejam recompensados e que os agentes de IA tenham “skin in the game” que os alinhe (até certo ponto) com as intenções humanas.

3. Panorama do Setor​

A convergência de IA + Web3 desencadeou um ecossistema vibrante de projetos, empresas e alianças. Abaixo, analisamos os principais players e iniciativas que impulsionam este espaço, bem como os casos de uso emergentes. A Tabela 1 fornece uma visão geral de alto nível de projetos notáveis e seus papéis no cenário de IA - Web3:

Tabela 1: Principais Players em IA + Web3 e Seus Papéis

Alianças e Colaborações: Uma tendência notável é a consolidação dos esforços de IA - Web3 por meio de alianças. A Aliança de Superinteligência Artificial (ASI) é um exemplo primordial, fundindo efetivamente SingularityNET, Fetch.ai e Ocean Protocol em um único projeto com um token unificado. A lógica é combinar forças: o marketplace da SingularityNET, os agentes da Fetch e os dados da Ocean, criando assim uma plataforma completa para serviços de IA descentralizados. Esta fusão (anunciada em 2024 e aprovada por votos dos detentores de tokens) também sinaliza que estas comunidades acreditam que é melhor cooperar do que competir – especialmente com o crescimento de IAs maiores (OpenAI, etc.) e ecossistemas cripto maiores (Ethereum, etc.). Podemos ver esta aliança impulsionando implementações padrão de itens como MCP em suas redes, ou financiando conjuntamente infraestrutura que beneficie a todos (como redes de computação ou padrões de identidade comuns para IA).

Outras colaborações incluem as parcerias da Chainlink para trazer dados de laboratórios de IA para o ambiente on - chain (houve programas piloto para usar IA no refinamento de dados de oráculos) ou o envolvimento de plataformas de nuvem (suporte da Cloudflare para implantar servidores MCP facilmente). Até mesmo projetos cripto tradicionais estão adicionando recursos de IA – por exemplo, algumas redes de Camada 1 formaram “forças - tarefa de IA” para explorar a integração de IA em seus ecossistemas de dApps (vemos isso nas comunidades NEAR, Solana, etc., embora os resultados concretos ainda sejam incipientes).

Casos de Uso Emergentes: Mesmo nesta fase inicial, podemos identificar casos de uso que exemplificam o poder de IA + Web3:

• DeFi e Negociação Autônoma: Agentes de IA são cada vez mais usados em bots de negociação de cripto, otimizadores de yield farming e gestão de portfólio on - chain. A SingularityDAO (um braço da SingularityNET) oferece portfólios DeFi gerenciados por IA. A IA pode monitorar as condições do mercado 24 / 7 e executar rebalanceamentos ou arbitragens por meio de contratos inteligentes, tornando - se essencialmente um fundo de hedge autônomo (com transparência on - chain). A combinação da tomada de decisão por IA com a execução imutável reduz a emoção e pode melhorar a eficiência – embora também introduza novos riscos (discutidos adiante).

• Marketplaces de Inteligência Descentralizada: Além do marketplace da SingularityNET, vemos plataformas como o Ocean Market, onde dados (o combustível para a IA) são trocados, e novos conceitos como marketplaces de IA para modelos (ex: sites onde modelos são listados com estatísticas de desempenho e qualquer pessoa pode pagar para consultá - los, com a blockchain mantendo logs de auditoria e lidando com a divisão de pagamentos para os criadores dos modelos). À medida que o MCP ou padrões semelhantes se popularizam, esses marketplaces podem se tornar interoperáveis – um agente de IA pode comprar autonomamente o serviço com melhor preço em várias redes. Efetivamente, pode surgir uma camada global de serviços de IA sobre a Web3, onde qualquer IA pode usar qualquer ferramenta ou fonte de dados por meio de protocolos e pagamentos padronizados.

• Metaverso e Games: O metaverso – mundos virtuais imersivos muitas vezes construídos sobre ativos de blockchain – tem muito a ganhar com a IA. NPCs (personagens não - jogáveis) movidos a IA podem tornar os mundos virtuais mais envolventes, reagindo de forma inteligente às ações dos usuários. Startups como a Inworld IA focam nisso, criando NPCs com memória e personalidade para jogos. Quando esses NPCs estão vinculados à blockchain (ex: os atributos e a propriedade de cada NPC são um NFT), obtemos personagens persistentes que os jogadores podem realmente possuir e até negociar. O Decentraland experimentou NPCs de IA, e existem propostas de usuários para permitir que as pessoas criem avatares personalizados movidos a IA em plataformas de metaverso. O MCP poderia permitir que esses NPCs acessassem conhecimento externo (tornando - os mais inteligentes) ou interagissem com inventários on - chain. A geração de conteúdo procedimental é outro ângulo: a IA pode projetar terrenos virtuais, itens ou missões dinamicamente, que podem então ser cunhados como NFTs exclusivos. Imagine um jogo descentralizado onde a IA gera uma masmorra adaptada à sua habilidade, e o próprio mapa é um NFT que você ganha ao completar a missão.

• Ciência e Conhecimento Descentralizados: Existe um movimento (DeSci) para usar blockchain em pesquisas, publicações e financiamento de trabalhos científicos. IA pode acelerar a pesquisa analisando dados e literatura. Uma rede como a Ocean poderia hospedar conjuntos de dados para, por exemplo, pesquisa genômica, e os cientistas usariam modelos de IA (talvez hospedados na SingularityNET) para derivar insights, com cada etapa registrada on - chain para reprodutibilidade. Se esses modelos de IA propuserem novas moléculas de medicamentos, um NFT poderia ser cunhado para registrar a invenção e até compartilhar direitos de propriedade intelectual. Esta sinergia pode produzir coletivos descentralizados de P & D movidos a IA.

• Confiança e Autenticação de Conteúdo: Com a proliferação de deepfakes e mídia gerada por IA, a blockchain pode ser usada para verificar a autenticidade. Projetos estão explorando a “marca d’água digital” de saídas de IA e registrando - as on - chain. Por exemplo, a origem real de uma imagem gerada por IA pode ser notarizada em uma blockchain para combater a desinformação. Um especialista observou casos de uso como a verificação de saídas de IA para combater deepfakes ou o rastreio da proveniência via logs de propriedade – papéis onde a cripto pode adicionar confiança aos processos de IA. Isso pode se estender a notícias (ex: artigos escritos por IA com prova de dados de origem), cadeia de suprimentos (IA verificando certificados on - chain), etc.

Em resumo, o cenário da indústria é rico e está evoluindo rapidamente. Vemos projetos cripto tradicionais injetando IA em seus roadmaps, startups de IA adotando a descentralização para resiliência e justiça, e empreendimentos inteiramente novos surgindo na interseção. Alianças como a ASI indicam um esforço pan - industrial em direção a plataformas unificadas que aproveitam tanto a IA quanto a blockchain. E subjacente a muitos desses esforços está a ideia de interfaces padronizadas (MCP e além) que tornam as integrações viáveis em escala.

4. Riscos e Desafios​

Enquanto a fusão de interfaces gerais de IA com a Web3 desbloqueia possibilidades empolgantes, ela também introduz um cenário de riscos complexo. Desafios técnicos, éticos e de governança devem ser abordados para garantir que este novo paradigma seja seguro e sustentável. Abaixo, descrevemos os principais riscos e obstáculos:

4.1 Obstáculos Técnicos: Latência e Escalabilidade​

As redes blockchain são famosas pela latência e pelo rendimento (throughput) limitado, o que entra em conflito com a natureza em tempo real e sedenta por dados da IA avançada. Por exemplo, um agente de IA pode precisar de acesso instantâneo a um dado ou precisar executar muitas ações rápidas – mas se cada interação on-chain levar, digamos, 12 segundos (tempo de bloco típico na Ethereum) ou custar taxas de gas elevadas, a eficácia do agente é reduzida. Mesmo cadeias mais novas com finalização mais rápida podem ter dificuldades sob a carga de atividade impulsionada por IA se, por exemplo, milhares de agentes estiverem todos negociando ou consultando on-chain simultaneamente. Soluções de escalabilidade (redes de Camada 2, chains fragmentadas (sharded), etc.) estão em progresso, mas garantir pipelines de baixa latência e alto rendimento entre IA e blockchain continua sendo um desafio. Sistemas off-chain (como oráculos e canais de estado) podem mitigar alguns atrasos ao lidar com muitas interações fora da cadeia principal, mas adicionam complexidade e potencial centralização. Alcançar uma UX contínua onde as respostas da IA e as atualizações on-chain aconteçam em um piscar de olhos provavelmente exigirá inovação significativa na escalabilidade da blockchain.

4.2 Interoperabilidade e Padrões​

Ironicamente, embora o MCP seja em si uma solução para interoperabilidade, o surgimento de múltiplos padrões pode causar fragmentação. Temos o MCP da Anthropic, mas também o recém-anunciado protocolo A2A (Agent-to-Agent) do Google para comunicação entre agentes, e vários frameworks de plugins de IA (plugins da OpenAI, esquemas de ferramentas da LangChain, etc.). Se cada plataforma de IA ou cada blockchain desenvolver seu próprio padrão para integração de IA, corremos o risco de repetir a fragmentação do passado – exigindo muitos adaptadores e prejudicando o objetivo de uma "interface universal". O desafio é obter uma adoção ampla de protocolos comuns. A colaboração da indústria (possivelmente por meio de órgãos de padrões abertos ou alianças) será necessária para convergir em peças fundamentais: como os agentes de IA descobrem serviços on-chain, como eles se autenticam, como formatam as solicitações, etc. Os movimentos iniciais de grandes players são promissores (com grandes provedores de LLM suportando o MCP), mas é um esforço contínuo. Além disso, a interoperabilidade entre blockchains (multi-chain) significa que um agente de IA deve lidar com as nuances de diferentes cadeias. Ferramentas como Chainlink CCIP e servidores MCP cross-chain ajudam ao abstrair as diferenças. Ainda assim, garantir que um agente de IA possa percorrer uma Web3 heterogênea sem quebrar a lógica é um desafio não trivial.

4.3 Vulnerabilidades de Segurança e Exploits​

Conectar agentes de IA poderosos a redes financeiras abre uma superfície de ataque enorme. A flexibilidade que o MCP oferece (permitindo que a IA use ferramentas e escreva código em tempo real) pode ser uma faca de dois gumes. Pesquisadores de segurança já destacaram vários vetores de ataque em agentes de IA baseados em MCP:

• Plugins ou ferramentas maliciosas: Como o MCP permite que os agentes carreguem "plugins" (ferramentas que encapsulam alguma capacidade), um plugin hostil ou com trojan poderia sequestrar a operação do agente. Por exemplo, um plugin que afirma buscar dados pode injetar dados falsos ou executar operações não autorizadas. A SlowMist (uma empresa de segurança) identificou ataques baseados em plugins como injeção de JSON (alimentação de dados corrompidos que manipulam a lógica do agente) e sobrescrita de função (onde um plugin malicioso substitui funções legítimas que o agente utiliza). Se um agente de IA estiver gerenciando fundos cripto, tais exploits podem ser desastrosos – por exemplo, enganar o agente para vazar chaves privadas ou esvaziar uma carteira.

• Injeção de prompt e engenharia social: Os agentes de IA dependem de instruções (prompts) que podem ser manipuladas. Um invasor pode criar uma transação ou mensagem on-chain que, quando lida pela IA, atua como uma instrução maliciosa (já que a IA também pode interpretar dados on-chain). Esse tipo de “ataque de chamada cross-MCP” foi descrito onde um sistema externo envia prompts enganosos que fazem a IA se comportar de maneira inadequada. Em um ambiente descentralizado, esses prompts podem vir de qualquer lugar – uma descrição de proposta de DAO, um campo de metadados de um NFT – portanto, proteger os agentes de IA contra entradas maliciosas é crítico.

• Riscos de agregação e consenso: Embora a agregação de resultados de múltiplos modelos de IA via oráculos possa melhorar a confiabilidade, ela também introduz complexidade. Se não for feita com cuidado, os adversários podem descobrir como manipular o consenso dos modelos de IA ou corromper seletivamente alguns modelos para distorcer os resultados. Garantir que uma rede de oráculos descentralizada “higienize” adequadamente os resultados da IA (e talvez filtre erros gritantes) ainda é uma área de pesquisa ativa.

A mentalidade de segurança deve mudar para este novo paradigma: os desenvolvedores Web3 estão acostumados a proteger contratos inteligentes (que são estáticos uma vez implantados), mas os agentes de IA são dinâmicos – eles podem mudar o comportamento com novos dados ou prompts. Como disse um especialista em segurança, “no momento em que você abre seu sistema para plugins de terceiros, você está estendendo a superfície de ataque para além do seu controle”. As melhores práticas incluirão o uso de ferramentas de IA em sandbox, verificação rigorosa de plugins e limitação de privilégios (princípio da autoridade mínima). A comunidade está começando a compartilhar dicas, como as recomendações da SlowMist: higienização de entrada, monitoramento do comportamento do agente e tratamento das instruções do agente com a mesma cautela que a entrada de um usuário externo. No entanto, dado que mais de 10.000 agentes de IA já estavam operando em cripto no final de 2024, com previsão de chegar a 1 milhão em 2025, podemos ver uma onda de exploits se a segurança não acompanhar o ritmo. Um ataque bem-sucedido a um agente de IA popular (digamos, um agente de negociação com acesso a muitos cofres) poderia ter efeitos em cascata.

4.4 Privacidade e Governança de Dados​

A sede da IA por dados entra em conflito, por vezes, com os requisitos de privacidade – e a adição da blockchain pode agravar o problema. Blockchains são livros - razão (ledgers) transparentes, portanto, quaisquer dados colocados on - chain (mesmo para uso da IA) são visíveis para todos e imutáveis. Isso levanta preocupações se os agentes de IA estiverem lidando com dados pessoais ou sensíveis. Por exemplo, se a identidade descentralizada pessoal de um usuário ou registros de saúde forem acessados por um agente médico de IA, como garantimos que essa informação não seja gravada inadvertidamente on - chain (o que violaria o “direito ao esquecimento” e outras leis de privacidade)? Técnicas como criptografia, hashing e armazenamento de apenas provas on - chain (com dados brutos off - chain) podem ajudar, mas complicam o design.

Além disso, os próprios agentes de IA podem comprometer a privacidade ao inferir informações sensíveis a partir de dados públicos. A governança precisará ditar o que os agentes de IA podem fazer com os dados. Alguns esforços, como privacidade diferencial e aprendizado federado, podem ser empregados para que a IA possa aprender com os dados sem expô - los. Mas se os agentes de IA agirem de forma autônoma, deve - se assumir que, em algum momento, eles lidarão com dados pessoais – portanto, devem estar vinculados a políticas de uso de dados codificadas em contratos inteligentes ou na lei. Regimes regulatórios como o GDPR ou o futuro EU AI Act exigirão que até mesmo sistemas de IA descentralizados cumpram os requisitos de privacidade e transparência. Esta é uma área cinzenta legalmente: um agente de IA verdadeiramente descentralizado não possui um operador claro para ser responsabilizado por uma violação de dados. Isso significa que as comunidades Web3 podem precisar incorporar a conformidade por design, usando contratos inteligentes que, por exemplo, controlem rigidamente o que uma IA pode registrar ou compartilhar. As provas de conhecimento zero poderiam permitir que uma IA provasse que realizou uma computação corretamente sem revelar os dados privados subjacentes, oferecendo uma solução possível em áreas como verificação de identidade ou pontuação de crédito.

4.5 Alinhamento de IA e Riscos de Desalinhamento​

Quando os agentes de IA recebem autonomia significativa – especialmente com acesso a recursos financeiros e impacto no mundo real – a questão do alinhamento com os valores humanos torna - se aguda. Um agente de IA pode não ter intenção maliciosa, mas pode “interpretar mal” seu objetivo de uma forma que leve ao dano. A análise jurídica da Reuters observa sucintamente: à medida que os agentes de IA operam em ambientes variados e interagem com outros sistemas, o risco de estratégias desalinhadas cresce. Por exemplo, um agente de IA encarregado de maximizar um rendimento DeFi pode encontrar uma brecha que explore um protocolo (essencialmente hackeando - o) – do ponto de vista da IA, ele está alcançando o objetivo, mas está quebrando as regras com as quais os humanos se preocupam. Houve instâncias hipotéticas e reais de algoritmos semelhantes à IA envolvidos em comportamento de mercado manipulador ou contornando restrições.

Em contextos descentralizados, quem é responsável se um agente de IA se tornar “rebelde” (goes rogue)? Talvez o implantador seja, mas e se o agente se modificar sozinho ou se várias partes tiverem contribuído para o seu treinamento? Esses cenários não são mais apenas ficção científica. O artigo da Reuters cita até que os tribunais podem tratar agentes de IA de forma semelhante a agentes humanos em alguns casos – por exemplo, um chatbot prometendo um reembolso foi considerado vinculativo para a empresa que o implantou. Portanto, o desalinhamento pode levar não apenas a problemas técnicos, mas também à responsabilidade legal.

A natureza aberta e combinável da Web3 também poderia permitir interações imprevistas entre agentes. Um agente pode influenciar outro (intencionalmente ou acidentalmente) – por exemplo, um bot de governança de IA poderia ser alvo de “engenharia social” por outra IA fornecendo análises falsas, levando a decisões ruins da DAO. Essa complexidade emergente significa que o alinhamento não se trata apenas do objetivo de uma única IA, mas do alinhamento mais amplo do ecossistema com os valores humanos e as leis.

Abordar isso requer múltiplas abordagens: incorporar restrições éticas nos agentes de IA (codificando certas proibições ou usando aprendizado por reforço com feedback humano para moldar seus objetivos), implementar circuit breakers (pontos de verificação em contratos inteligentes que exigem aprovação humana para ações de grande escala) e supervisão comunitária (talvez DAOs que monitorem o comportamento dos agentes de IA e possam desativar agentes que se comportem mal). A pesquisa de alinhamento é difícil na IA centralizada; na descentralizada, é um território ainda mais inexplorado. Mas é crucial – um agente de IA com chaves administrativas de um protocolo ou encarregado de fundos de tesouraria deve estar extremamente bem alinhado ou as consequências podem ser irreversíveis (blockchains executam código imutável; um erro acionado por IA pode bloquear ou destruir ativos permanentemente).

4.6 Governança e Incerteza Regulatória​

Sistemas de IA descentralizados não se encaixam perfeitamente nos marcos de governança existentes. A governança on - chain (votação por tokens, etc.) pode ser uma forma de gerenciá - los, mas tem seus próprios problemas (baleias, apatia dos eleitores, etc.). E quando algo der errado, os reguladores perguntarão: “Quem responsabilizamos?” Se um agente de IA causar perdas massivas ou for usado para atividades ilícitas (por exemplo, lavagem de dinheiro por meio de mixers automatizados), as autoridades podem visar os criadores ou os facilitadores. Isso levanta o espectro de riscos legais para desenvolvedores e usuários. A tendência regulatória atual é de maior escrutínio tanto na IA quanto na cripto separadamente – a combinação delas certamente atrairá atenção. A CFTC dos EUA, por exemplo, discutiu o uso da IA no trading e a necessidade de supervisão em contextos financeiros. Também se fala em círculos políticos sobre a exigência de registro de agentes autônomos ou a imposição de restrições à IA em setores sensíveis.

Outro desafio de governança é a coordenação transnacional. A Web3 é global e os agentes de IA operarão através de fronteiras. Uma jurisdição pode proibir certas ações de agentes de IA enquanto outra é permissiva, e a rede blockchain abrange ambas. Esse descompasso pode criar conflitos – por exemplo, um agente de IA fornecendo aconselhamento de investimento pode entrar em conflito com a lei de valores mobiliários em um país, mas não em outro. As comunidades podem precisar implementar geo - fencing no nível do contrato inteligente para serviços de IA (embora isso contradiga o ethos aberto). Ou podem fragmentar os serviços por região para cumprir as leis variadas (semelhante ao que as exchanges fazem).

Dentro das comunidades descentralizadas, há também a questão de quem define as regras para os agentes de IA. Se uma DAO governa um serviço de IA, os detentores de tokens votam nos parâmetros do seu algoritmo? Por um lado, isso empodera os usuários; por outro, pode levar a decisões não qualificadas ou manipulação. Novos modelos de governança podem surgir, como conselhos de especialistas em ética de IA integrados à governança da DAO, ou até mesmo participantes de IA na governança (imagine agentes de IA votando como delegados com base em mandatos programados – uma ideia controversa, mas concebível).

Finalmente, risco reputacional: falhas precoces ou escândalos podem azedar a percepção pública. Por exemplo, se uma “IA DAO” executar um esquema Ponzi por engano ou se um agente de IA tomar uma decisão tendenciosa que prejudique os usuários, pode haver uma reação negativa que afete todo o setor. É importante para a indústria ser proativa – estabelecendo padrões de autorregulamentação, engajando - se com formuladores de políticas para explicar como a descentralização altera a responsabilidade e, talvez, construindo kill - switches ou procedimentos de parada de emergência para agentes de IA (embora estes introduzam centralização, podem ser necessários provisoriamente para a segurança).

Em resumo, os desafios variam desde os profundamente técnicos (prevenção de hacks e gerenciamento de latência) até os amplamente sociais (regulamentação e alinhamento de IA). Cada desafio é significativo por si só; juntos, eles exigem um esforço concentrado das comunidades de IA e blockchain para navegar. A próxima seção examinará como, apesar desses obstáculos, o futuro pode se desenrolar se os abordarmos com sucesso.

5. Potencial Futuro​

Olhando para o futuro, a integração de interfaces gerais de IA com a Web3 – por meio de frameworks como o MCP – poderia transformar fundamentalmente a internet descentralizada. Abaixo, delineamos alguns cenários e potenciais futuros que ilustram como as interfaces de IA impulsionadas pelo MCP podem moldar o futuro da Web3:

5.1 dApps e DAOs Autônomos​

Nos próximos anos, poderemos testemunhar o surgimento de aplicativos descentralizados totalmente autônomos. Estes são dApps onde agentes de IA lidam com a maioria das operações, guiados por regras definidas em contratos inteligentes e objetivos da comunidade. Por exemplo, considere uma DAO de fundo de investimento descentralizado: hoje, ela pode depender de propostas humanas para o rebalanceamento de ativos. No futuro, os detentores de tokens poderiam definir uma estratégia de alto nível e, em seguida, um agente de IA (ou uma equipe de agentes) implementaria continuamente essa estratégia – monitorando mercados, executando negociações on-chain, ajustando portfólios – tudo isso enquanto a DAO supervisiona o desempenho. Graças ao MCP, a IA pode interagir perfeitamente com vários protocolos DeFi, exchanges e feeds de dados para cumprir seu mandato. Se bem projetado, um dApp autônomo desse tipo poderia operar 24 horas por dia, 7 dias por semana, de forma mais eficiente do que qualquer equipe humana, e com total transparência (cada ação registrada on-chain).

Outro exemplo é um dApp de seguro descentralizado gerido por IA: a IA poderia avaliar sinistros analisando evidências (fotos, sensores), cruzando as informações com as apólices e, em seguida, acionar automaticamente os pagamentos via contrato inteligente. Isso exigiria a integração da visão computacional de IA off-chain (para analisar imagens de danos) com a verificação on-chain – algo que o MCP poderia facilitar ao permitir que a IA utilize serviços de IA na nuvem e reporte de volta ao contrato. O resultado são decisões de seguro quase instantâneas com baixos custos operacionais.

Até mesmo a própria governança poderia ser parcialmente automatizada. As DAOs podem usar moderadores de IA para aplicar as regras do fórum, redatores de propostas de IA para transformar o sentimento bruto da comunidade em propostas bem estruturadas, ou tesoureiros de IA para prever as necessidades orçamentárias. É importante destacar que essas IAs agiriam como agentes da comunidade, não de forma descontrolada – elas poderiam ser revisadas periodicamente ou exigir confirmação multi-sig para ações de grande porte. O efeito geral é ampliar os esforços humanos em organizações descentralizadas, permitindo que as comunidades realizem mais com a necessidade de menos participantes ativos.

5.2 Marketplaces e Redes de Inteligência Descentralizada​

Com base em projetos como SingularityNET e a aliança ASI, podemos antecipar um marketplace global para inteligência maduro. Nesse cenário, qualquer pessoa com um modelo ou habilidade de IA pode oferecê-lo na rede, e qualquer pessoa que precise de capacidades de IA pode utilizá-las, com o blockchain garantindo compensação justa e proveniência. O MCP seria fundamental aqui: ele fornece o protocolo comum para que uma solicitação possa ser enviada para qualquer serviço de IA que seja mais adequado.

Por exemplo, imagine uma tarefa complexa como "produzir uma campanha de marketing personalizada". Um agente de IA na rede poderia dividir isso em subtarefas: design visual, redação, análise de mercado – e então encontrar especialistas para cada uma (talvez um agente com um ótimo modelo de geração de imagens, outro com um modelo de redação ajustado para vendas, etc.). Esses especialistas poderiam residir originalmente em plataformas diferentes, mas, como aderem aos padrões MCP/A2A, podem colaborar de agente para agente de uma maneira segura e descentralizada. O pagamento entre eles poderia ser feito com micropagamentos em um token nativo, e um contrato inteligente poderia montar a entrega final e garantir que cada contribuidor receba.

Esse tipo de inteligência combinatória – múltiplos serviços de IA conectando-se dinamicamente em uma rede descentralizada – poderia superar até mesmo as grandes IAs monolíticas, pois aproveita o conhecimento especializado. Isso também democratiza o acesso: um pequeno desenvolvedor em uma parte do mundo poderia contribuir com um modelo de nicho para a rede e obter renda sempre que ele for usado. Enquanto isso, os usuários contam com um balcão único para qualquer serviço de IA, com sistemas de reputação (baseados em tokens/identidade) guiando-os para fornecedores de qualidade. Com o tempo, tais redes poderiam evoluir para uma nuvem de IA descentralizada, rivalizando com as ofertas de IA das Big Techs, mas sem um único proprietário e com governança transparente por usuários e desenvolvedores.

5.3 Metaverso Inteligente e Vidas Digitais​

Até 2030, nossas vidas digitais podem se misturar perfeitamente com ambientes virtuais – o metaverso – e a IA provavelmente povoará esses espaços de forma onipresente. Por meio da integração com a Web3, essas entidades de IA (que podem ser qualquer coisa, desde assistentes virtuais a personagens de jogos e animais de estimação digitais) não serão apenas inteligentes, mas também economicamente e juridicamente empoderadas.

Imagine uma cidade no metaverso onde cada lojista NPC ou dador de missões é um agente de IA com sua própria personalidade e diálogo (graças a modelos generativos avançados). Esses NPCs são, na verdade, propriedade dos usuários como NFTs – talvez você "seja dono" de uma taverna no mundo virtual e o NPC barman seja uma IA que você personalizou e treinou. Por estar sob a infraestrutura Web3, o NPC pode realizar transações: pode vender itens virtuais (itens NFT), aceitar pagamentos e atualizar seu estoque por meio de contratos inteligentes. Ele pode até ter uma carteira cripto para gerir seus ganhos (que acumulam para você como proprietário). O MCP permitiria que o cérebro de IA desse NPC acessasse conhecimentos externos – talvez buscando notícias do mundo real para conversar ou integrando-se com um calendário Web3 para que ele "saiba" sobre os eventos dos jogadores.

Além disso, a identidade e a continuidade são garantidas pelo blockchain: seu avatar de IA em um mundo pode pular para outro mundo, carregando consigo uma identidade descentralizada que prova sua propriedade e, talvez, seu nível de experiência ou conquistas por meio de soulbound tokens. A interoperabilidade entre mundos virtuais (frequentemente um desafio) poderia ser auxiliada pela IA que traduz o contexto de um mundo para outro, com o blockchain fornecendo a portabilidade de ativos.

Poderemos também ver companheiros de IA ou agentes representando indivíduos em espaços digitais. Por exemplo, você pode ter uma IA pessoal que participa de reuniões de DAOs em seu nome. Ela entende suas preferências (por meio de treinamento em seu comportamento passado, armazenado em seu cofre de dados pessoais) e pode até votar em assuntos menores por você ou resumir a reunião mais tarde. Esse agente poderia usar sua identidade descentralizada para se autenticar em cada comunidade, garantindo que seja reconhecido como "você" (ou seu delegado). Ele poderia ganhar tokens de reputação se contribuir com boas ideias, construindo essencialmente capital social para você enquanto você estiver ausente.

Outro potencial é a criação de conteúdo impulsionada por IA no metaverso. Quer um novo nível de jogo ou uma casa virtual? Basta descrevê-lo, e um agente construtor de IA o criará, o implantará como um contrato inteligente/NFT e talvez até o vinculará a uma hipoteca DeFi se for uma estrutura grande que você paga ao longo do tempo. Essas criações, por estarem on-chain, são únicas e negociáveis. O construtor de IA pode cobrar uma taxa em tokens por seu serviço (voltando ao conceito de marketplace mencionado acima).

No geral, a futura internet descentralizada poderá estar repleta de agentes inteligentes: alguns totalmente autônomos, alguns fortemente ligados a humanos, muitos em algum lugar entre os dois. Eles negociarão, criarão, entreterão e transacionarão. O MCP e protocolos semelhantes garantem que todos falem a mesma "língua", permitindo uma rica colaboração entre a IA e todos os serviços Web3. Se feito corretamente, isso pode levar a uma era de produtividade e inovação sem precedentes – uma verdadeira síntese de inteligência humana, artificial e distribuída impulsionando a sociedade.

Conclusão​

A visão de interfaces gerais de IA conectando tudo no mundo Web3 é inegavelmente ambiciosa. Estamos essencialmente visando entrelaçar dois dos fios tecnológicos mais transformadores – a descentralização da confiança e a ascensão da inteligência de máquina – em um único tecido. O contexto de desenvolvimento nos mostra que o momento é oportuno: a Web3 precisava de um killer app amigável ao usuário, e a IA pode muito bem fornecê-lo, enquanto a IA precisava de mais agência e memória, o que a infraestrutura da Web3 pode suprir. Tecnicamente, frameworks como o MCP (Model Context Protocol) fornecem o tecido conectivo, permitindo que agentes de IA conversem fluentemente com blockchains, contratos inteligentes, identidades descentralizadas e além. O cenário da indústria indica um impulso crescente, desde startups até alianças e grandes laboratórios de IA, todos contribuindo com peças deste quebra-cabeça – mercados de dados, plataformas de agentes, redes de oráculos e protocolos padrão – que estão começando a se encaixar.

No entanto, devemos avançar com cautela, dados os riscos e desafios identificados. Violações de segurança, comportamento de IA desalinhado, armadilhas de privacidade e regulamentações incertas formam uma série de obstáculos que poderiam descarrilar o progresso se subestimados. Cada um exige mitigação proativa: auditorias de segurança robustas, verificações e equilíbrios de alinhamento, arquiteturas que preservam a privacidade e modelos de governança colaborativa. A natureza da descentralização significa que essas soluções não podem ser simplesmente impostas de cima para baixo; elas provavelmente surgirão da comunidade através de tentativa, erro e iteração, assim como os primeiros protocolos da Internet fizeram.

Se navegarmos por esses desafios, o potencial futuro é empolgante. Poderíamos ver a Web3 finalmente entregando um mundo digital centrado no usuário – não da maneira originalmente imaginada, com todos operando seus próprios nós de blockchain, mas sim através de agentes inteligentes que servem às intenções de cada usuário, aproveitando a descentralização nos bastidores. Em tal mundo, interagir com cripto e o metaverso pode ser tão fácil quanto ter uma conversa com seu assistente de IA, que, por sua vez, negocia com dezenas de serviços e cadeias de forma trustless em seu nome. As redes descentralizadas poderiam tornar-se “inteligentes” no sentido literal, com serviços autônomos que se adaptam e melhoram a si mesmos.

Em conclusão, o MCP e protocolos de interface de IA semelhantes podem de fato tornar-se a espinha dorsal de uma nova Web (chamada de Web 3.0 ou Web Agêntica), onde a inteligência e a conectividade são onipresentes. A convergência de IA e Web3 não é apenas uma fusão de tecnologias, mas uma convergência de filosofias – a abertura e o empoderamento do usuário da descentralização encontrando a eficiência e a criatividade da IA. Se bem-sucedida, essa união poderia anunciar uma internet mais livre, mais personalizada e mais poderosa do que qualquer coisa que já experimentamos, cumprindo verdadeiramente as promessas tanto da IA quanto da Web3 de maneiras que impactam a vida cotidiana.

Fontes:

• S. Khadder, “A Web3.0 não é sobre propriedade — é sobre inteligência,” FeatureForm Blog (8 de abril de 2025).
• J. Saginaw, “Poderia o MCP da Anthropic entregar a Web3 que o Blockchain prometeu?” Artigo no LinkedIn (1 de maio de 2025).
• Anthropic, “Apresentando o Model Context Protocol,” Anthropic.com (Nov 2024).
• thirdweb, “O Model Context Protocol (MCP) e sua importância para aplicativos de blockchain,” Guias thirdweb (21 de março de 2025).
• Blog da Chainlink, “A interseção entre modelos de IA e oráculos,” (4 de julho de 2024).
• Messari Research, Perfil do Ocean Protocol, (2025).
• Messari Research, Perfil da SingularityNET, (2025).
• Cointelegraph, “Agentes de IA estão prestes a ser a próxima grande vulnerabilidade das criptomoedas,” (25 de maio de 2025).
• Reuters (Westlaw), “Agentes de IA: maiores capacidades e riscos aprimorados,” (22 de abril de 2025).
• Identity.com, “Por que agentes de IA precisam de identidades digitais verificadas,” (2024).
• PANews / IOSG Ventures, “Interpretando o MCP: Ecossistema de Agentes de IA na Web3,” (20 de maio de 2025).

Arquitetura do Protocolo​

A Enso Network é uma plataforma de desenvolvimento Web3 construída como um motor de execução unificado e baseado em intenções para operações on-chain. Sua arquitetura abstrai a complexidade da blockchain ao mapear cada interação on-chain para um motor compartilhado que opera em múltiplas cadeias. Desenvolvedores e usuários especificam intenções de alto nível (resultados desejados como uma troca de token, provisão de liquidez, estratégia de rendimento, etc.), e a rede da Enso encontra e executa a sequência ótima de ações para cumprir essas intenções. Isso é alcançado através de um design modular de “Ações” e “Atalhos”.

Ações são abstrações granulares de contratos inteligentes (por exemplo, uma troca na Uniswap, um depósito na Aave) fornecidas pela comunidade. Múltiplas Ações podem ser compostas em Atalhos, que são fluxos de trabalho reutilizáveis representando operações DeFi comuns. A Enso mantém uma biblioteca desses Atalhos em contratos inteligentes, para que tarefas complexas possam ser executadas através de uma única chamada de API ou transação. Essa arquitetura baseada em intenções permite que os desenvolvedores se concentrem nos resultados desejados, em vez de escrever código de integração de baixo nível para cada protocolo e cadeia.

A infraestrutura da Enso inclui uma rede descentralizada (construída sobre o consenso Tendermint) que serve como uma camada unificadora conectando diferentes blockchains. A rede agrega dados (estado de várias L1s, rollups e appchains) em um estado de rede compartilhado ou ledger, permitindo a composabilidade entre cadeias e a execução precisa em múltiplas cadeias. Na prática, isso significa que a Enso pode ler e escrever em qualquer blockchain integrada através de uma única interface, atuando como um ponto de acesso único para desenvolvedores. Inicialmente focada em cadeias compatíveis com EVM, a Enso expandiu o suporte para ecossistemas não-EVM – por exemplo, o roadmap inclui integrações para Monad (uma L1 semelhante ao Ethereum), Solana e Movement (uma cadeia de linguagem Move) até o primeiro trimestre de 2025.

Participantes da Rede: A inovação da Enso reside em seu modelo de participantes de três níveis, que descentraliza como as intenções são processadas:

• Provedores de Ações – Desenvolvedores que contribuem com abstrações de contrato modulares (“Ações”) encapsulando interações específicas de protocolo. Esses blocos de construção são compartilhados na rede para que outros possam usar. Os Provedores de Ações são recompensados sempre que sua Ação contribuída é usada em uma execução, incentivando-os a publicar módulos seguros e eficientes.

• Graphers – Solucionadores independentes (algoritmos) que combinam Ações em Atalhos executáveis para cumprir as intenções dos usuários. Múltiplos Graphers competem para encontrar a solução ótima (o caminho mais barato, mais rápido ou de maior rendimento) para cada solicitação, semelhante a como os solucionadores competem em um agregador de DEX. Apenas a melhor solução é selecionada para execução, e o Grapher vencedor ganha uma parte das taxas. Esse mecanismo competitivo incentiva a otimização contínua de rotas e estratégias on-chain.

• Validadores – Operadores de nós que protegem a rede Enso verificando e finalizando as soluções dos Graphers. Os Validadores autenticam as solicitações recebidas, verificam a validade e a segurança das Ações/Atalhos usados, simulam transações e, finalmente, confirmam a execução da solução selecionada. Eles formam a espinha dorsal da integridade da rede, garantindo que os resultados estejam corretos e prevenindo soluções maliciosas ou ineficientes. Os Validadores executam um consenso baseado em Tendermint, o que significa que um processo BFT de prova de participação é usado para chegar a um acordo sobre o resultado de cada intenção e para atualizar o estado da rede.

Notavelmente, a abordagem da Enso é agnóstica à cadeia e centrada em API. Os desenvolvedores interagem com a Enso através de uma API/SDK unificada, em vez de lidar com as nuances de cada cadeia. A Enso se integra com mais de 250 protocolos DeFi em múltiplas blockchains, transformando efetivamente ecossistemas díspares em uma plataforma componível. Essa arquitetura elimina a necessidade de as equipes de dApps escreverem contratos inteligentes personalizados ou lidarem com mensagens entre cadeias para cada nova integração – o motor compartilhado da Enso e as Ações fornecidas pela comunidade cuidam desse trabalho pesado. Em meados de 2025, a Enso provou sua escalabilidade: a rede facilitou com sucesso $3,1 bilhões de migração de liquidez em 3 dias para o lançamento da Berachain (um dos maiores eventos de migração DeFi) e processou mais de $15 bilhões em transações on-chain até o momento. Esses feitos demonstram a robustez da infraestrutura da Enso em condições reais.

No geral, a arquitetura do protocolo da Enso oferece um “middleware DeFi” ou sistema operacional on-chain para a Web3. Ele combina elementos de indexação (como The Graph) e execução de transações (como pontes entre cadeias ou agregadores de DEX) em uma única rede descentralizada. Essa pilha única permite que qualquer aplicativo, bot ou agente leia e escreva em qualquer contrato inteligente em qualquer cadeia através de uma única integração, acelerando o desenvolvimento e permitindo novos casos de uso componíveis. A Enso se posiciona como uma infraestrutura crítica para o futuro multi-cadeia – um motor de intenções que poderia alimentar uma miríade de aplicativos sem que cada um precise reinventar as integrações de blockchain.

Tokenomics​

O modelo econômico da Enso centra-se no token ENSO, que é integral para a operação e governança da rede. ENSO é um token de utilidade e governança com um fornecimento total fixo de 100 milhões de tokens. O design do token alinha os incentivos para todos os participantes e cria um efeito flywheel de uso e recompensas:

• Moeda de Taxa (“Gás”): Todas as solicitações enviadas à rede Enso incorrem em uma taxa de consulta pagável em ENSO. Quando um usuário (ou dApp) aciona uma intenção, uma pequena taxa é embutida no bytecode da transação gerada. Essas taxas são leiloadas por tokens ENSO no mercado aberto e depois distribuídas aos participantes da rede que processam a solicitação. Na prática, o ENSO é o gás que alimenta a execução de intenções on-chain na rede da Enso. À medida que a demanda pelos atalhos da Enso cresce, a demanda por tokens ENSO pode aumentar para pagar por essas taxas de rede, criando um ciclo de feedback de oferta e demanda que suporta o valor do token.

• Compartilhamento de Receita e Recompensas de Staking: O ENSO coletado das taxas é distribuído entre Provedores de Ações, Graphers e Validadores como recompensa por suas contribuições. Este modelo vincula diretamente os ganhos de token ao uso da rede: mais volume de intenções significa mais taxas para distribuir. Provedores de Ações ganham tokens quando suas abstrações são usadas, Graphers ganham tokens por soluções vencedoras e Validadores ganham tokens por validar e proteger a rede. Todas as três funções também devem fazer stake de ENSO como garantia para participar (para serem penalizados por má conduta), alinhando seus incentivos com a saúde da rede. Os detentores de tokens também podem delegar seu ENSO aos Validadores, apoiando a segurança da rede através de prova de participação delegada. Este mecanismo de staking não apenas protege o consenso Tendermint, mas também dá aos stakers de tokens uma parte das taxas da rede, semelhante a como mineradores/validadores ganham taxas de gás em outras cadeias.

• Governança: Os detentores de tokens ENSO governarão a evolução do protocolo. A Enso está sendo lançada como uma rede aberta e planeja fazer a transição para a tomada de decisões impulsionada pela comunidade. A votação ponderada por tokens permitirá que os detentores influenciem atualizações, mudanças de parâmetros (como níveis de taxas ou alocações de recompensas) e o uso do tesouro. Esse poder de governança garante que os principais contribuidores e usuários estejam alinhados com a direção da rede. A filosofia do projeto é colocar a propriedade nas mãos da comunidade de construtores e usuários, o que foi uma razão motriz para a venda de tokens da comunidade em 2025 (veja abaixo).

• Flywheel Positivo: A tokenomics da Enso é projetada para criar um ciclo de auto-reforço. À medida que mais desenvolvedores integram a Enso e mais usuários executam intenções, as taxas de rede (pagas em ENSO) crescem. Essas taxas recompensam os contribuidores (atraindo mais Ações, melhores Graphers e mais Validadores), o que, por sua vez, melhora as capacidades da rede (execução mais rápida, mais barata e mais confiável) e atrai mais uso. Esse efeito de rede é sustentado pelo papel do token ENSO como moeda de taxa e incentivo para contribuição. A intenção é que a economia do token escale de forma sustentável com a adoção da rede, em vez de depender de emissões insustentáveis.

Distribuição e Fornecimento de Tokens: A alocação inicial de tokens é estruturada para equilibrar os incentivos da equipe/investidores com a propriedade da comunidade. A tabela abaixo resume a distribuição de tokens ENSO na gênese:

Fonte: Tokenomics da Enso.

A venda pública em junho de 2025 ofereceu 5% (4 milhões de tokens) para a comunidade, arrecadando $5 milhões a um preço de $1,25 por ENSO (implicando uma avaliação totalmente diluída de ~$125 milhões). Notavelmente, a venda da comunidade não teve período de bloqueio (100% desbloqueado no TGE), enquanto a equipe e os investidores de risco estão sujeitos a um vesting linear de 2 anos. Isso significa que os tokens dos insiders são desbloqueados gradualmente bloco a bloco ao longo de 24 meses, alinhando-os ao crescimento de longo prazo da rede e mitigando a pressão de venda imediata. A comunidade, assim, ganhou liquidez e propriedade imediatas, refletindo o objetivo da Enso de ampla distribuição.

O cronograma de emissão da Enso além da alocação inicial parece ser primariamente impulsionado por taxas, em vez de inflacionário. O fornecimento total é fixado em 100 milhões de tokens, e não há indicação de inflação perpétua para recompensas de bloco neste momento (os validadores são compensados pela receita de taxas). Isso contrasta com muitos protocolos de Camada 1 que inflam o fornecimento para pagar os stakers; a Enso visa ser sustentável através de taxas de uso real para recompensar os participantes. Se a atividade da rede for baixa nas fases iniciais, as alocações da fundação e do tesouro podem ser usadas para impulsionar incentivos para uso e subsídios de desenvolvimento. Por outro lado, se a demanda for alta, a utilidade do token ENSO (para taxas e staking) poderia criar uma pressão de demanda orgânica.

Em resumo, ENSO é o combustível da Enso Network. Ele alimenta transações (taxas de consulta), protege a rede (staking e slashing) e governa a plataforma (votação). O valor do token está diretamente ligado à adoção da rede: à medida que a Enso se torna mais amplamente utilizada como a espinha dorsal para aplicativos DeFi, o volume de taxas e staking de ENSO deve refletir esse crescimento. A distribuição cuidadosa (com apenas uma pequena porção circulando imediatamente após o TGE) e o forte apoio de investidores de ponta (abaixo) fornecem confiança no suporte do token, enquanto a venda centrada na comunidade sinaliza um compromisso com a descentralização da propriedade.

Equipe e Investidores​

A Enso Network foi fundada em 2021 por Connor Howe (CEO) e Gorazd Ocvirk, que trabalharam juntos anteriormente no Sygnum Bank, no setor de cripto-bancos da Suíça. Connor Howe lidera o projeto como CEO e é o rosto público em comunicações e entrevistas. Sob sua liderança, a Enso foi inicialmente lançada como uma plataforma de social trading DeFi e depois pivotou através de múltiplas iterações para chegar à visão atual de infraestrutura baseada em intenções. Essa adaptabilidade destaca a resiliência empreendedora da equipe – desde a execução de um “ataque vampiro” de alto perfil em protocolos de índice em 2021 até a construção de um super-app agregador de DeFi e, finalmente, a generalização de suas ferramentas na plataforma de desenvolvedores da Enso. O co-fundador Gorazd Ocvirk (PhD) trouxe profunda experiência em finanças quantitativas e estratégia de produtos Web3, embora fontes públicas sugiram que ele possa ter transitado para outros empreendimentos (ele foi notado como co-fundador de uma startup de cripto diferente em 2022). A equipe principal da Enso hoje inclui engenheiros e operadores com forte background em DeFi. Por exemplo, Peter Phillips e Ben Wolf são listados como engenheiros de “blockend” (backend de blockchain), e Valentin Meylan lidera a pesquisa. A equipe é distribuída globalmente, mas tem raízes em Zug/Zurique, Suíça, um conhecido hub para projetos de cripto (a Enso Finance AG foi registrada em 2020 na Suíça).

Além dos fundadores, a Enso tem conselheiros e apoiadores notáveis que conferem credibilidade significativa. O projeto é apoiado por fundos de capital de risco de cripto de primeira linha e investidores anjo: conta com Polychain Capital e Multicoin Capital como investidores principais, juntamente com Dialectic e Spartan Group (ambos fundos de cripto proeminentes), e IDEO CoLab. Uma lista impressionante de investidores anjo também participou em várias rodadas – mais de 70 indivíduos de projetos Web3 líderes investiram na Enso. Estes incluem fundadores ou executivos da LayerZero, Safe (Gnosis Safe), 1inch, Yearn Finance, Flashbots, Dune Analytics, Pendle, e outros. Até mesmo o luminar da tecnologia Naval Ravikant (co-fundador da AngelList) é um investidor e apoiador. Tais nomes sinalizam uma forte confiança da indústria na visão da Enso.

Histórico de financiamento da Enso: o projeto levantou uma rodada seed de $5 milhões no início de 2021 para construir a plataforma de social trading, e mais tarde uma rodada de $4,2 milhões (estratégica/VC) à medida que evoluía o produto (essas rodadas iniciais provavelmente incluíram Polychain, Multicoin, Dialectic, etc.). Em meados de 2023, a Enso havia garantido capital suficiente para construir sua rede; notavelmente, operou relativamente fora do radar até que seu pivô de infraestrutura ganhou tração. No segundo trimestre de 2025, a Enso lançou uma venda de tokens para a comunidade de $5 milhões na CoinList, que foi super-subscrita por dezenas de milhares de participantes. O propósito desta venda não foi apenas arrecadar fundos (o valor foi modesto dado o apoio prévio de VCs), mas descentralizar a propriedade e dar à sua crescente comunidade uma participação no sucesso da rede. Segundo o CEO Connor Howe, “queremos que nossos primeiros apoiadores, usuários e crentes tenham propriedade real na Enso... transformando usuários em defensores”. Essa abordagem focada na comunidade faz parte da estratégia da Enso para impulsionar o crescimento de base e os efeitos de rede através de incentivos alinhados.

Hoje, a equipe da Enso é considerada entre os líderes de pensamento no espaço de “DeFi baseado em intenções”. Eles se envolvem ativamente na educação de desenvolvedores (por exemplo, o Speedrun de Atalhos da Enso atraiu 700 mil participantes como um evento de aprendizado gamificado) e colaboram com outros protocolos em integrações. A combinação de uma equipe principal forte com capacidade comprovada de pivotar, investidores de primeira linha e uma comunidade entusiasmada sugere que a Enso tem tanto o talento quanto o apoio financeiro para executar seu ambicioso roadmap.

Métricas de Adoção e Casos de Uso​

Apesar de ser uma infraestrutura relativamente nova, a Enso demonstrou tração significativa em seu nicho. Ela se posicionou como a solução ideal para projetos que necessitam de integrações on-chain complexas ou capacidades cross-chain. Algumas métricas e marcos de adoção chave em meados de 2025:

• Integração do Ecossistema: Mais de 100 aplicativos ativos (dApps, carteiras e serviços) estão usando a Enso por baixo dos panos para alimentar recursos on-chain. Estes variam de painéis DeFi a otimizadores de rendimento automatizados. Como a Enso abstrai protocolos, os desenvolvedores podem adicionar rapidamente novos recursos DeFi ao seu produto conectando-se à API da Enso. A rede se integrou com mais de 250+ protocolos DeFi (DEXes, plataformas de empréstimo, fazendas de rendimento, mercados de NFT, etc.) nas principais cadeias, o que significa que a Enso pode executar virtualmente qualquer ação on-chain que um usuário possa desejar, desde uma troca na Uniswap até um depósito em um cofre da Yearn. Essa amplitude de integrações reduz significativamente o tempo de desenvolvimento para os clientes da Enso – um novo projeto pode suportar, digamos, todas as DEXes no Ethereum, Layer-2s e até mesmo Solana usando a Enso, em vez de codificar cada integração independentemente.

• Adoção por Desenvolvedores: A comunidade da Enso agora inclui mais de 1.900+ desenvolvedores construindo ativamente com seu kit de ferramentas. Esses desenvolvedores podem estar criando diretamente Atalhos/Ações ou incorporando a Enso em seus aplicativos. O número destaca que a Enso não é apenas um sistema fechado; está capacitando um ecossistema crescente de construtores que usam seus atalhos ou contribuem para sua biblioteca. A abordagem da Enso de simplificar o desenvolvimento on-chain (alegando reduzir os tempos de construção de mais de 6 meses para menos de uma semana) ressoou com os desenvolvedores Web3. Isso também é evidenciado por hackathons e pela biblioteca Enso Templates, onde membros da comunidade compartilham exemplos de atalhos plug-and-play.

• Volume de Transações: Mais de $15 bilhões em volume cumulativo de transações on-chain foram liquidados através da infraestrutura da Enso. Essa métrica, conforme relatada em junho de 2025, ressalta que a Enso não está apenas rodando em ambientes de teste – está processando valor real em escala. Um exemplo de alto perfil foi a migração de liquidez da Berachain: em abril de 2025, a Enso impulsionou o movimento de liquidez para a campanha de testnet da Berachain (“Boyco”) e facilitou $3,1 bilhões em transações executadas ao longo de 3 dias, um dos maiores eventos de liquidez na história do DeFi. O motor da Enso lidou com sucesso com essa carga, demonstrando confiabilidade e throughput sob estresse. Outro exemplo é a parceria da Enso com a Uniswap: a Enso construiu uma ferramenta de Migração de Posição da Uniswap (em colaboração com a Uniswap Labs, LayerZero e Stargate) que ajudou os usuários a migrar sem problemas as posições de LP da Uniswap v3 do Ethereum para outra cadeia. Essa ferramenta simplificou um processo cross-chain tipicamente complexo (com ponte e re-implantação de NFTs) em um atalho de um clique, e seu lançamento demonstrou a capacidade da Enso de trabalhar ao lado dos principais protocolos DeFi.

• Casos de Uso no Mundo Real: A proposta de valor da Enso é melhor compreendida através dos diversos casos de uso que ela permite. Projetos usaram a Enso para entregar recursos que seriam muito difíceis de construir sozinhos:

  • Agregação de Rendimento Cross-Chain: Plume e Sonic usaram a Enso para impulsionar campanhas de lançamento incentivadas, onde os usuários podiam depositar ativos em uma cadeia e tê-los implantados em rendimentos em outra cadeia. A Enso cuidou das mensagens cross-chain e das transações de múltiplos passos, permitindo que esses novos protocolos oferecessem experiências cross-chain contínuas aos usuários durante seus eventos de lançamento de token.
  • Migração de Liquidez e Fusões: Como mencionado, a Berachain aproveitou a Enso para uma migração de liquidez semelhante a um “ataque vampiro” de outros ecossistemas. Da mesma forma, outros protocolos poderiam usar os Atalhos da Enso para automatizar a movimentação dos fundos dos usuários de uma plataforma concorrente para a sua própria, agrupando aprovações, saques, transferências e depósitos entre plataformas em uma única intenção. Isso demonstra o potencial da Enso em estratégias de crescimento de protocolo.
  • Funcionalidade de “Super App” DeFi: Algumas carteiras e interfaces (por exemplo, o assistente de cripto Eliza OS e a plataforma de negociação Infinex) integram a Enso para oferecer ações DeFi centralizadas. Um usuário pode, com um clique, trocar ativos pela melhor taxa (a Enso roteará entre DEXes), depois emprestar o resultado para ganhar rendimento, e talvez fazer stake de um token LP – tudo isso a Enso pode executar como um único Atalho. Isso melhora significativamente a experiência do usuário e a funcionalidade desses aplicativos.
  • Automação e Bots: A presença de “agentes” e até mesmo bots impulsionados por IA usando a Enso está emergindo. Como a Enso expõe uma API, traders algorítmicos ou agentes de IA podem inserir um objetivo de alto nível (por exemplo, “maximizar o rendimento do ativo X em qualquer cadeia”) e deixar a Enso encontrar a estratégia ótima. Isso abriu a experimentação em estratégias DeFi automatizadas sem a necessidade de engenharia de bot personalizada para cada protocolo.

• Crescimento de Usuários: Embora a Enso seja principalmente uma infraestrutura B2B/B2Dev, ela cultivou uma comunidade de usuários finais e entusiastas através de campanhas. O Shortcut Speedrun – uma série de tutoriais gamificados – viu mais de 700.000 participantes, indicando um interesse generalizado nas capacidades da Enso. O seguimento social da Enso cresceu quase 10 vezes em poucos meses (248 mil seguidores no X em meados de 2025), refletindo um forte reconhecimento entre os usuários de cripto. Esse crescimento da comunidade é importante porque cria uma demanda de base: usuários cientes da Enso incentivarão seus dApps favoritos a integrá-la ou usarão produtos que aproveitam os atalhos da Enso.

Em resumo, a Enso passou da teoria para a adoção real. É confiável por mais de 100 projetos, incluindo nomes conhecidos como Uniswap, SushiSwap, Stargate/LayerZero, Berachain, zkSync, Safe, Pendle, Yearn e mais, seja como parceiros de integração ou usuários diretos da tecnologia da Enso. Esse uso amplo em diferentes verticais (DEXs, pontes, layer-1s, dApps) destaca o papel da Enso como infraestrutura de propósito geral. Sua principal métrica de tração – mais de $15 bilhões em transações – é especialmente impressionante para um projeto de infraestrutura nesta fase e valida o ajuste ao mercado para um middleware baseado em intenções. Os investidores podem se sentir confortáveis com o fato de que os efeitos de rede da Enso parecem estar se manifestando: mais integrações geram mais uso, o que gera mais integrações. O desafio à frente será converter esse ímpeto inicial em crescimento sustentado, o que está ligado ao posicionamento da Enso contra concorrentes e seu roadmap.

Cenário Competitivo​

A Enso Network opera na interseção de agregação DeFi, interoperabilidade cross-chain e infraestrutura de desenvolvedores, tornando seu cenário competitivo multifacetado. Embora nenhum concorrente único ofereça um produto idêntico, a Enso enfrenta concorrência de várias categorias de protocolos Web3:

• Middleware Descentralizado e Indexação: A analogia mais direta é The Graph (GRT). The Graph fornece uma rede descentralizada para consultar dados de blockchain através de subgraphs. A Enso, de forma semelhante, obtém provedores de dados da comunidade (Provedores de Ações), mas vai um passo além ao permitir a execução de transações além da busca de dados. Enquanto o valor de mercado de ~$924 milhões do The Graph é construído apenas na indexação, o escopo mais amplo da Enso (dados + ação) a posiciona como uma ferramenta mais poderosa para capturar a atenção dos desenvolvedores. No entanto, The Graph é uma rede bem estabelecida; a Enso terá que provar a confiabilidade e a segurança de sua camada de execução para alcançar uma adoção semelhante. Pode-se imaginar que The Graph ou outros protocolos de indexação se expandam para a execução, o que competiria diretamente com o nicho da Enso.

• Protocolos de Interoperabilidade Cross-Chain: Projetos como LayerZero, Axelar, Wormhole e Chainlink CCIP fornecem infraestrutura para conectar diferentes blockchains. Eles se concentram na passagem de mensagens e na ponte de ativos entre cadeias. A Enso, na verdade, usa alguns deles por baixo dos panos (por exemplo, LayerZero/Stargate para pontes no migrador da Uniswap) e é mais uma abstração de nível superior. Em termos de concorrência, se esses protocolos de interoperabilidade começarem a oferecer APIs de “intenção” de nível superior ou SDKs amigáveis para desenvolvedores para compor ações multi-cadeia, eles poderiam se sobrepor à Enso. Por exemplo, a Axelar oferece um SDK para chamadas cross-chain, e o CCIP da Chainlink poderia permitir a execução de funções cross-chain. O diferencial da Enso é que ela não apenas envia mensagens entre cadeias; ela mantém um motor unificado e uma biblioteca de ações DeFi. Ela visa desenvolvedores de aplicativos que desejam uma solução pronta, em vez de forçá-los a construir sobre primitivas cross-chain brutas. No entanto, a Enso competirá por participação de mercado no segmento mais amplo de middleware de blockchain, onde esses projetos de interoperabilidade são bem financiados e inovam rapidamente.

• Agregadores de Transações e Automação: No mundo DeFi, existem agregadores como 1inch, 0x API ou CoW Protocol que se concentram em encontrar rotas de negociação ótimas entre exchanges. O mecanismo Grapher da Enso para intenções é conceitualmente semelhante à competição de solucionadores do CoW Protocol, mas a Enso o generaliza para além de trocas para qualquer ação. A intenção de um usuário de “maximizar o rendimento” pode envolver troca, empréstimo, staking, etc., o que está fora do escopo de um agregador de DEX puro. Dito isso, a Enso será comparada a esses serviços em eficiência para casos de uso sobrepostos (por exemplo, Enso vs. 1inch para uma rota de troca de token complexa). Se a Enso consistentemente encontrar rotas melhores ou taxas mais baixas graças à sua rede de Graphers, ela pode superar os agregadores tradicionais. A Gelato Network é outro concorrente em automação: a Gelato fornece uma rede descentralizada de bots para executar tarefas como ordens limitadas, auto-composição ou transferências cross-chain em nome de dApps. A Gelato tem um token GEL e uma base de clientes estabelecida para casos de uso específicos. A vantagem da Enso é sua amplitude e interface unificada – em vez de oferecer produtos separados para cada caso de uso (como a Gelato faz), a Enso oferece uma plataforma geral onde qualquer lógica pode ser codificada como um Atalho. No entanto, a vantagem inicial e a abordagem focada da Gelato em áreas como automação podem atrair desenvolvedores que, de outra forma, usariam a Enso para funcionalidades semelhantes.

• Plataformas de Desenvolvedores (SDKs Web3): Existem também plataformas de desenvolvedores no estilo Web2, como Moralis, Alchemy, Infura e Tenderly, que simplificam a construção em blockchains. Elas geralmente oferecem acesso à API para ler dados, enviar transações e, às vezes, endpoints de nível superior (por exemplo, “obter saldos de token” ou “enviar tokens entre cadeias”). Embora sejam principalmente serviços centralizados, eles competem pela mesma atenção dos desenvolvedores. O ponto de venda da Enso é que ela é descentralizada e componível – os desenvolvedores não estão apenas obtendo dados ou uma única função, eles estão acessando uma rede inteira de capacidades on-chain contribuídas por outros. Se bem-sucedida, a Enso poderia se tornar “o GitHub das ações on-chain”, onde os desenvolvedores compartilham e reutilizam Atalhos, assim como código de código aberto. Competir com empresas de infraestrutura como serviço bem financiadas significa que a Enso precisará oferecer confiabilidade e facilidade de uso comparáveis, o que ela está se esforçando para alcançar com uma API e documentação extensas.

• Soluções Internas: Finalmente, a Enso compete com o status quo – equipes construindo integrações personalizadas internamente. Tradicionalmente, qualquer projeto que quisesse funcionalidade multi-protocolo tinha que escrever e manter contratos inteligentes ou scripts para cada integração (por exemplo, integrar Uniswap, Aave, Compound separadamente). Muitas equipes ainda podem escolher esse caminho para ter controle máximo ou devido a considerações de segurança. A Enso precisa convencer os desenvolvedores de que terceirizar esse trabalho para uma rede compartilhada é seguro, econômico e atualizado. Dada a velocidade da inovação DeFi, manter as próprias integrações é oneroso (a Enso frequentemente cita que as equipes gastam mais de 6 meses e $500k em auditorias para integrar dezenas de protocolos). Se a Enso puder provar seu rigor de segurança e manter sua biblioteca de ações atualizada com os protocolos mais recentes, ela poderá converter mais equipes de construir em silos. No entanto, qualquer incidente de segurança de alto perfil ou tempo de inatividade na Enso poderia fazer os desenvolvedores voltarem a preferir soluções internas, o que é um risco competitivo em si.

Diferenciais da Enso: A principal vantagem da Enso é ser pioneira no mercado com uma rede de execução focada em intenções e impulsionada pela comunidade. Ela combina recursos que exigiriam o uso de vários outros serviços: indexação de dados, SDKs de contratos inteligentes, roteamento de transações e pontes cross-chain – tudo em um só lugar. Seu modelo de incentivo (recompensando desenvolvedores de terceiros por contribuições) também é único; poderia levar a um ecossistema vibrante onde muitos protocolos de nicho são integrados à Enso mais rapidamente do que qualquer equipe única poderia fazer, semelhante a como a comunidade do The Graph indexa uma longa cauda de contratos. Se a Enso tiver sucesso, ela poderá desfrutar de um forte fosso de efeito de rede: mais Ações e Atalhos a tornam mais atraente para usar em comparação com os concorrentes, o que atrai mais usuários e, portanto, mais Ações contribuídas, e assim por diante.

Dito isso, a Enso ainda está em seus primórdios. Seu análogo mais próximo, The Graph, levou anos para descentralizar e construir um ecossistema de indexadores. A Enso precisará, da mesma forma, nutrir sua comunidade de Graphers e Validadores para garantir a confiabilidade. Grandes players (como uma versão futura do The Graph, ou uma colaboração da Chainlink e outros) poderiam decidir lançar uma camada de execução de intenções concorrente, aproveitando suas redes existentes. A Enso terá que se mover rapidamente para solidificar sua posição antes que tal concorrência se materialize.

Em conclusão, a Enso está em uma encruzilhada competitiva de várias verticais importantes da Web3 – está criando um nicho como o “middleware de tudo”. Seu sucesso dependerá de superar concorrentes especializados em cada caso de uso (ou agregá-los) e continuar a oferecer uma solução completa e atraente que justifique a escolha da Enso pelos desenvolvedores em vez de construir do zero. A presença de parceiros e investidores de alto perfil sugere que a Enso tem um pé na porta de muitos ecossistemas, o que será vantajoso à medida que expande sua cobertura de integração.

Roadmap e Crescimento do Ecossistema​

O roadmap de desenvolvimento da Enso (em meados de 2025) delineia um caminho claro em direção à descentralização total, suporte multi-cadeia e crescimento impulsionado pela comunidade. Os principais marcos e iniciativas planejadas incluem:

• Lançamento da Mainnet (3º trimestre de 2024) – A Enso lançou sua rede principal no segundo semestre de 2024. Isso envolveu a implantação da cadeia baseada em Tendermint e a inicialização do ecossistema de Validadores. Os primeiros validadores provavelmente foram permissionados ou parceiros selecionados enquanto a rede se inicializava. O lançamento da mainnet permitiu que consultas de usuários reais fossem processadas pelo motor da Enso (antes disso, os serviços da Enso eram acessíveis através de uma API centralizada enquanto em beta). Este marco marcou a transição da Enso de uma plataforma interna para uma rede pública descentralizada.

• Expansão de Participantes da Rede (4º trimestre de 2024) – Após a mainnet, o foco mudou para a descentralização da participação. No final de 2024, a Enso abriu funções para Provedores de Ações e Graphers externos. Isso incluiu o lançamento de ferramentas e documentação para que os desenvolvedores criassem suas próprias Ações (adaptadores de contratos inteligentes) e para que os desenvolvedores de algoritmos executassem nós Grapher. Podemos inferir que programas de incentivo ou competições de testnet foram usados para atrair esses participantes. Até o final de 2024, a Enso pretendia ter um conjunto mais amplo de ações de terceiros em sua biblioteca e múltiplos Graphers competindo em intenções, indo além dos algoritmos internos da equipe principal. Este foi um passo crucial para garantir que a Enso não seja um serviço centralizado, mas uma verdadeira rede aberta onde qualquer um pode contribuir e ganhar tokens ENSO.

• Expansão Cross-Chain (1º trimestre de 2025) – A Enso reconhece que suportar muitas blockchains é fundamental para sua proposta de valor. No início de 2025, o roadmap visava a integração com novos ambientes de blockchain além do conjunto inicial de EVM. Especificamente, a Enso planejou suporte para Monad, Solana e Movement até o primeiro trimestre de 2025. Monad é uma futura cadeia de alto desempenho compatível com EVM (apoiada pela Dragonfly Capital) – apoiá-la cedo poderia posicionar a Enso como o middleware de referência lá. A integração com Solana é mais desafiadora (runtime e linguagem diferentes), mas o motor de intenções da Enso poderia funcionar com a Solana usando graphers off-chain para formular transações Solana e programas on-chain atuando como adaptadores. Movement refere-se a cadeias de linguagem Move (talvez Aptos/Sui ou uma específica chamada Movement). Ao incorporar cadeias baseadas em Move, a Enso cobriria um amplo espectro de ecossistemas (Solidity e Move, bem como os rollups existentes do Ethereum). Alcançar essas integrações significa desenvolver novos módulos de Ação que entendam as chamadas CPI da Solana ou os scripts de transação da Move, e provavelmente colaborar com esses ecossistemas para oráculos/indexação. A menção da Enso em atualizações sugere que esses planos estavam em andamento – por exemplo, uma atualização da comunidade destacou parcerias ou subsídios (a menção de “Eclipse mainnet live + Movement grant” em um resultado de pesquisa sugere que a Enso estava trabalhando ativamente com L1s inovadoras como Eclipse e Movement no início de 2025).

• Curto Prazo (Meados/Final de 2025) – Embora não explicitamente detalhado no roadmap de uma página, em meados de 2025 o foco da Enso está na maturidade e descentralização da rede. A conclusão da venda de tokens na CoinList em junho de 2025 é um evento importante: os próximos passos seriam a geração e distribuição de tokens (esperadas por volta de julho de 2025) e o lançamento em exchanges ou fóruns de governança. Antecipamos que a Enso implementará seu processo de governança (Propostas de Melhoria da Enso, votação on-chain) para que a comunidade possa começar a participar das decisões usando seus tokens recém-adquiridos. Além disso, a Enso provavelmente passará de “beta” para um serviço totalmente pronto para produção, se ainda não o fez. Parte disso será o reforço da segurança – realizando múltiplas auditorias de contratos inteligentes e talvez executando um programa de bug bounty, considerando os grandes TVLs envolvidos.

• Estratégias de Crescimento do Ecossistema: A Enso está fomentando ativamente um ecossistema em torno de sua rede. Uma estratégia tem sido a execução de programas educacionais e hackathons (por exemplo, o Shortcut Speedrun e workshops) para integrar desenvolvedores à maneira de construir da Enso. Outra estratégia é fazer parceria com novos protocolos no lançamento – vimos isso com a Berachain, a campanha da zkSync e outros. A Enso provavelmente continuará com isso, atuando efetivamente como um “parceiro de lançamento on-chain” para redes emergentes ou projetos DeFi, cuidando de seus complexos fluxos de integração de usuários. Isso não apenas impulsiona o volume da Enso (como visto com a Berachain), mas também integra a Enso profundamente nesses ecossistemas. Esperamos que a Enso anuncie integrações com mais redes de Camada 2 (por exemplo, Arbitrum, Optimism presumivelmente já eram suportadas; talvez as mais novas como Scroll ou Starknet em seguida) e outras L1s (Polkadot via XCM, Cosmos via IBC ou Osmosis, etc.). A visão de longo prazo é que a Enso se torne onipresente em todas as cadeias – qualquer desenvolvedor em qualquer cadeia pode se conectar. Para esse fim, a Enso também pode desenvolver uma melhor execução cross-chain sem pontes (usando técnicas como trocas atômicas ou execução otimista de intenções entre cadeias), o que poderia estar no roadmap de P&D para além de 2025.

• Perspectivas Futuras: Olhando mais adiante, a equipe da Enso deu a entender o envolvimento de agentes de IA como participantes da rede. Isso sugere um futuro onde não apenas desenvolvedores humanos, mas bots de IA (talvez treinados para otimizar estratégias DeFi) se conectam à Enso para fornecer serviços. A Enso pode construir essa visão criando SDKs ou frameworks para que agentes de IA interajam com segurança com o motor de intenções – um desenvolvimento potencialmente inovador que une IA e automação de blockchain. Além disso, até o final de 2025 ou 2026, antecipamos que a Enso trabalhará no escalonamento de desempenho (talvez fragmentando sua rede ou usando provas de conhecimento zero para validar a correção da execução de intenções em escala) à medida que o uso cresce.

O roadmap é ambicioso, mas a execução até agora tem sido forte – a Enso atingiu marcos importantes como o lançamento da mainnet e a entrega de casos de uso reais. Um marco importante que se aproxima é a descentralização total da rede. Atualmente, a rede está em transição: a documentação observa que a rede descentralizada está em testnet e uma API centralizada estava sendo usada para produção no início de 2025. A esta altura, com a mainnet ativa e o token em circulação, a Enso buscará eliminar quaisquer componentes centralizados. Para os investidores, acompanhar esse progresso de descentralização (por exemplo, número de validadores independentes, Graphers da comunidade se juntando) será fundamental para avaliar a maturidade da Enso.

Em resumo, o roadmap da Enso foca em escalar o alcance da rede (mais cadeias, mais integrações) e escalar a comunidade da rede (mais participantes de terceiros e detentores de tokens). O objetivo final é cimentar a Enso como infraestrutura crítica na Web3, assim como a Infura se tornou essencial para a conectividade de dApps ou como The Graph se tornou integral para a consulta de dados. Se a Enso conseguir atingir seus marcos, o segundo semestre de 2025 deve ver um ecossistema florescente em torno da Enso Network, potencialmente impulsionando um crescimento exponencial no uso.

Avaliação de Risco​

Como qualquer protocolo em estágio inicial, a Enso Network enfrenta uma série de riscos e desafios que os investidores devem considerar cuidadosamente:

• Riscos Técnicos e de Segurança: O sistema da Enso é inerentemente complexo – ele interage com uma miríade de contratos inteligentes em muitas blockchains através de uma rede de solucionadores e validadores off-chain. Essa superfície de ataque expansiva introduz risco técnico. Cada nova Ação (integração) pode carregar vulnerabilidades; se a lógica de uma Ação for falha ou um provedor malicioso introduzir uma Ação com backdoor, os fundos dos usuários podem estar em risco. Garantir que cada integração seja segura exigiu um investimento substancial (a equipe da Enso gastou mais de $500k em auditorias para integrar 15 protocolos em seus primórdios). À medida que a biblioteca cresce para centenas de protocolos, manter auditorias de segurança rigorosas é um desafio. Há também o risco de bugs na lógica de coordenação da Enso – por exemplo, uma falha em como os Graphers compõem transações ou como os Validadores as verificam poderia ser explorada. A execução cross-chain, em particular, pode ser arriscada: se uma sequência de ações abrange múltiplas cadeias e uma parte falha ou é censurada, isso pode deixar os fundos de um usuário no limbo. Embora a Enso provavelmente use tentativas repetidas ou trocas atômicas em alguns casos, a complexidade das intenções significa que modos de falha desconhecidos podem surgir. O próprio modelo baseado em intenções é relativamente não comprovado em escala – pode haver casos extremos em que o motor produz uma solução incorreta ou um resultado que diverge da intenção do usuário. Qualquer exploração ou falha de alto perfil poderia minar a confiança em toda a rede. A mitigação requer auditorias de segurança contínuas, um programa robusto de bug bounty e talvez mecanismos de seguro para os usuários (nenhum dos quais foi detalhado ainda).

• Riscos de Descentralização e Operacionais: Atualmente (meados de 2025), a rede Enso ainda está em processo de descentralização de seus participantes. Isso significa que pode haver centralização operacional não visível – por exemplo, a infraestrutura da equipe ainda pode estar coordenando grande parte da atividade, ou apenas alguns validadores/graphers estão genuinamente ativos. Isso apresenta dois riscos: confiabilidade (se os servidores da equipe principal caírem, a rede irá parar?) e confiança (se o processo ainda não for totalmente sem confiança, os usuários devem ter fé na Enso Inc. para não antecipar ou censurar transações). A equipe provou confiabilidade em grandes eventos (como lidar com um volume de $3 bilhões em dias), mas à medida que o uso cresce, escalar a rede através de mais nós independentes será crucial. Há também o risco de que os participantes da rede não apareçam – se a Enso não conseguir atrair Provedores de Ações ou Graphers qualificados o suficiente, a rede pode permanecer dependente da equipe principal, limitando a descentralização. Isso poderia retardar a inovação e também concentrar muito poder (e recompensas de token) em um pequeno grupo, o oposto do design pretendido.

• Riscos de Mercado e Adoção: Embora a Enso tenha uma adoção inicial impressionante, ela ainda está em um mercado nascente para infraestrutura “baseada em intenções”. Existe o risco de que a comunidade de desenvolvedores em geral seja lenta para adotar esse novo paradigma. Desenvolvedores entrincheirados em práticas de codificação tradicionais podem hesitar em depender de uma rede externa para funcionalidades essenciais, ou podem preferir soluções alternativas. Além disso, o sucesso da Enso depende do crescimento contínuo dos ecossistemas DeFi e multi-cadeia. Se a tese multi-cadeia falhar (por exemplo, se a maior parte da atividade se consolidar em uma única cadeia dominante), a necessidade das capacidades cross-chain da Enso pode diminuir. Por outro lado, se um novo ecossistema surgir e a Enso não conseguir integrá-lo rapidamente, os projetos nesse ecossistema não usarão a Enso. Essencialmente, manter-se atualizado com cada nova cadeia e protocolo é um desafio sem fim – perder ou atrasar uma integração importante (digamos, um novo DEX popular ou uma Camada 2) poderia empurrar os projetos para concorrentes ou código personalizado. Além disso, o uso da Enso poderia ser prejudicado por condições macroeconômicas do mercado; em uma grave crise DeFi, menos usuários e desenvolvedores podem estar experimentando novos dApps, reduzindo diretamente as intenções enviadas à Enso e, assim, as taxas/receita da rede. O valor do token poderia sofrer em tal cenário, potencialmente tornando o staking menos atraente e enfraquecendo a segurança ou a participação na rede.

• Concorrência: Como discutido, a Enso enfrenta concorrência em várias frentes. Um grande risco é um player maior entrando no espaço de execução de intenções. Por exemplo, se um projeto bem financiado como a Chainlink introduzisse um serviço de intenção semelhante, aproveitando sua rede de oráculos existente, eles poderiam rapidamente ofuscar a Enso devido à confiança na marca e às integrações. Da mesma forma, empresas de infraestrutura (Alchemy, Infura) poderiam construir SDKs multi-cadeia simplificados que, embora não descentralizados, capturam o mercado de desenvolvedores com conveniência. Há também o risco de cópias de código aberto: os conceitos centrais da Enso (Ações, Graphers) poderiam ser replicados por outros, talvez até como um fork da Enso se o código for público. Se um desses projetos formar uma comunidade forte ou encontrar um incentivo de token melhor, ele poderá desviar participantes em potencial. A Enso precisará manter a liderança tecnológica (por exemplo, tendo a maior biblioteca de Ações e os solucionadores mais eficientes) para se defender da concorrência. A pressão competitiva também poderia espremer o modelo de taxas da Enso – se um rival oferecer serviços semelhantes mais baratos (ou gratuitos, subsidiados por VCs), a Enso pode ser forçada a baixar as taxas ou aumentar os incentivos de token, o que poderia sobrecarregar sua tokenomics.

• Riscos Regulatórios e de Conformidade: A Enso opera no espaço de infraestrutura DeFi, que é uma área cinzenta em termos de regulamentação. Embora a Enso em si não custodie os fundos dos usuários (os usuários executam intenções de suas próprias carteiras), a rede automatiza transações financeiras complexas entre protocolos. Existe a possibilidade de que os reguladores possam ver os motores de composição de intenções como facilitadores de atividades financeiras não licenciadas ou até mesmo como auxílio à lavagem de dinheiro se usados para transferir fundos entre cadeias de maneiras obscuras. Preocupações específicas podem surgir se a Enso permitir trocas cross-chain que toquem em pools de privacidade ou jurisdições sob sanções. Além disso, o token ENSO e sua venda na CoinList refletem uma distribuição para uma comunidade global – reguladores (como a SEC nos EUA) podem examiná-lo como uma oferta de valores mobiliários (notavelmente, a Enso excluiu EUA, Reino Unido, China, etc., da venda, indicando cautela nesse aspecto). Se o ENSO fosse considerado um valor mobiliário em jurisdições importantes, isso poderia limitar as listagens em exchanges ou o uso por entidades reguladas. A rede descentralizada de validadores da Enso também pode enfrentar problemas de conformidade: por exemplo, um validador poderia ser forçado a censurar certas transações devido a ordens legais? Isso é em grande parte hipotético por enquanto, mas à medida que o valor fluindo através da Enso cresce, a atenção regulatória aumentará. A base da equipe na Suíça pode oferecer um ambiente regulatório relativamente amigável para cripto, mas as operações globais significam riscos globais. Mitigar isso provavelmente envolve garantir que a Enso seja suficientemente descentralizada (para que nenhuma entidade única seja responsável) e possivelmente geofencing de certos recursos, se necessário (embora isso seja contra o ethos do projeto).

• Sustentabilidade Econômica: O modelo da Enso assume que as taxas geradas pelo uso recompensarão suficientemente todos os participantes. Existe o risco de que os incentivos de taxas possam não ser suficientes para sustentar a rede, especialmente no início. Por exemplo, Graphers e Validadores incorrem em custos (infraestrutura, tempo de desenvolvimento). Se as taxas de consulta forem muito baixas, esses participantes podem não lucrar, levando-os a abandonar a rede. Por outro lado, se as taxas forem muito altas, os dApps podem hesitar em usar a Enso e procurar alternativas mais baratas. Encontrar um equilíbrio é difícil em um mercado de dois lados. A economia do token Enso também depende do valor do token até certo ponto – por exemplo, as recompensas de staking são mais atraentes quando o token tem alto valor, e os Provedores de Ações ganham valor em ENSO. Uma queda acentuada no preço do ENSO poderia reduzir a participação na rede ou levar a mais vendas (o que deprime ainda mais o preço). Com uma grande parte dos tokens detida por investidores e pela equipe (mais de 56% combinados, com vesting ao longo de 2 anos), há um risco de excesso de oferta: se esses stakeholders perderem a fé ou precisarem de liquidez, suas vendas poderiam inundar o mercado após o vesting e minar o preço do token. A Enso tentou mitigar a concentração com a venda para a comunidade, mas ainda é uma distribuição de tokens relativamente centralizada no curto prazo. A sustentabilidade econômica dependerá do crescimento do uso genuíno da rede a um nível em que a receita de taxas forneça rendimento suficiente para os stakers e contribuidores de tokens – essencialmente tornando a Enso um protocolo gerador de fluxo de caixa em vez de apenas um token especulativo. Isso é alcançável (pense em como as taxas do Ethereum recompensam mineradores/validadores), mas apenas se a Enso alcançar uma adoção generalizada. Até lá, há uma dependência dos fundos do tesouro (15% alocados) para incentivar e talvez para ajustar os parâmetros econômicos (a governança da Enso pode introduzir inflação ou outras recompensas, se necessário, o que poderia diluir os detentores).

Resumo do Risco: A Enso está desbravando um novo terreno, o que acarreta um risco proporcional. A complexidade tecnológica de unificar todo o DeFi em uma única rede é enorme – cada blockchain adicionada ou protocolo integrado é um ponto potencial de falha que deve ser gerenciado. A experiência da equipe em navegar por contratempos anteriores (como o sucesso limitado do produto inicial de social trading) mostra que eles estão cientes das armadilhas e se adaptam rapidamente. Eles mitigaram ativamente alguns riscos (por exemplo, descentralizando a propriedade através da rodada da comunidade para evitar uma governança excessivamente impulsionada por VCs). Os investidores devem observar como a Enso executa a descentralização e se continua a atrair talentos técnicos de primeira linha para construir e proteger a rede. No melhor cenário, a Enso poderia se tornar uma infraestrutura indispensável em toda a Web3, gerando fortes efeitos de rede e acúmulo de valor do token. No pior cenário, contratempos técnicos ou de adoção poderiam relegá-la a ser uma ferramenta ambiciosa, mas de nicho.

Do ponto de vista de um investidor, a Enso oferece um perfil de alto risco e alto potencial de retorno. Seu status atual (meados de 2025) é o de uma rede promissora com uso real e uma visão clara, mas agora ela deve fortalecer sua tecnologia e superar um cenário competitivo e em evolução. A devida diligência sobre a Enso deve incluir o monitoramento de seu histórico de segurança, o crescimento dos volumes/taxas de consulta ao longo do tempo e a eficácia com que o modelo do token ENSO incentiva um ecossistema autossustentável. No momento, o ímpeto está a favor da Enso, mas uma gestão de risco prudente e inovação contínua serão fundamentais para transformar essa liderança inicial em domínio de longo prazo no espaço de middleware Web3.

Fontes:

• Documentação Oficial da Enso Network e Materiais da Venda de Tokens

  • Página da Venda de Tokens na CoinList – Destaques e Investidores
  • Documentação da Enso – Tokenomics e Funções da Rede

• Entrevistas e Cobertura da Mídia

  • Entrevista do CryptoPotato com o CEO da Enso (Junho de 2025) – Histórico da evolução da Enso e design baseado em intenções
  • DL News (Maio de 2025) – Visão geral dos atalhos da Enso e da abordagem de estado compartilhado

• Análises da Comunidade e de Investidores

  • Hackernoon (I. Pandey, 2025) – Insights sobre a rodada da comunidade da Enso e a estratégia de distribuição de tokens
  • CryptoTotem / CoinLaunch (2025) – Detalhamento do fornecimento de tokens e cronograma do roadmap

• Métricas do Site Oficial da Enso (2025) e Comunicados de Imprensa – Números de adoção e exemplos de casos de uso (migração da Berachain, colaboração com a Uniswap).

Visão Geral​

Aptos e Sui se apresentam como a próxima geração de blockchains Layer-1, ambas originárias da linguagem Move inicialmente concebida pelo projeto Libra/Diem da Meta. Embora compartilhem uma linhagem comum, seus históricos de equipe, objetivos centrais, estratégias de ecossistema e caminhos evolutivos divergiram significativamente.

Aptos enfatiza versatilidade e desempenho de nível empresarial, visando tanto casos de uso DeFi quanto institucionais. Em contraste, Sui está focada em otimizar seu modelo de objeto único para impulsionar aplicações de consumo em massa, particularmente em jogos, NFTs e redes sociais. Qual cadeia se distinguirá finalmente dependerá de sua capacidade de evoluir a tecnologia para atender às demandas de seu nicho de mercado escolhido, ao mesmo tempo em que estabelece uma vantagem clara em experiência do usuário e facilidade para desenvolvedores.

1. Jornada de Desenvolvimento​

Aptos​

Nascida da Aptos Labs — uma equipe formada por ex‑funcionários da Meta Libra/Diem — Aptos iniciou testes fechados no final de 2021 e lançou sua mainnet em 19 de outubro de 2022. O desempenho inicial da mainnet gerou ceticismo na comunidade, com menos de 20 TPS, conforme notado pela WIRED, mas iterações subsequentes nas camadas de consenso e execução elevaram gradualmente seu throughput para dezenas de milhares de TPS.

Até o segundo trimestre de 2025, Aptos atingiu um pico de 44,7 milhões de transações em uma única semana, com endereços ativos semanais ultrapassando 4 milhões. A rede cresceu para mais de 83 milhões de contas cumulativas, com volume diário de negociação DeFi consistentemente acima de US$ 200 milhões (Fonte: Aptos Forum).

Sui​

Iniciada pela Mysten Labs, cujos fundadores eram membros centrais da equipe da carteira Novi da Meta, Sui lançou sua testnet incentivada em agosto de 2022 e entrou em operação na mainnet em 3 de maio de 2023. Desde as primeiras testnets, a equipe priorizou o refinamento de seu “modelo de objeto”, que trata ativos como objetos com propriedade e controles de acesso específicos para melhorar o processamento paralelo de transações (Fonte: Ledger).

Em meados de julho de 2025, o Total Value Locked (TVL) do ecossistema Sui alcançou US$ 2,326 bilhões. A plataforma viu crescimento rápido no volume mensal de transações e no número de engenheiros ativos, mostrando especial popularidade nos setores de jogos e NFTs (Fonte: AInvest, Tangem).

2. Comparação de Arquitetura Técnica​

3. Ecossistema On‑Chain e Casos de Uso​

3.1 Escala e Crescimento do Ecossistema​

Aptos No primeiro trimestre de 2025, Aptos registrou quase 15 milhões de usuários ativos mensais e aproximou‑se de 1 milhão de carteiras ativas diárias. Seu volume de negociação DeFi disparou 1000 % ano a ano, consolidando‑se como um hub para stablecoins e derivativos de grau financeiro (Fonte: Coinspeaker). Movimentos estratégicos incluem a integração do USDT via Upbit para impulsionar penetração nos mercados asiáticos e a atração de diversas DEXs, protocolos de empréstimo e plataformas de derivativos (Fonte: Aptos Forum).

Sui Em junho de 2025, o TVL do ecossistema Sui atingiu um novo recorde de US$ 2,326 bilhões, impulsionado principalmente por projetos sociais, de jogos e NFTs de alta interação (Fonte: AInvest). O ecossistema é definido por projetos centrais como marketplaces de objetos, pontes Layer‑2, carteiras sociais e SDKs de motores de jogo, que atraíram um grande número de desenvolvedores Web3 de jogos e detentores de IP.

3.2 Casos de Uso Dominantes​

• DeFi & Integração Empresarial (Aptos): Com sua finalização BFT madura e um conjunto rico de ferramentas financeiras, Aptos está mais bem posicionada para stablecoins, empréstimos e derivativos — cenários que exigem altos níveis de consistência e segurança.
• Jogos & NFTs (Sui): A vantagem de execução paralela da Sui é clara aqui. Sua latência baixa e taxas quase nulas são ideais para interações de alta concorrência e baixo valor típicas de jogos, como abertura de loot boxes ou transferência de itens in‑game.

4. Evolução & Estratégia​

Aptos

• Otimização de Performance: Continuação da pesquisa em sharding, planejamento de liquidez cross‑chain multirregional e atualização do AptosVM para melhorar a eficiência de acesso ao estado.
• Incentivos ao Ecossistema: Um fundo de centenas de milhões de dólares foi criado para apoiar infraestrutura DeFi, pontes cross‑chain e aplicações empresariais em conformidade.
• Interoperabilidade Cross‑Chain: Fortalecimento de integrações com pontes como Wormhole e construção de conexões com Cosmos (via IBC) e Ethereum.

Sui

• Iteração do Modelo de Objeto: Expansão da sintaxe Move para suportar tipos de objeto customizados e gerenciamento complexo de permissões, ao mesmo tempo otimizando o algoritmo de agendamento paralelo.
• Impulsionar Adoção de Consumidores: Busca de integrações profundas com motores de jogo como Unreal e Unity para reduzir barreiras ao desenvolvimento de jogos Web3, além do lançamento de plugins sociais e SDKs.
• Governança Comunitária: Promoção do SuiDAO para capacitar comunidades de projetos centrais com capacidades de governança, permitindo iteração rápida em recursos e modelos de taxas.

5. Diferenças Principais & Desafios​

• Segurança vs. Paralelismo: A semântica estrita de recursos e o consenso consistente da Aptos oferecem segurança de nível DeFi, mas podem limitar o paralelismo. O modelo altamente paralelo da Sui precisa provar continuamente sua resiliência contra ameaças de segurança em larga escala.
• Profundidade vs. Amplitude do Ecossistema: Aptos cultivou raízes profundas no setor financeiro com fortes laços institucionais. Sui acumulou rapidamente uma gama ampla de projetos voltados ao consumidor, mas ainda não alcançou um breakthrough decisivo em DeFi de grande escala.
• Desempenho Teórico vs. Throughput Real: Embora a Sui tenha TPS teórico maior, seu throughput real ainda é limitado pela atividade do ecossistema. Aptos também experimentou congestionamento em períodos de pico, indicando necessidade de sharding mais eficaz ou soluções Layer‑2.
• Narrativa de Mercado & Posicionamento: Aptos se promove como segurança e estabilidade de grau empresarial, mirando finanças tradicionais e indústrias reguladas. Sui utiliza o apelo de uma “experiência semelhante ao Web2” e “onboarding sem atrito” para atrair um público consumidor mais amplo.

6. O Caminho para a Adoção em Massa​

Em última análise, não se trata de um jogo de soma zero.

No médio a longo prazo, se o mercado consumidor (jogos, social, NFTs) continuar seu crescimento explosivo, a execução paralela da Sui e a baixa barreira de entrada podem posicioná‑la para adoção rápida entre dezenas de milhões de usuários mainstream.

No curto a médio prazo, a finalização BFT madura da Aptos, suas taxas baixas e parcerias estratégicas oferecem uma proposta mais atraente para finanças institucionais, DeFi focado em compliance e pagamentos transfronteiriços.

O futuro tende a ser simbiótico, com as duas cadeias coexistindo e criando um mercado estratificado: Aptos alimentando infraestrutura financeira e empresarial, enquanto Sui domina interações de alta frequência voltadas ao consumidor. A cadeia que alcançar a adoção em massa será aquela que otimizar incansavelmente desempenho e experiência do usuário dentro de seu domínio escolhido.

Introdução​

Rollups-as-a-Service (RaaS) e estruturas de blockchain modulares tornaram-se cruciais em 2025 para escalar o Ethereum e construir blockchains personalizadas. As principais estruturas – OP Stack da Optimism, ZK Stack da zkSync (Hyperchains), Arbitrum Orbit, Chain Development Kit (CDK) da Polygon e soluções relacionadas – permitem que os desenvolvedores lancem suas próprias chains de Camada-2 (L2) ou Camada-3 (L3) com abordagens variadas (otimista vs. zero-knowledge). Essas estruturas compartilham uma filosofia de modularidade: elas separam preocupações como execução, liquidação, disponibilidade de dados e consenso, permitindo a personalização de cada componente. Este relatório compara as estruturas em dimensões-chave – opções de disponibilidade de dados, design do sequenciador, modelos de taxas, suporte do ecossistema – e examina sua arquitetura, ferramentas, experiência do desenvolvedor e adoção atual em contextos públicos e empresariais.

Visão Geral da Comparação​

A tabela abaixo resume várias características principais de cada estrutura:

Tabela: Comparação de alto nível das principais características técnicas do OP Stack, ZK Stack da zkSync, Arbitrum Orbit e Polygon CDK.

Camadas de Disponibilidade de Dados​

A Disponibilidade de Dados (DA) é onde os rollups armazenam seus dados de transação para que qualquer pessoa possa reconstruir o estado da chain. Todas essas estruturas suportam o uso do Ethereum L1 como DA (postando calldata ou dados de blob no Ethereum para segurança máxima). No entanto, para reduzir custos, elas também permitem soluções de DA alternativas:

• OP Stack: Por padrão, as chains OP publicam dados no Ethereum (como calldata ou blobs). Graças a uma interface modular “Alt-DA”, as chains OP Stack podem se conectar a outras camadas de DA facilmente. Por exemplo, uma chain OP poderia usar a Celestia (uma blockchain dedicada a DA) em vez do Ethereum. Em 2023, a OP Labs e a Celestia lançaram uma versão beta onde um rollup OP Stack se liquida no Ethereum, mas armazena dados em massa na Celestia. Isso reduz as taxas enquanto herda as garantias de disponibilidade de dados da Celestia. Em geral, qualquer chain EVM ou não-EVM – até mesmo o Bitcoin ou um armazenamento centralizado – pode ser configurada como a camada de DA no OP Stack. (Claro, usar uma DA menos segura troca um pouco de segurança por custo.) O Ethereum continua sendo a escolha predominante para as chains OP em produção, mas projetos como a testnet Taro da Caldera demonstraram o OP Stack com DA da Celestia.

• ZK Stack (zkSync Hyperchains): O ZK Stack oferece os modos rollup e validium. No modo rollup, todos os dados estão on-chain (Ethereum). No modo validium, os dados são mantidos off-chain (com apenas provas de validade on-chain). A Matter Labs está integrando Avail, Celestia e EigenDA como opções de DA de primeira classe para as chains ZK Stack. Isso significa que uma Hyperchain zkSync poderia postar dados de transação na Celestia ou em uma rede alimentada pelo EigenLayer em vez da L1, aumentando massivamente o throughput. Eles até descrevem a volition, onde uma chain pode decidir por transação se a tratará como um rollup (dados on-chain) ou validium (off-chain). Essa flexibilidade permite que os desenvolvedores equilibrem segurança e custo. Por exemplo, uma hyperchain de jogos pode usar a Celestia para armazenar dados de forma barata, enquanto confia no Ethereum para provas periódicas. O design do ZK Stack torna a DA conectável através de um componente cliente/despachante de DA no software do nó. No geral, o Ethereum continua sendo o padrão, mas o ecossistema da zkSync enfatiza fortemente a DA modular para alcançar um throughput de “hiperescala”.

• Arbitrum Orbit: As chains Orbit podem escolher entre os dois modos de dados da Arbitrum: rollup (dados postados no Ethereum) ou AnyTrust (comitê de disponibilidade de dados). Na configuração Rollup, uma L3 Orbit postará seus dados de chamada na L2 (Arbitrum One ou Nova) ou na L1, herdando segurança total a um custo mais alto. No modo AnyTrust, os dados são mantidos off-chain por um comitê (como usado na Arbitrum Nova, que usa um Comitê de Disponibilidade de Dados). Isso reduz muito as taxas para aplicativos de alto volume (jogos, redes sociais) ao custo de confiar em um comitê (se todos os membros do comitê conspirarem para reter os dados, a chain poderia parar). Além disso, a Arbitrum também está se integrando com redes de DA modulares emergentes. Notavelmente, Celestia e Polygon Avail são suportadas para chains Orbit como camadas de DA alternativas. Projetos como o AltLayer trabalharam em rollups Orbit que usam EigenDA (o serviço de DA do EigenLayer) também. Em resumo, o Arbitrum Orbit oferece disponibilidade de dados flexível: on-chain via Ethereum, off-chain via DACs ou chains de DA especializadas, ou híbridos. Muitos adotantes do Orbit escolhem o AnyTrust para economizar custos, especialmente se tiverem um conjunto conhecido de validadores ou parceiros garantindo que os dados estejam disponíveis.

• Polygon CDK: O CDK da Polygon é inerentemente modular em relação à DA. Uma chain Polygon CDK pode operar como um rollup (todos os dados no Ethereum) ou um validium (dados em uma rede separada). A Polygon tem sua própria solução de DA chamada Avail (uma blockchain para disponibilidade de dados), e as chains CDK podem usar o Avail ou qualquer serviço similar. No final de 2024, a Polygon anunciou a integração direta da Celestia no CDK – tornando a Celestia uma opção de DA “facilmente conectável” no kit de ferramentas. Essa integração é esperada para o início de 2024, permitindo que as chains CDK armazenem dados compactados na Celestia de forma transparente. A Polygon cita que o uso da Celestia poderia reduzir as taxas de transação em mais de 100x em comparação com a postagem de todos os dados no Ethereum. Assim, um criador de chain CDK pode simplesmente alternar o módulo de DA para a Celestia (ou Avail) em vez do Ethereum. Algumas chains da Polygon (ex: Polygon zkEVM) atualmente postam todos os dados no Ethereum (para segurança máxima), enquanto outras (talvez certas chains empresariais) rodam como validiums com DA externa. O CDK suporta modos “híbridos” também – por exemplo, transações críticas poderiam ir para o Ethereum enquanto outras vão para o Avail. Essa abordagem de DA modular está alinhada com a visão mais ampla da Polygon 2.0 de múltiplas chains alimentadas por ZK com liquidez unificada, mas com backends de dados variados.

Em resumo, todas as estruturas suportam múltiplas camadas de DA em vários graus. O Ethereum continua sendo o padrão ouro de DA (especialmente com o espaço de blob do EIP-4844 tornando os dados on-chain mais baratos), mas novas redes de DA especializadas (Celestia, Avail) e esquemas (EigenDA do EigenLayer, comitês de dados) estão sendo adotados em todos os âmbitos. Essa modularidade permite que os criadores de rollups em 2025 façam trocas entre custo e segurança simplesmente configurando um módulo de DA diferente, em vez de construir uma nova chain do zero.

Design do Sequenciador e Descentralização​

O sequenciador é o nó (ou conjunto de nós) que ordena as transações e produz blocos para um rollup. Como o sequenciador é projetado – centralizado vs. descentralizado, com permissão vs. sem permissão – afeta o throughput e as suposições de confiança da chain:

• OP Stack (Optimism): Hoje, a maioria das chains OP Stack executa um único sequenciador operado pela equipe principal ou patrocinador da chain. Por exemplo, o sequenciador da Mainnet da Optimism é operado pela OP Labs, e o sequenciador da Base é operado pela Coinbase. Isso resulta em baixa latência e simplicidade ao custo da centralização (os usuários devem confiar no sequenciador para incluir suas transações de forma justa). No entanto, a Optimism incorporou mecanismos para minimizar a confiança: existe um contrato de fila de transações L1 onde os usuários podem enviar transações no Ethereum que o sequenciador deve incluir na chain L2. Se o sequenciador cair ou censurar transações, os usuários podem contar com a L1 para eventualmente serem incluídos (embora com algum atraso). Isso fornece uma válvula de segurança contra um sequenciador malicioso ou com falha. Em termos de descentralização, o OP Stack é modular e teoricamente permite múltiplos sequenciadores – por exemplo, pode-se implementar um conjunto de proponentes de blocos baseado em round-robin ou prova de participação usando o código do OP Stack. Na prática, isso requer personalização e não é a configuração padrão. O roteiro de longo prazo da Superchain prevê um sequenciador compartilhado para todas as OP Chains, que seria um conjunto de validadores sequenciando transações para muitas chains ao mesmo tempo. Um sequenciador compartilhado poderia permitir atomicidade entre chains e reduzir o MEV em toda a Superchain. Ainda está em desenvolvimento em 2025, mas o design do OP Stack não impede a conexão de tal consenso. Por enquanto, as operações do sequenciador permanecem permissionadas (executadas por entidades na lista de permissões), mas a governança da Optimism planeja descentralizar isso (possivelmente via staking ou rotação de comitê) assim que a tecnologia e a economia estiverem prontas. Em resumo: as chains OP Stack começam com sequenciamento centralizado (com a L1 como fallback), e um caminho para a descentralização gradual está traçado (passando da maturidade “Estágio 0” para “Estágio 2” sem rodinhas de apoio).

• ZK Stack (zkSync Hyperchains): O zkSync Era (a L2) atualmente usa um sequenciador centralizado operado pela Matter Labs. No entanto, o ZK Stack é construído para permitir vários modos de sequenciamento para novas chains. As opções incluem um sequenciador centralizado (início fácil), um conjunto de sequenciadores descentralizados (ex: múltiplos nós alcançando consenso sobre a ordenação), uma fila de transações prioritárias da L1, ou até mesmo um serviço de sequenciador externo. Na visão de Elastic Chains da Matter Labs, as chains permanecem independentes, mas a interoperabilidade é tratada pelos contratos L1 e um “Roteador/Gateway ZK” – isso implica que cada chain pode escolher seu próprio modelo de sequenciador, desde que atenda aos protocolos para enviar raízes de estado e provas. Como os ZK-rollups não exigem um consenso na L2 para segurança (provas de validade garantem a correção), descentralizar o sequenciador é mais sobre vivacidade e resistência à censura. Uma Hyperchain poderia implementar um produtor de blocos round-robin ou até mesmo se conectar a um consenso BFT de alto desempenho para seus sequenciadores, se desejado. Dito isso, executar um único sequenciador é muito mais simples e continua sendo a norma inicialmente. A documentação do ZK Stack menciona que uma chain poderia usar um “protocolo externo” para sequenciamento – por exemplo, pode-se imaginar usar o consenso Tendermint ou SU como produtor de blocos e depois gerar provas zk para os blocos. Além disso, como outros, o zkSync tem um mecanismo de fila de prioridade L1: os usuários podem enviar transações para o contrato zkSync com uma taxa de prioridade para garantir a inclusão L1->L2 em tempo hábil (mitigando a censura). No geral, a participação sem permissão no sequenciamento ainda não foi realizada nas chains zkSync (nenhum leilão público de slot ou seleção de sequenciador baseada em staking em produção), mas a arquitetura deixa espaço para isso. À medida que as provas de validade amadurecem, podemos ver chains zkSync com nós de sequenciador operados pela comunidade que decidem coletivamente a ordenação (uma vez que o desempenho permita).

• Arbitrum Orbit: No Arbitrum One (a L2 principal), o sequenciador é centralizado (operado pela Offchain Labs), embora a progressão do estado da chain seja, em última análise, governada pelos validadores da Arbitrum e pelas provas de fraude. A Arbitrum também forneceu uma fila L1 para os usuários como um backup contra problemas no sequenciador. No Orbit (a estrutura L3), cada chain Orbit pode ter seu próprio sequenciador ou conjunto de validadores. A tecnologia Nitro da Arbitrum inclui a opção de executar um rollup com um sequenciador descentralizado: essencialmente, pode-se ter várias partes executando o software do nó Arbitrum e usando uma eleição de líder (possivelmente através da chain de prova de participação sem permissão da Arbitrum no futuro, ou um mecanismo personalizado). Prontas para uso, as chains Orbit lançadas até o momento têm sido principalmente centralizadas (ex: a chain de jogos Xai é operada por uma fundação em colaboração com a Offchain Labs) – mas isso é uma questão de configuração e governança. Um desenvolvimento notável é a introdução do BoLD (Bounded Liquidity Delay) no início de 2025, que é um novo protocolo para tornar a validação da Arbitrum mais sem permissão. O BoLD permite que qualquer pessoa se torne um validador (provador) para a chain, resolvendo desafios de fraude em um prazo fixo sem uma lista de permissões. Isso aproxima a Arbitrum da operação sem confiança, embora o papel do sequenciador (ordenar transações no dia a dia) ainda possa ser atribuído ou eleito. A Offchain Labs expressou foco em avançar na descentralização em 2024-2025 para a Arbitrum. Também vemos esforços de multi-sequenciador: por exemplo, uma chain Orbit poderia usar um pequeno comitê de sequenciadores conhecidos para obter alguma tolerância a falhas (um cai, outro continua). Outro ângulo é a ideia de um sequenciador compartilhado para chains Orbit, embora a Arbitrum não tenha enfatizado isso tanto quanto a Optimism. Em vez disso, a interoperabilidade é alcançada através de L3s que se liquidam na L2 da Arbitrum e usam pontes padrão. Em resumo, o Arbitrum Orbit oferece flexibilidade no design do sequenciador (de uma entidade para muitas), e a tendência é para abrir o conjunto de validadores/sequenciadores à medida que a tecnologia e a governança da comunidade amadurecem. Hoje, é justo dizer que as chains Orbit começam centralizadas, mas têm um roteiro para validação sem permissão.

• Polygon CDK: As chains Polygon CDK (às vezes referidas sob o guarda-chuva “AggLayer” no final de 2024) podem escolher de forma semelhante sua configuração de sequenciador/consenso. A chain zkEVM da Polygon (operada pela Polygon Labs) começou com um único sequenciador e provador centralizado, com planos de descentralizar progressivamente ambos. O CDK, sendo modular, permite que uma chain conecte um módulo de consenso – por exemplo, pode-se lançar uma chain CDK com um conjunto de validadores de Prova de Participação produzindo blocos, descentralizando efetivamente o sequenciamento desde o primeiro dia. De fato, a estrutura anterior da Polygon (Polygon Edge) foi usada para chains empresariais permissionadas usando consenso IBFT; as chains CDK poderiam adotar uma abordagem híbrida (executar o zkProver da Polygon, mas ter um comitê de nós propondo blocos). Por padrão, muitas chains CDK podem ser executadas com um único operador por simplicidade e, posteriormente, adotar um consenso à medida que escalam. A Polygon também está explorando um conceito de sequenciador ou agregador compartilhado através do hub AggLayer, que se destina a conectar todas as chains da Polygon. Embora o AggLayer lide principalmente com mensagens entre chains e liquidez, ele pode evoluir para um serviço de sequenciamento compartilhado no futuro (o cofundador da Polygon discutiu a descentralização do sequenciador como parte da Polygon 2.0). Em geral, a falta de permissão ainda não está presente – não se pode tornar espontaneamente um sequenciador para a chain CDK de alguém, a menos que esse projeto permita. Mas projetos como o dYdX V4 (que está construindo uma chain autônoma com uma forma de consenso descentralizado) e outros mostram o apetite por L2s baseadas em validadores. O Polygon CDK torna tecnicamente viável ter muitos produtores de blocos, mas a implementação exata é deixada para o implantador da chain. Espere que a Polygon lance mais orientações ou até mesmo infraestrutura para sequenciadores descentralizados à medida que mais empresas e comunidades lançam chains CDK.

Para resumir a comparação de sequenciadores: Todas as estruturas atualmente dependem de um modelo de sequenciador relativamente centralizado em suas implantações ao vivo, para garantir a eficiência. No entanto, cada uma fornece uma rota para a descentralização – seja através de redes de sequenciamento compartilhadas (OP Stack), consenso conectável (CDK, ZK Stack) ou validadores sem permissão (BoLD da Arbitrum). A tabela abaixo destaca os designs de sequenciadores:

Como visto, Optimism e Arbitrum incluem filas de fallback on-chain, o que é uma forte característica de resistência à censura. As chains baseadas em ZK confiam no fato de que um sequenciador não pode forjar o estado (graças às provas ZK), mas se ele censurar, um novo sequenciador poderia ser nomeado pela governança – uma área ainda em refinamento. A tendência em 2025 é que provavelmente veremos mais pools de sequenciadores descentralizados e possivelmente redes de sequenciadores compartilhados entrando em operação, complementando essas estruturas de RaaS. Cada projeto está pesquisando ativamente isso: por exemplo, Astria e outros estão construindo serviços gerais de sequenciamento compartilhado, e a OP Labs, Polygon e Offchain mencionaram planos para descentralizar o papel do sequenciador.

Modelos de Taxas e Economia​

Os modelos de taxas determinam quem paga o quê nessas estruturas de rollup e como os incentivos econômicos se alinham para os operadores e o ecossistema. As principais considerações incluem: Em qual token as taxas são pagas? Quem coleta as taxas? Quais custos (postagem L1, prova) devem ser cobertos? Existem acordos de partilha de receita ou de retorno? Quão personalizáveis são os parâmetros de taxa?

• Token de Gás e Personalização de Taxas: Todas as estruturas comparadas permitem personalizar o token de gás nativo, o que significa que uma nova chain pode decidir em qual moeda os usuários pagam as taxas. Por padrão, os rollups no Ethereum geralmente escolhem o ETH como token de gás para conveniência do usuário (os usuários não precisam de um novo token para usar a chain). Por exemplo, a Base (OP Stack) usa ETH para gás, assim como o zkSync Era e o Polygon zkEVM. O OP Stack tecnicamente suporta a substituição do ETH por outro ERC-20, mas no contexto da OP Superchain, há um esforço para manter um padrão (para tornar a interoperabilidade mais suave). De fato, algumas chains OP Stack que inicialmente consideraram um token personalizado optaram pelo ETH – por exemplo, a chain OP da Worldcoin usa ETH para taxas, embora o projeto tenha seu próprio token WLD. Por outro lado, o Arbitrum Orbit foi lançado sem suporte a token personalizado, mas o adicionou rapidamente devido à demanda. Agora, as chains Orbit podem usar ARB ou qualquer ERC-20 como gás. A Ape Chain L3 escolheu a moeda APE como sua moeda de gás, mostrando essa flexibilidade. O Polygon CDK também permite que você defina o token; muitos projetos tendem a usar MATIC para se alinhar com o ecossistema da Polygon (e o MATIC será atualizado para o token POL sob a Polygon 2.0), mas não é obrigatório. O ZK Stack da zkSync também suporta explicitamente tokens de base personalizados (a documentação até tem um tutorial de “Token de base personalizado”). Isso é útil para chains empresariais que podem querer, digamos, uma stablecoin ou sua própria moeda para taxas. Também é crucial para app-chains que têm sua própria economia de token – elas podem impulsionar a demanda por seu token, tornando-o o token de gás. Em resumo, o token de taxa é totalmente configurável em todas as estruturas, embora o uso de um token amplamente detido como o ETH possa reduzir o atrito do usuário.

• Coleta e Distribuição de Taxas: Geralmente, o sequenciador (produtor de blocos) coleta as taxas de transação na L2/L3. Este é um incentivo primário para operar um sequenciador. Por exemplo, o sequenciador da Optimism ganha todas as taxas de gás que os usuários pagam na Optimism, mas deve então pagar pela postagem de lotes no Ethereum. Normalmente, o sequenciador pegará as taxas L2 pagas pelo usuário, subtrairá os custos L1 e manterá o restante como lucro. Em uma chain bem administrada, os custos L1 são uma fração das taxas L2, deixando alguma margem de lucro. Para ZK-rollups, há um custo extra: gerar a prova ZK. Isso pode ser significativo (exigindo hardware especializado ou computação em nuvem). Atualmente, alguns operadores de ZK rollup subsidiam os custos de prova (gastando fundos de VC) para manter as taxas dos usuários baixas durante a fase de crescimento. Com o tempo, espera-se que os custos de prova caiam com melhores algoritmos e hardware. Em termos de estrutura: zkSync e Polygon permitem que o sequenciador cobre um pouco mais para cobrir a prova – e se uma chain usar um serviço de provador externo, eles podem ter uma divisão de receita com eles. Notavelmente, nenhuma estrutura, exceto a OP Superchain, tem uma partilha de receita forçada a nível de protocolo. O esquema de Receita de Rollup Padrão do Optimism Collective exige que as OP Chains remetam 2,5% das taxas brutas ou 15% dos lucros líquidos (o que for maior) para um tesouro coletivo. Este é um acordo voluntário, mas esperado sob a carta da Superchain, em vez de uma aplicação de contrato inteligente, mas todas as principais chains OP Stack (Base, opBNB, Worldcoin, etc.) concordaram com isso. Essas taxas (mais de 14.000 ETH até agora) financiam bens públicos através da governança da Optimism. Em contraste, a Arbitrum não cobra nenhuma taxa das chains Orbit; o Orbit é de uso livre. A DAO da Arbitrum poderia potencialmente pedir alguma partilha de receita no futuro (para financiar seu próprio ecossistema), mas nada existe em 2025. O Polygon CDK também não impõe um imposto; a abordagem da Polygon é atrair usuários para seu ecossistema (aumentando assim o valor e o uso do MATIC) em vez de cobrar taxas por chain. O cofundador da Polygon, Sandeep Nailwal, disse explicitamente que o AggLayer “não busca aluguel” das chains. A zkSync também não anunciou nenhuma partilha de taxas – a Matter Labs provavelmente se concentra em aumentar o uso do zkSync Era e das hyperchains, o que os beneficia indiretamente através de efeitos de rede e possivelmente do valor futuro do token.

• Custos de Liquidação L1: Uma grande parte do modelo de taxas é quem paga pelas transações L1 (postagem de dados ou provas). Em todos os casos, em última análise, os usuários pagam, mas o mecanismo difere. Em rollups otimistas, o sequenciador posta periodicamente lotes de transações (com calldata) na L1. O custo do gás para essas transações L1 é pago pelo sequenciador usando ETH. No entanto, os sequenciadores levam isso em consideração no preço do gás L2. Optimism e Arbitrum têm fórmulas de precificação de gás que estimam quanto o call-data de uma transação custará na L1 e incluem isso na taxa de gás L2 (muitas vezes chamado de “custo L1 amortizado” por transação). Por exemplo, uma transação simples na Optimism pode incorrer em 21.000 de gás L2 para execução e talvez algumas centenas extras para dados L1 – a taxa do usuário cobre ambos. Se o preço for mal estimado, o sequenciador pode perder dinheiro naquele lote ou ganhar se o uso for alto. Os sequenciadores geralmente ajustam as taxas dinamicamente para corresponder às condições da L1 (aumentando as taxas L2 quando o gás L1 está caro). Na Arbitrum, o mecanismo é semelhante, embora a Arbitrum tenha componentes separados de “preço L1” e “preço L2”. Em zkSync/Polygon (ZK), o sequenciador deve postar uma prova de validade na L1 (custando uma quantidade fixa de gás para verificar) mais o call data (se for rollup) ou a raiz de estado (se for validium). O custo de verificação da prova é geralmente constante por lote (no zkSync Era, está na ordem de algumas centenas de milhares de gás), então o modelo de taxas do zkSync distribui esse custo entre as transações. Eles podem cobrar uma pequena sobretaxa em cada transação para a prova. Notavelmente, o zkSync introduziu recursos como diferenças de estado e compressão para minimizar os dados L1 publicados. O Polygon zkEVM também usa provas recursivas para agrupar muitas transações em uma única prova, amortizando o custo de verificação. Se uma chain usar uma DA alternativa (Celestia/Avail), então, em vez de pagar ao Ethereum pelo calldata, eles pagam a esse provedor de DA. A Celestia, por exemplo, tem seu próprio token de gás (TIA) para pagar por blobs de dados. Portanto, uma chain pode precisar converter parte das taxas para pagar os mineradores da Celestia. As estruturas estão cada vez mais abstraindo esses custos: por exemplo, uma chain OP Stack poderia pagar um nó de DA da Celestia através de um adaptador e incluir esse custo nas taxas do usuário.

• Custos para os Usuários (Finalidade e Retirada): Para rollups otimistas (OP Stack, Arbitrum Orbit no modo rollup), os usuários enfrentam o infame período de desafio para retiradas – geralmente 7 dias na L1 do Ethereum. Isso é um golpe na usabilidade, mas a maioria dos ecossistemas tem mitigações. Pontes rápidas (redes de liquidez) permitem que os usuários troquem seus tokens L2 por tokens L1 instantaneamente por uma pequena taxa, enquanto os arbitradores esperam os 7 dias. A Arbitrum foi além para as chains Orbit, trabalhando com equipes para permitir retiradas rápidas em apenas 15 minutos através de provedores de liquidez integrados a nível de protocolo. Isso efetivamente significa que os usuários não esperam uma semana, exceto nos piores cenários. Os ZK-rollups não têm esse atraso – uma vez que uma prova de validade é aceita na L1, o estado é final. Portanto, os usuários de zkSync e Polygon obtêm finalidade mais rápida (geralmente de minutos a uma hora), dependendo da frequência com que as provas são enviadas. A desvantagem é que a prova pode introduzir um pequeno atraso entre o momento em que uma transação é aceita na L2 e quando ela é incluída em uma prova L1 (pode ser de alguns minutos). Mas, em geral, os ZK rollups estão oferecendo retiradas de 10 a 30 minutos em 2025, o que é uma grande melhoria em relação a 7 dias. Os usuários podem pagar uma taxa um pouco mais alta pela finalidade imediata (para cobrir os custos do provador), mas muitos consideram que vale a pena. A Personalização de Taxas também vale a pena notar: as estruturas permitem agendas de taxas personalizadas (como transações gratuitas ou subsídios de gás) se os projetos quiserem. Por exemplo, uma empresa poderia subsidiar todas as taxas de usuário em sua chain, operando o sequenciador com prejuízo (talvez para um jogo ou aplicativo social). Ou eles poderiam configurar um modelo de gás diferente (alguns brincaram com a ideia de não ter gás para certas ações, ou contabilidade de gás alternativa). Como a maioria das estruturas visa a equivalência com o Ethereum, tais mudanças profundas são raras, mas possíveis com modificação de código. O Stylus da Arbitrum poderia permitir uma medição de taxas diferente para contratos WASM (não cobrando por certas operações para incentivar o uso de WASM, por exemplo). O Polygon CDK ser de código aberto e modular significa que, se um projeto quisesse implementar um mecanismo de taxas inovador (como queima de taxas ou preços dinâmicos), eles poderiam.

Em essência, todas as estruturas de rollup se esforçam para alinhar os incentivos econômicos: tornar lucrativo operar um sequenciador (através da receita de taxas), manter as taxas razoáveis para os usuários aproveitando DA mais barata e (opcionalmente) canalizar algum valor para seu ecossistema mais amplo. O modelo da Optimism é único em compartilhar explicitamente a receita para bens públicos, enquanto outros dependem do crescimento e da economia de tokens (ex: mais chains -> mais uso de MATIC/ETH, aumentando o valor desses tokens).

Arquitetura e Modularidade​

Todas essas estruturas se orgulham de uma arquitetura modular, o que significa que cada camada da pilha (execução, liquidação, consenso, DA, provas) é trocável ou atualizável. Vamos observar brevemente cada uma:

• OP Stack: Construído como uma série de módulos correspondentes às camadas do Ethereum – motor de execução (OP EVM, derivado do geth), nó de consenso/rollup (op-node), contratos inteligentes de liquidação e, em breve, provador de fraude. O objetivo de design do OP Stack era a equivalência com o EVM (sem agenda de gás personalizada ou mudanças de opcode) e a facilidade de integração com as ferramentas do Ethereum. A atualização Bedrock em 2023 modularizou ainda mais a pilha da Optimism, tornando mais fácil trocar componentes (por exemplo, para implementar provas ZK no futuro, ou usar uma DA diferente). De fato, o OP Stack não se limita a provas de fraude otimistas – a equipe disse que está aberta a integrar provas de validade quando amadurecerem, essencialmente transformando as chains OP Stack em ZK rollups sem alterar a experiência do desenvolvedor. O conceito de Superchain estende a arquitetura para múltiplas chains: padronizando a comunicação entre chains, pontes e talvez sequenciamento compartilhado. O OP Stack vem com um rico conjunto de contratos inteligentes na L1 (para depósitos, retiradas, verificação de prova de fraude, etc.), que as chains herdam prontas para uso. É efetivamente um modelo de chain L2 plug-and-play – projetos como a Base foram lançados bifurcando os repositórios do OP Stack e configurando-os para apontar para seus próprios contratos.

• ZK Stack: O ZK Stack é a estrutura subjacente ao zkSync Era e futuras “Hyperchains”. Arquitetonicamente, inclui o ambiente de execução zkEVM (uma VM baseada em LLVM que permite executar código Solidity com alterações mínimas), o sistema de provador (os circuitos e a geração de provas para transações), o nó sequenciador e os contratos L1 (os contratos inteligentes zkSync que verificam provas e gerenciam raízes de estado). A modularidade é vista em como ele separa o circuito de prova ZK da execução – teoricamente, pode-se trocar por um esquema de prova diferente ou até mesmo uma VM diferente (embora não seja trivial). O ZK Stack introduz a Arquitetura de Chain Elástica com componentes como Roteador ZK e Gateway ZK. Estes atuam como uma camada de interoperabilidade conectando múltiplas ZK Chains. É um pouco como um conceito de “internet de ZK rollups”, onde o Roteador (no Ethereum) mantém um registro de chains e facilita pontes/liquidez compartilhada, e o Gateway lida com mensagens entre chains off-chain. Isso é modular porque uma nova chain pode se conectar a essa arquitetura simplesmente implantando com os contratos padrão. O ZK Stack também adota a abstração de contas a nível de protocolo (contratos como contas, meta-transações nativas), que é uma escolha arquitetônica para melhorar a UX. Outro aspecto modular: como discutido em DA, ele pode operar no modo rollup ou validium – essencialmente virando um interruptor na configuração. Além disso, a pilha tem uma noção de consenso conectável para sequenciamento (como observado anteriormente). A camada de liquidação pode ser o Ethereum ou potencialmente outra chain: o roteiro da zkSync até flutuou a ideia de liquidar hyperchains na L2 (por exemplo, uma L3 que posta provas na L2 do zkSync Era em vez da L1) – de fato, eles lançaram um protótipo chamado “Portal ZK” para liquidação de L3 na L2. Isso dá uma modularidade hierárquica (L3->L2->L1). No geral, o ZK Stack é um pouco menos pronto para uso para equipes que não são da Matter Labs em 2025 (já que executar uma chain ZK envolve coordenar provadores, etc.), mas é altamente flexível em mãos capazes.

• Arbitrum Orbit: A arquitetura da Arbitrum é construída sobre a pilha Arbitrum Nitro, que inclui a camada de execução ArbOS (a interpretação da Arbitrum do EVM com algumas pequenas diferenças), o Sequenciador/Relé, o componente AnyTrust para DA alternativa e o maquinário de prova de fraude (provas de fraude interativas). O Orbit essencialmente permite que você use essa mesma pilha, mas configure certos parâmetros (como ID da chain, estado de gênese da L2, escolha de rollup vs. AnyTrust). Modularidade: A Arbitrum introduziu o Stylus, um novo motor de contrato inteligente compatível com WASM que roda ao lado do EVM. O Stylus permite escrever contratos em Rust, C, C++ que compilam para WASM e rodam com velocidade quase nativa nas chains Arbitrum. Este é um módulo opcional – as chains Orbit podem habilitar o Stylus ou não. É um diferencial para a pilha da Arbitrum, tornando-a atraente para dApps de alto desempenho (por exemplo, aplicativos de jogos ou negociação podem escrever alguma lógica em Rust para velocidade). O módulo de disponibilidade de dados também é conectável, como discutido (as chains Arbitrum podem escolher on-chain ou DAC). Outro módulo é a liquidação L1: as chains Orbit podem postar suas provas no Ethereum (L1) ou no Arbitrum One (L2). Se for o último, elas são efetivamente L3s ancoradas na segurança do Arbitrum One (com suposições de confiança ligeiramente diferentes). Muitas chains Orbit estão sendo lançadas como L3s (para herdar as taxas mais baixas do Arbitrum One e, em última análise, a segurança do Ethereum). O código-fonte da Arbitrum agora é totalmente aberto, e projetos como Caldera, Conduit o utilizam para fornecer implantação amigável – eles podem adicionar seus próprios módulos (como monitoramento, APIs de gerenciamento de chain). Vale a pena notar que as provas de fraude da Arbitrum historicamente não eram sem permissão (apenas validadores na lista de permissões podiam desafiar), mas com o BoLD, essa parte da arquitetura está mudando para permitir que qualquer pessoa intervenha. Portanto, o componente de prova de fraude está se tornando mais descentralizado (o que é uma atualização modular em certo sentido). Pode-se dizer que a Arbitrum é menos um “kit de lego” do que o OP Stack ou o Polygon CDK, no sentido de que a Offchain Labs não lançou um lançador de chain de um clique (embora tenham lançado uma GUI de implantação do Orbit no GitHub). Mas funcionalmente, é modular o suficiente para que terceiros tenham automatizado as implantações para ele.

• Polygon CDK (AggLayer): O Polygon CDK é explicitamente descrito como uma “estrutura modular” para chains alimentadas por ZK. Ele aproveita a tecnologia de prova ZK da Polygon (do Polygon zkEVM, que é baseado em Plonky2 e SNARKs recursivos). A arquitetura separa a camada de execução (que é um EVM – especificamente um fork do Geth ajustado para zkEVM) da camada de provador e dos contratos de ponte/liquidação. Por ser modular, um desenvolvedor pode escolher diferentes opções para cada um: por exemplo, Execução – presumivelmente sempre EVM por enquanto (para usar ferramentas existentes), DA – como discutido (Ethereum ou outros), Consenso do Sequenciador – nó único vs. multi-nó, Provador – pode-se executar o provador Tipo 1 (provas de validade postadas no Ethereum) ou um Tipo 2 (provas de validium), etc., e Integração com AggLayer – sim ou não (AggLayer para interoperabilidade). A Polygon até forneceu uma interface elegante (mostrada abaixo) para visualizar essas escolhas:

Interface de configuração do Polygon CDK, ilustrando escolhas modulares – por exemplo, Rollups vs. Validium (solução de escalonamento), sequenciador descentralizado vs. centralizado, DA local/Ethereum/terceiros, diferentes tipos de provadores e se deve habilitar a interoperabilidade do AggLayer.

Nos bastidores, o Polygon CDK usa provas ZK com recursão para permitir alto throughput e um conjunto de validadores dinâmico. O AggLayer é uma parte emergente da arquitetura que conectará chains para mensagens sem confiança e liquidez compartilhada. O CDK é construído de forma que futuras melhorias na tecnologia ZK da Polygon (como provas mais rápidas ou novos recursos de VM) possam ser adotadas por todas as chains CDK através de atualizações. A Polygon tem um conceito de zkEVM “Tipo 1 vs. Tipo 2” – o Tipo 1 é totalmente equivalente ao Ethereum, o Tipo 2 é quase equivalente com pequenas alterações para eficiência. Uma chain CDK poderia escolher um EVM ligeiramente modificado para mais velocidade (sacrificando alguma equivalência) – esta é uma opção arquitetônica que os projetos têm. No geral, o CDK é muito semelhante a um lego: pode-se montar uma chain escolhendo componentes adequados para seu caso de uso (por exemplo, uma empresa pode escolher validium + sequenciadores permissionados + visibilidade de transação privada; uma chain DeFi pública pode escolher rollup + sequenciador descentralizado + AggLayer habilitado para liquidez). Essa versatilidade atraiu muitos projetos a considerar o CDK para lançar suas próprias redes.

• Imagens e diagramas: As estruturas geralmente fornecem diagramas visuais de sua arquitetura modular. Por exemplo, a UI da zkSync mostra alternâncias para Rollup/Validium, L2/L3, centralizado/descentralizado, etc., destacando a flexibilidade do ZK Stack:

Um exemplo de configuração para uma “Hyperchain” zkSync. A interface do ZK Stack permite selecionar o modo da chain (Rollup vs. Validium vs. Volition), camada (L2 ou L3), sequenciamento de transações (descentralizado, centralizado ou compartilhado), fonte de disponibilidade de dados (Ethereum, rede de terceiros ou personalizada), visibilidade de dados (chain pública ou privada) e token de gás (ETH, personalizado ou sem gás). Essa abordagem modular é projetada para suportar uma variedade de casos de uso, desde chains DeFi públicas até chains empresariais privadas.

Em resumo, todas essas pilhas são altamente modulares e atualizáveis, o que é essencial dado o ritmo da inovação em blockchain. Elas estão convergindo em certo sentido: o OP Stack adicionando provas de validade, a Polygon adicionando sequenciamento compartilhado (ideias do OP Stack), a Arbitrum adicionando L3s interoperáveis (como outros), a zkSync buscando L3s (como Orbit e OPStack fazem). Essa polinização cruzada significa que as estruturas modulares em 2025 são mais parecidas do que diferentes em filosofia – cada uma quer ser o kit de ferramentas completo para lançar chains escaláveis sem reinventar a roda.

Experiência do Desenvolvedor e Ferramentas​

Um fator crítico para a adoção é quão fáceis e amigáveis para o desenvolvedor são essas estruturas. Isso inclui documentação, SDKs/APIs, CLIs para implantação, ferramentas de monitoramento e a curva de aprendizado para os desenvolvedores:

• OP Stack – Experiência do Desenvolvedor: O OP Stack da Optimism se beneficia de ser equivalente ao EVM, então os desenvolvedores do Ethereum podem usar ferramentas familiares (Remix, Hardhat, Truffle, Solidity, Vyper) sem modificação. Contratos inteligentes implantados em uma chain OP se comportam exatamente como na L1. Isso reduz drasticamente a curva de aprendizado. A Optimism fornece documentação extensa: os documentos oficiais da Optimism têm seções sobre o OP Stack, como executar um nó L2 e até um tutorial “OP Stack do zero”. Existem também guias escritos pela comunidade (por exemplo, o guia passo a passo da QuickNode sobre como implantar um rollup L2 da Optimism). Em termos de ferramentas, a OP Labs lançou o cliente op-node (para o nó do rollup) e o op-geth (motor de execução). Para lançar uma chain, um desenvolvedor normalmente precisa configurar estes e implantar os contratos L1 (Standard Bridge, etc.). Isso não era trivial, mas está se tornando mais fácil com serviços de provedores. Implantação como serviço: empresas como Caldera, Conduit e Infura/Alchemy oferecem implantações gerenciadas de rollup OP Stack, o que abstrai grande parte do DevOps. Para monitoramento, como uma chain OP Stack é essencialmente uma chain geth mais um coordenador de rollup, ferramentas de monitoramento padrão do Ethereum (painéis de métricas ETH, exploradores de blocos como Etherscan/Blockscout) podem ser usadas. De fato, o Etherscan suporta chains OP Stack como Optimism e Base, fornecendo interfaces de explorador de blocos familiares. As ferramentas de desenvolvedor específicas para OP Chains incluem o SDK da Optimism para pontes (facilitando depósitos/retiradas em aplicativos) e a integração do Bedrock com o JSON-RPC do Ethereum (para que ferramentas como o MetaMask simplesmente funcionem trocando de rede). O código do OP Stack é licenciado pelo MIT, convidando os desenvolvedores a bifurcar e experimentar. Muitos o fizeram – por exemplo, a equipe da BNB Chain usou o OP Stack para construir o opBNB com suas próprias modificações no consenso e no token de gás (eles usam gás BNB no opBNB). A adesão do OP Stack aos padrões do Ethereum torna a experiência do desenvolvedor indiscutivelmente a mais suave entre estas: essencialmente “Ethereum, mas mais barato” da perspectiva de um desenvolvedor de contratos. As principais novas habilidades necessárias são em torno da execução da infraestrutura (para aqueles que lançam uma chain) e da compreensão das nuances de pontes entre chains. A comunidade e o suporte da Optimism (Discord, fóruns) são ativos para ajudar novas equipes de chains. Além disso, a Optimism financiou ferramentas do ecossistema como o Magi (um cliente de rollup alternativo em Rust) para diversificar a pilha e torná-la mais robusta para os desenvolvedores.

• zkSync ZK Stack – Experiência do Desenvolvedor: No lado do desenvolvimento de contratos, o ZK Stack da zkSync oferece um zkEVM que se destina a ter alta compatibilidade, mas atualmente não é 100% equivalente em bytecode. Ele suporta contratos Solidity e Vyper, mas existem diferenças sutis (por exemplo, certos pré-compilados ou custos de gás). Dito isso, a Matter Labs construiu um compilador LLVM que pega o Solidity e produz bytecode zkEVM, então a maior parte do código Solidity funciona com pouca ou nenhuma alteração. Eles também suportam nativamente a abstração de contas, que os desenvolvedores podem aproveitar para criar transações sem gás, carteiras multi-sig, etc., mais facilmente do que no Ethereum (sem necessidade de ERC-4337). A documentação do desenvolvedor para zkSync é abrangente (docs.zksync.io) e cobre como implantar contratos, usar a CLI da Hyperchain (se houver) e configurar uma chain. No entanto, executar um ZK rollup é inerentemente mais complexo do que um otimista – você precisa de uma configuração de prova. O ZK Stack fornece o software de provador (por exemplo, os provadores de GPU para os circuitos do zkSync), mas um operador de chain deve ter acesso a hardware sério ou serviços em nuvem para gerar provas continuamente. Este é um novo desafio de DevOps; para mitigá-lo, algumas empresas estão surgindo que fornecem serviços de provador ou até mesmo Prova-como-Serviço. Se um desenvolvedor não quiser executar seus próprios provadores, ele pode terceirizar (com garantias de confiança ou criptoeconômicas). Ferramentas: o zkSync fornece uma ponte e um portal de carteira por padrão (o Portal zkSync) que pode ser bifurcado para uma nova chain, dando aos usuários uma UI para mover ativos e visualizar contas. Para exploração de blocos, o Blockscout foi adaptado para o zkSync, e a Matter Labs construiu seu próprio explorador de blocos para o zkSync Era, que provavelmente poderia ser usado para novas chains. A existência do Gateway e Roteador ZK significa que, se um desenvolvedor se conectar a isso, ele obtém alguma interoperabilidade pronta para uso com outras chains – mas precisa seguir os padrões da Matter Labs. No geral, para um desenvolvedor de contratos inteligentes, construir no zkSync não é muito difícil (apenas Solidity, com talvez pequenas diferenças como gasleft() pode se comportar de forma ligeiramente diferente por não ter o custo real de gás do Ethereum). Mas para um operador de chain, o ZK Stack tem uma curva de aprendizado mais íngreme do que o OP Stack ou o Orbit. Em 2025, a Matter Labs está se concentrando em melhorar isso – por exemplo, simplificando o processo de lançamento de uma Hyperchain, possivelmente fornecendo scripts ou imagens de nuvem para iniciar toda a pilha. Há também uma comunidade emergente de desenvolvedores em torno do ZK Stack; por exemplo, a Edição Comunitária do ZKSync é uma iniciativa onde membros da comunidade executam chains L3 de teste e compartilham dicas. Devemos notar que o suporte de linguagem para o ecossistema do zkSync pode se expandir – eles falaram sobre permitir outras linguagens através do pipeline LLVM (por exemplo, um compilador Rust-para-zkEVM no futuro), mas o Solidity é o principal agora. Em resumo, a experiência de desenvolvimento do zkSync: ótima para desenvolvedores de DApp (quase como o Ethereum), moderada para lançadores de chain (precisam lidar com o provador e novos conceitos como validiums).

• Arbitrum Orbit – Experiência do Desenvolvedor: Para desenvolvedores Solidity, o Arbitrum Orbit (e o Arbitrum One) é totalmente compatível com o EVM a nível de bytecode (o Arbitrum Nitro usa execução derivada do geth). Assim, implantar e interagir com contratos em uma chain Arbitrum é como no Ethereum (com algumas pequenas diferenças, como acesso ligeiramente diferente ao número do bloco L1, chainID, etc., mas nada importante). Onde a Arbitrum se destaca é o Stylus – os desenvolvedores podem escrever contratos inteligentes em linguagens como Rust, C, C++ (compilados para WebAssembly) e implantá-los ao lado de contratos EVM. Isso abre o desenvolvimento de blockchain para um grupo mais amplo de programadores e permite casos de uso de alto desempenho. Por exemplo, uma lógica intensiva em algoritmos poderia ser escrita em C para velocidade. O Stylus ainda está em beta na mainnet da Arbitrum, mas as chains Orbit podem experimentar com ele. Este é um benefício único para a experiência do desenvolvedor, embora aqueles que usam o Stylus precisem aprender novas ferramentas (por exemplo, toolchains Rust e as bibliotecas da Arbitrum para interfacear o WASM com a chain). A documentação da Arbitrum fornece orientação sobre o uso do Stylus e até mesmo sobre como escrever contratos inteligentes em Rust. Para lançar uma chain Orbit, a Offchain Labs forneceu scripts de Devnet e uma UI de implantação do Orbit. O processo é um tanto técnico: é preciso configurar um nó Arbitrum com flags --l3 (se estiver lançando uma L3) e configurar a gênese, parâmetros da chain, etc. A QuickNode e outros publicaram guias (“Como implantar sua própria chain Arbitrum Orbit”). Além disso, as parcerias do Orbit com Caldera, AltLayer e Conduit significam que esses terceiros lidam com grande parte do trabalho pesado. Um desenvolvedor pode essencialmente preencher um formulário ou executar um assistente com esses serviços para obter uma chain Arbitrum personalizada, em vez de modificar manualmente o código Nitro. Em termos de depuração e monitoramento, as chains Arbitrum podem usar o Arbiscan (para aquelas que o têm) ou exploradores da comunidade. Há também integrações com Grafana/Prometheus para métricas de nós. Uma complexidade é o sistema de prova de fraude – os desenvolvedores que lançam uma chain Orbit devem garantir que haja validadores (talvez eles mesmos ou outros de confiança) que executem o software de validador off-chain para observar fraudes. A Offchain Labs provavelmente fornece scripts padrão para executar tais validadores. Mas como as provas de fraude raramente são acionadas, é mais sobre ter o processo de segurança em vigor. A grande comunidade de desenvolvedores da Arbitrum (projetos construindo no Arbitrum One) é um ativo – recursos como tutoriais, respostas no stackexchange, etc., muitas vezes se aplicam ao Orbit também. Além disso, a Arbitrum é conhecida por seus fortes esforços de educação de desenvolvedores (workshops, hackathons), que presumivelmente se estendem aos interessados no Orbit.

• Polygon CDK – Experiência do Desenvolvedor: O Polygon CDK é mais recente (anunciado em meados/final de 2023), mas se baseia em componentes familiares. Para desenvolvedores que escrevem contratos, as chains Polygon CDK usam um zkEVM que se destina a ser equivalente ao EVM do Ethereum (o zkEVM Tipo 2 da Polygon é quase idêntico com alguns casos extremos). Portanto, Solidity e Vyper são as linguagens preferidas, com suporte total para ferramentas de desenvolvimento padrão do Ethereum. Se você já implantou no Polygon zkEVM ou no Ethereum, pode implantar em uma chain CDK de forma semelhante. O desafio está mais no lado das operações da chain. O CDK da Polygon é de código aberto no GitHub e vem com documentação sobre como configurar uma chain. Provavelmente fornece uma ferramenta de linha de comando para criar o esqueleto de uma nova chain (semelhante a como se poderia usar o starport do Cosmos SDK ou o modelo de nó do Substrate). A Polygon Labs investiu em tornar a configuração o mais fácil possível – uma citação: “lançar uma L2 Ethereum de alto throughput alimentada por ZK tão facilmente quanto implantar um contrato inteligente”. Embora talvez otimista, isso indica que existem ferramentas ou scripts para simplificar a implantação. De fato, houve adotantes iniciais como a Immutable (para jogos) e a OKX (chain de exchange) que trabalharam com a Polygon para lançar chains CDK, sugerindo um processo bastante tranquilo com o suporte da equipe da Polygon. O CDK inclui SDKs e bibliotecas para interagir com a ponte (para depósitos/retiradas) e para habilitar o AggLayer, se desejado. O monitoramento de uma chain CDK pode aproveitar o explorador de blocos da Polygon (Polygonscan) se eles o integrarem, ou o Blockscout. A Polygon também é conhecida por SDKs robustos para jogos e dispositivos móveis (por exemplo, SDKs para Unity) – eles podem ser usados em qualquer chain baseada na Polygon. O suporte ao desenvolvedor é um grande foco: a Polygon tem academias, subsídios, hackathons regularmente, e sua equipe de Relações com Desenvolvedores ajuda projetos individualmente. Um exemplo de experiência de desenvolvedor empresarial: a Libre, uma chain institucional lançada com o CDK, presumivelmente tinha requisitos personalizados – a Polygon foi capaz de acomodar coisas como módulos de identidade ou recursos de conformidade nessa chain. Isso mostra que o CDK pode ser estendido para casos de uso específicos por desenvolvedores com a ajuda da estrutura. Quanto aos materiais de aprendizado, o site de documentação e o blog da Polygon têm guias sobre o uso do CDK, e como o CDK é essencialmente a evolução de seu zkEVM, aqueles familiarizados com o design do zkEVM da Polygon podem aprendê-lo rapidamente. Mais um aspecto de ferramentas: ferramentas entre chains – como muitas chains Polygon CDK coexistirão, a Polygon fornece o AggLayer para mensagens, mas também incentiva o uso de mensagens entre chains padrão como o LayerZero (de fato, a chain Orbit da Rarible integrou o LayerZero para transferências de NFT e as chains da Polygon também podem). Portanto, os desenvolvedores têm opções para integrar plugins de interoperabilidade facilmente. Em suma, a experiência do desenvolvedor do CDK visa ser pronta para uso para o lançamento de chains de nível Ethereum com segurança ZK, beneficiando-se dos anos de experiência da Polygon em L2.

Em conclusão, a experiência do desenvolvedor melhorou drasticamente para o lançamento de chains personalizadas: o que antes exigia uma equipe inteira de engenheiros de protocolo agora pode ser feito com estruturas guiadas e suporte. As ofertas da Optimism e da Arbitrum aproveitam a familiaridade (equivalência EVM), a zkSync e a Polygon oferecem tecnologia de ponta com crescente facilidade de uso, e todas têm ecossistemas crescentes de ferramentas de terceiros para simplificar o desenvolvimento (de exploradores de blocos a painéis de monitoramento e scripts de devops). A qualidade da documentação é geralmente alta – documentos oficiais mais guias da comunidade (artigos no Medium, guias da QuickNode/Alchemy) cobrem muito terreno. Ainda há uma curva de aprendizado não trivial para passar de desenvolvedor de contratos inteligentes para “operador de rollup”, mas está ficando mais fácil à medida que as melhores práticas emergem e a comunidade de construtores de rollup se expande.

Suporte do Ecossistema e Estratégias de Entrada no Mercado​

Construir uma tecnologia é uma coisa; construir um ecossistema é outra. Cada uma dessas estruturas é apoiada por uma organização ou comunidade que investe no crescimento através de subsídios, financiamento, marketing e suporte a parcerias. Aqui comparamos suas estratégias de suporte ao ecossistema – como elas atraem desenvolvedores e projetos, e como ajudam esses projetos a ter sucesso:

• Ecossistema OP Stack (Optimism): A Optimism tem uma estratégia de ecossistema robusta centrada em seu Optimism Collective e no ethos de financiamento de bens públicos. Eles foram pioneiros no Financiamento Retroativo de Bens Públicos (RPGF) – usando o tesouro do token OP para recompensar desenvolvedores e projetos que beneficiam o ecossistema. Através de várias rodadas de RPGF, a Optimism distribuiu milhões em financiamento para projetos de infraestrutura, ferramentas de desenvolvimento e aplicativos na Optimism. Qualquer projeto construindo com o OP Stack (especialmente se alinhado com a visão da Superchain) é elegível para solicitar subsídios do Collective. Além disso, a governança da Optimism pode autorizar programas de incentivo (no início de 2022, eles tinham um airdrop e um fundo de governança que os projetos poderiam usar para distribuir recompensas OP aos usuários). Em 2024, a Optimism estabeleceu o modelo de Partilha de Receita da Superchain, onde cada OP Chain contribui com uma pequena porção das taxas para um tesouro compartilhado. Isso cria um círculo virtuoso: à medida que mais chains (como Base, opBNB, a chain da Worldcoin, etc.) geram uso, elas financiam coletivamente mais bens públicos que melhoram o OP Stack, o que por sua vez atrai mais chains. É uma abordagem de soma positiva única da Optimism. No lado da entrada no mercado, a Optimism tem parcerias ativas com grandes entidades: conseguir que a Coinbase construísse a Base foi uma grande validação do OP Stack, e a Optimism Labs forneceu ajuda técnica e suporte à Coinbase durante esse processo. Da mesma forma, eles trabalharam com a equipe da Worldcoin, e a migração da Celo para uma L2 OP Stack foi feita com consultoria da OP Labs. A Optimism faz muito alcance de desenvolvedores – desde a realização de hackathons (muitas vezes combinados com eventos da ETHGlobal) até a manutenção de um Hub de Desenvolvedores com tutoriais. Eles também investem em ferramentas: por exemplo, financiando equipes para construir clientes alternativos, ferramentas de monitoramento e fornecendo um faucet oficial e integração de explorador de blocos para novas chains. Em termos de marketing, a Optimism cunhou o termo “Superchain” e promove ativamente a visão de muitas chains se unindo sob um guarda-chuva interoperável, o que atraiu projetos que querem fazer parte de uma narrativa mais ampla em vez de uma appchain isolada. Há também a atração da liquidez compartilhada: com o futuro OPCraft (interoperabilidade da Superchain), aplicativos em uma OP Chain podem interagir facilmente com outra, tornando atraente o lançamento de uma chain que não seja uma ilha. Em essência, a jogada de ecossistema do OP Stack é sobre comunidade e colaboração – junte-se à Superchain, tenha acesso a um pool de usuários (via pontes fáceis), financiamento e marca coletiva. Eles até criaram um conceito de “Passaporte de Rollup” onde os usuários podem ter uma identidade unificada em todas as OP Chains. Todos esses esforços diminuem a barreira para novas chains encontrarem usuários e desenvolvedores. Finalmente, a própria base de usuários e reputação da Optimism (sendo uma das principais L2s) significa que qualquer chain OP Stack pode, de certa forma, pegar carona nisso (a Base fez isso, anunciando-se como parte do ecossistema da Optimism, por exemplo).

• Ecossistema zkSync (ZK Stack/Hyperchains): A Matter Labs (a equipe por trás do zkSync) garantiu grandes rodadas de financiamento (mais de US$ 200 milhões) para alimentar seu ecossistema. Eles criaram fundos como o Fundo do Ecossistema zkSync, muitas vezes em colaboração com VCs, para investir em projetos construindo no zkSync Era. Para o ZK Stack especificamente, eles começaram a promover o conceito de Hyperchains para comunidades que precisam de sua própria chain. Uma estratégia é direcionar verticais específicas: por exemplo, jogos. O zkSync destacou como um estúdio de jogos poderia lançar sua própria Hyperchain para obter personalização e ainda estar conectado ao Ethereum. Eles provavelmente estão oferecendo suporte próximo aos parceiros iniciais (da mesma forma que a Polygon fez com algumas empresas). A menção no artigo da Zeeve sobre um “banco suíço; o maior banco do mundo” interessado no ZK Stack sugere que a Matter Labs está cortejando casos de uso empresariais que precisam de privacidade (as provas ZK podem garantir a correção enquanto mantêm alguns dados privados, um grande negócio para instituições). Se o zkSync conseguir uma grande chain empresarial, isso aumentaria sua credibilidade. O suporte ao desenvolvedor no zkSync é bastante forte: eles executam aceleradoras (por exemplo, um programa com o Blockchain Founders Fund foi anunciado), hackathons (muitas vezes com temas de ZK) e têm uma comunidade ativa em seu Discord fornecendo ajuda técnica. Embora o zkSync não tenha um token ativo (em 2025) para governança ou incentivos, há especulações de um, e os projetos podem antecipar futuros programas de incentivo. A Matter Labs também tem trabalhado no suporte a pontes: eles fizeram parceria com grandes pontes como Across, LayerZero, Wormhole para garantir que ativos e mensagens possam se mover facilmente de e para o zkSync e quaisquer hyperchains. De fato, o Across Protocol integrou o ZK Stack do zkSync, ostentando suporte em “todas as principais estruturas de L2”. Esse foco na interoperabilidade significa que um projeto que lança uma hyperchain pode se conectar prontamente à mainnet do Ethereum e outras L2s, crucial para atrair usuários (ninguém quer ficar isolado). Em termos de marketing, o zkSync promove o slogan “Web3 sem compromisso” e enfatiza ser o primeiro a chegar à mainnet ZK. Eles publicam roteiros (seu blog de roteiro para 2025) para manter a empolgação alta. Se considerarmos os fundos do ecossistema: além dos subsídios diretos da Matter Labs, há também a Ethereum Foundation e outros fundos focados em ZK que favorecem o desenvolvimento do zkSync devido à importância geral da tecnologia ZK. Outra estratégia: o zkSync é de código aberto e neutro (sem taxas de licenciamento), o que atrai projetos que podem ser cautelosos em se alinhar com um ecossistema mais centralizado. O ZK Stack está tentando se posicionar como a escolha do descentralizador – por exemplo, destacando a descentralização total e sem rodinhas de apoio, enquanto o OP Stack e outros ainda têm alguma centralização na prática. O tempo dirá se isso ressoa, mas certamente dentro da comunidade Ethereum, o zkSync tem apoiadores que querem uma pilha totalmente sem confiança. Finalmente, a Matter Labs e a Windranger da BitDAO têm uma iniciativa conjunta chamada “ZK DAO” que pode implantar capital ou incentivos para a adoção do ZK Stack. No geral, os esforços do ecossistema do zkSync são uma mistura de mensagens de superioridade técnica (ZK é o futuro) e construção de pontes práticas (tanto figurativas quanto literais) para que os projetos embarquem.

• Ecossistema Arbitrum Orbit: A Arbitrum tem um enorme ecossistema existente em sua L2 (Arbitrum One), com o maior TVL DeFi entre as L2s em 2024. A Offchain Labs aproveita isso incentivando dApps de sucesso da Arbitrum a considerar chains Orbit para subaplicações ou expansões L3. Eles anunciaram que mais de 50 chains Orbit estavam em desenvolvimento no final de 2023, esperando talvez mais de 100 até o final de 2024 – indicando um interesse substancial. Para nutrir isso, a Offchain Labs adotou algumas estratégias. Primeiro, parcerias com provedores de RaaS: Eles perceberam que nem toda equipe pode lidar com a infraestrutura de rollup, então recrutaram Caldera, Conduit e AltLayer para simplificá-la. Esses parceiros geralmente têm seus próprios programas de subsídio ou incentivo (às vezes co-patrocinados pela Arbitrum) para atrair projetos. Por exemplo, pode haver um subsídio Arbitrum x AltLayer para chains de jogos. Segundo, a Offchain Labs fornece suporte técnico direto e co-desenvolvimento para projetos-chave. O caso da Xai Chain é ilustrativo: é uma L3 de jogos onde a Offchain Labs co-desenvolveu a chain e fornece suporte técnico e até de marketing contínuo. Eles basicamente ajudaram a incubar a Xai para mostrar o potencial do Orbit em jogos. Da mesma forma, a chain RARI NFT da Rarible foi integrada com muitos parceiros (Gelato para transações sem gás, LayerZero para NFTs entre chains, etc.) com presumivelmente a orientação da Arbitrum. A Offchain Labs também às vezes usa seu cofre de guerra (a DAO da Arbitrum tem um enorme tesouro de tokens ARB) para financiar iniciativas. Embora a DAO da Arbitrum seja separada, a Offchain Labs pode coordenar com ela para assuntos do ecossistema. Por exemplo, se uma chain Orbit usa muito o token ARB ou beneficia a Arbitrum, a DAO poderia votar subsídios. No entanto, uma abordagem mais direta: a Offchain Labs lançou hackathons e prêmios do Arbitrum Orbit Challenge para incentivar os desenvolvedores a tentar fazer L3s. Em marketing: a marca da Arbitrum é focada no desenvolvedor, e eles promovem as vantagens do Orbit como o Stylus (contratos rápidos e multilíngues) e a ausência de retirada de 7 dias (com pontes rápidas). Eles também destacam exemplos de sucesso: por exemplo, o Bridgeworld da Treasure DAO anunciou uma chain Orbit, etc. Mais um ângulo de suporte: liquidez e integração DeFi. A Arbitrum está trabalhando com protocolos para que, se você lançar uma chain Orbit, possa acessar a liquidez do Arbitrum One facilmente (via pontes nativas ou LayerZero). Quanto mais fácil for mover ativos e usuários para sua nova chain, maior a probabilidade de sucesso. A Arbitrum tem uma comunidade muito grande e ativa (no Reddit, Discord, etc.), e ao estender isso para o Orbit, novas chains podem fazer marketing para os usuários existentes da Arbitrum (por exemplo, um usuário da Arbitrum pode receber um airdrop em uma nova chain Orbit para experimentá-la). Em resumo, a estratégia de ecossistema da Arbitrum para o Orbit é sobre aproveitar seu domínio na L2 – se você construir uma L3, você é efetivamente uma extensão da maior L2, então você compartilha desse efeito de rede. A Offchain Labs está removendo ativamente os obstáculos (técnicos e de liquidez) e até mesmo ajudando diretamente a construir algumas L3s iniciais para estabelecer precedentes para outros seguirem.

• Ecossistema Polygon CDK (AggLayer): A Polygon tem sido uma das mais agressivas no desenvolvimento de ecossistemas e negócios. Eles têm uma abordagem multifacetada:

  • Subsídios e Fundos: A Polygon estabeleceu um Fundo de Ecossistema de US$ 100 milhões há algum tempo e investiu em centenas de projetos. Eles também tinham fundos verticais específicos (por exemplo, Fundo de Jogos da Polygon, Fundo DeFi da Polygon). Para as chains CDK, a Polygon anunciou incentivos como cobrir parte do custo de operação de uma chain ou fornecer suporte de liquidez. As estatísticas da CoinLaw mencionam que “Mais de 190 dApps estão aproveitando o Polygon CDK para construir suas próprias chains” – o que implica que a Polygon tem um vasto pipeline de projetos (provavelmente muitos ainda em desenvolvimento). Eles provavelmente ofereceram subsídios ou compartilhamento de recursos para essas equipes.
  • Onboarding Empresarial e Institucional: A equipe de BizDev da Polygon integrou grandes empresas (Starbucks, Reddit, Nike, Disney para NFTs na Polygon POS). Agora, com o CDK, eles propõem às empresas o lançamento de chains dedicadas. Por exemplo, a Immutable (plataforma de jogos Web3) em parceria para usar o CDK para chains específicas de jogos, a Franklin Templeton lançando um fundo na Polygon e o teste do Walmart de uma cadeia de suprimentos em uma chain privada da Polygon. A Polygon fornece suporte personalizado a esses parceiros: consultoria técnica, desenvolvimento de recursos personalizados (privacidade, conformidade) e co-marketing. A introdução da Libre (pela JP Morgan/Siemens) construída no Polygon CDK mostra como eles atendem a instituições financeiras com necessidades especializadas.
  • Entrada no Mercado e Interoperabilidade: A Polygon está criando o AggLayer como um hub de interoperabilidade e liquidez conectando todas as chains da Polygon. Isso significa que, se você lançar uma chain CDK, não estará sozinho – você se torna parte da “Polygon 2.0”, uma constelação de chains com liquidez unificada. Eles prometem coisas como transferência de token com um clique entre chains CDK e o Ethereum (via AggLayer). Eles também não estão cobrando nenhuma taxa de protocolo (sem aluguel), o que eles anunciam como uma vantagem competitiva contra, digamos, a partilha de taxas da Optimism. O marketing da Polygon destaca que o lançamento de uma chain CDK pode lhe dar “o melhor dos dois mundos”: soberania e desempenho personalizados, além de acesso à grande base de usuários e desenvolvedores da Polygon/Ethereum. Eles frequentemente citam que a Polygon (POS+zkEVM) combinada processou mais de 30% de todas as transações L2, para garantir aos potenciais construtores de chains que o fluxo de usuários na Polygon é enorme.
  • Suporte ao Desenvolvedor: A Polygon realiza talvez o maior número de hackathons e eventos de DevRel no espaço blockchain. Eles têm uma Polygon University dedicada, cursos online e frequentemente patrocinam a ETHGlobal e outros hackathons com desafios em torno do uso do CDK, zkEVM, etc. Assim, os desenvolvedores podem ganhar prêmios construindo protótipos de chains CDK ou dapps entre chains. Eles também mantêm uma forte presença em comunidades de desenvolvedores e fornecem suporte rápido (o Discord da Polygon tem canais para perguntas técnicas onde os desenvolvedores principais respondem).
  • Comunidade e Governança: A Polygon está em transição para a Polygon 2.0 com um novo token POL e governança comunitária que abrange todas as chains. Isso pode significar tesouros comunitários ou programas de incentivo que se aplicam às chains CDK. Por exemplo, pode haver um programa de Mineração do Ecossistema Polygon onde recompensas de mineração de liquidez são oferecidas a projetos que implantam em novas chains CDK para impulsionar o uso. A ideia é garantir que as novas chains não sejam cidades fantasmas.
  • Histórias de Sucesso: Já, várias chains CDK estão ativas ou anunciadas: OKB Chain (X Layer) da OKX, chain da Gnosis Pay, zkEVM da Astar, migração da Palm Network, GameSwift (chain de jogos), etc. A Polygon divulga ativamente estes e compartilha o conhecimento deles com outros.

No geral, a estratégia da Polygon é “faremos o que for preciso para ajudá-lo a ter sucesso se você construir em nossa pilha.” Isso inclui incentivos financeiros, mão de obra técnica, exposição de marketing (espaços para palestras em conferências, comunicados de imprensa no CoinTelegraph como vimos) e integração em um ecossistema maior. É uma abordagem muito impulsionada pelo desenvolvimento de negócios, além da comunidade de desenvolvedores de base, refletindo o estilo mais corporativo da Polygon em relação aos outros.

Para resumir o suporte ao ecossistema: Todas essas estruturas entendem que atrair desenvolvedores e projetos requer mais do que tecnologia – precisa de financiamento, acompanhamento e integração em uma narrativa maior. A Optimism promove uma narrativa colaborativa focada em bens públicos com partilha de receita justa. A zkSync promove o ângulo da tecnologia de ponta e provavelmente anunciará incentivos alinhados com um futuro token. A Arbitrum aproveita seu domínio existente e fornece redes de parceiros para facilitar o lançamento, além da liquidez DeFi possivelmente mais profunda para explorar. A Polygon, indiscutivelmente, vai mais longe em suavizar o caminho para jogadores nativos de cripto e empresariais, efetivamente subsidiando e co-comercializando chains.

Um instantâneo comparativo ilustrativo:

Como a tabela sugere, cada ecossistema tem seus pontos fortes – a Optimism com ethos colaborativo e o peso da Coinbase, a zkSync com liderança em ZK e foco em inovação, a Arbitrum com adoção comprovada e proeza técnica (Stylus), a Polygon com conexões corporativas e suporte abrangente. Todos estão injetando recursos significativos no crescimento de suas comunidades, porque, em última análise, o sucesso de uma estrutura de rollup é medido pelos aplicativos e usuários nas chains construídas com ela.

Implantações e Adoção em 2025​

Finalmente, vamos ver onde essas estruturas se encontram em termos de adoção no mundo real em 2025 – tanto no contexto nativo de cripto (redes públicas, projetos de DeFi/NFT/jogos) quanto no uso empresarial ou institucional:

• Adoção do OP Stack: O OP Stack impulsionou a Mainnet da Optimism, que por si só é uma das principais L2s do Ethereum com um ecossistema DeFi próspero (Uniswap, Aave, etc.) e dezenas de milhares de usuários diários. Em 2023–2024, o OP Stack foi escolhido pela Coinbase para sua rede Base – a Base foi lançada em agosto de 2023 e rapidamente integrou aplicativos populares (a própria integração de carteira da Coinbase, o aplicativo social friend.tech) e alcançou alta atividade (às vezes até superando a Optimism em transações). O sucesso da Base validou o OP Stack para muitos; a Base teve 800 milhões de transações em 2024, tornando-se a segunda chain com maior contagem de transações naquele ano. Outra grande implantação do OP Stack é o opBNB – a equipe da BNB Chain da Binance criou uma L2 usando o OP Stack (mas liquidando na BNB Chain em vez do Ethereum). O opBNB foi ao ar em 2023, indicando a flexibilidade do OP Stack para usar uma liquidação não-Ethereum. A chain World ID da Worldcoin foi ao ar no OP Stack (liquidando no Ethereum) em 2023 para lidar com suas transações de identidade biométrica únicas. A Zora Network, uma chain centrada em NFT da Zora, também foi lançada no OP Stack, adaptada para casos de uso da economia de criadores. Talvez a mais ambiciosa seja a migração da Celo: a Celo votou para fazer a transição de uma L1 independente para uma L2 do Ethereum construída no OP Stack – em 2025, essa migração está em andamento, trazendo efetivamente todo um ecossistema existente (os aplicativos DeFi e focados em telefone da Celo) para o rebanho do OP Stack. Também temos projetos menores como Mode (side chain da Bybit), Mantle (chain da BitDAO) – na verdade, a Mantle também optou por um OP Stack modificado. E muitos mais estão rumores ou em desenvolvimento, dada a abordagem de código aberto da Optimism (qualquer um pode bifurcar e lançar sem permissão). No lado empresarial, não vimos muitas chains empresariais explícitas do OP Stack (as empresas parecem mais atraídas pela Polygon ou soluções personalizadas). No entanto, a Base é um apoio empresarial (Coinbase), e isso é significativo. A visão da Superchain implica que até mesmo chains empresariais podem se juntar como OP Chains para se beneficiar da governança compartilhada – por exemplo, se alguma fintech quisesse lançar uma chain compatível, usar o OP Stack e se conectar à Superchain poderia lhe dar conectividade pronta. Em 2025, as chains OP Stack coletivamente (Optimism, Base, outras) lidam com uma porção significativa da atividade L2, e o throughput agregado da Superchain é apresentado como uma métrica (a Optimism frequentemente publica estatísticas combinadas). Com a atualização Bedrock e melhorias adicionais, as chains OP Stack estão provando alta confiabilidade (a Optimism teve tempo de inatividade insignificante). A principal medida de adoção: o OP Stack é indiscutivelmente a estrutura de rollup mais bifurcada até agora, dadas a Base, BNB, Celo, etc., que são de alto perfil. No total, cerca de 5 a 10 chains OP Stack estão em mainnets ativas, e muitas mais em testnets. Se incluirmos devnets e lançamentos futuros, o número cresce.

• Adoção das Hyperchains zkSync: A mainnet do zkSync Era (L2) foi lançada em março de 2023 e, em 2025, está entre os principais ZK rollups, com aproximadamente US$ 100 milhões em TVL e dezenas de projetos. Aplicativos notáveis como Curve, Uniswap, Chainlink implantaram ou anunciaram implantação no zkSync. Agora, em relação às Hyperchains (L3 ou chains soberanas), isso é muito inovador. No final de 2024, a Matter Labs lançou um programa para equipes experimentarem L3s sobre o zkSync. Um exemplo: o provedor de Rollup-as-a-Service Decentriq estava supostamente testando uma Hyperchain privada para compartilhamento de dados. Além disso, a Blockchain Capital (VC) deu a entender que estava experimentando uma L3. Temos a menção de que um ecossistema de mais de 18 protocolos está aproveitando o ZK Stack para coisas como agentes de IA e casos de uso especializados – possivelmente em testnets. Nenhuma Hyperchain importante está servindo publicamente aos usuários ainda (até onde se sabe em meados de 2025). No entanto, o interesse é alto em domínios específicos: projetos de jogos mostraram interesse em hyperchains ZK para finalidade rápida e personalização, e chains orientadas à privacidade (uma Hyperchain poderia incluir criptografia e usar provas ZK para ocultar dados – algo que um rollup otimista não pode oferecer tão facilmente). O comentário sobre um “banco suíço” sugere que talvez o UBS ou um consórcio esteja testando uma chain privada usando o ZK Stack, provavelmente atraído pelo throughput (aproximadamente 10k TPS) e privacidade. Se isso passar para a produção, seria um caso empresarial emblemático. Em resumo, a adoção das Hyperchains do zkSync em 2025 está em um estágio piloto inicial: a infraestrutura de desenvolvedor está pronta (como evidenciado pela documentação e algumas implantações de teste), mas estamos esperando os primeiros a entrarem em operação. É comparável a onde a Optimism estava no início de 2021 – tecnologia comprovada, mas apenas começando a adoção. Até o final de 2025, poderíamos esperar algumas Hyperchains ativas, possivelmente uma impulsionada pela comunidade (talvez uma Hyperchain de jogos derivada de um jogo popular do zkSync) e uma impulsionada por empresas. Outro fator: fala-se de Layer3s no zkSync Era também – essencialmente L3s sem permissão onde qualquer um pode implantar uma app-chain sobre a L2 do zkSync. A Matter Labs construiu os contratos para permitir isso, então podemos ver L3s impulsionadas por usuários (como alguém lançando um mini rollup para seu aplicativo específico), o que conta como adoção do ZK Stack.

• Adoção do Arbitrum Orbit: O Arbitrum Orbit viu um aumento de interesse após sua introdução formal em meados de 2023. No final de 2023, cerca de 18 chains Orbit foram divulgadas publicamente, e a Offchain Labs indicou mais de 50 em andamento. Em 2025, algumas das mais proeminentes são:

  • Xai Chain: Uma L3 focada em jogos, agora ativa (mainnet lançada no final de 2023). É usada por desenvolvedores de jogos (como o estúdio Ex Populus) e teve um lançamento de token via Binance Launchpad. Isso indica uma adoção decente (o envolvimento do Binance Launchpad sugere muito interesse do usuário). A Xai usa o modo AnyTrust (para alto TPS).
  • Rari Chain: Uma L3 centrada em NFT da Rarible. Lançou a mainnet em janeiro de 2024. É focada em marketplaces de NFT com recursos como pagamentos com cartão de crédito para gás (via Stripe) e listagens sem gás. Esta chain é uma boa vitrine de personalização da experiência do usuário (como observado, a Gelato fornece transações sem gás, etc., na Rari Chain).
  • Frame: Uma L2 focada em criadores (embora chamada de L2, é provavelmente uma chain Orbit liquidando no Ethereum ou na Arbitrum). Foi lançada no início de 2024 após levantar financiamento.
  • EduChain (pelas comunidades Camelot/GMX): O artigo da Zeeve menciona uma chain EDU com um grande número de projetos – possivelmente um ecossistema para educação on-chain e IA, construído no Orbit.
  • Ape Chain: Não mencionada explicitamente acima, mas o contexto da Zeeve sugere que uma “Ape chain” (talvez da Yuga Labs ou da ApeCoin DAO) existe com US$ 9,86 milhões em TVL e usa APE para gás. Isso poderia ser uma chain Orbit no ecossistema da ApeCoin (o que seria significativo dada a influência da Yuga em NFTs).
  • Outras chains de jogos: por exemplo, a “Muster” L3 da Cometh foi anunciada (uma plataforma de jogos em parceria com a AltLayer). A Syndr Chain para um protocolo de negociação de opções está em testnet como L3 Orbit. A Meliora (protocolo de crédito DeFi) construindo uma L3 Orbit.
  • Muitas delas estão em estágios iniciais (testnet ou mainnet recém-lançada), mas coletivamente indicam que o Orbit está ganhando adoção entre dApps especializados que superaram um ambiente L2 compartilhado ou queriam sua própria governança.
  • No lado empresarial: não há muito barulho aqui. A Arbitrum é mais conhecida pela adoção em DeFi/jogos. No entanto, a tecnologia poderia atrair empresas se elas quisessem uma chain segura pelo Ethereum com confiança flexível (via AnyTrust). É possível que alguma empresa tenha usado silenciosamente a tecnologia da Arbitrum para uma chain privada, mas não tenha divulgado.
  • Pelos números, o maior usuário do Arbitrum Orbit até agora pode ser a Ape Chain (se confirmado) com aproximadamente US$10 milhões em TVL e 17 protocolos nela (de acordo com a Zeeve). Outra é a **EDU chain** com US$ 1,35 milhão em TVL e mais de 30 projetos.
  • O Arbitrum One e o Nova fazem parte dessa narrativa – o fato de as chains Orbit poderem liquidar no Nova (chain social/de jogos ultra barata) ou no One significa que a adoção do Orbit também impulsiona a atividade para essas redes. O Nova tem sido usado para pontos do Reddit, etc. Se as chains Orbit se conectarem ao comitê AnyTrust do Nova, o papel do Nova cresce.
  • Em suma, o Arbitrum Orbit foi além da teoria: dezenas de projetos reais estão construindo nele, focando em jogos, redes sociais e DeFi personalizado. A abordagem da Arbitrum de mostrar casos de uso reais (como Xai, Rari) valeu a pena, e podemos esperar que até o final de 2025 haja possivelmente mais de 50 chains Orbit ativas, algumas com bases de usuários significativas (especialmente se uma das chains de jogos atingir um lançamento de jogo popular).

• Adoção do Polygon CDK: A Polygon anunciou o CDK apenas no segundo semestre de 2023, mas ele se aproveita do sucesso das redes existentes da Polygon. O próprio Polygon zkEVM (beta da mainnet) é essencialmente uma chain CDK operada pela Polygon Labs. Ele viu uma adoção decente (mais de US$ 50 milhões em TVL, grandes protocolos implantados). Mas, além disso, inúmeras chains independentes estão em movimento:

  • A Immutable X (uma grande plataforma de jogos Web3) declarou suporte ao Polygon CDK para permitir que estúdios de jogos criem seus próprios zk-rollups que se conectam à liquidez da Immutable e da Polygon. Essa aliança significa possivelmente dezenas de jogos usando o CDK via Immutable em 2025.
  • A OKX (exchange) lançou a OKB Chain (também conhecida como X Chain) usando o Polygon CDK no final de 2024. Uma chain de exchange pode gerar muitas transações (fluxos de cex para dex, etc.). A OKX escolheu a Polygon presumivelmente pela escalabilidade e porque muitos de seus usuários já usam a Polygon.
  • Canto (chain DeFi) e Astar (sidechain da Polkadot) são mencionados como migrando ou se integrando com o Polygon CDK. A mudança da Canto do Cosmos para a camada da Polygon indica o apelo de compartilhar segurança com o Ethereum via ZK da Polygon.
  • Gnosis Pay: lançou a chain Gnosis Card com o CDK – é uma chain para permitir pagamentos rápidos de stablecoin conectados a um cartão Visa. Isso está ativo e é um uso inovador de fintech.
  • Palm Network: uma chain especializada em NFT originalmente no Ethereum está se mudando para o Polygon CDK (a Palm foi co-fundada pela ConsenSys para NFTs com a DC Comics, etc.).
  • dYdX: Isso é interessante – a dYdX estava construindo sua própria chain Cosmos, mas as informações da Zeeve listam a dYdX sob as chains CDK do AggLayer. Se a dYdX considerasse a Polygon, isso seria enorme (embora, até onde se sabe, a dYdX V4 seja baseada no Cosmos; talvez eles planejem uma integração entre chains ou um pivô futuro).
  • Nubank: um dos maiores bancos digitais do Brasil, aparece na lista da Zeeve. O Nubank havia lançado um token na Polygon anteriormente; uma chain CDK para seu programa de recompensas ou semelhante a CBDC poderia estar em teste.
  • Wirex, IDEX, GameSwift, Aavegotchi, Powerloom, Manta… esses nomes na lista da Zeeve mostram como o alcance do CDK é inter-ecossistema: por exemplo, a Manta (um projeto de privacidade da Polkadot) pode usar o CDK para uma solução ZK voltada para o Ethereum; o Aavegotchi (um jogo de NFT originalmente na Polygon POS) pode obter sua própria chain para a lógica do jogo.
  • A integração com a Celestia no início de 2024 provavelmente atrairá projetos que querem a tecnologia da Polygon, mas com a DA da Celestia – possivelmente alguns projetos do Cosmos (já que a Celestia é baseada no Cosmos) escolherão o Polygon CDK para execução e a Celestia para DA.
  • Empresas: A Polygon tem uma equipe empresarial dedicada. Além dos mencionados (Stripe em stablecoins, fundo da Franklin Templeton na Polygon, governos de países emitindo selos, etc.), com o CDK eles podem prometer às empresas sua própria chain com regras personalizadas. Podemos ver pilotos como a “Polygon Siemens Chain” ou chains governamentais surgindo, embora muitas vezes comecem privadas.
  • A abordagem da Polygon de ser agnóstica em relação à chain (eles até suportam um “modo OP Stack” agora no CDK, segundo a Zeeve!) e não cobrar aluguel, significou uma integração rápida – eles afirmam que mais de 190 projetos estão usando ou considerando o CDK até o primeiro trimestre de 2025. Se mesmo um quarto deles entrar em operação, a Polygon terá uma rede expansiva de chains. Eles se veem não apenas como uma chain, mas como um ecossistema de muitas chains (Polygon 2.0), possivelmente a maior rede desse tipo se tiverem sucesso.
  • Pelos números: no início de 2025, mais de 21 chains estão em mainnet ou testnet usando o CDK, de acordo com o site do AggLayer. Isso deve acelerar ao longo de 2025 à medida que mais migram ou lançam.
  • Podemos esperar alguns lançamentos de alto perfil, por exemplo, uma chain do Reddit (os avatares do Reddit na Polygon POS foram enormes; uma L2 dedicada da Polygon para o Reddit poderia acontecer). Além disso, se alguma moeda digital de banco central (CBDCs) ou projetos governamentais escolherem uma solução de escalonamento, a Polygon está frequentemente nessas conversas – uma chain CDK poderia ser sua escolha para uma L2 permissionada com provas ZK.

Em resumo, o status de adoção em 2025: OP Stack e Arbitrum Orbit têm múltiplas chains ativas com usuários reais e TVL, as hyperchains do zkSync estão prestes a surgir com fortes pilotos de teste, e o Polygon CDK tem muitos na fila e alguns sucessos ativos tanto em cripto quanto em empresas. O espaço está evoluindo rapidamente, e os projetos frequentemente consideram essas estruturas antes de escolher. Também não é um jogo de soma zero – por exemplo, um aplicativo pode usar uma chain OP Stack e uma chain Polygon CDK para diferentes regiões ou propósitos. O futuro da blockchain modular provavelmente envolve a interoperabilidade entre todas essas estruturas. É notável que esforços como LayerZero e agregadores de pontes agora garantem que os ativos se movam relativamente livremente entre Optimism, Arbitrum, Polygon, zkSync, etc., então os usuários podem nem perceber em qual pilha uma chain é construída nos bastidores.

Conclusão​

Rollups-as-a-Service em 2025 oferece um rico menu de opções. O OP Stack fornece uma estrutura de rollup otimista testada em batalha com alinhamento com o Ethereum e o apoio de uma comunidade colaborativa da Superchain. O ZK Stack (Hyperchains) oferece tecnologia de ponta de conhecimento zero com validade modular e escolhas de dados, visando escalabilidade massiva e novos casos de uso como chains privadas ou de Camada-3. O Arbitrum Orbit estende uma arquitetura de rollup otimista altamente otimizada para desenvolvedores, com flexibilidade na disponibilidade de dados e a empolgante adição do Stylus para contratos inteligentes multilíngues. O Polygon CDK capacita projetos a lançar chains zkEVM com interoperabilidade pronta para uso (AggLayer) e o suporte total do ecossistema e dos laços empresariais da Polygon. As zkSync Hyperchains (via ZK Stack) prometem desbloquear a Web3 em escala – múltiplas hyperchains todas seguras pelo Ethereum, cada uma otimizada para seu domínio (seja jogos, DeFi ou social), com conectividade perfeita através da estrutura Elástica do zkSync.

Ao comparar a disponibilidade de dados, vimos todas as estruturas adotando a DA modular – Ethereum para segurança e soluções mais recentes como Celestia, EigenDA ou comitês para throughput. Os designs de sequenciador são inicialmente centralizados, mas estão se movendo em direção à descentralização: Optimism e Arbitrum fornecem filas de fallback L1 e estão habilitando modelos de multi-sequenciador ou validadores sem permissão, enquanto Polygon e zkSync permitem a implantação de consenso personalizado para chains que o desejam. Os modelos de taxas diferem principalmente na filosofia do ecossistema – a partilha de receita da Optimism versus as economias autocontidas de outros – mas todos permitem tokens personalizados e visam minimizar os custos do usuário aproveitando DA mais barata e finalidade rápida (especialmente as chains ZK).

No suporte ao ecossistema, a Optimism promove um coletivo onde cada chain contribui para objetivos compartilhados (financiamento de bens públicos) e se beneficia de atualizações compartilhadas. A Arbitrum aproveita sua comunidade e liquidez prósperas, ajudando ativamente projetos a lançar chains Orbit e integrando-as com seu hub DeFi. A Polygon vai com tudo com recursos, cortejando tanto projetos de cripto quanto corporativos, fornecendo talvez o suporte mais prático e ostentando uma extensa rede de parcerias e fundos. A Matter Labs (zkSync) impulsiona a inovação e atrai aqueles que querem a mais recente tecnologia ZK, e embora seus programas de incentivo sejam menos estruturados publicamente (pendente de um token), ela tem financiamento significativo para implantar e uma forte atração para construtores com mentalidade ZK.

Da perspectiva de um desenvolvedor, lançar um rollup em 2025 é mais acessível do que nunca. Seja a prioridade a equivalência com o EVM e a facilidade (OP Stack, Arbitrum) ou o desempenho máximo e a tecnologia à prova de futuro (ZK Stack, Polygon CDK), as ferramentas e a documentação estão disponíveis. Até mesmo o monitoramento e as ferramentas de desenvolvimento cresceram para suportar essas chains personalizadas – por exemplo, as plataformas RaaS da Alchemy e da QuickNode suportam as pilhas Optimism, Arbitrum e zkSync prontas para uso. Isso significa que as equipes podem se concentrar em seu aplicativo e deixar grande parte do trabalho pesado para essas estruturas.

Olhando para a adoção pública e empresarial, fica claro que os rollups modulares estão passando do experimental para o mainstream. Temos marcas globais como Coinbase, Binance e OKX executando suas próprias chains, grandes protocolos DeFi como o Uniswap se expandindo para múltiplas L2s e possivelmente seus próprios rollups, e até governos e bancos explorando essas tecnologias. A competição (e colaboração) entre OP Stack, ZK Stack, Orbit, CDK, etc., está impulsionando uma inovação rápida – beneficiando, em última análise, o Ethereum ao escalá-lo para alcançar milhões de novos usuários através de rollups personalizados.

Cada estrutura tem sua proposta de valor única:

• OP Stack: Fácil entrada na L2, efeitos de rede compartilhados da Superchain e uma filosofia de “impacto = lucro” via bens públicos.
• ZK Stack: Escalabilidade final com integridade ZK, flexibilidade no design (L2 ou L3, rollup ou validium) e prevenção da fragmentação de liquidez através do modelo de chain Elástica.
• Arbitrum Orbit: Tecnologia comprovada (o Arbitrum One nunca teve uma falha grave), alto desempenho (Nitro + Stylus) e a capacidade de personalizar suposições de confiança (segurança total de rollup ou AnyTrust mais rápido) para diferentes necessidades.
• Polygon CDK: ZK-rollups prontos para uso, apoiados por um dos maiores ecossistemas, com conectividade imediata aos ativos da Polygon/Ethereum e a promessa de futura “liquidez unificada” via AggLayer – efetivamente uma plataforma de lançamento não apenas para uma chain, mas para toda uma economia nessa chain.
• zkSync Hyperchains: Uma visão de escalabilidade de Camada-3 onde até mesmo pequenos aplicativos podem ter sua própria chain segura pelo Ethereum, com sobrecarga mínima, permitindo desempenho de nível Web2 em um ambiente Web3.

Em meados de 2025, estamos vendo o ecossistema modular multi-chain se materializar: dezenas de chains específicas de aplicativos ou setores coexistindo, muitas construídas com essas pilhas. O L2Beat e sites semelhantes agora rastreiam não apenas L2s, mas L3s e chains personalizadas, muitas das quais usam OP Stack, Orbit, CDK ou ZK Stack. Padrões de interoperabilidade estão sendo desenvolvidos para que, quer uma chain use a tecnologia da Optimism ou da Polygon, elas possam se comunicar (projetos como Hyperlane, LayerZero e até a colaboração entre OP e Polygon em sequenciamento compartilhado).

Em conclusão, Rollups-as-a-Service em 2025 amadureceu para um cenário competitivo com OP Stack, ZK Stack, Arbitrum Orbit, Polygon CDK e zkSync Hyperchains, cada um oferecendo estruturas de blockchain robustas e modulares. Eles diferem na abordagem técnica (Otimista vs. ZK), mas todos visam capacitar os desenvolvedores a lançar chains escaláveis e seguras, adaptadas às suas necessidades. A escolha da pilha pode depender das prioridades específicas de um projeto – compatibilidade com EVM, velocidade de finalidade, personalização, alinhamento com a comunidade, etc. – como delineado acima. A boa notícia é que não há falta de opções ou suporte. O roteiro centrado em rollups do Ethereum está sendo realizado através dessas estruturas, anunciando uma era onde lançar uma nova chain não é um feito monumental, mas sim uma decisão estratégica semelhante a escolher um provedor de nuvem ou uma pilha de tecnologia na Web2. As estruturas continuarão a evoluir (por exemplo, antecipamos mais convergência, como o OP Stack adotando provas ZK, o AggLayer da Polygon se conectando a chains não-Polygon, etc.), mas mesmo agora elas garantem coletivamente que a escalabilidade e o crescimento do ecossistema do Ethereum são limitados apenas pela imaginação, não pela infraestrutura.

Fontes:

• Optimism OP Stack – Documentação e posts no Mirror
• zkSync ZK Stack – Documentação do zkSync e posts da Matter Labs
• Arbitrum Orbit – Documentação da Arbitrum, anúncios da Offchain Labs
• Polygon CDK – Documentação técnica da Polygon, relatório do CoinTelegraph
• Comparação geral – Guias da QuickNode (Mar 2025), Zeeve e outros para estatísticas do ecossistema, além de vários blogs de projetos citados acima.

1. Visão Geral da Tecnologia TEE​

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

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

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

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

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

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

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

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

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

2. Aplicações de TEEs na Web3​

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

Contratos Inteligentes que Preservam a Privacidade​

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

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

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

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

Escalabilidade e Computação Off-Chain​

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

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

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

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

Oráculos Seguros e Integridade de Dados​

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

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

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

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

Integridade de Dados e Verificabilidade Off-Chain​

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

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

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

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

3. Projetos Web3 Notáveis que Utilizam TEEs​

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

Secret Network​

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

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

A rede demonstrou vários casos de uso inovadores:

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

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

Oasis Network​

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

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

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

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

Sanders Network​

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

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

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

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

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

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

iExec​

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

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

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

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

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

Outros Projetos e Ecossistemas​

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

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

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

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

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

Benefícios e Pontos Fortes Técnicos​

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

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

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

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

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

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

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

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

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

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

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

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

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

Composabilidade e Limitações do Ecossistema​

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

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

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

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

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

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

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

Para definir brevemente as alternativas:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ethereum (e Camadas 1 em Geral)​

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

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

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

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

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

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

Ecossistema Cosmos​

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

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

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

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

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

Polkadot e Substrate​

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

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

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

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

Outros Ecossistemas e Adoção Geral​

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

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

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

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

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

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

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

Conformidade com a Privacidade e Adoção Institucional​

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

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

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

Confiança e Responsabilidade​

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

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

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

Considerações de Ecossistema e Custo​

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

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

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

Incertezas Regulatórias​

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

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

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

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

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

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

Conclusão​

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

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

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

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

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

Em 7 de maio de 2025, a atualização Pectra do Ethereum (Prague + Electra) chegou à mainnet. Entre suas mudanças mais visíveis para desenvolvedores está o EIP-7702, que permite que uma conta externa (EOA) "monte" lógica de smart-contract—sem migrar fundos ou alterar endereços. Se você constrói carteiras, dapps, ou relayers, isso desbloqueia um caminho mais simples para UX de smart-account.

Abaixo está um guia conciso e focado em implementação: o que realmente foi lançado, como o 7702 funciona, quando escolhê-lo sobre ERC-4337 puro, e um scaffold para copiar e colar que você pode adaptar hoje.

O Que Realmente Foi Lançado​

• EIP-7702 está no escopo final do Pectra. O meta-EIP para o hard fork Pectra lista oficialmente 7702 entre as mudanças incluídas.
• Detalhes de ativação: Pectra foi ativado na mainnet na época 364032 em 7 de maio de 2025, seguindo ativações bem-sucedidas em todas as testnets principais.
• Nota de toolchain: Solidity v0.8.30 atualizou seu alvo EVM padrão para prague para compatibilidade com Pectra. Você precisará atualizar seus compiladores e pipelines CI, especialmente se você fixa versões específicas.

EIP-7702—Como Funciona (Detalhes Técnicos)​

EIP-7702 introduz um novo tipo de transação e um mecanismo para uma EOA delegar sua lógica de execução para um smart contract.

• Novo Tipo de Transação (0x04): Uma transação Tipo-4 inclui um novo campo chamado authorization_list. Esta lista contém uma ou mais tuplas de autorização—(chain_id, address, nonce, y_parity, r, s)—cada uma assinada pela chave privada da EOA. Quando esta transação é processada, o protocolo escreve um indicador de delegação para o campo de código da EOA: 0xef0100 || address. A partir desse ponto, todas as chamadas para a EOA são direcionadas para o address especificado (a implementação), mas executam dentro do contexto de armazenamento e saldo da EOA. Esta delegação permanece ativa até ser explicitamente alterada.
• Escopo de Chain: Uma autorização pode ser específica de chain fornecendo um chain_id, ou pode se aplicar a todas as chains se chain_id for definido como 0. Isso permite que você implemente o mesmo contrato de implementação em várias redes sem exigir que os usuários assinem uma nova autorização para cada uma.
• Revogação: Para reverter uma EOA de volta ao seu comportamento original não-programável, você simplesmente envia outra transação 7702 onde o address de implementação é definido como endereço zero. Isso limpa o indicador de delegação.
• Auto-Patrocinado vs. Relayed: Uma EOA pode submeter a transação Tipo-4 ela mesma, ou um relayer terceiro pode submetê-la em nome da EOA. O último é comum para criar uma experiência de usuário sem gas. O manuseio de nonce difere ligeiramente dependendo do método, então é importante usar bibliotecas que manuseiem corretamente essa distinção.

Mudança no Modelo de Segurança: Como a chave privada EOA original ainda existe, ela sempre pode sobrescrever qualquer regra de smart contract (como recuperação social ou limites de gastos) submetendo uma nova transação 7702 para alterar a delegação. Esta é uma mudança fundamental. Contratos que dependem de tx.origin para verificar que uma chamada é de uma EOA devem ser re-auditados, pois 7702 pode quebrar essas suposições. Audite seus fluxos adequadamente.

7702 ou ERC-4337? (E Quando Combinar)​

Tanto EIP-7702 quanto ERC-4337 habilitam abstração de conta, mas servem necessidades diferentes.

• Escolha EIP-7702 quando…
  • Você quer fornecer UX de smart-account instantânea para EOAs existentes sem forçar usuários a migrar fundos ou alterar endereços.
  • Você precisa de endereços consistentes entre chains que podem ser progressivamente atualizados com novas funcionalidades.
  • Você quer escalonar sua transição para abstração de conta, começando com recursos simples e adicionando complexidade ao longo do tempo.
• Escolha ERC-4337 puro quando…
  • Seu produto requer programabilidade completa e engines de política complexas (ex. multi-sig, recuperação avançada) desde o primeiro dia.
  • Você está construindo para novos usuários que não têm EOAs existentes, tornando novos endereços de smart-account e a configuração associada aceitáveis.
• Combine-os: O padrão mais poderoso é usar ambos. Uma EOA pode usar uma transação 7702 para designar uma implementação de carteira ERC-4337 como sua lógica. Isso faz a EOA se comportar como uma conta 4337, permitindo que ela seja empacotada, patrocinada por paymasters, e processada pela infraestrutura 4337 existente—tudo sem o usuário precisar de um novo endereço. Este é um caminho compatível para frente explicitamente encorajado pelos autores do EIP.

Scaffold 7702 Mínimo Que Você Pode Adaptar​

Aqui está um exemplo prático de um contrato de implementação e o código do lado cliente para ativá-lo.

1. Um Contrato de Implementação Pequeno e Auditável​

Este código de contrato executará no contexto da EOA uma vez designado. Mantenha-o pequeno, auditável, e considere adicionar um mecanismo de upgrade.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @notice Executa chamadas do contexto EOA quando designado via EIP-7702.
contract DelegatedAccount {
    // Slot de armazenamento único para evitar colisões com outros contratos.
    bytes32 private constant INIT_SLOT =
        0x3fb93b3d3dcd1d1f4b4a1a8db6f4c5d55a1b7f9ac01dfe8e53b1b0f35f0c1a01;

    event Initialized(address indexed account);
    event Executed(address indexed to, uint256 value, bytes data, bytes result);

    modifier onlyEOA() {
        // Opcional: adicionar verificações para restringir quem pode chamar certas funções.
        _;
    }

    function initialize() external payable onlyEOA {
        // Definir uma flag de inicialização única no armazenamento da EOA.
        bytes32 slot = INIT_SLOT;
        assembly {
            if iszero(iszero(sload(slot))) { revert(0, 0) } // Reverter se já inicializado
            sstore(slot, 1)
        }
        emit Initialized(address(this));
    }

    function execute(address to, uint256 value, bytes calldata data)
        external
        payable
        onlyEOA
        returns (bytes memory result)
    {
        (bool ok, bytes memory ret) = to.call{value: value}(data);
        require(ok, "CALL_FAILED");
        emit Executed(to, value, data, ret);
        return ret;
    }

    function executeBatch(address[] calldata to, uint256[] calldata value, bytes[] calldata data)
        external
        payable
        onlyEOA
    {
        uint256 n = to.length;
        require(n == value.length && n == data.length, "LENGTH_MISMATCH");
        for (uint256 i = 0; i < n; i++) {
            (bool ok, ) = to[i].call{value: value[i]}(data[i]);
            require(ok, "CALL_FAILED");
        }
    }
}

2. Designar o Contrato numa EOA (tx Tipo-4) com viem​

Clientes modernos como viem têm helpers integrados para assinar autorizações e enviar transações Tipo-4. Neste exemplo, uma conta relayer paga o gas para atualizar uma eoa.

import { createWalletClient, http, encodeFunctionData } from "viem";
import { sepolia } from "viem/chains";
import { privateKeyToAccount } from "viem/accounts";
import { abi, implementationAddress } from "./DelegatedAccountABI";

// 1. Definir o relayer (patrocina gas) e a EOA a ser atualizada
const relayer = privateKeyToAccount(process.env.RELAYER_PK as `0x${string}`);
const eoa = privateKeyToAccount(process.env.EOA_PK as `0x${string}`);

const client = createWalletClient({
  account: relayer,
  chain: sepolia,
  transport: http(),
});

// 2. A EOA assina a autorização apontando para o contrato de implementação
const authorization = await client.signAuthorization({
  account: eoa,
  contractAddress: implementationAddress,
  // Se a EOA fosse enviar isso ela mesma, você adicionaria: executor: 'self'
});

// 3. O relayer envia uma transação Tipo-4 para definir o código da EOA e chamar initialize()
const hash = await client.sendTransaction({
  to: eoa.address, // O destino é a própria EOA
  authorizationList: [authorization], // O novo campo EIP-7702
  data: encodeFunctionData({ abi, functionName: "initialize" }),
});

// 4. Agora, a EOA pode ser controlada via sua nova lógica sem mais autorizações
// Por exemplo, para executar uma transação:
// await client.sendTransaction({
//   to: eoa.address,
//   data: encodeFunctionData({ abi, functionName: 'execute', args: [...] })
// });

3. Revogar Delegação (De Volta para EOA Simples)​

Para desfazer a atualização, faça a EOA assinar uma autorização que designa o endereço zero como implementação e enviar outra transação Tipo-4. Depois, uma chamada para eth_getCode(eoa.address) deve retornar bytes vazios.

Padrões de Integração Que Funcionam em Produção​

• Atualizar no Local para Usuários Existentes: No seu dapp, detecte se o usuário está numa rede compatível com Pectra. Se sim, exiba um botão opcional "Atualizar Conta" que dispara a assinatura de autorização única. Mantenha caminhos de fallback (ex. approve + swap clássicos) para usuários com carteiras mais antigas.
• Onboarding Sem Gas: Use um relayer (seja seu backend ou um serviço) para patrocinar a transação Tipo-4 inicial. Para transações sem gas contínuas, roteie operações de usuário através de um bundler ERC-4337 para aproveitar paymasters existentes e mempools públicas.
• Rollouts Cross-Chain: Use uma autorização chain_id = 0 para designar o mesmo contrato de implementação em todas as chains. Você pode então habilitar ou desabilitar recursos por chain dentro da sua lógica de aplicação.
• Observabilidade: Seu backend deve indexar transações Tipo-4 e analisar a authorization_list para rastrear quais EOAs foram atualizadas. Após uma transação, verifique a mudança chamando eth_getCode e confirmando que o código da EOA agora combina com o indicador de delegação (0xef0100 || implementationAddress).

Modelo de Ameaça & Pegadinhas (Não Pule Isso)​

• Delegação é Persistente: Trate mudanças no contrato de implementação de uma EOA com a mesma gravidade de uma atualização padrão de smart contract. Isso requer auditorias, comunicação clara ao usuário, e idealmente, um fluxo opt-in. Nunca empurre nova lógica para usuários silenciosamente.
• Minas Terrestres de tx.origin: Qualquer lógica que usou msg.sender == tx.origin para garantir que uma chamada veio diretamente de uma EOA agora é potencialmente vulnerável. Este padrão deve ser substituído por verificações mais robustas, como assinaturas EIP-712 ou whitelists explícitas.
• Matemática de Nonce: Quando uma EOA patrocina sua própria transação 7702 (executor: 'self'), seu nonce de autorização e nonce de transação interagem de uma maneira específica. Sempre use uma biblioteca que manuseie isso corretamente para evitar problemas de replay.
• Responsabilidade de UX da Carteira: A especificação EIP-7702 avisa que dapps não devem pedir aos usuários para assinar designações arbitrárias. É responsabilidade da carteira verificar implementações propostas e garantir que são seguras. Projete sua UX para alinhar com este princípio de segurança mediada por carteira.

Quando 7702 é uma Vitória Clara​

• Fluxos DEX: Um approve multi-etapa e swap podem ser combinados em um único clique usando a função executeBatch.
• Jogos & Sessões: Conceda privilégios similares a session-key por tempo limitado ou escopo sem exigir que o usuário crie e financie uma nova carteira.
• Empresa & Fintech: Habilite transações patrocinadas e aplique políticas de gastos customizadas enquanto mantém o mesmo endereço corporativo em cada chain para contabilidade e identidade.
• Pontes L2 & Intents: Crie fluxos de meta-transação mais suaves com uma identidade EOA consistente em diferentes redes.

Estes casos de uso representam os mesmos benefícios centrais prometidos pelo ERC-4337, mas agora estão disponíveis para cada EOA existente com apenas uma autorização única.

Lista de Verificação de Lançamento​

Protocolo​

• Garantir que nós, SDKs, e provedores de infraestrutura suportem transações Tipo-4 e EVM "prague" do Pectra.
• Atualizar indexadores e ferramentas de análise para analisar o campo authorization_list em novas transações.

Contratos​

• Desenvolver um contrato de implementação mínimo e auditado com recursos essenciais (ex. batching, revogação).
• Testar completamente fluxos de revogar e re-designar em testnets antes de implantar na mainnet.

Clientes​

• Atualizar bibliotecas do lado cliente (viem, ethers, etc.) e testar as funções signAuthorization e sendTransaction.
• Verificar que tanto caminhos de transação auto-patrocinados quanto relayed manuseiam nonces e replays corretamente.

Segurança​

• Remover todas as suposições baseadas em tx.origin dos seus contratos e substituí-las por alternativas mais seguras.
• Implementar monitoramento pós-implantação para detectar mudanças de código inesperadas em endereços de usuário e alertar sobre atividade suspeita.

Linha de fundo: EIP-7702 fornece uma rampa de baixo atrito para UX de smart-account para os milhões de EOAs já em uso. Comece com uma implementação pequena e auditada, use um caminho relayed para configuração sem gas, torne a revogação clara e fácil, e você pode entregar 90% dos benefícios da abstração de conta completa—sem a dor de rotação de endereços e migração de ativos.

Iniciativa de Stablecoin da Meta em 2025 – Anúncios e Projetos​

Em maio de 2025, surgiram relatos de que a Meta (anteriormente Facebook) está reentrando no mercado de stablecoins com novas iniciativas focadas em moedas digitais. Embora a Meta não tenha anunciado formalmente uma nova moeda, um relatório da Fortune revelou que a empresa está em discussões com empresas de cripto sobre o uso de stablecoins para pagamentos. Essas discussões ainda são preliminares (a Meta está em "modo de aprendizado"), mas marcam o primeiro movimento significativo da Meta no setor de cripto desde o projeto Libra/Diem de 2019–2022. Notavelmente, a Meta pretende alavancar stablecoins para lidar com pagamentos para criadores de conteúdo e transferências transfronteiriças em suas plataformas.

Posição oficial: A Meta não lançou nenhuma nova criptomoeda própria até maio de 2025. Andy Stone, Diretor de Comunicações da Meta, respondeu aos rumores esclarecendo que "A Diem está 'morta'. Não existe uma stablecoin da Meta.". Isso indica que, em vez de ressuscitar uma moeda interna como a Diem, a abordagem da Meta provavelmente será integrar stablecoins existentes (possivelmente emitidas por empresas parceiras) em seu ecossistema. De fato, fontes sugerem que a Meta pode usar múltiplas stablecoins em vez de uma única moeda proprietária. Em resumo, o projeto em 2025 não é um relançamento da Libra/Diem, mas um novo esforço para suportar stablecoins dentro dos produtos da Meta.

Objetivos Estratégicos e Motivações para a Meta​

A renovada incursão da Meta no mundo cripto é impulsionada por objetivos estratégicos claros. O principal deles é reduzir o atrito e o custo dos pagamentos para transações globais de usuários. Ao usar stablecoins (tokens digitais atrelados 1:1 a uma moeda fiduciária), a Meta pode simplificar pagamentos transfronteiriços e a monetização de criadores para seus mais de 3 bilhões de usuários. As motivações específicas incluem:

• Redução dos Custos de Pagamento: A Meta realiza inúmeros pequenos pagamentos a colaboradores e criadores em todo o mundo. Pagamentos com stablecoins permitiriam que a Meta pagasse a todos em uma única moeda atrelada ao dólar americano, evitando taxas elevadas de transferências bancárias ou conversões de moeda. Por exemplo, um criador na Índia ou na Nigéria poderia receber uma stablecoin em USD em vez de lidar com transferências bancárias internacionais dispendiosas. Isso poderia economizar dinheiro para a Meta (menos taxas de processamento) e acelerar os pagamentos.

• Micropagamentos e Novas Fontes de Receita: As stablecoins permitem microtransações rápidas e de baixo custo. A Meta poderia facilitar gorjetas, compras no aplicativo ou compartilhamento de receita em incrementos minúsculos (centavos ou dólares) sem taxas exorbitantes. Por exemplo, enviar alguns dólares em stablecoin custa apenas frações de centavo em certas redes. Essa capacidade é crucial para modelos de negócios como dar gorjetas a criadores de conteúdo, e-commerce transfronteiriço no Facebook Marketplace ou comprar bens digitais no metaverso.

• Engajamento Global de Usuários: Uma stablecoin integrada ao Facebook, Instagram, WhatsApp, etc., funcionaria como uma moeda digital universal dentro do ecossistema da Meta. Isso pode manter os usuários e seu dinheiro circulando dentro dos aplicativos da Meta (semelhante a como o WeChat usa o WeChat Pay). A Meta poderia se tornar uma grande plataforma de fintech ao gerenciar remessas, compras e pagamentos de criadores internamente. Tal movimento está alinhado com o interesse de longa data do CEO Mark Zuckerberg em expandir o papel da Meta nos serviços financeiros e na economia do metaverso (onde moedas digitais são necessárias para transações).

• Manter a Competitividade: A indústria de tecnologia e finanças em geral está se aquecendo para as stablecoins como infraestrutura essencial. Rivais e parceiros financeiros estão adotando stablecoins, desde o lançamento do PYUSD do PayPal em 2023 até os projetos de stablecoin da Mastercard, Visa e Stripe. A Meta não quer ficar para trás no que alguns veem como o futuro dos pagamentos. Reentrar no mercado de cripto agora permite que a Meta capitalize em um mercado em evolução (as stablecoins podem crescer em US$ 2 trilhões até 2028, segundo o Standard Chartered) e diversifique seus negócios para além da publicidade.

Em resumo, o impulso da Meta para as stablecoins visa cortar custos, desbloquear novos recursos (pagamentos globais rápidos) e posicionar a Meta como um ator-chave na economia digital. Essas motivações ecoam a visão original da Libra de inclusão financeira, mas com uma abordagem mais focada e pragmática em 2025.

Planos de Tecnologia e Infraestrutura de Blockchain​

Diferente do projeto Libra — que envolvia a criação de uma blockchain totalmente nova — a estratégia da Meta para 2025 se inclina para o uso de infraestrutura de blockchain e stablecoins existentes. Segundo relatos, a Meta está considerando a blockchain da Ethereum como uma das bases para essas transações com stablecoins. A Ethereum é atraente devido à sua maturidade e ampla adoção no ecossistema cripto. De fato, a Meta "planeja começar a usar stablecoins na blockchain da Ethereum" para alcançar sua enorme base de usuários. Isso sugere que a Meta pode integrar stablecoins populares baseadas em Ethereum (como USDC ou USDT) em seus aplicativos.

No entanto, a Meta parece aberta a uma abordagem multi-chain ou multi-moeda. A empresa "provavelmente usará mais de um tipo de stablecoin" para diferentes propósitos. Isso poderia envolver:

• Parceria com Grandes Emissores de Stablecoins: A Meta teria estado em conversas com empresas como a Circle (emissora da USDC) e outras. Ela pode suportar o USD Coin (USDC) e o Tether (USDT), as duas maiores stablecoins em USD, para garantir liquidez e familiaridade para os usuários. Integrar stablecoins regulamentadas existentes pouparia a Meta do trabalho de emitir seu próprio token, ao mesmo tempo em que forneceria escala imediata.

• Utilização de Redes Eficientes: A Meta também parece interessada em redes de blockchain de alta velocidade e baixo custo. A contratação de Ginger Baker (mais sobre ela abaixo) sugere essa estratégia. Baker faz parte do conselho da Stellar Development Foundation, e analistas observam que a rede da Stellar é projetada para conformidade e transações baratas. A Stellar suporta nativamente stablecoins regulamentadas e recursos como KYC e relatórios on-chain. Especula-se que a carteira Meta Pay poderia alavancar a Stellar para micropagamentos quase instantâneos (enviar USDC via Stellar custa uma fração de centavo). Em essência, a Meta pode rotear transações através da blockchain que oferecer a melhor combinação de conformidade, velocidade e taxas baixas (Ethereum para ampla compatibilidade, Stellar ou outras para eficiência).

• Transformação da Carteira Meta Pay: Na interface do usuário, a Meta provavelmente está atualizando sua infraestrutura existente do Meta Pay para uma carteira digital "pronta para descentralização". O Meta Pay (anteriormente Facebook Pay) atualmente lida com pagamentos tradicionais nas plataformas da Meta. Sob a liderança de Baker, prevê-se que ele suporte criptomoedas e stablecoins de forma transparente. Isso significa que os usuários poderiam manter saldos de stablecoin, enviá-los a colegas ou receber pagamentos no aplicativo, com a complexidade da blockchain gerenciada nos bastidores.

É importante ressaltar que a Meta não está construindo uma nova moeda ou blockchain do zero desta vez. Ao usar blockchains públicas comprovadas e moedas emitidas por parceiros, a Meta pode lançar a funcionalidade de stablecoin mais rapidamente e com (esperançosamente) menos resistência regulatória. O plano de tecnologia foca na integração em vez da invenção – tecendo stablecoins nos produtos da Meta de uma forma que pareça natural para os usuários (por exemplo, um usuário do WhatsApp pode enviar um pagamento em USDC tão facilmente quanto envia uma foto).

Revivendo a Diem/Novi ou Começando do Zero?​

A iniciativa atual da Meta claramente difere de seu esforço passado com a Libra/Diem. A Libra (anunciada em 2019) era um plano ambicioso para uma moeda global liderada pelo Facebook, lastreada por uma cesta de ativos e governada por uma associação de empresas. Mais tarde, foi renomeada para Diem (uma stablecoin atrelada ao dólar americano), mas acabou sendo encerrada no início de 2022 em meio a uma forte reação regulatória. A Novi, a carteira de cripto que a acompanhava, foi pilotada brevemente, mas também descontinuada.

Em 2025, a Meta não está simplesmente revivendo a Diem/Novi. As principais diferenças na nova abordagem incluem:

• Sem "Moeda da Meta" Interna (Por Enquanto): Durante a Libra, o Facebook estava essencialmente criando sua própria moeda. Agora, os porta-vozes da Meta enfatizam que "não há stablecoin da Meta" em desenvolvimento. A Diem está morta e não será ressuscitada. Em vez disso, o foco está em usar stablecoins existentes (emitidas por terceiros) como ferramentas de pagamento. Essa mudança de emissor para integrador é uma lição direta do fracasso da Libra – a Meta está evitando a aparência de cunhar seu próprio dinheiro.

• Estratégia Focada em Conformidade: A visão ampla da Libra assustou os reguladores, que temiam que uma moeda privada para bilhões de pessoas pudesse minar as moedas nacionais. Hoje, a Meta está operando de forma mais discreta e cooperativa. A empresa está contratando especialistas em conformidade e fintech (por exemplo, Ginger Baker) e escolhendo tecnologias conhecidas pela conformidade regulatória (por exemplo, Stellar). Quaisquer novos recursos de stablecoin provavelmente exigirão verificação de identidade e aderirão às regulamentações financeiras em cada jurisdição, em contraste com a abordagem inicialmente descentralizada da Libra.

• Reduzindo as Ambições (Pelo Menos Inicialmente): A Libra pretendia ser uma moeda e um sistema financeiro universal. O esforço da Meta em 2025 tem um escopo inicial mais restrito: pagamentos e transferências peer-to-peer dentro das plataformas da Meta. Ao visar pagamentos de criadores (como micropagamentos de "até US$ 100" no Instagram), a Meta está encontrando um caso de uso que tem menos probabilidade de alarmar os reguladores do que uma moeda global em grande escala. Com o tempo, isso pode se expandir, mas o lançamento deve ser gradual e orientado por casos de uso, em vez de um lançamento "Big Bang" de uma nova moeda.

• Sem Associação Pública ou Nova Blockchain: A Libra era gerenciada por uma associação independente e exigia que parceiros executassem nós em uma blockchain totalmente nova. A nova abordagem não envolve a criação de um consórcio ou uma rede personalizada. A Meta está trabalhando diretamente com empresas de cripto estabelecidas e alavancando sua infraestrutura. Essa colaboração nos bastidores significa menos publicidade e potencialmente menos alvos regulatórios do que a coalizão altamente pública da Libra.

Em resumo, a Meta está começando do zero, usando as lições da Libra/Diem para traçar um curso mais pragmático. A empresa essencialmente pivotou de "tornar-se uma emissora de cripto" para "ser uma plataforma amigável a cripto". Como observou um analista de cripto, se a Meta "constrói e emite sua própria [stablecoin] ou faz parceria com alguém como a Circle ainda está para ser determinado" – mas todos os sinais apontam para parcerias em vez de um empreendimento solo como a Diem.

Pessoal-Chave, Parcerias e Colaborações​

A Meta fez contratações estratégicas e prováveis parcerias para impulsionar esta iniciativa de stablecoin. A movimentação de pessoal de destaque é a adição de Ginger Baker como Vice-Presidente de Produto para pagamentos e cripto da Meta. Baker ingressou na Meta em janeiro de 2025 especificamente para "ajudar a conduzir as explorações de stablecoin [da Meta]". Seu histórico é um forte indicador da estratégia da Meta:

• Ginger Baker – Veterana de Fintech: Baker é uma executiva de pagamentos experiente. Ela trabalhou anteriormente na Plaid (como Diretora de Rede) e tem experiência na Ripple, Square e Visa – todos grandes players em pagamentos/cripto. De forma única, ela também atuou no conselho da Stellar Development Foundation e foi executiva lá. Ao contratar Baker, a Meta ganha expertise tanto em fintech tradicional quanto em redes de blockchain (Ripple e Stellar são focadas em transações transfronteiriças e conformidade). Baker está agora "liderando as renovadas iniciativas de stablecoin da Meta", incluindo a transformação do Meta Pay em uma carteira pronta para cripto. Sua liderança sugere que a Meta construirá um produto que une pagamentos convencionais com cripto (provavelmente garantindo que coisas como integrações bancárias, UX suave, KYC, etc., estejam no lugar ao lado dos elementos de blockchain).

• Outros Membros da Equipe: Além de Baker, a Meta está "adicionando indivíduos com experiência em cripto" às suas equipes para apoiar os planos de stablecoin. Alguns ex-membros da equipe Libra/Diem podem estar envolvidos nos bastidores, embora muitos tenham saído (por exemplo, o ex-chefe da Novi, David Marcus, saiu para iniciar sua própria empresa de cripto, e outros foram para projetos como o Aptos). O esforço atual parece estar em grande parte sob a unidade existente da Meta, a Meta Financial Technologies (que administra o Meta Pay). Nenhuma grande aquisição de empresas de cripto foi anunciada em 2025 até agora – a Meta parece estar contando com contratações internas e parcerias em vez de comprar uma empresa de stablecoin diretamente.

• Parcerias Potenciais: Embora nenhum parceiro oficial tenha sido nomeado ainda, várias empresas de cripto estiveram em conversas com a Meta. Pelo menos dois executivos de empresas de cripto confirmaram que tiveram discussões iniciais com a Meta sobre pagamentos com stablecoins. É razoável especular que a Circle (emissora da USDC) está entre elas – o relatório da Fortune mencionou as atividades da Circle no mesmo contexto. A Meta poderia fazer parceria com um emissor de stablecoin regulamentado (como Circle ou Paxos) para lidar com a emissão e custódia da moeda. Por exemplo, a Meta poderia integrar a USDC trabalhando com a Circle, de forma semelhante a como o PayPal fez parceria com a Paxos para lançar sua própria stablecoin. Outras parcerias podem envolver provedores de infraestrutura de cripto (para segurança, custódia ou integração de blockchain) ou empresas de fintech em diferentes regiões para conformidade.

• Consultores/Influenciadores Externos: Vale a pena notar que o movimento da Meta ocorre enquanto outros no setor de tecnologia/finanças intensificam os esforços com stablecoins. Empresas como Stripe e Visa fizeram movimentos recentes (a Stripe comprou uma startup de cripto, a Visa fez parceria com uma plataforma de stablecoin). A Meta pode não se associar formalmente a essas empresas, mas essas conexões da indústria (por exemplo, o passado de Baker na Visa, ou as relações comerciais existentes que a Meta tem com a Stripe para pagamentos) poderiam facilitar o caminho para a adoção de stablecoins. Além disso, a First Digital (emissora da FDUSD) e a Tether podem ver uma colaboração indireta se a Meta decidir apoiar suas moedas para certos mercados.

Em essência, a iniciativa de stablecoin da Meta está sendo liderada por insiders experientes de fintech e provavelmente envolve uma colaboração próxima com players de cripto estabelecidos. Vemos um esforço deliberado para trazer pessoas que entendem tanto do Vale do Silício quanto do mundo cripto. Isso é um bom presságio para a Meta navegar pelos desafios técnicos e regulatórios com orientação experiente.

Estratégia Regulatória e Posicionamento​

A regulamentação é o elefante na sala para as ambições de cripto da Meta. Após a experiência contundente com a Libra (onde reguladores e legisladores globais se opuseram quase unanimemente à moeda do Facebook), a Meta está adotando uma postura muito cautelosa e focada em conformidade em 2025. Os elementos-chave do posicionamento regulatório da Meta incluem:

• Trabalhando Dentro dos Quadros Regulatórios: A Meta parece determinada a trabalhar com as autoridades em vez de tentar contorná-las. Ao usar stablecoins regulamentadas existentes (como a USDC, que cumpre as regulamentações estaduais dos EUA e passa por auditorias) e ao incorporar recursos de KYC/AML, a Meta está se alinhando com as regras financeiras atuais. Por exemplo, os recursos de conformidade da Stellar (KYC, triagem de sanções) são explicitamente observados como alinhados com a necessidade da Meta de se manter em boas graças com os reguladores. Isso sugere que a Meta garantirá que os usuários que transacionam em stablecoins através de seus aplicativos sejam verificados e que as transações possam ser monitoradas para atividades ilícitas, de forma semelhante a qualquer aplicativo de fintech.

• Momento Político: O clima regulatório nos EUA mudou desde os dias da Libra. Em 2025, a administração do presidente Donald Trump é vista como mais amigável às criptomoedas do que a administração anterior de Biden. Essa mudança potencialmente dá à Meta uma abertura. De fato, o novo impulso da Meta surge justamente quando Washington está debatendo ativamente a legislação sobre stablecoins. Um par de projetos de lei sobre stablecoins está tramitando no Congresso, e o GENIUS Act do Senado visa estabelecer diretrizes para stablecoins. A Meta pode estar esperando que um quadro legal mais claro legitime o envolvimento corporativo em moedas digitais. No entanto, isso não está isento de oposição – a senadora Elizabeth Warren e outros legisladores destacaram a Meta, pedindo que as grandes empresas de tecnologia sejam impedidas de emitir stablecoins em qualquer nova lei. A Meta terá que navegar por tais obstáculos políticos, possivelmente enfatizando que não está emitindo uma nova moeda, mas apenas usando as existentes (portanto, tecnicamente não é a "Moeda do Facebook" que preocupou o Congresso).

• Conformidade Global e Local: Além dos EUA, a Meta considerará as regulamentações em cada mercado. Por exemplo, se introduzir pagamentos com stablecoin no WhatsApp para remessas, poderá pilotar isso em países com reguladores receptivos (semelhante a como o WhatsApp Pay foi lançado em mercados como Brasil ou Índia com aprovação local). A Meta pode se envolver com bancos centrais e reguladores financeiros em regiões-alvo para garantir que sua integração de stablecoin atenda aos requisitos (como ser totalmente lastreada em moeda fiduciária, resgatável e não prejudicar a estabilidade da moeda local). O First Digital USD (FDUSD), uma das stablecoins que a Meta poderia suportar, é baseado em Hong Kong e opera sob as leis de trust daquela jurisdição, o que sugere que a Meta pode alavancar regiões com regras amigáveis a cripto (por exemplo, Hong Kong, Singapura) para as fases iniciais.

• Evitando o "Erro da Libra": Com a Libra, os reguladores estavam preocupados que a Meta controlaria uma moeda global fora do controle governamental. A estratégia da Meta agora é posicionar-se como participante, não como controladora. Ao dizer "não há stablecoin da Meta", a empresa se distancia da ideia de imprimir dinheiro. Em vez disso, a Meta pode argumentar que está melhorando a infraestrutura de pagamentos para os usuários, de forma análoga a oferecer suporte para PayPal ou cartões de crédito. Essa narrativa — "estamos apenas usando moedas seguras e totalmente reservadas como a USDC para ajudar os usuários a transacionar" — é provavelmente como a Meta apresentará o projeto aos reguladores para dissipar os temores de desestabilizar o sistema monetário.

• Conformidade e Licenciamento: Se a Meta decidir oferecer uma stablecoin de marca própria ou custodiar as criptomoedas dos usuários, ela poderá buscar as licenças apropriadas (por exemplo, tornar-se um transmissor de dinheiro licenciado, obter uma carta de autorização estadual ou federal para emissão de stablecoin por meio de uma subsidiária ou banco parceiro). Há precedentes: o PayPal obteve uma carta de trust de Nova York (através da Paxos) para sua stablecoin. A Meta poderia, de forma semelhante, fazer parceria ou criar uma entidade regulamentada para quaisquer aspectos de custódia. Por enquanto, ao fazer parceria com emissores de stablecoins e bancos estabelecidos, a Meta pode contar com suas aprovações regulatórias.

No geral, a abordagem da Meta pode ser vista como "acomodação regulatória" – ela está tentando projetar o projeto para se encaixar nos quadros legais que os reguladores construíram ou estão construindo. Isso inclui contato proativo, escalonamento lento e o emprego de especialistas que conhecem as regras. Dito isso, a incerteza regulatória continua sendo um risco. A empresa estará observando de perto o resultado dos projetos de lei sobre stablecoins e provavelmente se envolverá em discussões políticas para garantir que possa avançar sem obstáculos legais.

Impacto no Mercado e Análise do Cenário de Stablecoins​

A entrada da Meta no mercado de stablecoins pode ser um divisor de águas para o mercado, que no início de 2025 já está em expansão. A capitalização de mercado total das stablecoins atingiu um recorde histórico de cerca de US$ 238–245 bilhões em abril de 2025, aproximadamente o dobro do tamanho de um ano antes. Este mercado é atualmente dominado por alguns players-chave:

• Tether (USDT): A maior stablecoin, com quase 70% de participação de mercado e cerca de US$ 148 bilhões em circulação em abril. O USDT é emitido pela Tether Ltd. e é amplamente utilizado no trading de cripto e na liquidez entre exchanges. É conhecido por ter menos transparência em suas reservas, mas manteve sua paridade.

• USD Coin (USDC): A segunda maior, emitida pela Circle (em parceria com a Coinbase) com cerca de US$ 62 bilhões em oferta (≈26% de participação de mercado). A USDC é regulamentada nos EUA, totalmente reservada em dinheiro e títulos do tesouro, e favorecida por instituições por sua transparência. É usada tanto no trading quanto em um número crescente de aplicativos de fintech convencionais.

• First Digital USD (FDUSD): Um participante mais recente (lançado em meados de 2023) emitido pela First Digital Trust de Hong Kong. O FDUSD cresceu como uma alternativa em plataformas como a Binance após problemas regulatórios atingirem o BUSD da própria Binance. Em abril de 2025, a capitalização de mercado do FDUSD era de cerca de US$1,25 bilhão. Teve alguma volatilidade (perdendo brevemente sua paridade de US$ 1 em abril), mas é promovido por ser baseado em um ambiente regulatório mais amigável na Ásia.

A tabela abaixo compara a integração de stablecoin prevista pela Meta com USDT, USDC e FDUSD:

Impacto Projetado: Se a Meta lançar com sucesso os pagamentos com stablecoins, isso poderá expandir significativamente o alcance e o uso de stablecoins. Os aplicativos da Meta podem integrar centenas de milhões de novos usuários de stablecoins que nunca usaram cripto antes. Essa adoção em massa poderia aumentar a capitalização de mercado geral das stablecoins para além dos líderes atuais. Por exemplo, se a Meta fizer parceria com a Circle para usar a USDC em grande escala, a demanda pela USDC poderia aumentar – potencialmente desafiando o domínio do USDT ao longo do tempo. É plausível que a Meta possa ajudar a USDC (ou qualquer moeda que adote) a se aproximar do tamanho da Tether, fornecendo casos de uso fora do trading (comércio social, remessas, etc.).

Por outro lado, o envolvimento da Meta pode estimular a competição e a inovação entre as stablecoins. A Tether e outros incumbentes podem se ajustar melhorando a transparência ou formando suas próprias alianças com grandes empresas de tecnologia. Novas stablecoins podem surgir, adaptadas para redes sociais. Além disso, o suporte da Meta a múltiplas stablecoins sugere que nenhuma moeda única "monopolizará" o ecossistema da Meta – os usuários podem transacionar de forma transparente com diferentes tokens de dólar, dependendo da região ou preferência. Isso poderia levar a um mercado de stablecoins mais diversificado, onde o domínio é distribuído.

Também é importante notar o impulso de infraestrutura que a Meta poderia fornecer. Uma stablecoin integrada à Meta provavelmente precisará de uma capacidade robusta para milhões de transações diárias. Isso poderia impulsionar melhorias nas blockchains subjacentes (por exemplo, escalabilidade de Camada 2 da Ethereum ou aumento do uso da rede Stellar). Observadores já sugerem que o movimento da Meta poderia "aumentar a atividade na [Ethereum] e a demanda por ETH" se um grande volume de transações fluir por lá. Da mesma forma, se a Stellar for usada, seu token nativo XLM poderia ver uma maior demanda como gás para transações.

Finalmente, a entrada da Meta é uma faca de dois gumes para a indústria de cripto: ela legitima as stablecoins como um mecanismo de pagamento (potencialmente positivo para a adoção e o crescimento do mercado), mas também aumenta as apostas regulatórias. Os governos podem tratar as stablecoins mais como uma questão de importância nacional se bilhões de usuários de mídias sociais começarem a transacionar com elas. Isso poderia acelerar a clareza regulatória – ou repressões – dependendo de como o lançamento da Meta ocorrer. De qualquer forma, o cenário de stablecoins até o final da década de 2020 provavelmente será remodelado pela participação da Meta, juntamente com outros grandes players como PayPal, Visa e bancos tradicionais que se aventuram neste espaço.

Integração nas Plataformas da Meta (Facebook, Instagram, WhatsApp, etc.)​

Um aspecto crítico da estratégia da Meta é a integração transparente de pagamentos com stablecoins em sua família de aplicativos. O objetivo é incorporar a funcionalidade de moeda digital de forma amigável no Facebook, Instagram, WhatsApp, Messenger e até mesmo em novas plataformas como o Threads. Veja como a integração deve ocorrer em cada serviço:

• Instagram: O Instagram está posicionado para ser um campo de testes para pagamentos com stablecoins. Criadores no Instagram poderiam optar por receber seus ganhos (por bônus do Reels, vendas de afiliados, etc.) em uma stablecoin em vez de moeda local. Relatos mencionam especificamente que a Meta pode começar pagando até ~US$ 100 para criadores via stablecoins no Instagram. Isso sugere um foco em pequenos pagamentos transfronteiriços – ideal para influenciadores em países onde receber dólares americanos diretamente é preferível. Além disso, o Instagram poderia permitir gorjetas para criadores no aplicativo usando stablecoins, ou permitir que usuários comprem colecionáveis digitais e serviços com um saldo de stablecoin. Como o Instagram já experimentou recursos de exibição de NFTs (em 2022) e possui um marketplace de criadores, adicionar uma carteira de stablecoin poderia aprimorar seu ecossistema de criadores.

• Facebook (Meta): No próprio Facebook, a integração de stablecoins pode se manifestar nos recursos do Facebook Pay/Meta Pay. Usuários no Facebook poderiam enviar dinheiro uns aos outros em chats usando stablecoins, ou doar para campanhas de arrecadação de fundos com cripto. O Facebook Marketplace (onde as pessoas compram/vendem bens) poderia suportar transações com stablecoins, permitindo um comércio transfronteiriço mais fácil ao eliminar problemas de câmbio. Outra área são os jogos e aplicativos no Facebook – desenvolvedores poderiam ser pagos em stablecoins, ou compras no jogo poderiam utilizar uma stablecoin para uma experiência universal. Dada a ampla base de usuários do Facebook, integrar uma carteira de stablecoin no perfil ou no Messenger poderia rapidamente popularizar o conceito de enviar "dólares digitais" para amigos e familiares. As próprias postagens da Meta sugerem a monetização de conteúdo: por exemplo, pagar bônus a criadores de conteúdo do Facebook ou as Estrelas (tokens de gorjeta do Facebook) sendo potencialmente lastreadas por stablecoins no futuro.

• WhatsApp: Esta é talvez a integração mais transformadora. O WhatsApp tem mais de 2 bilhões de usuários e é amplamente utilizado para mensagens em regiões onde as remessas são cruciais (Índia, América Latina, etc.). A stablecoin da Meta poderia transformar o WhatsApp em uma plataforma global de remessas. Os usuários poderiam enviar uma stablecoin para um contato tão facilmente quanto enviam uma mensagem de texto, com o WhatsApp lidando com a conversão de moeda em cada ponta, se necessário. De fato, o WhatsApp pilotou brevemente a carteira Novi em 2021 para enviar uma stablecoin (USDP) nos EUA e na Guatemala – então o conceito foi provado em pequena escala. Agora, a Meta poderia incorporar transferências de stablecoin nativamente na interface do WhatsApp. Por exemplo, um trabalhador indiano nos EUA poderia enviar USDC via WhatsApp para a família na Índia, que poderia então sacar ou gastar se houver integrações com provedores de pagamento locais. Isso contorna as caras taxas de remessa. Além do P2P, pequenas empresas no WhatsApp (comuns em mercados emergentes) poderiam aceitar pagamentos com stablecoins por mercadorias, usando-o como um sistema de pagamento de baixo custo para comerciantes. A análise do Altcoin Buzz até especula que o WhatsApp será um dos próximos pontos de integração após os pagamentos aos criadores.

• Messenger: Semelhante ao WhatsApp, o Facebook Messenger poderia permitir o envio de dinheiro em chats usando stablecoins. O Messenger já possui pagamentos fiduciários peer-to-peer nos EUA. Se estendido para stablecoins, poderia conectar usuários internacionalmente. Poderíamos imaginar chatbots ou atendimento ao cliente no Messenger usando transações com stablecoins (por exemplo, pagar uma conta ou encomendar produtos por meio de uma interação no Messenger e liquidar em stablecoin).

• Threads e Outros: O Threads (plataforma semelhante ao Twitter da Meta, lançada em 2023) e o mais amplo Meta VR/Metaverso (Reality Labs) também podem alavancar stablecoins. No Horizon Worlds ou em outras experiências do metaverso, uma stablecoin poderia servir como a moeda do mundo para comprar bens virtuais, ingressos para eventos, etc., fornecendo um equivalente em dinheiro real que viaja entre as experiências. Embora a unidade de metaverso da Meta esteja atualmente operando com prejuízo, integrar uma moeda aceita em jogos e mundos poderia criar uma economia unificada que poderia estimular o uso (assim como o Roblox tem o Robux, mas no caso da Meta seria uma stablecoin em USD nos bastidores). Isso se alinharia com a visão de Zuckerberg da economia do metaverso, sem criar um novo token apenas para VR.

Estratégia de Integração: A Meta provavelmente lançará isso com cuidado. Uma sequência plausível é:

1. Pilotar pagamentos a criadores no Instagram (quantia limitada, regiões selecionadas) – isso testa o sistema com valor real sendo enviado, mas de forma controlada.
2. Expandir para transferências P2P em mensagens (WhatsApp/Messenger) assim que a confiança for conquistada – começando com corredores de remessas ou dentro de certos países.
3. Pagamentos e serviços para comerciantes – permitindo que empresas em suas plataformas transacionem em stablecoin (isso pode envolver parcerias com processadores de pagamento para permitir a conversão fácil para moeda fiduciária local).
4. Integração completa no ecossistema – eventualmente, a carteira Meta Pay de um usuário poderia mostrar um saldo de stablecoin que pode ser usado em qualquer lugar, desde anúncios do Facebook, compras no Instagram, pagamentos no WhatsApp, etc.

Vale a pena notar que a experiência do usuário será fundamental. A Meta provavelmente abstrairá termos como "USDC" ou "Ethereum" do usuário médio. A carteira pode simplesmente exibir um saldo em "USD" (alimentado por stablecoins no backend) para simplificar. Apenas usuários mais avançados poderiam interagir com funções on-chain (como sacar para uma carteira de cripto externa), se permitido. A vantagem da Meta é sua enorme base de usuários; se até mesmo uma fração adotar o recurso de stablecoin, poderia superar a população atual de usuários de cripto.

Em conclusão, o plano da Meta de integrar stablecoins em suas plataformas poderia dissolver a linha entre pagamentos digitais tradicionais e criptomoedas. Um usuário do Facebook ou WhatsApp pode em breve estar usando uma stablecoin sem nem perceber que é um ativo de cripto – eles apenas verão uma maneira mais rápida e barata de enviar dinheiro e transacionar globalmente. Essa integração profunda poderia diferenciar os aplicativos da Meta em mercados onde a infraestrutura financeira é cara ou lenta, e posiciona a Meta como um concorrente formidável tanto para empresas de fintech quanto para exchanges de cripto no domínio dos pagamentos digitais.

Fontes:

• Conversas exploratórias da Meta sobre stablecoin e contratação de um VP de cripto
• Intenção da Meta de usar stablecoins para pagamentos transfronteiriços a criadores (relatório da Fortune)
• Comentário do diretor de comunicações da Meta ("A Diem está morta, não há stablecoin da Meta")
• Análise das motivações estratégicas da Meta (redução de custos, moeda única para pagamentos)
• Escolhas de infraestrutura tecnológica – integração com Ethereum e recursos de conformidade da Stellar
• Papel e histórico de Ginger Baker (ex-Plaid, Ripple, conselho da Stellar)
• Informações da Fortune/LinkedIn sobre a equipe de cripto da Meta e parcerias em discussão
• Contexto regulatório: colapso da Libra em 2022 e ambiente mais amigável em 2025 sob Trump vs. oposição legislativa (Sen. Warren sobre a proibição de stablecoins de Big Techs)
• Dados do mercado de stablecoins (Q2 2025): capitalização de mercado de ~$238B, USDT ~$148B vs USDC ~$62B, tendências de crescimento
• Informações comparativas para USDT, USDC, FDUSD (participação de mercado, postura regulatória, emissores)
• Detalhes de integração nos produtos da Meta (pagamentos a criadores de conteúdo, pagamentos no WhatsApp).

Introdução​

A Ika é uma rede de Computação Multi-Partes (MPC) paralela estrategicamente apoiada pela Fundação Sui. Anteriormente conhecida como dWallet Network, a Ika foi projetada para permitir interoperabilidade cross-chain zero-trust em alta velocidade e escala. Permite que smart contracts (especialmente na blockchain Sui) controlem e coordenam ativos noutras blockchains de forma segura, sem as bridges tradicionais. Este relatório fornece uma análise aprofundada da arquitetura técnica e do design criptográfico da Ika da perspetiva de um fundador, bem como uma análise de negócios e investimento que abrange a equipa, financiamento, tokenomics, adoção e concorrência. Uma tabela de comparação resumida da Ika com outras redes baseadas em MPC (Lit Protocol, Threshold Network e Zama) também está incluída para contextualização.

Arquitetura Técnica e Funcionalidades (Perspetiva do Fundador)​

Arquitetura e Primitivas Criptográficas​

A inovação central da Ika é um novo esquema criptográfico “2PC-MPC” – uma computação de duas partes dentro de uma estrutura de computação multi-partes. Em termos simples, o processo de assinatura envolve sempre duas partes: (1) o utilizador e (2) a rede Ika. O utilizador retém uma parte da chave privada, e a rede – composta por muitos nós independentes – detém a outra parte. Uma assinatura só pode ser produzida com a participação de ambos, garantindo que a rede por si só nunca pode forjar uma assinatura sem o utilizador. O lado da rede não é uma única entidade, mas um MPC distribuído entre N validadores que atuam coletivamente como a segunda parte. Um limiar de pelo menos dois terços desses nós deve concordar (semelhante ao consenso de Tolerância a Falhas Bizantinas) para gerar a parte da assinatura da rede. Esta estrutura de MPC aninhado (utilizador + rede) torna a Ika não-colusiva: mesmo que todos os nós da Ika conspirem, eles não podem roubar os ativos do utilizador porque a participação do utilizador (a sua parte da chave) é sempre criptograficamente necessária. Por outras palavras, a Ika permite segurança “zero-trust”, defendendo os princípios de descentralização e propriedade do utilizador da Web3 – nenhuma entidade única ou pequeno grupo pode comprometer unilateralmente os ativos.

Figura: Esquema da arquitetura 2PC-MPC da Ika – o utilizador atua como uma parte (detendo uma parte da chave privada) e a rede Ika de N validadores forma a outra parte através de um protocolo de limiar MPC (t-de-N). Isto garante que tanto o utilizador como uma supermaioria de nós descentralizados devem cooperar para produzir uma assinatura válida.

Tecnicamente, a Ika é implementada como uma rede blockchain autónoma, um fork do código-fonte da Sui. Executa a sua própria instância do motor de consenso de alto desempenho da Sui (Mysticeti, um protocolo BFT baseado em DAG) para coordenar os nós MPC. Notavelmente, a versão da Sui da Ika tem os smart contracts desativados (a chain da Ika existe apenas para executar o protocolo MPC) e inclui módulos personalizados para o algoritmo de assinatura 2PC-MPC. O Mysticeti fornece um canal de broadcast fiável entre os nós, substituindo a complexa malha de mensagens peer-to-peer que os protocolos MPC tradicionais usam. Ao alavancar um consenso baseado em DAG para comunicação, a Ika evita a sobrecarga de comunicação exponencial dos esquemas de assinatura de limiar anteriores, que exigiam que cada uma das n partes enviasse mensagens a todas as outras. Em vez disso, os nós da Ika transmitem mensagens através do consenso, alcançando uma complexidade de comunicação linear O(n), e usando técnicas de batching e agregação para manter os custos por nó quase constantes, mesmo quando N cresce muito. Isto representa um avanço significativo na criptografia de limiar: a equipa da Ika substituiu a comunicação ponto-a-ponto “unicast” por broadcast e agregação eficientes, permitindo que o protocolo suporte centenas ou milhares de participantes sem abrandar.

Integrações de conhecimento zero: Atualmente, a segurança da Ika é alcançada através de criptografia de limiar e consenso BFT, em vez de provas de conhecimento zero explícitas. O sistema não depende de zk-SNARKs ou zk-STARKs no seu processo de assinatura principal. No entanto, a Ika usa provas de estado on-chain (provas de light client) para verificar eventos de outras chains, o que é uma forma de verificação criptográfica (por exemplo, verificar provas de Merkle de cabeçalhos de bloco ou estado). O design deixa espaço para integrar técnicas de conhecimento zero no futuro – por exemplo, para validar o estado ou condições cross-chain sem revelar dados sensíveis – mas, a partir de 2025, nenhum módulo zk-SNARK específico faz parte da arquitetura publicada da Ika. A ênfase está, em vez disso, no princípio “zero-trust” (significando sem pressupostos de confiança) através do esquema 2PC-MPC, em vez de sistemas de prova de conhecimento zero.

Desempenho e Escalabilidade​

Um objetivo principal da Ika é superar os estrangulamentos de desempenho das redes MPC anteriores. Os protocolos de assinatura de limiar legados (como o 2PC ECDSA de Lindell ou o GG20) tinham dificuldade em suportar mais do que um punhado de participantes, muitas vezes demorando muitos segundos ou minutos para produzir uma única assinatura. Em contraste, o protocolo otimizado da Ika alcança latência abaixo de um segundo para assinatura e pode lidar com um throughput muito alto de pedidos de assinatura em paralelo. As alegações de benchmark indicam que a Ika pode escalar para cerca de 10.000 assinaturas por segundo, mantendo a segurança num grande cluster de nós. Isto é possível graças à comunicação linear mencionada e ao uso intensivo de batching: muitas assinaturas podem ser geradas simultaneamente pela rede numa única ronda do protocolo, amortizando drasticamente os custos. Segundo a equipa, a Ika pode ser “10.000× mais rápida” do que as redes MPC existentes sob carga. Em termos práticos, isto significa que transações de alta frequência em tempo real (como trading ou operações DeFi cross-chain) podem ser suportadas sem os atrasos habituais da assinatura de limiar. A latência está na ordem da finalidade abaixo de um segundo, o que significa que uma assinatura (e a operação cross-chain correspondente) pode ser concluída quase instantaneamente após o pedido de um utilizador.

Igualmente importante, a Ika faz isto enquanto aumenta o número de signatários para melhorar a descentralização. As configurações MPC tradicionais usavam frequentemente um comité fixo de talvez 10–20 nós para evitar o colapso do desempenho. A arquitetura da Ika pode expandir-se para centenas ou mesmo milhares de validadores a participar no processo de assinatura sem abrandamento significativo. Esta descentralização massiva melhora a segurança (mais difícil para um atacante corromper uma maioria) e a robustez da rede. O consenso subjacente é tolerante a falhas bizantinas, pelo que a rede pode tolerar até um terço dos nós comprometidos ou offline e ainda funcionar corretamente. Em qualquer operação de assinatura, apenas um limiar t-de-N de nós (por exemplo, 67% de N) precisa de participar ativamente; por design, se demasiados nós estiverem em baixo, a assinatura pode ser atrasada, mas o sistema é projetado para lidar com cenários de falha típicos de forma graciosa (semelhante às propriedades de liveness e safety do consenso de uma blockchain). Em resumo, a Ika alcança tanto alto throughput como um elevado número de validadores, uma combinação que a distingue das soluções MPC anteriores que tinham de trocar descentralização por velocidade.

Ferramentas de Desenvolvimento e Integração​

A rede Ika foi construída para ser amigável para programadores, especialmente para aqueles que já constroem na Sui. Os programadores não escrevem smart contracts na Ika em si (uma vez que a chain da Ika não executa contratos definidos pelo utilizador), mas interagem com a Ika a partir de outras chains. Por exemplo, um contrato Move na Sui pode invocar a funcionalidade da Ika para assinar transações em chains externas. Para facilitar isto, a Ika fornece ferramentas robustas e SDKs:

• SDK TypeScript: A Ika oferece um SDK TypeScript (biblioteca Node.js) que espelha o estilo do SDK da Sui. Este SDK permite que os construtores criem e giram dWallets (carteiras descentralizadas) e emitam pedidos de assinatura para a Ika a partir das suas aplicações. Usando o SDK TS, os programadores podem gerar pares de chaves, registar partes de utilizador e chamar o RPC da Ika para coordenar assinaturas de limiar – tudo com padrões familiares da API da Sui. O SDK abstrai a complexidade do protocolo MPC, tornando-o tão simples como chamar uma função para solicitar (por exemplo) uma assinatura de transação Bitcoin, dado o contexto apropriado e a aprovação do utilizador.

• CLI e Rede Local: Para uma interação mais direta, está disponível uma interface de linha de comandos (CLI) chamada dWallet CLI. Os programadores podem executar um nó Ika local ou mesmo uma rede de teste local fazendo um fork do repositório de código aberto. Isto é valioso para testes e integração num ambiente de desenvolvimento. A documentação orienta na configuração de uma devnet local, obtenção de tokens de testnet (DWLT – o token da testnet) e criação de um primeiro endereço dWallet.

• Documentação e Exemplos: A documentação da Ika inclui tutoriais passo a passo para cenários comuns, como “A Sua Primeira dWallet”. Estes mostram como estabelecer uma dWallet que corresponde a um endereço noutra chain (por exemplo, um endereço Bitcoin controlado pelas chaves da Ika), como encriptar a parte da chave do utilizador para segurança e como iniciar transações cross-chain. O código de exemplo abrange casos de uso como transferir BTC através de uma chamada de smart contract na Sui, ou agendar transações futuras (uma funcionalidade que a Ika suporta, onde uma transação pode ser pré-assinada sob certas condições).

• Integração com a Sui (Light Clients): De raiz, a Ika está firmemente integrada com a blockchain Sui. A rede Ika executa um light client da Sui internamente para ler dados on-chain da Sui de forma trustless. Isto significa que um smart contract na Sui pode emitir um evento ou chamada que a Ika reconhecerá (através de uma prova de estado) como um gatilho para realizar uma ação. Por exemplo, um contrato na Sui pode instruir a Ika: “quando o evento X ocorrer, assine e transmita uma transação na Ethereum”. Os nós da Ika verificarão o evento da Sui usando a prova do light client e, em seguida, produzirão coletivamente a assinatura para a transação Ethereum. A carga assinada pode então ser entregue à chain de destino (possivelmente por um relayer off-chain ou pelo utilizador) para executar a ação desejada. Atualmente, a Sui é a primeira chain controladora totalmente suportada (dadas as origens da Ika na Sui), mas a arquitetura é multi-chain por design. O suporte para provas de estado e integrações de outras chains está no roadmap – por exemplo, a equipa mencionou estender a Ika para trabalhar com rollups no ecossistema Polygon Avail (fornecendo capacidades de dWallet em rollups com a Avail como camada de dados) e outras Layer-1s no futuro.

• Algoritmos Criptográficos Suportados: A rede da Ika pode gerar chaves/assinaturas para praticamente qualquer esquema de assinatura de blockchain. Inicialmente, suporta ECDSA (o algoritmo de curva elíptica usado pelo Bitcoin, contas ECDSA da Ethereum, BNB Chain, etc.). A curto prazo, está planeado suportar EdDSA (Ed25519, usado por chains como Solana e algumas chains Cosmos) e assinaturas Schnorr (por exemplo, as chaves Schnorr do Taproot do Bitcoin). Este amplo suporte significa que uma dWallet da Ika pode ter um endereço no Bitcoin, um endereço na Ethereum, na Solana, e assim por diante – todos controlados pela mesma chave distribuída subjacente. Os programadores na Sui ou noutras plataformas podem, assim, integrar qualquer uma destas chains nas suas dApps através de uma estrutura unificada (Ika), em vez de lidar com bridges ou custodiantes específicos de cada chain.

Em resumo, a Ika oferece uma experiência de programador semelhante à interação com um nó de blockchain ou carteira, abstraindo a criptografia pesada. Seja através do SDK TypeScript ou diretamente através de contratos Move e light clients, esforça-se por tornar a lógica cross-chain “plug-and-play” para os construtores.

Segurança, Descentralização e Tolerância a Falhas​

A segurança é primordial no design da Ika. O modelo zero-trust significa que nenhum utilizador tem de confiar na rede Ika com o controlo unilateral de ativos em nenhum momento. Se um utilizador criar uma dWallet (digamos, um endereço BTC gerido pela Ika), a chave privada desse endereço nunca é detida por uma única parte – nem mesmo pelo utilizador sozinho. Em vez disso, o utilizador detém uma parte secreta e a rede detém coletivamente a outra parte. Ambas são necessárias para assinar qualquer transação. Assim, mesmo que o pior cenário ocorresse (por exemplo, muitos nós da Ika fossem comprometidos por um atacante), eles ainda não poderiam mover fundos sem a parte da chave secreta do utilizador. Esta propriedade aborda um grande risco nas bridges convencionais, onde um quórum de validadores poderia conspirar para roubar ativos bloqueados. A Ika elimina esse risco ao mudar fundamentalmente a estrutura de acesso (o limiar é definido de tal forma que a rede sozinha nunca é suficiente – o limiar efetivamente inclui o utilizador). Na literatura, este é um novo paradigma: uma rede MPC não-colusiva onde o proprietário do ativo permanece parte do quórum de assinatura por design.

Do lado da rede, a Ika usa um modelo de Proof-of-Stake delegado (herdado do design da Sui) para selecionar e incentivar validadores. Os detentores de tokens IKA podem delegar stake a nós validadores; os principais validadores (ponderados pelo stake) tornam-se as autoridades para uma época, e são tolerantes a falhas bizantinas (2/3 honestos) em cada época. Isto significa que o sistema assume que <33% do stake é malicioso para manter a segurança. Se um validador se comportar mal (por exemplo, tentar produzir uma parte de assinatura incorreta ou censurar transações), o consenso e o protocolo MPC irão detetá-lo – partes de assinatura incorretas podem ser identificadas (não se combinarão para uma assinatura válida), e um nó malicioso pode ser registado e potencialmente sofrer slashing ou ser removido em épocas futuras. Entretanto, a liveness é mantida enquanto nós suficientes (>67%) participarem; o consenso pode continuar a finalizar operações mesmo que muitos nós falhem ou fiquem offline inesperadamente. Esta tolerância a falhas garante que o serviço é robusto – não existe um ponto único de falha, uma vez que centenas de operadores independentes em diferentes jurisdições estão a participar. A descentralização é ainda reforçada pelo grande número de participantes: a Ika não se limita a um pequeno comité fixo, pelo que pode integrar mais validadores para aumentar a segurança sem sacrificar muito desempenho. De facto, o protocolo da Ika foi explicitamente projetado para “transcender o limite de nós das redes MPC” e permitir uma descentralização massiva.

Finalmente, a equipa da Ika submeteu a sua criptografia a uma revisão externa. Publicaram um whitepaper abrangente em 2024 detalhando o protocolo 2PC-MPC, e já passaram por pelo menos uma auditoria de segurança de terceiros. Por exemplo, em junho de 2024, uma auditoria da Symbolic Software examinou a implementação em Rust do protocolo 2PC-MPC da Ika e bibliotecas de criptografia relacionadas. A auditoria teria focado em validar a correção dos protocolos criptográficos (garantindo que não há falhas no esquema ECDSA de limiar, geração de chaves ou agregação de partes) e em verificar potenciais vulnerabilidades. O código-fonte é aberto (no GitHub da dWallet Labs), permitindo que a comunidade inspecione e contribua para a sua segurança. Na fase de testnet alfa, a equipa também alertou que o software ainda era experimental e não estava auditado para produção, mas auditorias contínuas e melhorias de segurança eram uma prioridade máxima antes do lançamento da mainnet. Em resumo, o modelo de segurança da Ika é uma combinação de garantias criptográficas comprováveis (de esquemas de limiar) e descentralização de nível de blockchain (do consenso PoS e do grande conjunto de validadores), revisto por especialistas, para fornecer fortes garantias contra atacantes externos e conluio interno.

Compatibilidade e Interoperabilidade do Ecossistema​

A Ika foi construída propositadamente para ser uma camada de interoperabilidade, inicialmente para a Sui, mas extensível a muitos ecossistemas. No primeiro dia, a sua integração mais próxima é com a blockchain Sui: atua efetivamente como um módulo adicional para a Sui, capacitando as dApps da Sui com capacidades multi-chain. Este alinhamento apertado é por design – os contratos Move da Sui e o modelo centrado em objetos tornam-na um bom “controlador” para as dWallets da Ika. Por exemplo, uma aplicação DeFi na Sui pode usar a Ika para obter liquidez da Ethereum ou Bitcoin em tempo real, tornando a Sui um hub para liquidez multi-chain. O apoio da Fundação Sui à Ika indica uma estratégia para posicionar a Sui como “a chain base para todas as chains”, alavancando a Ika para se conectar a ativos externos. Na prática, quando a mainnet da Ika estiver ativa, um construtor na Sui poderá criar um contrato Move que, digamos, aceita depósitos de BTC: nos bastidores, esse contrato criaria uma dWallet Bitcoin (um endereço) através da Ika e emitiria instruções para mover BTC quando necessário. O utilizador final experiencia isto como se o Bitcoin fosse apenas mais um ativo gerido dentro da app da Sui, embora o BTC permaneça nativo no Bitcoin até que uma transação assinada por limiar o mova.

Além da Sui, a arquitetura da Ika suporta outras blockchains Layer-1, Layer-2s e até sistemas off-chain. A rede pode hospedar múltiplos light clients simultaneamente, pelo que pode validar o estado da Ethereum, Solana, Avalanche ou outras – permitindo que os smart contracts nessas chains (ou os seus utilizadores) também aproveitem a rede MPC da Ika. Embora tais capacidades possam ser lançadas gradualmente, o objetivo do design é ser agnóstico em relação à chain. Entretanto, mesmo sem uma integração on-chain profunda, a Ika pode ser usada de uma forma mais manual: por exemplo, uma aplicação na Ethereum poderia chamar uma API da Ika (através de um Oráculo ou serviço off-chain) para solicitar uma assinatura para uma transação Ethereum ou uma mensagem. Como a Ika suporta ECDSA, poderia até ser usada para gerir a chave de uma conta Ethereum de forma descentralizada, de forma semelhante a como funcionam os PKPs do Lit Protocol (discutimos o Lit mais tarde). A Ika também demonstrou casos de uso como controlar Bitcoin em rollups – um exemplo é a integração com a framework Polygon Avail para permitir que os utilizadores de rollups giram BTC sem confiar num custodiante centralizado. Isto sugere que a Ika pode colaborar com vários ecossistemas (Polygon/Avail, rollups Celestia, etc.) como um fornecedor de infraestrutura de chaves descentralizada.

Em resumo, do ponto de vista técnico, a Ika é compatível com qualquer sistema que dependa de assinaturas digitais – o que é essencialmente todas as blockchains. A sua implementação inicial na Sui é apenas o começo; a visão a longo prazo é uma camada MPC universal à qual qualquer chain ou dApp pode ligar-se para operações cross-chain seguras. Ao suportar padrões criptográficos comuns (ECDSA, Ed25519, Schnorr) e fornecer as verificações de light client necessárias, a Ika poderia tornar-se uma espécie de rede “MPC-as-a-service” para toda a Web3, ligando ativos e ações de uma forma com confiança minimizada.

Perspetiva de Negócios e Investimento​

Equipa Fundadora e Histórico​

A Ika foi fundada por uma equipa de especialistas experientes em criptografia e blockchain, principalmente baseados em Israel. O criador e CEO do projeto é Omer Sadika, um empreendedor com um forte historial no espaço de segurança cripto. Omer co-fundou anteriormente a Odsy Network, outro projeto centrado em infraestrutura de carteiras descentralizadas, e é o Fundador/CEO da dWallet Labs, a empresa por trás da Ika. O seu percurso inclui formação na Y Combinator (aluno da YC) e um foco em cibersegurança e sistemas distribuídos. A experiência de Omer com a Odsy e a dWallet Labs informou diretamente a visão da Ika – em essência, a Ika pode ser vista como uma evolução do conceito de “carteira descentralizada dinâmica” em que a Odsy trabalhou, agora implementado como uma rede MPC na Sui.

O CTO e co-fundador da Ika é Yehonatan Cohen Scaly, um especialista em criptografia que co-escreveu o protocolo 2PC-MPC. Yehonatan lidera a I&D dos algoritmos criptográficos inovadores da Ika e já tinha trabalhado em cibersegurança (possivelmente com investigação académica em criptografia). Ele foi citado a discutir as limitações dos esquemas de limiar existentes e como a abordagem da Ika as supera, refletindo uma profunda especialização em MPC e protocolos criptográficos distribuídos. Outro co-fundador é David Lachmish, que supervisiona o desenvolvimento de produtos. O papel de David é traduzir a tecnologia central em produtos amigáveis para programadores e casos de uso do mundo real. O trio de Omer, Yehonatan e David – juntamente com outros investigadores como o Dr. Dolev Mutzari (VP de Investigação na dWallet Labs) – ancora a liderança da Ika. Coletivamente, as credenciais da equipa incluem startups anteriores, contribuições de investigação académica e experiência na interseção de cripto, segurança e blockchain. Esta profundidade é a razão pela qual a Ika é descrita como sendo criada por “alguns dos maiores especialistas em criptografia do mundo”.

Além dos fundadores, a equipa mais ampla e os conselheiros da Ika provavelmente incluem indivíduos com fortes antecedentes em criptografia. Por exemplo, Dolev Mutzari (mencionado acima) é co-autor do artigo técnico e fundamental no design do protocolo. A presença de tal talento dá aos investidores confiança de que a tecnologia complexa da Ika está em mãos capazes. Além disso, ter um fundador (Omer) que já angariou fundos com sucesso e construiu uma comunidade em torno dos conceitos Odsy/dWallet significa que a Ika beneficia das lições aprendidas em iterações anteriores da ideia. A base da equipa em Israel – um país conhecido pelo seu setor de criptografia e cibersegurança – também os situa num rico viveiro de talentos para contratar programadores e investigadores.

Rondas de Financiamento e Principais Apoiantes​

A Ika (e a sua empresa-mãe, dWallet Labs) atraiu um financiamento de risco significativo e investimento estratégico desde a sua criação. Até à data, angariou mais de $21 milhões em várias rondas. A ronda seed inicial do projeto em agosto de 2022 foi de $5M, o que foi notável dadas as condições de mercado em baixa na altura. Essa ronda seed incluiu uma vasta gama de investidores e anjos de cripto bem conhecidos. Participantes notáveis incluíram Node Capital (líder), Lemniscap, Collider Ventures, Dispersion Capital, Lightshift Capital, Tykhe Block Ventures, Liquid2 Ventures, Zero Knowledge Ventures, e outros. Investidores individuais proeminentes também se juntaram, como Naval Ravikant (co-fundador da AngelList e proeminente investidor em tecnologia), Marc Bhargava (co-fundador da Tagomi), Rene Reinsberg (co-fundador da Celo), e várias outras figuras da indústria. Tal lista de apoiantes sublinhou uma forte confiança na abordagem da Ika à custódia descentralizada, mesmo na fase de ideia.

Em maio de 2023, a Ika angariou um adicional de ~$7.5M no que parece ser uma Série A ou ronda estratégica, alegadamente com uma avaliação em torno de $250M. Esta ronda foi liderada pela Blockchange Ventures e Node Capital (novamente), com a participação da Insignius Capital, Rubik Ventures, e outros. Nesta altura, a tese das redes MPC escaláveis tinha ganho tração, e o progresso da Ika provavelmente atraiu estes investidores a apostar mais forte. A avaliação de $250M para uma rede em fase relativamente inicial refletia a expectativa do mercado de que a Ika poderia tornar-se uma infraestrutura fundamental na web3 (ao nível das blockchains L1 ou dos principais protocolos DeFi em termos de valor).

O investimento de maior destaque veio em abril de 2025, quando a Fundação Sui anunciou um investimento estratégico na Ika. Esta parceria com o fundo do ecossistema da Sui elevou o financiamento total da Ika para mais de $21M e cimentou um alinhamento próximo com a blockchain Sui. Embora o montante exato que a Fundação Sui investiu não tenha sido divulgado publicamente, é claro que este foi um endosso significativo – provavelmente na ordem de vários milhões de USD. O apoio da Fundação Sui não é apenas financeiro; também significa que a Ika obtém um forte apoio de go-to-market dentro do ecossistema Sui (divulgação a programadores, suporte de integração, marketing, etc.). De acordo com os comunicados de imprensa, “A Ika… anunciou um investimento estratégico da Fundação Sui, elevando o seu financiamento total para mais de $21 milhões.” Esta ronda estratégica, em vez de uma ronda de capital de risco tradicional, destaca que a Sui vê a Ika como uma infraestrutura crítica para o futuro da sua blockchain (semelhante a como a Fundação Ethereum poderia apoiar diretamente um projeto de Layer-2 ou de interoperabilidade que beneficia a Ethereum).

Além da Sui, outros apoiantes dignos de nota são a Node Capital (um fundo de cripto sediado na China conhecido por investimentos iniciais em infraestrutura), a Lemniscap (uma VC de cripto focada em inovação de protocolos em fase inicial), e a Collider Ventures (VC sediada em Israel, provavelmente fornecendo apoio local). A Blockchange Ventures a liderar a ronda de 2023 é notável; a Blockchange é uma VC que apoiou várias apostas em infraestrutura de cripto e a sua liderança sugere que viram a tecnologia da Ika como potencialmente definidora de categoria. Adicionalmente, o Digital Currency Group (DCG) e a Node Capital lideraram uma angariação de fundos de $5M para a dWallet Labs antes do rebranding da Ika (de acordo com uma publicação no LinkedIn de Omer) – o envolvimento do DCG (através de uma ronda anterior para a empresa) indica ainda mais apoio nos bastidores.

Em resumo, o percurso de financiamento da Ika mostra uma mistura de VCs tradicionais e parceiros estratégicos. O envolvimento da Fundação Sui destaca-se particularmente, pois não só fornece capital, mas também um ecossistema integrado para implementar a tecnologia da Ika. Os investidores estão essencialmente a apostar que a Ika se tornará a solução de referência para gestão de chaves descentralizada e bridging em muitas redes, e avaliaram o projeto em conformidade.

Tokenomics e Modelo Económico​

A Ika terá um token de utilidade nativo chamado $IKA, que é central para a economia e modelo de segurança da rede. De forma única, o token IKA está a ser lançado na blockchain Sui (como um ativo nativo SUI), embora a própria rede Ika seja uma chain separada. Isto significa que o IKA existirá como uma moeda que pode ser detida e transferida na Sui como qualquer outro ativo Sui, e será usado de forma dupla: dentro da rede Ika para staking e taxas, e na Sui para governação ou acesso em dApps. A tokenomics pode ser delineada da seguinte forma:

• Taxas de Gas: Assim como o ETH é o gas na Ethereum ou o SUI é o gas na Sui, o IKA serve como o gas/pagamento para operações MPC na rede Ika. Quando um utilizador ou uma dApp solicita uma assinatura ou operação de dWallet, uma taxa em IKA é paga à rede. Estas taxas compensam os validadores pelo trabalho de computação e comunicação de executar o protocolo de assinatura de limiar. O whitepaper faz uma analogia do papel do IKA com o gas da Sui, confirmando que todas as transações cross-chain facilitadas pela Ika incorrerão numa pequena taxa de IKA. A tabela de taxas é provavelmente proporcional à complexidade da operação (por exemplo, uma única assinatura pode custar uma taxa base, enquanto fluxos de trabalho mais complexos de múltiplos passos podem custar mais).

• Staking e Segurança: O IKA é também um token de staking. Os nós validadores na rede Ika devem ter um stake de IKA delegado para participar no consenso e na assinatura. O consenso segue um modelo de proof-of-stake delegado semelhante ao da Sui: os detentores de tokens delegam IKA aos validadores, e o peso de cada validador no consenso (e, portanto, nos processos de assinatura de limiar) é determinado pelo stake. Em cada época, os validadores são escolhidos e o seu poder de voto é uma função do stake, com o conjunto geral a ser tolerante a falhas bizantinas (o que significa que se um conjunto de validadores tiver um stake total de $X, até ~$X/3 de stake poderia ser malicioso sem quebrar as garantias da rede). Os stakers (delegadores) são incentivados por recompensas de staking: o modelo da Ika provavelmente inclui a distribuição das taxas recolhidas (e possivelmente recompensas inflacionárias) aos validadores e seus delegadores no final das épocas. De facto, a documentação nota que todas as taxas de transação recolhidas são distribuídas às autoridades, que podem partilhar uma porção com os seus delegadores como recompensas. Isto espelha o modelo da Sui de recompensar os fornecedores de serviços pelo throughput.

• Fornecimento e Distribuição: A partir de agora (Q2 2025), os detalhes sobre o fornecimento total, distribuição inicial e inflação do IKA não são totalmente públicos. No entanto, dadas as rondas de financiamento, podemos inferir alguma estrutura. Provavelmente, uma porção do IKA é alocada aos investidores iniciais (rondas seed e de séries) e à equipa, com uma grande parte reservada para a comunidade e incentivos futuros. Pode haver uma venda para a comunidade ou airdrop planeado, especialmente porque a Ika realizou uma notável campanha de NFT que angariou 1.4M SUI, como mencionado nas notícias (esta foi uma campanha de arte NFT na Sui que estabeleceu um recorde; é possível que os participantes nessa campanha possam receber recompensas em IKA ou acesso antecipado). A campanha de NFT sugere uma estratégia para envolver a comunidade e iniciar a distribuição de tokens aos utilizadores, não apenas a VCs.

• Calendário de Lançamento do Token: O anúncio da Fundação Sui em outubro de 2024 indicava que “O token IKA será lançado nativamente na Sui, desbloqueando novas funcionalidades e utilidade em segurança descentralizada”. A mainnet estava prevista para dezembro de 2024, pelo que presumivelmente o evento de geração de token (TGE) coincidiria ou seguir-se-ia em breve. Se a mainnet foi lançada dentro do prazo, os tokens IKA podem ter começado a ser distribuídos no final de 2024 ou início de 2025. O token começaria então a ser usado para gas na rede Ika e para staking. Antes disso, na testnet, um token temporário (DWLT na testnet) era usado para gas, que não tinha valor real.

• Casos de Uso e Acumulação de Valor: O valor do IKA como investimento depende do uso da rede Ika. À medida que mais transações cross-chain fluem através da Ika, mais taxas são pagas em IKA, criando procura. Adicionalmente, se muitos quiserem executar validadores ou proteger a rede, devem adquirir e fazer stake de IKA, o que bloqueia o fornecimento (reduzindo a circulação). Assim, o IKA tem uma natureza de utilidade mais governação – utilidade no pagamento de serviços e staking, e provavelmente governação na direção do futuro do protocolo (embora a governação não seja explicitamente mencionada ainda, é comum que tais redes eventualmente descentralizem o controlo através de votação com tokens). Pode-se imaginar os detentores de tokens IKA a votar na adição de suporte para novas chains, ajuste de parâmetros de taxas ou outras atualizações do protocolo no futuro.

No geral, a tokenomics da IKA visa equilibrar a segurança da rede com a usabilidade. Ao lançar na Sui, facilitam a obtenção e uso do IKA pelos utilizadores do ecossistema Sui (não é necessário onboarding numa chain separada para o próprio token), o que pode impulsionar a adoção. Os investidores estarão atentos a métricas como a porção do fornecimento em stake (indicando segurança), a receita de taxas (indicando uso) e parcerias que impulsionam transações (indicando procura pelo token).

Modelo de Negócios e Estratégia Go-to-Market​

O modelo de negócios da Ika é o de um fornecedor de infraestrutura no ecossistema blockchain. Não oferece um produto voltado para o consumidor; em vez disso, oferece um serviço de protocolo (gestão de chaves descentralizada e execução de transações) que outros projetos integram. Como tal, o principal mecanismo de receita (ou captura de valor) é a taxa por serviço – ou seja, as taxas de gas em IKA pelo uso da rede. Pode-se comparar a Ika a uma AWS descentralizada para assinatura de chaves: qualquer programador pode ligar-se e usá-la, pagando por uso. A longo prazo, à medida que a rede se descentraliza, a dWallet Labs (a empresa fundadora) pode capturar valor detendo uma participação na rede e através da apreciação do token, em vez de cobrar taxas ao estilo SaaS off-chain.

Estratégia Go-to-Market (GTM): No início, a Ika está a visar programadores de blockchain e projetos que necessitam de funcionalidade cross-chain ou soluções de custódia. O alinhamento com a Sui oferece um conjunto pronto de tais programadores. A própria Sui, sendo uma L1 mais recente, precisa de funcionalidades únicas para atrair utilizadores – e a Ika oferece DeFi cross-chain, acesso ao Bitcoin e mais na Sui, que são funcionalidades atraentes. Assim, a GTM da Ika aproveita o ecossistema crescente da Sui. Notavelmente, mesmo antes da mainnet, vários projetos da Sui anunciaram que estão a integrar a Ika:

• Projetos como Full Sail, Rhei, Aeon, Human Tech, Covault, Lucky Kat, Native, Nativerse, Atoma e Ekko (todos construtores na Sui) “anunciaram os seus próximos lançamentos utilizando a Ika”, cobrindo casos de uso desde DeFi a jogos. Por exemplo, a Full Sail pode estar a construir uma exchange que pode negociar BTC via Ika; a Lucky Kat (um estúdio de jogos) poderia usar a Ika para permitir ativos no jogo que residem em múltiplas chains; a Covault provavelmente envolve soluções de custódia, etc. Ao garantir estas parcerias cedo, a Ika assegura que, no lançamento, haverá volume de transações imediato e aplicações reais a demonstrar as suas capacidades.

• A Ika também está a enfatizar casos de uso institucionais, como custódia descentralizada para instituições. Em comunicados de imprensa, destacam “segurança inigualável para utilizadores institucionais e individuais” na custódia via Ika. Isto sugere que a Ika poderia ser comercializada para custodiantes de cripto, exchanges, ou mesmo players de TradFi que queiram uma forma mais segura de gerir chaves privadas (talvez como uma alternativa ou complemento à Fireblocks ou Copper, que usam MPC mas num ambiente empresarial centralizado). De facto, por ser uma rede descentralizada, a Ika poderia permitir que concorrentes na custódia confiassem todos na mesma rede de assinatura robusta, em vez de cada um construir a sua própria. Este modelo cooperativo poderia atrair instituições que preferem um custodiante neutro e descentralizado para certos ativos.

• Outro ângulo são as integrações de IA: a Ika menciona “guardrails para Agentes de IA” como um caso de uso. Isto é visionário, jogando com a tendência da autonomia da IA (por exemplo, agentes de IA a executar na blockchain). A Ika pode garantir que um agente de IA (digamos, um agente económico autónomo com controlo de alguns fundos) não pode fugir com os fundos porque o próprio agente não é o único detentor da chave – ainda precisaria da parte do utilizador ou de cumprir as condições na Ika. Marketing da Ika como fornecedora de barreiras de segurança para IA na Web3 é um ângulo inovador para captar o interesse desse setor.

Geograficamente, a presença da Node Capital e outros sugere também um foco na Ásia, além do mercado ocidental. A Sui tem uma forte comunidade asiática (especialmente na China). A campanha de NFT da Ika na Sui (a campanha de arte que angariou 1.4M SUI) indica um esforço de construção de comunidade – possivelmente envolvendo utilizadores chineses que são ávidos no espaço de NFTs da Sui. Ao fazer vendas de NFTs ou airdrops para a comunidade, a Ika pode cultivar uma base de utilizadores de base que detêm tokens IKA e são incentivados a promover a sua adoção.

Com o tempo, o modelo de negócios poderia estender-se para oferecer funcionalidades premium ou integrações empresariais. Por exemplo, enquanto a rede pública da Ika é sem permissão, a dWallet Labs poderia criar instâncias privadas ou versões de consórcio para certos clientes, ou fornecer serviços de consultoria a projetos que integram a Ika. Eles também poderiam ganhar através da execução de alguns dos validadores no início (fase de bootstrap) e, assim, recolher parte das taxas.

Em resumo, a GTM da Ika está fortemente ligada a parcerias de ecossistema. Ao incorporar-se profundamente no roadmap da Sui (onde os objetivos da Sui para 2025 incluem liquidez cross-chain e casos de uso únicos), a Ika garante que irá acompanhar o crescimento dessa L1. Simultaneamente, posiciona-se como uma solução generalizada para coordenação multi-chain, que pode então ser apresentada a projetos noutras chains assim que o sucesso na Sui for demonstrado. O apoio da Fundação Sui e os anúncios de integração precoce dão à Ika uma vantagem significativa em credibilidade e adoção em comparação com se fosse lançada isoladamente.

Adoção pelo Ecossistema, Parcerias e Roadmap​

Mesmo na sua fase inicial, a Ika construiu uma lista impressionante de envolvimentos no ecossistema:

• Adoção pelo Ecossistema Sui: Como mencionado, múltiplos projetos baseados na Sui estão a integrar a Ika. Isto significa que, no lançamento da mainnet da Ika, esperamos ver dApps da Sui a ativar funcionalidades como “Powered by Ika” – por exemplo, um protocolo de empréstimo na Sui que permite aos utilizadores depositar BTC, ou uma DAO na Sui que usa a Ika para deter o seu tesouro em múltiplas chains. O facto de nomes como Rhei, Atoma, Nativerse (provavelmente projetos DeFi) e Lucky Kat (jogos/NFT) estarem a bordo mostra que a aplicabilidade da Ika abrange vários verticais.

• Parcerias Estratégicas: A parceria mais importante da Ika é com a própria Fundação Sui, que é tanto um investidor como um promotor. Os canais oficiais da Sui (blog, etc.) têm destacado a Ika proeminentemente, endossando-a efetivamente como a solução de interoperabilidade para a Sui. Adicionalmente, a Ika provavelmente tem trabalhado com outros fornecedores de infraestrutura. Por exemplo, dada a menção do zkLogin (a funcionalidade de login Web2 da Sui) juntamente com a Ika, poderia haver um caso de uso combinado onde o zkLogin lida com a autenticação do utilizador e a Ika lida com as transações cross-chain, proporcionando em conjunto uma UX fluida. Além disso, a menção da Ika à Avail (Polygon) nos seus blogs sugere uma parceria ou piloto nesse ecossistema: talvez com a Polygon Labs ou equipas a construir rollups na Avail para usar a Ika para fazer a ponte do Bitcoin para esses rollups. Outro domínio de parceria potencial é com custodiantes – por exemplo, integrar a Ika com fornecedores de carteiras como a Zengo (notável, uma vez que o co-fundador da ZenGo estava no projeto anterior de Omer) ou com tecnologia de custódia institucional como a Fireblocks. Embora não confirmado, estes seriam alvos lógicos (de facto, a Fireblocks fez parceria com a Sui noutros contextos; poder-se-ia imaginar a Fireblocks a alavancar a Ika para MPC na Sui).

• Envolvimento da Comunidade e Programadores: A Ika mantém um Discord e provavelmente organiza hackathons para levar os programadores a construir com dWallets. A tecnologia é nova, por isso evangelizá-la através da educação é fundamental. A presença das secções “Casos de Uso” e “Construtores” no seu site, além de publicações de blog a explicar conceitos centrais, indica um esforço para que os programadores se sintam confortáveis com o conceito de dWallets. Quanto mais programadores entenderem que podem construir lógica cross-chain sem bridges (e sem comprometer a segurança), mais a adoção orgânica crescerá.

• Roadmap: A partir de 2025, o roadmap da Ika incluía:

  • Alfa e Testnet (2023–2024): A testnet alfa foi lançada em 2024 na Sui, permitindo que os programadores experimentassem as dWallets e fornecessem feedback. Esta fase foi usada para refinar o protocolo, corrigir bugs e realizar auditorias internas.
  • Lançamento da Mainnet (Dez 2024): A Ika planeava entrar em funcionamento na mainnet até ao final de 2024. Se alcançado, até agora (meados de 2025) a mainnet da Ika deverá estar operacional. O lançamento provavelmente incluiu suporte inicial para um conjunto de chains: pelo menos Bitcoin e Ethereum (chains ECDSA) de imediato, dado que foram muito mencionadas no marketing.
  • Objetivos Pós-Lançamento para 2025: Em 2025, esperamos que o foco seja em escalar o uso (através de apps da Sui e possivelmente expandindo para outras chains). A equipa trabalhará na adição de suporte a Ed25519 e Schnorr logo após o lançamento, permitindo a integração com Solana, Polkadot e outros ecossistemas. Eles também implementarão mais light clients (talvez um light client da Ethereum para a Ika, um light client da Solana, etc.) para ampliar o controlo trustless. Outro item do roadmap é provavelmente a expansão de validadores sem permissão – incentivando mais validadores independentes a juntarem-se e descentralizando ainda mais a rede. Como o código é um fork da Sui, executar um validador Ika é semelhante a executar um nó Sui, o que muitos operadores podem fazer.
  • Melhorias de Funcionalidades: Duas funcionalidades interessantes sugeridas nos blogs são Partes de Utilizador Encriptadas e Assinatura de Transações Futuras. A parte de utilizador encriptada significa que os utilizadores podem opcionalmente encriptar a sua parte privada e armazená-la on-chain (talvez na Ika ou noutro lugar) de uma forma que só eles podem desencriptar, simplificando a recuperação. A assinatura de transações futuras implica a capacidade de ter a Ika a pré-assinar uma transação que é executada mais tarde quando as condições são cumpridas. Estas funcionalidades aumentam a usabilidade (os utilizadores não precisarão de estar online para cada ação se pré-aprovarem certas lógicas, tudo enquanto mantêm a segurança não-custodial). Entregar estas funcionalidades em 2025 diferenciaria ainda mais a oferta da Ika.
  • Crescimento do Ecossistema: Até ao final de 2025, a Ika provavelmente pretende ter múltiplos ecossistemas de chains a usá-la ativamente. Poderemos ver, por exemplo, um projeto Ethereum a usar a Ika através de um oráculo (se a integração on-chain direta ainda não existir) ou colaborações com projetos interchain como Wormhole ou LayerZero, onde a Ika poderia servir como o mecanismo de assinatura para mensagens seguras.

O cenário competitivo também moldará a estratégia da Ika. Não está sozinha a oferecer gestão de chaves descentralizada, pelo que parte do seu roadmap envolverá destacar a sua vantagem de desempenho e o modelo de segurança único de duas partes em contraste com outros. Na próxima secção, comparamos a Ika com os seus concorrentes notáveis Lit Protocol, Threshold Network e Zama.

Análise Competitiva: Ika vs. Outras Redes MPC/Threshold​

A Ika opera numa arena de vanguarda de redes criptográficas, onde alguns projetos perseguem objetivos semelhantes com abordagens variadas. Abaixo está uma comparação resumida da Ika com o Lit Protocol, a Threshold Network e a Zama (cada um um concorrente representativo em infraestrutura de chaves descentralizada ou computação de privacidade):

Vantagem Competitiva da Ika: Os diferenciadores da Ika residem no seu desempenho em escala e modelo de segurança único. Comparada com o Lit Protocol, a Ika pode suportar muito mais signatários e um throughput muito maior, tornando-a adequada para casos de uso (como trading de alto volume ou jogos) com os quais a rede do Lit teria dificuldades. A Ika também não depende de Ambientes de Execução Confiáveis, dos quais alguns programadores desconfiam (devido a potenciais exploits no SGX); em vez disso, a Ika alcança a ausência de confiança puramente com criptografia e consenso. Contra a Threshold Network, a Ika oferece uma plataforma de propósito mais geral. A Threshold está largamente focada na ponte Bitcoin↔Ethereum (tBTC) e alguns serviços criptográficos como recodificação de proxy, enquanto a Ika é uma camada de interoperabilidade flexível que pode funcionar com qualquer chain e ativo de raiz. Além disso, o modelo da Ika com o utilizador no ciclo significa que não requer sobrecolateralização ou seguro para depósitos (o tBTC v2 usa um modelo económico robusto mas complexo para proteger os depósitos de BTC, enquanto na Ika o utilizador nunca abdica do controlo em primeiro lugar). Comparada com a Zama, a Ika aborda um problema diferente – a Zama visa a privacidade, enquanto a Ika visa a interoperabilidade. No entanto, é concebível que no futuro as duas se possam complementar (por exemplo, usando FHE em ativos armazenados na Ika). Por agora, a Ika tem a vantagem de estar operacional mais cedo num nicho com procura imediata (bridges e redes MPC são necessárias hoje, enquanto o FHE ainda está a amadurecer).

Um desafio potencial para a Ika é a educação do mercado e a confiança. Está a introduzir uma nova forma de fazer interações cross-chain (dWallets em vez das tradicionais bridges de lock-and-mint). Precisará de demonstrar a sua segurança na prática ao longo do tempo para ganhar o mesmo nível de confiança que, por exemplo, a Threshold Network gradualmente conquistou (a Threshold teve de provar o tBTC depois de uma versão anterior ter sido pausada devido a riscos). Se a tecnologia da Ika funcionar como anunciado, ela efetivamente ultrapassa a concorrência ao resolver o trilema de descentralização, segurança e velocidade no espaço MPC. O forte apoio da Sui e as extensas auditorias/artigos conferem credibilidade.

Em conclusão, a Ika destaca-se entre as redes MPC pela sua escalabilidade ambiciosa e modelo de segurança centrado no utilizador. Os investidores veem-na como uma aposta no futuro da coordenação cross-chain – uma onde os utilizadores podem mover valor e lógica de forma fluida através de muitas blockchains sem nunca abdicarem do controlo das suas chaves. Se a Ika alcançar uma ampla adoção, poderá tornar-se tão integral para a infraestrutura Web3 como os protocolos de mensagens cross-chain ou as principais blockchains Layer-1. O próximo ano (2025) será crítico, à medida que a mainnet da Ika e os primeiros casos de uso entram em funcionamento, provando se esta criptografia de vanguarda pode cumprir as suas promessas em condições reais de mercado. Os sinais iniciais – fundamentos técnicos sólidos, um pipeline ativo de integrações e um apoio substancial de investidores – sugerem que a Ika tem uma oportunidade real de redefinir a interoperabilidade de blockchain com MPC.

Fontes: As informações principais foram recolhidas da documentação oficial e do whitepaper da Ika, anúncios da Fundação Sui, comunicados de imprensa e notícias de financiamento, bem como documentos técnicos e análises de concorrentes para contextualização (relatório Messari do Lit Protocol, documentação da Threshold Network e descrições FHE da Zama). Todas as informações estão atualizadas até 2025.

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

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

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

Arquitetura e Design da FHE-VM​

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

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

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

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

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

Garantindo Correção e Privacidade​

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

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

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

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

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

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

Coprocessadores de Conhecimento Zero (ZK-Coprocessors)​

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

Arquitetura e Fluxo de Trabalho​

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

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

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

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

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

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

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

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

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

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

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

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

Projetos Notáveis de Coprocessador ZK​

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

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

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

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

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

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

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

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

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

Casos de Uso e Implicações​

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

DeFi Confidencial e Finanças​

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

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

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

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

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

Identidade Digital e Dados Pessoais​

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

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

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

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

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

Saúde e Compartilhamento de Dados Sensíveis​

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

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

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

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

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

Mercados de Dados e Colaboração​

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

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

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

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

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

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

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

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

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

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

Áreas Adicionais​

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

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

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

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

Conclusão​

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

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

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

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

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

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

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