AO hinta

$AO on kuin $ICP ilman pääomasijoittajia 39-kertaisella arvostuserolla. Teimme siitä pitkän raportin viime kuussa @dyorcryptoapp.

Tekijät: 0xjacobzhao ja ChatGPT 4o Lohkoketjun "Blockchain Trilemman" "turvallisuus", "hajauttaminen" ja "skaalautuvuus" paljastavat 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: Suoritukseen tehostettu skaalaus: parantaa suoritusominaisuuksia, kuten rinnakkaisuutta, grafiikkasuoritinta ja moniytimistä in situ Tilaeristetty skaalaus: Jakaa vaakasuunnassa tilan/sirpaleet, kuten sirpaleet, UTXO:t ja useat aliverkot Ketjun ulkoisen ulkoistamisen skaalaus: Suorituksen siirtäminen ketjun ulkopuolelle, kuten koonti, apuprosessorit ja DA:t Rakenteellinen irtikytkentäkapasiteetin laajennus: Arkkitehtuuri on modulaarinen ja toimii yhdessä, kuten moduuliketjut, jaetut sekvensserit ja rollup-verkot Asynkroninen samanaikainen skaalaus: Toimijamalli, prosessien eristys, viestipohjainen, kuten agentit ja monisäikeiset asynkroniset ketjut 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 Solana-projektia Objektitason rinnakkaisuus: Edustaa Sui-projektia Tapahtumataso: Edustaa projektia Monad, Aptos Call-level / MicroVM: Edustaa MegaETH-projektia Opetustaso: Edustaa GatlingX-projektia 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 Parallel Enhancement Chain: Yhteensopivuuden suorituskyvyn rajan rikkominen 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 rinnakkainen laskennallinen mekanismianalyysi Monad on korkean suorituskyvyn Layer 1 -lohkoketju, joka on suunniteltu uudelleen Ethereum Virtual Machinelle (EVM) ja joka perustuu pipelineingin rinnakkaiskonseptiin, jossa on asynkroninen toteutus konsensuskerroksessa ja optimistinen rinnakkaissuoritus suorituskerroksessa. 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: rinnakkaissuoritusmekanismi monivaiheisille putkille 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 ja lopulta suorituskyvyn parantamiseksi ja latenssin vähentämiseksi. Näitä vaiheita ovat: Ehdotus, konsensus, toteutus ja sitoutuminen. Asynkroninen suoritus: Konsensus - Suorittaa asynkronisen irtikytkennän Perinteisissä ketjuissa transaktioiden konsensus ja toteutus ovat tyypillisesti synkronisia prosesseja, ja tämä sarjamalli rajoittaa merkittävästi suorituskyvyn skaalaamista. 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. Ytimen suunnittelu: Konsensusprosessi (konsensuskerros) vastaa vain transaktioiden tilaamisesta, eikä se 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 rinnakkaistoteutus Perinteinen 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. Täytäntöönpanomekanismi: Monadi suorittaa optimistisesti kaikki transaktiot rinnakkain olettaen, että useimpien välillä ei ole tilallisia ristiriitoja. 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 rinnakkaislaskennallinen analyysi Monadin L1-paikannuksesta poiketen 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. Asynkroniset suoritus- ja takaisinsoittomekanismit MegaETH on rakennettu asynkronisen ohjelmointiparadigman päälle, samanlainen kuin Actor Modelin asynkroninen viestintä, joka ratkaisee 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ä. Sekä Monadin että MegaETH:n suunnittelukonseptit eroavat melko paljon sirpaloinnista: sirpalointi jakaa lohkoketjun vaakasuunnassa useisiin itsenäisiin aliketjuihin (sirpaleihin), ja jokainen aliketju vastaa osasta transaktioita ja tiloja, rikkoen yhden ketjun rajan ja skaalautuen 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 -rinnakkaislaskennan analyysi: Koko elinkaaren asynkroninen pipelining: Pharos irrottaa transaktion eri vaiheet (esim. konsensus, suoritus, tallennus) ja ottaa käyttöön asynkronisen käsittelyn, jotta jokainen vaihe voidaan suorittaa itsenäisesti ja rinnakkain, mikä parantaa käsittelyn yleistä tehokkuutta. 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. 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ä. 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 GPU:n rinnakkaissuoritusarkkitehtuuriin, ja sen ydin on EVM:n suoritusprosessin refaktorointi suorituskerroksen alkuperäisen rinnakkaistuksen saavuttamiseksi 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. Tällä hetkellä SDK on lanseerattu, ja integroitu suoritusmoduuli tarjotaan GatlingX kutsuu itseään "GPU-EVM:ksi" ja ehdottaa radikaalimpaa arkkitehtuuria, joka yrittää siirtää perinteisten EVM-virtuaalikoneiden "käskytason sarjasuoritusmallin" GPU-natiiveihin rinnakkaiskäyttöympäristöihin. 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. Alkuperäinen rinnakkaisarkkitehtuuriketju: Rekonstruoi virtuaalikoneiden suoritusontologia Ethereumin EVM-suoritusmalli on suunnittelunsa alusta lähtien ottanut käyttöön yksisäikeisen arkkitehtuurin "täysi transaktiojärjestys + sarjasuoritus", jonka tavoitteena 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 alimmasta kerroksesta, ja niillä on seuraavat edut: Tilamallien luonnollinen erottaminen: Solana käyttää tilin lukituksen ilmoitusmekanismia, MoveVM esittelee objektin omistajuusmallin ja Sei v2 toteuttaa tapahtumatyypin luokitteluun perustuvan staattisen ristiriitatuomion ja tukee tapahtumatason samanaikaista ajoitusta. 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. Ydinmekaniikka: 1. Eksplisiittiset tilien käyttöoikeusluettelot: Jokaisen tapahtuman on ilmoitettava mukana oleva tili (luku/kirjoitus) lähetettäessä, jotta järjestelmä voi määrittää, onko tapahtumien välillä tilaristiriita. 2. Ristiriitojen havaitseminen ja monisäikeinen ajoitus Jos näiden kahden tapahtuman käyttämät tilijoukot eivät ole päällekkäisiä→ ne voidaan suorittaa rinnakkain. On ristiriita→ joka 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, mikä korostaa käsitettä "resurssit ovat objekteja", ja kaikki ketjun sisäiset 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 olion omistajuusmalli Suin rinnakkaislaskentaominaisuudet johtuvat 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-täytäntöönpanomekanismi Aptos 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 transaktioiden suorittamisen lohkossa kolmeen vaiheeseen: Spekulatiivinen suoritus: Kaikki tapahtumat ovat oletusarvoisesti ristiriidattomia ennen suorittamista, ja järjestelmä ajoittaa tapahtumat useisiin säikeisiin samanaikaisia suoritusyrityksiä varten ja tallentaa niiden käyttämän tilin tilan (lukujoukko/kirjoitusjoukko). 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öörien aikataulutuskoulu, enemmän kuin "käyttöjärjestelmän ydin", joka soveltuu selkeisiin osavaltioiden rajoihin, hallittavaan korkeataajuiseen kaupankäyntiin ja on laitteistoinsinöörityylinen, jonka pitäisi pyörittää ketjua laitteiston tavoin (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:n rinnakkaislaajennus Sei V2 on korkean suorituskyvyn transaktioketju, joka on rakennettu Cosmos SDK:n pohjalta, ja sen rinnakkaisuuskyky heijastuu pääasiassa kahteen näkökohtaan: monisäikeiseen sovitusmoottoriin (Parallel Matching Engine) ja virtuaalikonekerroksen rinnakkaissuorituksen optimointiin, jonka tavoitteena on palvella korkeataajuisia ja matalan latenssin ketjun sisäisiä transaktioskenaarioita, kuten tilauskirjan DEX:iä, ketjun sisäistä vaihtoinfrastruktuuria jne. Ytimen rinnakkaismekanismi: Rinnakkainen täsmäytysmoottori: 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älisiä täsmäytystehtäviä voidaan käsitellä rinnakkain ja välttää yksisäikeisiä pullonkauloja. 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. 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-mallin reformerin polttoaine Fuel on korkean suorituskyvyn suorituskerros, joka on suunniteltu Ethereumin modulaarisen arkkitehtuurin pohjalta, ja sen ydinrinnakkaisuus 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: Uusi paradigma agenttien samanaikaiseen suorittamiseen 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 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 Arweaven pysyvällä tallennuskerroksella ja jonka ydintavoitteena on rakentaa ketjun sisäinen käyttöjärjestelmä, joka tukee laajamittaista asynkronista agenttitoimintaa. Arkkitehtuurin ydinominaisuudet: Prosessiarkkitehtuuri: Kutakin agenttia kutsutaan prosessiksi, jolla on itsenäinen tila, itsenäinen ajoitus 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öintialusta ICP on DFINITY:n lanseeraama Web3-natiivi täyden pinon sisäinen sovellusalusta, jonka tavoitteena on laajentaa ketjun sisäistä laskentatehoa Web2:n kaltaisiin kokemuksiin ja tukea täydellistä palvelun isännöintiä, verkkotunnusten sidontaa ja palvelimetonta arkkitehtuuria. Arkkitehtuurin ydinominaisuudet: Kanisteriarkkitehtuuri (säilöt agentteina): Jokainen kanisteri on agentti, joka toimii Wasm-virtuaalikoneella, jolla on itsenäinen 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 rinnakkaiset laskentaprojektit muille toimijamalliparadigmoille löytyvät seuraavasta taulukosta: 5. Yhteenveto ja näkymät Virtuaalikoneen 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: Ota käyttöön optimistinen rinnakkaissuoritusmalli, joka on yhteensopiva EVM:n kanssa lykätyn kirjoituksen ja suorituksenaikaisen ristiriidan tunnistuksen avulla, luo riippuvuuskaavioita konsensuksen saavuttamisen jälkeen ja ajoita suoritus useissa säikeissä. 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): Tilin käyttövaatimuksiin ja staattiseen ristiriitakaavion ajoitukseen perustuva se edustaa tilitason rinnakkaissuoritusmallia. 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): rakentaa ketjussa olevan asynkronisen mikroydinjärjestelmän, joka perustuu pysyvään tallennuspohjaiseen 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.

