54 postagens marcadas com "blockchain"

O surgimento da IA generativa tem sido nada menos que explosivo. De arte digital impressionante a textos que parecem humanos, a IA está criando conteúdo em uma escala sem precedentes. Mas esse boom tem um lado sombrio: de onde a IA obtém seus dados de treinamento? Frequentemente, vem da vasta extensão da internet — de arte, música e textos criados por humanos que não recebem crédito nem compensação.

Surge então o Camp Network, um novo projeto de blockchain que pretende resolver esse problema fundamental. Não é apenas mais uma plataforma cripto; é uma “Camada de IP Autônoma” criada para dar aos criadores propriedade e controle sobre seu trabalho na era da IA. Vamos mergulhar no que torna o Camp Network um projeto a ser observado.

Qual é a Grande Ideia?​

Em sua essência, o Camp Network é um blockchain que funciona como um registro global e verificável de propriedade intelectual (IP). A missão é permitir que qualquer pessoa — de um artista independente a um usuário de redes sociais — registre seu conteúdo on‑chain. Isso cria um registro permanente e à prova de adulteração de propriedade e proveniência.

Por que isso importa? Quando um modelo de IA utiliza conteúdo registrado no Camp, os contratos inteligentes da rede podem aplicar automaticamente os termos de licenciamento. Isso significa que o criador original pode receber atribuição e até pagamentos de royalties instantaneamente. A visão do Camp é construir uma nova economia criadora onde a compensação não é um detalhe posterior; está incorporada diretamente ao protocolo.

Por Dentro da Tecnologia: A Pilha Tecnológica​

O Camp não é apenas um conceito; é sustentado por tecnologia séria projetada para alto desempenho e facilidade para desenvolvedores.

• Arquitetura Modular: O Camp é construído como um rollup soberano usando Celestia para disponibilidade de dados. Esse design permite que seja incrivelmente rápido (alvo de 50.000 transações por segundo) e barato, mantendo total compatibilidade com as ferramentas do Ethereum (EVM).
• Proof of Provenance (PoP): Este é o mecanismo de consenso exclusivo do Camp. Em vez de depender de mineração intensiva em energia, a segurança da rede está atrelada à verificação da origem do conteúdo. Cada transação reforça a proveniência da IP na rede, tornando a propriedade “exigível por design”.
• Estratégia Dual‑VM: Para maximizar o desempenho, o Camp está integrando a Solana Virtual Machine (SVM) ao lado da compatibilidade com EVM. Isso permite que desenvolvedores escolham o ambiente mais adequado para seu aplicativo, especialmente para casos de uso de alta taxa de transferência, como interações de IA em tempo real.
• Kit de Ferramentas para Criadores e IA: O Camp oferece duas estruturas principais:
  • Origin Framework: Um sistema amigável para criadores registrarem sua IP, tokenizá‑la (como NFT) e incorporar regras de licenciamento.
  • mAItrix Framework: Um kit para desenvolvedores criarem e implantarem agentes de IA que podem interagir com a IP on‑chain de forma segura e permissionada.

Pessoas, Parcerias e Progresso​

Uma ideia só é tão boa quanto sua execução, e o Camp parece estar executando bem.

A Equipe e o Financiamento​

O projeto é liderado por uma equipe com uma mistura potente de experiência proveniente da The Raine Group (media e acordos de IP), Goldman Sachs, Figma e CoinList. Essa combinação de finanças, produto tecnológico e engenharia cripto ajudou a garantir US$ 30 milhões em financiamento de VCs de destaque como 1kx, Blockchain Capital e Maven 11.

Um Ecossistema em Expansão​

O Camp tem sido agressivo na construção de parcerias. A mais significativa é uma participação estratégica no KOR Protocol, uma plataforma para tokenizar IP musical que trabalha com artistas de grande porte como Deadmau5 e franquias como Black Mirror. Essa única parceria fornece ao Camp uma biblioteca massiva de conteúdo de alto perfil, já com direitos claros. Outros colaboradores chave incluem:

• RewardedTV: Plataforma descentralizada de streaming de vídeo que usa o Camp para direitos de conteúdo on‑chain.
• Rarible: Marketplace de NFT integrado para negociação de ativos de IP.
• LayerZero: Protocolo cross‑chain que garante interoperabilidade com outras blockchains.

Roteiro e Comunidade​

