Web3 Parallel Computing Track Panorama: paras ratkaisu alkuperäiseen skaalaukseen?

Kirjoittaja: 0xjacobzhao ja ChatGPT 4oLohkoketjun

"turvallisuuden", "hajauttamisen" ja "skaalautuvuuden" "lohkoketjutrilemma" paljastaa lohkoketjujärjestelmien suunnittelun olennaisen kompromissin, eli lohkoketjuprojektien on vaikea saavuttaa "äärimmäistä turvallisuutta, kaikki voivat osallistua ja nopeaa käsittelyä" samanaikaisesti. Vastauksena ikuiseen "skaalautuvuuden" aiheeseen markkinoiden valtavirran lohkoketjun skaalausratkaisut on jaettu paradigmojen mukaan, mukaan lukien:

• Suorituksella tehostettu skaalaus: Parantaa suoritusominaisuuksia paikan päällä, kuten rinnakkaisuutta, GPU:ta ja moniytimistä
• tilaeristetty skaalaus: Vaakasuunnassa jaettu tila/sirpale, esim. sirpaleet, UTXO ja useat aliverkot
• Ketjun ulkopuolinen ulkoistettu skaalaus: Suorituksen siirtäminen ketjun ulkopuolelle, kuten rollupit, Apuprosessorin ja DA-rakenteen
• irtikytkentäskaalaus: Modulaarinen arkkitehtuuri ja yhteistyötoiminta, kuten moduuliketju, jaettu sekvensseri, Rollup Mesh
• Asynkroninen samanaikainen skaalaus: Toimijamalli, prosessin eristys, viestipohjainen, kuten agentti, monisäikeinen asynkroninen ketju

  Lohkoketjun skaalausratkaisu sisältää: ketjun sisäisen rinnakkaislaskennan, rollupin, sirpaloinnin, DA-moduulin, modulaarisen rakenteen, toimijajärjestelmän, zk-proof-pakkauksen, tilattoman arkkitehtuurin jne., joka kattaa useita suoritustasoja, tilaa, dataa ja rakennetta, ja se on täydellinen skaalausjärjestelmä, jossa on "monikerroksinen yhteistyö ja moduuliyhdistelmä". Tässä artikkelissa keskitytään skaalausmenetelmiin, jotka valtavirtaistavat rinnakkaislaskennan.

  Ketjun sisäinen rinnakkaisuus, joka keskittyy lohkon sisäisten transaktioiden/ohjeiden rinnakkaiseen suorittamiseen. Rinnakkaismekanismin mukaan sen skaalausmenetelmät voidaan jakaa viiteen luokkaan, joista jokainen edustaa erilaista suorituskykytavoitetta, kehitysmallia ja arkkitehtuurifilosofiaa, ja rinnakkaisrakeisuus hienostuu ja tarkentuu, rinnakkaisuuden intensiteetti kasvaa ja kasvaa, ajoituksen monimutkaisuus kasvaa ja myös ohjelmoinnin monimutkaisuus ja toteutuksen vaikeus kasvavat ja kasvavat.

  • Tilitaso: Edustaa projektia
  • Objektitaso: Edustaa projektia Sui
  • Tapahtumataso: Edustaa projektia Monad, Aptos
  • Call-level / MicroVM : Opetustason MegaETH:
  • GatlingX

  Ketjun ulkopuolinen asynkroninen samanaikaisuusmalli, jota edustaa Actor / Actor Model, kuuluu toiseen rinnakkaisen laskennan paradigmaan, ketjujen välisenä/asynkronisena viestijärjestelmänä (ei-lohkosynkronointimalli), jokainen agentti toimii itsenäisesti "agenttiprosessina", asynkroniset viestit rinnakkaistilassa, tapahtumalähtöinen, ei synkronista ajoitusta, edustavat projektit, kuten AO, ICP, Cartesi jne.

  Tunnettu koonti- tai sirpaleiden skaalausmalli kuuluu järjestelmätason samanaikaisuusmekanismiin, ei ketjun sisäiseen rinnakkaislaskentaan. Ne saavuttavat skaalautumisen "ajamalla useita ketjuja/suoritusalueita rinnakkain" sen sijaan, että ne lisäisivät rinnakkaisuutta yhden lohkon/virtuaalikoneen sisällä. Tämäntyyppinen skaalausratkaisu ei ole tämän artikkelin painopiste, mutta käytämme sitä silti arkkitehtonisten konseptien yhtäläisyyksien ja erojen vertailuun.

  

  2. EVM:n rinnakkaisparannusketju: Suorituskyvyn rajan rikkominen yhteensopivuudessa

  Ethereumin sarjakäsittelyarkkitehtuurin kehittämisen jälkeen se on käynyt läpi useita skaalausyrityksiä, kuten sirpalointia, rollupia ja modulaarista arkkitehtuuria, mutta suorituskerroksen läpimenon pullonkaulaa ei ole vieläkään pohjimmiltaan rikottu. Mutta samaan aikaan EVM ja Solidity ovat edelleen älykkäitä sopimusalustoja, joilla on eniten kehittäjäpohjaa ja ekologista potentiaalia. Siksi EVM:n rinnakkaisparannusketjusta on tulossa tärkeä suunta uudelle skaalaus- ja kehityskierrokselle keskeisenä polkuna, joka ottaa huomioon ekologisen yhteensopivuuden ja toteutuksen suorituskyvyn parantamisen. Monad ja MegaETH ovat edustavimmat projektit tähän suuntaan, alkaen lykätystä suorituksesta ja tilan hajottamisesta, rakentaakseen EVM-rinnakkaiskäsittelyarkkitehtuurin korkean samanaikaisuuden ja suuren suorituskyvyn skenaarioita varten.

  Monadin Parallel Computing

  AnalysisMonad on korkean suorituskyvyn Layer1-lohkoketju, joka on suunniteltu uudelleen Ethereum Virtual Machinelle (EVM) ja joka perustuu rinnakkaiseen putkilinjauksen peruskonseptiin, jossa on asynkroninen suoritus konsensuskerroksessa ja optimistinen samanaikaisuus suorituskerroksessa Rinnakkainen suoritus) 。 Lisäksi konsensus- ja tallennuskerroksissa Monad on ottanut käyttöön korkean suorituskyvyn BFT-protokollan (MonadBFT) ja erillisen tietokantajärjestelmän (MonadDB) päästä päähän -optimoinnin saavuttamiseksi.

  Pipelining: Monivaiheinen putkilinjan rinnakkainen suoritusmekanismi

  Pipelining on Monadin rinnakkaissuorituksen peruskonsepti, ja sen ydinajatuksena on jakaa lohkoketjun suoritusprosessi useisiin itsenäisiin vaiheisiin ja käsitellä nämä vaiheet rinnakkain kolmiulotteisen putkiarkkitehtuurin muodostamiseksi, jokainen vaihe toimii itsenäisillä säikeillä tai ytimillä lohkojen välisen samanaikaisen käsittelyn saavuttamiseksi. Tuloksena on suurempi suorituskyky ja pienempi latenssi. Näitä vaiheita ovat: Ehdotus, konsensus, toteutus ja sitoutuminen.

  Asynkroninen toteutus: Konsensus - Suoritus on asynkronisesti irrotettuPerinteisissä

  ketjuissa transaktiokonsensus ja toteutus ovat usein synkronisia prosesseja, ja tämä sarjamalli rajoittaa merkittävästi suorituskyvyn skaalausta. Monad toteuttaa konsensuskerroksen asynkronisena, suorituskerroksen asynkronisena ja tallennustilan asynkronisena "asynkronisen suorituksen" kautta. Lyhennä merkittävästi lohkoaikaa ja vahvistusviivettä, mikä tekee järjestelmästä joustavamman, prosessoinnin segmentoidumman ja resurssien käytön.

  Ydinsuunnittelu:

  • Konsensusprosessi (konsensuskerros) vastaa vain tapahtumien lajittelusta eikä toteuta sopimuslogiikkaa.
  • Suoritusprosessi (suorituskerros) käynnistyy asynkronisesti konsensuksen päätyttyä.
  • Kun konsensus on valmis, se siirtyy seuraavan lohkon konsensusprosessiin välittömästi odottamatta suorituksen valmistumista.

  Optimistinen rinnakkaistoteutus: Optimistinen rinnakkaistoteutusPerinteinen

  Ethereum käyttää tiukasti sarjamallia transaktioiden suorittamiseen tilaristiriitojen välttämiseksi. Monad puolestaan omaksuu "optimistisen rinnakkaistoteutuksen" strategian lisätäkseen merkittävästi transaktioiden käsittelynopeutta.

  Toteutusmekanismi:

  • Monad suorittaa optimistisesti kaikki transaktiot rinnakkain olettaen, että suurin osa transaktioista on tilattomia ja konfliktittomia.
  • Suorita myös "Ristiriitojen tunnistin" seurataksesi, käytetäänkö samaa tilaa (esim. luku-/kirjoitusristiriidat) tapahtumien välillä.
  • Jos ristiriita havaitaan, ristiriitainen tapahtuma sarjoitetaan ja suoritetaan uudelleen tilan oikeellisuuden varmistamiseksi.

  Monad on valinnut yhteensopivan tien: siirtää mahdollisimman vähän EVM-sääntöjä, saavuttaa rinnakkaisuus lykkäämällä kirjoitustilaa ja havaitsemalla dynaamisesti ristiriidat suorituksen aikana, mikä on enemmän kuin Ethereumin suorituskykyversio, jonka kypsyystaso helpottaa siirtymistä EVM-ekosysteemiin ja on rinnakkaiskiihdytin EVM-maailmassa.

  MegaETH:n rinnakkaislaskentamekanismin resoluutio

  eroaa Monadin L1-paikannuksesta, ja MegaETH on sijoitettu EVM-yhteensopivaksi modulaariseksi korkean suorituskyvyn rinnakkaissuorituskerrokseksi, jota voidaan käyttää itsenäisenä L1-julkisena ketjuna, toteutuksen parannuskerroksena tai modulaarisena komponenttina Ethereumissa. Sen suunnittelun ydintavoitteena on purkaa tilin logiikka, suoritusympäristö ja tilan eristys pienimmäksi yksiköksi, joka voidaan ajoittaa itsenäisesti korkean samanaikaisuuden suorittamisen ja pienen viiveen vasteominaisuuden saavuttamiseksi ketjussa. MegaETH:n ehdottama keskeinen innovaatio on, että Micro-VM-arkkitehtuuri + State Dependency DAG (suunnattu ja asyklinen tilariippuvuuskaavio) ja modulaarinen synkronointimekanismi rakentavat yhdessä rinnakkaisen suoritusjärjestelmän ketjun sisäistä säikeistystä varten.

  Micro-VM-arkkitehtuuri: Tilit ovat säikeitä

  MegaETH esittelee suoritusmallin "yksi mikro-VM tiliä kohden", joka "säikkeettää" suoritusympäristön ja tarjoaa vähimmäiseristysyksikön rinnakkaista ajoitusta varten. Nämä virtuaalikoneet kommunikoivat keskenään asynkronisten viestien kautta synkronisten kutsujen sijaan, ja suuri määrä virtuaalikoneita voidaan suorittaa itsenäisesti, tallentaa itsenäisesti ja luonnollisesti rinnakkain.

  State Dependency DAG: graafipohjainen aikataulutusmekanismi

  MegaETH on rakentanut tilin tilan käyttöoikeussuhteeseen perustuvan DAG-aikataulutusjärjestelmän, ja järjestelmä ylläpitää globaalia riippuvuuskaaviota reaaliajassa, ja mitä tilejä muokataan ja mitkä tilit luetaan kullekin tapahtumalle, mallinnetaan kaikki riippuvuuksiksi. Ristiriitattomat tapahtumat voidaan suorittaa suoraan rinnakkain, ja riippuvaiset tapahtumat ajoitetaan ja lajitellaan sarjaan tai lykätään topologisessa järjestyksessä. Riippuvuuskaaviot varmistavat tilan johdonmukaisuuden ja päällekkäiset kirjoitukset rinnakkaisen suorituksen aikana.

  Asynkroninen suoritus- ja takaisinsoittomekanismi

  MegaETH on rakennettu asynkronisen ohjelmointiparadigman päälle, joka on samanlainen kuin Actor Modelin asynkroninen viestinvälitys, ratkaisemaan perinteisten EVM-sarjakutsujen ongelman. Sopimuskutsut ovat asynkronisia (ei-rekursiivinen suoritus), ja kun sopimus A -> B -> C kutsutaan, jokainen kutsu on asynkroninen estämättä odottamista; Kutsupino laajennetaan asynkroniseksi kutsukaavioksi; Tapahtumien käsittely = asynkronisen kaavion läpikulku + riippuvuuden ratkaisu + rinnakkainen ajoitus.

  Kaiken kaikkiaan MegaETH rikkoo perinteisen EVM:n yksisäikeisen tilakonemallin, toteuttaa mikrovirtuaalikoneiden kapseloinnin tilikohtaisesti, suorittaa tapahtumien ajoituksen tilariippuvaisten kaavioiden avulla ja korvaa synkronisen kutsupinon asynkronisella viestintämekanismilla. Se on rinnakkainen laskenta-alusta, joka on suunniteltu uudelleen "tilirakenteen→ aikatauluarkkitehtuurin → toteutusprosessin kaikista ulottuvuuksista", mikä tarjoaa paradigmatason uuden idean seuraavan sukupolven korkean suorituskyvyn ketjun sisäisen järjestelmän rakentamiseen.

  MegaETH on valinnut refaktorointipolun: se abstraktoi tilit ja sopimukset täysin itsenäisiksi virtuaalikoneiksi ja vapauttaa äärimmäisen rinnakkaisuuspotentiaalin asynkronisen suoritusaikataulutuksen avulla. Teoriassa MegaETH:lla on korkeampi rinnakkaiskatto, mutta sitä on myös vaikeampi hallita monimutkaisuudessa, ja se on enemmän kuin Ethereum-konseptin mukainen superhajautettu käyttöjärjestelmä.

  

  Monad ja MegaETH Molemmilla on erilaiset suunnittelukonseptit kuin sirpalointi: sirpalointi jakaa lohkoketjun vaakasuunnassa useisiin itsenäisiin aliketjuihin (sirpaleihin), joista jokainen on vastuussa osasta transaktioita ja tilaa, mikä rikkoo yhden ketjun rajoituksen ja skaalautuu verkkokerroksessa; Toisaalta sekä Monad että MegaETH ylläpitävät yksittäisen ketjun eheyttä, skaalautuvat vaakasuunnassa vain suorituskerroksessa ja suorittavat optimointiläpimurtoja rinnakkain yksittäisen ketjun rajalla. Nämä kaksi edustavat kahta suuntaa: pystysuoraa vahvistamista ja horisontaalista laajentumista lohkoketjun laajentumispolulla.

  Rinnakkaislaskentaprojektit, kuten Monad ja MegaETH, keskittyvät pääasiassa suorituskyvyn optimointipolkuun, ja niiden keskeisenä tavoitteena on parantaa ketjun sisäistä TPS:ää ja saavuttaa transaktio- tai tilitason rinnakkaiskäsittely lykätyn suorituksen ja mikro-VM-arkkitehtuurien avulla. Pharos Network on modulaarinen, täyden pinon rinnakkainen L1-lohkoketjuverkko, ja sen ydinrinnakkaislaskentajärjestelmä on nimeltään "Rollup Mesh". Tämä arkkitehtuuri tukee usean virtuaalin koneympäristöjä (EVM ja Wasm) pääverkon ja erikoisprosessointiverkkojen (SPN) synergian kautta ja integroi kehittyneitä teknologioita, kuten nollatietotodisteita (ZK) ja luotettuja suoritusympäristöjä (TEE).

  Rollup Mesh Parallel Computing Analysis:

  1. Koko elinkaaren asynkroninen pipelining: Pharos irrottaa tapahtuman eri vaiheet (kuten konsensuksen, suorituksen ja tallennuksen) ja ottaa käyttöön asynkronisen käsittelyn, jotta jokainen vaihe voidaan suorittaa itsenäisesti ja rinnakkain, mikä parantaa käsittelyn yleistä tehokkuutta.
  2. Kahden VM:n rinnakkainen suoritus: Pharos tukee sekä EVM- että WASM-virtuaalikoneympäristöjä, jolloin kehittäjät voivat valita tarpeisiinsa sopivan suoritusympäristön. Tämä kahden VM:n arkkitehtuuri ei ainoastaan lisää järjestelmän joustavuutta, vaan myös lisää tapahtumien käsittelyä rinnakkaisen suorituksen avulla.
  3. Erityiset prosessointiverkot (SPN): SPN:t ovat Pharos-arkkitehtuurin avainkomponentteja, jotka ovat samanlaisia kuin modulaariset aliverkot, jotka on suunniteltu käsittelemään tietyntyyppisiä tehtäviä tai sovelluksia. SPN:ien avulla Pharos mahdollistaa resurssien dynaamisen allokoinnin ja tehtävien rinnakkaisen käsittelyn, mikä parantaa entisestään järjestelmän skaalautuvuutta ja suorituskykyä.
  4. Modulaarinen konsensus ja uudelleenrakentaminen: Pharos esittelee joustavan konsensusmekanismin, joka tukee useita konsensusmalleja (kuten PBFT, PoS, PoA) ja mahdollistaa turvallisen jakamisen ja resurssien integroinnin pääverkon ja SPN:ien välillä uudelleenpanostusprotokollan kautta.

  Lisäksi Pharos rekonstruoi suoritusmallin tallennusmoottorin alimmasta kerroksesta moniversioisen Merkle-puun, Delta-koodauksen, versionoidun osoitteen ja ADS Pushdown -tekniikan avulla ja lanseeraa Pharos Storen, tehokkaan tallennusmoottorin alkuperäiselle lohkoketjulle, saavuttaakseen korkean suorituskyvyn, alhaisen latenssin ja vahvat todennettavissa olevat ketjun käsittelyominaisuudet.

  Yleisesti ottaen Pharosin Rollup Mesh -arkkitehtuuri saavuttaa korkean suorituskyvyn rinnakkaislaskentaominaisuudet modulaarisen suunnittelun ja asynkronisen käsittelymekanismin avulla.

  Monadin, MegaETH:n ja Pharosin rinnakkaisten suoritusarkkitehtuurien lisäksi havaitsemme myös, että markkinoilla on joitain projekteja, jotka tutkivat GPU-kiihdytyksen sovelluspolkua EVM-rinnakkaislaskennassa tärkeänä täydennyksenä ja huippuluokan kokeiluna EVM-rinnakkaisekosysteemiin. Niistä Reddio ja GatlingX ovat kaksi edustavaa suuntaa:

  • Reddio on korkean suorituskyvyn alusta, joka yhdistää zkRollupin ja GPU:n rinnakkaissuoritusarkkitehtuurin, ja sen ydin on EVM:n suoritusprosessin rekonstruoiminen ja suorituskerroksen alkuperäisen rinnakkaisasettelun toteuttaminen monisäikeisen ajoituksen, asynkronisen tilatallennuksen ja GPU-kiihdytetyn transaktioerien suorittamisen avulla. Rinnakkainen rakeisuus tapahtumatasolla + toimintatasolla (monisäikeinen suoritusopkoodi). Se on suunniteltu ottamaan käyttöön monisäikeinen eräsuoritus, asynkroninen tilalataus ja GPU:n rinnakkaisprosessointitapahtumalogiikka (CUDA-yhteensopiva rinnakkainen EVM). Kuten Monad / MegaETH, Reddio keskittyy myös rinnakkaiseen käsittelyyn suorituskerroksessa, erona on, että suoritusmoottori rekonstruoidaan GPU-rinnakkaisarkkitehtuurin avulla, joka on suunniteltu korkean suorituskyvyn ja laskentaintensiivisiin skenaarioihin, kuten tekoälypäättelyyn. GatlingX,
  • joka kutsuu itseään "GPU-EVM:ksi", ehdottaa radikaalimpaa arkkitehtuuria, joka yrittää siirtää perinteisten EVM-virtuaalikoneiden "käskytason sarjasuoritusmallin" GPU-natiiviseen rinnakkaisajoympäristöön. Ydinmekanismi on kääntää EVM-tavukoodi dynaamisesti CUDA-rinnakkaistehtäviksi ja suorittaa käskyvirta GPU:n moniytimisen kautta, jotta EVM:n peräkkäinen pullonkaula murtuu alimmalla tasolla. Rinnakkaisrakeisuus, joka kuuluu opetustason rinnakkaisuuteen (ILP). Verrattuna Monadin / MegaETH:n "transaktiotason/tilitason" rinnakkaiseen rakeisuuteen, GatlingX:n rinnakkaisuusmekanismi kuuluu käskytason optimointipolkuun, joka on lähempänä virtuaalikoneen moottorin taustalla olevaa refaktorointia. Se on tällä hetkellä konseptivaiheessa, ja raportti ja arkkitehtoninen luonnos on julkaistu, eikä SDK:ta tai pääverkkoa ole vielä julkaistu.

  Artela ehdottaa erilaista, rinnakkaista suunnittelukonseptia. EVM++-arkkitehtuurin WebAssembly (WASM) -virtuaalikoneen käyttöönoton myötä kehittäjät voivat dynaamisesti lisätä ja suorittaa laajennuksia ketjussa käyttämällä Spect-ohjelmointimallia säilyttäen samalla EVM-yhteensopivuuden. Se käyttää sopimuksen kutsun rakeisuutta (funktio / laajennus) rinnakkaisyksikkönä ja tukee laajennusmoduulien injektointia (samanlainen kuin "kytkettävä väliohjelmisto") EVM-sopimuksen ollessa käynnissä, jotta saavutetaan looginen irtikytkentä, asynkroninen kutsu ja moduulitason rinnakkaissuoritus. Suorituskerroksen koottavuuteen ja modulaariseen arkkitehtuuriin kiinnitetään enemmän huomiota. Konsepti tarjoaa uusia ideoita monimutkaisiin monimoduulisovelluksiin tulevaisuudessa.

  3. Natiivi rinnakkaisarkkitehtuuriketju: Ethereumin EVM-suoritusmalli, rekonstruoidun VM:n suoritusontologia

  , on suunnittelunsa

  alusta lähtien ottanut käyttöön yksisäikeisen arkkitehtuurin "täysi transaktiotilaus + sarjasuoritus", jonka tarkoituksena on varmistaa tilamuutosten varmuus ja johdonmukaisuus kaikille verkon solmuille. Tällä arkkitehtuurilla on kuitenkin luonnollinen pullonkaula suorituskyvyssä, joka rajoittaa järjestelmän suorituskykyä ja skaalautuvuutta. Sitä vastoin Cosmos SDK:hen rakennetut alkuperäiset rinnakkaislaskenta-arkkitehtuuriketjut, kuten Solana (SVM), MoveVM (Sui, Aptos) ja Sei v2, on räätälöity rinnakkaiseen suoritukseen taustalla olevasta suunnittelusta, ja niillä on seuraavat edut:

  • Tilamallien luonnollinen erottaminen: Solana käyttää tilin lukituksen määritysmekanismia, MoveVM ottaa käyttöön objektin omistajuusmallin ja Sei v2 perustuu tapahtumatyypin luokitukseen. Staattinen ristiriitojen arviointi toteutuu ja tapahtumatason samanaikaista ajoitusta tuetaan.
  • Virtuaalikoneet on optimoitu samanaikaisuutta varten: Solanan Sealevel-moottori tukee natiivisti monisäikeistä suoritusta; MoveVM voi suorittaa staattisen samanaikaisuuskaavioanalyysin; Sei v2 integroi monisäikeisen sovitusmoottorin rinnakkaiseen VM-moduuliin.

  Tietenkin tällaisella alkuperäisellä rinnakkaisketjulla on myös ekologisen yhteensopivuuden haaste. Muut kuin EVM-arkkitehtuurit vaativat yleensä uusia kehityskieliä (kuten Move ja Rust) ja työkaluketjuja, joista aiheutuu kehittäjille tiettyjä siirtokustannuksia. Lisäksi kehittäjien on hallittava joukko uusia käsitteitä, kuten tilalliset käyttöoikeusmallit, samanaikaisuusrajoitukset, objektien elinkaaret jne., jotka asettavat korkeampia vaatimuksia kynnysarvojen ja kehitysparadigmojen ymmärtämiselle.

  3.1 Solanan ja SVM:n merenpinnan rinnakkaismoottoriperiaate

  Solanan Sealevel-toteutusmalli on tilin rinnakkaisaikataulutusmekanismi, joka on Solanan ydinmoottori rinnakkaisten transaktioiden toteuttamiseen ketjussa ja saavuttaa tehokkaan samanaikaisuuden älysopimustasolla "tiliilmoitus + staattinen ajoitus + monisäikeinen toteutus" -mekanismin avulla. Sealevel on ensimmäinen lohkoketjualan toteutusmalli, joka on onnistuneesti toteuttanut ketjun sisäisen samanaikaisen aikataulutuksen tuotantoympäristössä, ja sen arkkitehtoniset ideat ovat vaikuttaneet moniin myöhempiin rinnakkaislaskentaprojekteihin, ja se on referenssiparadigma korkean suorituskyvyn Layer 1 -rinnakkaissuunnittelulle.

  Ydinmekanismi:

  1. Eksplisiittiset tilien käyttöoikeusluettelot: Jokaisen tapahtuman on ilmoitettava kyseessä oleva tili (luku/kirjoitus) lähetettäessä, ja järjestelmä määrittää, onko tapahtumien välillä tilaristiriita.

  2. Ristiriitojen havaitseminen ja monisäikeinen ajoitus

  • Jos kahden tapahtuman käyttämien tilijoukkojen välillä ei ole risteyskohtaa→ ne voidaan suorittaa rinnakkain;
  • On ristiriita→ suoritetaan sarjassa riippuvaisessa järjestyksessä;
  • Ajoitustoiminto kohdistaa tapahtumat eri säikeisiin riippuvuuskaavion perusteella.

  3. Ohjelman kutsukonteksti: Jokainen sopimuskutsu suoritetaan eristetyssä kontekstissa ilman jaettua pinoa puheluiden välisten häiriöiden välttämiseksi.

  Sealevel on Solanan rinnakkaissuorituksen ajoitusmoottori, kun taas SVM on älykäs sopimusten toteutusympäristö, joka on rakennettu Sealevelin päälle (BPF-virtuaalikonetta käyttäen). Yhdessä ne muodostavat teknisen perustan Solanan tehokkaalle rinnakkaissuoritusjärjestelmälle.

  Eclipse on projekti, joka ottaa käyttöön Solana VM:t modulaarisiin ketjuihin, kuten Ethereum L2:een tai Celestiaan, hyödyntäen Solanan rinnakkaissuoritusmoottoria rollupin suorituskerroksena. Eclipse on yksi ensimmäisistä projekteista, jossa ehdotetaan Solanan suorituskerroksen (Sealevel + SVM) irrottamista Solanan pääverkosta ja sen siirtämistä modulaariseen arkkitehtuuriin, ja Solanan "super concurrent execution model" modulaarinen tulos on Execution Layer-as-a-Service, joten Eclipse kuuluu myös rinnakkaislaskennan luokkaan.

  Neonin reitti on erilainen, se esittelee EVM:n toimimaan SVM/Sealevel-ympäristössä. Rakenna EVM-yhteensopiva ajonaikainen kerros, kehittäjät voivat käyttää Solidityä sopimusten kehittämiseen ja suorittamiseen SVM-ympäristössä, mutta ajoituksen suorittaminen käyttää SVM + Sealevea. Neon kallistuu enemmän Modular Blockchain -luokkaan kuin rinnakkaislaskentainnovaatioihin.

  Kaiken kaikkiaan Solana ja SVM:t luottavat Sealevel-suoritusmoottoriin, ja Solanan käyttöjärjestelmään perustuva ajoitusfilosofia on samanlainen kuin ytimen ajoitus, joka on nopea mutta suhteellisen joustamaton. Se on natiivi korkean suorituskyvyn rinnakkaislaskennan julkinen ketju.

  3.2 MoveVM-arkkitehtuuri: Resurssi- ja objektipohjainen

  MoveVM on älykäs sopimusvirtuaalikone, joka on suunniteltu ketjun sisäiseen resurssiturvallisuuteen ja rinnakkaiseen suoritukseen, ja sen ydinkielen, Moven, kehitti alun perin Meta (entinen Facebook) Libra-projektia varten, korostaen käsitettä "resurssit ovat objekteja", ja kaikki ketjun tilat ovat olemassa objekteina, joilla on selkeä omistajuus ja elinkaari. Tämän avulla MoveVM voi analysoida, onko tapahtumien välillä tilaristiriitoja käännösaikana, ja toteuttaa objektitason staattisen rinnakkaisaikataulutuksen, jota käytetään laajalti alkuperäisissä rinnakkaisissa julkisissa ketjuissa, kuten Sui ja Aptos.

  Suin objektin omistajuusmallSuin

  rinnakkaislaskentaominaisuudet juontavat juurensa sen ainutlaatuisesta lähestymistavasta tilamallinnukseen ja kielitason staattiseen analyysiin. Toisin kuin perinteiset lohkoketjut, jotka käyttävät globaaleja tilapuita, Sui on rakentanut "objektiin" perustuvan oliokeskeisen mallin, joka toimii MoveVM:n lineaarisen tyyppijärjestelmän kanssa tehdäkseen rinnakkaisaikataulutuksesta deterministisen prosessin, joka voidaan suorittaa käännöshetkellä.

  • Objektimalli on Suin rinnakkaisarkkitehtuurin perusta. Sui abstraktoi kaikki ketjun tilat erillisiksi objekteiksi, joista jokaisella on yksilöllinen tunnus, selkeä omistaja (tili tai sopimus) ja tyyppimääritys. Nämä objektit eivät jaa tilaa toistensa kanssa, ja ne ovat luonnostaan eristettyjä. Sopimuksessa on nimenomaisesti ilmoitettava mukana olevien objektien kokoelma, kun sitä kutsutaan, välttäen perinteisen ketjun sisäisen "globaalin tilapuun" tilakytkentäongelman. Tämä rakenne jakaa ketjun tilan useisiin itsenäisiin yksiköihin, mikä tekee samanaikaisesta suorituksesta rakenteellisesti toteuttamiskelpoisen ajoituslähtökohdan.
  • Staattinen omistajuusanalyysi on käännösaikainen analyysimekanismi, joka on toteutettu Move-kielen lineaarisen tyyppijärjestelmän tuella. Sen avulla järjestelmä voi ajoittaa rinnakkain suoritettavat tapahtumat päättelemällä, millä tapahtumilla ei ole tilaristiriitoja objektin omistajuuden kautta ennen niiden suorittamista. Verrattuna perinteisten suoritusaikojen ristiriitojen havaitsemiseen ja palauttamiseen, Suin staattinen analyysimekanismi vähentää huomattavasti ajoituksen monimutkaisuutta ja parantaa suoritustehokkuutta, mikä on avain korkean suorituskyvyn ja determinististen rinnakkaiskäsittelyominaisuuksien saavuttamiseen.

  Sui jakaa tila-avaruuden objektikohtaisesti yhdistettynä käännösaikaiseen omistusanalyysiin edullisen, palautumattoman objektitason rinnakkaissuorituksen saavuttamiseksi. Perinteisten ketjujen sarjasuoritukseen tai ajonaikaiseen tunnistukseen verrattuna Sui on saavuttanut merkittäviä parannuksia suorituksen tehokkuudessa, järjestelmän determinismissä ja resurssien käytössä.

  Aptosin Block-STM-suoritusmekanismiAptos

  on korkean suorituskyvyn Layer1-lohkoketju, joka perustuu Move-kieleen, ja sen rinnakkaissuorituskyky on johdettu pääasiassa itse kehitetystä Block-STM (Block-level Software Transactional Memory) -kehyksestä. Toisin kuin Suin strategia "staattinen rinnakkaisuus käännöshetkellä", Block-STM kuuluu dynaamiseen aikataulutusmekanismiin "optimistinen samanaikaisuus ajon aikana + konfliktin palautus", joka soveltuu monimutkaisten riippuvuuksien transaktiojoukkojen käsittelyyn.

  Block-STM jakaa lohkon transaktion suorittamisen kolmeen vaiheeseen:

  • Spekulatiivinen suoritus: Kaikki tapahtumat ovat oletuksena ristiriitattomia ennen suorittamista, ja järjestelmä ajoittaa tapahtumat rinnakkain useiden säikeiden kanssa yrittääkseen suorittaa samanaikaisesti ja tallentaa niiden käyttämän tilin tilan (luku-/kirjoitussarjan).
  • Validointivaihe: Järjestelmä tarkistaa suoritustuloksen: jos kahden tapahtuman välillä on luku- ja kirjoitusristiriita (esimerkiksi Tx1 lukee Tx2:n kirjoittaman tilan), toinen niistä palautetaan.
  • Uudelleenyritysvaihe: Ristiriitaiset tapahtumat ajoitetaan uudelleen, kunnes niiden riippuvuudet on ratkaistu, ja lopulta kaikki tapahtumat muodostavat kelvollisen, deterministisen tilalähetysten sarjan.

  Block-STM on dynaaminen suoritusmalli "optimistisesta rinnakkaisuudesta + palautus ja uudelleenyritykset", joka soveltuu tilaintensiivisiin ja loogisesti monimutkaisiin ketjun sisäisiin transaktioiden eräkäsittelyskenaarioihin ja on Aptosin rinnakkaislaskentaydin monipuolisen ja suuren suorituskyvyn julkisen ketjun rakentamiseen.

  

  Solana on insinöörin aikataulutuskoulu, enemmän kuin "käyttöjärjestelmän ydin", joka soveltuu selkeisiin osavaltioiden rajoihin, ohjattavaan korkeataajuiseen kaupankäyntiin, on laitteistoinsinöörin tyyli, joka pyörittää ketjua kuin laitteistoa (laitteistotason rinnakkaissuoritus); Aptos on järjestelmän vikasietoinen, enemmän kuin "tietokannan samanaikaisuusmoottori", joka soveltuu sopimusjärjestelmiin, joissa on vahva tilakytkentä ja monimutkaiset puheluketjut. Aptos ja Sui ovat kuin ohjelmointikieli-insinöörejä, ja ohjelmistotason resurssiturvallisuus edustaa Web3-rinnakkaislaskennan teknistä toteutuspolkua eri filosofioiden mukaisesti.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 on korkean suorituskyvyn transaktioketju, joka on rakennettu Cosmos SDK:n pohjalta, ja sen rinnakkaisuusominaisuus heijastuu pääasiassa kahdessa näkökohdassa: monisäikeinen sovitusmoottori (Parallel Matching Engine) ja virtuaalikonekerroksen rinnakkaissuorituksen optimointi, joka on suunniteltu palvelemaan korkeataajuisia ja matalan viiveen ketjun sisäisiä transaktioskenaarioita, kuten tilauskirja DEX, ketjun sisäinen vaihtoinfrastruktuuri jne.

  Ydinrinnakkaisuusmekanismi:

  1. Rinnakkaissovitusmoottori: SEI V2 esittelee monisäikeisen suorituspolun toimeksiantojen täsmäytyslogiikkaan, joka jakaa vireillä olevan tilauskirjan ja täsmäytyslogiikan säietason tasolla, jotta useiden kaupankäyntiparien väliset täsmäytystehtävät voidaan käsitellä rinnakkain ja välttää yksisäikeinen pullonkaula.
  2. Virtuaalikonetason samanaikaisuuden optimointi: Sei V2 rakentaa CosmWasm-ajonaikaisen ympäristön, jossa on samanaikaiset suoritusominaisuudet, mikä mahdollistaa joidenkin sopimuskutsujen suorittamisen rinnakkain ilman tilaristiriitoja, ja tekee yhteistyötä tapahtumatyyppien luokittelumekanismin kanssa korkeamman suorituskyvyn hallinnan saavuttamiseksi.
  3. Rinnakkainen konsensus- ja suorituskerroksen ajoitus: Niin kutsuttu "Twin-Turbo"-konsensusmekanismi otetaan käyttöön vahvistamaan konsensuskerroksen ja suorituskerroksen välistä suorituskykyä ja irrottamista sekä parantamaan lohkojen käsittelyn yleistä tehokkuutta.

  3.4 UTXO-malli Reformer Fuel Fuel on

  korkean suorituskyvyn suorituskerros, joka on suunniteltu Ethereumin modulaarisen arkkitehtuurin pohjalta, ja sen ydinrinnakkaisuusmekanismi on johdettu parannetusta UTXO-mallista (Unspent Transaction Output). Toisin kuin Ethereumin tilimalli, Fuel käyttää UTXO-rakennetta edustamaan varoja ja tiloja, mikä on luonnostaan tilaeristetty, joten on helppo määrittää, mitkä transaktiot voidaan suorittaa turvallisesti rinnakkain. Lisäksi Fuel esittelee itse kehittämänsä älysopimuskielen Swayn (samanlainen kuin Rust) yhdistettynä staattisiin analyysityökaluihin, jotka määrittävät syöttöristiriidat ennen transaktioiden suorittamista, jotta saavutetaan tehokas ja turvallinen tapahtumatason rinnakkaisaikataulutus. Se on EVM:n vaihtoehtoinen suorituskerros, joka tasapainottaa suorituskyvyn ja modulaarisuuden.

  4. Toimijamalli: Agenttien samanaikaisen toteutuksen uusi paradigma

  Toimijamalli on agenttiin tai prosessiin perustuva rinnakkaissuoritusparadigma, joka eroaa perinteisestä ketjun globaalin tilan synkronisesta laskennasta (Solana/Sui/Monad ja muut "ketjun sisäiset rinnakkaislaskennan" skenaariot), joka korostaa, että jokaisella agentilla on itsenäinen tila ja käyttäytyminen ja että se kommunikoi ja aikatauluttaa asynkronisten viestien kautta. Tässä arkkitehtuurissa ketjun sisäistä järjestelmää voidaan käyttää samanaikaisesti suurella määrällä toisistaan irrallaan olevia prosesseja, ja sillä on vahva skaalautuvuus ja asynkroninen vikasietoisuus. Edustavia projekteja ovat AO (Arweave AO), ICP (Internet Computer) ja Cartesi, jotka edistävät lohkoketjun kehitystä suoritusmoottorista "ketjun sisäiseksi käyttöjärjestelmäksi", joka tarjoaa alkuperäisen infrastruktuurin tekoälyagenteille, monitehtävävuorovaikutukselle ja monimutkaiselle logiikan orkestrointille.

  Vaikka toimijamallin rakenne on pinnallisten ominaisuuksien (esim. rinnakkaisuus, tilan eristäminen ja asynkroninen prosessointi) suhteen samanlainen kuin sirpalointi, nämä kaksi edustavat pohjimmiltaan täysin erilaisia teknisiä polkuja ja järjestelmäfilosofioita. Actor-malli korostaa "moniprosessista asynkronista laskentaa", jossa jokainen agentti toimii itsenäisesti, ylläpitää tilaa itsenäisesti ja on vuorovaikutuksessa viestivetoisella tavalla. Sirpalointi puolestaan on "valtion ja konsensuksen horisontaalinen sirpalointi" -mekanismi, joka jakaa koko lohkoketjun useisiin alijärjestelmiin (sirpaleihin), jotka käsittelevät transaktioita itsenäisesti. Toimijamallit ovat enemmän kuin "hajautetun agentin käyttöjärjestelmä" Web3-maailmassa, kun taas sirpalointi on rakenteellinen skaalausratkaisu ketjun sisäisille tapahtumien käsittelyominaisuuksille. Molemmat saavuttavat rinnakkaisuuden, mutta niillä on erilaiset lähtökohdat, tavoitteet ja suoritusarkkitehtuurit.

  4.1 AO (Arweave), superrinnakkainen tietokone tallennuskerroksen päälläAO

  on hajautettu laskenta-alusta, joka toimii pysyvällä Arweave-tallennuskerroksella ja jonka ydintavoitteena on rakentaa ketjussa oleva käyttöjärjestelmä, joka tukee suuren mittakaavan asynkronisten agenttien toimintaa.

  Arkkitehtuurin ydinominaisuudet:

  • Prosessiarkkitehtuuri: Kutakin agenttia kutsutaan prosessiksi, jolla on itsenäinen tila, itsenäinen ajastin ja suorituslogiikka;
  • Ei lohkoketjurakennetta: AO ei ole ketju, vaan hajautettu tallennuskerros + Arweaveen perustuva moniagenttiviestipohjainen suoritusmoottori;
  • Asynkroninen viestien ajoitusjärjestelmä: Prosessit kommunikoivat keskenään viestien kautta, ottavat käyttöön lukitun asynkronisen toimintamallin ja tukevat luonnollisesti samanaikaista laajentamista.
  • Pysyvä tilatallennus: Kaikki agentin tilat, viestitietueet ja ohjeet tallennetaan pysyvästi Arweaveen, mikä varmistaa täyden tarkastettavuuden ja hajautetun läpinäkyvyyden.
  • Agent-natiivi: Se soveltuu monimutkaisten monivaiheisten tehtävien (kuten tekoälyagenttien, DePIN-protokollaohjaimien, automaattisten tehtävien orkestrointilaitteiden jne.) käyttöönottoon, ja se voi rakentaa "ketjussa olevan AI-yhteisprosessorin".

  AO valitsee perimmäisen reitin "agentin natiivi + tallennusohjain + ketjuton arkkitehtuuri", korostaen joustavuutta ja moduulien irtikytkentää, ja se on "tallennuskerroksen päälle rakennetun ketjun mikroydinkehys", jossa järjestelmän raja kutistuu tarkoituksella, korostaen kevyttä laskentaa + koottavaa ohjausrakennetta.

  4.2 ICP (Internet Computer), täyden pinon Web3-isännöintialustaICP

  on DFINITY:n lanseeraama Web3-natiivi full-stack on-chain -sovellusalusta, jonka tavoitteena on laajentaa ketjun sisäistä laskentatehoa Web2:n kaltaisiin kokemuksiin ja tukea täydellisen palvelun isännöintiä, verkkotunnusten sidontaa ja palvelimetonta arkkitehtuuria.

  Arkkitehtuurin ydinominaisuudet:

  • Canister-arkkitehtuuri (kontit agentteina): Jokainen kanisteri on agentti, joka toimii Wasm VM:ssä, jolla on itsenäiset tila-, koodi- ja asynkroniset ajoitusominaisuudet;
  • Aliverkon hajautettu konsensusjärjestelmä (aliverkko): Koko verkko koostuu useista aliverkoista, joista jokainen ylläpitää joukkoa kapseleita ja saavuttaa konsensuksen BLS-allekirjoitusmekanismin kautta.
  • Asynkroninen kutsumalli: Canister kommunikoi Canisterin kanssa asynkronisten viestien kautta, tukee estämätöntä suoritusta ja sillä on luonnollinen rinnakkaisuus.
  • Ketjun sisäinen web-hosting: Se tukee älykkäitä sopimuksia käyttöliittymäsivujen suoraan isännöimiseen, alkuperäistä DNS-kartoitusta ja on ensimmäinen lohkoketjualusta, joka tukee selaimia suoraan dAppien käyttöön;
  • Järjestelmässä on täydelliset toiminnot: Siinä on järjestelmän sovellusliittymät, kuten ketjun sisäinen kuumapäivitys, identiteetin todennus, hajautettu satunnaisuus ja ajastin, joka soveltuu monimutkaiseen ketjun sisäiseen palvelun käyttöönottoon.

  ICP valitsee käyttöjärjestelmäparadigman, joka koostuu raskaasta alustasta, integroidusta paketoinnista ja vahvasta alustan hallinnasta, ja sillä on "lohkoketjukäyttöjärjestelmä", joka integroi konsensuksen, toteutuksen, tallennuksen ja pääsyn, korostaa täydellisiä palvelun isännöintiominaisuuksia ja laajentaa järjestelmän rajaa täyden pinon Web3-isännöintialustaksi.

  Lisäksi muiden Actor Model -paradigmojen rinnakkaislaskentaprojektit voidaan viitata seuraavaan taulukkoon:

  

  5. Yhteenveto ja näkymätVirtuaalikoneen

  arkkitehtuurin ja kielijärjestelmän erojen perusteella lohkoketjun rinnakkaislaskentaratkaisut voidaan jakaa karkeasti kahteen luokkaan: EVM-rinnakkaisparannusketju ja natiivi rinnakkaisarkkitehtuuriketju (ei-EVM).

  EVM/Solidity-ekosysteemin yhteensopivuuden säilyttämisen perusteella edellinen saavuttaa suuremman suorituskyvyn ja rinnakkaiskäsittelykyvyn suorituskerroksen perusteellisen optimoinnin avulla, mikä sopii skenaarioihin, jotka haluavat periä Ethereumin omaisuutta ja kehitystyökaluja ja saavuttaa samanaikaisesti suorituskyvyn läpimurtoja. Edustavia projekteja ovat:

  • Monad: Toteuttaa EVM:n kanssa yhteensopivan optimistisen rinnakkaissuoritusmallin lykätyn kirjoitus- ja ajonaikaisen ristiriitojen havaitsemisen avulla, rakentaa riippuvuuskaavioita ja ajoittaa toteutuksen konsensuksen saavuttamisen jälkeen.
  • MegaETH: Abstraktoi jokaisen tilin/sopimuksen itsenäiseksi mikro-VM:ksi ja toteuttaa erittäin irrallisen tilitason rinnakkaisaikataulutuksen, joka perustuu asynkroniseen viestintään ja tilakohtaisiin kaavioihin.
  • Pharos: Rakenna rollup-verkkoarkkitehtuuri, jolla saavutetaan järjestelmätason rinnakkainen käsittely prosessien välillä asynkronisten putkien ja SPN-moduulien avulla.
  • Reddio: Käyttää zkRollup + GPU -arkkitehtuuria nopeuttaakseen zkEVM:n ketjun ulkopuolista varmennusprosessia SNARK-erän luomisen kautta ja parantaakseen vahvistusta.

  Jälkimmäinen poistaa kokonaan Ethereumin yhteensopivuuden rajoitukset ja suunnittelee suoritusparadigman uudelleen virtuaalikoneesta, tilamallista ja ajoitusmekanismista saavuttaakseen alkuperäisen korkean suorituskyvyn samanaikaisuuden. Tyypillisiä alaluokkia ovat:

  • Solana (SVM): tilitason rinnakkaissuoritusmalli, joka perustuu tilin käyttöoikeusvaatimuksiin ja staattiseen ristiriitakaavion ajoitukseen;
  • Sui / Aptos (MoveVM-järjestelmä): Resurssiobjektimalliin ja tyyppijärjestelmään perustuva se tukee staattista analyysiä käännöshetkellä ja toteuttaa objektitason rinnakkaisuuden.
  • Sei V2 (Cosmos SDK -reitti): esittelee Cosmos-arkkitehtuurissa monisäikeisen vastaavuusmoduulin ja virtuaalikoneen samanaikaisuuden optimoinnin, joka soveltuu transaktiopohjaisiin korkean taajuuden sovelluksiin.
  • Polttoaine (UTXO + Sway -arkkitehtuuri): Tapahtumatason rinnakkaisuus UTXO-syötejoukon staattisen analyysin avulla yhdistämällä modulaarisen suorituskerroksen räätälöityyn älysopimuskieleen Sway;

  Lisäksi yleisempänä rinnakkaisjärjestelmänä Actor-malli rakentaa ketjun sisäisen suoritusparadigman "usean agentin riippumaton toiminta + viestipohjainen yhteistyö" Wasmiin tai mukautettuihin virtuaalikoneihin perustuvan asynkronisen prosessien ajoitusmekanismin avulla. Edustavia projekteja ovat:

  • AO (Arweave AO): Ketjun sisäisen asynkronisen mikroydinjärjestelmän rakentaminen, joka perustuu pysyvään tallennustilapohjaiseen agentin ajoon;
  • ICP (Internet Computer): käyttää konttiagenttia (Canister) pienimpänä yksikkönä asynkronisen ja erittäin skaalautuvan suorituksen saavuttamiseksi aliverkon koordinoinnin avulla.
  • Cartesi: Esittelee Linux-käyttöjärjestelmän ketjun ulkopuolisena laskentaympäristönä, joka tarjoaa ketjun sisäisen varmennuspoluun luotettaville laskentatuloksille, jotka soveltuvat monimutkaisiin tai resursseja vaativiin sovellusskenaarioihin.

  Yllä olevan logiikan perusteella voimme tiivistää nykyisen valtavirran rinnakkaislaskennan julkisen ketjun järjestelmän luokittelurakenteeksi, kuten seuraavassa kuvassa näkyy:

  

  Laajemmasta skaalausnäkökulmasta sirpalointi ja rollup (L2) keskittyvät horisontaaliseen skaalaukseen tilan sirpaloinnin tai ketjun ulkopuolisen suorituksen avulla, kun taas rinnakkaiset laskentaketjut (esim. Monad, Sui, Solana) ja toimijalähtöiset järjestelmät (esim. AO, ICP) rekonstruoivat suoritusmallin suoraan ja saavuttavat alkuperäisen rinnakkaisuuden ketjussa tai järjestelmäkerroksessa. Edellinen parantaa ketjun sisäistä suorituskykyä monisäikeisten virtuaalikoneiden, objektimallien, transaktiokonfliktianalyysin jne. Jälkimmäinen ottaa prosessin/agentin perusyksiköksi ja ottaa käyttöön viestipohjaiset ja asynkroniset suoritustilat usean agentin samanaikaisen toiminnan saavuttamiseksi. Sitä vastoin sirpalointi ja rollupit ovat enemmän kuin "kuorman jakamista useille ketjuille" tai "ulkoistamista ketjun ulkopuolelle", kun taas rinnakkaisketju- ja toimijamalli "vapauttaa suorituskykypotentiaalin itse suoritusmoottorista", mikä heijastaa perusteellisempaa arkkitehtuurin kehitystä.

  Rinnakkaislaskenta vs Sharding Architecture vs Rollup Scaling vs Actor Oriented Scaling Path -vertailu

  

  On syytä huomauttaa, että suurin osa alkuperäisistä rinnakkaisarkkitehtuuriketjuista on siirtynyt pääverkon käynnistysvaiheeseen, vaikka yleistä kehittäjäekosysteemiä on edelleen vaikea verrata EVM-järjestelmän Solidity-järjestelmään, mutta Solanan ja Suin edustamista projekteista on tullut korkean suorituskyvyn toteutusarkkitehtuurinsa ja ekologisten sovellusten asteittaisen vaurauden ansiosta keskeisiä julkisia ketjuja, joihin markkinat kiinnittävät suurta huomiota.

  Sitä vastoin, vaikka Ethereum Rollup (L2) -ekosysteemi on siirtynyt "10 000 ketjua kerralla" tai jopa "ylikapasiteetin" vaiheeseen, nykyinen valtavirran EVM-rinnakkaisparannusketju on yleensä edelleen testiverkkovaiheessa, eikä varsinainen pääverkkoympäristö ole vielä vahvistanut sitä, ja sen skaalauskykyä ja järjestelmän vakautta on vielä testattava edelleen. Nähtäväksi jää, voivatko nämä projektit parantaa merkittävästi EVM:n suorituskykyä ja ajaa ekologisia harppauksia yhteensopivuudesta tinkimättä, vai voivatko ne erottaa Ethereumin likviditeetti- ja kehitysresurssit entisestään.