---
title: "Arquitetura modular de blockchain"
description: "Guia baseado em dependências para separar execução, sequenciamento, disponibilidade de dados, consenso, liquidação, provas, pontes, governança e arquivamento."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Arquitetura modular de blockchain

> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

<a id="answer"></a>

## Resposta direta

A arquitetura modular de blockchain é uma forma de analisar como um sistema distribui responsabilidades, não uma categoria padronizada de produto. Execução, ordenação de transações, compromissos de estado, provas ou disputas, publicação de dados e seu consenso, liquidação, pontes, governança e arquivamento de longo prazo podem ser combinados em um protocolo, divididos entre vários sistemas ou duplicados entre provedores. Uma camada pode cumprir várias funções, e uma função pode depender de várias camadas.

A pergunta útil não é se um projeto é “modular”, mas qual componente valida cada objeto, quem o controla, o que acontece quando ele para e como o usuário recupera de forma independente o estado ou os ativos. Um recibo do sequenciador não comprova disponibilidade de dados nem finalidade; uma prova de validade não fornece dados; um compromisso na cadeia de liquidação não demonstra recuperação permanente; e liquidação compartilhada não cria composabilidade síncrona entre rollups.

<a id="mechanism"></a>

## Como funciona

1. Identifique o sistema implantado: chain IDs de execução e liquidação, versão do protocolo, máquina virtual, contratos, endereços da ponte e dos ativos, modo de disponibilidade de dados, operadores, administradores e bloco ou horário observado. A taxonomia de marketing não substitui a configuração implantada.
2. Construa uma matriz de responsabilidades. Separe entrada e sequenciamento de transações, execução determinística, compromisso de estado e prova ou disputa de falha, publicação DA e seu consenso, aceitação e finalidade da liquidação, ponte e mensagens entre domínios, atualizações e pausas, e armazenamento histórico. Registre sobreposições sem forçar uma função a pertencer a uma única camada.
3. Rastreie uma transação e seu batch de ponta a ponta: entrada assinada, recibo local ou do sequenciador, execução ordenada, batch codificado e comprimido, publicação em calldata, blob ou DA externa, alegação de estado e prova ou disputa, finalidade da liquidação e, depois, execução da mensagem ou retirada. Preserve hashes, versões, recibos e relógios em cada fronteira.
4. Identifique cada objeto verificado e hipótese de confiança. Diferencie compromisso de dados de bytes, disponibilidade durante a janela do protocolo de recuperação posterior, validade da execução de finalidade do consenso e contabilidade da ponte de liquidez do ativo. Registre quem pode reproduzir, provar, contestar, censurar, atualizar, pausar ou reter cada objeto.
5. Reconstrua o livro de capacidade e custos. Meça bytes brutos e comprimidos, ocupação do batch, preço de DA, custos de prova e liquidação, comissões de execução e operação, gas da ponte e comissões de liquidez. A alocação média do batch não é o mesmo que a cobrança real do usuário ou o custo marginal de outra transação.
6. Teste falhas em vez de observar apenas o throughput normal. Interrompa sequenciador, publicador de batches, prover, challenger, serviço DA, RPC de liquidação e relayer da ponte; teste inclusão forçada, derivação independente, reconstrução de dados, prova ou contestação, nova tentativa, saída e recuperação de arquivo sob congestionamento e mudanças de versão.
7. Reconcilie com evidências canônicas. Associe recibos de execução e raízes de estado aos compromissos do batch, inclusão DA, estado da prova ou disputa, finalidade da liquidação, mensagens da ponte e saldos finais. Repita a revisão após reorganização, mudança de parâmetros, atualização de contrato ou migração de DA.

<a id="example"></a>

## Exemplos resolvidos