Após campanhas de testnet incentivadas que atraíram dezenas de milhares de usuários (recompensando‑os com pontos que se convertem em tokens), o Camp mira um lançamento de mainnet no terceiro trimestre de 2025. Isso será acompanhado por um Evento de Geração de Token para seu token nativo, $CAMP, que será usado para taxas de gas, staking e governança. O projeto já cultivou uma comunidade apaixonada, pronta para construir e usar a plataforma desde o primeiro dia.

Como Ela se Compara?​

O Camp Network não está sozinho nesse espaço. Enfrenta concorrência forte de projetos como o Story Protocol, apoiado pela a16z, e o Soneium, ligado à Sony. Contudo, o Camp se diferencia em vários aspectos chave:

1. Abordagem Bottom‑Up: Enquanto concorrentes parecem mirar grandes detentores corporativos de IP, o Camp foca em capacitar criadores independentes e comunidades cripto por meio de incentivos tokenizados.
2. Solução Abrangente: Oferece um conjunto completo de ferramentas, desde um registro de IP até um framework de agentes de IA, posicionando‑se como um “one‑stop shop”.
3. Desempenho e Escalabilidade: Sua arquitetura modular e suporte dual‑VM são projetados para atender às demandas de alta taxa de transferência de IA e mídia.

Conclusão​

O Camp Network apresenta um caso convincente para se tornar a camada fundamental de propriedade intelectual na era Web3. Ao combinar tecnologia inovadora, equipe forte, parcerias estratégicas e uma ética centrada na comunidade, está construindo uma solução prática para um dos problemas mais urgentes criados pela IA generativa.

O verdadeiro teste virá com o lançamento da mainnet e a adoção no mundo real. Mas, com uma visão clara e execução sólida até agora, o Camp Network é, sem dúvida, um projeto chave a ser observado enquanto tenta construir um futuro mais equitativo para criadores digitais.

A perspectiva de Stripe lançar sua própria blockchain de Camada 1 (L1) tem sido um tema quente na comunidade cripto, alimentada por movimentos estratégicos recentes do gigante global de pagamentos. Embora não confirmados, os sussurros sugerem uma mudança potencialmente transformadora no cenário de pagamentos. Dada a missão central da Stripe de “crescer o PIB da internet” ao construir uma infraestrutura econômica global robusta, uma blockchain dedicada poderia ser um próximo passo lógico e poderoso, especialmente considerando a crescente adoção de iniciativas relacionadas a blockchain pela empresa.

A Base para uma Stripe L1​

A Stripe já estabeleceu fundamentos significativos que tornam a ideia de uma L1 altamente plausível. Em fevereiro de 2025, a Stripe adquiriu a Bridge, uma empresa de infraestrutura de stablecoin, por aproximadamente US$ 1,1 bilhão. Esse movimento sinaliza claramente o compromisso da Stripe com infraestrutura financeira baseada em stablecoins. Após essa aquisição, em maio de 2025, a Stripe introduziu seu serviço Stablecoin Financial Accounts no evento Stripe Sessions. Esse serviço, disponível em 101 países, permite que empresas:

• Mantenham USDC (emitido pela Circle) e USDB (emitido pela Bridge).
• Depoquem e retirem stablecoins facilmente via transferências tradicionais em USD (ACH/wire) e transferências em EUR (SEPA).
• Facilitem depósitos e retiradas de USDC em redes blockchain principais, incluindo Arbitrum, Avalanche C-Chain, Base, Ethereum, Optimism, Polygon, Solana e Stellar.

Isso significa que empresas ao redor do mundo podem integrar stablecoins baseadas em dólar em suas operações de forma fluida, conectando o sistema bancário tradicional à economia digital emergente.

Além disso, em junho de 2025, a Stripe adquiriu a Privy.io, uma startup de infraestrutura de carteiras Web3. A Privy oferece recursos cruciais como criação de carteira por e‑mail ou SSO, assinatura de transações, gerenciamento de chaves e abstração de gas. Essa aquisição completa as capacidades da Stripe, fornecendo a infraestrutura de carteira essencial para facilitar uma adoção mais ampla de blockchain.

Com infraestrutura de stablecoin e de carteira já firmemente estabelecida, a sinergia estratégica de lançar uma rede blockchain dedicada torna‑se evidente. Isso permitiria à Stripe integrar esses serviços de forma ainda mais estreita e desbloquear novas possibilidades dentro de seu ecossistema.

O Que uma Stripe L1 Poderia Significar para os Pagamentos​

