O "Trilema da Blockchain" revela os trade-offs essenciais no design de sistemas de blockchain, nomeadamente a dificuldade de alcançar "segurança máxima, participação universal e processamento de alta velocidade" simultaneamente. Relativamente ao eterno tema da "escalabilidade", as soluções de escalabilidade de blockchain mainstream atualmente no mercado podem ser categorizadas de acordo com paradigmas, incluindo:

• Executar escalabilidade aprimorada: Melhore as capacidades de execução no local, como paralelismo, GPU e multi-core.
• Expansão isolada de estado: particionamento horizontal do estado / Shard, como sharding, UTXO, multi-sub-rede
• Escalonamento de terceirização off-chain: execução fora da cadeia, como Rollup, Coprocessor, DA
• Expansão de estrutura desacoplada: arquitetura modular, operação colaborativa, como cadeias de módulos, classificadores compartilhados, Rollup Mesh.
• Escalonamento concorrente assíncrono: modelo de ator, isolamento de processos, orientado a mensagens, como agentes, cadeias assíncronas multithreaded.

As soluções de escalabilidade da blockchain incluem: computação paralela on-chain, Rollup, sharding, módulos DA, estruturas modulares, sistemas Actor, compressão zk-proof, arquitetura Stateless, etc., cobrindo múltiplas camadas de execução, estado, dados e estrutura, formando um sistema de escalabilidade completo de "colaboração em múltiplas camadas e combinação modular". Este artigo foca no método de escalabilidade mainstream baseado em computação paralela.

O paralelismo intra-cadeia foca na execução paralela de transações/instruções dentro do bloco. De acordo com o mecanismo paralelo, seus métodos de escalonamento podem ser divididos em cinco categorias, cada uma representando diferentes buscas de desempenho, modelos de desenvolvimento e filosofias arquitetônicas. A granularidade do paralelismo torna-se mais fina, a intensidade do paralelismo aumenta, a complexidade do agendamento sobe e a complexidade da programação e a dificuldade de implementação também aumentam.

• Nível de conta: Representa o projeto Solana
• Paralelismo a nível de objeto: representa o projeto Sui
• Nível de transação: Representa os projetos Monad, Aptos
• Nível de chamada / MicroVM: Representa o projeto MegaETH
• Paralelismo a nível de instrução: Representa o projeto GatlingX

O modelo concorrente assíncrono off-chain, representado pelo sistema Actor (Modelo de Agente / Actor), pertence a outro paradigma de computação paralela. Como um sistema de mensagens cross-chain / assíncrono (modelo de não-bloqueio), cada Agente opera como um "processo agente" que funciona de forma independente, enviando mensagens de maneira assíncrona, orientada a eventos e sem a necessidade de agendamento sincronizado. Projetos notáveis incluem AO, ICP, Cartesi, etc.

As soluções de escalabilidade bem conhecidas, como Rollup ou sharding, pertencem a mecanismos de concorrência a nível de sistema e não se enquadram na computação paralela em cadeia. Elas alcançam escalabilidade ao "executar múltiplas cadeias/domínios de execução em paralelo" em vez de aumentar o paralelismo dentro de um único bloco/máquina virtual. Essas soluções de escalabilidade não são o foco deste artigo, mas ainda assim as utilizaremos para uma análise comparativa de conceitos arquitetónicos.

2. Cadeia Paralela Aprimorada Baseada em EVM: Quebrando Limites de Desempenho Através da Compatibilidade

A arquitetura de processamento em série do Ethereum desenvolveu-se através de várias tentativas de expansão, incluindo sharding, Rollup e arquitetura modular. No entanto, o gargalo de throughput da camada de execução ainda não foi fundamentalmente superado. Enquanto isso, EVM e Solidity continuam a ser as plataformas de contratos inteligentes mais amigáveis para desenvolvedores e ecologicamente potentes hoje. Portanto, as cadeias aprimoradas em paralelo baseadas em EVM estão se tornando uma direção importante para a próxima rodada de evolução em escalabilidade, equilibrando compatibilidade ecológica e melhoria no desempenho de execução. Monad e MegaETH são os projetos mais representativos nessa direção, construindo, respectivamente, arquiteturas de processamento paralelo EVM voltadas para cenários de alta concorrência e alto throughput, começando pela execução atrasada e decomposição de estado.

Análise do Mecanismo de Computação Paralela da Monad

Monad é uma blockchain de Layer 1 de alto desempenho redesenhada para a Ethereum Virtual Machine (EVM), baseada no conceito fundamental de paralelismo de pipelining, apresentando execução assíncrona na camada de consenso e execução paralela otimista na camada de execução. Além disso, Monad introduz um protocolo BFT de alto desempenho (MonadBFT) e um sistema de banco de dados dedicado (MonadDB) nas camadas de consenso e armazenamento, alcançando otimização de ponta a ponta.

Pipelining: Mecanismo de execução paralela de pipeline em múltiplas etapas
A canalização é o conceito fundamental da execução paralela de Monad. A sua ideia central é dividir o processo de execução da blockchain em múltiplas etapas independentes e processar essas etapas em paralelo, formando uma arquitetura de pipeline tridimensional. Cada etapa é executada em threads ou núcleos independentes, alcançando um processamento concorrente entre blocos, melhorando, em última análise, a taxa de transferência e reduzindo a latência. Estas etapas incluem: proposta de transação (Propose), alcance de consenso (Consensus), execução de transação (Execution) e compromisso de bloco (Commit).

