Blockchains Modulares vs Monolíticas: Explicação Simples

O que 'modular vs monolítica' significa na prática

Se já leste um thread no X ou assististe a uma palestra numa conferência, provavelmente já ouviste chamar à Solana monolítica e à Celestia modular. Os termos são usados de forma vaga, às vezes como argumento de venda, por isso vale a pena reduzi-los aos princípios básicos.

Uma blockchain tem de fazer quatro tarefas. Tem de executar transações, ou seja, correr o código que diz 'A Alice envia 1 ETH ao Bob.' Tem de liquidar essas transações, ou seja, verificar se a execução foi correta e se os saldos resultantes são finais. Tem de chegar a consenso sobre a ordem das transações entre vários computadores independentes. E tem de tornar os dados das transações subjacentes disponíveis para que qualquer pessoa possa verificar de forma independente o histórico da cadeia.

Uma blockchain monolítica faz estas quatro tarefas numa única rede, com o mesmo conjunto de validadores. Bitcoin, Ethereum (antes de 2022), Solana, Aptos e Sui são todas monolíticas no sentido em que um único conjunto de validadores trata da execução, liquidação, consenso e disponibilidade de dados em conjunto. Uma blockchain modular divide essas tarefas por camadas ou redes separadas. A Celestia, por exemplo, foi construída para fazer apenas consenso e disponibilidade de dados, deixando a execução para cadeias rollup separadas que publicam os dados das suas transações de volta na Celestia. A EigenDA faz disponibilidade de dados para a Ethereum, enquanto a execução acontece em rollups como a Arbitrum.

Isto parece limpo num slide. Na prática, a fronteira é difusa. Mesmo a Ethereum, a história modular de referência, ainda tem o seu próprio conjunto de validadores que faz tudo na camada base. A parte modular é que a maior parte da atividade dos utilizadores acontece agora em rollups que entregam a disponibilidade de dados e algum trabalho de liquidação à Ethereum. Portanto, 'modular' e 'monolítica' são na verdade posições num espetro, e a maioria das cadeias reais fica algures no meio.

Porque é que as equipas separam as quatro tarefas desde o início

O argumento original para a modularidade é de escalabilidade. Se um único conjunto de validadores tem de fazer as quatro tarefas, então a rede está limitada pelo que o hardware do validador mais fraco conseguir suportar. A Bitcoin é lenta em parte porque deliberadamente mantém os requisitos para validadores baixos para que qualquer pessoa possa correr um nó. A Ethereum, antes da era dos rollups, bateu num teto semelhante à volta das 15 a 30 transações por segundo.

Separar as tarefas permite que cada camada otimize para a sua própria limitação. Uma camada de disponibilidade de dados como a Celestia pode usar um esquema de codificação especializado chamado amostragem de disponibilidade de dados que permite que clientes leves verifiquem blocos grandes sem os descarregar. Uma camada de execução pode focar-se em correr smart contracts rapidamente. Uma camada de liquidação pode ser uma cadeia lenta, cara e ultra-segura como a Ethereum, que finaliza resultados de muitos rollups. Em teoria, obténs mais capacidade total porque cada camada pode escalar horizontalmente, adicionando mais máquinas, sem arrastar as outras para baixo.

Outra motivação é a soberania e personalização. Uma equipa de rollup pode escolher o seu próprio ambiente de execução, token de gas e mercado de taxas, e depois alugar segurança a uma camada base em vez de criar o seu próprio conjunto de validadores. É assim que um projeto pode lançar uma cadeia com alguns milhões de euros em financiamento inicial em vez de centenas de milhões em capital de staking.

O compromisso é que passas a coordenar várias redes que têm de comunicar entre si, muitas vezes através de bridges que são por si só uma grande fonte de ataques. Também herdas a segurança da camada base, mas apenas na medida em que a camada base está a fazer o trabalho crítico de segurança de que dependes. Se um rollup usa a Celestia para disponibilidade de dados, mas o seu próprio sequenciador para execução, o utilizador está a confiar em dois modelos de segurança diferentes, não num só.