Kirjoittaneet 0xjacobzhao ja ChatGPT 4o Lohkoketjun "Blockchain Trilemman" "turvallisuus", "hajauttaminen" ja "skaalautuvuus" paljastavat 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: Suoritukseen tehostettu skaalaus: parantaa suoritusominaisuuksia, kuten rinnakkaisuutta, grafiikkasuoritinta ja moniytimistä in situ Tilaeristetty skaalaus: Jakaa vaakasuunnassa tilan/sirpaleet, kuten sirpaleet, UTXO:t ja useat aliverkot Ketjun ulkoisen ulkoistamisen skaalaus: Suorituksen siirtäminen ketjun ulkopuolelle, kuten koonti, apuprosessorit ja DA:t Rakenteellinen irtikytkentäkapasiteetin laajennus: Arkkitehtuuri on modulaarinen ja toimii yhdessä, kuten moduuliketjut, jaetut sekvensserit ja rollup-verkot Asynkroninen samanaikainen skaalaus: Toimijamalli, prosessien eristys, viestipohjainen, kuten agentit ja monisäikeiset asynkroniset ketjut 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 Solana-projektia Objektitason rinnakkaisuus: Edustaa Sui-projektia Tapahtumataso: Edustaa projektia Monad, Aptos Call-level / MicroVM: Edustaa MegaETH-projektia Opetustaso: Edustaa GatlingX-projektia 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 Parallel Enhancement Chain: Yhteensopivuuden suorituskyvyn rajan rikkominen 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 rinnakkainen laskennallinen mekanismianalyysi Monad on korkean suorituskyvyn Layer 1 -lohkoketju, joka on suunniteltu uudelleen Ethereum Virtual Machinelle (EVM) ja joka perustuu pipelineingin rinnakkaiskonseptiin, jossa on asynkroninen toteutus konsensuskerroksessa ja optimistinen rinnakkaissuoritus suorituskerroksessa. 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: rinnakkaissuoritusmekanismi monivaiheisille putkille 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 ja lopulta suorituskyvyn parantamiseksi ja latenssin vähentämiseksi. Näitä vaiheita ovat: Ehdotus, konsensus, toteutus ja sitoutuminen. Asynkroninen suoritus: Konsensus - Suorittaa asynkronisen irtikytkennän Perinteisissä ketjuissa transaktioiden konsensus ja toteutus ovat tyypillisesti synkronisia prosesseja, ja tämä sarjamalli rajoittaa merkittävästi suorituskyvyn skaalaamista. 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. Ytimen suunnittelu: Konsensusprosessi (konsensuskerros) vastaa vain transaktioiden tilaamisesta, eikä se 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 rinnakkaistoteutus Perinteinen 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. Täytäntöönpanomekanismi: Monadi suorittaa optimistisesti kaikki transaktiot rinnakkain olettaen, että useimpien välillä ei ole tilallisia ristiriitoja. 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 rinnakkaislaskennallinen analyysi Monadin L1-paikannuksesta poiketen 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. Asynkroniset suoritus- ja takaisinsoittomekanismit MegaETH on rakennettu asynkronisen ohjelmointiparadigman päälle, samanlainen kuin Actor Modelin asynkroninen viestintä, joka ratkaisee 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ä. Sekä Monadin että MegaETH:n suunnittelukonseptit eroavat melko paljon sirpaloinnista: sirpalointi jakaa lohkoketjun vaakasuunnassa useisiin itsenäisiin aliketjuihin (sirpaleihin), ja jokainen aliketju vastaa osasta transaktioita ja tiloja, rikkoen yhden ketjun rajan ja skaalautuen 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 -rinnakkaislaskennan analyysi: Koko elinkaaren asynkroninen pipelining: Pharos irrottaa transaktion eri vaiheet (esim. konsensus, suoritus, tallennus) ja ottaa käyttöön asynkronisen käsittelyn, jotta jokainen vaihe voidaan suorittaa itsenäisesti ja rinnakkain, mikä parantaa käsittelyn yleistä tehokkuutta. 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. 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ä. 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 GPU:n rinnakkaissuoritusarkkitehtuuriin, ja sen ydin on EVM:n suoritusprosessin refaktorointi suorituskerroksen alkuperäisen rinnakkaistuksen saavuttamiseksi 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. Tällä hetkellä SDK on lanseerattu, ja integroitu suoritusmoduuli tarjotaan GatlingX kutsuu itseään "GPU-EVM:ksi" ja ehdottaa radikaalimpaa arkkitehtuuria, joka yrittää siirtää perinteisten EVM-virtuaalikoneiden "käskytason sarjasuoritusmallin" GPU-natiiveihin rinnakkaiskäyttöympäristöihin. 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. Alkuperäinen rinnakkaisarkkitehtuuriketju: Rekonstruoi virtuaalikoneiden suoritusontologia Ethereumin EVM-suoritusmalli on suunnittelunsa alusta lähtien ottanut käyttöön yksisäikeisen arkkitehtuurin "täysi transaktiojärjestys + sarjasuoritus", jonka tavoitteena 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 alimmasta kerroksesta, ja niillä on seuraavat edut: Tilamallien luonnollinen erottaminen: Solana käyttää tilin lukituksen ilmoitusmekanismia, MoveVM esittelee objektin omistajuusmallin ja Sei v2 toteuttaa tapahtumatyypin luokitteluun perustuvan staattisen ristiriitatuomion ja tukee tapahtumatason samanaikaista ajoitusta. 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. Ydinmekaniikka: 1. Eksplisiittiset tilien käyttöoikeusluettelot: Jokaisen tapahtuman on ilmoitettava mukana oleva tili (luku/kirjoitus) lähetettäessä, jotta järjestelmä voi määrittää, onko tapahtumien välillä tilaristiriita. 2. Ristiriitojen havaitseminen ja monisäikeinen ajoitus Jos näiden kahden tapahtuman käyttämät tilijoukot eivät ole päällekkäisiä→ ne voidaan suorittaa rinnakkain. On ristiriita→ joka 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, mikä korostaa käsitettä "resurssit ovat objekteja", ja kaikki ketjun sisäiset 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 olion omistajuusmalli Suin rinnakkaislaskentaominaisuudet johtuvat 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-täytäntöönpanomekanismi Aptos 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 transaktioiden suorittamisen lohkossa kolmeen vaiheeseen: Spekulatiivinen suoritus: Kaikki tapahtumat ovat oletusarvoisesti ristiriidattomia ennen suorittamista, ja järjestelmä ajoittaa tapahtumat useisiin säikeisiin samanaikaisia suoritusyrityksiä varten ja tallentaa niiden käyttämän tilin tilan (lukujoukko/kirjoitusjoukko). 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öörien aikataulutuskoulu, enemmän kuin "käyttöjärjestelmän ydin", joka soveltuu selkeisiin osavaltioiden rajoihin, hallittavaan korkeataajuiseen kaupankäyntiin ja on laitteistoinsinöörityylinen, jonka pitäisi pyörittää ketjua laitteiston tavoin (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:n rinnakkaislaajennus Sei V2 on korkean suorituskyvyn transaktioketju, joka on rakennettu Cosmos SDK:n pohjalta, ja sen rinnakkaisuuskyky heijastuu pääasiassa kahteen näkökohtaan: monisäikeiseen sovitusmoottoriin (Parallel Matching Engine) ja virtuaalikonekerroksen rinnakkaissuorituksen optimointiin, jonka tavoitteena on palvella korkeataajuisia ja matalan latenssin ketjun sisäisiä transaktioskenaarioita, kuten tilauskirjan DEX:iä, ketjun sisäistä vaihtoinfrastruktuuria jne. Ytimen rinnakkaismekanismi: Rinnakkainen täsmäytysmoottori: 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älisiä täsmäytystehtäviä voidaan käsitellä rinnakkain ja välttää yksisäikeisiä pullonkauloja. 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. 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-mallin reformerin polttoaine Fuel on korkean suorituskyvyn suorituskerros, joka on suunniteltu Ethereumin modulaarisen arkkitehtuurin pohjalta, ja sen ydinrinnakkaisuus 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: Uusi paradigma agenttien samanaikaiseen suorittamiseen 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 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 Arweaven pysyvällä tallennuskerroksella ja jonka ydintavoitteena on rakentaa ketjun sisäinen käyttöjärjestelmä, joka tukee laajamittaista asynkronista agenttitoimintaa. Arkkitehtuurin ydinominaisuudet: Prosessiarkkitehtuuri: Kutakin agenttia kutsutaan prosessiksi, jolla on itsenäinen tila, itsenäinen ajoitus 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öintialusta ICP on DFINITY:n lanseeraama Web3-natiivi täyden pinon sisäinen sovellusalusta, jonka tavoitteena on laajentaa ketjun sisäistä laskentatehoa Web2:n kaltaisiin kokemuksiin ja tukea täydellistä palvelun isännöintiä, verkkotunnusten sidontaa ja palvelimetonta arkkitehtuuria. Arkkitehtuurin ydinominaisuudet: Kanisteriarkkitehtuuri (säilöt agentteina): Jokainen kanisteri on agentti, joka toimii Wasm-virtuaalikoneella, jolla on itsenäinen 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 rinnakkaiset laskentaprojektit muille toimijamalliparadigmoille löytyvät seuraavasta taulukosta: 5. Yhteenveto ja näkymät Virtuaalikoneen 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: Ota käyttöön optimistinen rinnakkaissuoritusmalli, joka on yhteensopiva EVM:n kanssa lykätyn kirjoituksen ja suorituksenaikaisen ristiriidan tunnistuksen avulla, luo riippuvuuskaavioita konsensuksen saavuttamisen jälkeen ja ajoita suoritus useissa säikeissä. 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): Tilin käyttövaatimuksiin ja staattiseen ristiriitakaavion ajoitukseen perustuva se edustaa tilitason rinnakkaissuoritusmallia. 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): rakentaa ketjussa olevan asynkronisen mikroydinjärjestelmän, joka perustuu pysyvään tallennuspohjaiseen 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.

Rakastan nähdä permabiittien yhteisön tapaamisten kasvavan!

The Daily Degen - perjantai 18. huhtikuuta 2025 Trendit, pegit, TGE:t, tekniikka, makro, videot, + uudet projektit! Huuto mainituille projekteille ja tickereille: $DOLO, $ATOM, $sUSD, $BTC, $OL, $WZRD, $AERGO, $T, $EVER, $AO, @GammaSwapLabs, @TradeNeutral, @Lighter_xyz, @jigsawdefi, @PeerlessAI, @VertigoDex, @clickerxyz, @getoro_xyz Ja huuda gigabrain-tileille, joilla on >10 tuhatta seuraajaa (muista seurata heitä!): @leviathan_news, @robbiepetersen_, @0xlykt, @AresLabs_xyz, @CryptoISFreedom Ja ole hyvä RT/etc tukeaksesi! Linkki seuraavassa twiitissä 👇