Execução assíncrona: consenso - desacoplamento assíncrono
Em blockchains tradicionais, o consenso de transações e a execução são tipicamente processos síncronos, e este modelo serial limita severamente a escalabilidade de desempenho. Monad alcança uma camada de consenso assíncrona, uma camada de execução assíncrona e um armazenamento assíncrono através da "execução assíncrona". Isso reduz significativamente o tempo de bloco e os atrasos de confirmação, tornando o sistema mais resiliente, os fluxos de processamento mais granulares e a utilização de recursos mais alta.

Design Central:

• O processo de consenso (camada de consenso) é apenas responsável por ordenar as transações e não executa a lógica do contrato.
• 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, entre imediatamente no processo de consenso para o próximo bloco sem esperar que a execução termine.

Execução Paralela Otimista
O Ethereum tradicional utiliza um modelo serial rigoroso para a execução de transações a fim de evitar conflitos de estado. Em contraste, o Monad emprega uma estratégia de "execução paralela otimista", melhorando significativamente a velocidade de processamento de 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.
• Ao mesmo tempo, execute um "Detetor de Conflitos" para monitorizar se as transações estão a aceder ao mesmo estado (como conflitos de leitura/escrita).
• Se um conflito for detectado, as transações conflitantes serão serializadas e reexecutadas para garantir a correção do estado.

Monad escolhe um caminho compatível: fazendo o mínimo de alterações possível nas regras do EVM, alcançando paralelismo ao adiar gravações de estado e detectar dinamicamente conflitos durante a execução, assemelhando-se a uma versão de desempenho do Ethereum. Sua maturidade facilita a migração fácil do ecossistema EVM e serve como um acelerador paralelo no mundo EVM.

Análise do Mecanismo de Computação Paralela do MegaETH

Ao contrário do posicionamento L1 da Monad, o MegaETH é posicionado como uma camada de execução paralela modular de alto desempenho compatível com EVM, que pode servir como uma cadeia pública L1 independente ou como uma camada de aprimoramento de execução no Ethereum ou como um componente modular. Seu objetivo de design central é isolar e deconstruir a lógica de contas, o ambiente de execução e o estado em unidades mínimas programáveis de forma independente para alcançar alta execução concorrente e capacidades de resposta de baixa latência na cadeia. As principais inovações propostas pelo MegaETH são: arquitetura Micro-VM + DAG de Dependências de Estado (Grafo Acíclico Dirigido de Dependências de Estado) e mecanismo de sincronização modular, que juntos constroem um sistema de execução paralela orientado para "threading on-chain."

Arquitetura Micro-VM: A conta é um thread
MegaETH introduz o modelo de execução de "uma micro máquina virtual (Micro-VM) por conta", que transforma o ambiente de execução em threads e fornece a menor unidade de isolamento para agendamento paralelo. Estas VMs comunicam-se através de mensagens assíncronas em vez de chamadas síncronas, permitindo que um grande número de VMs execute de forma independente e armazene de forma independente, permitindo um paralelismo natural.

DAG de Dependência de Estado: Um mecanismo de agendamento impulsionado por gráficos de dependência
MegaETH construiu um sistema de agendamento DAG baseado em relações de acesso ao estado da conta. O sistema mantém um Grafo de Dependência global em tempo real, modelando quais contas são modificadas e quais contas são lidas durante cada transação como dependências. Transações não conflitantes podem ser executadas em paralelo, enquanto transações com dependências serão agendadas em ordem ou adiadas de acordo com uma sequência topológica. O grafo de dependência garante a consistência do estado e a escrita não repetitiva durante o processo de execução paralela.

Execução Assíncrona e Mecanismo de Callback
MegaETH é construído sobre o paradigma de programação assíncrona, semelhante à passagem de mensagens assíncronas do Modelo Ator, abordando os problemas das chamadas seriais tradicionais do EVM. As chamadas de contrato são assíncronas (execução não recursiva), e ao chamar o contrato A -> B -> C, cada chamada é feita assíncronamente sem bloqueios; a pilha de chamadas é expandida em um gráfico de chamadas assíncronas (Call Graph); o processamento de transações = percorrendo o gráfico assíncrono + resolução de dependências + agendamento paralelo.

Em resumo, o MegaETH quebra o modelo tradicional de máquina de estado de thread única da EVM ao implementar encapsulamento de micro máquinas virtuais com base em contas, agendando transações através de um gráfico de dependência de estado e usando um mecanismo de mensagens assíncronas em vez de uma pilha de chamadas síncronas. É uma plataforma de computação paralela que foi redesenhada em todas as dimensões, desde "estrutura de conta → arquitetura de agendamento → fluxo de execução", proporcionando uma nova abordagem em nível de paradigma para construir a próxima geração de sistemas on-chain de alto desempenho.

MegaETH escolheu um caminho de reconstrução: abstraindo completamente contas e contratos em uma VM independente, e liberando um potencial extremo de paralelismo através de agendamento de execução assíncrono. Teoricamente, o limite paralelo do MegaETH é mais alto, mas também é mais difícil de controlar a complexidade, assemelhando-se a um sistema operacional super distribuído sob o conceito de Ethereum.

