Web3 Parallel Computing Track Panorama: Den beste løsningen for naturlig skalering?

Forfatter: 0xjacobzhao og ChatGPT 4o"

Blockchain Trilemma" av "sikkerhet", "desentralisering" og "skalerbarhet" av blokkjeden avslører den essensielle avveiningen i utformingen av blokkjedesystemer, det vil si at det er vanskelig for blokkjedeprosjekter å oppnå "ekstrem sikkerhet, alle kan delta og høyhastighetsbehandling" samtidig. Som svar på det evige temaet "skalerbarhet", er de vanlige blokkjedeskaleringsløsningene i markedet delt inn i henhold til paradigmer, inkludert:

• Utførelsesforbedret skalering: Forbedrer utførelsesmulighetene in situ, for eksempel parallellitet, GPU og multi-core
• tilstandsisolert skalering: Horisontalt delt tilstand/shard, for eksempel shards, UTXO og multi-subnett
• Off-chain outsourcet skalering: Sette utførelse utenfor kjeden, for eksempel rollups, Koprosessor- og
• DA-strukturfrakoblingsskalering: Modulær arkitektur og samarbeidsoperasjon, for eksempel modulkjede, delt sekvenser, Rollup Mesh
• Asynkron samtidig skalering: Aktørmodell, prosessisolering, meldingsdrevet, for eksempel agent, flertrådet asynkron kjede

  Blockchain-skaleringsløsningen inkluderer: parallell databehandling på kjeden, rollup, sharding, DA-modul, modulær struktur, aktørsystem, zk-beviskomprimering, tilstandsløs arkitektur, etc., som dekker flere nivåer av utførelse, tilstand, data og struktur, og er et komplett skaleringssystem for "flerlags samarbeid og modulkombinasjon". Denne artikkelen fokuserer på skaleringsmetoder som integrerer parallell databehandling.

  Intra-kjedeparallellitet, som fokuserer på parallell utførelse av intra-blokktransaksjoner/instruksjoner. I henhold til den parallelle mekanismen kan skaleringsmetodene deles inn i fem kategorier, som hver representerer en annen ytelsesforfølgelse, utviklingsmodell og arkitekturfilosofi, og den parallelle granulariteten blir finere og finere, parallellitetsintensiteten blir høyere og høyere, planleggingskompleksiteten blir høyere og høyere, og programmeringskompleksiteten og implementeringsvanskeligheten blir også høyere og høyere.

  • Kontonivå: Representerer prosjektet
  • Objektnivå: Representerer prosjektet Sui
  • Transaksjonsnivå: Representerer prosjektet Monad, Aptos
  • Call-level / MicroVM : MegaETH på instruksjonsnivå
  :
  • GatlingX

  Den asynkrone samtidighetsmodellen utenfor kjeden, representert ved Actor / Actor Model, tilhører et annet parallelt databehandlingsparadigme, som et krysskjede/asynkront meldingssystem (ikke-blokksynkroniseringsmodell), hver agent kjører uavhengig som en "agentprosess", asynkrone meldinger i parallell modus, hendelsesdrevet, ingen synkron planlegging, representative prosjekter som AO, ICP, Cartesi, etc.

  Det velkjente opprullings- eller fragmentskaleringsskjemaet tilhører samtidighetsmekanismen på systemnivå, ikke parallell databehandling i kjeden. De oppnår skalering ved å "kjøre flere kjeder/utførelsesdomener parallelt", i stedet for å øke parallelliteten innenfor en enkelt blokk/virtuell maskin. Denne typen skaleringsløsning er ikke fokuset i denne artikkelen, men vi vil fortsatt bruke den til å sammenligne likhetene og forskjellene i arkitektoniske konsepter.

  2. EVM Parallel Enhancement Chain: Bryte ytelsesgrensen i kompatibilitet

  Siden utviklingen av Ethereums serielle prosesseringsarkitektur har den gjennomgått flere runder med skaleringsforsøk som sharding, rollup og modulær arkitektur, men gjennomstrømningsflaskehalsen til utførelseslaget er fortsatt ikke fundamentalt brutt. Men samtidig er EVM og Solidity fortsatt de smarte kontraktsplattformene med mest utviklerbase og økologisk potensial. Derfor er EVM-parallellforbedringskjeden i ferd med å bli en viktig retning for en ny runde med skalering og evolusjon som en nøkkelvei som tar hensyn til økologisk kompatibilitet og forbedring av utførelsesytelsen. Monad og MegaETH er de mest representative prosjektene i denne retningen, med utgangspunkt i henholdsvis utsatt utførelse og tilstandsdekomponering, for å bygge en EVM-parallell prosesseringsarkitektur for scenarier med høy samtidighet og høy gjennomstrømning.

  Monads parallelle databehandlingsanalyseMonad

  er en høyytelses Layer1-blokkjede redesignet for Ethereum Virtual Machine (EVM), basert på det grunnleggende parallelle konseptet pipelining, med asynkron utførelse på konsensuslaget og optimistisk samtidighet på utførelseslaget Parallell utførelse) 。 I tillegg, ved konsensus- og lagringslagene, har Monad introdusert henholdsvis den høyytelses BFT-protokollen (MonadBFT) og et dedikert databasesystem (MonadDB) for å oppnå ende-til-ende-optimalisering.

  Pipelining: Flertrinns pipeline parallell utførelsesmekanisme

  Pipelining er det grunnleggende konseptet for Monad parallell utførelse, og kjerneideen er å dele utførelsesprosessen til blokkjeden i flere uavhengige stadier, og behandle disse trinnene parallelt for å danne en tredimensjonal pipeline-arkitektur, hvert trinn kjører på uavhengige tråder eller kjerner for å oppnå samtidig behandling på tvers av blokker. Resultatet er økt gjennomstrømning og redusert ventetid. Disse stadiene inkluderer: Forslag, konsensus, utførelse og forpliktelse.

  Asynkron utførelse: Konsensus – Utførelsen er asynkront frakobletPå

  tradisjonelle kjeder er transaksjonskonsensus og utførelse ofte synkrone prosesser, og denne serielle modellen begrenser ytelsesskalering sterkt. Monad implementerer konsensuslag asynkront, utførelseslag asynkront og lagring asynkront gjennom "asynkron utførelse". Reduser blokkeringstid og bekreftelsesforsinkelse betydelig, noe som gjør systemet mer fleksibelt, prosessering mer segmentert og ressursutnyttelse.

  Kjernedesign:

  • Konsensusprosessen (konsensuslaget) er kun ansvarlig for å sortere transaksjoner og utfører ikke kontraktslogikk.
  • Utførelsesprosessen (utførelseslaget) utløses asynkront etter at konsensus er fullført.
  • Etter at konsensus er fullført, vil den gå inn i konsensusprosessen for neste blokk umiddelbart, uten å vente på at utførelsen skal fullføres.

  Optimistisk parallell utførelse: Optimistisk parallell utførelseTradisjonell

  Ethereum tar i bruk en strengt seriell modell for transaksjonsutførelse for å unngå tilstandskonflikter. Monad, på den annen side, vedtar en "optimistisk parallell utførelse"-strategi for å øke transaksjonsbehandlingshastigheten betydelig.

  Utførelsesmekanisme:

  • Monad utfører optimistisk alle transaksjoner parallelt, forutsatt at de fleste transaksjonene er statsløse og konfliktfrie.
  • Kjør også en "konfliktdetektor" for å overvåke om den samme tilstanden (f.eks. lese-/skrivekonflikter) er tilgjengelig mellom transaksjoner.
  • Hvis det oppdages en konflikt, serialiseres den motstridende transaksjonen og kjøres på nytt for å sikre at tilstanden er riktig.

  Monad har valgt en kompatibel vei: å flytte så få EVM-regler som mulig, å oppnå parallellitet ved å utsette skrivetilstand og dynamisk oppdage konflikter under utførelse, som er mer som en ytelsesversjon av Ethereum, med et modenhetsnivå som gjør det enkelt å migrere til EVM-økosystemet, og er en parallell akselerator i EVM-verdenen.

  MegaETHs parallelle databehandlingsmekanismeoppløsning

  er forskjellig fra Monads L1-posisjonering, og MegaETH er posisjonert som et EVM-kompatibelt modulært høyytelses parallelt utførelseslag, som kan brukes som en uavhengig L1 offentlig kjede, som et utførelsesforbedringslag eller modulær komponent på Ethereum. Kjernedesignmålet er å dekonstruere kontologikken, utførelsesmiljøet og tilstandsisolasjonen til den minste enheten som kan planlegges uavhengig for å oppnå høy samtidighet og responsevne med lav latens i kjeden. Den viktigste innovasjonen foreslått av MegaETH er at Micro-VM-arkitekturen + State Dependency DAG (rettet og asyklisk tilstandsavhengighetsgraf) og modulær synkroniseringsmekanisme i fellesskap bygger et parallelt utførelsessystem for "intra-chain threading".

  Micro-VM-arkitektur: Kontoer er tråder

  MegaETH introduserer utførelsesmodellen "en mikro-VM per konto", som "tråder" utførelsesmiljøet og gir en minimum isolasjonsenhet for parallell planlegging. Disse virtuelle maskinene kommuniserer med hverandre gjennom asynkrone meldinger i stedet for synkrone kall, og et stort antall virtuelle maskiner kan kjøres uavhengig, lagres uavhengig og naturlig parallelt.

  State Dependency DAG: en grafdrevet planleggingsmekanisme

  MegaETH har bygget et DAG-planleggingssystem basert på tilgangsforholdet for kontotilstanden, og systemet opprettholder en global avhengighetsgraf i sanntid, og hvilke kontoer som endres og hvilke kontoer som leses for hver transaksjon er alle modellert til avhengigheter. Konfliktfrie transaksjoner kan utføres direkte parallelt, og avhengige transaksjoner vil bli planlagt og sortert serielt eller utsatt i topologisk rekkefølge. Avhengighetsgrafer sikrer tilstandskonsistens og ikke-dupliserte skrivinger under parallell kjøring. Den

  asynkrone utførelses- og tilbakekallingsmekanismen

  MegaETH er bygget på toppen av det asynkrone programmeringsparadigmet, i likhet med den asynkrone meldingssendingen til Actor Model, for å løse problemet med tradisjonelle EVM-seriekall. Kontraktkall er asynkrone (ikke-rekursiv utførelse), og når kontrakt A -> B -> C kalles, er hvert kall asynkront uten å blokkere venting; Anropsstakken utvides til en asynkron anropsgraf; Transaksjonsbehandling = traversering av asynkron graf + avhengighetsoppløsning + parallell planlegging.

  Alt i alt bryter MegaETH den tradisjonelle EVM-enkelttrådede tilstandsmaskinmodellen, implementerer mikro-virtuell maskininnkapsling på konto-for-konto-basis, utfører transaksjonsplanlegging gjennom tilstandsavhengige grafer og erstatter den synkrone anropsstabelen med en asynkron meldingsmekanisme. Det er en parallell databehandlingsplattform som er redesignet fra de fulle dimensjonene av "kontostruktur→ planleggingsarkitektur → utførelsesprosess", og gir en ny idé på paradigmenivå for å bygge et neste generasjons høyytelsessystem på kjeden.

  MegaETH har valgt refaktoreringsbanen: den abstraherer kontoer og kontrakter fullstendig til uavhengige VM-er, og frigjør det ultimate parallellitetspotensialet gjennom asynkron utførelsesplanlegging. Teoretisk sett har MegaETH et høyere parallellt tak, men det er også vanskeligere å kontrollere kompleksiteten, og det er mer som et superdistribuert operativsystem under Ethereum-konseptet.

  

  Monad og MegaETH Begge har forskjellige designkonsepter fra sharding: sharding deler blokkjeden horisontalt inn i flere uavhengige underkjeder (shards), som hver er ansvarlig for en del av transaksjonene og tilstanden, bryter enkeltkjedebegrensningen og skaleringen på nettverkslaget; På den annen side opprettholder både Monad og MegaETH integriteten til enkeltkjeden, skalerer horisontalt bare på utførelseslaget, og utfører optimaliseringsgjennombrudd parallelt på grensen av enkeltkjeden. De to representerer to retninger: vertikal forsterkning og horisontal ekspansjon i blokkjedens ekspansjonsbane.

  Parallelle databehandlingsprosjekter som Monad og MegaETH fokuserer hovedsakelig på gjennomstrømningsoptimaliseringsbanen, med kjernemålet å forbedre TPS på kjeden, og oppnå parallell behandling på transaksjonsnivå eller kontonivå gjennom utsatt utførelse og mikro-VM-arkitekturer. Pharos Network er et modulært, full-stack parallelt L1 blokkjedenettverk, og dets kjerneparallelle databehandlingssystem kalles "Rollup Mesh". Denne arkitekturen støtter multi-virtuelle maskinmiljøer (EVM og Wasm) gjennom synergien mellom hovednett og spesielle prosesseringsnettverk (SPN-er), og integrerer avanserte teknologier som nullkunnskapsbevis (ZK) og klarerte utførelsesmiljøer (TEE-er).

  Rollup Mesh Parallel Computing Analysis:

  1. Full livssyklus asynkron pipelining: Pharos kobler fra de ulike stadiene i en transaksjon (som konsensus, utførelse og lagring) og tar i bruk asynkron prosessering slik at hvert trinn kan utføres uavhengig og parallelt, og dermed forbedre den generelle prosesseringseffektiviteten.
  2. Dobbel VM parallell kjøring: Pharos støtter både EVM- og WASM-virtuelle maskinmiljøer, slik at utviklere kan velge riktig utførelsesmiljø for deres behov. Denne dual-VM-arkitekturen øker ikke bare fleksibiliteten til systemet, men øker også transaksjonsbehandlingen gjennom parallell kjøring.
  3. Special Processing Networks (SPN-er): SPN-er er nøkkelkomponenter i Pharos-arkitekturen, i likhet med modulære undernettverk designet for å håndtere spesifikke typer oppgaver eller applikasjoner. Med SPN-er muliggjør Pharos dynamisk allokering av ressurser og parallell behandling av oppgaver, noe som forbedrer skalerbarheten og ytelsen til systemet ytterligere.
  4. Modulær konsensus og gjenopptakelse: Pharos introduserer en fleksibel konsensusmekanisme som støtter flere konsensusmodeller (som PBFT, PoS, PoA), og muliggjør sikker deling og ressursintegrasjon mellom hovednettet og SPN-er gjennom gjentakingsprotokollen.

  I tillegg rekonstruerer Pharos utførelsesmodellen fra det nederste laget av lagringsmotoren gjennom flerversjons Merkle-tre, Delta-koding, versjonsadressering og ADS Pushdown-teknologi, og lanserer Pharos Store, en høyytelses lagringsmotor for den opprinnelige blokkjeden, for å oppnå høy gjennomstrømning, lav ventetid og sterke verifiserbare prosesseringsevner på kjeden.

  Generelt oppnår Pharos' Rollup Mesh-arkitektur høyytelses parallelle databehandlingsmuligheter gjennom modulær design og asynkron prosesseringsmekanisme.

  I tillegg til de parallelle utførelsesarkitekturene til Monad, MegaETH og Pharos, observerer vi også at det er noen prosjekter i markedet som utforsker applikasjonsbanen til GPU-akselerasjon i EVM parallell databehandling, som et viktig supplement og banebrytende eksperiment til EVM parallelle økosystem. Blant dem er Reddio og GatlingX to representative retninger:

  • Reddio er en høyytelsesplattform som kombinerer zkRollup og GPU parallell utførelsesarkitektur, og kjernen ligger i å rekonstruere EVM-utførelsesprosessen, og realisere den opprinnelige parallelliseringen av utførelseslaget gjennom flertrådsplanlegging, asynkron tilstandslagring og GPU-akselerert utførelse av transaksjonsbatcher. Parallell granularitet på transaksjonsnivå + operasjonsnivå (flertrådet utførelseskode). Den er designet for å introdusere flertrådet batchkjøring, asynkron tilstandslasting og GPU-parallell prosesseringstransaksjonslogikk (CUDA-kompatibel parallell EVM). I likhet med Monad/MegaETH fokuserer Reddio også på parallell prosessering på utførelseslaget, med forskjellen at utførelsesmotoren rekonstrueres gjennom en GPU-parallell arkitektur, designet for høy gjennomstrømning og beregningsintensive scenarier som AI-inferens. GatlingX,
  • som kaller seg "GPU-EVM", foreslår en mer radikal arkitektur som forsøker å migrere "instruksjonsnivå seriell utførelse"-modellen til tradisjonelle virtuelle EVM-maskiner til et GPU-basert parallelt kjøretidsmiljø. Kjernemekanismen er å dynamisk kompilere EVM-bytekoden til CUDA-parallelle oppgaver, og utføre instruksjonsstrømmen gjennom GPU-flerkjernen, for å bryte den sekvensielle flaskehalsen til EVM på det laveste nivået. Parallell granularitet som tilhører Instruction-Level Parallelism (ILP). Sammenlignet med den parallelle granulariteten på "transaksjonsnivå/kontonivå" til Monad / MegaETH, tilhører GatlingXs parallellitetsmekanisme optimaliseringsbanen på instruksjonsnivå, som er nærmere den underliggende refaktoreringen av den virtuelle maskinmotoren. Den er for tiden i konseptfasen, med en whitepaper og arkitektonisk skisse publisert, og ingen SDK eller mainnet ennå.

  Artela foreslår et differensiert, parallelt designkonsept. Med introduksjonen av den virtuelle maskinen EVM++-arkitekturen WebAssembly (WASM), har utviklere lov til dynamisk å legge til og utføre utvidelser på kjeden ved hjelp av Aspect programmeringsmodell samtidig som de opprettholder EVM-kompatibilitet. Den bruker kontraktspåkallingsgranulariteten (funksjon / utvidelse) som minimum parallell enhet, og støtter injeksjon av utvidelsesmoduler (ligner på "pluggbar mellomvare") når EVM-kontrakten kjører, for å oppnå logisk frakobling, asynkron aktivering og parallell utførelse på modulnivå. Mer oppmerksomhet rettes mot komponerbarheten og den modulære arkitekturen til utførelseslaget. Konseptet gir nye ideer for komplekse multimodulapplikasjoner i fremtiden.

  3. Native parallell arkitekturkjede: EVM-utførelsesmodellen til Ethereum, utførelsesontologien til den rekonstruerte VMen

  ,

  har tatt i bruk en entrådet arkitektur med "full transaksjonsordre + seriell utførelse" siden begynnelsen av designet, med sikte på å sikre sikkerheten og konsistensen av tilstandsendringer for alle noder i nettverket. Denne arkitekturen har imidlertid en naturlig flaskehals i ytelse, noe som begrenser systemgjennomstrømning og skalerbarhet. I motsetning til dette er native parallelle databehandlingsarkitekturkjeder som Solana (SVM), MoveVM (Sui, Aptos) og Sei v2 bygget på Cosmos SDK skreddersydd for parallell kjøring fra den underliggende designen og har følgende fordeler:

  Naturlig
  • separasjon av tilstandsmodeller: Solana bruker en deklarasjonsmekanisme for kontolås, MoveVM introduserer en objekteierskapsmodell, og Sei v2 er basert på transaksjonstypeklassifisering. Statisk konfliktvurdering realiseres, og samtidig planlegging på transaksjonsnivå støttes.
  • Virtuelle maskiner er optimalisert for samtidighet: Solanas Sealevel-motor støtter utførelse med flere tråder; MoveVM kan utføre statisk samtidighetsgrafanalyse; Sei v2 integrerer en flertrådet matchende motor med en parallell VM-modul.

  Selvfølgelig står denne typen innfødte parallellkjeder også overfor utfordringen med økologisk kompatibilitet. Ikke-EVM-arkitekturer krever vanligvis nye utviklingsspråk (som Move og Rust) og verktøykjeder, som har visse migreringskostnader for utviklere. I tillegg må utviklere mestre en rekke nye konsepter som tilstandsfulle tilgangsmodeller, samtidighetsgrenser, objektlivssykluser, etc., som stiller høyere krav til å forstå terskler og utviklingsparadigmer.

  3.1 Parallellmotorprinsippet ved havnivå til Solana og SVM

  Solanas Sealevel-utførelsesmodell er en parallell planleggingsmekanisme for kontoer, som er kjernemotoren som brukes av Solana for å realisere utførelsen av parallelle transaksjoner i kjeden, og oppnår høyytelses samtidighet på smartkontraktsnivå gjennom mekanismen "kontodeklarasjon + statisk planlegging + flertrådet utførelse". Sealevel er den første utførelsesmodellen i blokkjedefeltet som vellykket implementerer parallell planlegging innen kjeden i et produksjonsmiljø, og dens arkitektoniske ideer har påvirket mange påfølgende parallelle databehandlingsprosjekter, og er et referanseparadigme for høyytelses Layer 1 parallell design.

  Kjernemekanisme:

  1. Eksplisitte kontotilgangslister: Hver transaksjon må deklarere kontoen som er involvert (lese/skrive) ved innsending, og systemet vil avgjøre om det er en tilstandskonflikt mellom transaksjoner.

  2. Konfliktdeteksjon og flertrådet planlegging

  • Hvis det ikke er noe skjæringspunkt mellom kontosettene som de to transaksjonene har tilgang til→ kan de utføres parallelt;
  • Det er en konflikt→ å utføre serielt i avhengig rekkefølge;
  • Planleggeren tildeler transaksjoner til forskjellige tråder basert på avhengighetsgrafen.

  3. Programaktiveringskontekst: Hvert kontraktkall kjører i en isolert kontekst uten en delt stabel for å unngå forstyrrelser på tvers av samtaler.

  Sealevel er Solanas parallelle utførelsesplanleggingsmotor, mens SVM er et smart kontraktsutførelsesmiljø bygget på toppen av Sealevel (ved hjelp av den virtuelle BPF-maskinen). Sammen danner de det tekniske grunnlaget for Solanas høyytelses parallelle utførelsessystem.

  Eclipse er et prosjekt som distribuerer Solana VM-er på modulære kjeder som Ethereum L2 eller Celestia, og utnytter Solanas parallelle utførelsesmotor som utførelseslag for rollup. Eclipse er et av de første prosjektene som foreslår å koble Solana-utførelseslaget (Sealevel + SVM) fra Solana-hovednettet og migrere det til en modulær arkitektur, og den modulære utgangen av Solanas "super concurrent execution model" er Execution Layer-as-a-Service, så Eclipse tilhører også kategorien parallell databehandling.

  Neons rute er annerledes, den introduserer EVM for å operere i et SVM/Sealevel-miljø. Bygg et EVM-kompatibelt kjøretidslag, utviklere kan bruke Solidity til å utvikle kontrakter og kjøre i SVM-miljøet, men planleggingsutførelsen bruker SVM + Sealeve. Neon lener seg mer mot kategorien modulær blokkjede enn innovasjon innen parallell databehandling.

  Alt i alt er Solana og SVM-er avhengige av Sealevel-utførelsesmotoren, og Solanas OS-baserte planleggingsfilosofi ligner på kjerneplanleggeren, som er rask, men relativt lite fleksibel. Det er en innebygd offentlig kjede med høy ytelse og parallell databehandling.

  3.2 MoveVM-arkitektur: Ressurs- og objektdrevet

  MoveVM er en virtuell maskin for smarte kontrakter designet for ressurssikkerhet på kjeden og parallell utførelse, og kjernespråket, Move, ble opprinnelig utviklet av Meta (tidligere Facebook) for Libra-prosjektet, med vekt på konseptet "ressurser er objekter", og alle tilstander på kjeden eksisterer som objekter, med klart eierskap og livssykluser. Dette gjør det mulig for MoveVM å analysere om det er tilstandskonflikter mellom transaksjoner i kompileringstiden, og implementere statisk parallell planlegging på objektnivå, som er mye brukt i native parallelle offentlige kjeder som Sui og Aptos.

  Suis objekteierskapsmodellSuis

  parallelle databehandlingsevner stammer fra dens unike tilnærming til tilstandsmodellering og statisk analyse på språknivå. I motsetning til tradisjonelle blokkjeder, som bruker globale statstrær, har Sui bygget en objektsentrisk modell basert på "objektet", som fungerer med MoveVMs lineære typesystem for å gjøre parallell planlegging til en deterministisk prosess som kan fullføres på kompileringstidspunktet.

  • Objektmodellen er grunnlaget for Suis parallelle arkitektur. Sui abstraherer hele tilstanden i kjeden i separate objekter, hver med en unik ID, en tydelig eier (konto eller kontrakt) og en typedefinisjon. Disse objektene deler ikke tilstand med hverandre og er iboende isolert. Kontrakten må eksplisitt erklære samlingen av objekter som er involvert når den kalles, og unngå tilstandskoblingsproblemet til det tradisjonelle "globale statstreet" på kjeden. Denne designen deler tilstanden på kjeden i flere uavhengige enheter, noe som gjør samtidig kjøring til et strukturelt gjennomførbart planleggingspremiss.
  • Statisk eierskapsanalyse er en kompileringstidsanalysemekanisme implementert med støtte fra Move-språkets lineære typesystem. Det gjør det mulig for systemet å planlegge transaksjoner som skal utføres parallelt ved å utlede hvilke transaksjoner som ikke har tilstandskonflikter gjennom objekteierskap før de utføres. Sammenlignet med konfliktdeteksjon og tilbakerulling av tradisjonelle kjøretider, reduserer Suis statiske analysemekanisme planleggingskompleksiteten betraktelig samtidig som den forbedrer utførelseseffektiviteten, noe som er nøkkelen til å oppnå høy gjennomstrømning og deterministiske parallelle prosesseringsevner.

  Sui deler tilstandsrommet på objekt-for-objekt-basis, kombinert med kompileringstidseierskapsanalyse, for å oppnå rimelig, tilbakerullingsfri parallell utførelse på objektnivå. Sammenlignet med seriell utførelse eller kjøretidsdeteksjon av tradisjonelle kjeder, har Sui oppnådd betydelige forbedringer i utførelseseffektivitet, systemdeterminisme og ressursutnyttelse.

  Aptos' Block-STM-utførelsesmekanismeAptos

  er en høyytelses Layer1-blokkjede basert på Move-språket, og dens parallelle utførelsesevne er hovedsakelig avledet fra det egenutviklede Block-STM-rammeverket (Block-level Software Transactional Memory). I motsetning til Suis strategi med «statisk parallellitet ved kompileringstid», tilhører Block-STM den dynamiske planleggingsmekanismen «optimistisk samtidighet ved kjøretid + tilbakerulling av konflikt», som er egnet for å håndtere transaksjonssett med komplekse avhengigheter.

  Block-STM deler transaksjonsutførelsen av en blokk inn i tre stadier:

  • Spekulativ utførelse: Alle transaksjoner er konfliktfrie som standard før utførelse, og systemet planlegger transaksjoner parallelt med flere tråder for å prøve å utføre samtidig, og registrerer kontostatusen (lese-/skrivesett) som de har tilgang til.
  • Valideringsfase: Systemet verifiserer utførelsesresultatet: hvis det er en lese-skrive-konflikt mellom to transaksjoner (for eksempel leser Tx1 tilstanden til å bli skrevet av Tx2), rulles en av dem tilbake.
  • Prøv på nytt: Motstridende transaksjoner vil bli planlagt på nytt til avhengighetene deres er løst, og til slutt danner alle transaksjoner en gyldig, deterministisk sekvens av tilstandsinnsendinger.

  Block-STM er en dynamisk utførelsesmodell for "optimistisk parallellitet + tilbakerulling og gjenforsøk", som er egnet for tilstandsintensive og logisk komplekse transaksjonsbatchbehandlingsscenarier på kjeden, og er den parallelle datakjernen for Aptos for å bygge en offentlig kjede med høy allsidighet og høy gjennomstrømning.

  

  Solana er en ingeniørplanleggingsskole, mer som en "operativsystemkjerne", egnet for klare statsgrenser, kontrollerbar høyfrekvent handel, er en maskinvareingeniørstil, for å kjøre kjeden som maskinvare (Hardware-grade parallell utførelse); Aptos er en systemfeiltolerant, mer som en "databasesamtidighetsmotor", egnet for kontraktssystemer med sterk tilstandskobling og komplekse anropskjeder. Aptos og Sui er som programmeringsspråkingeniører, og ressurssikkerhet i programvareklasse representerer den tekniske implementeringsveien til Web3 parallell databehandling under forskjellige filosofier.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 er en offentlig transaksjonskjede med høy ytelse bygget basert på Cosmos SDK, og dens parallellitetsevne gjenspeiles hovedsakelig i to aspekter: den flertrådede matchingsmotoren (Parallel Matching Engine) og den parallelle utførelsesoptimaliseringen av det virtuelle maskinlaget, som er designet for å betjene transaksjonsscenarier med høy frekvens og lav latens på kjeden, for eksempel ordrebok DEX, utvekslingsinfrastruktur på kjeden, etc.

  Kjerneparallellitetsmekanisme:

  1. Parallell matchingsmotor: SEI V2 introduserer en flertrådet utførelsesbane i ordrematchingslogikken, og deler den ventende ordreboken og matchingslogikken på trådnivå, slik at matchingsoppgavene mellom flere handelspar kan behandles parallelt og unngå den enkelttrådede flaskehalsen.
  2. Samtidighetsoptimalisering på virtuell maskinnivå: Sei V2 bygger et CosmWasm-kjøretidsmiljø med samtidige utførelsesmuligheter, som gjør at noen kontraktkall kan kjøres parallelt uten tilstandskonflikter, og samarbeider med transaksjonstypeklassifiseringsmekanismen for å oppnå høyere gjennomstrømmingskontroll.
  3. Parallell konsensus og planlegging av utførelseslag: Den såkalte "Twin-Turbo"-konsensusmekanismen introduseres for å styrke gjennomstrømningen og frakoblingen mellom konsensuslaget og utførelseslaget, og forbedre den generelle blokkbehandlingseffektiviteten.

  3.4 UTXO Model Reformer Fuel Fuel er

  et høyytelses utførelseslag designet basert på Ethereums modulære arkitektur, og kjerneparallellitetsmekanismen er avledet fra den forbedrede UTXO-modellen (Unspent Transaction Output). I motsetning til Ethereums kontomodell, bruker Fuel en UTXO-struktur for å representere eiendeler og tilstander, som er iboende tilstandsisolert, noe som gjør det enkelt å bestemme hvilke transaksjoner som trygt kan utføres parallelt. I tillegg introduserer Fuel sitt egenutviklede smarte kontraktsspråk Sway (ligner på Rust), kombinert med statiske analyseverktøy, for å bestemme inngangskonflikter før transaksjoner utføres, for å oppnå effektiv og sikker parallell planlegging på transaksjonsnivå. Det er et EVM-alternativt utførelseslag som balanserer ytelse og modularitet.

  4. Aktørmodell: Et nytt paradigme for samtidig utførelse

  av agenter Aktørmodell er et parallelt utførelsesparadigme basert på agent eller prosess, som er forskjellig fra den tradisjonelle synkrone databehandlingen av global tilstand på kjeden (Solana/Sui/Monad og andre "on-chain parallel computing"-scenarier), som understreker at hver agent har en uavhengig tilstand og oppførsel, og kommuniserer og planlegger gjennom asynkrone meldinger. Under denne arkitekturen kan on-chain-systemet kjøres samtidig av et stort antall prosesser som er frakoblet hverandre, og har sterk skalerbarhet og asynkron feiltoleranse. Representative prosjekter inkluderer AO (Arweave AO), ICP (Internet Computer) og Cartesi, som driver utviklingen av blokkjede fra en utførelsesmotor til et "on-chain-operativsystem", som gir en innebygd infrastruktur for AI-agenter, multi-task-interaksjoner og kompleks logisk orkestrering.

  Mens utformingen av Actor-modellen ligner på sharding når det gjelder overfladiske egenskaper (f.eks. parallellitet, tilstandsisolering og asynkron prosessering), representerer de to i hovedsak helt forskjellige tekniske veier og systemfilosofier. Aktørmodellen legger vekt på "asynkron databehandling med flere prosesser", der hver agent kjører uavhengig, opprettholder tilstand uavhengig og samhandler på en meldingsdrevet måte. Sharding, derimot, er en «horisontal sharding av stat og konsensus»-mekanisme, som deler hele blokkjeden inn i flere delsystemer (shards) som behandler transaksjoner uavhengig. Aktørmodeller er mer som et "distribuert agentoperativsystem" i Web3-verdenen, mens sharding er en strukturell skaleringsløsning for transaksjonsbehandlingsmuligheter på kjeden. Begge oppnår parallellitet, men har forskjellige utgangspunkt, mål og utførelsesarkitekturer.

  4.1 AO (Arweave), en superparallell datamaskin på toppen av lagringslagetAO

  er en desentralisert dataplattform som kjører på Arweaves permanente lagringslag, med kjernemålet å bygge et operativsystem på kjeden som støtter driften av storskala asynkrone agenter.

  Kjernearkitekturfunksjoner:

  • Prosessarkitektur: Hver agent kalles en prosess, med uavhengig tilstand, uavhengig planlegger og utførelseslogikk;
  • Ingen blokkjedestruktur: AO er ikke en kjede, men et desentralisert lagringslag + multi-agent meldingsdrevet utførelsesmotor basert på Arweave;
  • Asynkront meldingsplanleggingssystem: Prosesser kommuniserer med hverandre gjennom meldinger, tar i bruk en låsfri asynkron driftsmodell og støtter naturlig samtidig utvidelse.
  • Permanent tilstandslagring: Alle agenttilstander, meldingsposter og instruksjoner registreres permanent på Arweave, noe som sikrer full revisjonsevne og desentralisert åpenhet.
  • Agent-innfødt: Den er egnet for distribusjon av komplekse flertrinnsoppgaver (som AI-agenter, DePIN-protokollkontrollere, automatiske oppgaveorkestratorer, etc.), og kan bygge en "AI-koprosessor på kjeden".

  AO tar den ultimate ruten med "agent native + storage driver + chainless architecture", med vekt på fleksibilitet og modulfrakobling, og er et "mikrokjernerammeverk på kjeden bygget på toppen av lagringslaget", med systemgrensen bevisst krympet, med vekt på lett databehandling + komponerbar kontrollstruktur.

  4.2 ICP (Internet Computer), en full-stack Web3-vertsplattformICP

  er en Web3-native full-stack on-chain applikasjonsplattform lansert av DFINITY, med mål om å utvide datakraft på kjeden til Web2-lignende opplevelser, og støtte komplett tjenestehosting, domenenavnbinding og serverløs arkitektur.

  Kjernearkitekturfunksjoner:

  • Beholderarkitektur (beholdere som agenter): Hver beholder er en agent som kjører på en virtuell Wasm-maskin med uavhengige tilstands-, kode- og asynkrone planleggingsfunksjoner.
  • Subnet Distributed Consensus System (Subnet): Hele nettverket består av flere subnett, som hver opprettholder et sett med beholdere og når konsensus gjennom BLS-signaturmekanismen.
  • Asynkron aktiveringsmodell: Canister kommuniserer med Canister gjennom asynkrone meldinger, støtter ikke-blokkerende kjøring og har naturlig parallellitet.
  • Webhotell på kjeden: Den støtter smarte kontrakter for direkte å være vert for front-end-sider, innebygd DNS-kartlegging, og er den første blokkjedeplattformen som støtter nettlesere for direkte tilgang til dApps;
  • Systemet har komplette funksjoner: Det har system-APIer som varm oppgradering på kjeden, identitetsautentisering, distribuert tilfeldighet og timer, som er egnet for kompleks distribusjon av tjenester på kjeden.

  ICP velger et operativsystemparadigme med tung plattform, integrert emballasje og sterk plattformkontroll, og har et "blokkjedeoperativsystem" som integrerer konsensus, utførelse, lagring og tilgang, med vekt på komplette tjenestevertsfunksjoner og utvider systemgrensen til en fullstack Web3-vertsplattform.

  I tillegg kan de parallelle databehandlingsprosjektene til andre Actor Model-paradigmer henvises til følgende tabell:

  

  5. Sammendrag og prospektBasert

  på forskjellene mellom virtuell maskinarkitektur og språksystem, kan blockchain parallelle databehandlingsløsninger grovt deles inn i to kategorier: EVM parallell forbedringskjede og native parallell arkitekturkjede (ikke-EVM).

  På grunnlag av å beholde kompatibiliteten til EVM/Solidity-økosystemet, oppnår førstnevnte høyere gjennomstrømning og parallelle prosesseringsevner gjennom dyptgående optimalisering av utførelseslaget, som er egnet for scenarier som ønsker å arve Ethereum-eiendeler og utviklingsverktøy og oppnå ytelsesgjennombrudd samtidig. Representative prosjekter inkluderer:

  • Monad: Implementerer en optimistisk parallell utførelsesmodell som er kompatibel med EVM gjennom utsatt skriving og konfliktdeteksjon under kjøring, bygger avhengighetsgrafer og planlegger utførelse etter at konsensus er fullført.
  • MegaETH: Abstraherer hver konto/kontrakt i en uavhengig mikro-VM, og implementerer svært frakoblet parallell planlegging på kontonivå basert på asynkrone meldinger og tilstandsavhengige grafer.
  • Pharos: Bygg en samlenettarkitektur for å oppnå parallell behandling på systemnivå på tvers av prosesser gjennom asynkrone pipeliner og SPN-moduler.
  • Reddio: Bruker zkRollup + GPU-arkitekturen for å akselerere verifiseringsprosessen utenfor kjeden til zkEVM gjennom batch SNARK-generering og forbedre verifiseringsgjennomstrømningen.

  Sistnevnte kvitter seg fullstendig med begrensningene i Ethereums kompatibilitet og redesigner utførelsesparadigmet fra den virtuelle maskinen, tilstandsmodellen og planleggingsmekanismen for å oppnå naturlig høyytelses samtidighet. Typiske underklasser inkluderer:

  • Solana (SVM): en parallell utførelsesmodell på kontonivå basert på kontotilgangskrav og statisk konfliktgrafplanlegging;
  • Sui / Aptos (MoveVM-system): Basert på ressursobjektmodellen og typesystemet, støtter den statisk analyse på kompileringstidspunktet og realiserer parallellitet på objektnivå.
  • Sei V2 (Cosmos SDK-rute): introduserer en flertrådet matchingsmotor og samtidighetsoptimalisering av virtuelle maskiner i Cosmos-arkitekturen, som er egnet for transaksjonsapplikasjoner med høy frekvens.
  • Drivstoff (UTXO + Sway-arkitektur): Parallellitet på transaksjonsnivå gjennom statisk analyse av UTXO-inngangssettet, som kombinerer et modulært utførelseslag med et tilpasset smart kontraktsspråk Sway;

  I tillegg, som et mer generalisert parallelt system, bygger Actor Model et utførelsesparadigme på kjeden for "multi-agent uavhengig operasjon + meldingsdrevet samarbeid" gjennom en asynkron prosessplanleggingsmekanisme basert på Wasm eller tilpassede VM-er. Representative prosjekter inkluderer:

  • AO (Arweave AO): Bygge et asynkront mikrokjernesystem på kjeden basert på den vedvarende lagringsdrevne agentkjøretiden;
  • ICP (Internet Computer): bruker den containeriserte agenten (Canister) som den minste enheten for å oppnå asynkron og svært skalerbar utførelse gjennom subnettkoordinering.
  • Cartesi: Introduserer Linux-operativsystemet som et off-chain databehandlingsmiljø for å gi en verifiseringsbane på kjeden for pålitelige databehandlingsresultater, egnet for komplekse eller ressurskrevende applikasjonsscenarier.

  Basert på logikken ovenfor kan vi oppsummere det nåværende vanlige offentlige kjedeskjemaet for parallell databehandling i en klassifiseringsstruktur som vist i følgende figur:

  

  Fra et bredere skaleringsperspektiv fokuserer sharding og rollup (L2) på horisontal skalering gjennom tilstandsfragmentering eller utførelse utenfor kjeden, mens parallelle datakjeder (f.eks. Monad, Sui, Solana) og aktørorienterte systemer (f.eks. AO, ICP) rekonstruerer utførelsesmodellen direkte og oppnår naturlig parallellitet i kjeden eller på systemlaget. Førstnevnte forbedrer gjennomstrømningen i kjeden gjennom flertrådede virtuelle maskiner, objektmodeller, transaksjonskonfliktanalyse, etc.; Sistnevnte tar prosessen/agenten som den grunnleggende enheten og tar i bruk meldingsdrevne og asynkrone utførelsesmoduser for å oppnå samtidig drift med flere agenter. I motsetning til dette er sharding og rollups mer som å "dele belastningen til flere kjeder" eller "outsource utenfor kjeden", mens den parallelle kjeden og aktørmodellen "frigjør ytelsespotensialet fra selve utførelsesmotoren", noe som gjenspeiler en mer grundig arkitektonisk utvikling.

  Parallell databehandling vs Sharding-arkitektur vs Rollup-skalering vs aktørorientert skaleringsbanesammenligning

  

  Det skal påpekes at de fleste av de opprinnelige parallelle arkitekturkjedene har gått inn i lanseringsstadiet for hovednettet, selv om det generelle utviklerøkosystemet fortsatt er vanskelig å sammenligne med Solidity-systemet til EVM-systemet, men prosjektene representert av Solana og Sui, med sin høyytelses utførelsesarkitektur og den gradvise velstanden til økologiske applikasjoner, har blitt kjerneoffentlige kjeder som markedet legger stor vekt på.

  I motsetning til dette, selv om Ethereum Rollup (L2)-økosystemet har gått inn i stadiet med "10 000 kjeder samtidig" eller til og med "overkapasitet", er den nåværende mainstream EVM-parallellforbedringskjeden fortsatt generelt i testnettstadiet, og har ennå ikke blitt verifisert av det faktiske mainnet-miljøet, og dens skaleringsevne og systemstabilitet må fortsatt testes ytterligere. Det gjenstår å se om disse prosjektene kan forbedre EVM-ytelsen betydelig og drive økologiske sprang uten å ofre kompatibilitet, eller om de kan differensiere Ethereums likviditets- og utviklingsressurser ytterligere.