AO koers

$AO is als $ICP zonder VC's met een waarderingsverschil van 39x. We hebben er vorige maand een uitgebreid rapport over geschreven op @dyorcryptoapp.

Auteurs: 0xjacobzhao en ChatGPT 4o De "veiligheid", "decentralisatie" en "schaalbaarheid" van blockchain "Blockchain Trilemma" onthullen de essentiële afweging in het ontwerp van blockchain-systemen, dat wil zeggen dat het moeilijk is 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 volgens paradigma's, waaronder: Scaling met verbeterde uitvoering: verbetert de uitvoeringsmogelijkheden, zoals parallellisme, GPU en multicore, in situ Staat-geïsoleerde schaling: Splitst status/shards, zoals shards, UTXO's en multi-subnetten horizontaal Off-chain outsourcing schaling: Uitvoering off-chain plaatsen, zoals rollups, coprocessors en DA's Structurele uitbreiding van de ontkoppelingscapaciteit: De architectuur is modulair en werkt samen, zoals moduleketens, gedeelde sequencers en rollup meshes Asynchrone gelijktijdige schaling: Actormodel, procesisolatie, berichtgestuurd, zoals agents en multi-threaded asynchrone ketens 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. Accountniveau: Vertegenwoordigt het project Solana Parallellisme op objectniveau: Vertegenwoordigt project Sui Transactieniveau: Vertegenwoordigt het project Monad, Aptos Call-level / MicroVM: Vertegenwoordigt het project MegaETH Instructieniveau: Vertegenwoordigt het project 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 Parallel Enhancement Chain: de prestatiegrens doorbreken op het gebied van compatibiliteit 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. Parallelle computationele mechanisme-analyse van Monad Monad is een krachtige Layer 1-blockchain die opnieuw is ontworpen voor de Ethereum Virtual Machine (EVM), gebaseerd op het parallelle basisconcept van pipelining, met asynchrone uitvoering op de consensuslaag en optimistische parallelle uitvoering op de uitvoeringslaag. 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: een parallel uitvoeringsmechanisme voor meertraps pijpleidingen Pipelining is het basisconcept van parallelle uitvoering van Monad, 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 wordt uitgevoerd op onafhankelijke threads of kernen om gelijktijdige verwerking van cross-block te bereiken en uiteindelijk het effect te bereiken van het verbeteren van de doorvoer en het verminderen van latentie. Deze fasen omvatten: voorstellen, consensus, uitvoering en toezeggen. Asynchrone uitvoering: consensus - voert asynchrone ontkoppeling uit In traditionele ketens zijn transactieconsensus en -uitvoering doorgaans synchrone processen, en dit seriële model beperkt de schaalvergroting van de 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. Kern Ontwerp: Het consensusproces (consensuslaag) is alleen verantwoordelijk voor het ordenen van transacties en voert de contractlogica niet 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 uitvoering Traditioneel Ethereum gebruikt een strikt serieel model voor het uitvoeren 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. Handhavingsmechanisme: Monad voert alle transacties optimistisch parallel uit, in de veronderstelling dat de meeste van hen geen stateful conflicten tussen hen hebben. 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. Parallelle computationele analyse van MegaETH Anders dan de L1-positionering van Monad, is MegaETH 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. Asynchrone uitvoerings- en callback-mechanismen MegaETH is gebouwd op de top van het asynchrone programmeerparadigma, vergelijkbaar met de asynchrone berichtgeving van het Actor Model, dat het probleem van traditionele EVM-seriële aanroepen oplost. 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. De ontwerpconcepten van zowel Monad als MegaETH zijn heel anders dan sharding: sharding verdeelt de blockchain horizontaal in meerdere onafhankelijke subketens (shards), en elke subketen is verantwoordelijk voor een deel van de transacties en staten, het doorbreken van de single-chain-limiet en schaalbaar 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: Asynchrone pipelining gedurende de volledige levenscyclus: Pharos ontkoppelt de verschillende fasen van een transactie (bijv. consensus, uitvoering, opslag) en past asynchrone verwerking toe, zodat elke fase onafhankelijk en parallel kan worden uitgevoerd, waardoor de algehele verwerkingsefficiëntie wordt verbeterd. 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. 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. 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 krachtig platform dat zkRollup combineert met GPU-architectuur voor parallelle uitvoering, en de kern is het herstructureren van het EVM-uitvoeringsproces om native parallellisatie van de uitvoeringslaag te bereiken 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. Op dit moment is de SDK gelanceerd en is er een geïntegreerde uitvoeringsmodule beschikbaar GatlingX noemt zichzelf "GPU-EVM" en stelt een meer radicale architectuur voor die probeert het "seriële uitvoering op instructieniveau"-model van traditionele virtuele EVM-machines te migreren naar GPU-native parallelle runtime-omgevingen. 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: reconstrueer de uitvoeringsontologie van VM's Het EVM-uitvoeringsmodel van Ethereum 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. Native parallelle computerarchitectuurketens zoals Solana (SVM), MoveVM (Sui, Aptos) en Sei v2 die zijn gebouwd op de Cosmos SDK, zijn daarentegen op maat gemaakt voor parallelle uitvoering vanaf de onderste laag en hebben de volgende voordelen: Natuurlijke scheiding van statusmodellen: Solana gebruikt het declaratiemechanisme voor accountvergrendeling, MoveVM introduceert het objecteigendomsmodel en Sei v2 implementeert statische conflictbeoordeling op basis van classificatie van transactietypen en ondersteunt gelijktijdige planning op transactieniveau. 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. Kern mechanica: 1. Expliciete lijsten met accounttoegang: Elke transactie moet de betrokken account aangeven (lezen/schrijven) bij het indienen, zodat het systeem kan bepalen of er een statusconflict is tussen transacties. 2. Conflictdetectie en multi-threaded planning Als er geen overlapping is tussen de rekeningsets waartoe de twee transacties toegang hebben→ kunnen ze parallel worden uitgevoerd; Er is een conflict→ serieel uitgevoerd in afhankelijke volgorde; 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 duidelijk 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 model voor objecteigendom De 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. Het Block-STM-handhavingsmechanisme van Aptos Aptos is een krachtige Layer1-blockchain gebaseerd op de Move-taal en de parallelle uitvoeringscapaciteit is voornamelijk afgeleid van het zelf ontwikkelde Block-STM-framework (Block-level Software Transactional Memory). 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 transacties in een blok in drie fasen: Speculatieve uitvoering: Alle transacties zijn standaard conflictvrij voordat ze worden uitgevoerd, en het systeem plant transacties naar meerdere threads voor gelijktijdige uitvoeringspogingen en registreert de accountstatus (leesset/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, en is een hardware-ingenieursstijl, die de keten als hardware moet uitvoeren (parallelle uitvoering van hardwarekwaliteit); 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 parallelle extensie Sei V2 is een krachtige transactionele openbare keten die is gebouwd op basis van de Cosmos SDK, en het parallellismevermogen wordt voornamelijk weerspiegeld in twee aspecten: de multi-threaded matching-engine (Parallel Matching Engine) en de parallelle uitvoeringsoptimalisatie van de virtuele machinelaag, met als doel on-chain transactiescenario's met hoge frequentie en lage latentie te bedienen, zoals orderboek DEX's, on-chain uitwisselingsinfrastructuur, enz. Kern parallel mechanisme: Parallelle overeenkomst-engine: SEI V2 introduceert een multi-threaded uitvoeringspad in de orderovereenkomstlogica, waarbij het hangende orderboek en de overeenkomstlogica op threadniveau worden gesplitst, zodat de overeenkomende taken tussen meerdere handelsparen parallel kunnen worden verwerkt en single-threaded knelpunten worden voorkomen. 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. 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 Brandstof Fuel is een krachtige uitvoeringslaag die is ontworpen op basis van de modulaire architectuur van Ethereum, en de kernparallelliteit 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. Actor Model: een nieuw paradigma voor gelijktijdige executie van agenten Het Actor Model is een parallel uitvoeringsparadigma op basis van agent of proces, dat verschilt van de traditionele synchrone berekening van de globale toestand op 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 opslaglaag AO is een gedecentraliseerd computerplatform dat draait op de persistente opslaglaag van Arweave, met als kerndoel het bouwen van een on-chain besturingssysteem dat grootschalige asynchrone agentwerking ondersteunt. Kenmerken 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 hosting platform ICP 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. Kenmerken van de kernarchitectuur: Canisterarchitectuur (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 zijn parallelle rekenprojecten voor andere Actor Model-paradigma's te vinden in de volgende tabel: 5. Samenvatting en vooruitzichten Op basis van de verschillen tussen de architectuur van virtuele machines en het taalsysteem kunnen parallelle blockchain-computingoplossingen 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: Implementeer een optimistisch parallel uitvoeringsmodel dat compatibel is met EVM door middel van uitgestelde schrijf- en runtimeconflictdetectie, bouw afhankelijkheidsgrafieken nadat de consensus is voltooid en plan de uitvoering in meerdere threads. 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 onder meer: Solana (SVM): Op basis van claims voor accounttoegang en statische conflictgrafiekplanning vertegenwoordigt het een parallel uitvoeringsmodel op accountniveau. 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): bouwt 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ënteerde schaalpadvergelijking 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.

Geschreven door 0xjacobzhao en ChatGPT 4o De "veiligheid", "decentralisatie" en "schaalbaarheid" van blockchain "Blockchain Trilemma" onthullen de essentiële afweging in het ontwerp van blockchain-systemen, dat wil zeggen dat het moeilijk is 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 volgens paradigma's, waaronder: Scaling met verbeterde uitvoering: verbetert de uitvoeringsmogelijkheden, zoals parallellisme, GPU en multicore, in situ Staat-geïsoleerde schaling: Splitst status/shards, zoals shards, UTXO's en multi-subnetten horizontaal Off-chain outsourcing schaling: Uitvoering off-chain plaatsen, zoals rollups, coprocessors en DA's Structurele uitbreiding van de ontkoppelingscapaciteit: De architectuur is modulair en werkt samen, zoals moduleketens, gedeelde sequencers en rollup meshes Asynchrone gelijktijdige schaling: Actormodel, procesisolatie, berichtgestuurd, zoals agents en multi-threaded asynchrone ketens 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. Accountniveau: Vertegenwoordigt het project Solana Parallellisme op objectniveau: Vertegenwoordigt project Sui Transactieniveau: Vertegenwoordigt het project Monad, Aptos Call-level / MicroVM: Vertegenwoordigt het project MegaETH Instructieniveau: Vertegenwoordigt het project 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 Parallel Enhancement Chain: de prestatiegrens doorbreken op het gebied van compatibiliteit 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. Parallelle computationele mechanisme-analyse van Monad Monad is een krachtige Layer 1-blockchain die opnieuw is ontworpen voor de Ethereum Virtual Machine (EVM), gebaseerd op het parallelle basisconcept van pipelining, met asynchrone uitvoering op de consensuslaag en optimistische parallelle uitvoering op de uitvoeringslaag. 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: een parallel uitvoeringsmechanisme voor meertraps pijpleidingen Pipelining is het basisconcept van parallelle uitvoering van Monad, 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 wordt uitgevoerd op onafhankelijke threads of kernen om gelijktijdige verwerking van cross-block te bereiken en uiteindelijk het effect te bereiken van het verbeteren van de doorvoer en het verminderen van latentie. Deze fasen omvatten: voorstellen, consensus, uitvoering en toezeggen. Asynchrone uitvoering: consensus - voert asynchrone ontkoppeling uit In traditionele ketens zijn transactieconsensus en -uitvoering doorgaans synchrone processen, en dit seriële model beperkt de schaalvergroting van de 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. Kern Ontwerp: Het consensusproces (consensuslaag) is alleen verantwoordelijk voor het ordenen van transacties en voert de contractlogica niet 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 uitvoering Traditioneel Ethereum gebruikt een strikt serieel model voor het uitvoeren 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. Handhavingsmechanisme: Monad voert alle transacties optimistisch parallel uit, in de veronderstelling dat de meeste van hen geen stateful conflicten tussen hen hebben. 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. Parallelle computationele analyse van MegaETH Anders dan de L1-positionering van Monad, is MegaETH 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. Asynchrone uitvoerings- en callback-mechanismen MegaETH is gebouwd op de top van het asynchrone programmeerparadigma, vergelijkbaar met de asynchrone berichtgeving van het Actor Model, dat het probleem van traditionele EVM-seriële aanroepen oplost. 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. De ontwerpconcepten van zowel Monad als MegaETH zijn heel anders dan sharding: sharding verdeelt de blockchain horizontaal in meerdere onafhankelijke subketens (shards), en elke subketen is verantwoordelijk voor een deel van de transacties en staten, het doorbreken van de single-chain-limiet en schaalbaar 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: Asynchrone pipelining gedurende de volledige levenscyclus: Pharos ontkoppelt de verschillende fasen van een transactie (bijv. consensus, uitvoering, opslag) en past asynchrone verwerking toe, zodat elke fase onafhankelijk en parallel kan worden uitgevoerd, waardoor de algehele verwerkingsefficiëntie wordt verbeterd. 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. 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. 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 krachtig platform dat zkRollup combineert met GPU-architectuur voor parallelle uitvoering, en de kern is het herstructureren van het EVM-uitvoeringsproces om native parallellisatie van de uitvoeringslaag te bereiken 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. Op dit moment is de SDK gelanceerd en is er een geïntegreerde uitvoeringsmodule beschikbaar GatlingX noemt zichzelf "GPU-EVM" en stelt een meer radicale architectuur voor die probeert het "seriële uitvoering op instructieniveau"-model van traditionele virtuele EVM-machines te migreren naar GPU-native parallelle runtime-omgevingen. 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: reconstrueer de uitvoeringsontologie van VM's Het EVM-uitvoeringsmodel van Ethereum 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. Native parallelle computerarchitectuurketens zoals Solana (SVM), MoveVM (Sui, Aptos) en Sei v2 die zijn gebouwd op de Cosmos SDK, zijn daarentegen op maat gemaakt voor parallelle uitvoering vanaf de onderste laag en hebben de volgende voordelen: Natuurlijke scheiding van statusmodellen: Solana gebruikt het declaratiemechanisme voor accountvergrendeling, MoveVM introduceert het objecteigendomsmodel en Sei v2 implementeert statische conflictbeoordeling op basis van classificatie van transactietypen en ondersteunt gelijktijdige planning op transactieniveau. 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. Kern mechanica: 1. Expliciete lijsten met accounttoegang: Elke transactie moet de betrokken account aangeven (lezen/schrijven) bij het indienen, zodat het systeem kan bepalen of er een statusconflict is tussen transacties. 2. Conflictdetectie en multi-threaded planning Als er geen overlapping is tussen de rekeningsets waartoe de twee transacties toegang hebben→ kunnen ze parallel worden uitgevoerd; Er is een conflict→ serieel uitgevoerd in afhankelijke volgorde; 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 duidelijk 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 model voor objecteigendom De 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. Het Block-STM-handhavingsmechanisme van Aptos Aptos is een krachtige Layer1-blockchain gebaseerd op de Move-taal en de parallelle uitvoeringscapaciteit is voornamelijk afgeleid van het zelf ontwikkelde Block-STM-framework (Block-level Software Transactional Memory). 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 transacties in een blok in drie fasen: Speculatieve uitvoering: Alle transacties zijn standaard conflictvrij voordat ze worden uitgevoerd, en het systeem plant transacties naar meerdere threads voor gelijktijdige uitvoeringspogingen en registreert de accountstatus (leesset/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, en is een hardware-ingenieursstijl, die de keten als hardware moet uitvoeren (parallelle uitvoering van hardwarekwaliteit); 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 parallelle extensie Sei V2 is een krachtige transactionele openbare keten die is gebouwd op basis van de Cosmos SDK, en het parallellismevermogen wordt voornamelijk weerspiegeld in twee aspecten: de multi-threaded matching-engine (Parallel Matching Engine) en de parallelle uitvoeringsoptimalisatie van de virtuele machinelaag, met als doel on-chain transactiescenario's met hoge frequentie en lage latentie te bedienen, zoals orderboek DEX's, on-chain uitwisselingsinfrastructuur, enz. Kern parallel mechanisme: Parallelle overeenkomst-engine: SEI V2 introduceert een multi-threaded uitvoeringspad in de orderovereenkomstlogica, waarbij het hangende orderboek en de overeenkomstlogica op threadniveau worden gesplitst, zodat de overeenkomende taken tussen meerdere handelsparen parallel kunnen worden verwerkt en single-threaded knelpunten worden voorkomen. 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. 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 Brandstof Fuel is een krachtige uitvoeringslaag die is ontworpen op basis van de modulaire architectuur van Ethereum, en de kernparallelliteit 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. Actor Model: een nieuw paradigma voor gelijktijdige executie van agenten Het Actor Model is een parallel uitvoeringsparadigma op basis van agent of proces, dat verschilt van de traditionele synchrone berekening van de globale toestand op 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 opslaglaag AO is een gedecentraliseerd computerplatform dat draait op de persistente opslaglaag van Arweave, met als kerndoel het bouwen van een on-chain besturingssysteem dat grootschalige asynchrone agentwerking ondersteunt. Kenmerken 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 hosting platform ICP 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. Kenmerken van de kernarchitectuur: Canisterarchitectuur (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 zijn parallelle rekenprojecten voor andere Actor Model-paradigma's te vinden in de volgende tabel: 5. Samenvatting en vooruitzichten Op basis van de verschillen tussen de architectuur van virtuele machines en het taalsysteem kunnen parallelle blockchain-computingoplossingen 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: Implementeer een optimistisch parallel uitvoeringsmodel dat compatibel is met EVM door middel van uitgestelde schrijf- en runtimeconflictdetectie, bouw afhankelijkheidsgrafieken nadat de consensus is voltooid en plan de uitvoering in meerdere threads. 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 onder meer: Solana (SVM): Op basis van claims voor accounttoegang en statische conflictgrafiekplanning vertegenwoordigt het een parallel uitvoeringsmodel op accountniveau. 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): bouwt 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ënteerde schaalpadvergelijking 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.

Ik vind het geweldig om de Permabites community meetups te zien groeien!

The Daily Degen - vrijdag 18 april 2025 Trends, Pegs, TGE's, Tech, Macro, Video's, + Nieuwe Projecten! Shout-out naar genoemde projecten en tickers: $DOLO, $ATOM, $sUSD, $BTC, $OL, $WZRD, $AERGO, $T, $EVER, $AO, @GammaSwapLabs, @TradeNeutral, @Lighter_xyz, @jigsawdefi, @PeerlessAI, @VertigoDex, @clickerxyz, @getoro_xyz En shout-out naar gigabrain-accounts die worden genoemd met >10k volgers (zorg ervoor dat je ze volgt!): @leviathan_news, @robbiepetersen_, @0xlykt, @AresLabs_xyz, @CryptoISFreedom En alsjeblieft RT / etc om te ondersteunen! Link in volgende tweet 👇