Os conceitos de design do Monad e do MegaETH são bastante diferentes do sharding: o sharding divide horizontalmente a blockchain em múltiplas sub-chains independentes (shards), com cada sub-chain responsável por uma parte das transações e estados, quebrando as limitações de uma única chain para alcançar escalabilidade na camada de rede; enquanto o Monad e o MegaETH mantêm a integridade de uma única chain e apenas alcançam escalabilidade horizontal na camada de execução, otimizando o desempenho através da execução paralela extrema dentro da única chain. Os dois representam duas direções no caminho da escalabilidade da blockchain: aprimoramento vertical e expansão horizontal.

Projetos como Monad e MegaETH concentram-se em caminhos de otimização de throughput, com o objetivo central de aumentar o TPS on-chain. Eles alcançam processamento paralelo em nível de transação ou conta através de Execução Diferida e arquiteturas de Micro-VM. A Pharos Network, como uma rede blockchain modular e de pilha completa L1 paralela, possui um mecanismo central de computação paralela conhecido como "Rollup Mesh." Esta arquitetura suporta ambientes multi-máquina virtual (EVM e Wasm) através do trabalho colaborativo da mainnet e das Redes de Processamento Especial (SPNs), integrando tecnologias avançadas como Provas de Conhecimento Zero (ZK) e Ambientes de Execução Confiável (TEE).

Análise do Mecanismo de Computação Paralela em Malha Rollup:

• Ciclo de Vida Completo de Pipelining Assíncrono: Pharos desacopla as várias etapas de uma transação (como consenso, execução, armazenamento) e adota uma abordagem de processamento assíncrono, permitindo que cada etapa prossiga de forma independente e em paralelo, melhorando assim a eficiência geral do processamento.
• Execução Paralela em Dual VM: Pharos suporta dois ambientes de máquina virtual, EVM e WASM, permitindo que os desenvolvedores escolham o ambiente de execução apropriado com base nas suas necessidades. Esta arquitetura de dual VM não só aumenta a flexibilidade do sistema, mas também melhora as capacidades de processamento de transações através da execução paralela.
• Redes de Processamento Especiais (SPNs): As SPNs são componentes chave na arquitetura Pharos, semelhantes a sub-redes modulares, projetadas especificamente para lidar com tipos específicos de tarefas ou aplicações. Através das SPNs, o Pharos pode alcançar alocação dinâmica de recursos e processamento paralelo de tarefas, melhorando ainda mais a escalabilidade e o desempenho do sistema.
• Consenso Modular e Restaking: Pharos introduz um mecanismo de consenso flexível que suporta múltiplos modelos de consenso (como PBFT, PoS, PoA) e alcança compartilhamento seguro e integração de recursos entre a mainnet e os SPNs através do protocolo de Restaking.

Além disso, o Pharos reestruturou o modelo de execução do mecanismo de armazenamento subjacente utilizando árvores de Merkle de múltiplas versões, Codificação Delta, Endereçamento Versionado e tecnologias de ADS Pushdown, lançando o mecanismo de armazenamento de alto desempenho nativo da blockchain, Pharos Store, alcançando alta capacidade de processamento, baixa latência e fortes capacidades de processamento em cadeia verificáveis.

No geral, a arquitetura Rollup Mesh da Pharos alcança altas capacidades de computação paralela de alto desempenho através de um design modular e um mecanismo de processamento assíncrono. A Pharos atua como um coordenador de agendamento para a paralelismo entre Rollups, não como um otimizador de execução para "paralelismo em cadeia", mas sim assume tarefas de execução personalizadas heterogêneas através de SPNs.

Além da arquitetura de execução paralela do Monad, MegaETH e Pharos, também observamos que existem alguns projetos no mercado explorando os caminhos de aplicação da aceleração por GPU na computação paralela EVM, que servem como um importante complemento e experimento de ponta para o ecossistema paralelo EVM. Entre eles, Reddio e GatlingX são duas direções representativas:

• Reddio é uma plataforma de alto desempenho que combina zkRollup e arquitetura de execução paralela em GPU. Seu núcleo reside na reconstrução do processo de execução da EVM, alcançando paralelização nativa na camada de execução por meio do agendamento de múltiplas threads, armazenamento de estado assíncrono e execução acelerada por GPU de lotes de transações. Pertence à granularidade paralela de nível de transação + nível de operação (execução de múltiplas threads de opcodes). Seu design introduz execução em lote com múltiplas threads, carregamento de estado assíncrono e processamento paralelo em GPU da lógica de transações (EVM Paralela Compatível com CUDA). Assim como Monad / MegaETH, Reddio também se concentra no processamento paralelo na camada de execução, com a diferença de que a reconstrução do motor de execução é feita através de uma arquitetura paralela em GPU, especificamente projetada para cenários de alta taxa de transferência e computação intensiva (como inferência de IA). O SDK foi lançado, fornecendo um módulo de execução integrável.
• GatlingX afirma ser um "GPU-EVM" e propõe uma arquitetura mais radical que tenta migrar o modelo de "execução serial em nível de instrução" da máquina virtual EVM tradicional para um ambiente de execução paralelo nativo de GPU. Seu mecanismo central envolve a compilação dinâmica de bytecode EVM em tarefas paralelas CUDA, executando fluxos de instruções através de múltiplos núcleos de GPU, quebrando assim o gargalo sequencial da EVM no nível mais baixo. Pertence à granularidade paralela em nível de instrução (Instruction-Level Parallelism, ILP). Comparado à granularidade paralela "em nível de transação/em nível de conta" do Monad / MegaETH, o mecanismo paralelo do GatlingX está mais próximo de caminhos de otimização em nível de instrução, mais semelhante à reconstrução subjacente do motor da máquina virtual. Atualmente, está em estágio conceitual, com um white paper e esboços arquitetônicos lançados, mas sem SDK ou mainnet ainda.

