Web3 Parallel Computing Track Panorama: de beste oplossing voor native schaling?

Auteur: 0xjacobzhao en ChatGPT 4oHet

"Blockchain Trilemma" van "beveiliging", "decentralisatie" en "schaalbaarheid" van de blockchain onthult de essentiële afweging in het ontwerp van blockchain-systemen, dat wil zeggen, het is moeilijk voor blockchain-projecten om tegelijkertijd "extreme beveiliging, iedereen kan deelnemen en snelle verwerking" te bereiken. Als reactie op het eeuwige onderwerp "schaalbaarheid", zijn de mainstream blockchain-schaaloplossingen op de markt onderverdeeld op basis van paradigma's, waaronder:

• Execution-enhanced scaling: Verbetert de uitvoeringsmogelijkheden ter plaatse, zoals parallellisme, GPU en multi-core
• State-isolated scaling: Horizontaal gesplitste state/shard, bijv. shards, UTXO en multi-subnetten
• Off-chain uitbestede schaling: Uitvoering off-chain plaatsen, zoals rollups, Ontkoppeling van coprocessor- en
• DA-structuurschaling: modulaire architectuur en collaboratieve werking, zoals moduleketen, gedeelde sequencer, Rollup Mesh
• Asynchrone gelijktijdige schaling: actormodel, procesisolatie, berichtgestuurd, zoals agent, multi-threaded asynchrone keten

  De blockchain-schaaloplossing omvat: on-chain parallel computing, rollup, sharding, DA-module, modulaire structuur, actorsysteem, zk-proof compressie, stateless architectuur, enz., die meerdere niveaus van uitvoering, status, gegevens en structuur bestrijkt, en is een compleet schaalsysteem van "meerlaagse samenwerking en modulecombinatie". Dit artikel richt zich op schaalmethoden die parallel computing mainstreamen.

  Intra-chain parallellisme, dat zich richt op de parallelle uitvoering van intra-block transacties/instructies. Volgens het parallelle mechanisme kunnen de schaalmethoden worden onderverdeeld in vijf categorieën, die elk een ander prestatiestreven, ontwikkelingsmodel en architectuurfilosofie vertegenwoordigen, en de parallelle granulariteit wordt steeds fijner, de parallellisme-intensiteit wordt steeds hoger, de planningscomplexiteit wordt steeds hoger, en de programmeercomplexiteit en implementatiemoeilijkheid worden ook steeds hoger.

  • Account-level: Vertegenwoordigt het project
  • Object-level: Vertegenwoordigt het project
  • Sui Transaction-level: Vertegenwoordigt het project Monad, Aptos
  • Call-level / MicroVM : MegaETH op instructieniveau
  :
  • GatlingX

  Het off-chain asynchrone gelijktijdigheidsmodel, vertegenwoordigd door het Actor / Actor Model, behoort tot een ander parallel computerparadigma, als een cross-chain/asynchroon berichtensysteem (niet-bloksynchronisatiemodel), elke agent wordt onafhankelijk uitgevoerd als een "agentproces", asynchrone berichten in parallelle modus, gebeurtenisgestuurd, geen synchrone planning, representatieve projecten zoals AO, ICP, Cartesi, enz.

  Het bekende rollup- of shard-schalingsschema behoort tot het gelijktijdigheidsmechanisme op systeemniveau, niet tot de parallelle computing binnen de keten. Ze bereiken schaalbaarheid door "meerdere ketens/uitvoeringsdomeinen parallel te laten draaien", in plaats van het parallellisme binnen een enkel blok/virtuele machine te vergroten. Dit type schaaloplossing is niet de focus van dit artikel, maar we zullen het toch gebruiken om de overeenkomsten en verschillen in architecturale concepten te vergelijken.

  

  2. EVM parallelle verbeteringsketen: de prestatiegrens in compatibiliteit

  doorbreken Sinds de ontwikkeling van de seriële verwerkingsarchitectuur van Ethereum heeft het meerdere rondes van schaalpogingen ondergaan, zoals sharding, rollup en modulaire architectuur, maar het doorvoerknelpunt van de uitvoeringslaag is nog steeds niet fundamenteel doorbroken. Maar tegelijkertijd zijn EVM en Solidity nog steeds de slimme contractplatforms met de meeste ontwikkelaarsbasis en ecologisch potentieel. Daarom wordt de parallelle verbeteringsketen van EVM een belangrijke richting voor een nieuwe ronde van opschaling en evolutie als een belangrijk pad dat rekening houdt met ecologische compatibiliteit en verbetering van de uitvoeringsprestaties. Monad en MegaETH zijn de meest representatieve projecten in deze richting, te beginnen met respectievelijk uitgestelde uitvoering en statusdecompositie, om een EVM-parallelle verwerkingsarchitectuur te bouwen voor scenario's met hoge gelijktijdigheid en hoge doorvoer.

  Monad's Parallel

  Computing-analyseMonad is een krachtige Layer1-blockchain die opnieuw is ontworpen voor de Ethereum Virtual Machine (EVM), gebaseerd op het basisconcept van parallelle pipelining, met asynchrone uitvoering op de consensuslaag en optimistische gelijktijdigheid op de uitvoeringslaag Parallelle uitvoering) 。 Bovendien heeft Monad op de consensus- en opslaglagen respectievelijk het krachtige BFT-protocol (MonadBFT) en een speciaal databasesysteem (MonadDB) geïntroduceerd om end-to-end optimalisatie te bereiken.

  Pipelining: Multi-stage pipeline parallel executiemechanisme

  Pipelining is het basisconcept van Monad parallelle uitvoering, en het kernidee is om het uitvoeringsproces van de blockchain op te splitsen in meerdere onafhankelijke fasen, en deze fasen parallel te verwerken om een driedimensionale pijplijnarchitectuur te vormen, elke fase draait op onafhankelijke threads of cores om gelijktijdige verwerking van meerdere blokken te bereiken. Het resultaat is een hogere doorvoer en een verminderde latentie. Deze fasen omvatten: voorstellen, consensus, uitvoering en toezeggen.

  Asynchrone uitvoering: consensus - uitvoering is asynchroon ontkoppeldOp

  traditionele ketens zijn transactieconsensus en uitvoering vaak synchrone processen, en dit seriële model beperkt het schalen van prestaties ernstig. Monad implementeert de consensuslaag asynchroon, de uitvoeringslaag asynchroon en de opslag asynchroon door middel van "asynchrone uitvoering". Verminder de bloktijd en bevestigingslatentie aanzienlijk, waardoor het systeem veerkrachtiger wordt, de verwerking meer gesegmenteerd wordt en resources worden gebruikt.

  Kernontwerp:

  Het
  • consensusproces (consensuslaag) is alleen verantwoordelijk voor het sorteren van transacties en voert geen contractlogica uit.
  • Het uitvoeringsproces (uitvoeringslaag) wordt asynchroon geactiveerd nadat de consensus is voltooid.
  • Nadat de consensus is voltooid, gaat deze onmiddellijk het consensusproces van het volgende blok in, zonder te wachten tot de uitvoering is voltooid.

  Optimistische parallelle uitvoering: optimistische parallelle uitvoeringTraditioneel

  Ethereum hanteert een strikt serieel model voor de uitvoering van transacties om staatsconflicten te voorkomen. Monad, aan de andere kant, hanteert een "optimistische parallelle uitvoering"-strategie om de verwerkingssnelheid van transacties aanzienlijk te verhogen.

  Uitvoeringsmechanisme:

  • Monad voert optimistisch alle transacties parallel uit, ervan uitgaande dat de meeste transacties staatloos en conflictvrij zijn.
  • Voer ook een "Conflict Detector" uit om te controleren of dezelfde status (bijv. lees-/schrijfconflicten) wordt benaderd tussen transacties.
  • Als er een conflict wordt gedetecteerd, wordt de conflicterende transactie geserialiseerd en opnieuw uitgevoerd om ervoor te zorgen dat de status correct is.

  Monad heeft een compatibel pad gekozen: om zo min mogelijk EVM-regels te verplaatsen, parallellisme te bereiken door de schrijfstatus uit te stellen en conflicten dynamisch te detecteren tijdens de uitvoering, wat meer lijkt op een prestatieversie van Ethereum, met een volwassenheidsniveau dat het gemakkelijk maakt om te migreren naar het EVM-ecosysteem, en is een parallelle versneller in de EVM-wereld.

  De resolutie van het parallelle computermechanisme van MegaETH

  verschilt van de L1-positionering van Monad, en MegaETH is gepositioneerd als een EVM-compatibele modulaire high-performance parallelle uitvoeringslaag, die kan worden gebruikt als een onafhankelijke L1 openbare keten, als een uitvoeringsverbeteringslaag of modulaire component op Ethereum. Het belangrijkste ontwerpdoel is om de accountlogica, uitvoeringsomgeving en statusisolatie te deconstrueren in de kleinste eenheid die onafhankelijk kan worden gepland om uitvoering met hoge gelijktijdigheid en responsvermogen met lage latentie binnen de keten te bereiken. De belangrijkste innovatie die door MegaETH wordt voorgesteld, is dat de Micro-VM-architectuur + State Dependency DAG (directed and acyclic state dependency graph) en het modulaire synchronisatiemechanisme gezamenlijk een parallel uitvoeringssysteem bouwen voor "intra-chain threading".

  Micro-VM-architectuur: Accounts zijn threads

  MegaETH introduceert het uitvoeringsmodel van "één micro-VM per account", dat de uitvoeringsomgeving "threads" en een minimale isolatie-eenheid biedt voor parallelle planning. Deze VM's communiceren met elkaar via asynchrone berichten in plaats van synchrone aanroepen, en een groot aantal VM's kan onafhankelijk worden uitgevoerd, onafhankelijk worden opgeslagen en op natuurlijke wijze parallel worden uitgevoerd.

  State Dependency DAG: een grafiekgestuurd planningsmechanisme

  MegaETH heeft een DAG-planningssysteem gebouwd op basis van de toegangsrelatie tot de accountstatus, en het systeem onderhoudt in realtime een wereldwijde afhankelijkheidsgrafiek, en welke accounts worden gewijzigd en welke accounts voor elke transactie worden gelezen, worden allemaal gemodelleerd in afhankelijkheden. Conflictvrije transacties kunnen direct parallel worden uitgevoerd, en afhankelijke transacties worden gepland en serieel gesorteerd of uitgesteld in topologische volgorde. Afhankelijkheidsgrafieken zorgen voor statusconsistentie en niet-dubbele schrijfbewerkingen tijdens parallelle uitvoering.

  Het

  asynchrone uitvoerings- en callback-mechanisme

  MegaETH is gebouwd op het asynchrone programmeerparadigma, vergelijkbaar met het asynchrone doorgeven van berichten van het Actor Model, om het probleem van traditionele EVM-seriële aanroepen op te lossen. Contractaanroepen zijn asynchroon (niet-recursieve uitvoering) en wanneer contract A -> B -> C wordt aangeroepen, is elke aanroep asynchroon zonder het wachten te blokkeren; De gespreksstack wordt uitgebreid tot een asynchrone oproepgrafiek; Transactieverwerking = doorlopen van asynchrone grafiek + afhankelijkheidsresolutie + parallelle planning.

  Al met al doorbreekt MegaETH het traditionele EVM single-threaded state machine-model, implementeert het inkapseling van micro-virtuele machines op een account-per-account-basis, voert het transactieplanning uit via statusafhankelijke grafieken en vervangt het de synchrone oproepstapel door een asynchroon berichtenmechanisme. Het is een parallel computerplatform dat opnieuw is ontworpen vanuit de volledige dimensies van "accountstructuur→ planningsarchitectuur, → uitvoeringsproces", en biedt een nieuw idee op paradigmaniveau voor het bouwen van een high-performance on-chain-systeem van de volgende generatie.

  MegaETH heeft gekozen voor het refactoring-pad: het abstraheert accounts en contracten volledig tot onafhankelijke VM's en ontketent het ultieme parallellismepotentieel door middel van asynchrone uitvoeringsplanning. Theoretisch heeft MegaETH een hogere parallelle limiet, maar het is ook moeilijker om de complexiteit te beheersen, en het lijkt meer op een supergedistribueerd besturingssysteem onder het Ethereum-concept.

  

  Monad en MegaETH Beide hebben andere ontwerpconcepten dan sharding: sharding verdeelt de blockchain horizontaal in meerdere onafhankelijke subketens (shards), die elk verantwoordelijk zijn voor een deel van de transacties en de staat, waardoor de single-chain-beperking wordt doorbroken en schaalbaar is op de netwerklaag; Aan de andere kant behouden zowel Monad als MegaETH de integriteit van de enkele keten, schalen ze alleen horizontaal op de uitvoeringslaag en voeren ze parallel optimalisatiedoorbraken uit aan de limiet van de enkele keten. De twee vertegenwoordigen twee richtingen: verticale versterking en horizontale expansie in het blockchain-uitbreidingspad.

  Parallelle computerprojecten zoals Monad en MegaETH richten zich voornamelijk op het optimalisatiepad van de doorvoer, met als kerndoel het verbeteren van on-chain TPS en het bereiken van parallelle verwerking op transactieniveau of accountniveau door middel van uitgestelde uitvoering en micro-VM-architecturen. Pharos Network is een modulair, full-stack parallel L1 blockchain-netwerk en het parallelle kerncomputersysteem wordt "Rollup Mesh" genoemd. Deze architectuur ondersteunt omgevingen met meerdere virtuele machines (EVM en Wasm) via de synergie van mainnet en speciale verwerkingsnetwerken (SPN's) en integreert geavanceerde technologieën zoals zero-knowledge proofs (ZK) en trusted execution environments (TEE's).

  Rollup Mesh Parallel Computing-analyse:

  1. Asynchrone pipelining gedurende de volledige levenscyclus: Pharos ontkoppelt de verschillende fasen van een transactie (zoals consensus, uitvoering en opslag) en past asynchrone verwerking toe, zodat elke fase onafhankelijk en parallel kan worden uitgevoerd, waardoor de algehele verwerkingsefficiëntie wordt verbeterd.
  2. Dubbele VM parallelle uitvoering: Pharos ondersteunt zowel EVM- als WASM-omgevingen voor virtuele machines, waardoor ontwikkelaars de juiste uitvoeringsomgeving voor hun behoeften kunnen kiezen. Deze dual-VM-architectuur verhoogt niet alleen de flexibiliteit van het systeem, maar verhoogt ook de transactieverwerking door parallelle uitvoering.
  3. Special Processing Networks (SPN's): SPN's zijn belangrijke componenten in de Pharos-architectuur, vergelijkbaar met modulaire subnetwerken die zijn ontworpen om specifieke soorten taken of toepassingen aan te kunnen. Met SPN's maakt Pharos dynamische toewijzing van middelen en parallelle verwerking van taken mogelijk, waardoor de schaalbaarheid en prestaties van het systeem verder worden verbeterd.
  4. Modulaire consensus en restaking: Pharos introduceert een flexibel consensusmechanisme dat meerdere consensusmodellen ondersteunt (zoals PBFT, PoS, PoA) en maakt veilig delen en resource-integratie tussen het mainnet en SPN's mogelijk via het herstaking-protocol.

  Daarnaast reconstrueert Pharos het uitvoeringsmodel vanaf de onderste laag van de opslagengine door middel van multi-versie Merkle tree, Delta Encoding, Versioned Addressing en ADS Pushdown-technologie, en lanceert Pharos Store, een krachtige opslagengine voor de native blockchain, om een hoge doorvoer, lage latentie en sterke verifieerbare on-chain verwerkingsmogelijkheden te bereiken.

  Over het algemeen bereikt de Rollup Mesh-architectuur van Pharos krachtige parallelle computermogelijkheden door middel van een modulair ontwerp en een asynchroon verwerkingsmechanisme.

  Naast de parallelle uitvoeringsarchitecturen van Monad, MegaETH en Pharos, zien we ook dat er enkele projecten op de markt zijn die het toepassingspad van GPU-versnelling in EVM parallel computing onderzoeken, als een belangrijke aanvulling en baanbrekend experiment voor het parallelle EVM-ecosysteem. Onder hen zijn Reddio en GatlingX twee representatieve richtingen:

  • Reddio is een high-performance platform dat zkRollup en GPU parallelle uitvoeringsarchitectuur combineert, en de kern ligt in het reconstrueren van het EVM-uitvoeringsproces en het realiseren van de native parallellisatie van de uitvoeringslaag door middel van multi-threaded planning, asynchrone statusopslag en GPU-versnelde uitvoering van transactiebatches. Parallelle granulariteit op transactieniveau + bewerkingsniveau (multi-threaded execution opcode). Het is ontworpen om multi-threaded batchuitvoering, asynchroon laden van toestanden en GPU-parallelle verwerkingstransactielogica (CUDA-compatibele parallelle EVM) te introduceren. Net als Monad / MegaETH richt Reddio zich ook op parallelle verwerking op de uitvoeringslaag, met het verschil dat de uitvoeringsengine wordt gereconstrueerd via een GPU-parallelle architectuur, ontworpen voor high-throughput en rekenintensieve scenario's zoals AI-inferentie. GatlingX,
  • dat zichzelf "GPU-EVM" noemt, stelt een radicalere architectuur voor die probeert het "seriële uitvoering op instructieniveau"-model van traditionele virtuele EVM-machines te migreren naar een GPU-native parallelle runtime-omgeving. Het kernmechanisme is om de EVM-bytecode dynamisch te compileren in parallelle CUDA-taken en de instructiestroom uit te voeren via de GPU-multicore, om het sequentiële knelpunt van de EVM op het laagste niveau te doorbreken. Parallelle granulariteit die behoort tot parallellisme op instructieniveau (ILP). Vergeleken met de parallelle granulariteit op "transactieniveau/accountniveau" van Monad / MegaETH, behoort het parallelliteitsmechanisme van GatlingX tot het optimalisatiepad op instructieniveau, dat dichter bij de onderliggende refactoring van de virtuele machine-engine ligt. Het bevindt zich momenteel in de conceptfase, met een whitepaper en architectuurschets gepubliceerd, en nog geen SDK of mainnet.

  Artela stelt een gedifferentieerd, parallel ontwerpconcept voor. Met de introductie van de virtuele machine WebAssembly (WASM) van de EVM++-architectuur kunnen ontwikkelaars dynamisch on-chain extensies toevoegen en uitvoeren met behulp van het Aspect-programmeermodel met behoud van EVM-compatibiliteit. Het gebruikt de granulariteit van de contractaanroep (Functie / Uitbreiding) als de minimale parallelle eenheid en ondersteunt de injectie van uitbreidingsmodules (vergelijkbaar met "pluggable middleware") wanneer het EVM-contract wordt uitgevoerd, om logische ontkoppeling, asynchrone aanroep en parallelle uitvoering op moduleniveau te bereiken. Er wordt meer aandacht besteed aan de samenstelbaarheid en modulaire architectuur van de uitvoeringslaag. Het concept biedt nieuwe ideeën voor complexe toepassingen met meerdere modules in de toekomst.

  3. Native parallelle architectuurketen: Het EVM-uitvoeringsmodel van Ethereum, de uitvoeringsontologie van de gereconstrueerde VM,

  heeft sinds het begin van het ontwerp een single-threaded architectuur van "volledige transactieorder + seriële uitvoering" aangenomen, met als doel de zekerheid en consistentie van statuswijzigingen voor alle knooppunten in het netwerk te waarborgen. Deze architectuur heeft echter een natuurlijk knelpunt in prestaties, waardoor de systeemdoorvoer en schaalbaarheid worden beperkt. Daarentegen zijn native parallelle computerarchitectuurketens zoals Solana (SVM), MoveVM (Sui, Aptos) en Sei v2 die zijn gebouwd op de Cosmos SDK, op maat gemaakt voor parallelle uitvoering vanuit het onderliggende ontwerp en hebben ze de volgende voordelen:

  • Natuurlijke scheiding van statusmodellen: Solana gebruikt een declaratiemechanisme voor accountvergrendeling, MoveVM introduceert een objecteigendomsmodel en Sei v2 is gebaseerd op classificatie van het transactietype. Statische conflictbeoordeling wordt gerealiseerd en gelijktijdige planning op transactieniveau wordt ondersteund.
  • Virtuele machines zijn geoptimaliseerd voor gelijktijdigheid: Solana's Sealevel-engine ondersteunt native multi-threaded uitvoering; MoveVM kan statische gelijktijdigheidsgrafiekanalyse uitvoeren; Sei v2 integreert een multi-threaded matching engine met een parallelle VM-module.

  Natuurlijk staat dit soort inheemse parallelle keten ook voor de uitdaging van ecologische compatibiliteit. Niet-EVM-architecturen vereisen meestal nieuwe ontwikkeltalen (zoals Move en Rust) en toolchains, die bepaalde migratiekosten voor ontwikkelaars met zich meebrengen. Bovendien moeten ontwikkelaars een reeks nieuwe concepten onder de knie krijgen, zoals stateful access-modellen, gelijktijdigheidslimieten, objectlevenscycli, enz., die hogere eisen stellen aan het begrijpen van drempels en ontwikkelingsparadigma's.

  3.1 Het Sealevel parallelle motorprincipe van Solana en SVM

  Solana's Sealevel-uitvoeringsmodel is een mechanisme voor parallelle accountplanning, de kernengine die door Solana wordt gebruikt om de uitvoering van parallelle transacties binnen de keten te realiseren, en bereikt high-performance gelijktijdigheid op slim contractniveau via het mechanisme van "accountdeclaratie + statische planning + multi-threaded uitvoering". Sealevel is het eerste uitvoeringsmodel op het gebied van blockchain dat met succes gelijktijdige planning binnen de keten in een productieomgeving implementeert, en de architecturale ideeën hebben veel latere parallelle computerprojecten beïnvloed en zijn een referentieparadigma voor high-performance Layer 1 parallel ontwerp.

  Kernmechanisme:

  1. Expliciete lijsten met accounttoegang: Elke transactie moet de betrokken account aangeven (lezen/schrijven) bij het indienen, en het systeem zal bepalen of er een statusconflict is tussen transacties.

  2. Conflictdetectie en multi-threaded scheduling

  • Als er geen raakvlak is tussen de accountsets waartoe de twee transacties toegang hebben→ kunnen ze parallel worden uitgevoerd;
  • Er is een conflict→ dat achtereenvolgens in afhankelijke volgorde wordt uitgevoerd;
  • De planner wijst transacties toe aan verschillende threads op basis van de afhankelijkheidsgrafiek.

  3. Context van programma-aanroep: Elke contractaanroep wordt uitgevoerd in een geïsoleerde context zonder een gedeelde stack om interferentie tussen oproepen te voorkomen.

  Sealevel is Solana's parallelle uitvoeringsplanningsengine, terwijl SVM een slimme contractuitvoeringsomgeving is die bovenop Sealevel is gebouwd (met behulp van de virtuele BPF-machine). Samen vormen ze de technische basis van Solana's krachtige parallelle uitvoeringssysteem.

  Eclipse is een project dat Solana-VM's implementeert op modulaire ketens zoals Ethereum L2 of Celestia, waarbij gebruik wordt gemaakt van Solana's parallelle uitvoeringsengine als de rollup-uitvoeringslaag. Eclipse is een van de eerste projecten die voorstelt om de Solana-uitvoeringslaag (Sealevel + SVM) los te koppelen van het Solana-mainnet en deze te migreren naar een modulaire architectuur, en de modulaire uitvoer van Solana's "super concurrent execution model" is Execution Layer-as-a-Service, dus Eclipse behoort ook tot de categorie van parallel computing.

  De route van Neon is anders, het introduceert de EVM om te opereren in een SVM / Sealevel-omgeving. Bouw een EVM-compatibele runtime-laag, ontwikkelaars kunnen Solidity gebruiken om contracten te ontwikkelen en uit te voeren in de SVM-omgeving, maar de uitvoering van de planning maakt gebruik van SVM + Sealeve. Neon neigt meer naar de categorie Modular Blockchain dan naar parallelle computerinnovatie.

  Al met al vertrouwen Solana en SVM's op de Sealevel-uitvoeringsengine, en Solana's op besturingssystemen gebaseerde planningsfilosofie is vergelijkbaar met de kernelplanner, die snel maar relatief inflexibel is. Het is een native high-performance, parallel computing public chain.

  3.2 MoveVM-architectuur: resource- en objectgestuurd

  MoveVM is een virtuele machine met een slim contract die is ontworpen voor on-chain resourcebeveiliging en parallelle uitvoering, en de kerntaal, Move, is oorspronkelijk ontwikkeld door Meta (voorheen Facebook) voor het Libra-project, met de nadruk op het concept van "resources zijn objecten", en alle on-chain-staten bestaan als objecten, met duidelijke eigendom en levenscycli. Dit stelt MoveVM in staat om te analyseren of er statusconflicten zijn tussen transacties tijdens de compilatietijd, en statische parallelle planning op objectniveau te implementeren, die veel wordt gebruikt in native parallelle openbare ketens zoals Sui en Aptos.

  Sui's objecteigendomsmodelDe

  parallelle computermogelijkheden van Sui komen voort uit de unieke benadering van toestandsmodellering en statische analyse op taalniveau. In tegenstelling tot traditionele blockchains, die gebruik maken van wereldwijde toestandsbomen, heeft Sui een objectcentrisch model gebouwd op basis van het "object", dat werkt met het lineaire typesysteem van MoveVM om van parallelle planning een deterministisch proces te maken dat kan worden voltooid tijdens het compileren.

  • Het objectmodel is de basis van Sui's parallelle architectuur. Sui abstraheert alle toestanden in de keten tot afzonderlijke objecten, elk met een unieke ID, een duidelijke eigenaar (account of contract) en een typedefinitie. Deze objecten delen geen toestand met elkaar en zijn inherent geïsoleerd. Het contract moet de verzameling van betrokken objecten expliciet aangeven wanneer deze wordt opgeroepen, waardoor het probleem van de staatskoppeling van de traditionele on-chain "global state tree" wordt vermeden. Dit ontwerp splitst de on-chain-status op in verschillende onafhankelijke eenheden, waardoor gelijktijdige uitvoering een structureel haalbaar planningsuitgangspunt wordt.
  • Statische eigendomsanalyse is een analysemechanisme voor compilatietijd dat wordt geïmplementeerd met behulp van het lineaire typesysteem van de Move-taal. Het stelt het systeem in staat om transacties te plannen die parallel moeten worden uitgevoerd door af te leiden welke transacties geen statusconflicten hebben door middel van objecteigendom voordat ze worden uitgevoerd. Vergeleken met de conflictdetectie en het terugdraaien van traditionele runtimes, vermindert het statische analysemechanisme van Sui de complexiteit van de planning aanzienlijk en verbetert het de efficiëntie van de uitvoering, wat de sleutel is tot het bereiken van een hoge doorvoer en deterministische parallelle verwerkingsmogelijkheden.

  Sui verdeelt de toestandsruimte op een object-voor-object basis, gecombineerd met compile-time eigendomsanalyse, om goedkope, rollback-vrije parallelle uitvoering op objectniveau te bereiken. Vergeleken met de seriële uitvoering of runtime-detectie van traditionele ketens, heeft Sui aanzienlijke verbeteringen bereikt in de efficiëntie van de uitvoering, het systeemdeterminisme en het gebruik van hulpbronnen.

  Aptos' Block-STM Execution

  MechanismAptos is een krachtige Layer1 blockchain gebaseerd op de Move-taal, en de parallelle uitvoeringscapaciteit is voornamelijk afgeleid van het zelf ontwikkelde Block-STM (Block-level Software Transactional Memory) framework. In tegenstelling tot Sui's strategie van "statisch parallellisme tijdens het compileren", behoort Block-STM tot het dynamische planningsmechanisme van "optimistische gelijktijdigheid bij runtime + conflict rollback", dat geschikt is voor het omgaan met transactiesets met complexe afhankelijkheden.

  Block-STM verdeelt de uitvoering van de transactie van een blok in drie fasen:

  • Speculatieve uitvoering: Alle transacties zijn standaard conflictvrij voordat ze worden uitgevoerd, en het systeem plant transacties parallel aan meerdere threads om te proberen gelijktijdig uit te voeren, en registreert de accountstatus (lees-/schrijfset) die door hen wordt geopend.
  • Validatiefase: Het systeem verifieert het uitvoeringsresultaat: als er een lees-schrijfconflict is tussen twee transacties (Tx1 leest bijvoorbeeld de status van geschreven door Tx2), wordt een van deze teruggedraaid.
  • Fase opnieuw proberen: Conflicterende transacties worden opnieuw gepland totdat hun afhankelijkheden zijn opgelost, en uiteindelijk vormen alle transacties een geldige, deterministische reeks statusinzendingen.

  Block-STM is een dynamisch uitvoeringsmodel van "optimistisch parallellisme + rollback en nieuwe pogingen", dat geschikt is voor staatsintensieve en logisch complexe on-chain transactiebatchverwerkingsscenario's, en is de parallelle computing-kern voor Aptos om een openbare keten met hoge veelzijdigheid en hoge doorvoer te bouwen.

  

  Solana is een technische planningsschool, meer als een "besturingssysteemkernel", geschikt voor duidelijke staatsgrenzen, controleerbare hoogfrequente handel, is een hardware-ingenieursstijl, om de keten te runnen als hardware (Hardware-grade parallelle uitvoering); Aptos is een systeemfouttolerant, meer als een "database concurrency engine", geschikt voor contractsystemen met sterke state-koppeling en complexe aanroepketens. Aptos en Sui zijn als programmeertaalingenieurs, en software-grade resource security vertegenwoordigt het technische implementatiepad van Web3 parallel computing onder verschillende filosofieën.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 is een krachtige transactionele openbare keten die is gebouwd op basis van de Cosmos SDK, en de parallelliteitsmogelijkheid wordt voornamelijk weerspiegeld in twee aspecten: de multi-threaded matching engine (Parallel Matching Engine) en de parallelle uitvoeringsoptimalisatie van de virtuele machinelaag, die is ontworpen om on-chain transactiescenario's met hoge frequentie en lage latentie te bedienen, zoals orderboek DEX, on-chain uitwisselingsinfrastructuur, enz.

  Kernparallelliteitsmechanisme:

  1. Parallelle overeenkomstmotor: SEI V2 introduceert een multi-threaded uitvoeringspad in de ordervergelijkingslogica, waarbij het hangende orderboek en de overeenkomstlogica op threadniveau worden gesplitst, zodat de overeenkomende taken tussen meerdere handelsparen parallel kunnen worden verwerkt en de single-threaded bottleneck kan worden vermeden.
  2. Optimalisatie van gelijktijdigheid op virtueel-machineniveau: Sei V2 bouwt een CosmWasm-runtime-omgeving met gelijktijdige uitvoeringsmogelijkheden, waardoor sommige contractaanroepen parallel kunnen worden uitgevoerd zonder statusconflicten, en werkt samen met het classificatiemechanisme voor transactietypen om een hogere doorvoercontrole te bereiken.
  3. Parallelle consensus- en uitvoeringslaagplanning: Het zogenaamde "Twin-Turbo" consensusmechanisme wordt geïntroduceerd om de doorvoer en ontkoppeling tussen de consensuslaag en de uitvoeringslaag te versterken en de algehele efficiëntie van de blokverwerking te verbeteren.

  3.4 UTXO Model Reformer Fuel Fuel

  is een high-performance uitvoeringslaag die is ontworpen op basis van de modulaire architectuur van Ethereum, en het kernparallellismemechanisme is afgeleid van het verbeterde UTXO-model (Unspent Transaction Output). In tegenstelling tot het accountmodel van Ethereum, gebruikt Fuel een UTXO-structuur om activa en staten weer te geven, die inherent staatsgeïsoleerd is, waardoor het gemakkelijk is om te bepalen welke transacties veilig parallel kunnen worden uitgevoerd. Daarnaast introduceert Fuel zijn zelfontwikkelde slimme contracttaal Sway (vergelijkbaar met Rust), gecombineerd met statische analysetools, om invoerconflicten te bepalen voordat transacties worden uitgevoerd, om zo een efficiënte en veilige parallelle planning op transactieniveau te bereiken. Het is een alternatieve uitvoeringslaag van EVM die prestaties en modulariteit in evenwicht houdt.

  4. Actormodel: een nieuw paradigma van gelijktijdige uitvoering

  van agenten Actormodel is een parallel uitvoeringsparadigma op basis van agent of proces, dat verschilt van de traditionele synchrone computing van de wereldtoestand in de keten (Solana/Sui/Monad en andere "on-chain parallel computing"-scenario's), die benadrukt dat elke agent een onafhankelijke toestand en gedrag heeft, en communiceert en plant via asynchrone berichten. Onder deze architectuur kan het on-chain-systeem gelijktijdig worden uitgevoerd door een groot aantal processen die van elkaar zijn losgekoppeld, en heeft het een sterke schaalbaarheid en asynchrone fouttolerantie. Representatieve projecten zijn onder meer AO (Arweave AO), ICP (Internet Computer) en Cartesi, die de evolutie van blockchain van een uitvoeringsengine naar een "on-chain besturingssysteem" aansturen, en een native infrastructuur bieden voor AI-agents, multi-task interacties en complexe logische orkestratie.

  Hoewel het ontwerp van het Actor Model vergelijkbaar is met sharding in termen van oppervlakkige kenmerken (bijv. parallellisme, toestandsisolatie en asynchrone verwerking), vertegenwoordigen de twee in wezen totaal verschillende technische paden en systeemfilosofieën. Het Actor Model legt de nadruk op "multi-process asynchronous computing", waarbij elke agent onafhankelijk draait, de status onafhankelijk handhaaft en op een berichtgestuurde manier communiceert. Sharding, aan de andere kant, is een "horizontale sharding of state and consensus"-mechanisme, dat de hele blockchain verdeelt in meerdere subsystemen (shards) die transacties onafhankelijk van elkaar verwerken. Actor-modellen lijken meer op een "gedistribueerd agentbesturingssysteem" in de Web3-wereld, terwijl sharding een structurele schaaloplossing is voor on-chain transactieverwerkingsmogelijkheden. Beide bereiken parallellisme, maar hebben verschillende startpunten, doelen en uitvoeringsarchitecturen.

  4.1 AO (Arweave), een superparallelle computer bovenop de opslaglaagAO

  is een gedecentraliseerd computerplatform dat draait op de permanente opslaglaag van Arweave, met als kerndoel het bouwen van een on-chain besturingssysteem dat de werking van grootschalige asynchrone agents ondersteunt.

  Functies van de kernarchitectuur:

  • Procesarchitectuur: elke agent wordt een proces genoemd, met een onafhankelijke status, een onafhankelijke planner en uitvoeringslogica;
  • Geen blockchain-structuur: AO is geen keten, maar een gedecentraliseerde opslaglaag + multi-agent message-driven execution engine op basis van Arweave;
  • Asynchroon berichtplanningssysteem: processen communiceren met elkaar via berichten, hanteren een vergrendelingsvrij asynchroon bedieningsmodel en ondersteunen op natuurlijke wijze gelijktijdige uitbreiding.
  • Permanente statusopslag: Alle agentstatussen, berichtrecords en instructies worden permanent vastgelegd op Arweave, wat zorgt voor volledige controleerbaarheid en gedecentraliseerde transparantie.
  • Agent-native: Het is geschikt voor het implementeren van complexe taken met meerdere stappen (zoals AI-agents, DePIN-protocolcontrollers, automatische taakorchestrators, enz.), en kan een "on-chain AI-coprocessor" bouwen.

  AO neemt de ultieme route van "agent native + storage driver + chainless architecture", met de nadruk op flexibiliteit en module-ontkoppeling, en is een "microkernel-framework op de keten gebouwd bovenop de opslaglaag", waarbij de systeemgrens opzettelijk wordt verkleind, met de nadruk op lichtgewicht computing + composable controlestructuur.

  4.2 ICP (Internet Computer), een full-stack Web3-hostingplatformICP

  is een Web3-native full-stack on-chain applicatieplatform gelanceerd door DFINITY, met als doel on-chain rekenkracht uit te breiden naar Web2-achtige ervaringen, en volledige servicehosting, domeinnaambinding en serverloze architectuur te ondersteunen.

  Kernarchitectuurfuncties:

  • Canister-architectuur (containers als agents): Elke canister is een agent die wordt uitgevoerd op een Wasm-VM met onafhankelijke status-, code- en asynchrone planningsmogelijkheden;
  • Subnet Distributed Consensus System (Subnet): Het hele netwerk bestaat uit meerdere subnetten, die elk een set bussen onderhouden en consensus bereiken via het BLS-handtekeningmechanisme.
  • Asynchroon aanroepmodel: Canister communiceert met Canister via asynchrone berichten, ondersteunt niet-blokkerende uitvoering en heeft een natuurlijk parallellisme.
  • On-chain webhosting: Het ondersteunt slimme contracten om front-end pagina's rechtstreeks te hosten, native DNS-mapping, en is het eerste blockchain-platform dat browsers ondersteunt om rechtstreeks toegang te krijgen tot dApps;
  • Het systeem heeft volledige functies: het heeft systeem-API's zoals on-chain hot upgrade, identiteitsverificatie, gedistribueerde willekeur en timer, die geschikt is voor complexe on-chain service-implementatie.

  ICP kiest voor een besturingssysteemparadigma van zwaar platform, geïntegreerde verpakking en sterke platformcontrole, en heeft een "blockchain-besturingssysteem" dat consensus, uitvoering, opslag en toegang integreert, de nadruk legt op volledige servicehostingmogelijkheden en de systeemgrens uitbreidt naar een full-stack Web3-hostingplatform.

  Daarnaast kunnen de parallelle computerprojecten van andere Actor Model-paradigma's worden verwezen naar de volgende tabel:

  

  5. Samenvatting en vooruitzichtOp

  basis van de verschillen tussen de architectuur van virtuele machines en het taalsysteem kunnen parallelle blockchain-computeroplossingen grofweg worden onderverdeeld in twee categorieën: EVM parallelle verbeteringsketen en native parallelle architectuurketen (niet-EVM).

  Op basis van het behoud van de compatibiliteit van het EVM/Solidity-ecosysteem, bereikt de eerste een hogere doorvoer en parallelle verwerkingsmogelijkheden door diepgaande optimalisatie van de uitvoeringslaag, die geschikt is voor scenario's die Ethereum-activa en ontwikkelingstools willen erven en tegelijkertijd prestatiedoorbraken willen bereiken. Representatieve projecten zijn onder meer:

  • Monad: Implementeert een optimistisch parallel uitvoeringsmodel dat compatibel is met EVM door middel van uitgestelde schrijf- en runtimeconflictdetectie, bouwt afhankelijkheidsgrafieken en plant de uitvoering nadat de consensus is voltooid.
  • MegaETH: Abstractie van elk account/contract in een onafhankelijke micro-VM en implementeert sterk ontkoppelde parallelle planning op accountniveau op basis van asynchrone berichten en statusafhankelijke grafieken.
  • Pharos: Bouw een rollup mesh-architectuur om parallelle verwerking op systeemniveau in processen te bereiken via asynchrone pijplijnen en SPN-modules.
  • Reddio: Gebruikt de zkRollup + GPU-architectuur om het off-chain verificatieproces van zkEVM te versnellen door middel van batch SNARK-generatie en de verificatiedoorvoer te verbeteren.

  Dit laatste maakt volledig komaf met de beperkingen van de compatibiliteit van Ethereum en herontwerpt het uitvoeringsparadigma van de virtuele machine, het staatsmodel en het planningsmechanisme om native high-performance gelijktijdigheid te bereiken. Typische subklassen zijn:

  • Solana (SVM): een parallel uitvoeringsmodel op accountniveau op basis van claims voor accounttoegang en statische conflictgrafiekplanning;
  • Sui / Aptos (MoveVM-systeem): Gebaseerd op het resource-objectmodel en -typesysteem, ondersteunt het statische analyse tijdens het compileren en realiseert het parallellisme op objectniveau.
  • Sei V2 (Cosmos SDK-route): introduceert een multi-threaded matching-engine en gelijktijdigheidsoptimalisatie van virtuele machines in de Cosmos-architectuur, die geschikt is voor transactionele hoogfrequente toepassingen.
  • Brandstof (UTXO + Sway-architectuur): Parallellisme op transactieniveau door statische analyse van de UTXO-invoerset, waarbij een modulaire uitvoeringslaag wordt gecombineerd met een aangepaste slimme contracttaal Sway;

  Bovendien bouwt het Actor-model, als een meer algemeen parallel systeem, een on-chain uitvoeringsparadigma van "multi-agent onafhankelijke operatie + berichtgestuurde samenwerking" door middel van een asynchroon procesplanningsmechanisme op basis van Wasm of aangepaste VM's. Representatieve projecten zijn onder meer:

  • AO (Arweave AO): Het bouwen van een on-chain asynchroon microkernelsysteem op basis van de persistente opslaggestuurde agentruntime;
  • ICP (Internet Computer): gebruikt de gecontaineriseerde agent (Canister) als de kleinste eenheid om asynchrone en zeer schaalbare uitvoering te bereiken door middel van subnetcoördinatie.
  • Cartesi: Introduceert het Linux-besturingssysteem als een off-chain computeromgeving om een on-chain verificatiepad te bieden voor betrouwbare computerresultaten, geschikt voor complexe of resource-intensieve toepassingsscenario's.

  Op basis van de bovenstaande logica kunnen we het huidige mainstream parallel computing public chain-schema samenvatten in een classificatiestructuur, zoals weergegeven in de volgende afbeelding:

  

  Vanuit een breder schaalperspectief richten sharding en rollup (L2) zich op horizontale schaling door middel van state sharding of off-chain uitvoering, terwijl parallelle rekenketens (bijv. Monad, Sui, Solana) en actorgeoriënteerde systemen (bijv. AO, ICP) het uitvoeringsmodel direct reconstrueren en native parallellisme bereiken binnen de keten of op de systeemlaag. De eerste verbetert de doorvoer binnen de keten door middel van multi-threaded virtuele machines, objectmodellen, analyse van transactieconflicten, enz.; De laatste neemt het proces/de agent als de basiseenheid en hanteert berichtgestuurde en asynchrone uitvoeringsmodi om gelijktijdige werking met meerdere agenten te bereiken. Daarentegen lijken sharding en rollups meer op "het splitsen van de last over meerdere ketens" of "off-chain uitbesteden", terwijl het parallelle keten- en actormodel "het prestatiepotentieel van de uitvoeringsengine zelf ontketent", wat een grondigere architecturale evolutie weerspiegelt.

  Parallel computing versus sliding-architectuur versus rollup-schaling versus actorgeoriënteerd schaalpad Vergelijking

  

  Opgemerkt moet worden dat de meeste van de native parallelle architectuurketens de lanceringsfase van het mainnet zijn ingegaan, hoewel het algehele ecosysteem van ontwikkelaars nog steeds moeilijk te vergelijken is met het Solidity-systeem van het EVM-systeem, maar de projecten vertegenwoordigd door Solana en Sui, met hun krachtige uitvoeringsarchitectuur en de geleidelijke welvaart van ecologische toepassingen, zijn de belangrijkste openbare ketens geworden waar de markt veel aandacht aan besteedt.

  Daarentegen, hoewel het Ethereum Rollup (L2)-ecosysteem het stadium van "10.000 ketens tegelijk" of zelfs "overcapaciteit" is ingegaan, bevindt de huidige mainstream EVM parallelle verbeteringsketen zich over het algemeen nog steeds in de testnetfase en is deze nog niet geverifieerd door de daadwerkelijke mainnet-omgeving, en het schaalvermogen en de systeemstabiliteit moeten nog verder worden getest. Het valt nog te bezien of deze projecten de EVM-prestaties aanzienlijk kunnen verbeteren en ecologische sprongen kunnen maken zonder compatibiliteit op te offeren, of dat ze de liquiditeit en ontwikkelingsmiddelen van Ethereum verder kunnen differentiëren.