Panorama do setor de computação paralela Web3: a melhor solução de escalonamento nativa?

I. Visão Geral do Contexto

O "triângulo impossível" da blockchain "segurança", "descentralização", "escalabilidade" revela os compromissos essenciais no design de sistemas de blockchain, ou seja, é difícil para os projetos de blockchain alcançarem simultaneamente "máxima segurança, participação universal, processamento rápido". Em relação ao tema eterno da "escalabilidade", as soluções de escalonamento de blockchain predominantes no mercado são classificadas segundo paradigmas, incluindo:

• Execução de escalabilidade aprimorada: aumentar a capacidade de execução no local, como paralelismo, GPU, multicore
• Isolamento de estado para escalabilidade: divisão horizontal de estado/Sharding, como fragmentação, UTXO, múltiplas sub-redes
• Escalabilidade do tipo off-chain: colocar a execução fora da cadeia, por exemplo, Rollup, Coprocessor, DA
• Escalabilidade de desconexão estrutural: modularização da arquitetura, operação colaborativa, como cadeias modulares, ordenadores compartilhados, Rollup Mesh
• Escalonamento assíncrono e concorrente: Modelo Actor, isolamento de processos, acionado por mensagens, como agentes, cadeia assíncrona multithread

As soluções de escalabilidade para blockchain incluem: computação paralela dentro da cadeia, Rollup, sharding, módulos DA, estrutura modular, sistema Actor, compressão de provas zk, arquitetura Stateless, entre outros, abrangendo múltiplos níveis de execução, estado, dados e estrutura, constituindo um sistema completo de escalabilidade "multicamadas e combinação modular". Este artigo foca principalmente na escalabilidade baseada em computação paralela.

Cálculo paralelo intra-cadeia (intra-chain parallelism), focando na execução paralela de transações/instruções dentro do bloco. De acordo com o mecanismo de paralelismo, suas formas de escalabilidade podem ser divididas em cinco grandes categorias, cada uma representando diferentes buscas por desempenho, modelos de desenvolvimento e filosofias de arquitetura, com a granularidade de paralelismo tornando-se cada vez mais fina, a intensidade paralela aumentando cada vez mais, a complexidade de agendamento também aumentando, e a complexidade de programação e a dificuldade de implementação crescendo cada vez mais.

• Nível de conta paralelo(Account-level): representa o projeto Solana
• Paralelismo a nível de objeto ( Nível de objeto ): representa o projeto Sui
• Nível de transação (Transaction-level): representa o projeto Monad, Aptos
• Chamada de nível / MicroVM paralelo ( Chamada de nível / MicroVM ): representa o projeto MegaETH
• Paralelismo em nível de instrução(Instruction-level): representa o projeto GatlingX

Modelo de concorrência assíncrona fora da cadeia, representado pelo sistema de agentes inteligentes (Agent / Actor Model), pertencente a uma outra paradigma de computação paralela, como um sistema de mensagens assíncronas/cross-chain (modelo não sincronizado em blockchain), cada Agente atua como um "processo inteligente independente", utilizando mensagens assíncronas em paralelo, acionado por eventos, sem necessidade de agendamento sincronizado, com projetos representativos como AO, ICP, Cartesi, etc.

Os conhecidos Rollup ou soluções de escalabilidade por fragmentação pertencem a mecanismos de concorrência a nível de sistema, não se enquadrando no cálculo paralelo dentro da cadeia. Eles realizam a escalabilidade através da "execução paralela de várias cadeias/domínios de execução", ao invés de aumentar a paralelidade dentro de um único bloco/máquina virtual. Esse tipo de solução de escalabilidade não é o foco desta discussão, mas ainda assim iremos utilizá-la para comparar as semelhanças e diferenças nos conceitos de arquitetura.

2. EVM Chain de Aumento Paralelo: Superando as Fronteiras de Desempenho na Compatibilidade

A arquitetura de processamento em série do Ethereum se desenvolveu até hoje, passando por várias tentativas de escalabilidade como sharding, Rollup e arquiteturas modularizadas, mas o gargalo de throughput na camada de execução ainda não foi fundamentalmente superado. No entanto, o EVM e o Solidity continuam sendo as plataformas de contratos inteligentes com a maior base de desenvolvedores e potencial ecológico atualmente. Assim, a cadeia paralela do EVM, que busca um equilíbrio entre compatibilidade ecológica e melhoria de desempenho de execução, está se tornando uma direção importante na evolução da nova rodada de escalabilidade. Monad e MegaETH são os projetos mais representativos nessa direção, construindo uma arquitetura de processamento paralelo EVM voltada para cenários de alta concorrência e alto throughput, a partir da execução com atraso e da decomposição de estado.