Os riscos honestos das arquiteturas modulares

As cadeias modulares são frequentemente apresentadas como o passo seguinte óbvio, mas os modos de falha são reais e a história das criptomoedas está cheia de lições caras. Os maiores riscos distribuem-se por três categorias.

Pressupostos de confiança entre camadas. Quando se separa a execução da disponibilidade de dados, o utilizador está agora a confiar que ambas as camadas fizeram corretamente o seu trabalho. Se a camada de disponibilidade de dados retiver dados, uma camada de execução pode ficar num estado em que ninguém consegue provar se uma transação é válida. Se a prova de fraude ou a prova de validade da camada de execução tiver erros, fundos podem ser perdidos. Os famosos ataques às bridges Wormhole e Ronin não foram propriamente "falhas modulares", mas ilustram que adicionar interfaces entre sistemas multiplica a superfície de ataque. As arquiteturas modulares têm, por construção, mais interfaces.

Latência e finalidade. Um rollup que publica dados numa camada separada geralmente tem de esperar que essa camada confirme os dados antes de poder ser considerado totalmente finalizado. A Celestia finaliza em cerca de 1 a 2 minutos. A camada de disponibilidade de dados da Ethereum é igualmente lenta. Isto é muito mais rápido do que esperar uma semana por uma confirmação na Bitcoin, mas é uma ordem de grandeza mais lento do que a finalidade em menos de um segundo da Solana. Para trading, bridges ou bots de liquidação, esta diferença de latência não é académica; é a diferença entre uma estratégia lucrativa e uma não lucrativa.

A segurança partilhada não é gratuita. A ideia de que se "aluga segurança" a uma camada base parte do princípio de que essa camada base é honesta e bem financiada. Se construir sobre uma camada de disponibilidade de dados mais pequena, está a herdar o seu conjunto de validadores, que pode ser muito mais pequeno e mais barato de atacar do que o da Ethereum. A EigenDA está ligada ao design de restaking da EigenLayer, que tem por resolver questões sobre slashing e economia dos validadores. O conjunto de validadores da Celestia é real, mas é mais recente e menos testado em batalha do que o da Ethereum. Nada disto significa que estes sistemas sejam inseguros na prática, mas significa que "modular" não é uma melhoria mágica de segurança. É um conjunto diferente de compromissos.

Porque é que algumas equipas estão a voltar aos designs monolíticos

Uma das tendências menos notadas de 2024 a 2026 é que várias equipas que começaram com uma narrativa modular voltaram a aproximar-se de designs monolíticos. As razões são sobretudo práticas.

Solana é o caso óbvio. Sempre foi monolítica, com um único conjunto de validadores a fazer os quatro trabalhos e requisitos de hardware agressivos. O período 2024–2025 viu um renovado investimento na Solana, incluindo o cliente Firedancer da Jump Crypto, a proposta SIMD-0096 e uma utilização crescente em DeFi e trading de memecoins. Os críticos que em 2022 chamaram à Solana "centralizada" tiveram de lidar com o facto de que, por muitas métricas, é a segunda cadeia economicamente mais ativa do mundo.

MegaETH é um exemplo mais direto de re-monolitização. Posiciona-se como uma cadeia EVM em tempo real e de elevado throughput que trata execução, settlement e disponibilidade de dados numa única rede, otimizada para aplicações de baixa latência. A equipa tem sido clara ao afirmar que considera o custo de separar camadas demasiado alto para o seu caso de uso. Isto não é um rollup. É uma nova L1 monolítica com uma filosofia de design diferente.

Mesmo na própria Ethereum, a distinção está a esbater-se. Os based rollups e as appchains estão a reintegrar mais responsabilidades na camada base, e a evolução para rollups nativos com partilha de sequenciação sugere que parte da separação modular ia ser sempre um andaime temporário e não a arquitetura final.

