Web3 Parallel Computing Track Panorama: la migliore soluzione per la scalabilità nativa?

Autore: 0xjacobzhao e ChatGPT 4oIl

"Trilemma Blockchain" di "sicurezza", "decentralizzazione" e "scalabilità" della blockchain rivela il compromesso essenziale nella progettazione dei sistemi blockchain, ovvero è difficile per i progetti blockchain raggiungere "sicurezza estrema, tutti possono partecipare e un'elaborazione ad alta velocità" allo stesso tempo. In risposta all'eterno tema della "scalabilità", le principali soluzioni di scalabilità blockchain sul mercato sono suddivise in base a paradigmi, tra cui:

• Scalabilità potenziata dall'esecuzione: migliora le capacità di esecuzione in situ, come parallelismo, GPU e multi-core
• Scalabilità isolata dallo stato: suddivisione orizzontale di stato/shard, ad esempio shard, UTXO e multi-subnet
• Scalabilità esternalizzata off-chain: messa dell'esecuzione off-chain, come rollup, Ridimensionamento del disaccoppiamento della struttura del coprocessore e DA
• : architettura modulare e operazioni collaborative, come catena di moduli, sequenziatore condiviso, Rollup Mesh
• Ridimensionamento simultaneo asincrono: modello ad attore, isolamento del processo, basato su messaggi, come agente, catena asincrona multi-thread

  La soluzione di scalabilità blockchain include: calcolo parallelo on-chain, rollup, sharding, modulo DA, struttura modulare, sistema ad attori, compressione zk proof, architettura stateless, ecc., che copre più livelli di esecuzione, stato, dati e struttura, ed è un sistema di scalabilità completo di "collaborazione multilivello e combinazione di moduli". Questo articolo è incentrato sui metodi di scalabilità che integrano il calcolo parallelo.

  Parallelismo intra-chain, che si concentra sull'esecuzione parallela di transazioni/istruzioni intra-blocco. Secondo il meccanismo parallelo, i suoi metodi di ridimensionamento possono essere suddivisi in cinque categorie, ognuna delle quali rappresenta una diversa ricerca di prestazioni, modello di sviluppo e filosofia dell'architettura, e la granularità parallela sta diventando sempre più fine, l'intensità del parallelismo sta diventando sempre più alta, la complessità della pianificazione sta diventando sempre più alta e anche la complessità della programmazione e la difficoltà di implementazione stanno diventando sempre più elevate.

  • Livello di account: Rappresenta il progetto Livello di
  • oggetto: Rappresenta il progetto Sui
  • Livello di transazione: Rappresenta il progetto Monad, Aptos
  • Livello di chiamata / MicroVM : Livello di istruzione MegaETH
  :
  • GatlingX

  Il modello di concorrenza asincrona off-chain, rappresentato dall'Actor / Actor Model, appartiene ad un altro paradigma di calcolo parallelo, come sistema di messaggi cross-chain/asincrono (modello di sincronizzazione non a blocchi), ogni agente viene eseguito in modo indipendente come un "processo agente", messaggi asincroni in modalità parallela, event-driven, nessuna schedulazione sincrona, progetti rappresentativi come AO, ICP, Cartesi, ecc.

  Il noto schema di rollup o shard scaling appartiene al meccanismo di concorrenza a livello di sistema, non al calcolo parallelo intra-chain. Ottengono la scalabilità "eseguendo più catene/domini di esecuzione in parallelo", piuttosto che aumentando il parallelismo all'interno di un singolo blocco/macchina virtuale. Questo tipo di soluzione di ridimensionamento non è l'obiettivo di questo articolo, ma lo useremo comunque per confrontare le somiglianze e le differenze nei concetti architettonici.

  

  2. Catena di miglioramento parallelo EVM: rottura del limite delle prestazioni in compatibilità

  Dallo sviluppo dell'architettura di elaborazione seriale di Ethereum, è stata sottoposta a diversi tentativi di scalabilità come lo sharding, il rollup e l'architettura modulare, ma il collo di bottiglia del throughput del livello di esecuzione non è ancora stato fondamentalmente superato. Ma allo stesso tempo, EVM e Solidity sono ancora le piattaforme di smart contract con la maggior base di sviluppatori e potenziale ecologico. Pertanto, la catena di miglioramento parallela EVM sta diventando una direzione importante per un nuovo ciclo di scalabilità ed evoluzione come percorso chiave che tiene conto della compatibilità ecologica e del miglioramento delle prestazioni di esecuzione. Monad e MegaETH sono i progetti più rappresentativi in questa direzione, a partire rispettivamente dall'esecuzione differita e dalla scomposizione dello stato, per costruire un'architettura di elaborazione parallela EVM per scenari ad alta concorrenza e ad alto rendimento.

  Analisi del calcolo parallelo di MonadMonad

  è una blockchain Layer1 ad alte prestazioni riprogettata per la Ethereum Virtual Machine (EVM), basata sul concetto parallelo di base del pipelining, con esecuzione asincrona a livello di consenso e concorrenza ottimistica a livello di esecuzione Esecuzione parallela) 。 Inoltre, a livello di consenso e di archiviazione, Monad ha introdotto rispettivamente il protocollo BFT ad alte prestazioni (MonadBFT) e un sistema di database dedicato (MonadDB) per ottenere l'ottimizzazione end-to-end.

  Pipelining: meccanismo di esecuzione parallela della pipeline a più fasi

  Il pipelining è il concetto di base dell'esecuzione parallela di Monad e la sua idea centrale è quella di suddividere il processo di esecuzione della blockchain in più fasi indipendenti ed elaborare queste fasi in parallelo per formare un'architettura di pipeline tridimensionale, ogni fase viene eseguita su thread o core indipendenti per ottenere un'elaborazione simultanea cross-block. Il risultato è un aumento della velocità effettiva e una riduzione della latenza. Queste fasi includono: Proposta, Consenso, Esecuzione e Commit.

  Esecuzione asincrona: consenso - L'esecuzione è disaccoppiata in modo asincronoSulle

  catene tradizionali, il consenso e l'esecuzione delle transazioni sono spesso processi sincroni e questo modello seriale limita fortemente la scalabilità delle prestazioni. Monad implementa il livello di consenso asincrono, il livello di esecuzione asincrono e lo storage asincrono attraverso l'"esecuzione asincrona". Riduci significativamente il tempo di blocco e la latenza di conferma, rendendo il sistema più resiliente, l'elaborazione più segmentata e l'utilizzo delle risorse.

  Core design:

  il
  • processo di consenso (livello di consenso) è responsabile solo dello smistamento delle transazioni e non esegue la logica del contratto.
  • Il processo di esecuzione (livello di esecuzione) viene attivato in modo asincrono dopo il completamento del consenso.
  • Dopo che il consenso è stato completato, entrerà immediatamente nel processo di consenso del blocco successivo, senza attendere il completamento dell'esecuzione.

  Esecuzione parallela ottimistica: Esecuzione parallela ottimisticaEthereum tradizionale

  adotta un modello rigorosamente seriale per l'esecuzione delle transazioni per evitare conflitti di stato. Monad, d'altra parte, adotta una strategia di "esecuzione parallela ottimistica" per aumentare significativamente la velocità di elaborazione delle transazioni.

  Meccanismo di esecuzione:

  • Monad esegue ottimisticamente tutte le transazioni in parallelo, supponendo che la maggior parte delle transazioni siano stateless e prive di conflitti.
  • Esegui anche un "Conflict Detector" per monitorare se si accede allo stesso stato (ad es. conflitti di lettura/scrittura) tra le transazioni.
  • Se viene rilevato un conflitto, la transazione in conflitto viene serializzata e rieseguita per garantire che lo stato sia corretto.

  Monad ha scelto un percorso compatibile: spostare il minor numero possibile di regole EVM, ottenere il parallelismo rinviando lo stato di scrittura e rilevando dinamicamente i conflitti durante l'esecuzione, che è più simile a una versione performance di Ethereum, con un livello di maturità che facilita la migrazione all'ecosistema EVM, ed è un acceleratore parallelo nel mondo EVM.

  La risoluzione del meccanismo di calcolo parallelo di MegaETH

  è diversa dal posizionamento L1 di Monad, e MegaETH è posizionato come un livello di esecuzione parallela modulare ad alte prestazioni compatibile con EVM, che può essere utilizzato come catena pubblica L1 indipendente, come livello di miglioramento dell'esecuzione o componente modulare su Ethereum. L'obiettivo principale della progettazione è quello di decostruire la logica dell'account, l'ambiente di esecuzione e l'isolamento dello stato nell'unità più piccola che può essere pianificata in modo indipendente per ottenere un'esecuzione ad alta concorrenza e una capacità di risposta a bassa latenza all'interno della catena. L'innovazione chiave proposta da MegaETH è che l'architettura Micro-VM + State Dependency DAG (directed and acyclic state dependency graph) e il meccanismo di sincronizzazione modulare costruiscono congiuntamente un sistema di esecuzione parallela per il "threading intra-chain".

  Architettura Micro-VM: gli account sono thread MegaETH

  introduce il modello di esecuzione di "una micro-VM per account", che "threada" l'ambiente di esecuzione e fornisce un'unità di isolamento minima per la pianificazione parallela. Queste macchine virtuali comunicano tra loro tramite messaggistica asincrona anziché chiamate sincrone e un numero elevato di macchine virtuali può essere eseguito in modo indipendente, archiviato in modo indipendente e naturalmente parallelo.

  State Dependency DAG: un meccanismo di schedulazione basato su grafici

  MegaETH ha costruito un sistema di pianificazione DAG basato sulla relazione di accesso allo stato dell'account e il sistema mantiene un grafico delle dipendenze globale in tempo reale e quali account vengono modificati e quali account vengono letti per ogni transazione sono tutti modellati in dipendenze. Le transazioni prive di conflitti possono essere eseguite direttamente in parallelo e le transazioni dipendenti verranno pianificate e ordinate in serie o differite in ordine topologico. I grafici delle dipendenze garantiscono la coerenza dello stato e le scritture non duplicate durante l'esecuzione parallela.

  Il

  meccanismo di esecuzione e callback asincrono

  MegaETH si basa sul paradigma di programmazione asincrona, simile al passaggio asincrono di messaggi dell'Actor Model, per risolvere il problema delle tradizionali chiamate seriali EVM. Le chiamate al contratto sono asincrone (esecuzione non ricorsiva) e quando viene chiamato il contratto A -> B -> C, ogni chiamata è asincrona senza bloccare l'attesa; Lo stack di chiamate viene espanso in un grafico delle chiamate asincrone. Elaborazione delle transazioni = attraversamento del grafo asincrono + risoluzione delle dipendenze + pianificazione parallela.

  Nel complesso, MegaETH rompe il tradizionale modello di macchina a stati a thread singolo EVM, implementa l'incapsulamento di micro-macchine virtuali su base account-by-account, esegue la pianificazione delle transazioni attraverso grafici dipendenti dallo stato e sostituisce lo stack di chiamate sincrone con un meccanismo di messaggistica asincrona. Si tratta di una piattaforma di calcolo parallelo che è stata ridisegnata dalle dimensioni complete di "struttura del conto→ architettura di pianificazione, → processo di esecuzione", fornendo una nuova idea a livello di paradigma per la costruzione di un sistema on-chain ad alte prestazioni di prossima generazione.

  MegaETH ha scelto la strada del refactoring: astrae completamente account e contratti in VM indipendenti e libera il massimo potenziale di parallelismo attraverso la pianificazione dell'esecuzione asincrona. In teoria, MegaETH ha un limite parallelo più alto, ma è anche più difficile da controllare la complessità ed è più simile a un sistema operativo super-distribuito secondo il concetto di Ethereum.

  

  Monad e MegaETH Entrambi hanno concetti di progettazione diversi dallo sharding: lo sharding divide orizzontalmente la blockchain in più sotto-catene indipendenti (shard), ognuna delle quali è responsabile di parte delle transazioni e dello stato, rompendo la limitazione della singola catena e scalando a livello di rete; D'altra parte, sia Monad che MegaETH mantengono l'integrità della singola catena, scalando orizzontalmente solo a livello di esecuzione, ed eseguendo scoperte di ottimizzazione in parallelo al limite della singola catena. Le due rappresentano due direzioni: il rafforzamento verticale e l'espansione orizzontale nel percorso di espansione della blockchain.

  I progetti di calcolo parallelo come Monad e MegaETH si concentrano principalmente sul percorso di ottimizzazione del throughput, con l'obiettivo principale di migliorare il TPS on-chain, e ottenere un'elaborazione parallela a livello di transazione o di account attraverso l'esecuzione differita e le architetture micro-VM. Pharos Network è una rete blockchain L1 parallela modulare e full-stack e il suo sistema di calcolo parallelo principale si chiama "Rollup Mesh". Questa architettura supporta ambienti multi-virtual machine (EVM e Wasm) attraverso la sinergia di mainnet e reti di elaborazione speciale (SPN) e integra tecnologie avanzate come zero-knowledge proofs (ZK) e ambienti di esecuzione trusted (TEE).

  Analisi del calcolo parallelo Rollup Mesh:

  1. Pipelining asincrono dell'intero ciclo di vita: Pharos disaccoppia le varie fasi di una transazione (come il consenso, l'esecuzione e l'archiviazione) e adotta l'elaborazione asincrona in modo che ogni fase possa essere eseguita in modo indipendente e in parallelo, migliorando così l'efficienza complessiva dell'elaborazione.
  2. Esecuzione parallela a due VM: Pharos supporta ambienti di macchine virtuali EVM e WASM, consentendo agli sviluppatori di scegliere l'ambiente di esecuzione giusto per le loro esigenze. Questa architettura a doppia VM non solo aumenta la flessibilità del sistema, ma aumenta anche l'elaborazione delle transazioni attraverso l'esecuzione parallela.
  3. Reti di elaborazione speciale (SPN): le SPN sono componenti chiave dell'architettura Pharos, simili a sottoreti modulari progettate per gestire tipi specifici di attività o applicazioni. Con gli SPN, Pharos consente l'allocazione dinamica delle risorse e l'elaborazione parallela delle attività, migliorando ulteriormente la scalabilità e le prestazioni del sistema.
  4. Consenso modulare e restaking: Pharos introduce un meccanismo di consenso flessibile che supporta più modelli di consenso (come PBFT, PoS, PoA) e consente la condivisione sicura e l'integrazione delle risorse tra la mainnet e gli SPN attraverso il protocollo di restaking.

  Inoltre, Pharos ricostruisce il modello di esecuzione dal livello inferiore del motore di archiviazione attraverso l'albero di Merkle multi-versione, la codifica Delta, l'indirizzamento con versioni e la tecnologia ADS Pushdown, e lancia Pharos Store, un motore di archiviazione ad alte prestazioni per la blockchain nativa, per ottenere un throughput elevato, una bassa latenza e forti capacità di elaborazione on-chain verificabili.

  In generale, l'architettura Rollup Mesh di Pharos raggiunge capacità di calcolo parallelo ad alte prestazioni attraverso un design modulare e un meccanismo di elaborazione asincrona.

  Oltre alle architetture di esecuzione parallela di Monad, MegaETH e Pharos, osserviamo anche che ci sono alcuni progetti sul mercato che esplorano il percorso applicativo dell'accelerazione GPU nel calcolo parallelo EVM, come importante complemento ed esperimento all'avanguardia dell'ecosistema parallelo EVM. Tra questi, Reddio e GatlingX sono due direzioni rappresentative:

  • Reddio è una piattaforma ad alte prestazioni che combina zkRollup e l'architettura di esecuzione parallela della GPU, e il suo fulcro risiede nella ricostruzione del processo di esecuzione EVM e nella realizzazione della parallelizzazione nativa del livello di esecuzione attraverso la pianificazione multi-thread, lo storage asincrono dello stato e l'esecuzione accelerata dalla GPU dei batch di transazioni. Granularità parallela a livello di transazione + livello di operazione (codice operativo di esecuzione multithread). È progettato per introdurre l'esecuzione batch multi-thread, il caricamento asincrono dello stato e la logica di transazione di elaborazione parallela della GPU (CUDA-Compatible Parallel EVM). Come Monad / MegaETH, anche Reddio si concentra sull'elaborazione parallela a livello di esecuzione, con la differenza che il motore di esecuzione viene ricostruito attraverso un'architettura parallela alla GPU, progettata per scenari ad alto throughput e ad alta intensità di calcolo come l'inferenza AI. GatlingX,
  • che si fa chiamare "GPU-EVM", propone un'architettura più radicale che tenta di migrare il modello di "esecuzione seriale a livello di istruzione" delle tradizionali macchine virtuali EVM in un ambiente di runtime parallelo nativo della GPU. Il meccanismo di base consiste nel compilare dinamicamente il bytecode EVM in attività parallele CUDA ed eseguire il flusso di istruzioni attraverso il multi-core GPU, in modo da interrompere il collo di bottiglia sequenziale dell'EVM al livello più basso. Granularità parallela che appartiene al parallelismo a livello di istruzione (ILP). Rispetto alla granularità parallela "a livello di transazione/a livello di account" di Monad / MegaETH, il meccanismo di parallelismo di GatlingX appartiene al percorso di ottimizzazione a livello di istruzione, che è più vicino al refactoring sottostante del motore della macchina virtuale. Attualmente è in fase di concetto, con un whitepaper e uno schizzo architettonico pubblicati, e non c'è ancora un SDK o una mainnet.

  Artela propone un concetto di design differenziato e parallelo. Con l'introduzione della macchina virtuale WebAssembly (WASM) con architettura EVM++, gli sviluppatori possono aggiungere ed eseguire dinamicamente estensioni on-chain utilizzando il modello di programmazione Aspect, mantenendo la compatibilità EVM. Utilizza la granularità dell'invocazione del contratto (funzione/estensione) come unità parallela minima e supporta l'inserimento di moduli di estensione (simile al "middleware collegabile") quando il contratto EVM è in esecuzione, in modo da ottenere il disaccoppiamento logico, l'invocazione asincrona e l'esecuzione parallela a livello di modulo. Maggiore attenzione è rivolta alla componibilità e all'architettura modulare del livello di esecuzione. Il concetto fornisce nuove idee per applicazioni multi-modulo complesse in futuro.

  3. Catena di architettura parallela nativa: il modello di esecuzione EVM di Ethereum, l'ontologia di esecuzione della VM ricostruita

  ,

  ha adottato un'architettura a thread singolo di "ordine di transazione completo + esecuzione seriale" sin dall'inizio della sua progettazione, con l'obiettivo di garantire la certezza e la coerenza dei cambiamenti di stato per tutti i nodi della rete. Tuttavia, questa architettura presenta un collo di bottiglia naturale nelle prestazioni, che limita la velocità effettiva e la scalabilità del sistema. Al contrario, le catene di architettura di calcolo parallelo native come Solana (SVM), MoveVM (Sui, Aptos) e Sei v2 basate su Cosmos SDK sono personalizzate per l'esecuzione parallela dal design sottostante e presentano i seguenti vantaggi:

  • Separazione naturale dei modelli di stato: Solana utilizza un meccanismo di dichiarazione del blocco dell'account, MoveVM introduce un modello di proprietà degli oggetti e Sei v2 si basa sulla classificazione del tipo di transazione. Viene realizzato il giudizio statico dei conflitti ed è supportata la programmazione simultanea a livello di transazione.
  • Le macchine virtuali sono ottimizzate per la concorrenza: il motore Sealevel di Solana supporta nativamente l'esecuzione multi-thread; MoveVM può eseguire l'analisi del grafo di concorrenza statica; Sei v2 integra un motore di corrispondenza multi-thread con un modulo VM parallelo.

  Naturalmente, questo tipo di catena parallela autoctona deve affrontare anche la sfida della compatibilità ecologica. Le architetture non EVM di solito richiedono nuovi linguaggi di sviluppo (come Move e Rust) e toolchain, che hanno determinati costi di migrazione per gli sviluppatori. Inoltre, gli sviluppatori devono padroneggiare una serie di nuovi concetti come i modelli di accesso stateful, i limiti di concorrenza, i cicli di vita degli oggetti, ecc., che pongono requisiti più elevati per comprendere le soglie e i paradigmi di sviluppo.

  3.1 Il principio del motore parallelo Sealevel di Solana e SVM

  Il modello di esecuzione Sealevel di Solana è un meccanismo di pianificazione parallela degli account, che è il motore principale utilizzato da Solana per realizzare l'esecuzione di transazioni parallele all'interno della catena, e raggiunge una concorrenza ad alte prestazioni a livello di smart contract attraverso il meccanismo di "dichiarazione dell'account + pianificazione statica + esecuzione multi-thread". Sealevel è il primo modello di esecuzione nel campo della blockchain a implementare con successo la pianificazione simultanea intra-chain in un ambiente di produzione e le sue idee architetturali hanno influenzato molti progetti di calcolo parallelo successivi, ed è un paradigma di riferimento per la progettazione parallela Layer 1 ad alte prestazioni.

  Meccanismo di base:

  1. Elenchi di accesso espliciti all'account: ogni transazione deve dichiarare l'account coinvolto (lettura/scrittura) al momento dell'invio e il sistema determinerà se esiste un conflitto di stato tra le transazioni.

  2. Rilevamento dei conflitti e schedulazione multi-thread

  • Se non vi è intersezione tra i set di conti a cui accedono le due transazioni→ possono essere eseguite in parallelo;
  • C'è un conflitto→ l'esecuzione seriale in ordine dipendente;
  • L'utilità di pianificazione alloca le transazioni a thread diversi in base al grafico delle dipendenze.

  3. Contesto di chiamata del programma: ogni chiamata al contratto viene eseguita in un contesto isolato senza uno stack condiviso per evitare interferenze tra chiamate.

  Sealevel è il motore di pianificazione dell'esecuzione parallela di Solana, mentre SVM è un ambiente di esecuzione di smart contract basato su Sealevel (utilizzando la macchina virtuale BPF). Insieme, costituiscono la base tecnica del sistema di esecuzione parallela ad alte prestazioni di Solana.

  Eclipse è un progetto che distribuisce VM Solana su chain modulari come Ethereum L2 o Celestia, sfruttando il motore di esecuzione parallela di Solana come livello di esecuzione del rollup. Eclipse è uno dei primi progetti a proporre di staccare il livello di esecuzione di Solana (Sealevel + SVM) dalla mainnet di Solana e migrarlo verso un'architettura modulare, e l'output modulare del "modello di esecuzione super concorrente" di Solana è Execution Layer-as-a-Service, quindi anche Eclipse appartiene alla categoria del calcolo parallelo.

  Il percorso di Neon è diverso, introduce l'EVM per operare in un ambiente SVM / Sealevel. Costruisci un livello di runtime compatibile con EVM, gli sviluppatori possono utilizzare Solidity per sviluppare contratti ed eseguirli nell'ambiente SVM, ma l'esecuzione della pianificazione utilizza SVM + Sealeve. Neon si orienta più verso la categoria Blockchain modulare che verso l'innovazione del calcolo parallelo.

  Tutto sommato, Solana e SVM si basano sul motore di esecuzione Sealevel e la filosofia di pianificazione basata sul sistema operativo di Solana è simile allo scheduler del kernel, che è veloce ma relativamente poco flessibile. Si tratta di una catena pubblica nativa di calcolo parallelo ad alte prestazioni.

  3.2 Architettura MoveVM: Resource and Object Driven

  MoveVM è una macchina virtuale smart contract progettata per la sicurezza delle risorse on-chain e l'esecuzione parallela, e il suo linguaggio principale, Move, è stato originariamente sviluppato da Meta (ex Facebook) per il progetto Libra, sottolineando il concetto di "le risorse sono oggetti" e tutti gli stati on-chain esistono come oggetti, con una chiara proprietà e cicli di vita. Ciò consente a MoveVM di analizzare se sono presenti conflitti di stato tra le transazioni durante la fase di compilazione e di implementare la pianificazione parallela statica a livello di oggetto, che è ampiamente utilizzata nelle catene pubbliche parallele native come Sui e Aptos.

  Il modello di proprietà degli oggetti di SuiLe

  capacità di calcolo parallelo di Sui derivano dal suo approccio unico alla modellazione dello stato e all'analisi statica a livello di linguaggio. A differenza delle blockchain tradizionali, che utilizzano alberi di stato globali, Sui ha costruito un modello incentrato sull'oggetto basato sull'"oggetto", che funziona con il sistema di tipi lineari di MoveVM per rendere la pianificazione parallela un processo deterministico che può essere completato in fase di compilazione.

  • Il Modello a Oggetti è il fondamento dell'architettura parallela di Sui. Sui astrae tutto lo stato della catena in oggetti separati, ognuno con un ID univoco, un proprietario chiaro (account o contratto) e una definizione del tipo. Questi oggetti non condividono lo stato tra loro e sono intrinsecamente isolati. Il contratto deve dichiarare esplicitamente l'insieme degli oggetti coinvolti quando viene chiamato, evitando il problema dell'accoppiamento di stato del tradizionale "albero di stato globale" on-chain. Questo design suddivide lo stato on-chain in diverse unità indipendenti, rendendo l'esecuzione simultanea una premessa di pianificazione strutturalmente fattibile.
  • L'analisi statica della proprietà è un meccanismo di analisi in fase di compilazione implementato con il supporto del sistema di tipi lineari del linguaggio Move. Consente al sistema di pianificare l'esecuzione delle transazioni in parallelo deducendo quali transazioni non presentano conflitti di stato attraverso la proprietà dell'oggetto prima di essere eseguite. Rispetto al rilevamento dei conflitti e al rollback dei runtime tradizionali, il meccanismo di analisi statica di Sui riduce notevolmente la complessità della pianificazione migliorando al contempo l'efficienza dell'esecuzione, che è la chiave per ottenere un throughput elevato e capacità di elaborazione parallela deterministica.

  Sui divide lo spazio degli stati in base all'oggetto, in combinazione con l'analisi della proprietà in fase di compilazione, per ottenere un'esecuzione parallela a livello di oggetto a basso costo e senza rollback. Rispetto all'esecuzione seriale o al rilevamento del runtime delle catene tradizionali, Sui ha ottenuto miglioramenti significativi nell'efficienza dell'esecuzione, nel determinismo del sistema e nell'utilizzo delle risorse.

  Meccanismo di esecuzione Block-STM di AptosAptos

  è una blockchain Layer1 ad alte prestazioni basata sul linguaggio Move e la sua capacità di esecuzione parallela deriva principalmente dal framework Block-STM (Block-level Software Transactional Memory) auto-sviluppato. A differenza della strategia di Sui di "parallelismo statico in fase di compilazione", Block-STM appartiene al meccanismo di pianificazione dinamica di "concorrenza ottimistica in fase di esecuzione + rollback dei conflitti", che è adatto per gestire set di transazioni con dipendenze complesse.

  Block-STM divide l'esecuzione della transazione di un blocco in tre fasi:

  • Esecuzione speculativa: tutte le transazioni sono prive di conflitti per impostazione predefinita prima dell'esecuzione e il sistema pianifica le transazioni in parallelo a più thread per tentare di eseguirle contemporaneamente e registra lo stato dell'account (set di lettura/scrittura) a cui accedono.
  • Fase di convalida: il sistema verifica il risultato dell'esecuzione: se si verifica un conflitto di lettura/scrittura tra due transazioni (ad esempio, Tx1 legge lo stato di scrittura da Tx2), viene eseguito il rollback di una di esse.
  • Fase di tentativi: le transazioni in conflitto verranno riprogrammate fino a quando le relative dipendenze non vengono risolte e infine tutte le transazioni formano una sequenza deterministica valida di invii di stato.

  Block-STM è un modello di esecuzione dinamica di "parallelismo ottimistico + rollback e tentativi", adatto per scenari di elaborazione batch di transazioni on-chain ad alta intensità di stato e logicamente complessi, ed è il nucleo di calcolo parallelo per Aptos per costruire una catena pubblica ad alta versatilità e throughput elevato.

  

  Solana è una scuola di programmazione di ingegneria, più simile a un "kernel del sistema operativo", adatto per confini di stato chiari, trading ad alta frequenza controllabile, è uno stile di ingegnere hardware, per eseguire la catena come hardware (esecuzione parallela di livello hardware); Aptos è un sistema tollerante ai guasti, più simile a un "motore di concorrenza di database", adatto per sistemi a contratto con forte accoppiamento di stato e catene di chiamate complesse. Aptos e Sui sono come ingegneri di linguaggi di programmazione e la sicurezza delle risorse di livello software rappresenta il percorso di implementazione tecnica del calcolo parallelo Web3 sotto diverse filosofie.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 è una catena pubblica transazionale ad alte prestazioni costruita sulla base di Cosmos SDK e la sua capacità di parallelismo si riflette principalmente in due aspetti: il motore di corrispondenza multi-thread (Parallel Matching Engine) e l'ottimizzazione dell'esecuzione parallela del livello della macchina virtuale, progettato per servire scenari di transazione on-chain ad alta frequenza e bassa latenza, come il DEX del libro degli ordini, infrastruttura di scambio on-chain, ecc.

  Meccanismo di parallelismo principale:

  1. Motore di corrispondenza parallela: SEI V2 introduce un percorso di esecuzione multi-thread nella logica di corrispondenza degli ordini, suddividendo l'order book in sospeso e la logica di corrispondenza a livello di thread, in modo che le attività di corrispondenza tra più coppie di trading possano essere elaborate in parallelo ed evitare il collo di bottiglia a thread singolo.
  2. Ottimizzazione della concorrenza a livello di macchina virtuale: Sei V2 crea un ambiente di runtime CosmWasm con funzionalità di esecuzione simultanea, che consente l'esecuzione di alcune chiamate di contratto in parallelo senza conflitti di stato e coopera con il meccanismo di classificazione del tipo di transazione per ottenere un controllo della velocità effettiva più elevato.
  3. Pianificazione parallela del consenso e del livello di esecuzione: viene introdotto il cosiddetto meccanismo di consenso "Twin-Turbo" per rafforzare il throughput e il disaccoppiamento tra il livello di consenso e il livello di esecuzione e migliorare l'efficienza complessiva dell'elaborazione dei blocchi.

  3.4 UTXO Model Reformer Fuel Fuel

  è un livello di esecuzione ad alte prestazioni progettato sulla base dell'architettura modulare di Ethereum e il suo meccanismo di parallelismo di base deriva dal modello UTXO (Unspent Transaction Output) migliorato. A differenza del modello di account di Ethereum, Fuel utilizza una struttura UTXO per rappresentare asset e stati, che è intrinsecamente isolata dallo stato, rendendo facile determinare quali transazioni possono essere eseguite in modo sicuro in parallelo. Inoltre, Fuel introduce il suo linguaggio di smart contract Sway (simile a Rust), combinato con strumenti di analisi statica, per determinare i conflitti di input prima che le transazioni vengano eseguite, in modo da ottenere una pianificazione parallela efficiente e sicura a livello di transazione. Si tratta di un livello di esecuzione alternativo EVM che bilancia prestazioni e modularità.

  4. Modello ad attori: un nuovo paradigma di esecuzione simultanea

  degli agenti Il modello ad attori è un paradigma di esecuzione parallela basato su agenti o processi, che è diverso dal tradizionale calcolo sincrono dello stato globale sulla catena (Solana/Sui/Monad e altri scenari di "calcolo parallelo on-chain"), che enfatizza che ogni agente ha uno stato e un comportamento indipendenti e comunica e pianifica attraverso messaggi asincroni. In base a questa architettura, il sistema on-chain può essere eseguito contemporaneamente da un gran numero di processi disaccoppiati l'uno dall'altro e ha una forte scalabilità e tolleranza ai guasti asincroni. I progetti rappresentativi includono AO (Arweave AO), ICP (Internet Computer) e Cartesi, che stanno guidando l'evoluzione della blockchain da un motore di esecuzione a un "sistema operativo on-chain", fornendo un'infrastruttura nativa per agenti di intelligenza artificiale, interazioni multi-task e orchestrazione logica complessa.

  Sebbene la progettazione dell'Actor Model sia simile allo sharding in termini di caratteristiche superficiali (ad esempio, parallelismo, isolamento dello stato ed elaborazione asincrona), i due rappresentano essenzialmente percorsi tecnici e filosofie di sistema completamente diversi. L'Actor Model enfatizza il "calcolo asincrono multiprocesso", in cui ogni agente viene eseguito in modo indipendente, mantiene lo stato in modo indipendente e interagisce in modo basato sui messaggi. Lo sharding, invece, è un meccanismo di "sharding orizzontale di stato e consenso", che divide l'intera blockchain in più sottosistemi (shard) che elaborano le transazioni in modo indipendente. I modelli ad attori sono più simili a un "sistema operativo ad agenti distribuiti" nel mondo Web3, mentre lo sharding è una soluzione di scalabilità strutturale per le capacità di elaborazione delle transazioni on-chain. Entrambi raggiungono il parallelismo, ma hanno punti di partenza, obiettivi e architetture di esecuzione diversi.

  4.1 AO (Arweave), un computer super-parallelo sopra il livello di archiviazioneAO

  è una piattaforma di calcolo decentralizzata in esecuzione sul livello di archiviazione permanente Arweave, con l'obiettivo principale di costruire un sistema operativo on-chain che supporti il funzionamento di agenti asincroni su larga scala.

  Caratteristiche principali dell'architettura:

  • Architettura dei processi: ogni agente è chiamato processo, con stato indipendente, pianificatore indipendente e logica di esecuzione;
  • Nessuna struttura blockchain: AO non è una catena, ma un livello di archiviazione decentralizzato + un motore di esecuzione basato su messaggi multi-agente basato su Arweave;
  • Sistema di pianificazione dei messaggi asincroni: i processi comunicano tra loro tramite messaggi, adottano un modello operativo asincrono senza blocchi e supportano naturalmente l'espansione simultanea.
  • Archiviazione permanente dello stato: tutti gli stati degli agenti, i record dei messaggi e le istruzioni sono registrati in modo permanente su Arweave, garantendo la piena verificabilità e la trasparenza decentralizzata.
  • Nativo dell'agente: è adatto per l'implementazione di attività complesse in più fasi (come agenti AI, controller del protocollo DePIN, orchestratori automatici di attività, ecc.) e può creare un "coprocessore AI on-chain".

  AO prende la strada definitiva di "agente nativo + driver di archiviazione + architettura senza catena", enfatizzando la flessibilità e il disaccoppiamento dei moduli, ed è un "framework di microkernel sulla catena costruito sopra il livello di archiviazione", con il limite del sistema che si restringe deliberatamente, enfatizzando il calcolo leggero + la struttura di controllo componibile.

  4.2 ICP (Internet Computer), una piattaforma di hosting Web3 full-stackICP

  è una piattaforma applicativa on-chain full-stack nativa Web3 lanciata da DFINITY, con l'obiettivo di estendere la potenza di calcolo on-chain a esperienze simili a Web2 e supportare l'hosting di servizi completi, l'associazione dei nomi di dominio e l'architettura serverless.

  Funzionalità principali dell'architettura:

  • Architettura canister (contenitori come agenti): ogni contenitore è un agente in esecuzione su una macchina virtuale Wasm con funzionalità di pianificazione asincrona e di stato, codice e indipendenti ;
  • Subnet Distributed Consensus System (Subnet): l'intera rete è composta da più sottoreti, ognuna delle quali mantiene una serie di contenitori e raggiunge il consenso attraverso il meccanismo di firma BLS.
  • Modello di chiamata asincrona: Canister comunica con Canister tramite messaggi asincroni, supporta l'esecuzione non bloccante e ha un parallelismo naturale.
  • Web hosting on-chain: supporta gli smart contract per ospitare direttamente le pagine front-end, la mappatura DNS nativa ed è la prima piattaforma blockchain che supporta i browser per accedere direttamente alle dApp;
  • Il sistema ha funzioni complete: dispone di API di sistema come l'aggiornamento a caldo on-chain, l'autenticazione dell'identità, la casualità distribuita e il timer, adatto per l'implementazione di servizi on-chain complessi.

  ICP sceglie un paradigma di sistema operativo composto da una piattaforma pesante, un packaging integrato e un forte controllo della piattaforma e dispone di un "sistema operativo blockchain" che integra consenso, esecuzione, archiviazione e accesso, enfatizzando le capacità complete di hosting dei servizi ed espandendo i confini del sistema a una piattaforma di hosting Web3 full-stack.

  Inoltre, i progetti di calcolo parallelo di altri paradigmi Actor Model possono essere riferiti alla seguente tabella:

  

  5. Sommario e prospettivaSulla base

  delle differenze tra l'architettura della macchina virtuale e il sistema di linguaggio, le soluzioni di calcolo parallelo blockchain possono essere approssimativamente suddivise in due categorie: EVM parallel enhancement chain e native parallel architecture chain (non-EVM).

  Sulla base del mantenimento della compatibilità dell'ecosistema EVM/Solidity, il primo raggiunge un throughput più elevato e capacità di elaborazione parallela attraverso un'ottimizzazione approfondita del livello di esecuzione, che è adatto per scenari che desiderano ereditare gli asset e gli strumenti di sviluppo di Ethereum e ottenere allo stesso tempo risultati in termini di prestazioni. I progetti rappresentativi includono:

  • Monad: implementa un modello di esecuzione parallela ottimistico compatibile con EVM attraverso la scrittura differita e il rilevamento dei conflitti di runtime, crea grafici delle dipendenze e pianifica l'esecuzione dopo il completamento del consenso.
  • MegaETH: astrae ogni account/contratto in una micro-VM indipendente e implementa una pianificazione parallela a livello di account altamente disaccoppiata basata su messaggistica asincrona e grafici dipendenti dallo stato.
  • Pharos: creare un'architettura mesh di rollup per ottenere l'elaborazione parallela a livello di sistema tra i processi tramite pipeline asincrone e moduli SPN.
  • Reddio: utilizza l'architettura zkRollup + GPU per accelerare il processo di verifica off-chain di zkEVM attraverso la generazione batch di SNARK e migliorare il throughput di verifica.

  Quest'ultimo elimina completamente i limiti della compatibilità di Ethereum e ridisegna il paradigma di esecuzione dalla macchina virtuale, dal modello di stato e dal meccanismo di pianificazione per ottenere una concorrenza nativa ad alte prestazioni. Le sottoclassi tipiche includono:

  • Solana (SVM): un modello di esecuzione parallela a livello di account basato su dichiarazioni di accesso all'account e pianificazione di grafici di conflitti statici;
  • Sui / Aptos (sistema MoveVM): basato sul modello a oggetti e sul sistema di tipi delle risorse, supporta l'analisi statica in fase di compilazione e realizza il parallelismo a livello di oggetto.
  • Sei V2 (route Cosmos SDK): introduce un motore di corrispondenza multithread e l'ottimizzazione della concorrenza delle macchine virtuali nell'architettura Cosmos, adatta per applicazioni transazionali ad alta frequenza.
  • Fuel (architettura UTXO + Sway): parallelismo a livello di transazione attraverso l'analisi statica del set di input UTXO, combinando un livello di esecuzione modulare con un linguaggio di smart contract personalizzato Sway;

  Inoltre, come sistema parallelo più generalizzato, l'Actor Model costruisce un paradigma di esecuzione on-chain di "operazione indipendente multi-agente + collaborazione basata su messaggi" attraverso un meccanismo di pianificazione dei processi asincroni basato su Wasm o VM personalizzate. I progetti rappresentativi includono:

  • AO (Arweave AO): Creazione di un sistema di microkernel asincrono on-chain basato sul runtime dell'agente persistente basato sullo storage;
  • ICP (Internet Computer): utilizza l'agente containerizzato (Canister) come unità più piccola per ottenere un'esecuzione asincrona e altamente scalabile attraverso il coordinamento della subnet.
  • Cartesi: Introduce il sistema operativo Linux come ambiente di elaborazione off-chain per fornire un percorso di verifica on-chain per risultati di calcolo affidabili, adatto a scenari applicativi complessi o ad alta intensità di risorse.

  Sulla base della logica di cui sopra, possiamo riassumere l'attuale schema di catena pubblica di calcolo parallelo mainstream in una struttura di classificazione come mostrato nella figura seguente:

  

  Da una prospettiva di scalabilità più ampia, lo sharding e il rollup (L2) si concentrano sulla scalabilità orizzontale attraverso lo sharding di stato o l'esecuzione off-chain, mentre le catene di calcolo parallele (ad esempio, Monad, Sui, Solana) e i sistemi orientati agli attori (ad esempio, AO, ICP) ricostruiscono direttamente il modello di esecuzione e ottengono il parallelismo nativo all'interno della catena o a livello di sistema. Il primo migliora il throughput intra-chain attraverso macchine virtuali multi-thread, modelli a oggetti, analisi dei conflitti di transazione, ecc.; Quest'ultimo prende il processo/agente come unità di base e adotta modalità di esecuzione asincrone e basate su messaggi per ottenere un'operazione simultanea multi-agente. Al contrario, lo sharding e i rollup sono più simili a "dividere il carico su più catene" o "esternalizzare off-chain", mentre il modello di catena parallela e attore sta "liberando il potenziale di prestazioni dal motore di esecuzione stesso", riflettendo un'evoluzione architetturale più completa.

  Calcolo parallelo vs architettura di sharding vs ridimensionamento rollup vs confronto del percorso di ridimensionamento orientato agli attori

  

  Va sottolineato che la maggior parte delle catene di architetture parallele native sono entrate nella fase di lancio della mainnet, sebbene l'ecosistema di sviluppatori complessivo sia ancora difficile da confrontare con il sistema Solidity del sistema EVM, ma i progetti rappresentati da Solana e Sui, con la loro architettura di esecuzione ad alte prestazioni e la graduale prosperità delle applicazioni ecologiche, sono diventati le core chain pubbliche a cui il mercato presta grande attenzione.

  Al contrario, sebbene l'ecosistema Ethereum Rollup (L2) sia entrato nella fase di "10.000 chain at once" o addirittura di "sovraccapacità", l'attuale catena di potenziamento parallelo EVM mainstream è ancora generalmente in fase di testnet e non è ancora stata verificata dall'attuale ambiente mainnet, e la sua capacità di scalabilità e stabilità del sistema devono ancora essere ulteriormente testate. Resta da vedere se questi progetti possono migliorare significativamente le prestazioni EVM e guidare i salti ecologici senza sacrificare la compatibilità, o se possono differenziare ulteriormente la liquidità e le risorse di sviluppo di Ethereum.