Se a Stripe introduzisse sua própria rede L1, poderia melhorar significativamente os serviços de pagamento existentes e habilitar funcionalidades totalmente novas.

Melhorias de Caso Base​

Em sua forma mais fundamental, uma Stripe L1 poderia trazer várias melhorias imediatas:

• Contas Financeiras de Stablecoin Integradas: O serviço de contas financeiras de stablecoin existente da Stripe provavelmente se integraria totalmente à Stripe L1, permitindo que comerciantes depositem, retirem e utilizem seus ativos de stablecoin diretamente na rede para diversas atividades financeiras.
• Liquidação em Stablecoin para Comerciantes: Comerciantes poderiam optar por liquidar suas receitas de vendas diretamente em stablecoins baseadas em dólar. Isso seria um benefício substancial, especialmente para negócios com alta demanda por dólares mas acesso limitado a vias bancárias tradicionais, simplificando transações transfronteiriças e reduzindo complexidades cambiais.
• Serviços de Carteira para Clientes: Aproveitando a infraestrutura da Privy, uma Stripe L1 poderia permitir que indivíduos criem facilmente carteiras Web3 dentro do ecossistema Stripe. Isso facilitaria pagamentos em stablecoin para clientes e abriria portas para participação em uma gama mais ampla de atividades financeiras na Stripe L1.
• Opções de Pagamento em Stablecoin para Clientes: Clientes que atualmente utilizam cartões ou transferências bancárias poderiam conectar suas carteiras Web3 (sejam fornecidas pela Stripe ou de terceiros) e escolher stablecoins como método de pagamento, oferecendo maior flexibilidade e potencialmente custos de transação menores.

Cenários Revolucionários “Bull Case”​

Além dessas melhorias fundamentais, uma Stripe L1 tem o potencial de realmente revolucionar a indústria de pagamentos, abordando ineficiências de longa data:

• Pagamentos Diretos Cliente‑para‑Comerciante: Um dos prospectos mais empolgantes é a possibilidade de pagamentos diretos entre clientes e comerciantes usando stablecoins na Stripe L1. Isso poderia contornar intermediários tradicionais como redes de cartões e bancos emissores, levando a tempos de liquidação significativamente mais rápidos e taxas de transação reduzidas. Embora salvaguardas para reembolsos e cancelamentos sejam cruciais, a natureza direta das transações blockchain oferece eficiência incomparável.
• Serviços de Assinatura Baseados em Micropagamentos: O suporte inerente da blockchain a micropagamentos poderia desbloquear modelos de negócios totalmente novos. Imagine assinaturas cobradas por minuto, onde usuários pagam estritamente com base no uso real, com todos os pagamentos automatizados via smart contracts. Isso contrasta fortemente com os modelos mensais ou anuais atuais, abrindo um vasto leque de novas ofertas de serviço.
• Utilização DeFi de Depósitos de Curto Prazo: Em sistemas tradicionais, as liquidações de pagamento frequentemente enfrentam atrasos devido à necessidade de detecção de fraude, cancelamentos e reembolsos. Se a Stripe L1 lidar com pagamentos diretos em stablecoin, os fundos ainda podem ficar temporariamente retidos na rede antes da liberação total ao comerciante. Esses depósitos de curto prazo, esperados em escala substancial, poderiam formar um enorme pool de liquidez na Stripe L1. Essa liquidez poderia ser então empregada em protocolos de finanças descentralizadas (DeFi), mercados de empréstimo ou investida em títulos de alto rendimento, melhorando significativamente a eficiência de capital para todos os participantes.

O Futuro dos Pagamentos​

Os rumores em torno de uma rede Stripe L1 são mais do que mera especulação; apontam para uma tendência mais profunda no mundo financeiro. Gigantes de pagamento como Visa, Mastercard e PayPal têm visto blockchain e stablecoins principalmente como recursos complementares. Se a Stripe se comprometer totalmente com uma L1, isso poderia sinalizar uma mudança de paradigma histórica nos sistemas de pagamento, remodelando fundamentalmente como o dinheiro circula globalmente.

Historicamente, a Stripe tem se destacado como gateway e adquirente de pagamentos. Contudo, uma Stripe L1 poderia permitir que a empresa expandisse seu papel, potencialmente assumindo funções tradicionalmente desempenhadas por redes de cartões e até bancos emissores. Esse movimento não apenas aumentaria a eficiência dos pagamentos por meio da blockchain, mas também habilitaria recursos antes inatingíveis, como assinaturas granulares de micro‑streaming e gestão automatizada de liquidez de curto prazo.