A Artela propõe um conceito de design paralelo diferenciado. Ao introduzir a arquitetura EVM++ com uma máquina virtual WebAssembly (WASM), permite que os desenvolvedores adicionem e executem dinamicamente extensões na cadeia, mantendo a compatibilidade com EVM, utilizando o modelo de programação Aspect. Considera a granularidade das chamadas de contrato (Função / Extensão) como a unidade paralela mínima, suportando a injeção de módulos de Extensão (semelhantes a "middleware plugável") durante a execução de contratos EVM, alcançando desacoplamento lógico, chamadas assíncronas e execução paralela em nível de módulo. Foca mais na composabilidade e na arquitetura modular da camada de execução. Este conceito oferece novas ideias para futuras aplicações complexas de múltiplos módulos.

3. Cadeia de Arquitetura Paralela Nativa: Reestruturando a Entidade de Execução da VM

O modelo de execução EVM do Ethereum adotou uma arquitetura de "ordenação total de transações + execução serial" de thread única desde seu design, visando garantir a determinismo e consistência das mudanças de estado em todos os nós da rede. No entanto, essa arquitetura possui gargalos de desempenho inerentes que limitam a taxa de transferência e a escalabilidade do sistema. Em contraste, cadeias de arquitetura de computação paralela nativa, como Solana (SVM), MoveVM (Sui, Aptos) e Sei v2 construídas sobre o Cosmos SDK, são projetadas para execução paralela desde o início, oferecendo as seguintes vantagens:

• O modelo de estado separa naturalmente: Solana adota um mecanismo de declaração de bloqueio de conta, MoveVM introduz um modelo de propriedade de objeto, e Sei v2 classifica com base nos tipos de transação para alcançar a determinação de conflitos estáticos, suportando agendamento concorrente a nível de transação.
• Otimização da concorrência de máquinas virtuais: o motor Sealevel da Solana suporta nativamente a execução multithread; o MoveVM pode realizar análise de grafo de concorrência estática; o Sei v2 integra um motor de correspondência multithread e um módulo VM paralelo.

Claro, este tipo de cadeia paralela nativa também enfrenta desafios de compatibilidade ecológica. As arquiteturas não-EVM muitas vezes exigem linguagens de desenvolvimento (como Move, Rust) e ferramentas completamente novas, o que representa um certo custo de migração para os desenvolvedores; além disso, os desenvolvedores também devem dominar uma série de novos conceitos, como modelos de acesso ao estado, limites de concorrência e ciclos de vida de objetos, todos os quais elevam o limiar de compreensão e impõem demandas mais altas sobre os paradigmas de desenvolvimento.

3.1 O Princípio do Solana e o Motor Paralelo Sealevel do SVM

O modelo de execução Sealevel da Solana é um mecanismo de agendamento paralelo baseado em contas, que é o motor central usado pela Solana para alcançar a execução de transações paralelas em cadeia. Através do mecanismo "declaração de conta + agendamento estático + execução multithread", ele realiza alta concorrência de desempenho no nível do contrato inteligente. Sealevel é o primeiro modelo de execução no campo da blockchain a implementar com sucesso o agendamento concorrente em cadeia em um ambiente de produção, e suas ideias arquitetônicas influenciaram muitos projetos subsequentes de computação paralela, servindo como um paradigma de referência para o design paralelo de alto desempenho em Layer 1.

Mecanismo Central:

1. Declaração Explícita de Acesso à Conta (Listas de Acesso à Conta): Cada transação deve declarar as contas envolvidas (leitura/escrita) no momento da submissão, permitindo que o sistema determine se existem conflitos de estado entre as transações.

2. Detecção de Conflitos e Agendamento de Multithreading

• Se o conjunto de contas acedido pelas duas transações não tiver interseção → podem ser executadas em paralelo;
• O conflito existe → Executar em série na ordem de dependência;
• O agendador aloca transações a diferentes threads com base no grafo de dependência.

3. Contexto de Execução Independente (Contexto de Invocação de Programas): Cada chamada de contrato opera em um contexto isolado, sem pilha compartilhada, prevenindo interferência entre chamadas.

Sealevel é o motor de agendamento de execução paralela da Solana, enquanto SVM é o ambiente de execução de contratos inteligentes construído sobre Sealevel (usando a máquina virtual BPF). Juntos, eles formam a base técnica do sistema de execução paralela de alto desempenho da Solana.

