Rollups-as-a-Service em 2025: OP, ZK, Arbitrum Orbit, Polygon CDK e zkSync Hyperchains
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:
| Aspecto | OP Stack (Optimism) | ZK Stack (zkSync) | Arbitrum Orbit | Polygon CDK (AggLayer) |
|---|---|---|---|---|
| Tipo de Rollup | Rollup Otimista | Zero-Knowledge (Validade) | Rollup Otimista | Zero-Knowledge (Validade) |
| Sistema de Prova | Provas de falha (provas de fraude) | Provas de validade ZK-SNARK | Provas de falha (provas de fraude) | Provas de validade ZK-SNARK |
| Compatibilidade EVM | Equivalente a EVM (geth) | Alta – zkEVM (baseado em LLVM) | Equivalente a EVM (Arbitrum Nitro) + WASM via Stylus | Polygon zkEVM (Equivalente a EVM) |
| Disponibilidade de Dados | Ethereum L1 (on-chain); módulos Alt-DA conectáveis (Celestia, etc.) | Ethereum L1; também opções Validium off-chain (Celestia, Avail, EigenDA) | Ethereum L1 (rollup) ou comitê AnyTrust (DAC off-chain); suporta Celestia, Avail | Ethereum L1 (rollup) ou off-chain (validium via Avail ou Celestia); híbrido possível |
| Design do Sequenciador | Sequenciador único (padrão); multi-sequenciador possível com personalização. Visão de sequenciador compartilhado para a Superchain (futuro). | Configurável: pode ser centralizado ou descentralizado; fila de prioridade L1 suportada. | Configurável: operador único ou validadores descentralizados. | Flexível: sequenciador único ou múltiplos validadores (ex: comitê PoS). |
| Acesso ao Sequenciador | Centralizado hoje (o sequenciador de cada chain OP é executado por seu operador); ainda não é sem permissão. Planos para uma rede de sequenciadores compartilhada e sem permissão entre as OP Chains. A fila de backup L1 permite o envio de transações sem confiança se o sequenciador falhar. | O zkSync Era usa um sequenciador centralizado (Matter Labs), mas o ZK Stack permite lógica de sequenciador personalizada (até mesmo consenso externo). O sequenciamento prioritário L1 é suportado para garantir a justiça. Opções de sequenciador descentralizado em desenvolvimento. | O Arbitrum One usa um sequenciador centralizado (Offchain Labs), com failover via inbox L1. As chains Arbitrum Orbit podem executar seu próprio sequenciador (inicialmente centralizado) ou instituir um conjunto de validadores. A atualização BoLD (2025) permite a validação sem permissão para descentralizar as chains Orbit. | O Polygon zkEVM começou com um único sequenciador (Polygon Labs). O CDK permite lançar uma chain com um conjunto de validadores permissionados ou outro consenso para descentralização. Muitas chains CDK começam centralizadas por simplicidade, com um roteiro para sequenciadores operados pela comunidade posteriormente. |
| Token de Taxa | ETH por padrão em L2s baseadas em OP (para facilitar a UX). Token de gás personalizado é tecnicamente suportado, mas a maioria das OP Chains opta por ETH ou um token padrão para interoperabilidade. (A orientação recente do OP Stack favorece tokens comuns em toda a Superchain). | Suporte para tokens de base personalizados – os desenvolvedores podem escolher ETH ou qualquer ERC-20 como o gás nativo. (Essa flexibilidade permite economias específicas de projetos em chains baseadas em zkSync.) | Suporte para token de gás personalizado (atualização no final de 2023). As chains podem usar ETH, o ARB da Arbitrum ou seu próprio token para taxas. Exemplo: A Ape Chain usa APE como gás. | Suporte para token nativo personalizado. Muitas chains Polygon CDK usam MATIC ou outro token como gás. O ecossistema da Polygon incentiva o uso de MATIC para consistência entre chains, mas não é obrigatório. |
| Modelo de Taxas e Custos | Os usuários pagam gás L2 (coletado pelo sequenciador) mais os custos de postagem de dados L1. O sequenciador deve postar dados de transação (calldata ou blobs) no Ethereum, então uma parte das taxas cobre o gás L1. Partilha de receita: As OP Chains na Superchain comprometem ~2,5% da receita para o Optimism Collective (financiando bens públicos). | Os usuários pagam taxas (geralmente em ETH ou no token escolhido) que cobrem a verificação de prova L1 e os dados. Sem “imposto” a nível de protocolo sobre as taxas – o sequenciador de cada chain retém a receita para incentivar os operadores. Os custos do provador ZK são um fator: os operadores podem cobrar taxas ligeiramente mais altas ou usar provadores eficientes para gerenciar os custos. A finalidade é rápida (sem atraso), então os usuários não precisam de saídas rápidas de terceiros. | Os usuários pagam gás (em ETH ou no token da chain) cobrindo a execução L2 + custo do lote L1. Sequenciadores/validadores retêm a receita das taxas; sem partilha de receita obrigatória para a DAO da Arbitrum ou L1 (além dos custos de gás L1). Para evitar o atraso otimista de 7 dias, muitas chains Orbit integram provedores de liquidez ou pontes oficiais de retirada rápida (a Arbitrum suporta saídas rápidas de 15 minutos em algumas chains Orbit via redes de liquidez). | Os usuários pagam taxas de gás que cobrem os custos de prova e postagem. Sequenciadores ou validadores ganham essas taxas; a Polygon não impõe nenhum aluguel ou imposto sobre a receita da chain CDK. Usar DA off-chain (modo validium) pode cortar as taxas em mais de 100x (armazenando dados na Celestia ou Avail em vez do Ethereum), ao custo de algumas suposições de confiança. |
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:
| Design do Sequenciador | OP Stack | ZK Stack (zkSync) | Arbitrum Orbit | Polygon CDK |
|---|---|---|---|---|
| Modelo de operador padrão | Sequenciador único (operado pelo projeto) | Sequenciador único (Matter Labs ou operado pelo projeto) | Sequenciador único (operado pelo projeto/Offchain Labs) | Sequenciador único (operado pelo projeto ou pela Polygon) |
| Opções de descentralização | Sim – pode personalizar o consenso, ex: múltiplos sequenciadores ou futuro conjunto compartilhado | Sim – configurável; pode integrar consenso externo ou filas de prioridade | Sim – configurável; pode usar multi-validador (comitê AnyTrust ou personalizado) | Sim – pode integrar validadores PoS ou consenso IBFT (escolha do projeto) |
| Participação sem permissão | Planejado: Sequenciador compartilhado da Superchain (ainda não ativo). Os provadores de fraude são sem permissão na L1 (qualquer um pode desafiar). | Ainda não (nenhum leilão público de sequenciador ainda). As provas de validade não precisam de desafiantes. A comunidade pode executar nós de leitura, mas não produzir blocos a menos que escolhida. | Emergente: O BoLD permite que qualquer pessoa valide provas de fraude. O sequenciador ainda é escolhido pela chain (poderia ser via DAO no futuro). | Ainda não. Os sequenciadores são nomeados pelos proprietários da chain ou os validadores são permissionados/staked. O roteiro da Polygon inclui validação comunitária eventualmente. |
| Resistência à censura | Fila L1 para os usuários garante a inclusão. A governança com "rodinhas de apoio" pode vetar a má conduta do sequenciador. | Fila de prioridade L1 para inclusão. O modo Validium precisa de confiança no comitê de DA para a disponibilidade de dados. | A caixa de entrada L1 garante a inclusão se o sequenciador parar. O modo DAC requer ≥1 membro honesto do comitê para fornecer dados. | Depende do consenso da chain – ex: se usar um conjunto de validadores, precisa de ≥2/3 honestos. O fallback do modo rollup é a inclusão na L1 do Ethereum. |
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
starportdo 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