( Análise do mecanismo de computação paralela Monad

Monad é uma blockchain Layer1 de alto desempenho, redesenhada para a Máquina Virtual Ethereum )EVM###. Baseada no conceito fundamental de processamento em pipeline (Pipelining), executa de forma assíncrona na camada de consenso (Asynchronous Execution) e utiliza concorrência otimista na camada de execução (Optimistic Parallel Execution). Além disso, na camada de consenso e armazenamento, Monad introduz, respetivamente, um protocolo BFT de alto desempenho (MonadBFT) e um sistema de banco de dados dedicado (MonadDB), realizando otimização de ponta a ponta.

Pipelining: Mecanismo de execução paralela em múltiplas etapas

Pipelining é o conceito básico da execução paralela de Monads, cuja ideia central é dividir o fluxo de execução da blockchain em várias etapas independentes e processar essas etapas em paralelo, formando uma arquitetura de pipeline tridimensional, onde cada etapa opera em threads ou núcleos independentes, permitindo o processamento concorrente entre blocos, e assim alcançando o aumento da capacidade de processamento e a redução da latência. Essas etapas incluem: proposta de transação (Propose), consenso alcançado (Consensus), execução de transação (Execution) e compromisso de bloco (Commit).

Execução Assíncrona: Consenso - Execução Assíncrona Desacoplada

Na cadeia tradicional, o consenso e a execução de transações geralmente são processos síncronos, e esse modelo sequencial limita severamente a escalabilidade de desempenho. O Monad implementou a "execução assíncrona" para alcançar a assíncrona na camada de consenso, assíncrona na camada de execução e assíncrona no armazenamento. Isso reduz significativamente o tempo de bloco (block time) e a latência de confirmação, tornando o sistema mais resiliente, com processos mais segmentados e maior taxa de utilização de recursos.

Design central:

• O processo de consenso ( camada de consenso ) é responsável apenas pela ordenação das transações, não executa a lógica dos contratos.
• O processo de execução ( camada de execução ) é acionado de forma assíncrona após a conclusão do consenso.
• Após a conclusão do consenso, entra-se imediatamente no processo de consenso do próximo bloco, sem necessidade de aguardar a conclusão da execução.

Execução Paralela Otimista: Execução Paralela Otimista

O Ethereum tradicional utiliza um modelo de execução estritamente sequencial para evitar conflitos de estado. Em contraste, o Monad adota uma estratégia de "execução paralela otimista", aumentando significativamente a taxa de processamento das transações.

Mecanismo de execução:

• Monad irá executar otimisticamente todas as transações em paralelo, assumindo que a maioria das transações não tem conflitos de estado.
• Executar simultaneamente um "detector de conflitos (Conflict Detector)" para monitorar se as transações acessaram o mesmo estado (, como conflitos de leitura/gravação ).
• Se um conflito for detectado, as transações em conflito serão reexecutadas em série, garantindo a correção do estado.

Monad escolheu um caminho compatível: alterando o mínimo possível as regras da EVM, realizando a execução através do adiamento da escrita de estado e da detecção dinâmica de conflitos para alcançar a paralelização, mais parecido com uma versão de desempenho do Ethereum, com boa maturidade e fácil implementação da migração do ecossistema EVM, sendo um acelerador de paralelização no mundo da EVM.

( Análise do mecanismo de computação paralela do MegaETH

Diferente da localização L1 do Monad, o MegaETH é posicionado como uma camada de execução paralela de alto desempenho e modular compatível com EVM, podendo atuar tanto como uma blockchain pública L1 independente, quanto como uma camada de aumento de execução no Ethereum )Execution Layer### ou como um componente modular. O objetivo central do design é desmembrar a lógica de contas, o ambiente de execução e o estado em unidades mínimas que podem ser agendadas de forma independente, para alcançar uma execução de alta concorrência e baixa latência dentro da cadeia. A inovação chave proposta pelo MegaETH é a arquitetura Micro-VM + DAG de Dependência de Estado (grafo de dependência de estado acíclico orientado) e um mecanismo de sincronização modular, que constroem conjuntamente um sistema de execução paralela voltado para "threading dentro da cadeia".

Micro-VM( micro máquina virtual ) arquitetura: conta é um thread

O MegaETH introduziu o modelo de execução "uma Micro-VM por conta(Micro-VM)", tornando o ambiente de execução "multithreaded", proporcionando a menor unidade de isolamento para agendamento paralelo. Essas VMs comunicam-se entre si por meio de mensagens assíncronas(Asynchronous Messaging), em vez de chamadas síncronas, permitindo que muitas VMs sejam executadas de forma independente e armazenadas de forma independente, de forma naturalmente paralela.