Eclipse é um projeto que implementa a VM Solana em cadeias modulares (como Ethereum L2 ou Celestia), utilizando o motor de execução paralelo da Solana como a camada de execução Rollup. Eclipse é um dos primeiros projetos a propor a separação da camada de execução da Solana (Sealevel + SVM) da mainnet da Solana e a migração para uma arquitetura modular, modularizando o "modelo de execução concorrente super forte" da Solana como Camada de Execução como Serviço. Portanto, Eclipse também se enquadra na categoria de computação paralela.

A abordagem da Neon é diferente; ela introduz a EVM para operar no ambiente SVM / Sealevel. Cria uma camada de runtime compatível com a EVM, permitindo que os desenvolvedores utilizem Solidity para desenvolver contratos que operem no ambiente SVM, mas a execução programada utiliza SVM + Sealevel. A Neon está mais inclinada para a categoria de Blockchain Modular em vez de enfatizar inovações em computação paralela.

Em resumo, Solana e SVM dependem do motor de execução Sealevel, e a filosofia de agendamento do sistema operativo Solana é semelhante à de um agendador de kernel, executando rapidamente, mas com relativamente baixa flexibilidade. É uma cadeia pública nativa de alto desempenho e computação paralela.

3.2 Arquitetura MoveVM: Orientada a Recursos e Objetos

MoveVM é uma máquina virtual de contratos inteligentes projetada para a segurança dos recursos on-chain e execução paralela. Sua linguagem central, Move, foi originalmente desenvolvida pela Meta (anteriormente Facebook) para o projeto Libra, enfatizando o conceito de “recurso como um objeto”. Todos os estados on-chain existem como objetos com propriedade e ciclo de vida claros. Isso permite que o MoveVM analise se há conflitos de estado entre transações em tempo de compilação, possibilitando o agendamento paralelo estático em nível de objeto, e é amplamente utilizado em blockchains públicas nativas paralelas como Sui e Aptos.

O modelo de propriedade de objetos da Sui
A capacidade de computação paralela do Sui decorre da sua abordagem única de modelagem de estado e do mecanismo de análise estática a nível de linguagem. Ao contrário das blockchains tradicionais que utilizam uma árvore de estado global, o Sui construiu um conjunto de modelos de estado centrados em objetos, combinados com o sistema de tipos linear do MoveVM, permitindo que o agendamento paralelo seja um processo determinístico que pode ser concluído em tempo de compilação.

• O Modelo de Objeto é a base da arquitetura paralela do Sui. O Sui abstrai todos os estados on-chain em objetos independentes, cada um com um ID único, um proprietário claro (conta ou contrato) e definições de tipo. Estes objetos não compartilham estados entre si, proporcionando isolamento natural. Os contratos devem declarar explicitamente o conjunto de objetos envolvidos quando invocados, evitando os problemas de acoplamento de estado da tradicional "árvore de estado global" on-chain. Este design decompõe os estados on-chain em várias unidades independentes, tornando a execução concorrente uma premissa de agendamento estruturalmente viável.
• A Análise de Propriedade Estática é um mecanismo de análise em tempo de compilação implementado com o suporte do sistema de tipos linear da linguagem Move. Ela permite que o sistema infira quais transações não causarão conflitos de estado através da propriedade de objetos antes que as transações sejam executadas, organizando-as para execução paralela. Comparado à detecção de conflitos em tempo de execução e reversão tradicionais, o mecanismo de análise estática do Sui melhora significativamente a eficiência de execução enquanto reduz consideravelmente a complexidade de agendamento, o que é fundamental para alcançar alta taxa de transferência e capacidades de processamento paralelo determinístico.

Sui divide o espaço de estado com base em objetos e combina a análise de propriedade em tempo de compilação para alcançar uma execução paralela a nível de objeto, de baixo custo e sem retrocessos. Comparado à execução serial ou verificações em tempo de execução de cadeias tradicionais, Sui alcançou melhorias significativas na eficiência de execução, determinismo do sistema e utilização de recursos.

O mecanismo de execução Block-STM da Aptos
Aptos é uma blockchain de alto desempenho de Camada 1 baseada na linguagem Move, cuja capacidade de execução paralela vem principalmente do framework auto-desenvolvido Block-STM (Memória Transacional de Software em Nível de Bloco). Ao contrário do Sui, que tende a adotar uma estratégia de "paralelismo estático em tempo de compilação", o Block-STM pertence a um mecanismo de agendamento dinâmico de "concorrência otimista em tempo de execução + retrocesso de conflito", adequado para lidar com conjuntos de transações com dependências complexas.

O Block-STM divide a execução das transações de um bloco em três fases:

• Execução Especulativa: Todas as transações são assumidas como livres de conflitos antes da execução, e o sistema programa transações para múltiplas threads para execução concorrente, gravando os estados das contas que acessam (conjunto de leitura / conjunto de escrita).
• Fase de Detecção de Conflitos e Validação: O sistema verifica os resultados da execução: se duas transações tiverem um conflito de leitura-escrita (por exemplo, Tx1 lê o estado escrito por Tx2), uma delas será revertida.
• Retrocesso de Transação em Conflito (Fase de Tentativa): As transações em conflito serão reprogramadas para execução até que suas dependências sejam resolvidas, formando, em última análise, uma sequência de compromisso de estado válida e determinística para todas as transações.

