Preț AO

$AO este ca $ICP fără VC la un decalaj de evaluare de 39 de ori. Am făcut un raport lung luna trecută la @dyorcryptoapp.

Autori: 0xjacobzhao și ChatGPT 4o "Securitatea", "descentralizarea" și "scalabilitatea" blockchain-ului "Blockchain Trilemma" dezvăluie compromisul esențial în proiectarea sistemelor blockchain, adică este dificil pentru proiectele blockchain să obțină "securitate extremă, toată lumea poate participa și procesare de mare viteză" în același timp. Ca răspuns la eternul subiect al "scalabilității", soluțiile de scalare blockchain de pe piață sunt împărțite în funcție de paradigme, inclusiv: Scalare îmbunătățită de execuție: îmbunătățește capacitățile de execuție, cum ar fi paralelismul, GPU și multi-core, in situ Scalare izolată de stare: Împarte orizontal starea/fragmentele, cum ar fi fragmente, UTXO și mai multe subrețele Scalarea externalizării în afara lanțului: Punerea execuției în afara lanțului, cum ar fi rollup-uri, coprocesoare și DA Extinderea capacității de decuplare structurală: Arhitectura este modulară și funcționează împreună, cum ar fi lanțuri de module, secvențiere partajate și ochiuri de rollup Scalare concurentă asincronă: model de actor, izolare de proces, bazată pe mesaje, cum ar fi agenți și lanțuri asincrone cu mai multe fire de execuție Soluția de scalare blockchain include: calcul paralel on-chain, rollup, sharding, modul DA, structură modulară, sistem actor, compresie zk proof, arhitectură stateless etc., acoperind mai multe niveluri de execuție, stare, date și structură și este un sistem complet de scalare de "colaborare multi-strat și combinație de module". Acest articol se concentrează pe metodele de scalare care integrează calculul paralel. Paralelismul intra-lanț, care se concentrează pe executarea paralelă a tranzacțiilor/instrucțiunilor intra-bloc. Conform mecanismului paralel, metodele sale de scalare pot fi împărțite în cinci categorii, fiecare dintre ele reprezentând o căutare diferită de performanță, model de dezvoltare și filozofie de arhitectură, iar granularitatea paralelă devine din ce în ce mai fină, intensitatea paralelismului devine din ce în ce mai mare, complexitatea programării devine din ce în ce mai mare, iar complexitatea programării și dificultatea de implementare devin din ce în ce mai mari. La nivel de cont: Reprezintă proiectul Solana Paralelism la nivel de obiect: Reprezintă proiectul Sui La nivel de tranzacție: Reprezintă proiectul Monad, Aptos Call-level / MicroVM: Reprezintă proiectul MegaETH Nivel de instruire: Reprezintă proiectul GatlingX Modelul de concurență asincronă off-chain, reprezentat de Modelul Actor/Actor, aparține unei alte paradigme de calcul paralel, ca sistem de mesaje cross-chain/asincron (model de sincronizare non-block), fiecare agent rulează independent ca "proces agent", mesaje asincrone în mod paralel, event-driven, fără programare sincronă, proiecte reprezentative precum AO, ICP, Cartesi etc. Binecunoscuta schemă de scalare a cumulului sau a fragmentelor aparține mecanismului de concurență la nivel de sistem, nu calculului paralel intra-lanț. Acestea obțin scalarea prin "rularea mai multor lanțuri/domenii de execuție în paralel", mai degrabă decât creșterea paralelismului într-un singur bloc/mașină virtuală. Acest tip de soluție de scalare nu este punctul central al acestui articol, dar îl vom folosi în continuare pentru a compara asemănările și diferențele dintre conceptele arhitecturale. 2. Lanț de îmbunătățire paralelă EVM: depășirea limitei de performanță în compatibilitate De la dezvoltarea arhitecturii de procesare serială a Ethereum, aceasta a suferit mai multe runde de încercări de scalare, cum ar fi fragmentare, rollup și arhitectură modulară, dar blocajul de debit al stratului de execuție nu a fost încă rupt fundamental. Dar, în același timp, EVM și Solidity sunt în continuare platformele de contracte inteligente cu cea mai mare bază de dezvoltatori și potențial ecologic. Prin urmare, lanțul de îmbunătățire paralelă EVM devine o direcție importantă pentru o nouă rundă de scalare și evoluție ca o cale cheie care ia în considerare compatibilitatea ecologică și îmbunătățirea performanței de execuție. Monad și MegaETH sunt cele mai reprezentative proiecte în această direcție, începând de la execuția amânată și, respectiv, descompunerea stării, pentru a construi o arhitectură de procesare paralelă EVM pentru scenarii de concurență ridicată și de mare randament. Analiza mecanismului de calcul paralel al Monadului Monad este un blockchain de înaltă performanță de nivel 1 reproiectat pentru Ethereum Virtual Machine (EVM), bazat pe conceptul paralel de bază al pipelining, cu execuție asincronă la nivelul de consens și execuție paralelă optimistă la nivelul de execuție. În plus, la nivelurile de consens și stocare, Monad a introdus protocolul BFT de înaltă performanță (MonadBFT) și, respectiv, un sistem de baze de date dedicat (MonadDB) pentru a obține optimizarea end-to-end. Pipelining: un mecanism de execuție paralelă pentru conducte în mai multe etape Pipelining este conceptul de bază al execuției paralele Monad, iar ideea sa de bază este de a împărți procesul de execuție a blockchain-ului în mai multe etape independente și de a procesa aceste etape în paralel pentru a forma o arhitectură de conductă tridimensională, fiecare etapă rulează pe fire sau nuclee independente pentru a realiza procesarea concurentă între blocuri și, în cele din urmă, a obține efectul de îmbunătățire a debitului și de reducere a latenței Aceste etape includ: Propunere, Consens, Execuție și Comitere. Execuție asincronă: Consens - Efectuează decuplarea asincronă Pe lanțurile tradiționale, consensul și execuția tranzacțiilor sunt de obicei procese sincrone, iar acest model serial limitează sever scalarea performanței. Monad implementează stratul de consens asincron, stratul de execuție asincron și stocarea asincronă prin "execuție asincronă". Reduceți semnificativ timpul de blocare și latența de confirmare, făcând sistemul mai rezistent, procesarea mai segmentată și utilizarea resurselor. Design de bază: Procesul de consens (stratul de consens) este responsabil doar pentru ordonarea tranzacțiilor și nu execută logica contractului. Procesul de execuție (stratul de execuție) este declanșat asincron după finalizarea consensului. După finalizarea consensului, acesta va intra imediat în procesul de consens al următorului bloc, fără a aștepta finalizarea execuției. Execuție paralelă optimistă: Execuție paralelă optimistă Ethereum tradițional folosește un model strict serial pentru executarea tranzacțiilor pentru a evita conflictele de stare. Monad, pe de altă parte, adoptă o strategie de "execuție paralelă optimistă" pentru a crește semnificativ viteza de procesare a tranzacțiilor. Mecanismul de aplicare: Monad execută cu optimism toate tranzacțiile în paralel, presupunând că cele mai multe dintre ele nu au conflicte între ele. De asemenea, rulați un "detector de conflicte" pentru a monitoriza dacă aceeași stare (de exemplu, conflicte de citire/scriere) este accesată între tranzacții. Dacă este detectat un conflict, tranzacția conflictuală este serializată și reexecutată pentru a se asigura că starea este corectă. Monad a ales o cale compatibilă: să mute cât mai puține reguli EVM, să obțină paralelismul prin amânarea stării de scriere și detectarea dinamică a conflictelor în timpul execuției, care seamănă mai mult cu o versiune de performanță a Ethereum, cu un nivel de maturitate care facilitează migrarea către ecosistemul EVM și este un accelerator paralel în lumea EVM. Analiza computațională paralelă a MegaETH Spre deosebire de poziționarea L1 a Monad, MegaETH este poziționat ca un strat modular de execuție paralelă de înaltă performanță compatibil cu EVM, care poate fi utilizat ca un lanț public L1 independent, ca un strat de îmbunătățire a execuției sau o componentă modulară pe Ethereum. Scopul său principal de proiectare este de a deconstrui logica contului, mediul de execuție și izolarea stării în cea mai mică unitate care poate fi programată independent pentru a obține o execuție cu concurență ridicată și o capacitate de răspuns cu latență scăzută în cadrul lanțului. Inovația cheie propusă de MegaETH este că arhitectura Micro-VM + State Dependency DAG (graficul de dependență de stare direcționat și aciclic) și mecanismul de sincronizare modulară construiesc împreună un sistem de execuție paralelă pentru "threading intra-lanț". Arhitectura Micro-VM: Conturile sunt fire de execuție MegaETH introduce modelul de execuție "un micro-VM per cont", care "threadează" mediul de execuție și oferă o unitate de izolare minimă pentru programarea paralelă. Aceste mașini virtuale comunică între ele prin mesagerie asincronă în loc de apeluri sincrone, iar un număr mare de mașini virtuale pot fi executate independent, stocate independent și în mod natural în paralel. State Dependency DAG: un mecanism de programare bazat pe grafice MegaETH a construit un sistem de programare DAG bazat pe relația de acces la starea contului, iar sistemul menține un grafic global de dependențe în timp real, iar conturile care sunt modificate și conturile sunt citite pentru fiecare tranzacție sunt toate modelate în dependențe. Tranzacțiile fără conflict pot fi executate direct în paralel, iar tranzacțiile dependente vor fi programate și sortate în serie sau amânate în ordine topologică. Graficele de dependență asigură consecvența stării și scrierile non-duplicate în timpul execuției paralele. Execuție asincronă și mecanisme de apelare inversă MegaETH este construit pe baza paradigmei de programare asincronă, similară cu mesageria asincronă a modelului Actor, care rezolvă problema apelurilor seriale EVM tradiționale. Apelurile contractuale sunt asincrone (execuție non-recursivă), iar atunci când contractul A -> B -> C este apelat, fiecare apel este asincron fără a bloca așteptarea; Stiva de apeluri este extinsă într-un grafic de apeluri asincron; Procesarea tranzacțiilor = traversarea grafului asincron + rezoluția dependențelor + programarea paralelă. Una peste alta, MegaETH sparge modelul tradițional de mașină de stare EVM cu un singur fir, implementează încapsularea mașinilor micro-virtuale cont cu cont, efectuează programarea tranzacțiilor prin grafice dependente de stare și înlocuiește stiva de apeluri sincrone cu un mecanism de mesagerie asincron. Este o platformă de calcul paralel care este reproiectată din dimensiunile complete ale "structurii contului→ arhitecturii de planificare, → procesului de execuție", oferind o nouă idee la nivel de paradigmă pentru construirea unui sistem on-chain de înaltă performanță de ultimă generație. MegaETH a ales calea refactorizării: abstractizează complet conturile și contractele în VM-uri independente și dezlănțuie potențialul suprem de paralelism prin programarea asincronă a execuției. Teoretic, MegaETH are o limită paralelă mai mare, dar este și mai dificil de controlat complexitatea și seamănă mai mult cu un sistem de operare super-distribuit sub conceptul Ethereum. Conceptele de design ale Monad și MegaETH sunt destul de diferite de sharding: sharding-ul împarte orizontal blockchain-ul în mai multe sub-lanțuri independente (fragmente), iar fiecare sub-lanț este responsabil pentru o parte din tranzacții și stări, depășind limita unui singur lanț și scalând la nivelul rețelei; Pe de altă parte, atât Monad, cât și MegaETH mențin integritatea lanțului unic, scalând orizontal doar la nivelul de execuție și efectuând descoperiri de optimizare în paralel la limita lanțului unic. Cele două reprezintă două direcții: consolidarea verticală și expansiunea orizontală pe calea de expansiune a blockchain-ului. Proiectele de calcul paralel, cum ar fi Monad și MegaETH, se concentrează în principal pe calea de optimizare a debitului, cu scopul principal de a îmbunătăți TPS on-chain și de a realiza procesarea paralelă la nivel de tranzacție sau la nivel de cont prin execuție amânată și arhitecturi micro-VM. Pharos Network este o rețea blockchain L1 paralelă modulară, full-stack, iar sistemul său de calcul paralel de bază se numește "Rollup Mesh". Această arhitectură acceptă medii de mașini multi-virtuale (EVM și Wasm) prin sinergia rețelelor principale și a rețelelor speciale de procesare (SPN) și integrează tehnologii avansate, cum ar fi dovezile zero-knowledge (ZK) și mediile de execuție de încredere (TEE). Analiza de calcul paralel Rollup Mesh: Canalizare asincronă a ciclului de viață complet: Pharos decuplează diferitele etape ale unei tranzacții (de exemplu, consens, execuție, stocare) și adoptă procesarea asincronă, astfel încât fiecare etapă să poată fi efectuată independent și în paralel, îmbunătățind astfel eficiența generală a procesării. Execuție paralelă duală VM: Pharos acceptă atât medii de mașini virtuale EVM, cât și WASM, permițând dezvoltatorilor să aleagă mediul de execuție potrivit pentru nevoile lor. Această arhitectură dual-VM nu numai că crește flexibilitatea sistemului, dar crește și procesarea tranzacțiilor prin execuție paralelă. Rețele speciale de procesare (SPN): SPN-urile sunt componente cheie în arhitectura Pharos, similare cu subrețelele modulare concepute pentru a gestiona tipuri specifice de sarcini sau aplicații. Cu SPN-urile, Pharos permite alocarea dinamică a resurselor și procesarea paralelă a sarcinilor, îmbunătățind și mai mult scalabilitatea și performanța sistemului. Consens modular și restaking: Pharos introduce un mecanism de consens flexibil care acceptă mai multe modele de consens (cum ar fi PBFT, PoS, PoA) și permite partajarea sigură și integrarea resurselor între rețeaua principală și SPN-uri prin protocolul de restaking. În plus, Pharos reconstruiește modelul de execuție din stratul inferior al motorului de stocare prin intermediul tehnologiei Merkle tree multi-version, Delta Encoding, Versioned Addressing și ADS Pushdown și lansează Pharos Store, un motor de stocare de înaltă performanță pentru blockchain-ul nativ, pentru a obține un debit ridicat, latență scăzută și capabilități puternice de procesare verificabile în lanț. În general, arhitectura Rollup Mesh de la Pharos atinge capabilități de calcul paralel de înaltă performanță prin design modular și mecanism de procesare asincronă. Pe lângă arhitecturile de execuție paralelă ale Monad, MegaETH și Pharos, observăm și că există unele proiecte pe piață care explorează calea de aplicare a accelerației GPU în calculul paralel EVM, ca un supliment important și un experiment de ultimă oră pentru ecosistemul paralel EVM. Dintre acestea, Reddio și GatlingX sunt două direcții reprezentative: Reddio este o platformă de înaltă performanță care combină zkRollup cu arhitectura de execuție paralelă GPU, iar nucleul său este de a refactoriza procesul de execuție EVM pentru a obține paralelizarea nativă a stratului de execuție prin programare multi-threaded, stocare asincronă a stării și execuție accelerată de GPU a loturilor de tranzacții. Granularitate paralelă la nivel de tranzacție + nivel de operațiune (opcode de execuție multi-threaded). Este conceput pentru a introduce execuția loturilor multi-threaded, încărcarea asincronă a stării și logica de tranzacție de procesare paralelă GPU (EVM paralel compatibil CUDA). La fel ca Monad / MegaETH, Reddio se concentrează și pe procesarea paralelă la nivelul de execuție, diferența fiind că motorul de execuție este reconstruit printr-o arhitectură paralelă GPU, concepută pentru scenarii cu randament ridicat și cu consum intensiv de calcul, cum ar fi inferența AI. În prezent, SDK-ul a fost lansat și este furnizat un modul de execuție integrat Numindu-se "GPU-EVM", GatlingX propune o arhitectură mai radicală care încearcă să migreze modelul de "execuție serială la nivel de instrucțiune" a mașinilor virtuale EVM tradiționale în medii de rulare paralele native GPU. Mecanismul de bază este de a compila dinamic codul de octeți EVM în sarcini paralele CUDA și de a executa fluxul de instrucțiuni prin GPU multi-core, astfel încât să spargă blocajul secvențial al EVM la cel mai mic nivel. Granularitate paralelă care aparține paralelismului la nivel de instrucțiune (ILP). În comparație cu granularitatea paralelă "la nivel de tranzacție/la nivel de cont" a Monad / MegaETH, mecanismul de paralelism al GatlingX aparține căii de optimizare la nivel de instrucțiune, care este mai aproape de refactorizarea de bază a motorului mașinii virtuale. În prezent, se află în faza de concept, cu o carte albă și o schiță arhitecturală publicate și fără SDK sau mainnet încă. Artela propune un concept de design diferențiat, paralel. Odată cu introducerea mașinii virtuale WebAssembly (WASM) cu arhitectură EVM++, dezvoltatorilor li se permite să adauge și să execute dinamic extensii on-chain folosind modelul de programare Aspect, menținând în același timp compatibilitatea EVM. Folosește granularitatea de invocare a contractului (Funcție / Extensie) ca unitate paralelă minimă și acceptă injectarea modulelor de extensie (similar cu "middleware-ul conectabil") atunci când contractul EVM rulează, astfel încât să obțină decuplarea logică, invocarea asincronă și execuția paralelă la nivel de modul. Se acordă mai multă atenție compoziției și arhitecturii modulare a stratului de execuție. Conceptul oferă idei noi pentru aplicații complexe cu mai multe module în viitor. 3. Lanț de arhitectură paralelă nativă: Reconstruiți ontologia de execuție a VM-urilor Modelul de execuție EVM de la Ethereum a adoptat o arhitectură single-threaded de "ordin complet de tranzacție + execuție serială" încă de la începutul proiectării sale, cu scopul de a asigura certitudinea și consecvența schimbărilor de stare pentru toate nodurile din rețea. Cu toate acestea, această arhitectură are un blocaj natural în performanță, limitând debitul și scalabilitatea sistemului. În schimb, lanțurile native de arhitectură de calcul paralel, cum ar fi Solana (SVM), MoveVM (Sui, Aptos) și Sei v2 construite pe Cosmos SDK sunt adaptate pentru execuție paralelă din stratul inferior și au următoarele avantaje: Separarea naturală a modelelor de stare: Solana folosește mecanismul de declarație de blocare a contului, MoveVM introduce modelul de proprietate a obiectului, iar Sei v2 implementează judecata statică a conflictului pe baza clasificării tipului de tranzacție și acceptă programarea concurentă la nivel de tranzacție. Mașinile virtuale sunt optimizate pentru concurență: motorul Sealevel al Solana acceptă în mod nativ execuția multi-threaded; MoveVM poate efectua analiza graficului de concurență statică; Sei v2 integrează un motor de potrivire multi-threaded cu un modul VM paralel. Desigur, acest tip de lanț paralel nativ se confruntă și cu provocarea compatibilității ecologice. Arhitecturile non-EVM necesită de obicei noi limbaje de dezvoltare (cum ar fi Move și Rust) și lanțuri de instrumente, care au anumite costuri de migrare pentru dezvoltatori. În plus, dezvoltatorii trebuie să stăpânească o serie de concepte noi, cum ar fi modele de acces cu stare, limite de concurență, cicluri de viață ale obiectelor etc., care prezintă cerințe mai mari pentru înțelegerea pragurilor și a paradigmelor de dezvoltare. 3.1 Principiul motorului paralel Sealevel al Solana și SVM Modelul de execuție Sealevel al Solana este un mecanism de programare paralelă a contului, care este motorul de bază utilizat de Solana pentru a realiza executarea tranzacțiilor paralele în cadrul lanțului și realizează concurență de înaltă performanță la nivel de contract inteligent prin mecanismul "declarație cont + programare statică + execuție multi-threaded". Sealevel este primul model de execuție din domeniul blockchain care a implementat cu succes programarea concurentă intra-lanț într-un mediu de producție, iar ideile sale arhitecturale au influențat multe proiecte ulterioare de calcul paralel și este o paradigmă de referință pentru proiectarea paralelă de înaltă performanță Layer 1. Mecanica de bază: 1. Liste explicite de acces la cont: Fiecare tranzacție trebuie să declare contul implicat (citire/scriere) la trimitere, astfel încât sistemul să poată determina dacă există un conflict de stare între tranzacții. 2. Detectarea conflictelor și programarea cu mai multe fire de execuție Dacă nu există suprapuneri între seturile de conturi accesate de cele două tranzacții→ acestea pot fi executate în paralel; Există un conflict→ executat în serie în ordine dependentă; Programatorul alocă tranzacții diferitelor fire de execuție pe baza graficului de dependențe. 3. Contextul de invocare a programului: Fiecare apel de contract rulează într-un context izolat, fără o stivă partajată pentru a evita interferențele între apeluri. Sealevel este motorul de programare a execuției paralele al Solana, în timp ce SVM este un mediu de execuție a contractelor inteligente construit pe Sealevel (folosind mașina virtuală BPF). Împreună, acestea formează baza tehnică a sistemului de execuție paralelă de înaltă performanță al Solana. Eclipse este un proiect care implementează VM-uri Solana pe lanțuri modulare, cum ar fi Ethereum L2 sau Celestia, folosind motorul de execuție paralelă al Solana ca strat de execuție rollup. Eclipse este unul dintre primele proiecte care propune detașarea stratului de execuție Solana (Sealevel + SVM) de la rețeaua principală Solana și migrarea acestuia la o arhitectură modulară, iar rezultatul modular al "modelului de execuție super concurent" al Solana este Execution Layer-as-a-Service, astfel încât Eclipse aparține și categoriei de calcul paralel. Traseul Neon este diferit, introduce EVM pentru a funcționa într-un mediu SVM / Sealevel. Construiți un strat de rulare compatibil cu EVM, dezvoltatorii pot folosi Solidity pentru a dezvolta contracte și a rula în mediul SVM, dar execuția de programare folosește SVM + Sealeve. Neon înclină mai mult spre categoria Modular Blockchain decât spre inovația de calcul paralel. Una peste alta, Solana și SVM-urile se bazează pe motorul de execuție Sealevel, iar filozofia de planificare bazată pe sistemul de operare Solana este similară cu planificatorul kernel, care este rapid, dar relativ inflexibil. Este un lanț public nativ de calcul paralel de înaltă performanță. 3.2 Arhitectura MoveVM: bazată pe resurse și obiecte MoveVM este o mașină virtuală cu contract inteligent concepută pentru securitatea resurselor on-chain și execuția paralelă, iar limbajul său de bază, Move, a fost dezvoltat inițial de Meta (fostul Facebook) pentru proiectul Libra, subliniind conceptul de "resursele sunt obiecte" și toate stările on-chain există ca obiecte, cu proprietate și cicluri de viață clare. Acest lucru permite MoveVM să analizeze dacă există conflicte de stare între tranzacții în timpul compilării și să implementeze programarea paralelă statică la nivel de obiect, care este utilizată pe scară largă în lanțurile publice paralele native, cum ar fi Sui și Aptos. Modelul de proprietate a obiectelor lui Sui Capacitățile de calcul paralel ale lui Sui provin din abordarea sa unică a modelării stării și a analizei statice la nivel de limbaj. Spre deosebire de blockchain-urile tradiționale, care folosesc arbori de stare globali, Sui a construit un model centrat pe obiect bazat pe "obiect", care funcționează cu sistemul de tip liniar al MoveVM pentru a face din programarea paralelă un proces determinist care poate fi finalizat în timpul compilării. Modelul obiect este fundamentul arhitecturii paralele a lui Sui. Sui abstractizează toate stările de pe lanț în obiecte separate, fiecare cu un ID unic, un proprietar clar (cont sau contract) și o definiție de tip. Aceste obiecte nu împărtășesc starea între ele și sunt în mod inerent izolate. Contractul trebuie să declare în mod explicit colecția de obiecte implicate atunci când este apelat, evitând problema cuplării de stare a tradiționalului "arbore global de stat". Acest design împarte starea on-chain în mai multe unități independente, făcând execuția concomitentă o premisă de programare fezabilă din punct de vedere structural. Analiza statică a proprietății este un mecanism de analiză în timp de compilare implementat cu sprijinul sistemului de tip liniar al limbajului Move. Permite sistemului să programeze tranzacțiile care să fie executate în paralel prin deducerea tranzacțiilor care nu au conflicte de stare prin proprietatea obiectului înainte de a fi executate. În comparație cu detectarea conflictelor și revenirea timpilor de rulare tradiționali, mecanismul de analiză statică al lui Sui reduce considerabil complexitatea programării, îmbunătățind în același timp eficiența execuției, care este cheia pentru obținerea unui randament ridicat și a capacităților de procesare paralelă deterministă. Sui împarte spațiul de stare pe bază de obiect cu obiect, combinat cu analiza proprietății în timpul compilării, pentru a obține o execuție paralelă la nivel de obiect cu costuri reduse, fără revenire. În comparație cu execuția serială sau detectarea timpului de rulare a lanțurilor tradiționale, Sui a obținut îmbunătățiri semnificative în eficiența execuției, determinismul sistemului și utilizarea resurselor. Mecanismul de aplicare Block-STM al Aptos Aptos este un blockchain Layer1 de înaltă performanță bazat pe limbajul Move, iar capacitatea sa de execuție paralelă este derivată în principal din cadrul Block-STM (Block-level Software Transactional Memory). Spre deosebire de strategia lui Sui de "paralelism static în timpul compilării", Block-STM aparține mecanismului de programare dinamică al "concurenței optimiste la rulare + revenire a conflictelor", care este potrivit pentru a face față seturilor de tranzacții cu dependențe complexe. Block-STM împarte executarea tranzacțiilor dintr-un bloc în trei etape: Execuție speculativă: Toate tranzacțiile sunt fără conflicte în mod implicit înainte de execuție, iar sistemul programează tranzacțiile pe mai multe fire de execuție pentru încercări de execuție simultană și înregistrează starea contului (set de citire/set de scriere) accesat de acestea. Faza de validare: Sistemul verifică rezultatul execuției: dacă există un conflict de citire-scriere între două tranzacții (de exemplu, Tx1 citește starea de scriere de Tx2), una dintre ele este anulată. Faza de reîncercare: Tranzacțiile conflictuale vor fi reprogramate până când dependențele lor sunt rezolvate și, în cele din urmă, toate tranzacțiile formează o secvență validă, deterministă de trimiteri de stare. Block-STM este un model de execuție dinamică de "paralelism optimist + rollback și reîncercări", care este potrivit pentru scenarii de procesare a loturilor de tranzacții on-chain cu utilizare intensivă a stării și complexe din punct de vedere logic și este nucleul de calcul paralel pentru Aptos pentru a construi un lanț public de înaltă versatilitate și randament ridicat. Solana este o școală de programare inginerească, mai mult ca un "nucleu de sistem de operare", potrivit pentru granițe clare de stare, tranzacționare controlabilă de înaltă frecvență și este un stil de inginer hardware, care ar trebui să ruleze lanțul ca hardware (execuție paralelă de nivel hardware); Aptos este un sistem tolerant la erori, mai degrabă un "motor de concurență a bazei de date", potrivit pentru sisteme contractuale cu cuplare puternică a stării și lanțuri de apeluri complexe. Aptos și Sui sunt ca inginerii limbajului de programare, iar securitatea resurselor de nivel software reprezintă calea de implementare tehnică a calculului paralel Web3 sub diferite filozofii. 3.3 Extensia paralelă Cosmos SDK Sei V2 este un lanț public tranzacțional de înaltă performanță construit pe baza Cosmos SDK, iar capacitatea sa de paralelism se reflectă în principal în două aspecte: motorul de potrivire multi-threaded (Parallel Matching Engine) și optimizarea execuției paralele a stratului de mașină virtuală, cu scopul de a deservi scenarii de tranzacții on-chain de înaltă frecvență și latență scăzută, cum ar fi DEX-urile din registrul de comenzi, infrastructura de schimb on-chain etc. Mecanismul paralel de bază: Motor de potrivire paralelă: SEI V2 introduce o cale de execuție cu mai multe fire de execuție în logica de potrivire a comenzilor, împărțind registrul de ordine în așteptare și logica de potrivire la nivel de fir, astfel încât sarcinile de potrivire între mai multe perechi de tranzacționare să poată fi procesate în paralel și să evite blocajele cu un singur fir. Optimizarea concurenței la nivel de mașină virtuală: Sei V2 construiește un mediu de rulare CosmWasm cu capabilități de execuție simultană, care permite unor apeluri de contract să ruleze în paralel fără conflicte de stare și cooperează cu mecanismul de clasificare a tipului de tranzacție pentru a obține un control mai mare al debitului. Planificarea paralelă a consensului și a stratului de execuție: Așa-numitul mecanism de consens "Twin-Turbo" este introdus pentru a consolida debitul și decuplarea dintre stratul de consens și stratul de execuție și pentru a îmbunătăți eficiența generală a procesării blocurilor. 3.4 Combustibil UTXO Model Reformer Fuel este un strat de execuție de înaltă performanță proiectat pe baza arhitecturii modulare a Ethereum, iar paralelismul său de bază este derivat din modelul UTXO îmbunătățit (Unspent Transaction Output). Spre deosebire de modelul de cont al Ethereum, Fuel folosește o structură UTXO pentru a reprezenta active și state, care este în mod inerent izolată de stat, ceea ce facilitează determinarea tranzacțiilor care pot fi executate în siguranță în paralel. În plus, Fuel introduce limbajul său de contract inteligent Sway (similar cu Rust), combinat cu instrumente de analiză statică, pentru a determina conflictele de intrare înainte ca tranzacțiile să fie executate, astfel încât să obțină o programare paralelă eficientă și sigură la nivel de tranzacție. Este un strat de execuție alternativ EVM care echilibrează performanța și modularitatea. 4. Modelul actorului: O nouă paradigmă pentru execuția simultană a agenților Modelul Actor este o paradigmă de execuție paralelă bazată pe agent sau proces, care este diferită de calculul sincron tradițional al stării globale pe lanț (Solana/Sui/Monad și alte scenarii de "calcul paralel on-chain"), care subliniază că fiecare agent are o stare și un comportament independent și comunică și programează prin mesaje asincrone. În cadrul acestei arhitecturi, sistemul on-chain poate fi rulat simultan de un număr mare de procese care sunt decuplate între ele și are o scalabilitate puternică și toleranță asincronă la erori. Printre proiectele reprezentative se numără AO (Arweave AO), ICP (Internet Computer) și Cartesi, care conduc evoluția blockchain-ului de la un motor de execuție la un "sistem de operare on-chain", oferind o infrastructură nativă pentru agenții AI, interacțiuni multi-tasking și orchestrare logică complexă. În timp ce designul modelului actorului este similar cu fragmentarea în ceea ce privește caracteristicile superficiale (de exemplu, paralelism, izolarea stării și procesarea asincronă), cele două reprezintă în esență căi tehnice și filozofii de sistem complet diferite. Modelul Actor pune accentul pe "calculul asincron multi-proces", în care fiecare agent rulează independent, menține starea independent și interacționează într-o manieră bazată pe mesaje. Fragmentarea, pe de altă parte, este un mecanism de "fragmentare orizontală a stării și a consensului", care împarte întregul blockchain în mai multe subsisteme (fragmente) care procesează tranzacțiile în mod independent. Modelele Actor seamănă mai mult cu un "sistem de operare cu agent distribuit" în lumea Web3, în timp ce fragmentarea este o soluție de scalare structurală pentru capabilitățile de procesare a tranzacțiilor în lanț. Ambele realizează paralelism, dar au puncte de plecare, obiective și arhitecturi de execuție diferite. 4.1 AO (Arweave), un computer super-paralel deasupra stratului de stocare AO este o platformă de calcul descentralizată care rulează pe stratul de stocare persistent al Arweave, cu scopul principal de a construi un sistem de operare on-chain care să accepte funcționarea agenților asincroni la scară largă. Caracteristici arhitecturale de bază: Arhitectura procesului: Fiecare agent este numit proces, cu stare independentă, programator independent și logică de execuție. Fără structură blockchain: AO nu este un lanț, ci un strat de stocare descentralizat + un motor de execuție bazat pe mesaje multi-agent bazat pe Arweave; Sistem asincron de programare a mesajelor: Procesele comunică între ele prin mesaje, adoptă un model de operare asincron fără blocare și, în mod natural, acceptă extinderea concurentă. Stocare permanentă a stării: Toate stările agenților, înregistrările mesajelor și instrucțiunile sunt înregistrate permanent pe Arweave, asigurând auditabilitate deplină și transparență descentralizată. Agent nativ: Este potrivit pentru implementarea sarcinilor complexe în mai mulți pași (cum ar fi agenți AI, controlere de protocol DePIN, orchestratori automati de sarcini etc.) și poate construi un "coprocesor AI on-chain". AO urmează calea finală a "agent nativ + driver de stocare + arhitectură fără lanț", punând accentul pe flexibilitate și decuplarea modulelor și este un "cadru de microkernel pe lanț construit deasupra stratului de stocare", cu limita sistemului micșorându-se în mod deliberat, subliniind calculul ușor + structura de control componabilă. 4.2 ICP (Internet Computer), o platformă de găzduire Web3 full-stack ICP este o platformă de aplicații on-chain nativă Web3 lansată de DFINITY, cu scopul de a extinde puterea de calcul on-chain la experiențe asemănătoare Web2 și de a sprijini găzduirea completă a serviciilor, legarea numelui de domeniu și arhitectura serverless. Caracteristici arhitecturale de bază: Arhitectura recipientului (containere ca agenți): Fiecare recipient este un agent care rulează pe o mașină virtuală Wasm cu capacitati independente de stare, cod și planificare asincronă. Sistem de consens distribuit de subrețea (subrețea): Întreaga rețea constă din mai multe subrețele, fiecare dintre ele menținând un set de canistre și ajungând la un consens prin mecanismul de semnătură BLS. Model de invocare asincron: Canister comunică cu Canister prin mesaje asincrone, acceptă execuția fără blocare și are paralelism natural. Găzduire web în lanț: Acceptă contracte inteligente pentru a găzdui direct pagini front-end, mapare DNS nativă și este prima platformă blockchain care acceptă browsere pentru a accesa direct dApps; Sistemul are funcții complete: Are API-uri de sistem, cum ar fi actualizarea la cald în lanț, autentificarea identității, aleatorietatea distribuită și temporizatorul, care este potrivit pentru implementarea complexă a serviciilor în lanț. ICP alege o paradigmă de sistem de operare de platformă grea, ambalaj integrat și control puternic al platformei și are un "sistem de operare blockchain" care integrează consensul, execuția, stocarea și accesul, subliniind capabilitățile complete de găzduire a serviciilor și extinzând limitele sistemului către o platformă de găzduire Web3 full-stack. În plus, proiectele de calcul paralel pentru alte paradigme ale modelului de actori pot fi găsite în tabelul următor: 5. Rezumat și perspectivă Pe baza diferențelor dintre arhitectura mașinii virtuale și sistemul de limbaj, soluțiile de calcul paralel blockchain pot fi împărțite în două categorii: lanț de îmbunătățire paralelă EVM și lanț de arhitectură paralelă nativă (non-EVM). Pe baza păstrării compatibilității ecosistemului EVM/Solidity, primul atinge un randament mai mare și capabilități de procesare paralelă prin optimizarea aprofundată a stratului de execuție, care este potrivit pentru scenariile care doresc să moștenească activele Ethereum și instrumentele de dezvoltare și să obțină progrese de performanță în același timp. Printre proiectele reprezentative se numără: Monad: Implementați un model optimist de execuție paralelă compatibil cu EVM prin detectarea conflictelor de scriere și rulare amânată, construiți grafice de dependență după finalizarea consensului și programați execuția în mai multe fire de execuție. MegaETH: Abstractizează fiecare cont/contract într-o micro-VM independentă și implementează programarea paralelă la nivel de cont foarte decuplată, bazată pe mesagerie asincronă și grafice dependente de stare. Pharos: Construiți o arhitectură de rețea rollup pentru a realiza procesarea paralelă la nivel de sistem între procese prin conducte asincrone și module SPN. Reddio: Folosește arhitectura zkRollup + GPU pentru a accelera procesul de verificare off-chain al zkEVM prin generarea SNARK în lot și pentru a îmbunătăți debitul de verificare. Acesta din urmă scapă complet de limitările compatibilității Ethereum și reproiectează paradigma de execuție din mașina virtuală, modelul de stare și mecanismul de programare pentru a obține concurență nativă de înaltă performanță. Subclasele tipice includ: Solana (SVM): Pe baza revendicărilor de acces la cont și a programării graficului de conflict static, reprezintă un model de execuție paralelă la nivel de cont. Sui / Aptos (sistem MoveVM): Bazat pe modelul obiectului de resurse și sistemul de tipuri, acceptă analiza statică în timpul compilării și realizează paralelismul la nivel de obiect. Sei V2 (ruta Cosmos SDK): introduce un motor de potrivire multi-threaded și optimizarea concurenței mașinilor virtuale în arhitectura Cosmos, care este potrivită pentru aplicații tranzacționale de înaltă frecvență. Combustibil (arhitectura UTXO + Sway): paralelism la nivel de tranzacție prin analiza statică a setului de intrări UTXO, combinând un strat de execuție modular cu un limbaj de contract inteligent personalizat Sway; În plus, ca un sistem paralel mai generalizat, modelul Actor construiește o paradigmă de execuție on-chain de "operare independentă multi-agent + colaborare bazată pe mesaje" printr-un mecanism asincron de programare a proceselor bazat pe Wasm sau VM personalizate. Printre proiectele reprezentative se numără: AO (Arweave AO): construiește un sistem de microkernel asincron on-chain bazat pe timpul de execuție a agentului bazat pe stocare persistentă. ICP (Internet Computer): utilizează agentul containerizat (Canister) ca cea mai mică unitate pentru a realiza o execuție asincronă și foarte scalabilă prin coordonarea subrețelei. Cartesi: Introduce sistemul de operare Linux ca un mediu de calcul off-chain pentru a oferi o cale de verificare on-chain pentru rezultate de calcul de încredere, potrivite pentru scenarii de aplicații complexe sau care necesită multe resurse. Pe baza logicii de mai sus, putem rezuma schema actuală a lanțului public de calcul paralel într-o structură de clasificare, așa cum se arată în figura următoare: Dintr-o perspectivă mai largă, sharding-ul și rollup-ul (L2) se concentrează pe scalarea orizontală prin fragmentarea stării sau execuția în afara lanțului, în timp ce lanțurile de calcul paralele (de exemplu, Monad, Sui, Solana) și sistemele orientate spre actori (de exemplu, AO, ICP) reconstruiesc direct modelul de execuție și obțin paralelism nativ în cadrul lanțului sau la nivelul sistemului. Primul îmbunătățește randamentul intra-lanț prin mașini virtuale multi-threaded, modele de obiecte, analiza conflictelor de tranzacții etc.; Acesta din urmă ia procesul/agentul ca unitate de bază și adoptă moduri de execuție bazate pe mesaje și asincrone pentru a realiza o funcționare simultană cu mai mulți agenți. În schimb, sharding-ul și rollup-urile seamănă mai mult cu "împărțirea sarcinii în mai multe lanțuri" sau "externalizarea off-chain", în timp ce modelul de lanț paralel și actor "dezlănțuie potențialul de performanță de la motorul de execuție în sine", reflectând o evoluție arhitecturală mai profundă. Calcul paralel vs arhitectură de fragmentare vs scalare rollup vs comparație a căii de scalare orientată spre actor Trebuie subliniat faptul că majoritatea lanțurilor native de arhitectură paralelă au intrat în faza de lansare a rețelei principale, deși ecosistemul general al dezvoltatorilor este încă dificil de comparat cu sistemul Solidity al sistemului EVM, dar proiectele reprezentate de Solana și Sui, cu arhitectura lor de execuție de înaltă performanță și prosperitatea treptată a aplicațiilor ecologice, au devenit lanțurile publice de bază cărora piața acordă o mare atenție. În schimb, deși ecosistemul Ethereum Rollup (L2) a intrat în stadiul de "10.000 de lanțuri simultan" sau chiar "supracapacitate", actualul lanț de îmbunătățire paralelă EVM este încă în general în stadiul de testnet și nu a fost încă verificat de mediul real al rețelei principale, iar capacitatea sa de scalare și stabilitatea sistemului trebuie încă testate în continuare. Rămâne de văzut dacă aceste proiecte pot îmbunătăți semnificativ performanța EVM și pot genera salturi ecologice fără a sacrifica compatibilitatea sau dacă pot diferenția și mai mult lichiditatea și resursele de dezvoltare ale Ethereum.