Estamos realmente à beira de uma era disruptiva nos sistemas de pagamento, impulsionada pela tecnologia blockchain. Se a Stripe lançará oficialmente uma L1 ainda é incerto, mas as peças estratégicas certamente estão se encaixando para esse passo monumental.

TL;DR​

Ethereum acabou de ganhar duas primitivas poderosas que levam a experiência do usuário além de frases‑semente e dapps marcáveis, rumo a “experiências on‑chain clicáveis”.

• ERC-4337 traz abstração de conta ao Ethereum atual sem mudanças no protocolo central. Isso torna recursos como contas de contrato inteligente, patrocínio de gas, chamadas em lote e autenticação estilo passkey nativos nas carteiras.
• ERC-4804 introduz URLs web3:// — links legíveis por humanos que resolvem diretamente para chamadas de leitura de contrato e podem até renderizar HTML ou SVG on‑chain, tudo sem um servidor web tradicional atuando como intermediário. Pense nisso como “HTTP para a EVM”.

Quando usados juntos, ERC-4337 lida com ações, enquanto ERC-4804 lida com endereços. Essa combinação permite compartilhar um link que puxa sua interface de usuário de forma verificável a partir de um contrato inteligente. Quando o usuário está pronto para agir, o fluxo entrega a uma conta inteligente que pode patrocinar o gas e agrupar múltiplas etapas em um único clique perfeito.

Por Que Isso Importa Agora​

Não é apenas um futuro teórico; essas tecnologias já estão ao vivo e ganhando tração significativa. ERC-4337 já está escalado e comprovado na prática. O contrato canônico EntryPoint foi implantado na mainnet Ethereum em 1 de março de 2023, e desde então alimentou dezenas de milhões de contas de contrato inteligente e processou mais de 100 milhões de operações de usuário.

Simultaneamente, o protocolo central está convergindo com essas ideias. A atualização Pectra, lançada em maio de 2025, incluiu o EIP-7702, que permite que contas externamente possuídas padrão (EOAs) se comportem temporariamente como contas inteligentes. Isso complementa o ERC-4337 ao facilitar a transição para usuários existentes, em vez de substituir o padrão.

No front de endereçamento, web3:// agora está formalizado. O ERC-4804 especifica exatamente como uma URL se traduz em uma chamada EVM, e web3 foi listado pela IANA como um esquema URI provisório. As ferramentas e gateways necessários para tornar essas URLs práticas já estão disponíveis, transformando dados on‑chain em recursos compartilháveis e linkáveis.

Guia Rápido: ERC-4337 em Uma Página​

Em sua essência, o ERC-4337 introduz um trilho de transação paralelo ao Ethereum, construído para flexibilidade. Em vez de transações tradicionais, os usuários enviam objetos UserOperation para um mempool alternativo. Esses objetos descrevem o que a conta deseja fazer. Nós especializados chamados “Bundlers” capturam essas operações e as executam através de um contrato global EntryPoint.

Isso habilita três componentes chave:

1. Contas de Contrato Inteligente (SCAs): Essas contas contêm sua própria lógica. Elas definem o que torna uma transação válida, permitindo esquemas de assinatura personalizados (como passkeys ou multisig), chaves de sessão para jogos, limites de gasto e mecanismos de recuperação social. A conta, não a rede, impõe as regras.
2. Paymasters: Esses contratos especiais podem patrocinar taxas de gas para usuários ou permitir que paguem em tokens ERC‑20. Essa é a chave para desbloquear onboarding verdadeiramente “sem ETH na carteira” e criar experiências de um clique ao agrupar múltiplas chamadas em uma única operação.
3. Segurança contra DoS & Regras: O mempool público ERC‑4337 é protegido por regras de validação off‑chain padronizadas (definidas no ERC‑7562) que evitam que Bundlers desperdicem recursos em operações destinadas a falhar. Embora mempools alternativos possam existir para casos de uso especializados, essas regras compartilhadas mantêm o ecossistema coerente e seguro.

Modelo mental: ERC‑4337 transforma carteiras em apps programáveis. Em vez de apenas assinar transações brutas, os usuários enviam “intents” que o código da sua conta valida e o contrato EntryPoint executa — de forma segura e atômica.

Guia Rápido: ERC-4804 em Uma Página​

