Ir para o conteúdo
Financial Context Wiki

Arquitetura modular de blockchain

Guia baseado em dependências para separar execução, sequenciamento, disponibilidade de dados, consenso, liquidação, provas, pontes, governança e arquivamento.

Atualizado

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

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.

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.

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.

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.

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.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...