Scris de 0xjacobzhao și ChatGPT 4o "Securitatea", "descentralizarea" și "scalabilitatea" blockchain-ului "Blockchain Trilemma" dezvăluie compromisul esențial în proiectarea sistemelor blockchain, adică este dificil pentru proiectele blockchain să obțină "securitate extremă, toată lumea poate participa și procesare de mare viteză" în același timp. Ca răspuns la eternul subiect al "scalabilității", soluțiile de scalare blockchain de pe piață sunt împărțite în funcție de paradigme, inclusiv: Scalare îmbunătățită de execuție: îmbunătățește capacitățile de execuție, cum ar fi paralelismul, GPU și multi-core, in situ Scalare izolată de stare: Împarte orizontal starea/fragmentele, cum ar fi fragmente, UTXO și mai multe subrețele Scalarea externalizării în afara lanțului: Punerea execuției în afara lanțului, cum ar fi rollup-uri, coprocesoare și DA Extinderea capacității de decuplare structurală: Arhitectura este modulară și funcționează împreună, cum ar fi lanțuri de module, secvențiere partajate și ochiuri de rollup Scalare concurentă asincronă: model de actor, izolare de proces, bazată pe mesaje, cum ar fi agenți și lanțuri asincrone cu mai multe fire de execuție Soluția de scalare blockchain include: calcul paralel on-chain, rollup, sharding, modul DA, structură modulară, sistem actor, compresie zk proof, arhitectură stateless etc., acoperind mai multe niveluri de execuție, stare, date și structură și este un sistem complet de scalare de "colaborare multi-strat și combinație de module". Acest articol se concentrează pe metodele de scalare care integrează calculul paralel. Paralelismul intra-lanț, care se concentrează pe executarea paralelă a tranzacțiilor/instrucțiunilor intra-bloc. Conform mecanismului paralel, metodele sale de scalare pot fi împărțite în cinci categorii, fiecare dintre ele reprezentând o căutare diferită de performanță, model de dezvoltare și filozofie de arhitectură, iar granularitatea paralelă devine din ce în ce mai fină, intensitatea paralelismului devine din ce în ce mai mare, complexitatea programării devine din ce în ce mai mare, iar complexitatea programării și dificultatea de implementare devin din ce în ce mai mari. La nivel de cont: Reprezintă proiectul Solana Paralelism la nivel de obiect: Reprezintă proiectul Sui La nivel de tranzacție: Reprezintă proiectul Monad, Aptos Call-level / MicroVM: Reprezintă proiectul MegaETH Nivel de instruire: Reprezintă proiectul GatlingX Modelul de concurență asincronă off-chain, reprezentat de Modelul Actor/Actor, aparține unei alte paradigme de calcul paralel, ca sistem de mesaje cross-chain/asincron (model de sincronizare non-block), fiecare agent rulează independent ca "proces agent", mesaje asincrone în mod paralel, event-driven, fără programare sincronă, proiecte reprezentative precum AO, ICP, Cartesi etc. Binecunoscuta schemă de scalare a cumulului sau a fragmentelor aparține mecanismului de concurență la nivel de sistem, nu calculului paralel intra-lanț. Acestea obțin scalarea prin "rularea mai multor lanțuri/domenii de execuție în paralel", mai degrabă decât creșterea paralelismului într-un singur bloc/mașină virtuală. Acest tip de soluție de scalare nu este punctul central al acestui articol, dar îl vom folosi în continuare pentru a compara asemănările și diferențele dintre conceptele arhitecturale. 2. Lanț de îmbunătățire paralelă EVM: depășirea limitei de performanță în compatibilitate De la dezvoltarea arhitecturii de procesare serială a Ethereum, aceasta a suferit mai multe runde de încercări de scalare, cum ar fi fragmentare, rollup și arhitectură modulară, dar blocajul de debit al stratului de execuție nu a fost încă rupt fundamental. Dar, în același timp, EVM și Solidity sunt în continuare platformele de contracte inteligente cu cea mai mare bază de dezvoltatori și potențial ecologic. Prin urmare, lanțul de îmbunătățire paralelă EVM devine o direcție importantă pentru o nouă rundă de scalare și evoluție ca o cale cheie care ia în considerare compatibilitatea ecologică și îmbunătățirea performanței de execuție. Monad și MegaETH sunt cele mai reprezentative proiecte în această direcție, începând de la execuția amânată și, respectiv, descompunerea stării, pentru a construi o arhitectură de procesare paralelă EVM pentru scenarii de concurență ridicată și de mare randament. Analiza mecanismului de calcul paralel al Monadului Monad este un blockchain de înaltă performanță de nivel 1 reproiectat pentru Ethereum Virtual Machine (EVM), bazat pe conceptul paralel de bază al pipelining, cu execuție asincronă la nivelul de consens și execuție paralelă optimistă la nivelul de execuție. În plus, la nivelurile de consens și stocare, Monad a introdus protocolul BFT de înaltă performanță (MonadBFT) și, respectiv, un sistem de baze de date dedicat (MonadDB) pentru a obține optimizarea end-to-end. Pipelining: un mecanism de execuție paralelă pentru conducte în mai multe etape Pipelining este conceptul de bază al execuției paralele Monad, iar ideea sa de bază este de a împărți procesul de execuție a blockchain-ului în mai multe etape independente și de a procesa aceste etape în paralel pentru a forma o arhitectură de conductă tridimensională, fiecare etapă rulează pe fire sau nuclee independente pentru a realiza procesarea concurentă între blocuri și, în cele din urmă, a obține efectul de îmbunătățire a debitului și de reducere a latenței Aceste etape includ: Propunere, Consens, Execuție și Comitere. Execuție asincronă: Consens - Efectuează decuplarea asincronă Pe lanțurile tradiționale, consensul și execuția tranzacțiilor sunt de obicei procese sincrone, iar acest model serial limitează sever scalarea performanței. Monad implementează stratul de consens asincron, stratul de execuție asincron și stocarea asincronă prin "execuție asincronă". Reduceți semnificativ timpul de blocare și latența de confirmare, făcând sistemul mai rezistent, procesarea mai segmentată și utilizarea resurselor. Design de bază: Procesul de consens (stratul de consens) este responsabil doar pentru ordonarea tranzacțiilor și nu execută logica contractului. Procesul de execuție (stratul de execuție) este declanșat asincron după finalizarea consensului. După finalizarea consensului, acesta va intra imediat în procesul de consens al următorului bloc, fără a aștepta finalizarea execuției. Execuție paralelă optimistă: Execuție paralelă optimistă Ethereum tradițional folosește un model strict serial pentru executarea tranzacțiilor pentru a evita conflictele de stare. Monad, pe de altă parte, adoptă o strategie de "execuție paralelă optimistă" pentru a crește semnificativ viteza de procesare a tranzacțiilor. Mecanismul de aplicare: Monad execută cu optimism toate tranzacțiile în paralel, presupunând că cele mai multe dintre ele nu au conflicte între ele. De asemenea, rulați un "detector de conflicte" pentru a monitoriza dacă aceeași stare (de exemplu, conflicte de citire/scriere) este accesată între tranzacții. Dacă este detectat un conflict, tranzacția conflictuală este serializată și reexecutată pentru a se asigura că starea este corectă. Monad a ales o cale compatibilă: să mute cât mai puține reguli EVM, să obțină paralelismul prin amânarea stării de scriere și detectarea dinamică a conflictelor în timpul execuției, care seamănă mai mult cu o versiune de performanță a Ethereum, cu un nivel de maturitate care facilitează migrarea către ecosistemul EVM și este un accelerator paralel în lumea EVM. Analiza computațională paralelă a MegaETH Spre deosebire de poziționarea L1 a Monad, MegaETH este poziționat ca un strat modular de execuție paralelă de înaltă performanță compatibil cu EVM, care poate fi utilizat ca un lanț public L1 independent, ca un strat de îmbunătățire a execuției sau o componentă modulară pe Ethereum. Scopul său principal de proiectare este de a deconstrui logica contului, mediul de execuție și izolarea stării în cea mai mică unitate care poate fi programată independent pentru a obține o execuție cu concurență ridicată și o capacitate de răspuns cu latență scăzută în cadrul lanțului. Inovația cheie propusă de MegaETH este că arhitectura Micro-VM + State Dependency DAG (graficul de dependență de stare direcționat și aciclic) și mecanismul de sincronizare modulară construiesc împreună un sistem de execuție paralelă pentru "threading intra-lanț". Arhitectura Micro-VM: Conturile sunt fire de execuție MegaETH introduce modelul de execuție "un micro-VM per cont", care "threadează" mediul de execuție și oferă o unitate de izolare minimă pentru programarea paralelă. Aceste mașini virtuale comunică între ele prin mesagerie asincronă în loc de apeluri sincrone, iar un număr mare de mașini virtuale pot fi executate independent, stocate independent și în mod natural în paralel. State Dependency DAG: un mecanism de programare bazat pe grafice MegaETH a construit un sistem de programare DAG bazat pe relația de acces la starea contului, iar sistemul menține un grafic global de dependențe în timp real, iar conturile care sunt modificate și conturile sunt citite pentru fiecare tranzacție sunt toate modelate în dependențe. Tranzacțiile fără conflict pot fi executate direct în paralel, iar tranzacțiile dependente vor fi programate și sortate în serie sau amânate în ordine topologică. Graficele de dependență asigură consecvența stării și scrierile non-duplicate în timpul execuției paralele. Execuție asincronă și mecanisme de apelare inversă MegaETH este construit pe baza paradigmei de programare asincronă, similară cu mesageria asincronă a modelului Actor, care rezolvă problema apelurilor seriale EVM tradiționale. Apelurile contractuale sunt asincrone (execuție non-recursivă), iar atunci când contractul A -> B -> C este apelat, fiecare apel este asincron fără a bloca așteptarea; Stiva de apeluri este extinsă într-un grafic de apeluri asincron; Procesarea tranzacțiilor = traversarea grafului asincron + rezoluția dependențelor + programarea paralelă. Una peste alta, MegaETH sparge modelul tradițional de mașină de stare EVM cu un singur fir, implementează încapsularea mașinilor micro-virtuale cont cu cont, efectuează programarea tranzacțiilor prin grafice dependente de stare și înlocuiește stiva de apeluri sincrone cu un mecanism de mesagerie asincron. Este o platformă de calcul paralel care este reproiectată din dimensiunile complete ale "structurii contului→ arhitecturii de planificare, → procesului de execuție", oferind o nouă idee la nivel de paradigmă pentru construirea unui sistem on-chain de înaltă performanță de ultimă generație. MegaETH a ales calea refactorizării: abstractizează complet conturile și contractele în VM-uri independente și dezlănțuie potențialul suprem de paralelism prin programarea asincronă a execuției. Teoretic, MegaETH are o limită paralelă mai mare, dar este și mai dificil de controlat complexitatea și seamănă mai mult cu un sistem de operare super-distribuit sub conceptul Ethereum. Conceptele de design ale Monad și MegaETH sunt destul de diferite de sharding: sharding-ul împarte orizontal blockchain-ul în mai multe sub-lanțuri independente (fragmente), iar fiecare sub-lanț este responsabil pentru o parte din tranzacții și stări, depășind limita unui singur lanț și scalând la nivelul rețelei; Pe de altă parte, atât Monad, cât și MegaETH mențin integritatea lanțului unic, scalând orizontal doar la nivelul de execuție și efectuând descoperiri de optimizare în paralel la limita lanțului unic. Cele două reprezintă două direcții: consolidarea verticală și expansiunea orizontală pe calea de expansiune a blockchain-ului. Proiectele de calcul paralel, cum ar fi Monad și MegaETH, se concentrează în principal pe calea de optimizare a debitului, cu scopul principal de a îmbunătăți TPS on-chain și de a realiza procesarea paralelă la nivel de tranzacție sau la nivel de cont prin execuție amânată și arhitecturi micro-VM. Pharos Network este o rețea blockchain L1 paralelă modulară, full-stack, iar sistemul său de calcul paralel de bază se numește "Rollup Mesh". Această arhitectură acceptă medii de mașini multi-virtuale (EVM și Wasm) prin sinergia rețelelor principale și a rețelelor speciale de procesare (SPN) și integrează tehnologii avansate, cum ar fi dovezile zero-knowledge (ZK) și mediile de execuție de încredere (TEE). Analiza de calcul paralel Rollup Mesh: Canalizare asincronă a ciclului de viață complet: Pharos decuplează diferitele etape ale unei tranzacții (de exemplu, consens, execuție, stocare) și adoptă procesarea asincronă, astfel încât fiecare etapă să poată fi efectuată independent și în paralel, îmbunătățind astfel eficiența generală a procesării. Execuție paralelă duală VM: Pharos acceptă atât medii de mașini virtuale EVM, cât și WASM, permițând dezvoltatorilor să aleagă mediul de execuție potrivit pentru nevoile lor. Această arhitectură dual-VM nu numai că crește flexibilitatea sistemului, dar crește și procesarea tranzacțiilor prin execuție paralelă. Rețele speciale de procesare (SPN): SPN-urile sunt componente cheie în arhitectura Pharos, similare cu subrețelele modulare concepute pentru a gestiona tipuri specifice de sarcini sau aplicații. Cu SPN-urile, Pharos permite alocarea dinamică a resurselor și procesarea paralelă a sarcinilor, îmbunătățind și mai mult scalabilitatea și performanța sistemului. Consens modular și restaking: Pharos introduce un mecanism de consens flexibil care acceptă mai multe modele de consens (cum ar fi PBFT, PoS, PoA) și permite partajarea sigură și integrarea resurselor între rețeaua principală și SPN-uri prin protocolul de restaking. În plus, Pharos reconstruiește modelul de execuție din stratul inferior al motorului de stocare prin intermediul tehnologiei Merkle tree multi-version, Delta Encoding, Versioned Addressing și ADS Pushdown și lansează Pharos Store, un motor de stocare de înaltă performanță pentru blockchain-ul nativ, pentru a obține un debit ridicat, latență scăzută și capabilități puternice de procesare verificabile în lanț. În general, arhitectura Rollup Mesh de la Pharos atinge capabilități de calcul paralel de înaltă performanță prin design modular și mecanism de procesare asincronă. Pe lângă arhitecturile de execuție paralelă ale Monad, MegaETH și Pharos, observăm și că există unele proiecte pe piață care explorează calea de aplicare a accelerației GPU în calculul paralel EVM, ca un supliment important și un experiment de ultimă oră pentru ecosistemul paralel EVM. Dintre acestea, Reddio și GatlingX sunt două direcții reprezentative: Reddio este o platformă de înaltă performanță care combină zkRollup cu arhitectura de execuție paralelă GPU, iar nucleul său este de a refactoriza procesul de execuție EVM pentru a obține paralelizarea nativă a stratului de execuție prin programare multi-threaded, stocare asincronă a stării și execuție accelerată de GPU a loturilor de tranzacții. Granularitate paralelă la nivel de tranzacție + nivel de operațiune (opcode de execuție multi-threaded). Este conceput pentru a introduce execuția loturilor multi-threaded, încărcarea asincronă a stării și logica de tranzacție de procesare paralelă GPU (EVM paralel compatibil CUDA). La fel ca Monad / MegaETH, Reddio se concentrează și pe procesarea paralelă la nivelul de execuție, diferența fiind că motorul de execuție este reconstruit printr-o arhitectură paralelă GPU, concepută pentru scenarii cu randament ridicat și cu consum intensiv de calcul, cum ar fi inferența AI. În prezent, SDK-ul a fost lansat și este furnizat un modul de execuție integrat Numindu-se "GPU-EVM", GatlingX propune o arhitectură mai radicală care încearcă să migreze modelul de "execuție serială la nivel de instrucțiune" a mașinilor virtuale EVM tradiționale în medii de rulare paralele native GPU. Mecanismul de bază este de a compila dinamic codul de octeți EVM în sarcini paralele CUDA și de a executa fluxul de instrucțiuni prin GPU multi-core, astfel încât să spargă blocajul secvențial al EVM la cel mai mic nivel. Granularitate paralelă care aparține paralelismului la nivel de instrucțiune (ILP). În comparație cu granularitatea paralelă "la nivel de tranzacție/la nivel de cont" a Monad / MegaETH, mecanismul de paralelism al GatlingX aparține căii de optimizare la nivel de instrucțiune, care este mai aproape de refactorizarea de bază a motorului mașinii virtuale. În prezent, se află în faza de concept, cu o carte albă și o schiță arhitecturală publicate și fără SDK sau mainnet încă. Artela propune un concept de design diferențiat, paralel. Odată cu introducerea mașinii virtuale WebAssembly (WASM) cu arhitectură EVM++, dezvoltatorilor li se permite să adauge și să execute dinamic extensii on-chain folosind modelul de programare Aspect, menținând în același timp compatibilitatea EVM. Folosește granularitatea de invocare a contractului (Funcție / Extensie) ca unitate paralelă minimă și acceptă injectarea modulelor de extensie (similar cu "middleware-ul conectabil") atunci când contractul EVM rulează, astfel încât să obțină decuplarea logică, invocarea asincronă și execuția paralelă la nivel de modul. Se acordă mai multă atenție compoziției și arhitecturii modulare a stratului de execuție. Conceptul oferă idei noi pentru aplicații complexe cu mai multe module în viitor. 3. Lanț de arhitectură paralelă nativă: Reconstruiți ontologia de execuție a VM-urilor Modelul de execuție EVM de la Ethereum a adoptat o arhitectură single-threaded de "ordin complet de tranzacție + execuție serială" încă de la începutul proiectării sale, cu scopul de a asigura certitudinea și consecvența schimbărilor de stare pentru toate nodurile din rețea. Cu toate acestea, această arhitectură are un blocaj natural în performanță, limitând debitul și scalabilitatea sistemului. În schimb, lanțurile native de arhitectură de calcul paralel, cum ar fi Solana (SVM), MoveVM (Sui, Aptos) și Sei v2 construite pe Cosmos SDK sunt adaptate pentru execuție paralelă din stratul inferior și au următoarele avantaje: Separarea naturală a modelelor de stare: Solana folosește mecanismul de declarație de blocare a contului, MoveVM introduce modelul de proprietate a obiectului, iar Sei v2 implementează judecata statică a conflictului pe baza clasificării tipului de tranzacție și acceptă programarea concurentă la nivel de tranzacție. Mașinile virtuale sunt optimizate pentru concurență: motorul Sealevel al Solana acceptă în mod nativ execuția multi-threaded; MoveVM poate efectua analiza graficului de concurență statică; Sei v2 integrează un motor de potrivire multi-threaded cu un modul VM paralel. Desigur, acest tip de lanț paralel nativ se confruntă și cu provocarea compatibilității ecologice. Arhitecturile non-EVM necesită de obicei noi limbaje de dezvoltare (cum ar fi Move și Rust) și lanțuri de instrumente, care au anumite costuri de migrare pentru dezvoltatori. În plus, dezvoltatorii trebuie să stăpânească o serie de concepte noi, cum ar fi modele de acces cu stare, limite de concurență, cicluri de viață ale obiectelor etc., care prezintă cerințe mai mari pentru înțelegerea pragurilor și a paradigmelor de dezvoltare. 3.1 Principiul motorului paralel Sealevel al Solana și SVM Modelul de execuție Sealevel al Solana este un mecanism de programare paralelă a contului, care este motorul de bază utilizat de Solana pentru a realiza executarea tranzacțiilor paralele în cadrul lanțului și realizează concurență de înaltă performanță la nivel de contract inteligent prin mecanismul "declarație cont + programare statică + execuție multi-threaded". Sealevel este primul model de execuție din domeniul blockchain care a implementat cu succes programarea concurentă intra-lanț într-un mediu de producție, iar ideile sale arhitecturale au influențat multe proiecte ulterioare de calcul paralel și este o paradigmă de referință pentru proiectarea paralelă de înaltă performanță Layer 1. Mecanica de bază: 1. Liste explicite de acces la cont: Fiecare tranzacție trebuie să declare contul implicat (citire/scriere) la trimitere, astfel încât sistemul să poată determina dacă există un conflict de stare între tranzacții. 2. Detectarea conflictelor și programarea cu mai multe fire de execuție Dacă nu există suprapuneri între seturile de conturi accesate de cele două tranzacții→ acestea pot fi executate în paralel; Există un conflict→ executat în serie în ordine dependentă; Programatorul alocă tranzacții diferitelor fire de execuție pe baza graficului de dependențe. 3. Contextul de invocare a programului: Fiecare apel de contract rulează într-un context izolat, fără o stivă partajată pentru a evita interferențele între apeluri. Sealevel este motorul de programare a execuției paralele al Solana, în timp ce SVM este un mediu de execuție a contractelor inteligente construit pe Sealevel (folosind mașina virtuală BPF). Împreună, acestea formează baza tehnică a sistemului de execuție paralelă de înaltă performanță al Solana. Eclipse este un proiect care implementează VM-uri Solana pe lanțuri modulare, cum ar fi Ethereum L2 sau Celestia, folosind motorul de execuție paralelă al Solana ca strat de execuție rollup. Eclipse este unul dintre primele proiecte care propune detașarea stratului de execuție Solana (Sealevel + SVM) de la rețeaua principală Solana și migrarea acestuia la o arhitectură modulară, iar rezultatul modular al "modelului de execuție super concurent" al Solana este Execution Layer-as-a-Service, astfel încât Eclipse aparține și categoriei de calcul paralel. Traseul Neon este diferit, introduce EVM pentru a funcționa într-un mediu SVM / Sealevel. Construiți un strat de rulare compatibil cu EVM, dezvoltatorii pot folosi Solidity pentru a dezvolta contracte și a rula în mediul SVM, dar execuția de programare folosește SVM + Sealeve. Neon înclină mai mult spre categoria Modular Blockchain decât spre inovația de calcul paralel. Una peste alta, Solana și SVM-urile se bazează pe motorul de execuție Sealevel, iar filozofia de planificare bazată pe sistemul de operare Solana este similară cu planificatorul kernel, care este rapid, dar relativ inflexibil. Este un lanț public nativ de calcul paralel de înaltă performanță. 3.2 Arhitectura MoveVM: bazată pe resurse și obiecte MoveVM este o mașină virtuală cu contract inteligent concepută pentru securitatea resurselor on-chain și execuția paralelă, iar limbajul său de bază, Move, a fost dezvoltat inițial de Meta (fostul Facebook) pentru proiectul Libra, subliniind conceptul de "resursele sunt obiecte" și toate stările on-chain există ca obiecte, cu proprietate și cicluri de viață clare. Acest lucru permite MoveVM să analizeze dacă există conflicte de stare între tranzacții în timpul compilării și să implementeze programarea paralelă statică la nivel de obiect, care este utilizată pe scară largă în lanțurile publice paralele native, cum ar fi Sui și Aptos. Modelul de proprietate a obiectelor lui Sui Capacitățile de calcul paralel ale lui Sui provin din abordarea sa unică a modelării stării și a analizei statice la nivel de limbaj. Spre deosebire de blockchain-urile tradiționale, care folosesc arbori de stare globali, Sui a construit un model centrat pe obiect bazat pe "obiect", care funcționează cu sistemul de tip liniar al MoveVM pentru a face din programarea paralelă un proces determinist care poate fi finalizat în timpul compilării. Modelul obiect este fundamentul arhitecturii paralele a lui Sui. Sui abstractizează toate stările de pe lanț în obiecte separate, fiecare cu un ID unic, un proprietar clar (cont sau contract) și o definiție de tip. Aceste obiecte nu împărtășesc starea între ele și sunt în mod inerent izolate. Contractul trebuie să declare în mod explicit colecția de obiecte implicate atunci când este apelat, evitând problema cuplării de stare a tradiționalului "arbore global de stat". Acest design împarte starea on-chain în mai multe unități independente, făcând execuția concomitentă o premisă de programare fezabilă din punct de vedere structural. Analiza statică a proprietății este un mecanism de analiză în timp de compilare implementat cu sprijinul sistemului de tip liniar al limbajului Move. Permite sistemului să programeze tranzacțiile care să fie executate în paralel prin deducerea tranzacțiilor care nu au conflicte de stare prin proprietatea obiectului înainte de a fi executate. În comparație cu detectarea conflictelor și revenirea timpilor de rulare tradiționali, mecanismul de analiză statică al lui Sui reduce considerabil complexitatea programării, îmbunătățind în același timp eficiența execuției, care este cheia pentru obținerea unui randament ridicat și a capacităților de procesare paralelă deterministă. Sui împarte spațiul de stare pe bază de obiect cu obiect, combinat cu analiza proprietății în timpul compilării, pentru a obține o execuție paralelă la nivel de obiect cu costuri reduse, fără revenire. În comparație cu execuția serială sau detectarea timpului de rulare a lanțurilor tradiționale, Sui a obținut îmbunătățiri semnificative în eficiența execuției, determinismul sistemului și utilizarea resurselor. Mecanismul de aplicare Block-STM al Aptos Aptos este un blockchain Layer1 de înaltă performanță bazat pe limbajul Move, iar capacitatea sa de execuție paralelă este derivată în principal din cadrul Block-STM (Block-level Software Transactional Memory). Spre deosebire de strategia lui Sui de "paralelism static în timpul compilării", Block-STM aparține mecanismului de programare dinamică al "concurenței optimiste la rulare + revenire a conflictelor", care este potrivit pentru a face față seturilor de tranzacții cu dependențe complexe. Block-STM împarte executarea tranzacțiilor dintr-un bloc în trei etape: Execuție speculativă: Toate tranzacțiile sunt fără conflicte în mod implicit înainte de execuție, iar sistemul programează tranzacțiile pe mai multe fire de execuție pentru încercări de execuție simultană și înregistrează starea contului (set de citire/set de scriere) accesat de acestea. Faza de validare: Sistemul verifică rezultatul execuției: dacă există un conflict de citire-scriere între două tranzacții (de exemplu, Tx1 citește starea de scriere de Tx2), una dintre ele este anulată. Faza de reîncercare: Tranzacțiile conflictuale vor fi reprogramate până când dependențele lor sunt rezolvate și, în cele din urmă, toate tranzacțiile formează o secvență validă, deterministă de trimiteri de stare. Block-STM este un model de execuție dinamică de "paralelism optimist + rollback și reîncercări", care este potrivit pentru scenarii de procesare a loturilor de tranzacții on-chain cu utilizare intensivă a stării și complexe din punct de vedere logic și este nucleul de calcul paralel pentru Aptos pentru a construi un lanț public de înaltă versatilitate și randament ridicat. Solana este o școală de programare inginerească, mai mult ca un "nucleu de sistem de operare", potrivit pentru granițe clare de stare, tranzacționare controlabilă de înaltă frecvență și este un stil de inginer hardware, care ar trebui să ruleze lanțul ca hardware (execuție paralelă de nivel hardware); Aptos este un sistem tolerant la erori, mai degrabă un "motor de concurență a bazei de date", potrivit pentru sisteme contractuale cu cuplare puternică a stării și lanțuri de apeluri complexe. Aptos și Sui sunt ca inginerii limbajului de programare, iar securitatea resurselor de nivel software reprezintă calea de implementare tehnică a calculului paralel Web3 sub diferite filozofii. 3.3 Extensia paralelă Cosmos SDK Sei V2 este un lanț public tranzacțional de înaltă performanță construit pe baza Cosmos SDK, iar capacitatea sa de paralelism se reflectă în principal în două aspecte: motorul de potrivire multi-threaded (Parallel Matching Engine) și optimizarea execuției paralele a stratului de mașină virtuală, cu scopul de a deservi scenarii de tranzacții on-chain de înaltă frecvență și latență scăzută, cum ar fi DEX-urile din registrul de comenzi, infrastructura de schimb on-chain etc. Mecanismul paralel de bază: Motor de potrivire paralelă: SEI V2 introduce o cale de execuție cu mai multe fire de execuție în logica de potrivire a comenzilor, împărțind registrul de ordine în așteptare și logica de potrivire la nivel de fir, astfel încât sarcinile de potrivire între mai multe perechi de tranzacționare să poată fi procesate în paralel și să evite blocajele cu un singur fir. Optimizarea concurenței la nivel de mașină virtuală: Sei V2 construiește un mediu de rulare CosmWasm cu capabilități de execuție simultană, care permite unor apeluri de contract să ruleze în paralel fără conflicte de stare și cooperează cu mecanismul de clasificare a tipului de tranzacție pentru a obține un control mai mare al debitului. Planificarea paralelă a consensului și a stratului de execuție: Așa-numitul mecanism de consens "Twin-Turbo" este introdus pentru a consolida debitul și decuplarea dintre stratul de consens și stratul de execuție și pentru a îmbunătăți eficiența generală a procesării blocurilor. 3.4 Combustibil UTXO Model Reformer Fuel este un strat de execuție de înaltă performanță proiectat pe baza arhitecturii modulare a Ethereum, iar paralelismul său de bază este derivat din modelul UTXO îmbunătățit (Unspent Transaction Output). Spre deosebire de modelul de cont al Ethereum, Fuel folosește o structură UTXO pentru a reprezenta active și state, care este în mod inerent izolată de stat, ceea ce facilitează determinarea tranzacțiilor care pot fi executate în siguranță în paralel. În plus, Fuel introduce limbajul său de contract inteligent Sway (similar cu Rust), combinat cu instrumente de analiză statică, pentru a determina conflictele de intrare înainte ca tranzacțiile să fie executate, astfel încât să obțină o programare paralelă eficientă și sigură la nivel de tranzacție. Este un strat de execuție alternativ EVM care echilibrează performanța și modularitatea. 4. Modelul actorului: O nouă paradigmă pentru execuția simultană a agenților Modelul Actor este o paradigmă de execuție paralelă bazată pe agent sau proces, care este diferită de calculul sincron tradițional al stării globale pe lanț (Solana/Sui/Monad și alte scenarii de "calcul paralel on-chain"), care subliniază că fiecare agent are o stare și un comportament independent și comunică și programează prin mesaje asincrone. În cadrul acestei arhitecturi, sistemul on-chain poate fi rulat simultan de un număr mare de procese care sunt decuplate între ele și are o scalabilitate puternică și toleranță asincronă la erori. Printre proiectele reprezentative se numără AO (Arweave AO), ICP (Internet Computer) și Cartesi, care conduc evoluția blockchain-ului de la un motor de execuție la un "sistem de operare on-chain", oferind o infrastructură nativă pentru agenții AI, interacțiuni multi-tasking și orchestrare logică complexă. În timp ce designul modelului actorului este similar cu fragmentarea în ceea ce privește caracteristicile superficiale (de exemplu, paralelism, izolarea stării și procesarea asincronă), cele două reprezintă în esență căi tehnice și filozofii de sistem complet diferite. Modelul Actor pune accentul pe "calculul asincron multi-proces", în care fiecare agent rulează independent, menține starea independent și interacționează într-o manieră bazată pe mesaje. Fragmentarea, pe de altă parte, este un mecanism de "fragmentare orizontală a stării și a consensului", care împarte întregul blockchain în mai multe subsisteme (fragmente) care procesează tranzacțiile în mod independent. Modelele Actor seamănă mai mult cu un "sistem de operare cu agent distribuit" în lumea Web3, în timp ce fragmentarea este o soluție de scalare structurală pentru capabilitățile de procesare a tranzacțiilor în lanț. Ambele realizează paralelism, dar au puncte de plecare, obiective și arhitecturi de execuție diferite. 4.1 AO (Arweave), un computer super-paralel deasupra stratului de stocare AO este o platformă de calcul descentralizată care rulează pe stratul de stocare persistent al Arweave, cu scopul principal de a construi un sistem de operare on-chain care să accepte funcționarea agenților asincroni la scară largă. Caracteristici arhitecturale de bază: Arhitectura procesului: Fiecare agent este numit proces, cu stare independentă, programator independent și logică de execuție. Fără structură blockchain: AO nu este un lanț, ci un strat de stocare descentralizat + un motor de execuție bazat pe mesaje multi-agent bazat pe Arweave; Sistem asincron de programare a mesajelor: Procesele comunică între ele prin mesaje, adoptă un model de operare asincron fără blocare și, în mod natural, acceptă extinderea concurentă. Stocare permanentă a stării: Toate stările agenților, înregistrările mesajelor și instrucțiunile sunt înregistrate permanent pe Arweave, asigurând auditabilitate deplină și transparență descentralizată. Agent nativ: Este potrivit pentru implementarea sarcinilor complexe în mai mulți pași (cum ar fi agenți AI, controlere de protocol DePIN, orchestratori automati de sarcini etc.) și poate construi un "coprocesor AI on-chain". AO urmează calea finală a "agent nativ + driver de stocare + arhitectură fără lanț", punând accentul pe flexibilitate și decuplarea modulelor și este un "cadru de microkernel pe lanț construit deasupra stratului de stocare", cu limita sistemului micșorându-se în mod deliberat, subliniind calculul ușor + structura de control componabilă. 4.2 ICP (Internet Computer), o platformă de găzduire Web3 full-stack ICP este o platformă de aplicații on-chain nativă Web3 lansată de DFINITY, cu scopul de a extinde puterea de calcul on-chain la experiențe asemănătoare Web2 și de a sprijini găzduirea completă a serviciilor, legarea numelui de domeniu și arhitectura serverless. Caracteristici arhitecturale de bază: Arhitectura recipientului (containere ca agenți): Fiecare recipient este un agent care rulează pe o mașină virtuală Wasm cu capacitati independente de stare, cod și planificare asincronă. Sistem de consens distribuit de subrețea (subrețea): Întreaga rețea constă din mai multe subrețele, fiecare dintre ele menținând un set de canistre și ajungând la un consens prin mecanismul de semnătură BLS. Model de invocare asincron: Canister comunică cu Canister prin mesaje asincrone, acceptă execuția fără blocare și are paralelism natural. Găzduire web în lanț: Acceptă contracte inteligente pentru a găzdui direct pagini front-end, mapare DNS nativă și este prima platformă blockchain care acceptă browsere pentru a accesa direct dApps; Sistemul are funcții complete: Are API-uri de sistem, cum ar fi actualizarea la cald în lanț, autentificarea identității, aleatorietatea distribuită și temporizatorul, care este potrivit pentru implementarea complexă a serviciilor în lanț. ICP alege o paradigmă de sistem de operare de platformă grea, ambalaj integrat și control puternic al platformei și are un "sistem de operare blockchain" care integrează consensul, execuția, stocarea și accesul, subliniind capabilitățile complete de găzduire a serviciilor și extinzând limitele sistemului către o platformă de găzduire Web3 full-stack. În plus, proiectele de calcul paralel pentru alte paradigme ale modelului de actori pot fi găsite în tabelul următor: 5. Rezumat și perspectivă Pe baza diferențelor dintre arhitectura mașinii virtuale și sistemul de limbaj, soluțiile de calcul paralel blockchain pot fi împărțite în două categorii: lanț de îmbunătățire paralelă EVM și lanț de arhitectură paralelă nativă (non-EVM). Pe baza păstrării compatibilității ecosistemului EVM/Solidity, primul atinge un randament mai mare și capabilități de procesare paralelă prin optimizarea aprofundată a stratului de execuție, care este potrivit pentru scenariile care doresc să moștenească activele Ethereum și instrumentele de dezvoltare și să obțină progrese de performanță în același timp. Printre proiectele reprezentative se numără: Monad: Implementați un model optimist de execuție paralelă compatibil cu EVM prin detectarea conflictelor de scriere și rulare amânată, construiți grafice de dependență după finalizarea consensului și programați execuția în mai multe fire de execuție. MegaETH: Abstractizează fiecare cont/contract într-o micro-VM independentă și implementează programarea paralelă la nivel de cont foarte decuplată, bazată pe mesagerie asincronă și grafice dependente de stare. Pharos: Construiți o arhitectură de rețea rollup pentru a realiza procesarea paralelă la nivel de sistem între procese prin conducte asincrone și module SPN. Reddio: Folosește arhitectura zkRollup + GPU pentru a accelera procesul de verificare off-chain al zkEVM prin generarea SNARK în lot și pentru a îmbunătăți debitul de verificare. Acesta din urmă scapă complet de limitările compatibilității Ethereum și reproiectează paradigma de execuție din mașina virtuală, modelul de stare și mecanismul de programare pentru a obține concurență nativă de înaltă performanță. Subclasele tipice includ: Solana (SVM): Pe baza revendicărilor de acces la cont și a programării graficului de conflict static, reprezintă un model de execuție paralelă la nivel de cont. Sui / Aptos (sistem MoveVM): Bazat pe modelul obiectului de resurse și sistemul de tipuri, acceptă analiza statică în timpul compilării și realizează paralelismul la nivel de obiect. Sei V2 (ruta Cosmos SDK): introduce un motor de potrivire multi-threaded și optimizarea concurenței mașinilor virtuale în arhitectura Cosmos, care este potrivită pentru aplicații tranzacționale de înaltă frecvență. Combustibil (arhitectura UTXO + Sway): paralelism la nivel de tranzacție prin analiza statică a setului de intrări UTXO, combinând un strat de execuție modular cu un limbaj de contract inteligent personalizat Sway; În plus, ca un sistem paralel mai generalizat, modelul Actor construiește o paradigmă de execuție on-chain de "operare independentă multi-agent + colaborare bazată pe mesaje" printr-un mecanism asincron de programare a proceselor bazat pe Wasm sau VM personalizate. Printre proiectele reprezentative se numără: AO (Arweave AO): construiește un sistem de microkernel asincron on-chain bazat pe timpul de execuție a agentului bazat pe stocare persistentă. ICP (Internet Computer): utilizează agentul containerizat (Canister) ca cea mai mică unitate pentru a realiza o execuție asincronă și foarte scalabilă prin coordonarea subrețelei. Cartesi: Introduce sistemul de operare Linux ca un mediu de calcul off-chain pentru a oferi o cale de verificare on-chain pentru rezultate de calcul de încredere, potrivite pentru scenarii de aplicații complexe sau care necesită multe resurse. Pe baza logicii de mai sus, putem rezuma schema actuală a lanțului public de calcul paralel într-o structură de clasificare, așa cum se arată în figura următoare: Dintr-o perspectivă mai largă, sharding-ul și rollup-ul (L2) se concentrează pe scalarea orizontală prin fragmentarea stării sau execuția în afara lanțului, în timp ce lanțurile de calcul paralele (de exemplu, Monad, Sui, Solana) și sistemele orientate spre actori (de exemplu, AO, ICP) reconstruiesc direct modelul de execuție și obțin paralelism nativ în cadrul lanțului sau la nivelul sistemului. Primul îmbunătățește randamentul intra-lanț prin mașini virtuale multi-threaded, modele de obiecte, analiza conflictelor de tranzacții etc.; Acesta din urmă ia procesul/agentul ca unitate de bază și adoptă moduri de execuție bazate pe mesaje și asincrone pentru a realiza o funcționare simultană cu mai mulți agenți. În schimb, sharding-ul și rollup-urile seamănă mai mult cu "împărțirea sarcinii în mai multe lanțuri" sau "externalizarea off-chain", în timp ce modelul de lanț paralel și actor "dezlănțuie potențialul de performanță de la motorul de execuție în sine", reflectând o evoluție arhitecturală mai profundă. Calcul paralel vs arhitectură de fragmentare vs scalare rollup vs comparație a căii de scalare orientată spre actor Trebuie subliniat faptul că majoritatea lanțurilor native de arhitectură paralelă au intrat în faza de lansare a rețelei principale, deși ecosistemul general al dezvoltatorilor este încă dificil de comparat cu sistemul Solidity al sistemului EVM, dar proiectele reprezentate de Solana și Sui, cu arhitectura lor de execuție de înaltă performanță și prosperitatea treptată a aplicațiilor ecologice, au devenit lanțurile publice de bază cărora piața acordă o mare atenție. În schimb, deși ecosistemul Ethereum Rollup (L2) a intrat în stadiul de "10.000 de lanțuri simultan" sau chiar "supracapacitate", actualul lanț de îmbunătățire paralelă EVM este încă în general în stadiul de testnet și nu a fost încă verificat de mediul real al rețelei principale, iar capacitatea sa de scalare și stabilitatea sistemului trebuie încă testate în continuare. Rămâne de văzut dacă aceste proiecte pot îmbunătăți semnificativ performanța EVM și pot genera salturi ecologice fără a sacrifica compatibilitatea sau dacă pot diferenția și mai mult lichiditatea și resursele de dezvoltare ale Ethereum.

Îmi place să văd întâlnirile comunității Permabites crescând!

The Daily Degen - vineri, 18 aprilie 2025 Tendințe, Pegs, TGE's, Tech, Macro, Videoclipuri, + Proiecte noi! Mulțumiți proiectelor și tickerelor menționate: $DOLO, $ATOM, $sUSD, $BTC, $OL, $WZRD, $AERGO, $T, $EVER, $AO, @GammaSwapLabs, @TradeNeutral, @Lighter_xyz, @jigsawdefi, @PeerlessAI, @VertigoDex, @clickerxyz, @getoro_xyz Și mulțumesc conturilor gigabrain menționate cu >10 de urmăritori (asigurați-vă că le urmăriți!): @leviathan_news, @robbiepetersen_, @0xlykt, @AresLabs_xyz, @CryptoISFreedom Și vă rugăm RT/etc să sprijiniți! Link în următorul tweet 👇