Block-STM é um modelo de execução dinâmica que emprega "paralelismo otimista + tentativa de retrocesso", adequado para cenários de processamento em lote de transações on-chain que são intensivos em estado e logicamente complexos. É o núcleo da computação paralela para Aptos construir uma cadeia pública altamente versátil e de alto desempenho.

Solana é a facção de agendamento de engenharia, mais parecida com um "kernel de sistema operacional". É adequada para limites de estado claros e negociação de alta frequência controlável, incorporando um estilo de engenheiro de hardware, e foi projetada para executar a cadeia como hardware (Execução paralela de grau de hardware). Aptos é a facção de tolerância a falhas do sistema, mais parecida com um "motor de concorrência de banco de dados". É adequada para contratos com forte acoplamento de estado e cadeias de chamadas complexas. Sui é a facção de segurança em tempo de compilação, mais parecida com uma "plataforma de linguagem inteligente orientada a recursos". É adequada para aplicações em cadeia com separação de ativos e combinações claras. Aptos e Sui destinam-se a operar a cadeia como engenheiros de linguagens de programação, garantindo a segurança de recursos de grau de software. Os três representam diferentes caminhos filosóficos para a implementação técnica da computação paralela na Web3.

3.3 Tipo de Escala Paralela do Cosmos SDK

Sei V2 é uma cadeia pública de trading de alto desempenho construída sobre o Cosmos SDK. Suas capacidades paralelas estão refletidas principalmente em dois aspectos: o motor de correspondência multithread e a otimização de execução paralela na camada da máquina virtual, com o objetivo de atender a cenários de trading on-chain de alta frequência e baixa latência, como DEXs de livro de ordens e infraestrutura de troca on-chain.

Mecanismo Paralelo Central:

• Motor de Correspondência Paralelo: O Sei V2 introduz um caminho de execução multi-threaded na lógica de correspondência de ordens, separando o livro de ordens da lógica de correspondência ao nível de thread, permitindo que as tarefas de correspondência entre múltiplos mercados (pares de negociação) sejam processadas em paralelo, evitando assim gargalos de thread única.
• Otimização de Concurrency a Nível de Máquina Virtual: O Sei V2 construiu um ambiente de runtime CosmWasm com capacidades de execução concorrente, permitindo que certas chamadas de contrato sejam executadas em paralelo sob a condição de que seus estados não entrem em conflito, alcançando um controle de maior throughput em conjunto com um mecanismo de classificação de tipos de transação.
• Consenso paralelo combinado com agendamento da camada de execução: Apresentando o chamado mecanismo de consenso "Twin-Turbo" para fortalecer a desacoplagem de throughput entre a camada de consenso e a camada de execução, melhorando a eficiência geral do processamento de blocos.

3.4 Recondicionador do Modelo UTXO

Fuel é uma camada de execução de alto desempenho projetada com base na arquitetura modular do Ethereum, com seu mecanismo paralelo central derivado de um modelo UTXO melhorado (Unspent Transaction Output). Ao contrário do modelo de conta do Ethereum, o Fuel utiliza uma estrutura UTXO para representar ativos e estados, que possui isolamento de estado, tornando mais fácil determinar quais transações podem ser executadas em paralelo de forma segura. Além disso, o Fuel introduz uma linguagem de contrato inteligente autodesenvolvida chamada Sway (semelhante ao Rust), e a combina com ferramentas de análise estática para identificar conflitos de entrada antes da execução da transação, alcançando assim um agendamento paralelo de transações eficiente e seguro. Serve como uma camada de execução alternativa ao EVM que equilibra desempenho e modularidade.

4. Modelo de Actor: Um Novo Paradigma para Execução Concorrente de Agentes

O Modelo de Ator é um paradigma de execução paralela que utiliza processos de agente (Agente ou Processo) como unidades, diferindo da computação síncrona tradicional com um estado global em cadeia (cenários como "computação paralela em cadeia" como Solana/Sui/Monad), já que enfatiza que cada agente tem seu próprio estado e comportamento independentes, comunicando e agendando através de mensagens assíncronas. Sob essa arquitetura, sistemas em cadeia podem executar simultaneamente um grande número de processos desacoplados, proporcionando forte escalabilidade e tolerância a falhas assíncronas. Projetos representativos incluem AO (Arweave AO), ICP (Internet Computer) e Cartesi, que estão impulsionando a evolução da blockchain de um motor de execução para um "sistema operacional em cadeia", fornecendo infraestrutura nativa para Agentes de IA, interações multitarefa e orquestração de lógica complexa.

Embora o design do Modelo de Ator tenha certas semelhanças superficiais com Sharding (como concorrência, isolamento de estado e processamento assíncrono), eles representam, essencialmente, caminhos técnicos e filosofias de sistema completamente diferentes. O Modelo de Ator enfatiza a "computação assíncrona multiprocessual", onde cada agente (Ator) opera de forma independente e mantém seu próprio estado, interagindo por meio de uma abordagem orientada a mensagens; enquanto Sharding é um mecanismo para "particionamento horizontal de estado e consenso", dividindo toda a blockchain em múltiplos subsistemas independentes (Shards) que processam transações. O Modelo de Ator é mais como um "sistema operacional de agentes distribuídos" no mundo Web3, enquanto Sharding é uma solução de escalabilidade estrutural para as capacidades de processamento de transações on-chain. Ambos alcançam concorrência, mas seus pontos de partida, objetivos e arquiteturas de execução são diferentes.

