A arquitetura blockchain está se afastando do debate simplista de que "uma única cadeia faz tudo". A questão mais relevante agora é quais funções devem permanecer juntas, quais podem ser separadas e quais novos riscos surgem quando um sistema se torna modular. Isso é importante porque execução, liquidação, consenso, disponibilidade de dados, comprovação, sequenciamento e segurança compartilhada agora podem ser combinados de diversas maneiras.
Em setembro de 2026, não há um vencedor universal. Cadeias monolíticas podem oferecer um modelo operacional e de segurança mais robusto, enquanto sistemas modulares podem especializar camadas individuais e escalar diferentes recursos de forma independente. Celestia é um dos exemplos mais claros de uma rede especializada em disponibilidade de dados. EigenLayer desempenha um papel diferente: não é simplesmente "mais uma blockchain modular", mas sim uma estrutura de reestruturação e segurança compartilhada que pode ajudar serviços adicionais a impulsionar a segurança econômica. O próprio Ethereum opera cada vez mais como um sistema L1+L2, em vez de se encaixar perfeitamente em um rótulo puramente monolítico.
Uma blockchain monolítica lida com as principais funções do protocolo dentro de um sistema base integrado. Essas funções geralmente incluem execução de transações, liquidação, consenso e disponibilidade de dados. A arquitetura é mais fácil de entender porque a mesma cadeia define as regras, ordena as atividades, verifica as transições de estado e disponibiliza os dados das transações.
Uma arquitetura modular de blockchain separa algumas dessas tarefas em camadas especializadas. Uma rede pode executar transações, outra pode fornecer disponibilidade de dados e outra pode fornecer liquidação ou segurança. A documentação da Celestia descreve o modelo modular como aquele em que a execução e a liquidação podem residir acima de uma camada base focada em consenso e disponibilidade de dados. Sua documentação atual também explica a amostragem de disponibilidade de dados (DAS, na sigla em inglês), que permite que nós leves verifiquem se os dados do bloco foram publicados sem precisar baixar cada byte do bloco. Consulte a documentação de disponibilidade de dados da Celestia .
Não. A modularidade é uma ferramenta de projeto, não uma garantia de melhor desempenho ou maior segurança. Separar funções pode permitir que cada camada otimize para uma tarefa mais específica, mas também cria interfaces entre as camadas. Essas interfaces introduzem suposições adicionais: as pontes podem falhar, os sequenciadores podem censurar, os dados podem estar indisponíveis quando necessários, as provas podem ser atrasadas ou um aplicativo pode depender de vários sistemas com diferentes modelos de confiança.
Projetos monolíticos reduzem parte dessa complexidade entre camadas, pois o mesmo conjunto de validadores e regras de protocolo geralmente governam uma parcela maior da pilha. A desvantagem é que cada nó completo pode precisar lidar com mais trabalho, o que pode dificultar o aumento da taxa de transferência bruta sem elevar os requisitos de hardware ou largura de banda.
Ação para os leitores: ao comparar duas blockchains, não se limitem ao número de transações por segundo ou às taxas. Anotem onde a execução ocorre, onde os dados são publicados, onde a liquidação final é realizada, quem pode reordenar as transações e qual componente pode causar a paralisação do sistema ou a perda de fundos.
Celestia é melhor compreendida como uma rede especializada em consenso e disponibilidade de dados. Aplicativos e rollups podem publicar dados na Celestia enquanto executam transações em outros locais. Isso altera o problema de escalabilidade: em vez de exigir que uma única blockchain execute todas as transações de um aplicativo, a Celestia se concentra em disponibilizar e verificar os dados dos blocos.
Sua técnica principal é a amostragem de disponibilidade de dados. O Celestia utiliza códigos de apagamento para bloquear dados, e nós leves amostram pequenas porções desses dados com provas. Uma amostragem bem-sucedida garante que o bloco de dados completo esteja disponível. O Celestia também utiliza árvores Merkle com namespaces, permitindo que os aplicativos recuperem e comprovem a integridade dos dados relevantes ao seu próprio namespace, em vez de baixar dados de aplicativos não relacionados.
Isso não significa que "disponibilidade de dados" seja a mesma coisa que armazenamento permanente. A própria documentação do Celestia distingue explicitamente a comprovação da publicação de novos dados de bloco da manutenção permanente de dados históricos. Sua documentação atual sobre recuperabilidade observa que a amostragem de nós leves utiliza uma janela móvel de sete dias sob o modelo de poda atual, portanto, os desenvolvedores ainda precisam de um plano para recuperação histórica a longo prazo. Consulte a documentação sobre recuperabilidade e poda do Celestia .
Ação para desenvolvedores: se você estiver considerando o Celestia para um rollup ou cadeia de aplicativos, defina sua estratégia de dados históricos separadamente da sua estratégia de disponibilidade de dados em tempo real.
Não no mesmo sentido. Essa é uma simplificação comum que vale a pena corrigir. A ideia central do EigenLayer é a redefinição de tokens: tokens de participação relacionados ao Ethereum podem ser utilizados para realizar validações adicionais em serviços externos. Esses serviços são historicamente chamados de Serviços Ativamente Validados, ou AVSs. O objetivo é permitir que novas infraestruturas utilizem segurança criptoeconômica compartilhada, em vez de criar sempre uma economia de validadores completamente separada do zero.
Portanto, o EigenLayer se encaixa na discussão sobre modularidade como uma primitiva de segurança e coordenação, e não apenas como uma cadeia de disponibilidade de dados. A Eigen Labs descreveu o lançamento de sua rede principal em 2024 como o lançamento de um protocolo de reestruturação destinado a expandir a segurança criptoeconômica para serviços adicionais. Consulte o relatório oficial "EigenLayer 2024 Year in Review" . A documentação atual do EigenCloud também posiciona os AVSs (Serviços de Acesso Aberto) do EigenLayer como uma forma de construir serviços verificáveis por meio de suas ferramentas de desenvolvimento; consulte a documentação do EigenCloud .
O EigenDA é um exemplo útil de como esse modelo de segurança compartilhada pode suportar infraestrutura modular. Trata-se de um serviço de disponibilidade de dados construído no ecossistema EigenLayer, enquanto o próprio EigenLayer é a estrutura mais ampla de reestruturação e segurança. Uma explicação oficial da arquitetura da Eigen Labs, mais antiga, mas ainda útil, descreve o EigenDA como um armazenamento de disponibilidade de dados construído sobre o EigenLayer e mostra como um rollup pode usar o EigenDA para dados, enquanto ainda utiliza o Ethereum para outras partes da pilha. Consulte a visão geral oficial da integração do EigenDA .
Ação para os leitores: separem “EigenLayer” de “EigenDA” em seu modelo mental. Um é a estrutura mais ampla de segurança compartilhada/reinvestimento; o outro é um sistema específico de disponibilidade de dados nesse ecossistema.
Ethereum é um bom exemplo de por que o rótulo binário está se tornando menos útil. A camada 1 do Ethereum ainda integra execução, consenso, liquidação e disponibilidade de dados nativos na camada base. Mas a estratégia de escalabilidade do ecossistema tem transferido cada vez mais a execução do usuário para a camada 2 (rollups), enquanto o Ethereum fornece liquidação, segurança e capacidade de dados.
A Fundação Ethereum descreveu explicitamente o Ethereum como um sistema L1-mais-L2. Em março de 2026, escreveu que a plataforma deve ser entendida como uma relação de reforço mútuo entre a camada L1 e uma rede diferenciada de camadas L2, reconhecendo também que a fragmentação é uma grande desvantagem de um ambiente multichain. Veja a estratégia da Fundação Ethereum para plataformas L1 e L2 .
Isso também é visível no roteiro de dados do Ethereum. A EIP-4844 introduziu o espaço de blobs para rollups, tornando mais barato publicar dados da camada 2 sem tratar cada byte como dados de chamada de execução comuns. A documentação oficial do Ethereum explica que os rollups dependem da disponibilidade de dados para verificação independente e que os dados de blobs são temporários, e não um armazenamento histórico permanente. Consulte a documentação sobre disponibilidade de dados em Ethereum.org .
| Pergunta | Abordagem monolítica | Abordagem modular |
|---|---|---|
| Onde são tratadas as funções principais? | Na maior parte dos casos, está contido em um único protocolo base integrado. | Dividido em camadas ou serviços especializados. |
| Estratégia de escalonamento | Aumentar a capacidade do sistema base, mantendo as funções integradas. | Escalar a execução, a disponibilidade de dados, a comprovação ou a segurança de forma independente. |
| Análise de segurança | Geralmente há menos dependências externas para auditar. | É necessário analisar a camada relevante mais frágil e as interfaces entre as camadas. |
| Flexibilidade do desenvolvedor | Mais limitado pelas escolhas de design da camada base. | É possível combinar ambientes de execução, sistemas DA, camadas de liquidação e serviços de segurança. |
| Experiência do usuário | Pode ser mais simples quando os ativos e os aplicativos permanecem em uma única cadeia. | Pode criar fragmentação de pontes, carteiras, liquidez e cadeias cruzadas. |
| Caminho de atualização | As alterações podem exigir coordenação em todo o protocolo integrado. | Os módulos individuais podem evoluir independentemente, mas a compatibilidade torna-se uma preocupação adicional. |
Às vezes, mas não necessariamente. A questão importante é se um sistema modular preserva as propriedades de segurança que os usuários esperam obter. Um sistema de consolidação que publica dados em uma rede, realiza a liquidação em outra, utiliza um sequenciador centralizado e depende de uma ponte separada apresenta múltiplos pontos vulneráveis a falhas. Um bug ou uma falha de governança em um componente crítico pode ser um problema, mesmo que a cadeia de liquidação em si permaneça segura.
Por outro lado, a especialização pode melhorar a segurança quando uma camada é projetada especificamente para uma tarefa e expõe regras de verificação claras. Sistemas de segurança compartilhada também podem reduzir a necessidade de cada novo serviço inicializar um conjunto de validadores totalmente independente. O resultado depende da implementação, da distribuição de participações, da diversidade de operadores, das condições de penalização, dos sistemas de prova, do projeto da ponte, das chaves de atualização e da descentralização operacional.
Ação para investidores e usuários: procurem por um modelo de ameaças publicado e uma descrição clara de quem pode atualizar contratos, interromper saques, censurar transações ou substituir operadores. Apenas frases como "Protegido pelo Ethereum", "usa Celestia" ou "construído sobre EigenLayer" não fornecem detalhes suficientes.
Diversas questões importantes permanecem sem resposta. Em primeiro lugar, ainda não está claro quais serviços modulares desenvolverão mercados de taxas duradouros. Uma camada tecnicamente eficiente ainda precisa de demanda suficiente para custear operadoras, largura de banda, armazenamento, comprovação de dados e desenvolvimento contínuo.
Em segundo lugar, a experiência do usuário entre diferentes cadeias e camadas continua sendo um desafio. A própria estratégia da plataforma Ethereum para 2026 identifica a fragmentação como um problema central. Uma melhor interoperabilidade pode ocultar grande parte da complexidade dos usuários, mas ocultar a complexidade não é o mesmo que eliminar a necessidade de confiança mútua.
Em terceiro lugar, os sistemas modulares podem deslocar a centralização em vez de eliminá-la. A execução pode ser descentralizada enquanto o sequenciamento é concentrado; a disponibilidade de dados pode ser descentralizada enquanto a geração de provas é concentrada; ou a segurança pode ser economicamente agrupada enquanto a participação do operador permanece concentrada.
Por fim, o próprio termo "modular" abrange muitas arquiteturas. Um rollup soberano usando Celestia não é o mesmo que um Ethereum L2 enviando blobs para o Ethereum, e tampouco é o mesmo que um AVS usando a segurança do EigenLayer. Portanto, as afirmações sobre blockchains modulares devem ser avaliadas camada por camada.
Escolha com base no gargalo e nos requisitos de segurança da aplicação, não no rótulo. Uma aplicação financeira de alto valor pode preferir um caminho de liquidação e disponibilidade de dados fortemente integrado, mesmo que custe mais. Uma aplicação de jogos ou social pode valorizar mais a execução barata e a alta taxa de transferência de dados. Uma cadeia de aplicações pode querer regras de execução personalizadas ao terceirizar a disponibilidade e a segurança dos dados.
Uma avaliação prática deve responder a cinco perguntas antes de escolher uma pilha de pilhas de pilhas:
A direção mais plausível é a híbrida, em vez da abordagem "tudo ou nada". É improvável que as blockchains monolíticas desapareçam, pois a integração de execução e segurança pode ser valiosa. Ao mesmo tempo, redes especializadas de disponibilidade de dados, agregações (rollups), serviços de segurança compartilhada, sistemas de prova e camadas de execução interoperáveis estão oferecendo aos desenvolvedores mais maneiras de montar a infraestrutura de blockchain.
Celestia demonstra a importância de especializar a disponibilidade de dados. EigenLayer demonstra a importância de tratar a segurança econômica como um serviço que pode ser reutilizado por outros sistemas. Ethereum mostra como uma blockchain base pode permanecer integrada enquanto evolui para uma plataforma modular mais ampla, com camadas L1 e L2.
A mudança importante não é que todas as blockchains devam se tornar modulares. É que os desenvolvedores não precisam mais aceitar uma arquitetura fixa. A próxima fase das criptomoedas provavelmente será definida pela capacidade dos projetos de combinar especialização com segurança verificável, limites claros de falha, economia sustentável e uma experiência do usuário que não exija que as pessoas entendam todas as camadas subjacentes.
Compare Banana Gun, Maestro e Sol Trading Bot através de uma negociação hipotética de SOL, com verificações práticas de carteira, Telegram, slippage, taxas e segurança contra fraudes.
Um guia prático sobre capital privado e dívida privada tokenizados: como funciona, exemplos reais, benefícios, riscos, regulamentação e o que observar a seguir.
Compare Hyperliquid, dYdX e GMX em termos de modelo de execução, taxas, financiamento, liquidez, garantias e risco, utilizando um cenário hipotético de negociação na prática.
Entenda as diferenças entre blockchains modulares e monolíticas, onde Celestia e EigenLayer se encaixam, as vantagens e desvantagens em termos de segurança e escalabilidade e o que pode moldar o futuro das criptomoedas.
Regras práticas de risco para derivativos de criptomoedas: alavancagem, dimensionamento de posição, stops, liquidação, margem, financiamento, correlação e risco de câmbio.
Um guia para iniciantes sobre reestruturação de estruturas com EigenLayer e Symbiotic: como as recompensas são criadas, de onde vem a redução de riscos e como comparar oportunidades.
Aprenda como funcionam os tokens ordinais do Bitcoin e os tokens BRC-20, por que eles criam demanda por espaço em bloco, como podem afetar as taxas e o que os iniciantes devem verificar antes de usá-los.
Aprenda a interpretar o interesse em aberto com base em preço, financiamento, volume e liquidações para distinguir alavancagem de alta, alavancagem de baixa, desalavancagem e risco de concentração de mercado.
Compare a estrutura criptográfica mais recente da SEC dos EUA, as regras MiCA da UE e os principais regimes asiáticos em Hong Kong, Singapura, Japão e Coreia do Sul, a partir de setembro de 2026.
Aprenda a avaliar uma possível altseason usando a liquidez das stablecoins, os fluxos de câmbio, a atividade da rede e o MVRV — sem depender de um único indicador mágico.