- **Custo e compressão de um batch.** Um batch contém `5,000` transações, `2,400 KB` de entradas brutas e `300 KB` após a compressão. A razão de compressão é `2,400 / 300 = 8.0x`, e os bytes caem `87.5%`. Se DA custa `0.020 ETH` e prova compartilhada mais liquidação custam `0.005 ETH`, o custo médio compartilhado é `(0.020 + 0.005) / 5,000 = 0.000005 ETH/tx`. Somar `0.000020 ETH/tx` de execução e operação resulta em `0.000025 ETH/tx`. Trata-se de alocação, não de cobrança garantida.
- **Limite do modelo de amostragem.** Em um modelo didático, um adversário retém `25%` dos fragmentos e um cliente faz `20` amostras uniformes independentes com reposição. A probabilidade de não detectar nenhum fragmento retido é `0.75^20 = 0.003171211939 = 0.3171211939%`; a probabilidade de detecção é `99.6828788061%`. Peers correlacionados, serviço adaptativo, codificação de apagamento e a regra real de amostragem podem invalidar esse modelo simples.
- **Segurança e disponibilidade de um comitê.** Um comitê DA `5-of-7` pode formar nova atestação de limiar com no máximo `2` membros indisponíveis; com `3` ausentes, restam apenas `4 < 5`. Sob uma regra didática baseada somente em assinaturas, controlar `5` signatários autorizados satisfaz o limiar. O certificado ainda não prova que existam cinco cópias duráveis, que o usuário consiga recuperar os bytes agora ou que execução e liquidação sejam válidas.
- **Vários relógios e uma saída rápida.** Uma soft confirmation didática chega em `2 seconds`, o batch é publicado após `8 minutes` e a finalidade da liquidação chega `13 minutes` depois: o tempo exato é `21 minutes 2 seconds`. Se uma retirada otimista acrescentar hipotéticos `7 days`, o total será `10,101 minutes 2 seconds`. Uma ponte rápida que cobra `0.15%` sobre `10,000 USDC` retém `15 USDC` e entrega `9,985 USDC`; a velocidade acrescenta hipóteses sobre ponte, provedor de liquidez e reorganização, em vez de encurtar o relógio do protocolo.

<a id="risks"></a>

## Riscos

- Identificação incorreta das responsabilidades ou fronteiras reais.
- Censura, reordenação ou indisponibilidade do sequenciador.
- Inclusão forçada indisponível, permissionada ou lenta demais.
- Indisponibilidade do publicador de batches ou proponente de estado.
- Falha do prover centralizado ou acúmulo de provas.
- Ausência de challenger ativo, habilitado ou financiado.
- Falha de relógio, bond, oracle ou verificador do fault game.
- Erro no circuito de validade, sistema de prova ou chave de verificação.
- Retenção de dados durante a janela de disponibilidade exigida.
- Amostragem correlacionada, ataque eclipse ou falha de visão da rede.
- Conluio de limiar ou comprometimento de chaves do comitê DA.
- Dados disponíveis ao protocolo sem arquivos independentes duráveis.
- Reorganização da liquidação ou classificação errada da finalidade.
- Falha da ponte, messenger, proteção contra replay ou execução de destino.
- Insolvência, falta de inventário ou preço adverso da ponte rápida.
- Comprometimento de administrador, multisig ou conselho de segurança.
- Atualização imediata, versão incompatível ou atraso de saída inadequado.
- Alta do custo DA, congestionamento de blobs, batches menores ou fim do subsídio.
- Incompatibilidade entre estado, dados, prova, contrato ou versão do cliente.
- Ordenação assíncrona entre domínios, conclusão parcial ou falha de composabilidade.

<a id="misconceptions"></a>

## Equívocos comuns

- A arquitetura modular é automaticamente mais descentralizada do que uma arquitetura monolítica.
- Uma prova de validade substitui disponibilidade e recuperação histórica de dados.
- Liquidar no Ethereum transfere todas as propriedades de segurança do Ethereum a cada componente.
- Uma mensagem de sucesso do sequenciador significa liquidação final e retirada executável.
- TPS maior, DA compartilhada ou liquidação compartilhada garantem custos menores e composabilidade síncrona.

<a id="related"></a>

## Tópicos relacionados

- [Camada 2](/pt-br/crypto/layer2/)
- [Disponibilidade de dados](/pt-br/crypto/data-availability/)
- [Rollups](/pt-br/crypto/rollup/)

<a id="sources"></a>

## Fontes

- [Scaling](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (acessado em: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (acessado em: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (acessado em: 2026-08-13)
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (acessado em: 2026-08-13)
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (acessado em: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (acessado em: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (acessado em: 2026-08-13)
- [LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts](https://arxiv.org/abs/1905.09274) - arXiv (acessado em: 2026-08-13)

Source: https://wiki.fcontext.com/pt-br/crypto/modular-blockchain/index.mdx