4.1 AO (Arweave), um supercomputador paralelo acima da camada de armazenamento

AO é uma plataforma de computação descentralizada que opera na camada de armazenamento permanente Arweave, com o objetivo principal de construir um sistema operativo em cadeia que suporte a operação de agentes assíncronos em grande escala.

Características principais da arquitetura:

• Arquitetura de processos: Cada agente é referido como um Processo, possuindo estado independente, escalonador independente e lógica de execução.
• Sem estrutura de blockchain: AO não é uma cadeia, mas sim uma camada de armazenamento descentralizada baseada em Arweave + um motor de execução orientado a mensagens multi-agente;
• Sistema de Agendamento de Mensagens Assíncronas: Os processos comunicam-se através de mensagens, adotando um modelo operacional assíncrono sem bloqueios, que suporta intrinsecamente a escalabilidade concorrente;
• Armazenamento permanente de estado: Todos os estados dos agentes, registros de mensagens e instruções são gravados permanentemente na Arweave, garantindo total auditabilidade e transparência descentralizada.
• Agente-nativo: Adequado para implantar tarefas complexas em múltiplas etapas (como agentes de IA, controladores de protocolo DePIN, orquestradores de tarefas automatizadas, etc.), pode construir um "Coprocessador de IA em cadeia."

AO segue uma abordagem extrema de "corpo inteligente nativo + armazenamento orientado + arquitetura sem cadeia", enfatizando a flexibilidade e o desacoplamento modular. É uma "estrutura de microkernel construída sobre a camada de armazenamento", com limites de sistema intencionalmente reduzidos, enfatizando computação leve + estruturas de controle compostas.

4.2 ICP (Internet Computer), uma plataforma de alojamento Web3 de pilha completa

ICP é uma plataforma de aplicação on-chain de pilha completa nativa da Web3 lançada pela DFINITY, com o objetivo de estender as capacidades de computação on-chain para uma experiência semelhante à Web2, e suporta hospedagem de serviços completa, vinculação de domínios e uma arquitetura sem servidor.

Características principais da arquitetura:

• Arquitetura de canisters (containers como agentes inteligentes): Cada Canister é um agente inteligente que opera na VM Wasm, possuindo estado independente, código e capacidades de agendamento assíncrono;
• Sistema de Consenso Distribuído de Sub-rede: A rede inteira é composta por múltiplas Sub-redes, cada uma das quais mantém um grupo de Canisters e alcança consenso através do mecanismo de assinatura BLS.
• Modelo de chamada assíncrona: Os canisters comunicam-se entre si através de mensagens assíncronas, suportando execução não bloqueante e apresentando paralelismo inerente;
• Hospedagem Web On-chain: Suporta contratos inteligentes para hospedar diretamente páginas front-end, com mapeamento DNS nativo, tornando-se a primeira plataforma blockchain a suportar acesso direto a dApps através do navegador.
• Funções abrangentes do sistema: Equipado com atualizações quentes em cadeia, autenticação de identidade, aleatoriedade distribuída, temporizadores e outras APIs do sistema, adequado para implantação de serviços on-chain complexos.

ICP seleciona uma plataforma pesada, encapsulação integrada e um paradigma de sistema operacional de controle de plataforma forte, apresentando um "Sistema Operacional de Blockchain" com consenso, execução, armazenamento e acesso integrados. Enfatiza capacidades completas de hospedagem de serviços, e a fronteira do sistema se expande para uma plataforma de hospedagem Web3 de pilha completa.

Além disso, outros projetos de computação paralela baseados no paradigma do Modelo de Actor podem consultar a tabela abaixo:

V. Resumo e Perspectivas

Com base nas diferenças na arquitetura de máquinas virtuais e nos sistemas de linguagem, as soluções de computação paralela em blockchain podem ser divididas em duas categorias: cadeias de melhoria paralela baseadas em EVM e cadeias de arquitetura paralela nativa (não EVM).

O anterior alcança maior capacidade de processamento e capacidade de processamento paralelo através da otimização profunda da camada de execução, mantendo a compatibilidade com o ecossistema EVM/Solidity. É adequado para cenários onde há o desejo de herdar ativos Ethereum e ferramentas de desenvolvimento, ao mesmo tempo em que se alcançam avanços de desempenho. Projetos representativos incluem:

• Monad: Alcança um modelo de execução paralela otimista compatível com EVM através de gravações atrasadas e deteção de conflitos em tempo de execução, construindo um grafo de dependências e agendando a execução com multithreading após o consenso ser alcançado.
• MegaETH: Abstrai cada conta/contrato como uma Micro-VM independente, alcançando um agendamento paralelo a nível de conta altamente desacoplado com base em mensagens assíncronas e gráficos de dependência de estado.
• Pharos: Construindo uma arquitetura de malha Rollup que colabora com o módulo SPN através de pipelines assíncronos para alcançar processamento paralelo em nível de sistema entre processos.
• Reddio: Adota uma arquitetura zkRollup + GPU, focando na aceleração do processo de verificação off-chain do zkEVM através da geração em massa de SNARK, melhorando a taxa de verificação.