O ERC‑4804 fornece um mapeamento simples e direto de uma URL web3:// para uma chamada somente de leitura da EVM. A gramática da URL é intuitiva: web3://<nome-ou-endereço>[:chainId]/<método>/<arg0>?returns=(tipos). Nomes podem ser resolvidos via sistemas como ENS, e argumentos são tipados automaticamente com base no ABI do contrato.

Alguns exemplos:

• web3://uniswap.eth/ chamaria o contrato no endereço uniswap.eth com calldata vazio.
• web3://.../balanceOf/vitalik.eth?returns=(uint256) codificaria via ABI uma chamada à função balanceOf com o endereço de Vitalik e retornaria um resultado JSON tipado corretamente.

Importante, este padrão atualmente serve apenas para chamadas somente de leitura (equivalente às funções view do Solidity). Qualquer ação que altere o estado ainda requer uma transação — exatamente onde o ERC‑4337 ou o EIP‑7702 entram. Com web3 registrado como esquema URI provisório na IANA, o caminho está aberto para suporte nativo em navegadores e clientes, embora por ora dependa de extensões ou gateways.

Modelo mental: ERC‑4804 transforma recursos on‑chain em objetos web linkáveis. “Compartilhe esta visualização de contrato como URL” torna‑se tão natural quanto compartilhar um link para um painel.

Juntos: “Experiências On‑chain Clicáveis”​

Combinar esses dois padrões desbloqueia um padrão poderoso para construir aplicações descentralizadas hoje.

Primeiro, você entrega uma UI verificável via web3://. Em vez de hospedar seu frontend em um servidor centralizado como S3, você pode armazenar uma interface HTML ou SVG mínima diretamente on‑chain. Um link como web3://app.eth/render permite que um cliente resolva a URL e renderize a UI direto do contrato, garantindo que o usuário veja exatamente o que o código determina.

A partir dessa interface verificável, você pode disparar uma ação de um clique via ERC‑4337. Um botão “Mint” ou “Subscribe” pode compilar uma UserOperation que um paymaster patrocina. O usuário aprova com um passkey ou um simples prompt biométrico, e o contrato EntryPoint executa uma chamada em lote que implanta sua conta inteligente (se for a primeira vez) e completa a ação desejada em um único passo atômico.

Isso cria uma transferência profunda de deep‑link perfeita. A UI pode incorporar links baseados em intents que são tratados diretamente pela carteira do usuário, eliminando a necessidade de enviá‑lo a um site externo que ele possa não confiar. O conteúdo é o contrato, e a ação é a conta.

Isso desbloqueia:

• Testes sem gas e onboarding “funciona imediatamente”: Novos usuários não precisam adquirir ETH para começar. Sua aplicação pode patrocinar as primeiras interações, reduzindo drasticamente o atrito.
• Estado compartilhável: Um link web3:// é uma consulta ao estado da blockchain. Isso é perfeito para dashboards, provas de propriedade ou qualquer conteúdo que precise ser verificavelmente à prova de adulteração.
• Fluxos amigáveis a agentes: Agentes de IA podem buscar estado verificável via URLs web3:// e submeter intents transacionais através do ERC‑4337 usando chaves de sessão escopadas, tudo sem raspagem de tela frágil ou manuseio inseguro de chaves privadas.

Notas de Design para Construtores​

Ao implementar esses padrões, há algumas escolhas arquiteturais a considerar. Para ERC‑4337, é aconselhável começar com templates mínimos de contas inteligentes e adicionar capacidades por meio de módulos guardados para manter a lógica de validação central simples e segura. Sua política de paymaster deve ser robusta, com limites claros de gas patrocinado e listas brancas de métodos aprovados para prevenir ataques de griefing.

Para ERC‑4804, priorize links legíveis usando nomes ENS. Seja explícito sobre o chainId para evitar ambiguidades e inclua o parâmetro returns=(…) para garantir que os clientes recebam respostas tipadas e previsíveis. Embora seja possível renderizar UIs completas, costuma ser melhor manter HTML/SVG on‑chain mínimo, usando-os como shells verificáveis que podem buscar ativos mais pesados de armazenamento descentralizado como IPFS.

Por fim, lembre‑se de que EIP‑7702 e ERC‑4337 trabalham juntos, não contra. Com o EIP‑7702 agora ativo na atualização Pectra, usuários de EOAs existentes podem delegar ações a lógica de contrato sem implantar uma conta inteligente completa. As ferramentas no ecossistema de abstração de conta já estão se alinhando para suportar isso, suavizando o caminho de migração para todos.

Segurança, Realidade e Restrições​