Dependência de Estado DAG: Mecanismo de Agendamento Baseado em Gráficos de Dependência

MegaETH construiu um sistema de agendamento DAG baseado em relações de acesso ao estado da conta, que mantém em tempo real um gráfico de dependência global (Dependency Graph). Cada transação modela quais contas são modificadas e quais contas são lidas como relações de dependência. Transações sem conflito podem ser executadas em paralelo diretamente, enquanto transações com relações de dependência serão agendadas em ordem topológica ou adiadas. O gráfico de dependência garante a consistência de estado e a não duplicação de gravações durante o processo de execução paralela.

Execução assíncrona e mecanismo de callback

B

Em suma, o MegaETH rompe com o modelo tradicional de máquina de estado de thread única EVM, implementando o encapsulamento de micromáquinas virtuais por unidade de conta, realizando o agendamento de transações através de um gráfico de dependência de estado e substituindo a pilha de chamadas síncronas por um mecanismo de mensagens assíncronas. É uma plataforma de computação paralela redesenhada em todas as dimensões de "estrutura de conta → arquitetura de agendamento → fluxo de execução", oferecendo novas ideias em nível de paradigma para a construção do próximo sistema de alta performance em cadeia.

MegaETH escolheu um caminho de reestruturação: abstrair completamente contas e contratos em uma VM independente, liberando um potencial de paralelismo extremo através da programação de execução assíncrona. Em teoria, o limite de paralelismo do MegaETH é maior, mas também mais difícil de controlar em termos de complexidade, mais parecido com um sistema operacional distribuído super sob a filosofia do Ethereum.

A filosofia de design de Monad e MegaETH é bastante diferente da fragmentação (Sharding): a fragmentação divide a blockchain horizontalmente em várias sub-chains independentes (fragmentos Shards), cada uma responsável por parte das transações e estados, quebrando as limitações de uma única cadeia na expansão em nível de rede; enquanto Monad e MegaETH mantêm a integridade de uma única cadeia, apenas expandindo horizontalmente no nível de execução, otimizando a execução paralela extrema dentro da única cadeia para superar o desempenho. Ambos representam as duas direções de fortalecimento vertical e expansão horizontal no caminho de escalabilidade da blockchain.

Os projetos de computação paralela como Monad e MegaETH estão principalmente focados em otimização de throughput, com o objetivo central de aumentar o TPS na cadeia, realizando processamento paralelo em nível de transação ou de conta através da execução diferida (Deferred Execution) e da arquitetura de micro máquina virtual (Micro-VM). O Pharos Network, como uma rede de blockchain L1 modular e full-stack paralela, tem seu mecanismo central de computação paralela chamado "Rollup Mesh". Esta arquitetura suporta ambientes de múltiplas máquinas virtuais (EVM e Wasm) através do trabalho colaborativo entre a mainnet e as redes de processamento especial (SPNs), e integra tecnologias avançadas como provas de zero conhecimento (ZK) e ambientes de execução confiáveis (TEE).

Análise do mecanismo de computação paralela Rollup Mesh:

1. Processamento Assíncrono de Pipeline de Ciclo de Vida Completo (Full Lifecycle Asynchronous Pipelining): Pharos desacopla as várias fases da transação(, como consenso, execução e armazenamento), e adota um método de processamento assíncrono, permitindo que cada fase seja realizada de forma independente e em paralelo, aumentando assim a eficiência geral do processamento.
2. Execução Paralela de Dual VM (: Pharos suporta dois ambientes de máquina virtual, EVM e WASM, permitindo que os desenvolvedores escolham o ambiente de execução adequado conforme suas necessidades. Esta arquitetura de dupla VM não só aumenta a flexibilidade do sistema, mas também melhora a capacidade de processamento de transações através da execução paralela.
3. Tratamento especial da rede )SPNs(: SPNs são componentes chave na arquitetura Pharos, semelhantes a sub-redes modularizadas, dedicadas ao tratamento de tipos específicos de tarefas ou aplicações. Através dos SPNs, o Pharos pode realizar a alocação dinâmica de recursos e o processamento paralelo de tarefas, aumentando ainda mais a escalabilidade e o desempenho do sistema.
4. Consenso Modular e Mecanismo de Reestaca)Modular Consensus & Restaking(: Pharos introduziu um mecanismo de consenso flexível, suportando vários modelos de consenso) como PBFT, PoS, PoA(, e através do protocolo de reestaca)Restaking(, realiza o compartilhamento seguro e a integração de recursos entre a mainnet e os SPNs.