O último liberta-se completamente das limitações da compatibilidade com o Ethereum, redesenhando o paradigma de execução a partir da máquina virtual, do modelo de estado e do mecanismo de agendamento para alcançar capacidades nativas de concorrência de alto desempenho. Subclasses típicas incluem:

• Solana (Sistema SVM): Baseado em declarações de acesso a contas e agendamento de gráfico de conflitos estático, representando um modelo de execução paralela a nível de conta;
• Sui / Aptos (Sistema MoveVM): Baseado no modelo de objeto de recurso e no sistema de tipos, suporta análise estática em tempo de compilação e alcança paralelismo a nível de objeto.
• Sei V2 (Rota Cosmos SDK): Introduz um motor de correspondência multi-threaded e otimização de concorrência de máquina virtual dentro da arquitetura Cosmos, adequado para aplicações de negociação de alta frequência.
• Fuel (UTXO + arquitetura Sway): Atingindo paralelismo em nível de transação através da análise estática de conjuntos de entradas UTXO, combinada com uma camada de execução modular e a linguagem de contrato inteligente personalizada Sway.

Além disso, o Modelo de Ator, como um sistema paralelo mais amplo, constrói um paradigma de execução on-chain de "operação independente de múltiplos agentes + colaboração orientada a mensagens" por meio de um mecanismo de agendamento de processos assíncronos baseado em Wasm ou VMs personalizadas. Projetos representativos incluem:

• AO (Arweave AO): Um runtime de agente impulsionado por armazenamento permanente, construindo um sistema de microkernel assíncrono em cadeia.
• ICP (Internet Computer): Alcança uma execução de alta escalabilidade assíncrona através da coordenação de sub-redes com o agente containerizado (Canister) como a menor unidade.
• Cartesi: Introduz o sistema operativo Linux como um ambiente de computação off-chain, fornecendo um caminho de verificação on-chain para resultados de computação confiáveis, adequado para cenários de aplicação complexos ou intensivos em recursos.

Com base na lógica acima, podemos categorizar as atuais soluções de cadeias públicas de computação paralela mainstream na estrutura de classificação mostrada no gráfico abaixo:

De uma perspectiva mais ampla de escalabilidade, sharding e rollup (L2) focam em alcançar a escalabilidade horizontal do sistema por meio da partição de estado ou execução off-chain, enquanto cadeias de computação paralela (como Monad, Sui, Solana) e sistemas orientados a atores (como AO, ICP) reconstroem diretamente o modelo de execução para alcançar paralelismo nativo no nível da cadeia ou do sistema. O primeiro aumenta a capacidade de processamento on-chain através de métodos como máquinas virtuais multithreaded, modelos de objetos e análise de conflitos de transação; o último utiliza processos/agentes como unidades básicas e adota métodos de execução orientados a mensagens e assíncronos para permitir a operação concorrente de múltiplos agentes. Em comparação, sharding e rollup são mais como 'distribuir a carga entre várias cadeias' ou 'terceirizar para off-chain', enquanto cadeias paralelas e o modelo de ator são sobre 'liberar o potencial de desempenho do próprio motor de execução', refletindo uma direção de evolução arquitetônica mais completa.

Comparação entre Computação Paralela, Arquitetura Shard, Escalabilidade Rollup e Caminho de Extensão Orientado a Atores

Vale a pena notar que a maioria das cadeias de arquitetura paralela nativa já entrou na fase de lançamento da mainnet. Embora o ecossistema geral de desenvolvedores ainda seja difícil de comparar com o sistema Solidity baseado em EVM, projetos representados por Solana e Sui, com sua arquitetura de execução de alto desempenho e a gradual prosperidade das aplicações ecológicas, tornaram-se as cadeias públicas centrais que atraem uma atenção significativa do mercado.

Em contraste, embora o ecossistema Ethereum Rollup (L2) tenha entrado na fase de "muitas cadeias correndo para lançar" ou até mesmo "supercapacidade", as cadeias de melhoria paralela compatíveis com EVM atualmente predominantes ainda estão geralmente na fase de testnet e ainda não passaram por verificação real no ambiente mainnet. Suas capacidades de escalabilidade e a estabilidade do sistema ainda requerem mais exames. Quanto a saber se esses projetos podem melhorar significativamente o desempenho do EVM e promover a evolução ecológica sem sacrificar a compatibilidade, ou se, ao contrário, irão agravar a diferenciação adicional da liquidez e dos recursos de desenvolvimento no Ethereum, ainda está por ver.

Declaração:

1. Este artigo é reproduzido de [TechFlow] O copyright pertence ao autor original [0xjacobzhao e ChatGPT 4o] Se tiver alguma objeção à reimpressão, por favor entre em contacto Equipe Gate LearnA equipe irá processá-lo o mais rápido possível de acordo com os procedimentos relevantes.
2. Aviso: As opiniões e os pontos de vista expressos neste artigo são exclusivamente da responsabilidade do autor e não constituem qualquer aconselhamento de investimento.
3. Outras versões em línguas do artigo são traduzidas pela equipe Gate Learn, a menos que seja mencionado de outra forma.PortãoEm nenhuma circunstância os artigos traduzidos devem ser copiados, disseminados ou plagiados.