Embora poderosos, esses sistemas têm trade‑offs. O contrato EntryPoint é um ponto de estrangulamento central por design; ele simplifica o modelo de segurança mas também concentra risco. Sempre use versões auditadas e canônicas. As regras de validação de mempool do ERC‑7562 são uma convenção social, não uma regra enforceada on‑chain, portanto não presuma que todo mempool alternativo ofereça a mesma resistência a censura ou proteção contra DoS.

Além disso, web3:// ainda está amadurecendo. Ele permanece um padrão de leitura, e qualquer operação de escrita requer uma transação. Enquanto o protocolo em si é descentralizado, os gateways e clientes que resolvem essas URLs podem ainda ser pontos potenciais de falha ou censura. A verdadeira “desbloqueabilidade” dependerá de suporte nativo amplo em clientes.

Um Blueprint Concreto​

Imagine que você queira construir um clube de membros alimentado por NFT com UI verificável e compartilhável e um processo de ingresso de um clique. Veja como você poderia entregá‑lo neste trimestre:

1. Compartilhe a UI: Distribua um link como web3://club.eth/home. Quando um usuário o abre, seu cliente resolve a URL, chama o contrato e renderiza uma UI on‑chain que exibe a lista de membros permitidos e o preço de mint.
2. Ingresso de Um Clique: O usuário clica no botão “Join”. Sua carteira compila uma UserOperation ERC‑4337 patrocinada pelo seu paymaster. Essa única operação agrupa três chamadas: implantar a conta inteligente do usuário (se ainda não houver), pagar a taxa de mint e registrar seus dados de perfil.
3. Recibo Verificável: Após a confirmação da transação, o usuário vê uma visualização de confirmação que é outro link web3://, como web3://club.eth/receipt/<tokenId>, criando um link permanente on‑chain para sua prova de associação.

O Grande Panorama​

Esses dois padrões sinalizam uma mudança fundamental em como construímos no Ethereum. Contas estão se tornando software. ERC‑4337 e EIP‑7702 estão transformando “UX de carteira” em um espaço para inovação de produto real, nos levando além de palestras sobre gerenciamento de chaves. Ao mesmo tempo, links estão se tornando consultas. ERC‑4804 restaura a URL como um primitivo para endereçar fatos verificáveis on‑chain, não apenas os frontends que os proxyam.

Juntos, eles encurtam a distância entre o que os usuários clicam e o que os contratos fazem. Essa lacuna antes era preenchida por servidores web centralizados e suposições de confiança. Agora, pode ser preenchida por caminhos de código verificáveis e mempools abertos e permissionless.

Se você está construindo aplicações cripto para consumidores, esta é sua chance de tornar o primeiro minuto do usuário encantador. Compartilhe um link, renderize a verdade, patrocine a primeira ação e mantenha seus usuários dentro de um loop verificável. Os trilhos estão aqui — agora é hora de lançar as experiências.

Introdução​

A IA e a Web3 estão a convergir de formas poderosas, com as interfaces gerais de IA a serem agora vistas como um tecido conjuntivo para a web descentralizada. Um conceito-chave que emerge desta convergência é o MCP, que tanto pode significar “Model Context Protocol” (conforme introduzido pela Anthropic) como ser vagamente descrito como um Metaverse Connection Protocol em discussões mais amplas. Em essência, o MCP é uma estrutura padronizada que permite que sistemas de IA interajam com ferramentas e redes externas de uma forma natural e segura – potencialmente “ligando” 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 neuro-simbólicos) poderiam conectar tudo no mundo Web3 através do 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 as 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ões centrada na propriedade do utilizador. Os entusiastas imaginaram substituir a infraestrutura centralizada da Web2 por alternativas baseadas em blockchain – por exemplo, o Ethereum Name Service (para DNS), Filecoin ou IPFS (para armazenamento) e DeFi para os trilhos financeiros. Em teoria, isto retiraria o controlo das plataformas das Big Tech e daria aos indivíduos auto-soberania sobre dados, identidade e ativos.

A realidade ficou aquém. Apesar de anos de desenvolvimento e hype, o impacto mainstream da Web3 permaneceu marginal. Os utilizadores médios da internet não migraram em massa para as redes sociais descentralizadas nem começaram a gerir chaves privadas. As principais razões incluíram uma má experiência do utilizador, transações lentas e caras, fraudes de alto perfil e incerteza regulatória. A “web da propriedade” descentralizada, em grande parte, “não se materializou” para além de uma comunidade de nicho. Em meados da década de 2020, até os proponentes de cripto admitiram que a Web3 não tinha proporcionado uma mudança de paradigma para o utilizador médio.

