Web3 Parallel Computing Track Panorama: A melhor solução para dimensionamento nativo?

Autor: 0xjacobzhao e ChatGPT 4oO

"Trilema Blockchain" de "segurança", "descentralização" e "escalabilidade" do blockchain revela o trade-off essencial no design de sistemas blockchain, ou seja, é difícil para os projetos de blockchain alcançar "segurança extrema, todos podem participar e processamento de alta velocidade" ao mesmo tempo. Em resposta ao eterno tópico de "escalabilidade", as principais soluções de escalonamento de blockchain no mercado são divididas de acordo com paradigmas, incluindo:

• Dimensionamento aprimorado de execução: melhora os recursos de execução in situ, como paralelismo, GPU e
• dimensionamento isolado de estado multi-core: estado/fragmento dividido horizontalmente, por exemplo, fragmentos, UTXO e várias sub-redes
• Dimensionamento terceirizado off-chain: Colocando a execução fora da cadeia, como rollups, Coprocessador e dimensionamento de
• desacoplamento de estrutura DA: arquitetura modular e operação colaborativa, como cadeia de módulos, sequenciador compartilhado, malha de rollup
• Dimensionamento simultâneo assíncrono: Modelo de ator, isolamento de processo, orientado por mensagem, como agente, cadeia assíncrona multi-threaded

  A solução de escalonamento blockchain inclui: computação paralela on-chain, rollup, fragmentação, módulo DA, estrutura modular, sistema de atores, compressão à prova de zk, arquitetura sem estado, etc., cobrindo vários níveis de execução, estado, dados e estrutura, e é um sistema de escalonamento completo de "colaboração multicamadas e combinação de módulos". Este artigo se concentra em métodos de dimensionamento que integram a computação paralela.

  Paralelismo intra-cadeia, que se concentra na execução paralela de transações/instruções intra-bloco. De acordo com o mecanismo paralelo, seus métodos de escalonamento podem ser divididos em cinco categorias, cada uma das quais representa uma busca de desempenho diferente, modelo de desenvolvimento e filosofia de arquitetura, e a granularidade paralela está ficando cada vez mais fina, a intensidade do paralelismo está ficando cada vez maior, a complexidade de programação está ficando cada vez maior, e a complexidade de programação e dificuldade de implementação também estão ficando cada vez maiores.

  • Nível da conta: Representa o projeto
  • Nível do objeto: Representa o projeto Sui
  • Nível de transação: Representa o projeto Monad, Aptos
  • Call-level / MicroVM : MegaETH de nível de instrução
  :
  • GatlingX

  O modelo de simultaneidade assíncrona off-chain, representado pelo Modelo Ator/Ator, pertence a outro paradigma de computação paralela, como um sistema de mensagens cross-chain/assíncrono (modelo de sincronização sem bloco), cada agente é executado independentemente como um "processo de agente", mensagens assíncronas em modo paralelo, orientadas a eventos, sem agendamento síncrono, projetos representativos como AO, ICP, Cartesi, etc.

  O conhecido esquema de rollup ou escalonamento de estilhaços pertence ao mecanismo de simultaneidade no nível do sistema, não à computação paralela intracadeia. Eles alcançam o dimensionamento "executando várias cadeias/domínios de execução em paralelo", em vez de aumentar o paralelismo dentro de um único bloco/máquina virtual. Este tipo de solução de dimensionamento não é o foco deste artigo, mas ainda vamos usá-lo para comparar as semelhanças e diferenças nos conceitos arquitetônicos.

  

  2. EVM Parallel Enhancement Chain: Quebrando o limite de desempenho em compatibilidade

  Desde o desenvolvimento da arquitetura de processamento serial do Ethereum, ele passou por várias rodadas de tentativas de escala, como fragmentação, rollup e arquitetura modular, mas o gargalo de taxa de transferência da camada de execução ainda não foi fundamentalmente quebrado. Mas, ao mesmo tempo, EVM e Solidity ainda são as plataformas de contratos inteligentes com mais base de desenvolvedores e potencial ecológico. Portanto, a cadeia de aprimoramento paralelo EVM está se tornando uma direção importante para uma nova rodada de escalonamento e evolução como um caminho chave que leva em conta a compatibilidade ecológica e a melhoria do desempenho de execução. Monad e MegaETH são os projetos mais representativos nessa direção, começando pela execução diferida e decomposição de estado, respectivamente, para construir uma arquitetura de processamento paralelo EVM para cenários de alta simultaneidade e alta taxa de transferência.

  Análise de

  computação paralela da MonadMonad

  é um blockchain Layer1 de alto desempenho redesenhado para a Máquina Virtual Ethereum (EVM), baseado no conceito paralelo básico de pipelining, com execução assíncrona na camada de consenso e simultaneidade otimista na camada de execução Execução paralela) 。 Além disso, nas camadas de consenso e armazenamento, a Monad introduziu o protocolo BFT de alto desempenho (MonadBFT) e um sistema de banco de dados dedicado (MonadDB), respectivamente, para alcançar a otimização de ponta a ponta.

  Pipelining: Mecanismo de execução paralela de pipeline de vários estágios

  O pipelining é o conceito básico da execução paralela da Monad, e sua ideia central é dividir o processo de execução do blockchain em vários estágios independentes, e processar esses estágios em paralelo para formar uma arquitetura de pipeline tridimensional, cada estágio é executado em threads ou núcleos independentes para alcançar o processamento simultâneo de blocos cruzados. O resultado é o aumento da taxa de transferência e a redução da latência. Essas etapas incluem: Proposta, Consenso, Execução e Compromisso.

  Execução assíncrona: Consenso - A execução é dissociada de forma assíncronaNas

  cadeias tradicionais, o consenso e a execução de transações geralmente são processos síncronos, e esse modelo serial limita severamente o dimensionamento de desempenho. O Monad implementa camada de consenso assíncrona, camada de execução assíncrona e armazenamento assíncrono por meio de "execução assíncrona". Reduza significativamente o tempo de bloqueio e a latência de confirmação, tornando o sistema mais resiliente, o processamento mais segmentado e a utilização de recursos.

  Design central:

  O
  • processo de consenso (camada de consenso) é responsável apenas pela classificação de 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.
  • Depois que o consenso for concluído, ele entrará no processo de consenso do próximo bloco imediatamente, sem esperar que a execução seja concluída.

  Execução paralela otimista: execução paralela otimistaO Ethereum tradicional

  adota um modelo estritamente serial para execução de transações para evitar conflitos de estado. A Monad, por outro lado, adota uma estratégia de "execução paralela otimista" para aumentar significativamente a velocidade de processamento das transações.

  Mecanismo de execução:

  • A Monad executa com otimismo todas as transações em paralelo, assumindo que a maioria das transações são apátridas e livres de conflitos.
  • Execute também um "Detetor de Conflitos" para monitorar se o mesmo estado (por exemplo, conflitos de leitura/gravação) é acessado entre as transações.
  • Se um conflito for detetado, a transação conflitante será serializada e reexecutada para garantir que o estado esteja correto.

  A Monad escolheu um caminho compatível: mover o menor número possível de regras EVM, alcançar paralelismo adiando o estado de gravação e detetando dinamicamente conflitos durante a execução, o que é mais parecido com uma versão de desempenho do Ethereum, com um nível de maturidade que facilita a migração para o ecossistema EVM, e é um acelerador paralelo no mundo EVM.

  A resolução do mecanismo de computação paralela do MegaETH

  é diferente do posicionamento L1 do Monad, e o MegaETH é posicionado como uma camada de execução paralela modular de alto desempenho compatível com EVM, que pode ser usada como uma cadeia pública L1 independente, como uma camada de aprimoramento de execução ou componente modular no Ethereum. Seu objetivo principal de design é desconstruir a lógica da conta, o ambiente de execução e o isolamento de estado na menor unidade que pode ser programada de forma independente para alcançar a execução de alta simultaneidade e a capacidade de resposta de baixa latência dentro da cadeia. A principal inovação proposta pelo MegaETH é que a arquitetura Micro-VM + State Dependency DAG (gráfico de dependência de estado dirigido e acíclico) e o mecanismo de sincronização modular constroem em conjunto um sistema de execução paralela para "threading intra-chain".

  Arquitetura Micro-VM: Contas são threads

  MegaETH introduz o modelo de execução de "uma micro-VM por conta", que "encadeia" o ambiente de execução e fornece uma unidade de isolamento mínima para agendamento paralelo. Essas VMs se comunicam entre si por meio de mensagens assíncronas em vez de chamadas síncronas, e um grande número de VMs pode ser executado independentemente, armazenado de forma independente e naturalmente paralelo.

  DAG de dependência de estado: um mecanismo

  de agendamento controlado por gráfico MegaETH construiu um sistema de agendamento DAG com base na relação de acesso ao estado da conta, e o sistema mantém um gráfico de dependência global em tempo real, e quais contas são modificadas e quais contas são lidas para cada transação são todas modeladas em dependências. As transações sem conflitos podem ser executadas diretamente em paralelo, e as transações dependentes serão agendadas e classificadas em série ou diferidas em ordem topológica. Os gráficos de dependência garantem consistência de estado e gravações não duplicadas durante a execução paralela.

  O

  mecanismo de execução assíncrona e retorno de chamada

  MegaETH é construído sobre o paradigma de programação assíncrona, semelhante à passagem assíncrona de mensagens do Modelo Ator, para resolver o problema das chamadas seriais EVM tradicionais. As chamadas de contrato são assíncronas (execução não recursiva) e, quando o contrato A -> B -> C é chamado, cada chamada é assíncrona sem bloquear a espera; A pilha de chamadas é expandida em um gráfico de chamadas assíncronas; Processamento de transações = travessia de gráfico assíncrono + resolução de dependência + agendamento paralelo.

  Em suma, o MegaETH quebra o modelo tradicional de máquina de estado de thread único EVM, implementa o encapsulamento de máquina microvirtual conta a conta, executa o agendamento de transações por meio de gráficos dependentes de estado e substitui a pilha de chamadas síncronas por um mecanismo de mensagens assíncrono. É uma plataforma de computação paralela que é redesenhada a partir de todas as dimensões da "estrutura de conta→ arquitetura de agendamento → processo de execução", fornecendo uma nova ideia de nível paradigmático para a construção de um sistema on-chain de alto desempenho de próxima geração.

  O MegaETH escolheu o caminho da refatoração: abstrai completamente contas e contratos em VMs independentes e libera o potencial de paralelismo final por meio de agendamento de execução assíncrono. Teoricamente, MegaETH tem um limite paralelo mais alto, mas também é mais difícil de controlar a complexidade, e é mais como um sistema operacional super-distribuído sob o conceito Ethereum.

  

  Monad e MegaETH Ambos têm conceitos de design diferentes do sharding: o sharding divide horizontalmente o blockchain em várias sub-cadeias independentes (shards), cada uma das quais é responsável por parte das transações e estado, quebrando a limitação de cadeia única e escalando a camada de rede; Por outro lado, tanto o Monad quanto o MegaETH mantêm a integridade da cadeia única, escalando horizontalmente apenas na camada de execução e realizando avanços de otimização em paralelo no limite da cadeia única. Os dois representam duas direções: fortalecimento vertical e expansão horizontal no caminho de expansão do blockchain.

  Projetos de computação paralela, como Monad e MegaETH, se concentram principalmente no caminho de otimização de taxa de transferência, com o objetivo principal de melhorar o TPS on-chain e alcançar processamento paralelo em nível de transação ou conta por meio de execução diferida e arquiteturas de micro-VM. Pharos Network é uma rede blockchain L1 paralela modular e full-stack, e seu principal sistema de computação paralela é chamado de "Rollup Mesh". Esta arquitetura suporta ambientes de máquinas multivirtuais (EVM e Wasm) através da sinergia de mainnet e redes de processamento especiais (SPNs), e integra tecnologias avançadas, como provas de conhecimento zero (ZK) e ambientes de execução confiáveis (TEEs).

  Análise de computação

  paralela de malha de rollup:

  1. pipelining assíncrono de ciclo de vida completo: o Pharos separa os vários estágios de uma transação (como consenso, execução e armazenamento) e adota processamento assíncrono para que cada estágio possa ser realizado de forma independente e em paralelo, melhorando assim a eficiência geral do processamento.
  2. Execução paralela de VM dupla: o Pharos suporta ambientes de máquina virtual EVM e WASM, permitindo que os desenvolvedores escolham o ambiente de execução certo para suas necessidades. Esta arquitetura dual-VM não só aumenta a flexibilidade do sistema, mas também aumenta o processamento de transações através da execução paralela.
  3. Redes de Processamento Especial (SPNs): SPNs são componentes-chave na arquitetura Pharos, semelhantes a sub-redes modulares projetadas para lidar com tipos específicos de tarefas ou aplicações. Com SPNs, Pharos permite alocação dinâmica de recursos e processamento paralelo de tarefas, aumentando ainda mais a escalabilidade e o desempenho do sistema.
  4. Consenso modular & Restaking: Pharos introduz um mecanismo de consenso flexível que suporta vários modelos de consenso (como PBFT, PoS, PoA) e permite o compartilhamento seguro e a integração de recursos entre a rede principal e SPNs por meio do protocolo de restake.

  Além disso, a Pharos reconstrói o modelo de execução a partir da camada inferior do mecanismo de armazenamento por meio da árvore Merkle multiversão, codificação Delta, endereçamento versionado e tecnologia ADS Pushdown, e lança a Pharos Store, um mecanismo de armazenamento de alto desempenho para o blockchain nativo, para alcançar alta taxa de transferência, baixa latência e fortes recursos de processamento on-chain verificáveis.

  Em geral, a arquitetura Rollup Mesh da Pharos alcança recursos de computação paralela de alto desempenho por meio de design modular e mecanismo de processamento assíncrono.

  Além das arquiteturas de execução paralela de Monad, MegaETH e Pharos, também observamos que existem alguns projetos no mercado que exploram o caminho de aplicação da aceleração de GPU em computação paralela EVM, como um importante suplemento 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 GPU, e seu núcleo está em reconstruir o processo de execução EVM e realizar a paralelização nativa da camada de execução por meio de agendamento multi-threaded, armazenamento de estado assíncrono e execução acelerada por GPU de lotes de transação. Granularidade paralela no nível de transação + nível de operação (opcode de execução multi-threaded). Ele foi projetado para introduzir a execução em lote multi-threaded, carregamento de estado assíncrono e lógica de transação de processamento paralelo de GPU (EVM paralelo compatível com CUDA). Assim como Monad / MegaETH, o Reddio também se concentra no processamento paralelo na camada de execução, com a diferença de que o mecanismo de execução é reconstruído por meio de uma arquitetura paralela GPU, projetada para cenários de alto rendimento e computação intensiva, como inferência de IA. O GatlingX,
  • que se autodenomina "GPU-EVM", propõe uma arquitetura mais radical que tenta migrar o modelo de "execução serial de nível de instrução" das máquinas virtuais EVM tradicionais para um ambiente de tempo de execução paralelo nativo da GPU. O mecanismo central é compilar dinamicamente o bytecode EVM em tarefas paralelas CUDA e executar o fluxo de instruções através do GPU multi-core, de modo a quebrar o gargalo sequencial do EVM no nível mais baixo. Granularidade paralela que pertence ao paralelismo de nível de instrução (ILP). Comparado com a granularidade paralela "nível de transação/nível de conta" do Monad / MegaETH, o mecanismo de paralelismo do GatlingX pertence ao caminho de otimização de nível de instrução, que está mais próximo da refatoração subjacente do mecanismo de máquina virtual. Atualmente está na fase de conceito, com um whitepaper e esboço arquitetônico publicados, e nenhum SDK ou mainnet ainda.

  A Artela propõe um conceito de design diferenciado e paralelo. Com a introdução da máquina virtual WebAssembly (WASM) da arquitetura EVM++, os desenvolvedores podem adicionar e executar dinamicamente extensões on-chain usando o modelo de programação Aspect enquanto mantêm a compatibilidade com EVM. Ele usa a granularidade de invocação de contrato (Função / Extensão) como a unidade paralela mínima, e suporta a injeção de módulos de extensão (semelhante ao "middleware conectável") quando o contrato EVM está em execução, de modo a alcançar o desacoplamento lógico, invocação assíncrona e execução paralela no nível do módulo. Mais atenção é dada à composibilidade e arquitetura modular da camada de execução. O conceito fornece novas ideias para aplicações multi-módulo complexas no futuro.

  3. Cadeia de arquitetura paralela nativa: O modelo de execução EVM do Ethereum, a ontologia de execução da VM reconstruída

  ,

  adotou uma arquitetura single-threaded de "ordem de transação completa + execução serial" desde o início de seu projeto, com o objetivo de garantir a certeza e consistência das mudanças de estado para todos os nós da rede. No entanto, essa arquitetura tem um gargalo natural no desempenho, limitando a taxa de transferência e a escalabilidade do sistema. Em contraste, cadeias de arquitetura de computação paralela nativas, como Solana (SVM), MoveVM (Sui, Aptos) e Sei v2 construídas no SDK do Cosmos, são adaptadas para execução paralela a partir do design subjacente e têm as seguintes vantagens:

  • Separação natural de modelos de estado: Solana usa um mecanismo de declaração de bloqueio de conta, MoveVM introduz um modelo de propriedade de objeto e Sei v2 é baseado na classificação de tipo de transação. O julgamento de conflito estático é realizado e o agendamento simultâneo no nível de transação é suportado.
  • As máquinas virtuais são otimizadas para simultaneidade: o mecanismo Sealevel do Solana suporta nativamente a execução multi-threaded; O MoveVM pode executar a análise de gráficos de simultaneidade estática; O Sei v2 integra um mecanismo de correspondência multi-threaded com um módulo VM paralelo.

  É claro que este tipo de cadeia paralela nativa também enfrenta o desafio da compatibilidade ecológica. As arquiteturas não-EVM geralmente exigem novas linguagens de desenvolvimento (como Move e Rust) e cadeias de ferramentas, que têm certos custos de migração para os desenvolvedores. Além disso, os desenvolvedores precisam dominar uma série de novos conceitos, como modelos de acesso stateful, limites de simultaneidade, ciclos de vida de objetos, etc., que apresentam requisitos mais altos para a compreensão de limites e paradigmas de desenvolvimento.

  3.1 O princípio do motor paralelo Sealevel de Solana e SVM

  O modelo de execução Sealevel de Solana é um mecanismo de agendamento paralelo de conta, que é o motor central usado por Solana para realizar a execução de transações paralelas dentro da cadeia, e alcança simultaneidade de alto desempenho no nível de contrato inteligente através do mecanismo de "declaração de conta + agendamento estático + execução multi-threaded". Sealevel é o primeiro modelo de execução no campo blockchain a implementar com sucesso o agendamento simultâneo intra-cadeia em um ambiente de produção, e suas ideias arquitetônicas influenciaram muitos projetos subsequentes de computação paralela, e é um paradigma de referência para o design paralelo de camada 1 de alto desempenho.

  Mecanismo principal:

  1. Listas de acesso explícitas à conta: Cada transação deve declarar a conta envolvida (leitura/gravação) ao enviar, e o sistema determinará se há um conflito de estado entre as transações.

  2. Deteção de conflitos e agendamento multi-threaded

  • Se não houver interseção entre os conjuntos de contas acessados pelas duas transações→ eles podem ser executados em paralelo;
  • Há um conflito→ executando serialmente em ordem dependente;
  • O agendador aloca transações para diferentes threads com base no gráfico de dependência.

  3. Contexto de invocação do programa: Cada chamada de contrato é executada em um contexto isolado sem uma pilha compartilhada para evitar interferência entre chamadas.

  O Sealevel é o mecanismo de agendamento de execução paralela do Solana, enquanto o SVM é um ambiente de execução de contrato inteligente 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 de Solana.

  O Eclipse é um projeto que implanta VMs Solana em cadeias modulares como Ethereum L2 ou Celestia, aproveitando o mecanismo de execução paralela de Solana como a camada de execução rollup. O Eclipse é um dos primeiros projetos a propor separar a camada de execução Solana (Sealevel + SVM) da rede principal Solana e migrá-la para uma arquitetura modular, e a saída modular do "modelo de execução super concorrente" de Solana é a Camada de Execução como Serviço, então o Eclipse também pertence à categoria de computação paralela.

  A rota da Neon é diferente, ela introduz o EVM para operar em um ambiente SVM / Sealevel. Crie uma camada de tempo de execução compatível com EVM, os desenvolvedores podem usar o Solidity para desenvolver contratos e executar no ambiente SVM, mas a execução de agendamento usa SVM + Sealeve. Neon inclina-se mais para a categoria Blockchain modular do que a inovação de computação paralela.

  Em suma, Solana e SVMs dependem do mecanismo de execução Sealevel, e a filosofia de agendamento baseada em SO de Solana é semelhante ao agendador do kernel, que é rápido, mas relativamente inflexível. É uma cadeia pública nativa de computação paralela de alto desempenho.

  3.2 Arquitetura MoveVM: Resource and Object Driven

  MoveVM é uma máquina virtual de contrato inteligente projetada para segurança de recursos on-chain e execução paralela, e sua linguagem central, Move, foi originalmente desenvolvida pela Meta (anteriormente Facebook) para o projeto Libra, enfatizando o conceito de "recursos são objetos", e todos os estados on-chain existem como objetos, com propriedade clara e ciclos de vida. Isso permite que o MoveVM analise se há conflitos de estado entre as transações durante o tempo de compilação e implemente o agendamento paralelo estático no nível do objeto, que é amplamente usado em cadeias públicas paralelas nativas, como Sui e Aptos.

  Modelo de propriedade de objeto de SuiOs

  recursos de computação paralela de Sui derivam de sua abordagem única para modelagem de estado e análise estática em nível de linguagem. Ao contrário das blockchains tradicionais, que usam árvores de estado globais, Sui construiu um modelo centrado no objeto baseado no "objeto", que trabalha com o sistema de tipo linear do MoveVM para tornar o agendamento paralelo um processo determinístico que pode ser concluído em tempo de compilação.

  • O Modelo de Objeto é a base da arquitetura paralela de Sui. Sui abstrai todo o estado na cadeia em objetos separados, cada um com um ID único, um proprietário claro (conta ou contrato) e uma definição de tipo. Esses objetos não compartilham estados uns com os outros e são inerentemente isolados. O contrato deve declarar explicitamente a coleção de objetos envolvidos quando é chamado, evitando o problema de acoplamento de estado da tradicional "árvore de estado global" on-chain. Este projeto divide o estado on-chain em várias unidades independentes, tornando a execução simultânea 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 apoio do sistema de tipo linear da linguagem Move. Ele permite que o sistema programe transações para serem executadas em paralelo, inferindo quais transações não têm conflitos de estado por meio da propriedade do objeto antes de serem executadas. Em comparação com a deteção de conflitos e a reversão de tempos de execução tradicionais, o mecanismo de análise estática da Sui reduz consideravelmente a complexidade de agendamento enquanto melhora a eficiência de execução, que é a chave para alcançar altos recursos de throughput e processamento paralelo determinístico.

  Sui divide o espaço de estado em uma base de objeto por objeto, combinado com a análise de propriedade em tempo de compilação, para obter uma execução paralela de baixo custo e sem reversão no nível do objeto. Em comparação com a execução serial ou deteção de 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 AptosAptos

  é um blockchain Layer1 de alto desempenho baseado na linguagem Move, e sua capacidade de execução paralela é derivada principalmente da estrutura auto-desenvolvida Block-STM (Block-level Software Transactional Memory). Ao contrário da estratégia de Sui de "paralelismo estático em tempo de compilação", o Block-STM pertence ao mecanismo de agendamento dinâmico de "simultaneidade otimista em tempo de execução + reversão de conflito", que é adequado para lidar com conjuntos de transações com dependências complexas.

  O Block-STM divide a execução da transação de um bloco em três estágios:

  • Execução especulativa: Todas as transações são livres de conflitos por padrão antes da execução, e o sistema agenda transações em paralelo a vários threads para tentar executar simultaneamente e registra o status da conta (conjunto de leitura/gravação) acessado por eles.
  • Fase de validação: O sistema verifica o resultado da execução: se houver um conflito de leitura-gravação entre duas transações (por exemplo, Tx1 lê o estado de ser escrito por Tx2), uma delas é revertida.
  • Fase de repetição: as transações conflitantes serão reagendadas até que suas dependências sejam resolvidas e, eventualmente, todas as transações formem uma sequência válida e determinística de envios de estado.

  O Block-STM é um modelo de execução dinâmica de "paralelismo otimista + reversão e tentativas", que é adequado para cenários de processamento em lote de transações on-chain intensivos e logicamente complexos, e é o núcleo de computação paralela para o Aptos construir uma cadeia pública de alta versatilidade e alto rendimento.

  

  Solana é uma escola de programação de engenharia, mais como um "kernel do sistema operacional", adequado para limites de estado claros, negociação controlável de alta frequência, é um estilo de engenheiro de hardware, para executar a cadeia como hardware (execução paralela de nível de hardware); O Aptos é um sistema tolerante a falhas, mais parecido com um "motor de simultaneidade de banco de dados", adequado para sistemas de contrato com forte acoplamento de estado e cadeias de chamadas complexas. Aptos e Sui são como engenheiros de linguagem de programação, e a segurança de recursos de nível de software representa o caminho de implementação técnica da computação paralela Web3 sob diferentes filosofias.

  3.3 Cosmos SDK Parallel Scaling

  O Sei V2 é uma cadeia pública transacional de alto desempenho construída com base no SDK do Cosmos, e sua capacidade de paralelismo é refletida principalmente em dois aspetos: o mecanismo de correspondência multi-threaded (Parallel Matching Engine) e a otimização da execução paralela da camada de máquina virtual, que é projetada para atender cenários de transação on-chain de alta frequência e baixa latência, como o livro de ordens DEX, infraestrutura de intercâmbio em cadeia, etc.

  Core Parallelism Mechanism:

  1. Parallel Matching Engine: O SEI V2 introduz um caminho de execução multi-threaded na lógica de correspondência de ordens, dividindo o livro de ordens pendentes e a lógica de correspondência no nível de thread, para que as tarefas de correspondência entre vários pares de negociação possam ser processadas em paralelo e evitar o gargalo de thread único.
  2. Otimização de simultaneidade no nível da máquina virtual: o Sei V2 cria um ambiente de tempo de execução CosmWasm com recursos de execução simultânea, que permite que algumas chamadas de contrato sejam executadas em paralelo sem conflitos de estado, e coopera com o mecanismo de classificação de tipo de transação para obter um controle de taxa de transferência mais alto.
  3. Consenso paralelo e programação da camada de execução: O chamado mecanismo de consenso "Twin-Turbo" é introduzido para fortalecer a taxa de transferência e o desacoplamento entre a camada de consenso e a camada de execução, e melhorar a eficiência geral do processamento de blocos.

  3.4 UTXO Model Reformer Fuel Fuel é

  uma camada de execução de alto desempenho projetada com base na arquitetura modular do Ethereum, e seu mecanismo de paralelismo central é derivado do modelo UTXO melhorado (Unspent Transaction Output). Ao contrário do modelo de conta do Ethereum, o Fuel usa uma estrutura UTXO para representar ativos e estados, que é inerentemente isolada do estado, tornando mais fácil determinar quais transações podem ser executadas com segurança em paralelo. Além disso, a Fuel introduz sua linguagem de contrato inteligente auto-desenvolvida Sway (semelhante ao Rust), combinada com ferramentas de análise estática, para determinar conflitos de entrada antes que as transações sejam executadas, de modo a alcançar um agendamento paralelo de nível de transação eficiente e seguro. É uma camada de execução alternativa EVM que equilibra desempenho e modularidade.

  4. Modelo de ator: um novo paradigma de execução simultânea

  de agentes O modelo de ator é um paradigma de execução paralela baseado em agente ou processo, que é diferente da computação síncrona tradicional do estado global na cadeia (Solana/Sui/Monad e outros cenários de "computação paralela on-chain"), que enfatiza que cada agente tem um estado e comportamento independentes, e se comunica e agenda através de mensagens assíncronas. Sob essa arquitetura, o sistema on-chain pode ser executado simultaneamente por um grande número de processos que são dissociados uns dos outros, e tem 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 do blockchain de um mecanismo de execução para um "sistema operacional on-chain", fornecendo uma infraestrutura nativa para agentes de IA, interações multitarefas e orquestração lógica complexa.

  Embora o design do Modelo de Ator seja semelhante à fragmentação em termos de características superficiais (por exemplo, paralelismo, isolamento de estado e processamento assíncrono), os dois representam essencialmente caminhos técnicos e filosofias de sistema completamente diferentes. O Modelo de Ator enfatiza a "computação assíncrona de vários processos", onde cada agente é executado de forma independente, mantém o estado de forma independente e interage de forma orientada por mensagem. O compartilhamento, por outro lado, é um mecanismo de "fragmentação horizontal de estado e consenso", que divide todo o blockchain em vários subsistemas (fragmentos) que processam transações de forma independente. Os Modelos de Ator são mais parecidos com um "sistema operacional de agente distribuído" no mundo Web3, enquanto o fragmento é uma solução de dimensionamento estrutural para recursos de processamento de transações on-chain. Ambos alcançam paralelismo, mas têm pontos de partida, objetivos e arquiteturas de execução diferentes.

  4.1 AO (Arweave), um computador super-paralelo no topo da camada de armazenamentoAO

  é uma plataforma de computação descentralizada executada 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.

  Principais características da arquitetura:

  • Arquitetura de processo: Cada agente é chamado de processo, com estado independente, agendador independente e lógica de execução;
  • Nenhuma estrutura de blockchain: AO não é uma cadeia, mas uma camada de armazenamento descentralizada + mecanismo de execução multiagente orientado por mensagem baseado em Arweave;
  • Sistema de agendamento assíncrono de mensagens: os processos se comunicam entre si por meio de mensagens, adotam um modelo de operação assíncrona sem bloqueio e, naturalmente, suportam expansão simultânea.
  • Armazenamento de estado permanente: Todos os estados do agente, registros de mensagens e instruções são gravados permanentemente no Arweave, garantindo total auditabilidade e transparência descentralizada.
  • Nativo de agente: é adequado para implantar tarefas complexas de várias etapas (como agentes de IA, controladores de protocolo DePIN, orquestradores automáticos de tarefas, etc.) e pode construir um "coprocessador de IA on-chain".

  O AO toma a rota final de "agente nativo + driver de armazenamento + arquitetura sem cadeia", enfatizando flexibilidade e desacoplamento de módulos, e é uma "estrutura de microkernel na cadeia construída sobre a camada de armazenamento", com o limite do sistema deliberadamente encolhendo, enfatizando computação leve + estrutura de controle composable.

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

  é uma plataforma de aplicativos on-chain full-stack nativa da Web3 lançada pela DFINITY, com o objetivo de estender o poder de computação on-chain para experiências semelhantes à Web2 e suportar hospedagem de serviço completa, vinculação de nome de domínio e arquitetura sem servidor.

  Principais recursos da arquitetura:

  • Arquitetura de canister (contêineres como agentes): Cada canister é um agente em execução em uma VM Wasm com recursos independentes de estado, código e agendamento assíncrono;
  • Subnet Distributed Consensus System (Subnet): Toda a rede consiste em várias sub-redes, cada uma das quais mantém um conjunto de caixas e chega a um consenso através do mecanismo de assinatura BLS.
  • Modelo de invocação assíncrona: o Canister se comunica com o Canister por meio de mensagens assíncronas, suporta execução sem bloqueio e tem paralelismo natural.
  • Hospedagem on-chain: suporta contratos inteligentes para hospedar diretamente páginas front-end, mapeamento DNS nativo e é a primeira plataforma blockchain que suporta navegadores para acessar diretamente dApps;
  • O sistema tem funções completas: ele tem APIs do sistema, como atualização a quente on-chain, autenticação de identidade, aleatoriedade distribuída e temporizador, que é adequado para implantação complexa de serviços on-chain.

  O ICP escolhe um paradigma de sistema operacional de plataforma pesada, empacotamento integrado e forte controle de plataforma, e tem um "sistema operacional blockchain" que integra consenso, execução, armazenamento e acesso, enfatizando recursos completos de hospedagem de serviços e expandindo o limite do sistema para uma plataforma de hospedagem Web3 full-stack.

  Além disso, os projetos de computação paralela de outros paradigmas do Modelo de Ator podem ser consultados na tabela a seguir:

  

  5. Resumo e prospectCom

  base nas diferenças entre arquitetura de máquina virtual e sistema de linguagem, as soluções de computação paralela blockchain podem ser divididas em duas categorias: cadeia de aprimoramento paralelo EVM e cadeia de arquitetura paralela nativa (não-EVM).

  Com base na manutenção da compatibilidade do ecossistema EVM/Solidity, o primeiro alcança maior taxa de transferência e recursos de processamento paralelo através da otimização profunda da camada de execução, o que é adequado para cenários que desejam herdar ativos Ethereum e ferramentas de desenvolvimento e alcançar avanços de desempenho ao mesmo tempo. Os projetos representativos incluem:

  • Monad: Implementa um modelo de execução paralela otimista compatível com EVM por meio de gravação diferida e deteção de conflitos de tempo de execução, cria gráficos de dependência e agenda a execução após a conclusão do consenso.
  • MegaETH: abstrai cada conta/contrato em uma micro-VM independente e implementa agendamento paralelo no nível da conta altamente dissociado com base em mensagens assíncronas e gráficos dependentes do estado.
  • Pharos: Crie uma arquitetura de malha rollup para obter processamento paralelo no nível do sistema entre processos por meio de pipelines assíncronos e módulos SPN.
  • Reddio: Usa a arquitetura zkRollup + GPU para acelerar o processo de verificação off-chain do zkEVM através da geração de SNARK em lote e melhorar a taxa de transferência de verificação.

  Este último se livra completamente das limitações da compatibilidade do Ethereum e redesenha o paradigma de execução da máquina virtual, modelo de estado e mecanismo de agendamento para alcançar a simultaneidade nativa de alto desempenho. As subclasses típicas incluem:

  • Solana (SVM): um modelo de execução paralela no nível da conta baseado em declarações de acesso à conta e agendamento de gráficos de conflitos estáticos;
  • Sui / Aptos (sistema MoveVM): Baseado no modelo de objeto de recurso e no sistema de tipos, ele suporta análise estática em tempo de compilação e realiza paralelismo no nível do objeto.
  • Sei V2 (rota do Cosmos SDK): introduz um mecanismo de correspondência multi-threaded e otimização de simultaneidade de máquina virtual na arquitetura Cosmos, que é adequado para aplicações transacionais de alta frequência.
  • Combustível (arquitetura UTXO + Sway): Paralelismo em nível de transação através da análise estática do conjunto de entrada UTXO, combinando uma camada de execução modular com uma linguagem de contrato inteligente personalizada Sway;

  Além disso, como um sistema paralelo mais generalizado, o Ator Model constrói um paradigma de execução on-chain de "operação independente multiagente + colaboração orientada por mensagem" através de um mecanismo de agendamento de processo assíncrono baseado em Wasm ou VMs personalizadas. Projetos representativos incluem:

  • AO (Arweave AO): Construção de um sistema de microkernel assíncrono on-chain baseado no tempo de execução persistente do agente orientado por armazenamento;
  • ICP (Internet Computer): usa o agente conteinerizado (Canister) como a menor unidade para alcançar uma execução assíncrona e altamente escalável através da coordenação de sub-rede.
  • Cartesi: Apresenta o sistema operacional Linux como um ambiente de computação off-chain para fornecer um caminho de verificação on-chain para resultados de computação confiáveis, adequado para cenários de aplicativos complexos ou que consomem muitos recursos.

  Com base na lógica acima, podemos resumir o atual esquema de cadeia pública de computação paralela em uma estrutura de classificação, como mostrado na figura a seguir:

  

  De uma perspetiva de dimensionamento mais ampla, a fragmentação e o rollup (L2) se concentram no dimensionamento horizontal por meio de fragmentação de estado ou execução off-chain, enquanto cadeias de computação paralelas (por exemplo, Monad, Sui, Solana) e sistemas orientados a atores (por exemplo, AO, ICP) reconstroem diretamente o modelo de execução e alcançam paralelismo nativo dentro da cadeia ou na camada do sistema. O primeiro melhora a taxa de transferência intra-cadeia através de máquinas virtuais multi-threaded, modelos de objeto, análise de conflitos de transações, etc.; Este último toma o processo/agente como a unidade básica e adota modos de execução assíncronos e orientados por mensagem para alcançar a operação simultânea de vários agentes. Em contraste, sharding e rollups são mais como "dividir a carga em várias cadeias" ou "terceirizar off-chain", enquanto o modelo de cadeia paralela e ator está "liberando o potencial de desempenho do próprio motor de execução", refletindo uma evolução arquitetônica mais completa.

  Computação paralela vs arquitetura de compartilhamento vs escalonamento de rollup vs comparação de caminho de escala orientada ao ator

  

  Deve-se salientar que a maioria das cadeias de arquitetura paralela nativas entraram na fase de lançamento da mainnet, embora o ecossistema geral de desenvolvedores ainda seja difícil de comparar com o sistema Solidity do sistema EVM, mas os projetos representados por Solana e Sui, com sua arquitetura de execução de alto desempenho e a prosperidade gradual das aplicações ecológicas, tornaram-se as principais cadeias públicas às quais o mercado presta grande atenção.

  Em contraste, embora o ecossistema Ethereum Rollup (L2) tenha entrado no estágio de "10.000 cadeias ao mesmo tempo" ou mesmo "sobrecapacidade", a atual cadeia de aprimoramento paralelo EVM mainstream ainda está geralmente no estágio testnet, e ainda não foi verificada pelo ambiente mainnet real, e sua capacidade de dimensionamento e estabilidade do sistema ainda precisam ser testadas. Resta saber se esses projetos podem melhorar significativamente o desempenho do EVM e impulsionar saltos ecológicos sem sacrificar a compatibilidade, ou se eles podem diferenciar ainda mais a liquidez e os recursos de desenvolvimento do Ethereum.