O padrão é consistente. A modularidade é uma ferramenta poderosa para arrancar, mas a complexidade operacional da coordenação entre camadas, o custo de latência e a dificuldade de construir boas primitivas de segurança partilhada empurraram as equipas sérias a procurar formas de voltar a juntar as peças. Os diagramas em 2021 faziam parecer uma separação de responsabilidades limpa. A realidade de correr estes sistemas em produção é mais complicada.

Como é que o espetro se parece na prática

Em vez de uma escolha binária, é mais útil pensar em cada cadeia como pontuada em quatro eixos: quanto da execução, settlement, consenso e disponibilidade de dados faz por si própria.

• Bitcoin: monolítica, faz os quatro com uma camada de execução deliberadamente simples.
• Solana: monolítica, faz os quatro com requisitos de hardware elevados e um único conjunto de validadores.
• Aptos e Sui: monolíticas, com motores de execução paralela para aumentar o throughput.
• Ethereum: uma camada base que trata dos quatro, mais um ecossistema de rollups onde a execução é maioritariamente descarregada e o settlement e a disponibilidade de dados são alugados à camada base.
• Arbitrum, Optimism, Base: rollups que fazem a execução e algum settlement por si e publicam dados na Ethereum (ou, cada vez mais, numa camada de DA de terceiros como Celestia ou EigenDA).
• Celestia: especializa-se em consenso e disponibilidade de dados, com a execução feita por rollups separados por cima.
• EigenDA: apenas disponibilidade de dados, concebida para ser usada como módulo plug-in por outras cadeias.
• Cadeias NEAR e Cosmos (ATOM): situam-se a meio, com execução soberana que pode opcionalmente publicar dados numa camada de DA partilhada.

Não há uma posição "melhor" neste espetro. Depende do objetivo da cadeia. Uma cadeia otimizada para trading de alta frequência tenderá a ser monolítica para minimizar a latência. Uma cadeia otimizada para smart contracts genéricos baratos tenderá a ser modular para maximizar o throughput. Uma cadeia otimizada para uma aplicação específica pode ser um rollup sobre uma base partilhada. A resposta honesta é que este é um espaço de design e os bons engenheiros estão a escolher pontos dentro dele, não a declarar um vencedor.

Conclusões práticas para utilizadores e builders

Se é um utilizador a escolher onde colocar dinheiro ou aplicações, o enquadramento modular vs monolítico não deve ser o seu principal filtro. O que importa de facto é: quanto é que esta cadeia foi testada em produção, qual é o tamanho e descentralização do seu conjunto de validadores, como se comporta sob carga e qual é o seu historial de incidentes de segurança. Tanto a Ethereum como a Solana já tiveram incidentes de segurança de vários milhares de milhões de dólares na sua história, e ambas continuaram a crescer, pelo que o enquadramento de "mais seguro porque modular" ou "mais rápido porque monolítico" deve ser encarado com muita cautela.

Se é um builder, a decisão modular vs monolítico é um compromisso de engenharia real. Modular oferece um lançamento mais rápido, mais flexibilidade e menor custo inicial. Monolítico oferece menor latência, modelos mentais mais simples e menos pressupostos entre camadas. A evidência de 2024–2026 sugere que o custo da modularidade é, muitas vezes, superior ao que os diagramas sugerem, e que deve ser honesto consigo próprio sobre se a sua equipa consegue lidar com a complexidade operacional antes de se comprometer.

Como acompanhar o debate modular vs monolítico de forma inteligente

Os designs modulares e monolíticos estão a evoluir rapidamente, e o mesmo acontece com as notícias em torno deles. Acompanhar quais as cadeias que estão a ganhar utilizadores reais, quais os rollups que estão a migrar a sua disponibilidade de dados e quais os pressupostos de segurança que estão a ser testados em produção é uma batalha perdida se o fizer manualmente. O Zippfeed reúne manchetes de criptomoedas com classificação de sentimento (bullish, neutral ou bearish) e uma classificação de importância, para que possa ver o sinal através do ruído e acompanhar o debate modular vs monolítico com o contexto que ele realmente merece.