Panorama da trilha de computação paralela Web3: a melhor solução para escalonamento 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 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:

• Escalonamento aprimorado de execução: Melhora os recursos de execução in situ, como paralelismo, GPU e multi-core
• Escalonamento isolado de estado: Estado/fragmento dividido horizontalmente, por exemplo, fragmentos, UTXO e multi-sub-redes
• Escalonamento terceirizado off-chain: Colocando a execução fora da cadeia, como rollups, Dimensionamento de desacoplamento de estrutura de coprocessador e DA
• : Arquitetura modular e operação colaborativa, como cadeia de módulos, sequenciador compartilhado, Rollup Mesh
• Dimensionamento simultâneo assíncrono: Modelo de ator, isolamento de processo, orientado por mensagens, como agente, cadeia assíncrona multi-thread

  A solução de escalonamento de blockchain inclui: computação paralela on-chain, rollup, sharding, módulo DA, estrutura modular, sistema de ator, compactação de prova 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 multicamada e combinação de módulos". Este artigo se concentra nos 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 dimensionamento 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 agendamento está ficando cada vez mais alta e a complexidade de programação e a dificuldade de implementação também estão ficando cada vez mais altas.

  • Nível da conta: Representa o projeto
  • Nível do objeto: Representa o projeto Sui
  • Nível da 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 de 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 de forma independente 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 fragmentos pertence ao mecanismo de simultaneidade no nível do sistema, não à computação paralela intra-cadeia. Eles alcançam o dimensionamento "executando várias cadeias/domínios de execução em paralelo", em vez de aumentar o paralelismo em um único bloco/máquina virtual. Esse tipo de solução de dimensionamento não é o foco deste artigo, mas ainda o usaremos para comparar as semelhanças e diferenças nos conceitos de arquitetura.

  

  2. Cadeia de aprimoramento paralelo EVM: 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 dimensionamento, 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 contrato inteligente com maior 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 dimensionamento e evolução como um caminho fundamental que leva em consideração 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 com a execução diferida e a decomposição de estado, respectivamente, para construir uma arquitetura de processamento paralelo EVM para cenários de alta simultaneidade e alto rendimento.

  Análise

  de computação paralela da MonadMonad

  é uma blockchain de camada 1 de alto desempenho redesenhada para a Ethereum Virtual Machine (EVM), com base 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 obter otimização de ponta a ponta.

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

  Pipelining é o conceito básico de 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 obter processamento simultâneo entre blocos. O resultado é maior taxa de transferência e latência reduzida. Esses estágios incluem: Propor, Consenso, Execução e Confirmação.

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

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

  Design principal:

  O
  • processo de consenso (camada de consenso) é responsável apenas por classificar 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, 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 da transação.

  Mecanismo de execução:

  • O Monad executa com otimismo todas as transações em paralelo, assumindo que a maioria das transações é sem estado e livre de conflitos.
  • Execute também um "Detector de Conflitos" para monitorar se o mesmo estado (por exemplo, conflitos de leitura/gravação) é acessado entre as transações.
  • Se um conflito for detectado, a transação conflitante será serializada e executada novamente 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 o paralelismo adiando o estado de gravação e detectando dinamicamente conflitos durante a execução, que é mais como 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 da Monad, e o MegaETH está 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 principal objetivo de design é desconstruir a lógica da conta, o ambiente de execução e o isolamento de estado na menor unidade que pode ser agendada de forma independente para obter execução de alta simultaneidade e 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 direcionado e acíclico) e o mecanismo de sincronização modular constroem em conjunto um sistema de execução paralelo para "threading intra-chain".

  Arquitetura de micro-VM: Contas são threads O

  MegaETH apresenta o modelo de execução de "uma micro-VM por conta", que "threads" o ambiente de execução e fornece uma unidade mínima de isolamento 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 de forma independente, armazenado de forma independente e naturalmente paralelo.

  State Dependency DAG: um mecanismo

  de agendamento baseado em gráficos A MegaETH construiu um sistema de agendamento DAG com base no relacionamento 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 livres de conflitos podem ser executadas diretamente em paralelo e as transações dependentes serão agendadas e classificadas em série ou adiadas em ordem topológica. Os gráficos de dependência garantem a consistência do 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 de mensagens assíncronas do Modelo de 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 = passagem do 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 micro-máquina virtual conta por 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íncronas. É uma plataforma de computação paralela que é redesenhada a partir de todas as dimensões da "estrutura de contas→ 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 última geração.

  O MegaETH escolheu o caminho de refatoração: ele abstrai completamente contas e contratos em VMs independentes e libera o potencial de paralelismo final por meio do agendamento de execução assíncrona. Teoricamente, o MegaETH tem um limite paralelo mais alto, mas também é mais difícil controlar a complexidade e é mais como um sistema operacional superdistribuí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 do estado, quebrando a limitação de cadeia única e escalando na 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 da blockchain.

  Projetos de computação paralela, como Monad e MegaETH, concentram-se principalmente no caminho de otimização da taxa de transferência, com o objetivo principal de melhorar o TPS on-chain e alcançar o processamento paralelo no nível da transação ou da conta por meio de execução diferida e arquiteturas de micro-VM. A Pharos Network é uma rede blockchain L1 paralela modular e full-stack, e seu sistema de computação paralela central é chamado de "Rollup Mesh". Essa arquitetura oferece suporte a ambientes de várias máquinas virtuais (EVM e Wasm) por meio da sinergia de rede principal e redes de processamento especial (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. Pipeline 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 o 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 oferece suporte a ambientes de máquina virtual EVM e WASM, permitindo que os desenvolvedores escolham o ambiente de execução certo para suas necessidades. Essa arquitetura de VM dupla não apenas aumenta a flexibilidade do sistema, mas também aumenta o processamento de transações por meio 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 aplicativos. Com SPNs, o Pharos permite a alocação dinâmica de recursos e o processamento paralelo de tarefas, aprimorando ainda mais a escalabilidade e o desempenho do sistema.
  4. Consenso modular e restaking: o Pharos apresenta 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 os SPNs por meio do protocolo de retaking.

  Além disso, o Pharos reconstrói o modelo de execução a partir da camada inferior do mecanismo de armazenamento por meio da árvore Merkle de várias versões, codificação Delta, endereçamento versionado e tecnologia ADS Pushdown, e lança o Pharos Store, um mecanismo de armazenamento de alto desempenho para o blockchain nativo, para obter 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 na computação paralela EVM, 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 de 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ções. Granularidade paralela no nível da transação + nível de operação (opcode de execução multithreaded). 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 o 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 de 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 em nível de instrução" de máquinas virtuais EVM tradicionais para um ambiente de tempo de execução paralelo nativo de GPU. O mecanismo principal é compilar dinamicamente o bytecode EVM em tarefas paralelas CUDA e executar o fluxo de instruções por meio do multi-core da GPU, de modo a quebrar o gargalo sequencial do EVM no nível mais baixo. Granularidade paralela que pertence ao ILP (Paralelismo no Nível de Instrução). 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 no nível da instrução, que está mais próximo da refatoração subjacente do mecanismo da máquina virtual. Atualmente, está na fase de conceito, com um whitepaper e um esboço arquitetônico publicados, e ainda não há SDK ou rede principal.

  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 da Aspect, mantendo a compatibilidade com EVM. Ele usa a granularidade de invocação do 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 obter desacoplamento lógico, invocação assíncrona e execução paralela no nível do módulo. Mais atenção é dada à capacidade de composição e arquitetura modular da camada de execução. O conceito fornece novas ideias para aplicações complexas de vários módulos 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. Por outro lado, as cadeias de arquitetura de computação paralela nativas, como Solana (SVM), MoveVM (Sui, Aptos) e Sei v2 criadas no Cosmos SDK, 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 da transação é suportado.
  • As máquinas virtuais são otimizadas para simultaneidade: o mecanismo Sealevel da Solana suporta nativamente a execução multithread; O MoveVM pode realizar análises de gráfico de simultaneidade estática; O Sei v2 integra um mecanismo de correspondência multithread com um módulo de VM paralelo.

  Claro, esse 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 com estado, limites de simultaneidade, ciclos de vida de objetos, etc., que apresentam requisitos mais altos para entender limites e paradigmas de desenvolvimento.

  3.1 O princípio do motor paralelo ao nível do mar de Solana e SVM

  O modelo de execução Sealevel da Solana é um mecanismo de agendamento paralelo de contas, que é o mecanismo principal usado pela Solana para realizar a execução de transações paralelas dentro da cadeia e alcança simultaneidade de alto desempenho no nível do contrato inteligente por meio do mecanismo de "declaração de conta + agendamento estático + execução multithread". 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 de computação paralela subsequentes e é um paradigma de referência para design paralelo de Camada 1 de alto desempenho.

  Mecanismo principal:

  1. Listas explícitas de acesso à 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. Detecçã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→ executar em série em ordem dependente;
  • O agendador aloca transações para threads diferentes 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 de chamada cruzada.

  O Sealevel é o mecanismo de agendamento de execução paralela da 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 da Solana.

  O Eclipse é um projeto que implanta VMs Solana em cadeias modulares, como Ethereum L2 ou Celestia, aproveitando o mecanismo de execução paralela da Solana como a camada de execução de rollup. O Eclipse é um dos primeiros projetos a propor a desanexação da 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" da 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. Construa 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 do agendamento usa SVM + Sealeve. A Neon se inclina mais para a categoria Modular Blockchain do que para a inovação em computação paralela.

  Em suma, Solana e SVMs contam com o mecanismo de execução Sealevel, e a filosofia de agendamento baseada em sistema operacional da 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: Orientado a Recursos e Objetos

  MoveVM é uma máquina virtual de contrato inteligente projetada para segurança de recursos on-chain e execução paralela, e sua linguagem principal, 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 e ciclos de vida claros. 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 objetos da SuiOs

  recursos de computação paralela da Sui derivam de sua abordagem exclusiva 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, a Sui construiu um modelo centrado em objetos baseado no "objeto", que funciona com o sistema de tipos lineares 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 do Sui. O Sui abstrai todo o estado da cadeia em objetos separados, cada um com um ID exclusivo, um proprietário claro (conta ou contrato) e uma definição de tipo. Esses objetos não compartilham estado entre si 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. Esse design 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 suporte do sistema de tipos lineares da linguagem Move. Ele permite que o sistema agende transações a 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. Comparado com a detecção de conflitos e reversão de tempos de execução tradicionais, o mecanismo de análise estática do Sui reduz muito a complexidade do agendamento e melhora a eficiência da execução, que é a chave para alcançar alto rendimento e recursos de processamento paralelo determinístico.

  O Sui divide o espaço de estado 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 detecção de tempo de execução de cadeias tradicionais, a Sui alcançou melhorias significativas na eficiência da execução, determinismo do sistema e utilização de recursos.

  Mecanismo de execução Block-STM da AptosAptos

  é uma blockchain Layer1 de alto desempenho baseada na linguagem Move, e sua capacidade de execução paralela é derivada principalmente da estrutura Block-STM (Block-level Software Transactional Memory) autodesenvolvida. Ao contrário da estratégia de Sui de "paralelismo estático em tempo de compilação", o Block-STM pertence ao mecanismo de escalonamento 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) acessada por eles.
  • Fase de validação: O sistema verifica o resultado da execução: se houver um conflito de leitura e gravação entre duas transações (por exemplo, Tx1 lê o estado de gravação 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 novas tentativas", que é adequado para cenários de processamento em lote de transações on-chain com uso intensivo de estado e logicamente complexos, e é o núcleo de computação paralela para a 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 de alta frequência controlável, é um estilo de engenheiro de hardware, para executar a cadeia como hardware (execução paralela de nível de hardware); O Aptos é um tolerante a falhas do sistema, mais como um "mecanismo 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 Dimensionamento paralelo do Cosmos SDK

  O Sei V2 é uma cadeia pública transacional de alto desempenho construída com base no Cosmos SDK, e sua capacidade de paralelismo se reflete principalmente em dois aspectos: o mecanismo de correspondência multithread (Parallel Matching Engine) e a otimização de execução paralela da camada de máquina virtual, projetada para atender a cenários de transações on-chain de alta frequência e baixa latência, como DEX de livro de pedidos, infraestrutura de troca on-chain, etc.

  Mecanismo de paralelismo principal:

  1. mecanismo de correspondência paralela: O SEI V2 introduz um caminho de execução multithread na lógica de correspondência de pedidos, dividindo o livro de pedidos pendente e a lógica de correspondência no nível do 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, o 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 maior controle de taxa de transferência.
  3. Consenso paralelo e escalonamento 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 Reformador de modelo UTXO Fuel Fuel

  é uma camada de execução de alto desempenho projetada com base na arquitetura modular do Ethereum, e seu mecanismo de paralelismo principal é derivado do modelo UTXO (Unspent Transaction Output) aprimorado. Ao contrário do modelo de conta da Ethereum, o Fuel usa uma estrutura UTXO para representar ativos e estados, que é inerentemente isolada do estado, facilitando a determinação de quais transações podem ser executadas com segurança em paralelo. Além disso, a Fuel apresenta sua linguagem de contrato inteligente autodesenvolvida 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 obter um agendamento paralelo eficiente e seguro no nível da transação. É 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 de 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 por meio 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 desacoplados uns dos outros e tem forte escalabilidade e tolerância a falhas assíncronas. Os 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 multitarefa e orquestração lógica complexa.

  Embora o design do Modelo de Ator seja semelhante ao 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", em que cada agente é executado de forma independente, mantém o estado de forma independente e interage de maneira orientada por mensagens. O sharding, 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 como um "sistema operacional de agente distribuído" no mundo Web3, enquanto o sharding é uma solução de dimensionamento estrutural para recursos de processamento de transações on-chain. Ambos alcançam paralelismo, mas têm diferentes pontos de partida, metas e arquiteturas de execução.

  4.1 AO (Arweave), um computador superparalelo 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 larga escala.

  Principais recursos da arquitetura:

  • Arquitetura de processo: Cada agente é chamado de processo, com estado independente, agendador independente e lógica de execução;
  • Sem estrutura de blockchain: AO não é uma cadeia, mas uma camada de armazenamento descentralizada + mecanismo de execução orientado a mensagens multiagente baseado em Arweave;
  • Sistema de agendamento de mensagens assíncronas: os processos se comunicam entre si por meio de mensagens, adotam um modelo de operação assíncrona sem bloqueio e oferecem suporte natural à expansão simultânea.
  • Armazenamento de estado permanente: Todos os estados do agente, registros de mensagens e instruções são registrados permanentemente no Arweave, garantindo total auditabilidade e transparência descentralizada.
  • Nativo do 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 segue o caminho final de "agente nativo + driver de armazenamento + arquitetura sem cadeia", enfatizando a flexibilidade e o desacoplamento de módulos, e é uma "estrutura de microkernel na cadeia construída sobre a camada de armazenamento", com o limite do sistema diminuindo deliberadamente, enfatizando a computação leve + estrutura de controle combinável.

  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 oferecer suporte a hospedagem de serviço completo, vinculação de nomes de domínio e arquitetura sem servidor.

  Principais recursos de arquitetura:

  • Arquitetura de caixa (contêineres como agentes): cada caixa é um agente em execução em uma VM Wasm com recursos independentes de estado, código e agendamento assíncrono;
  • Sistema de Consenso Distribuído de Sub-rede (Sub-rede): Toda a rede consiste em várias sub-redes, cada uma das quais mantém um conjunto de caixas e chega a um consenso por meio do mecanismo de assinatura BLS.
  • Modelo de invocação assíncrona: o Canister se comunica com o Canister por meio de mensagens assíncronas, dá suporte à execução sem bloqueio e tem paralelismo natural.
  • Hospedagem na web on-chain: Ele 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: Possui 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 referidos na tabela a seguir:

  

  5. Resumo e PerspectivaCom base

  nas diferenças entre a arquitetura de máquina virtual e o 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 por meio 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 obter 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 adiada e detecção de conflitos em 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 microVM independente e implementa o agendamento paralelo no nível da conta altamente desacoplado com base em mensagens assíncronas e gráficos dependentes de estado.
  • Pharos: crie uma arquitetura de malha de 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 por meio da geração de SNARK em lote e melhorar a taxa de transferência de verificação.

  Este último elimina completamente as limitações de compatibilidade do Ethereum e redesenha o paradigma de execução da máquina virtual, modelo de estado e mecanismo de agendamento para obter 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áfico de conflito estático;
  • Sui / Aptos (sistema MoveVM): com base no modelo de objeto de recurso e no sistema de tipos, ele dá suporte à análise estática em tempo de compilação e realiza o paralelismo no nível do objeto.
  • Sei V2 (rota do Cosmos SDK): apresenta um mecanismo de correspondência multithread e otimização de simultaneidade de máquina virtual na arquitetura do Cosmos, que é adequada para aplicativos transacionais de alta frequência.
  • Fuel (arquitetura UTXO + Sway): Paralelismo em nível de transação por meio de 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 Modelo de Ator cria um paradigma de execução on-chain de "operação independente multiagente + colaboração orientada por mensagens" por meio de um mecanismo de agendamento de processo assíncrono baseado em Wasm ou VMs personalizadas. Os projetos representativos incluem:

  • AO (Arweave AO): Construindo um sistema de microkernel assíncrono on-chain baseado no tempo de execução do agente orientado por armazenamento persistente;
  • ICP (Internet Computer): usa o agente conteinerizado (Canister) como a menor unidade para obter execução assíncrona e altamente escalável por meio 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, adequados para cenários de aplicativos complexos ou com uso intensivo de recursos.

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

  

  De uma perspectiva de dimensionamento mais ampla, o sharding e o rollup (L2) se concentram no dimensionamento horizontal por meio de fragmentação de estado ou execução fora da cadeia, enquanto cadeias de computação paralela (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 por meio de máquinas virtuais multi-threaded, modelos de objetos, análise de conflitos de transações, etc.; Este último assume o processo/agente como unidade básica e adota modos de execução assíncronos e orientados por mensagens para obter operação simultânea multiagente. Em contraste, sharding e rollups são mais como "dividir a carga em várias cadeias" ou "terceirizar off-chain", enquanto a cadeia paralela e o modelo de ator estão "liberando o potencial de desempenho do próprio mecanismo de execução", refletindo uma evolução arquitetônica mais completa.

  Computação paralela vs arquitetura de fragmentação vs escalonamento de rollup vs comparação de caminho de escalonamento orientado a ator

  Deve-se ressaltar que a maioria das cadeias de arquitetura paralela nativas entrou no estágio de lançamento da rede principal, 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 de aplicativos ecológicos, 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 de uma só vez" ou mesmo "excesso de capacidade", a atual cadeia de aprimoramento paralelo EVM ainda está geralmente no estágio de rede de teste e ainda não foi verificada pelo ambiente real da rede principal, e sua capacidade de dimensionamento e estabilidade do sistema ainda precisam ser testadas mais detalhadamente. Resta saber se esses projetos podem melhorar significativamente o desempenho do EVM e impulsionar saltos ecológicos sem sacrificar a compatibilidade, ou se podem diferenciar ainda mais a liquidez e os recursos de desenvolvimento do Ethereum.