Entretanto, a IA estava a passar por uma revolução. À medida que o capital e o talento dos programadores se deslocavam de cripto para IA, avanços transformadores em deep learning e modelos de fundação (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 tinham tido dificuldade em fazer. De facto, o impacto dos grandes modelos de linguagem em apenas alguns anos superou drasticamente uma década de adoção de blockchain por parte dos utilizadores. Este contraste levou alguns a gracejar que “a Web3 foi desperdiçada em cripto” e que a verdadeira Web 3.0 está a emergir da onda da IA.

1.2 A Ascensão das Interfaces Gerais de IA​

Ao longo de décadas, as interfaces de utilizador evoluíram de páginas web estáticas (Web1.0) para aplicações interativas (Web2.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 utilizadores podem simplesmente expressar a sua intenção em linguagem simples e ter sistemas de IA a executar ações complexas em muitos domínios. Esta mudança é tão profunda que alguns sugerem redefinir a “Web 3.0” como a era dos agentes impulsionados por IA (“a Web Agêntica”) em vez da definição anterior centrada em blockchain.

No entanto, as primeiras experiências com agentes de IA autónomos expuseram um estrangulamento crítico. Estes agentes – por exemplo, protótipos como o AutoGPT – podiam gerar texto ou código, mas faltava-lhes uma forma robusta de comunicar com sistemas externos e entre si. Não havia “nenhuma linguagem comum nativa de IA” para a interoperabilidade. Cada integração com uma ferramenta ou fonte de dados era um hack personalizado, e a interação de IA para IA não tinha um protocolo padrão. Em termos práticos, um agente de IA podia ter uma grande capacidade de raciocínio, mas falhar na execução de tarefas que exigiam o uso de aplicações web ou serviços on-chain, simplesmente porque não sabia como falar com esses sistemas. Este desajuste – cérebros poderosos, E/S primitivas – era semelhante a ter um software super-inteligente preso atrás de uma GUI desajeitada.

1.3 Convergência e o Surgimento do MCP​

Em 2024, tornou-se evidente que, para a IA atingir o seu pleno potencial (e para a Web3 cumprir a sua promessa), era necessária uma convergência: os agentes de IA requerem acesso contínuo às capacidades da Web3 (aplicações descentralizadas, contratos, dados), e a Web3 precisa de mais inteligência e usabilidade, que a IA pode fornecer. É neste contexto que nasceu o MCP (Model Context Protocol). 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 forma estruturada e detetável para os “hospedeiros de IA” (como o ChatGPT, Claude, etc.) encontrarem e usarem uma variedade de ferramentas e recursos externos através de servidores MCP. Por outras palavras, o MCP é uma camada de interface comum que permite que agentes de IA se liguem a serviços web, APIs e até funções de blockchain, sem codificar cada integração de forma personalizada.

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 não precise de cabos diferentes para cada dispositivo), o MCP padroniza a forma como os agentes de IA se conectam a ferramentas e dados. Em vez de codificar diferentes chamadas de API para cada serviço (Slack vs. Gmail vs. nó Ethereum), um programador pode implementar a especificação MCP uma vez, e qualquer IA compatível com MCP pode entender como usar esse serviço. Os principais players de IA rapidamente viram a importância: a Anthropic tornou o MCP open-source, e empresas como a OpenAI e a Google estão a construir suporte para ele nos seus modelos. Este impulso sugere que o MCP (ou “Meta Connectivity Protocols” semelhantes) poderia tornar-se 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 Web3.0. Nas palavras de Simba Khadder, “o MCP visa padronizar uma API entre LLMs e aplicações,” semelhante a como as APIs REST permitiram 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 por si só, a convergência com a IA poderia tornar a descentralização útil, escondendo a complexidade por trás da linguagem natural e dos agentes autónomos. O restante deste relatório aprofunda como, técnica e praticamente, as interfaces gerais de IA (através de protocolos como o MCP) podem conectar tudo no mundo Web3.

2. Arquitetura Técnica: Interfaces de IA a Fazer a Ponte com as Tecnologias Web3​

Incorporar agentes de IA na stack Web3 requer integração em múltiplos níveis: redes de blockchain e contratos inteligentes, armazenamento descentralizado, sistemas de identidade e economias baseadas em tokens. As interfaces gerais de IA – desde grandes modelos de fundação a sistemas neuro-simbólicos híbridos – podem servir como um “adaptador universal” que conecta estes componentes. Abaixo, analisamos a arquitetura de tal integração:

Figura: Um diagrama conceptual da arquitetura do MCP, mostrando como os hospedeiros de IA (aplicações baseadas 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 (por exemplo, Slack, Gmail, calendários ou dados locais), análogo a periféricos que se conectam através de um hub universal. Esta interface MCP padronizada permite que agentes de IA acedam a serviços remotos e recursos on-chain através 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 impor lógica de uma maneira sem confiança. Como pode uma interface de IA interagir com estes? Existem duas direções a considerar:

• IA a ler da blockchain: Um agente de IA pode precisar de dados on-chain (por exemplo, preços de tokens, saldo de ativos do utilizador, propostas de DAO) como contexto para as suas decisões. Tradicionalmente, a recuperação de dados de blockchain requer a interação com APIs RPC de nós ou bases de dados de subgrafos. Com uma estrutura como o MCP, uma IA pode consultar um servidor MCP padronizado de “dados de blockchain” para obter informações on-chain em tempo real. Por exemplo, um agente habilitado para MCP poderia pedir o volume de transações mais recente de um determinado token, ou o estado de um contrato inteligente, e o servidor MCP lidaria com os detalhes de baixo nível de conexão à blockchain e devolveria os dados num formato que a IA pode usar. Isto aumenta a interoperabilidade ao desacoplar a IA do formato de API de qualquer blockchain específica.

• IA a escrever na blockchain: De forma mais poderosa, os agentes de IA podem executar chamadas de contratos inteligentes ou transações através de integrações Web3. Uma IA poderia, por exemplo, executar autonomamente uma troca numa exchange descentralizada ou ajustar parâmetros num contrato inteligente se certas condições forem cumpridas. Isto é alcançado pela IA a invocar um servidor MCP que encapsula a funcionalidade de transação de 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 a mecânica específica da cadeia. Usando tal ferramenta, um agente de IA poderia desencadear ações on-chain “sem intervenção humana”, permitindo dApps autónomas – por exemplo, um cofre DeFi gerido por IA que se reequilibra ao assinar transações quando as condições de mercado mudam.

Nos bastidores, estas interações ainda dependem de carteiras, chaves e taxas de gás, 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 alimentados on-chain de uma forma confiável. O Cross-Chain Interoperability Protocol (CCIP) da Chainlink, por exemplo, poderia permitir que um modelo de IA considerado fiável desencadeasse múltiplos contratos em diferentes cadeias simultaneamente em nome de um utilizador. Em resumo, as interfaces gerais de IA podem atuar como um novo tipo de cliente Web3 – um que pode tanto consumir dados de blockchain como produzir transações de blockchain através de protocolos padronizados.

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

Um aspeto intrigante da integração IA-Web3 é o potencial para arquiteturas neuro-simbólicas que combinam a capacidade de aprendizagem da IA (redes neuronais) com a lógica rigorosa dos contratos inteligentes (regras simbólicas). Na prática, isto poderia significar que os agentes de IA lidam com a tomada de decisões não estruturadas e passam certas tarefas para contratos inteligentes para execução verificável. Por exemplo, uma IA pode analisar o sentimento do mercado (uma tarefa imprecisa), mas depois executar trocas através de um contrato inteligente determinístico que segue regras de risco pré-estabelecidas. A estrutura MCP e padrões relacionados tornam tais transferências viáveis, dando à IA uma interface comum para chamar funções de contrato ou para consultar as regras de uma DAO antes de agir.

Um exemplo concreto é a AI-DSL (Linguagem Específica de Domínio de IA) da SingularityNET, que visa padronizar a comunicação entre agentes de IA na sua rede descentralizada. Isto pode ser visto como um passo em direção à integração neuro-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 os contratos inteligentes chamassem modelos de IA para a resolução de problemas on-chain. Embora executar grandes modelos de IA diretamente on-chain seja impraticável hoje, abordagens híbridas estão a surgir: por exemplo, certas blockchains permitem a verificação de computações de ML através de provas de conhecimento zero ou execução confiável, permitindo a verificação on-chain de resultados de IA off-chain. Em resumo, a arquitetura técnica prevê os sistemas de IA e os contratos inteligentes de blockchain como componentes complementares, orquestrados através de protocolos comuns: a IA lida com a

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.