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

• Execute escalabilidade aprimorada: Melhore as capacidades de execução no local, como paralelismo, GPU e múltiplos núcleos.
• Expansão isolada de estado: particionamento horizontal de estado / Shard, como sharding, UTXO, multi-subnet
• 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, acionado por mensagens, como agentes, cadeias assíncronas multithreaded.

Soluções de escalabilidade de 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 escalabilidade podem ser divididos em cinco categorias, cada uma representando diferentes buscas de desempenho, modelos de desenvolvimento e filosofias arquitetônicas. A granularidade do paralelismo se torna mais fina, a intensidade do paralelismo aumenta, a complexidade do agendamento se eleva, e a complexidade de programação e a dificuldade de implementação também aumentam.

• Nível de conta: Representa o projeto Solana
• Paralelismo em 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 em nível de instrução: Representa o projeto GatlingX

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

As conhecidas soluções de escalabilidade Rollup ou sharding pertencem a mecanismos de concorrência a nível de sistema e não se enquadram na computação paralela on-chain. 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 serial do Ethereum se desenvolveu através de várias rodadas de 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 sendo 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 a compatibilidade ecológica e a melhoria do 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 do Monad

Monad é uma blockchain de alto desempenho de Camada 1 redesenhada para a Máquina Virtual Ethereum (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 em múltiplas etapas
Pipelining é o conceito fundamental da execução paralela de Monad. 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 processamento concorrente entre blocos, melhorando assim a taxa de transferência e reduzindo a latência. Essas 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 e a execução das transações são tipicamente processos síncronos, e esse 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 na confirmação, tornando o sistema mais resiliente, os fluxos de processamento mais granulares e a utilização de recursos mais alta.

Design Principal:

• O processo de consenso (camada de consenso) é responsável apenas por ordenar 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 a execução terminar.

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", aumentando significativamente a velocidade de processamento de transações.

Mecanismo de execução:

• Monad executará otimisticamente todas as transações em paralelo, assumindo que a maioria das transações não possui conflitos de estado.
• Ao mesmo tempo, execute um "Detector de Conflitos" para monitorar se as transações estão acessando o mesmo estado (como conflitos de leitura/gravação).
• 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íveis nas regras do EVM, alcançando paralelismo ao adiar gravações de estado e detectar conflitos dinamicamente durante a execução, assemelhando-se a uma versão de desempenho do Ethereum. Sua maturidade facilita a migração 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 da 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 na Ethereum ou como um componente modular. Seu objetivo de design central é isolar e desconstruir a lógica de conta, o ambiente de execução e o estado em unidades mínimas agendáveis independentemente para alcançar alta execução concorrente e baixa latência de resposta na cadeia. As principais inovações propostas pelo MegaETH são: arquitetura Micro-VM + DAG de Dependência de Estado (Gráfico 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: Conta é uma thread
MegaETH introduz o modelo de execução de "uma micro máquina virtual (Micro-VM) por conta", que organiza o ambiente de execução em threads e fornece a menor unidade de isolamento para agendamento paralelo. Essas VMs se comunicam por meio de mensagens assíncronas em vez de chamadas síncronas, permitindo que um grande número de VMs execute e armazene de forma independente, possibilitando 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 das contas. 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 consistência de estado e 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 de 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 de forma assíncrona sem bloqueio; a pilha de chamadas é expandida em um grafo de chamadas assíncronas (Grafo de Chamadas); o processamento de transações = percorrendo o grafo assíncrono + resolução de dependências + agendamento paralelo.

Em resumo, MegaETH quebra o modelo tradicional de máquina de estado de thread única EVM ao implementar encapsulamento de micro máquina virtual com base em contas, agendando transações por meio de um gráfico de dependência de estado e usando um mecanismo de mensagem assíncrono em vez de uma pilha de chamadas síncrona. É uma plataforma de computação paralela que é redesenhada em todas as dimensões de “estrutura da conta → arquitetura de agendamento → fluxo de execução”, proporcionando uma nova abordagem em nível de paradigma para a construção da 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 paralelo extremo através de um agendamento de execução assíncrono. Teoricamente, o limite paralelo do MegaETH é maior, mas também é mais difícil controlar a complexidade, assemelhando-se a um super sistema operacional distribuído sob o conceito de Ethereum.

Os conceitos de design do Monad e MegaETH são bem 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 cadeia para alcançar escalabilidade na camada de rede; enquanto Monad e MegaETH mantêm a integridade de uma única cadeia e apenas alcançam escalabilidade horizontal na camada de execução, otimizando o desempenho por meio da execução paralela extrema dentro da única cadeia. Os dois representam duas direções no caminho da escalabilidade da blockchain: aprimoramento vertical e expansão horizontal.

Projetos como Monad e MegaETH focam em caminhos de otimização de throughput, com o objetivo central de melhorar 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 Micro-VM. A Pharos Network, como uma rede blockchain L1 modular e de pilha completa, possui um mecanismo central de computação paralela conhecido como “Rollup Mesh.” Esta arquitetura suporta ambientes de múltiplas máquinas virtuais (EVM e Wasm) através do trabalho colaborativo da mainnet e Redes de Processamento Especiais (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:

• Pipeline Assíncrono de Ciclo de Vida Completo: 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 de 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 em suas necessidades. Essa arquitetura de dual VM não apenas melhora a flexibilidade do sistema, mas também aprimora as capacidades de processamento de transações por meio da execução paralela.
• Redes de Processamento Especiais (SPNs): As SPNs são componentes chave na arquitetura Pharos, semelhantes a subredes 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 por meio do protocolo de Restaking.

Além disso, o Pharos reestruturou o modelo de execução do mecanismo de armazenamento subjacente usando árvores de Merkle de múltiplas versões, Codificação Delta, Endereçamento Versionado e tecnologias ADS Pushdown, lançando o mecanismo de armazenamento de alto desempenho da blockchain nativa Pharos Store, alcançando alta taxa de transferência, baixa latência e fortes capacidades de processamento verificável on-chain.

No geral, a arquitetura Rollup Mesh da Pharos alcança altas capacidades de computação paralela de alto desempenho por meio de um design modular e um mecanismo de processamento assíncrono. A Pharos atua como um coordenador de agendamento para 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 por meio de SPNs.

Além da arquitetura de execução paralela de 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 complemento importante 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 do EVM, alcançando paralelização nativa na camada de execução por meio de agendamento multithread, armazenamento de estado assíncrono e execução acelerada por GPU de lotes de transações. Pertence à granularidade paralela de nível transacional + nível de operação (execução multithread de opcodes). Seu design introduz execução em lote multithread, carregamento de estado assíncrono e processamento paralelo em GPU da lógica de transações (EVM Paralelo Compatível com CUDA). Assim como Monad / MegaETH, Reddio também foca no processamento paralelo na camada de execução, com a diferença sendo a reconstrução do motor de execução através da arquitetura paralela em GPU, especificamente projetada para cenários de alta taxa de transferência e intensivos em computação (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 paralela nativo de GPU. Seu mecanismo central envolve a compilação dinâmica de bytecode EVM em tarefas paralelas CUDA, executando fluxos de instrução 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/nível de conta" do Monad/MegaETH, o mecanismo paralelo do GatlingX está mais próximo dos caminhos de otimização em nível de instrução, mais semelhante à reconstrução subjacente do motor da máquina virtual. Atualmente, está na fase conceitual, com um white paper e esboços arquitetônicos lançados, mas ainda sem SDK ou mainnet.

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 extensões dinamicamente na cadeia, mantendo a compatibilidade com EVM, utilizando o modelo de programação Aspect. Ela 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 (semelhante a "middleware plugável") durante a execução do contrato 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 thread única de "ordem total de transações + execução serial" desde seu design, visando garantir a determinismo e a 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 a 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 conflito estático, apoiando o agendamento concorrente em nível de transação.
• Otimização de concorrência de máquinas virtuais: O mecanismo Sealevel da Solana suporta nativamente a execução multithread; O MoveVM pode realizar análise estática de gráficos de concorrência; O Sei v2 integra um mecanismo de correspondência multithread e um módulo de VM paralelo.

Claro, esse tipo de cadeia paralela nativa também enfrenta desafios de compatibilidade ecológica. Arquiteturas não-EVM geralmente requerem linguagens de desenvolvimento totalmente novas (como Move, Rust) e cadeias de ferramentas, o que apresenta 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 aumentam o nível 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 paralela de transações em cadeia. Através do mecanismo "declaração de conta + agendamento estático + execução multithreaded", 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 de Camada 1.

Mecanismo Central:

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

2. Detecção de Conflitos e Agendamento Multithreading

• Se o conjunto de contas acessadas pelas duas transações não tiver interseção → elas podem ser executadas em paralelo;
• Existe conflito → Executar em série em ordem de dependência;
• O planejador aloca transações para diferentes threads com base no gráfico de dependência.

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

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

Eclipse é um projeto que implanta 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 Solana e sua 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 do Neon é diferente; ele introduz o EVM para rodar no ambiente SVM / Sealevel. Ele constrói uma camada de tempo de execução compatível com o EVM, permitindo que os desenvolvedores usem Solidity para desenvolver contratos que rodem no ambiente SVM, mas a execução de agendamento usa SVM + Sealevel. O Neon está mais inclinado à 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 operacional Solana é semelhante à de um escalonador 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 de 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.

Modelo de propriedade de objetos do Sui
A capacidade de computação paralela do Sui decorre de sua abordagem única de modelagem de estado e mecanismo de análise estática em nível de linguagem. Diferentemente 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 lineares 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. Esses 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 "árvore de estado global" on-chain tradicional. Este design divide 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. Ele permite que o sistema infira quais transações não causarão conflitos de estado por meio da propriedade de objetos antes que as transações sejam executadas, organizando-as para execução paralela. Em comparação com a detecção de conflitos em tempo de execução tradicional e a reversão, 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 em nível de objeto de baixo custo e sem retrocesso. 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 do 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 + reversão de conflitos", adequado para lidar com conjuntos de transações com dependências complexas.

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 pressupostas como livres de conflitos antes da execução, e o sistema agenda transações para múltiplas threads para execução concorrente, registrando os estados da conta que acessam (conjunto de leitura / conjunto de gravação).
• Fase de Detecção e Validação de Conflitos: 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.
• Rollback de Transação em Conflito Retry (Fase de Retry): Transações em conflito serão reagendadas para execução até que suas dependências sejam resolvidas, formando, por fim, 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 + retry de rollback", adequado para cenários de processamento em lote de transações on-chain que são intensivas em estado e logicamente complexas. É o núcleo da computação paralela para Aptos construir uma cadeia pública altamente versátil e de alto throughput.

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 nível 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 on-chain com separação de ativos e combinações claras. Aptos e Sui foram projetados para operar a cadeia como engenheiros de linguagem de programação, garantindo a segurança de recursos em nível de software. Os três representam diferentes caminhos filosóficos para a implementação técnica da computação paralela no Web3.

3.3 Tipo de Escalonamento Paralelo do Cosmos SDK

Sei V2 é uma blockchain pública de alto desempenho para negociação, construída sobre o Cosmos SDK. Suas capacidades paralelas se refletem principalmente em dois aspectos: o motor de correspondência multithread e a otimização de execução paralela na camada da máquina virtual, visando atender cenários de negociação 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 Paralela: Sei V2 introduz um caminho de execução multithread na lógica de correspondência de ordens, separando o livro de ordens da lógica de correspondência no nível de thread, permitindo que 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 em Nível de Máquina Virtual: 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 conflitem, alcançando um controle de throughput mais alto em conjunto com um mecanismo de classificação de tipo de transação.
• Consenso paralelo combinado com agendamento da camada de execução: introduzindo o chamado mecanismo de consenso "Twin-Turbo" para fortalecer o desacoplamento da capacidade entre a camada de consenso e a camada de execução, aumentando a eficiência geral do processamento de blocos.

3.4 Reconstructor de Modelo UTXO Fuel

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

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

O Modelo de Ator é um paradigma de execução paralela que utiliza processos agentes (Agente ou Processo) como unidades, diferenciando-se da computação síncrona tradicional com um estado global na cadeia (cenários como "computação paralela on-chain" como Solana/Sui/Monad), pois 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 on-chain 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 on-chain", fornecendo infraestrutura nativa para Agentes de IA, interações multi-tarefa 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 "computação assíncrona multi-processo", 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 o 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 o Sharding é uma solução de escalonamento 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 operacional on-chain que suporte a operação de agentes assíncronos em grande escala.

Recursos Principais da Arquitetura:

• Arquitetura de processo: 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 uma camada de armazenamento descentralizada baseada em Arweave + um motor de execução orientado a mensagens multiagente;
• Sistema de Agendamento de Mensagens Assíncronas: Os processos se comunicam por meio de mensagens, adotando um modelo de operação assíncrono livre de bloqueios, que suporta intrinsecamente a escalabilidade concorrente;
• Armazenamento permanente de estado: Todos os estados dos agentes, registros de mensagens e instruções são registrados permanentemente no Arweave, garantindo completa auditabilidade e transparência descentralizada.
• Agente-nativo: Adequado para implantar tarefas complexas de 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 + orientado a armazenamento + arquitetura sem cadeia", enfatizando flexibilidade e 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 compostáveis.

4.2 ICP (Internet Computer), uma plataforma de hospedagem Web3 full-stack

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

Recursos da arquitetura principal:

• Arquitetura de Canister (containers como agentes inteligentes): Cada Canister é um agente inteligente executando 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 se comunicam entre si por meio de mensagens assíncronas, suportando execução não bloqueante e tendo paralelismo inerente;
• Hospedagem Web On-chain: Suporta contratos inteligentes para hospedar diretamente páginas front-end, com mapeamento de DNS nativo, tornando-se a primeira plataforma blockchain a suportar acesso direto a dApps via navegador.
• Funções abrangentes do sistema: Equipado com atualizações quentes on-chain, autenticação de identidade, aleatoriedade distribuída, temporizadores e outras APIs do sistema, adequado para implantação de serviços on-chain complexos.

O ICP seleciona uma plataforma robusta, encapsulamento integrado e um paradigma de sistema operacional de controle forte, apresentando um "Sistema Operacional de Blockchain" com consenso, execução, armazenamento e acesso integrados. Ele 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 Ator podem se referir à tabela abaixo:

V. Resumo e Perspectivas

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

O primeiro alcança maior capacidade de processamento e processamento paralelo por meio 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 e ferramentas de desenvolvimento do Ethereum, 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 por meio de gravações atrasadas e detecção de conflitos em tempo de execução, construindo um grafo de dependência 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 em nível de conta altamente desacoplado com base em mensagens assíncronas e grafos de dependência de estado.
• Pharos: Construindo uma arquitetura Rollup Mesh que colabora com o módulo SPN através de pipelines assíncronas para alcançar o processamento paralelo em nível de sistema entre processos.
• Reddio: Adota uma arquitetura zkRollup + GPU, focando em acelerar o processo de verificação off-chain do zkEVM através da geração em massa de SNARK, aumentando a capacidade de verificação.

O último se liberta completamente das limitações da compatibilidade com Ethereum, redesenhando o paradigma de execução a partir da máquina virtual, modelo de estado e 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 grafo de conflito estático, representando um modelo de execução paralela em 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 do Cosmos SDK): Introduz um motor de correspondência multi-thread 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): Alcançando paralelismo em nível de transação por meio 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ções independentes 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 execução de alta escalabilidade assíncrona por meio da coordenação de sub-redes com o agente containerizado (Canister) como a menor unidade.
• Cartesi: Introduz o sistema operacional 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 que consomem muitos recursos.

Com base na lógica acima, podemos categorizar as atuais soluções de blockchain pública 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) se concentram em alcançar a escalabilidade horizontal do sistema através 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 taxa de transferência on-chain por meio de métodos como máquinas virtuais multithreaded, modelos de objeto e análise de conflito de transações; o último usa processos/agentes como unidades básicas e adota métodos de execução orientados a mensagens e assíncronos para possibilitar a operação concorrente de múltiplos agentes. Em comparação, sharding e rollup são mais como 'distribuir a carga entre múltiplas 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 profunda.

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

Vale a pena notar que a maioria das cadeias nativas de arquitetura paralela 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 de aplicações ecológicas, tornaram-se as cadeias públicas centrais que atraem 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 de “sobrecarga”, as atuais cadeias de aprimoramento paralelo compatíveis com EVM ainda estão, em geral, na fase de testnet e ainda não passaram por verificação real no ambiente da mainnet. Suas capacidades de escalonamento e 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, em vez disso, eles irão agravar a diferenciação adicional da liquidez e dos recursos de desenvolvimento no Ethereum, ainda está por ser visto.

Declaração:

1. Este artigo é reproduzido de [TechFlow] Os direitos autorais pertencem ao autor original [0xjacobzhao e ChatGPT 4o] Se você tiver alguma objeção à reimpressão, entre em contato 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 visões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. Outras versões do artigo em outros idiomas são traduzidas pela equipe do Gate Learn, a menos que mencionado de outra forma.PortãoEm nenhuma circunstância os artigos traduzidos poderão ser copiados, disseminados ou plagiados.