Web3 Parallel Computing Track Panorama: Den bästa lösningen för inbyggd skalning?

Författare: 0xjacobzhao och ChatGPT 4o"Blockchain

Trilemma" av "säkerhet", "decentralisering" och "skalbarhet" av blockchain avslöjar den väsentliga avvägningen i utformningen av blockchain-system, det vill säga det är svårt för blockchain-projekt att uppnå "extrem säkerhet, alla kan delta och höghastighetsbearbetning" samtidigt. Som svar på det eviga ämnet "skalbarhet" är de vanliga blockkedjeskalningslösningarna på marknaden uppdelade efter paradigm, inklusive:

• Exekveringsförbättrad skalning: Förbättrar exekveringskapaciteten på plats, såsom parallellitet, GPU och flerkärnig
• tillståndsisolerad skalning: Horisontellt delat tillstånd/skärva, t.ex. skärvor, UTXO och flera undernät
• Off-chain outsourcad skalning: Sätta exekvering off-chain, såsom rollups, Skalning av frikopplingsskalning av coprocessor- och DA-struktur
• : Modulär arkitektur och samarbetsdrift, till exempel modulkedja, delad sekvenserare, Rollup Mesh
• Asynkron samtidig skalning: Aktörsmodell, processisolering, meddelandedriven, till exempel agent, flertrådad asynkron kedja

  Blockchain-skalningslösningen inkluderar: parallell databehandling på kedjan, rollup, sharding, DA-modul, modulär struktur, aktörssystem, zk-säker komprimering, tillståndslös arkitektur, etc., som täcker flera nivåer av utförande, tillstånd, data och struktur, och är ett komplett skalningssystem för "flerskiktssamarbete och modulkombination". Den här artikeln fokuserar på skalningsmetoder som integrerar parallell databehandling.

  Intra-chain parallelism, som fokuserar på parallell exekvering av transaktioner/instruktioner inom blocket. Enligt den parallella mekanismen kan dess skalningsmetoder delas in i fem kategorier, som var och en representerar en annan prestandasträvan, utvecklingsmodell och arkitekturfilosofi, och den parallella granulariteten blir finare och finare, parallellitetsintensiteten blir högre och högre, schemaläggningskomplexiteten blir högre och högre, och programmeringskomplexiteten och implementeringssvårigheten blir också högre och högre.

  • Kontonivå: Representerar projektet
  • Objektnivå: Representerar projektet Sui
  • Transaktionsnivå: Representerar projektet Monad, Aptos
  • Call-level / MicroVM : Instruktionsnivå MegaETH
  :
  • GatlingX

  Den asynkrona samtidighetsmodellen utanför kedjan, representerad av aktörs-/aktörsmodellen, tillhör ett annat parallellt beräkningsparadigm, som ett tvärkedjat/asynkront meddelandesystem (icke-blocksynkroniseringsmodell), varje agent körs oberoende som en "agentprocess", asynkrona meddelanden i parallellt läge, händelsestyrda, ingen synkron schemaläggning, representativa projekt som AO, ICP, Cartesi, etc.

  Det välkända sammanslagnings- eller shardskalningsschemat tillhör samtidighetsmekanismen på systemnivå, inte parallell databehandling inom kedjan. De uppnår skalning genom att "köra flera kedjor/exekveringsdomäner parallellt", snarare än att öka parallelliteten inom ett enda block/virtuell maskin. Den här typen av skalningslösning är inte i fokus för den här artikeln, men vi kommer ändå att använda den för att jämföra likheter och skillnader i arkitektoniska begrepp.

  

  2. EVM Parallel Enhancement Chain: Bryta prestandagränsen i kompatibilitet

  Sedan utvecklingen av Ethereums seriella bearbetningsarkitektur har den genomgått flera omgångar av skalningsförsök som sharding, rollup och modulär arkitektur, men flaskhalsen för genomströmning i exekveringslagret har fortfarande inte brutits i grunden. Men samtidigt är EVM och Solidity fortfarande de plattformar för smarta kontrakt som har den största utvecklarbasen och ekologiska potentialen. Därför blir EVM:s parallella förbättringskedja en viktig riktning för en ny omgång av skalning och utveckling som en nyckelväg som tar hänsyn till ekologisk kompatibilitet och förbättring av exekveringsprestanda. Monad och MegaETH är de mest representativa projekten i denna riktning, med början från uppskjuten exekvering respektive tillståndsnedbrytning, för att bygga en EVM-parallell bearbetningsarkitektur för scenarier med hög samtidighet och hög genomströmning.

  Monad's Parallel Computing

  AnalysisMonad är en högpresterande Layer1-blockkedja omdesignad för Ethereum Virtual Machine (EVM), baserad på det grundläggande parallella konceptet pipelining, med asynkron exekvering i konsensuslagret och optimistisk samtidighet i exekveringslagret Parallell körning) 。 Dessutom har Monad på konsensus- och lagringsnivåerna introducerat det högpresterande BFT-protokollet (MonadBFT) respektive ett dedikerat databassystem (MonadDB) för att uppnå end-to-end-optimering.

  Pipelining: Mekanism för parallell exekvering av pipeline i flera steg

  Pipelining är det grundläggande konceptet för Monad parallell exekvering, och dess kärnidé är att dela upp exekveringsprocessen för blockkedjan i flera oberoende steg och bearbeta dessa steg parallellt för att bilda en tredimensionell pipelinearkitektur, där varje steg körs på oberoende trådar eller kärnor för att uppnå samtidig bearbetning över block. Resultatet är ökat dataflöde och minskad latens. Dessa steg inkluderar: Föreslå, Konsensus, Genomförande och Genomföra.

  Asynkron körning: Konsensus - Körningen är asynkront frikoppladPå

  traditionella kedjor är transaktionskonsensus och exekvering ofta synkrona processer, och denna seriella modell begränsar kraftigt prestandaskalningen. Monad implementerar konsensuslager asynkront, exekveringslager asynkront och lagring asynkront genom "asynkron körning". Minska blocktiden och bekräftelselatensen avsevärt, vilket gör systemet mer motståndskraftigt, bearbetningen mer segmenterad och resursutnyttjandet.

  Kärndesign:

  • Konsensusprocessen (konsensusskiktet) ansvarar endast för att sortera transaktioner och kör inte kontraktslogik.
  • Körningsprocessen (körningslagret) utlöses asynkront när konsensus har slutförts.
  • När konsensus är klar kommer den att gå in i konsensusprocessen för nästa block omedelbart, utan att vänta på att körningen ska slutföras.

  Optimistisk parallell exekvering: Optimistisk parallell exekveringTraditionell

  Ethereum antar en strikt seriell modell för transaktionsutförande för att undvika tillståndskonflikter. Monad, å andra sidan, antar en "optimistisk parallell exekvering"-strategi för att avsevärt öka transaktionsbearbetningshastigheten.

  Exekveringsmekanism:

  • Monad utför optimistiskt alla transaktioner parallellt, förutsatt att de flesta transaktionerna är tillståndslösa och konfliktfria.
  • Kör också en "Konfliktdetektor" för att övervaka om samma tillstånd (t.ex. läs-/skrivkonflikter) nås mellan transaktioner.
  • Om en konflikt upptäcks serialiseras den motstridiga transaktionen och körs på nytt för att säkerställa att tillståndet är korrekt.

  Monad har valt en kompatibel väg: att flytta så få EVM-regler som möjligt, att uppnå parallellitet genom att skjuta upp skrivtillstånd och dynamiskt upptäcka konflikter under exekvering, vilket är mer som en prestandaversion av Ethereum, med en mognadsnivå som gör det enkelt att migrera till EVM-ekosystemet, och är en parallell accelerator i EVM-världen.

  MegaETH:s parallella beräkningsmekanismupplösning

  skiljer sig från Monads L1-positionering, och MegaETH är positionerad som ett EVM-kompatibelt modulärt högpresterande parallellt exekveringslager, som kan användas som en oberoende L1 offentlig kedja, som ett exekveringsförbättringslager eller modulär komponent på Ethereum. Dess huvudsakliga designmål är att dekonstruera kontologiken, körningsmiljön och tillståndsisoleringen till den minsta enheten som kan schemaläggas oberoende för att uppnå hög samtidighetskörning och svarskapacitet med låg latens i kedjan. Den viktigaste innovationen som föreslagits av MegaETH är att Micro-VM-arkitekturen + State Dependency DAG (directed and acyclic state dependency graph) och den modulära synkroniseringsmekanismen tillsammans bygger ett parallellt exekveringssystem för "intra-chain threading".

  Micro-VM-arkitektur: Konton är trådar

  MegaETH introducerar körningsmodellen med "en mikro-VM per konto", som "trådar" körningsmiljön och ger en minsta isoleringsenhet för parallell schemaläggning. Dessa virtuella datorer kommunicerar med varandra via asynkrona meddelanden i stället för synkrona anrop, och ett stort antal virtuella datorer kan köras oberoende av varandra, lagras oberoende av varandra och naturligt parallellt.

  State Dependency DAG: en grafdriven schemaläggningsmekanism

  MegaETH har byggt ett DAG-schemaläggningssystem baserat på åtkomstförhållandet för kontotillstånd, och systemet upprätthåller en global beroendegraf i realtid, och vilka konton som ändras och vilka konton som läses för varje transaktion modelleras alla till beroenden. Konfliktfria transaktioner kan utföras direkt parallellt, och beroende transaktioner schemaläggs och sorteras seriellt eller skjuts upp i topologisk ordning. Beroendediagram säkerställer tillståndskonsekvens och icke-duplicerade skrivningar under parallell körning.

  Den

  asynkrona exekverings- och återuppringningsmekanismen

  MegaETH är byggd ovanpå det asynkrona programmeringsparadigmet, liknande den asynkrona meddelandepassningen av aktörsmodellen, för att lösa problemet med traditionella EVM-serieanrop. Kontraktsanrop är asynkrona (icke-rekursiv körning) och när kontrakt A -> B -> C anropas är varje anrop asynkront utan att blockera väntan. Anropsstacken expanderas till ett asynkront anropsdiagram. Transaktionsbearbetning = bläddring av asynkron graf + beroendematchning + parallell schemaläggning.

  Sammantaget bryter MegaETH den traditionella EVM-modellen med enkeltrådade tillståndsmaskiner, implementerar mikro-virtuell maskininkapsling på konto-för-konto-basis, utför transaktionsschemaläggning genom tillståndsberoende grafer och ersätter den synkrona anropsstacken med en asynkron meddelandemekanism. Det är en parallell datorplattform som är omdesignad från de fulla dimensionerna av "kontostruktur→ schemaläggningsarkitektur → utförandeprocess", vilket ger en ny idé på paradigmnivå för att bygga nästa generations högpresterande on-chain-system.

  MegaETH har valt refaktoriseringsvägen: den abstraherar helt konton och kontrakt till oberoende VM:er och frigör den ultimata parallellitetspotentialen genom asynkron körningsschemaläggning. Teoretiskt sett har MegaETH ett högre parallellt tak, men det är också svårare att kontrollera komplexiteten, och det är mer som ett superdistribuerat operativsystem enligt Ethereum-konceptet.

  

  Monad och MegaETH Båda har olika designkoncept från sharding: sharding delar horisontellt upp blockkedjan i flera oberoende underkedjor (shards), som var och en ansvarar för en del av transaktionerna och tillståndet, vilket bryter begränsningen av enkelkedjan och skalning i nätverkslagret; Å andra sidan upprätthåller både Monad och MegaETH integriteten hos den enskilda kedjan, skalar horisontellt endast vid exekveringslagret och utför optimeringsgenombrott parallellt vid gränsen för den enskilda kedjan. De två representerar två riktningar: vertikal förstärkning och horisontell expansion i blockkedjans expansionsväg.

  Parallella databehandlingsprojekt som Monad och MegaETH fokuserar huvudsakligen på optimeringsvägen för genomströmning, med huvudmålet att förbättra TPS i kedjan och uppnå parallell bearbetning på transaktionsnivå eller kontonivå genom uppskjuten körning och mikro-VM-arkitekturer. Pharos Network är ett modulärt, fullstack parallellt L1 blockchain-nätverk, och dess kärna parallella datorsystem kallas "Rollup Mesh". Den här arkitekturen stöder miljöer med flera virtuella datorer (EVM och Wasm) genom synergin mellan huvudnät och SPN (Special Processing Networks) och integrerar avancerad teknik som nollkunskapsbevis (ZK) och betrodda körningsmiljöer (TEE).

  Rollup Mesh Parallel Computing Analysis:

  1. Full Lifecycle Asynchronous Pipelining: Pharos frikopplar de olika stegen i en transaktion (t.ex. konsensus, exekvering och lagring) och antar asynkron bearbetning så att varje steg kan utföras oberoende och parallellt, vilket förbättrar den totala bearbetningseffektiviteten.
  2. Dubbel parallell körning av virtuella datorer: Pharos stöder både EVM- och WASM virtuella maskinmiljöer, vilket gör att utvecklare kan välja rätt körningsmiljö för sina behov. Den här arkitekturen med dubbla virtuella datorer ökar inte bara systemets flexibilitet, utan ökar även transaktionsbearbetningen genom parallell körning.
  3. Special Processing Networks (SPN): SPN:er är nyckelkomponenter i Pharos-arkitekturen, liknande modulära undernätverk som är utformade för att hantera specifika typer av uppgifter eller applikationer. Med SPN:er möjliggör Pharos dynamisk allokering av resurser och parallell bearbetning av uppgifter, vilket ytterligare förbättrar systemets skalbarhet och prestanda.
  4. Modulär konsensus och omplacering: Pharos introducerar en flexibel konsensusmekanism som stöder flera konsensusmodeller (såsom PBFT, PoS, PoA) och möjliggör säker delning och resursintegration mellan huvudnätet och SPN:er genom omsättningsprotokollet.

  Dessutom rekonstruerar Pharos exekveringsmodellen från det nedre lagret av lagringsmotorn genom Merkle-träd med flera versioner, Delta Encoding, Versioned Addressing och ADS Pushdown-teknik, och lanserar Pharos Store, en högpresterande lagringsmotor för den inbyggda blockkedjan, för att uppnå hög genomströmning, låg latens och starka verifierbara bearbetningsfunktioner i kedjan.

  I allmänhet uppnår Pharos Rollup Mesh-arkitektur högpresterande parallella datorfunktioner genom modulär design och asynkron bearbetningsmekanism.

  Förutom de parallella exekveringsarkitekturerna för Monad, MegaETH och Pharos, observerar vi också att det finns några projekt på marknaden som utforskar applikationsvägen för GPU-acceleration i EVM parallell databehandling, som ett viktigt komplement och banbrytande experiment till EVM:s parallella ekosystem. Bland dem finns Reddio och GatlingX två representativa riktningar:

  • Reddio är en högpresterande plattform som kombinerar zkRollup och GPU parallell exekveringsarkitektur, och dess kärna ligger i att rekonstruera EVM-exekveringsprocessen och realisera den inbyggda parallelliseringen av exekveringslagret genom flertrådad schemaläggning, asynkron tillståndslagring och GPU-accelererad exekvering av transaktionsbatcher. Parallell kornighet på transaktionsnivå + åtgärdsnivå (opcode för flertrådad körning). Den är utformad för att introducera flertrådad batchkörning, asynkron tillståndsinläsning och transaktionslogik för GPU-parallell bearbetning (CUDA-Compatible Parallel EVM). Liksom Monad / MegaETH fokuserar Reddio också på parallell bearbetning i exekveringslagret, med skillnaden att exekveringsmotorn rekonstrueras genom en GPU-parallell arkitektur, designad för hög genomströmning och beräkningsintensiva scenarier som AI-inferens. GatlingX,
  • som kallar sig "GPU-EVM", föreslår en mer radikal arkitektur som försöker migrera modellen "instruktionsnivå seriell körning" för traditionella virtuella EVM-maskiner till en GPU-inbyggd parallell körningsmiljö. Kärnmekanismen är att dynamiskt kompilera EVM-bytekoden till parallella CUDA-uppgifter och köra instruktionsströmmen genom GPU:n med flera kärnor, för att bryta den sekventiella flaskhalsen i EVM på den lägsta nivån. Parallell kornighet som tillhör parallellitet på instruktionsnivå (ILP). Jämfört med den parallella granulariteten på "transaktionsnivå/kontonivå" för Monad / MegaETH, tillhör GatlingX:s parallellitetsmekanism optimeringsvägen på instruktionsnivå, som ligger närmare den underliggande refaktoriseringen av den virtuella maskinmotorn. Det är för närvarande i konceptfasen, med ett whitepaper och en arkitektonisk skiss publicerad, och inget SDK eller mainnet ännu.

  Artela föreslår ett differentierat, parallellt designkoncept. Med introduktionen av den virtuella maskinen EVM++-arkitekturen WebAssembly (WASM) får utvecklare dynamiskt lägga till och köra tillägg i kedjan med hjälp av Aspekt-programmeringsmodellen samtidigt som EVM-kompatibiliteten bibehålls. Den använder kontraktsanropets kornighet (funktion/tillägg) som minsta parallella enhet och stöder inmatning av tilläggsmoduler (liknande "pluggbar mellanprogramvara") när EVM-kontraktet körs, för att uppnå logisk frikoppling, asynkront anrop och parallell körning på modulnivå. Mer uppmärksamhet ägnas åt komponerbarheten och den modulära arkitekturen i exekveringsskiktet. Konceptet ger nya idéer för komplexa flermodulsapplikationer i framtiden.

  3. Inbyggd parallell arkitekturkedja: EVM-exekveringsmodellen för Ethereum, exekveringsontologin för den rekonstruerade VM,

  har antagit en enkeltrådad arkitektur med "full transaktionsorder + seriell exekvering" sedan början av sin design, i syfte att säkerställa säkerhet och konsekvens i tillståndsändringar för alla noder i nätverket. Den här arkitekturen har dock en naturlig flaskhals i prestanda, vilket begränsar systemets dataflöde och skalbarhet. Däremot är inbyggda parallella databehandlingsarkitekturkedjor som Solana (SVM), MoveVM (Sui, Aptos) och Sei v2 som bygger på Cosmos SDK skräddarsydda för parallell körning från den underliggande designen och har följande fördelar:

  Naturlig
  • separation av tillståndsmodeller: Solana använder en mekanism för deklaration av kontolås, MoveVM introducerar en modell för objektägande och Sei v2 baseras på klassificering av transaktionstyp. Statisk konfliktbedömning realiseras och samtidig schemaläggning på transaktionsnivå stöds.
  • Virtuella maskiner är optimerade för samtidighet: Solanas Sealevel-motor har inbyggt stöd för flertrådig körning; MoveVM kan utföra statisk samtidighetsdiagramanalys; Sei v2 integrerar en flertrådad matchningsmotor med en parallell VM-modul.

  Naturligtvis står denna typ av inhemsk parallell kedja också inför utmaningen med ekologisk kompatibilitet. Icke-EVM-arkitekturer kräver vanligtvis nya utvecklingsspråk (som Move och Rust) och verktygskedjor, vilket har vissa migreringskostnader för utvecklare. Dessutom måste utvecklare behärska en rad nya koncept, t.ex. tillståndskänsliga åtkomstmodeller, samtidighetsgränser, objektlivscykler osv., vilket ställer högre krav på att förstå tröskelvärden och utvecklingsparadigm.

  3.1 Principen för parallella motorer på havsnivå för Solana och SVM

  Solanas Sealevel-exekveringsmodell är en mekanism för parallell schemaläggning av konton, som är kärnmotorn som används av Solana för att realisera utförandet av parallella transaktioner inom kedjan, och uppnår högpresterande samtidighet på nivån för smarta kontrakt genom mekanismen "kontodeklaration + statisk schemaläggning + flertrådad exekvering". Sealevel är den första exekveringsmodellen inom blockkedjeområdet som framgångsrikt implementerar samtidig schemaläggning inom kedjan i en produktionsmiljö, och dess arkitektoniska idéer har påverkat många efterföljande parallella datorprojekt och är ett referensparadigm för högpresterande Layer 1 parallell design.

  Kärnmekanism:

  1. Explicita kontoåtkomstlistor: Varje transaktion måste deklarera vilket konto som är involverat (läsa/skriva) när den skickas in, och systemet kommer att avgöra om det finns en tillståndskonflikt mellan transaktionerna.

  2. Konfliktdetektering och flertrådad schemaläggning

  • Om det inte finns någon skärningspunkt mellan de kontouppsättningar som används av de två transaktionerna→ kan de köras parallellt;
  • Det finns en konflikt→ att köra seriellt i beroende ordning.
  • Schemaläggaren allokerar transaktioner till olika trådar baserat på beroendediagrammet.

  3. Programanropskontext: Varje kontraktsanrop körs i en isolerad kontext utan en delad stack för att undvika störningar mellan samtal.

  Sealevel är Solanas schemaläggningsmotor för parallell körning, medan SVM är en miljö för utförande av smarta kontrakt som bygger på Sealevel (med hjälp av den virtuella BPF-maskinen). Tillsammans utgör de den tekniska grunden för Solanas högpresterande parallella exekveringssystem.

  Eclipse är ett projekt som distribuerar Solana VM:er på modulära kedjor som Ethereum L2 eller Celestia, och utnyttjar Solanas parallella exekveringsmotor som rollup-exekveringslager. Eclipse är ett av de första projekten som föreslår att koppla bort Solana-exekveringsskiktet (Sealevel + SVM) från Solanas huvudnät och migrera det till en modulär arkitektur, och den modulära utdata av Solanas "supersamtidiga exekveringsmodell" är Execution Layer-as-a-Service, så Eclipse tillhör också kategorin parallell databehandling.

  Neons rutt är annorlunda, den introducerar EVM för att fungera i en SVM / Sealevel-miljö. Bygg ett EVM-kompatibelt runtime-lager, utvecklare kan använda Solidity för att utveckla kontrakt och köra i SVM-miljön, men schemaläggningsutförandet använder SVM + Sealeve. Neon lutar sig mer mot kategorin Modular Blockchain än innovation inom parallell databehandling.

  Sammantaget förlitar sig Solana och SVM:er på Sealevel-exekveringsmotorn, och Solanas OS-baserade schemaläggningsfilosofi liknar kärnschemaläggaren, som är snabb men relativt oflexibel. Det är en inbyggd högpresterande, parallell offentlig datorkedja.

  3.2 MoveVM-arkitektur: Resurs- och objektdriven

  MoveVM är en virtuell maskin med smarta kontrakt som är utformad för resurssäkerhet på kedjan och parallell körning, och dess kärnspråk, Move, utvecklades ursprungligen av Meta (tidigare Facebook) för Libra-projektet, med betoning på konceptet "resurser är objekt", och alla tillstånd i kedjan existerar som objekt, med tydligt ägande och livscykler. Detta gör det möjligt för MoveVM att analysera om det finns tillståndskonflikter mellan transaktioner under kompileringstiden och implementera statisk parallell schemaläggning på objektnivå, som ofta används i inbyggda parallella offentliga kedjor som Sui och Aptos.

  Suis modell för objektägandeSuis

  kapacitet för parallell databehandling kommer från dess unika metod för tillståndsmodellering och statisk analys på språknivå. Till skillnad från traditionella blockkedjor, som använder globala tillståndsträd, har Sui byggt en objektcentrerad modell baserad på "objektet", som fungerar med MoveVM:s linjära typsystem för att göra parallell schemaläggning till en deterministisk process som kan slutföras vid kompileringstillfället.

  • Objektmodellen är grunden för Suis parallella arkitektur. Sui abstraherar alla tillstånd i kedjan till separata objekt, vart och ett med ett unikt ID, en tydlig ägare (konto eller kontrakt) och en typdefinition. Dessa objekt delar inte tillstånd med varandra och är i sig isolerade. Kontraktet måste uttryckligen deklarera samlingen av objekt som ingår när det anropas, för att undvika tillståndskopplingsproblemet med det traditionella "globala tillståndsträdet" i kedjan. Denna design delar upp tillståndet i kedjan i flera oberoende enheter, vilket gör samtidig körning till en strukturellt genomförbar schemaläggningsförutsättning.
  • Static Ownership Analysis är en mekanism för kompileringsanalys som implementeras med stöd av Move-språkets linjära typsystem. Det gör det möjligt för systemet att schemalägga transaktioner som ska köras parallellt genom att härleda vilka transaktioner som inte har tillståndskonflikter genom objektägarskap innan de körs. Jämfört med konfliktdetektering och återställning av traditionella körningar minskar Suis statiska analysmekanism avsevärt schemaläggningskomplexiteten samtidigt som exekveringseffektiviteten förbättras, vilket är nyckeln till att uppnå hög genomströmning och deterministisk parallell bearbetningskapacitet.

  Sui delar upp tillståndsutrymmet objekt för objekt, i kombination med analys av ägande vid kompilering, för att uppnå låg kostnad, återställningsfri parallell exekvering på objektnivå. Jämfört med seriell exekvering eller körtidsdetektering av traditionella kedjor har Sui uppnått betydande förbättringar i exekveringseffektivitet, systemdeterminism och resursutnyttjande.

  Aptos Block-STM Execution

  MechanismAptos är en högpresterande Layer1-blockkedja baserad på Move-språket, och dess parallella exekveringsförmåga härrör huvudsakligen från det egenutvecklade Block-STM-ramverket (Block-level Software Transactional Memory). Till skillnad från Suis strategi med "statisk parallellitet vid kompileringstid" tillhör Block-STM den dynamiska schemaläggningsmekanismen för "optimistisk samtidighet vid körning + konfliktåterställning", som är lämplig för att hantera transaktionsuppsättningar med komplexa beroenden.

  Block-STM delar upp transaktionsutförandet av ett block i tre steg:

  • Spekulativ körning: Alla transaktioner är konfliktfria som standard före utförande, och systemet schemalägger transaktioner parallellt med flera trådar för att försöka köra samtidigt och registrerar kontostatusen (läs-/skrivuppsättningen) som de har åtkomst till.
  • Valideringsfas: Systemet verifierar exekveringsresultatet: om det finns en läs- och skrivkonflikt mellan två transaktioner (till exempel om Tx1 läser tillståndet för att skrivas av Tx2) återställs en av dem.
  • Återförsöksfas: Motstridiga transaktioner schemaläggs om tills deras beroenden har lösts, och så småningom bildar alla transaktioner en giltig, deterministisk sekvens av tillståndsöverföringar.

  Block-STM är en dynamisk exekveringsmodell för "optimistisk parallellism + återställning och återförsök", som är lämplig för tillståndsintensiva och logiskt komplexa scenarier för batchbearbetning av transaktioner i kedjan, och är den parallella beräkningskärnan för Aptos för att bygga en offentlig kedja med hög mångsidighet och hög genomströmning.

  

  Solana är en ingenjörsschemaläggningsskola, mer som en "operativsystemkärna", lämplig för tydliga statsgränser, kontrollerbar högfrekvent handel, är en hårdvaruingenjörsstil, för att köra kedjan som hårdvara (parallell exekvering av hårdvarukvalitet); Aptos är ett systemfeltolerant, mer som en "database concurrency engine", lämplig för kontraktssystem med stark tillståndskoppling och komplexa anropskedjor. Aptos och Sui är som programmeringsspråksingenjörer, och resurssäkerhet i programvaruklass representerar den tekniska implementeringsvägen för Web3 parallell databehandling under olika filosofier.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 är en högpresterande transaktionell offentlig kedja byggd baserat på Cosmos SDK, och dess parallellitetsförmåga återspeglas huvudsakligen i två aspekter: den flertrådade matchningsmotorn (Parallel Matching Engine) och den parallella exekveringsoptimeringen av det virtuella maskinlagret, som är utformad för att betjäna högfrekventa transaktionsscenarier på kedjan med låg latens, såsom orderbok DEX, Infrastruktur för utbyte på kedjan, etc.

  Core Parallel Mechanism (Mekanism för parallell parallellitet

  1. ): Parallel Matching Engine: SEI V2 introducerar en flertrådad exekveringsväg i ordermatchningslogiken, som delar upp den väntande orderboken och matchningslogiken på trådnivå, så att matchningsuppgifterna mellan flera handelspar kan bearbetas parallellt och undvika den enkeltrådade flaskhalsen.
  2. Samtidighetsoptimering på virtuell maskinnivå: Sei V2 bygger en CosmWasm-körningsmiljö med funktioner för samtidig körning, vilket gör att vissa kontraktsanrop kan köras parallellt utan tillståndskonflikter, och samarbetar med klassificeringsmekanismen för transaktionstyp för att uppnå högre genomströmningskontroll.
  3. Parallell konsensus- och exekveringslagerschemaläggning: Den så kallade "Twin-Turbo"-konsensusmekanismen introduceras för att stärka genomströmningen och frikopplingen mellan konsensuslagret och exekveringslagret och förbättra den övergripande blockbearbetningseffektiviteten.

  3.4 UTXO Model Reformer Fuel Fuel är

  ett högpresterande exekveringsskikt designat baserat på Ethereums modulära arkitektur, och dess kärnparallellitetsmekanism härrör från den förbättrade UTXO-modellen (Unspent Transaction Output). Till skillnad från Ethereums kontomodell använder Fuel en UTXO-struktur för att representera tillgångar och stater, som i sig är tillståndsisolerad, vilket gör det enkelt att avgöra vilka transaktioner som säkert kan utföras parallellt. Dessutom introducerar Fuel sitt egenutvecklade smarta kontraktsspråk Sway (liknande Rust), i kombination med statiska analysverktyg, för att bestämma ingångskonflikter innan transaktioner utförs, för att uppnå effektiv och säker parallell schemaläggning på transaktionsnivå. Det är ett EVM-alternativt exekveringslager som balanserar prestanda och modularitet.

  4. Aktörsmodell: Ett nytt paradigm för samtidig exekvering

  av agenter Aktörsmodell är ett parallellt exekveringsparadigm baserat på agent eller process, som skiljer sig från den traditionella synkrona databehandlingen av globalt tillstånd i kedjan (Solana/Sui/Monad och andra "on-chain parallel computing"-scenarier), som betonar att varje agent har ett oberoende tillstånd och beteende, och kommunicerar och schemalägger genom asynkrona meddelanden. Under denna arkitektur kan on-chain-systemet köras samtidigt av ett stort antal processer som är frikopplade från varandra och har stark skalbarhet och asynkron feltolerans. Representativa projekt inkluderar AO (Arweave AO), ICP (Internet Computer) och Cartesi, som driver utvecklingen av blockchain från en exekveringsmotor till ett "on-chain-operativsystem", vilket tillhandahåller en inbyggd infrastruktur för AI-agenter, interaktioner med flera uppgifter och komplex logisk orkestrering.

  Även om utformningen av aktörsmodellen liknar horisontell partitionering när det gäller ytliga egenskaper (t.ex. parallellitet, tillståndsisolering och asynkron bearbetning), representerar de två i huvudsak helt olika tekniska vägar och systemfilosofier. Aktörsmodellen betonar "asynkron databehandling med flera processer", där varje agent körs oberoende, upprätthåller tillstånd oberoende och interagerar på ett meddelandedrivet sätt. Sharding, å andra sidan, är en "horisontell sharding av tillstånd och konsensus"-mekanism, som delar upp hela blockkedjan i flera delsystem (shards) som bearbetar transaktioner oberoende av varandra. Aktörsmodeller är mer som ett "distribuerat agentoperativsystem" i Web3-världen, medan sharding är en strukturell skalningslösning för transaktionsbearbetningsfunktioner i kedjan. Båda uppnår parallellitet, men har olika startpunkter, mål och körningsarkitekturer.

  4.1 AO (Arweave), en superparallell dator ovanpå lagringslagretAO

  är en decentraliserad datorplattform som körs på det permanenta lagringslagret Arweave, med huvudmålet att bygga ett operativsystem på kedjan som stöder driften av storskaliga asynkrona agenter.

  Kärnarkitekturfunktioner:

  • Processarkitektur: Varje agent kallas en process, med oberoende tillstånd, oberoende schemaläggare och körningslogik;
  • Ingen blockchain-struktur: AO är inte en kedja, utan ett decentraliserat lagringslager + meddelandedriven exekveringsmotor med flera agenter baserad på Arweave;
  • System för schemaläggning av asynkrona meddelanden: Processer kommunicerar med varandra via meddelanden, antar en låsfri asynkron driftsmodell och stöder naturligtvis samtidig expansion.
  • Permanent tillståndslagring: Alla agenttillstånd, meddelandeposter och instruktioner registreras permanent på Arweave, vilket säkerställer full granskningsbarhet och decentraliserad transparens.
  • Agent-native: Den är lämplig för att distribuera komplexa flerstegsuppgifter (t.ex. AI-agenter, DePIN-protokollkontroller, automatiska uppgiftsorkestrerare osv.) och kan bygga en "on-chain AI-coprocessor".

  AO tar den ultimata vägen med "agent native + storage driver + chainless architecture", med betoning på flexibilitet och modulfrikoppling, och är ett "mikrokärnramverk på kedjan byggt ovanpå lagringslagret", där systemgränsen avsiktligt krymper, med betoning på lättviktsberäkning + komponerbar kontrollstruktur.

  4.2 ICP (Internet Computer), en fullstack Web3-värdplattformICP

  är en Web3-inbyggd fullstack on-chain-applikationsplattform lanserad av DFINITY, med målet att utöka on-chain datorkraft till Web2-liknande upplevelser och stödja komplett tjänstehosting, domännamnsbindning och serverlös arkitektur.

  Kärnarkitekturfunktioner:

  • Kapselarkitektur (containrar som agenter): Varje behållare är en agent som körs på en virtuell Wasm-dator med oberoende tillstånd, kod och asynkrona schemaläggningsfunktioner;
  • Subnet Distributed Consensus System (Subnet): Hela nätverket består av flera subnät, som var och en upprätthåller en uppsättning behållare och når konsensus genom BLS-signaturmekanismen.
  • Asynkron anropsmodell: Canister kommunicerar med Canister genom asynkrona meddelanden, stöder icke-blockerande körning och har naturlig parallellitet.
  • Webbhotell på kedjan: Det stöder smarta kontrakt för att direkt vara värd för front-end-sidor, inbyggd DNS-mappning och är den första blockchain-plattformen som stöder webbläsare för att direkt komma åt dApps;
  • Systemet har kompletta funktioner: Det har system-API:er som on-chain hot upgrade, identitetsautentisering, distribuerad slumpmässighet och timer, som är lämplig för komplex on-chain-tjänstdistribution.

  ICP väljer ett operativsystemparadigm med tung plattform, integrerad förpackning och stark plattformskontroll, och har ett "blockchain-operativsystem" som integrerar konsensus, utförande, lagring och åtkomst, med betoning på kompletta tjänstevärdfunktioner och utökar systemgränsen till en fullstack Web3-värdplattform.

  Dessutom kan parallella databehandlingsprojekt från andra paradigm för aktörsmodeller hänvisas till följande tabell:

  

  5. Sammanfattning och utsiktBaserat

  på skillnaderna mellan virtuell maskinarkitektur och språksystem kan blockchain-parallella databehandlingslösningar grovt delas in i två kategorier: EVM parallell förbättringskedja och inbyggd parallell arkitekturkedja (icke-EVM).

  På grundval av att behålla kompatibiliteten hos EVM/Solidity-ekosystemet uppnår den förstnämnda högre genomströmning och parallell bearbetningskapacitet genom djupgående optimering av exekveringsskiktet, vilket är lämpligt för scenarier som vill ärva Ethereum-tillgångar och utvecklingsverktyg och samtidigt uppnå prestandagenombrott. Representativa projekt inkluderar:

  • Monad: Implementerar en optimistisk parallell exekveringsmodell som är kompatibel med EVM genom upptäckt av uppskjuten skrivning och körtidskonflikter, bygger beroendediagram och schemalägger körning efter att konsensus är uppfylld.
  • MegaETH: Abstraherar varje konto/kontrakt till en oberoende mikro-VM och implementerar mycket frikopplad parallell schemaläggning på kontonivå baserat på asynkrona meddelanden och tillståndsberoende grafer.
  • Pharos: Skapa en sammanslagningsnätarkitektur för att uppnå parallell bearbetning på systemnivå mellan processer via asynkrona pipelines och SPN-moduler.
  • Reddio: Använder zkRollup + GPU-arkitekturen för att påskynda verifieringsprocessen utanför kedjan för zkEVM genom batch-SNARK-generering och förbättra verifieringsgenomströmningen.

  Den senare gör sig helt av med begränsningarna i Ethereums kompatibilitet och omformar exekveringsparadigmet från den virtuella maskinen, tillståndsmodellen och schemaläggningsmekanismen för att uppnå inbyggd högpresterande samtidighet. Typiska underklasser inkluderar:

  • Solana (SVM): en parallell körningsmodell på kontonivå baserad på kontoåtkomstanspråk och statisk schemaläggning av konfliktdiagram;
  • Sui / Aptos (MoveVM-system): Baserat på resursobjektmodellen och typsystemet stöder den statisk analys vid kompileringstillfället och realiserar parallellitet på objektnivå.
  • Sei V2 (Cosmos SDK-väg): introducerar en flertrådad matchningsmotor och samtidighetsoptimering av virtuella datorer i Cosmos-arkitekturen, som är lämplig för transaktionella högfrekvensprogram.
  • Bränsle (UTXO + Sway-arkitektur): Parallellitet på transaktionsnivå genom statisk analys av UTXO-ingångsuppsättningen, som kombinerar ett modulärt exekveringslager med ett anpassat smart kontraktsspråk Sway;

  Dessutom, som ett mer generaliserat parallellt system, skapar aktörsmodellen ett körningsparadigm i kedjan för "oberoende drift med flera agenter + meddelandedrivet samarbete" via en asynkron processschemaläggningsmekanism baserad på Wasm eller anpassade virtuella datorer. Representativa projekt inkluderar:

  • AO (Arweave AO): Att bygga ett asynkront mikrokärnsystem på kedjan baserat på den beständiga lagringsdrivna agentkörningen;
  • ICP (Internet Computer): använder den containerbaserade agenten (Canister) som den minsta enheten för att uppnå asynkron och mycket skalbar körning genom undernätskoordinering.
  • Cartesi: Introducerar Linux-operativsystemet som en off-chain databehandlingsmiljö för att tillhandahålla en verifieringsväg på kedjan för betrodda datorresultat, lämplig för komplexa eller resurskrävande applikationsscenarier.

  Baserat på ovanstående logik kan vi sammanfatta det nuvarande vanliga schemat för parallell databehandling i en klassificeringsstruktur som visas i följande figur:

  

  Ur ett bredare skalningsperspektiv fokuserar horisontell partitionering och rollup (L2) på horisontell skalning genom tillståndshorisontell partitionering eller off-chain-körning, medan parallella beräkningskedjor (t.ex. Monad, Sui, Solana) och aktörsorienterade system (t.ex. AO, ICP) direkt rekonstruerar körningsmodellen och uppnår inbyggd parallellitet inom kedjan eller på systemlagret. Den förstnämnda förbättrar genomströmningen inom kedjan genom flertrådade virtuella maskiner, objektmodeller, analys av transaktionskonflikter, etc.; Den senare tar processen/agenten som grundenhet och antar meddelandedrivna och asynkrona körningslägen för att uppnå samtidig drift med flera agenter. Däremot är sharding och rollups mer som att "dela upp lasten till flera kedjor" eller "outsourca off-chain", medan den parallella kedjan och aktörsmodellen "frigör prestandapotentialen från själva exekveringsmotorn", vilket återspeglar en mer grundlig arkitektonisk utveckling.

  Parallell databehandling vs Sharding Architecture vs Rollup Scaling vs Actor Oriented Scaling Path Comparison

  Det bör påpekas att de flesta av de inhemska parallella arkitekturkedjorna har gått in i lanseringsstadiet för huvudnätet, även om det övergripande utvecklarekosystemet fortfarande är svårt att jämföra med EVM-systemets Solidity-system, men de projekt som representeras av Solana och Sui, med sin högpresterande exekveringsarkitektur och det gradvisa välståndet för ekologiska applikationer, har blivit de centrala offentliga kedjorna som marknaden ägnar stor uppmärksamhet åt.

  Däremot, även om Ethereum Rollup (L2)-ekosystemet har gått in i stadiet med "10 000 kedjor på en gång" eller till och med "överkapacitet", är den nuvarande vanliga EVM-parallellförbättringskedjan fortfarande i allmänhet i testnätstadiet och har ännu inte verifierats av den faktiska huvudnätmiljön, och dess skalningsförmåga och systemstabilitet behöver fortfarande testas ytterligare. Det återstår att se om dessa projekt kan förbättra EVM-prestandan avsevärt och driva ekologiska språng utan att offra kompatibiliteten, eller om de ytterligare kan differentiera Ethereums likviditet och utvecklingsresurser.