Web3 Parallel Computing Track Panorama: Nejlepší řešení pro nativní škálování?

Autor: 0xjacobzhao a ChatGPT 4o"Blockchainové

trilema" "bezpečnosti", "decentralizace" a "škálovatelnosti" blockchainu odhaluje zásadní kompromis v návrhu blockchainových systémů, to znamená, že pro blockchainové projekty je obtížné dosáhnout "extrémní bezpečnosti, může se zúčastnit každý a vysokorychlostního zpracování" současně. V reakci na věčné téma "škálovatelnosti" jsou hlavní řešení škálování blockchainu na trhu rozdělena podle paradigmat, včetně:

• Škálování s vylepšeným prováděním: Zlepšuje možnosti provádění in situ, jako je paralelismus, GPU a vícejádrové
• škálování izolované od stavu: Horizontálně rozdělené stav/shard, např. shardy, UTXO a více podsítí
• Outsourcované škálování mimo řetězec: Uvedení provádění mimo řetězec, jako jsou rollupy, Škálování oddělení koprocesoru a DA
• struktury: Modulární architektura a kolaborativní operace, jako je modulový řetězec, sdílený sekvencer, Rollup Mesh
• Asynchronní souběžné škálování: Model aktéra, izolace procesu, řízený zprávami, jako je agent, vícevláknový asynchronní řetězec

  Řešení škálování blockchainu zahrnuje: paralelní výpočty v řetězci, rollup, sharding, DA modul, modulární strukturu, systém aktérů, kompresi zk proof, bezstavovou architekturu atd., pokrývající několik úrovní provádění, stavu, dat a struktury, a je kompletním systémem škálování "vícevrstvé spolupráce a kombinace modulů". Tento článek se zaměřuje na metody škálování, které jsou hlavním proudem paralelních výpočtů.

  Paralelismus v rámci řetězce, který se zaměřuje na paralelní provádění vnitroblokových transakcí/pokynů. Podle paralelního mechanismu lze jeho metody škálování rozdělit do pěti kategorií, z nichž každá představuje jinou výkonnost, vývojový model a filozofii architektury, a paralelní granularita je stále jemnější a jemnější, intenzita paralelismu je stále vyšší a vyšší, složitost plánování je stále vyšší a vyšší a složitost programování a obtížnost implementace jsou také stále vyšší a vyšší.

  • Na úrovni účtu: Představuje projekt
  • Na úrovni objektu: Představuje projekt Sui
  • Na úrovni transakce: Představuje projekt Monad, Aptos
  • na úrovni volání / MicroVM : MegaETH na úrovni instrukce
  :
  • GatlingX

  Off-chain asynchronní model souběžnosti, reprezentovaný modelem Actor / Actor, patří do jiného paradigmatu paralelních výpočtů, jako cross-chain/asynchronní systém zpráv (model neblokové synchronizace), každý agent běží nezávisle jako "proces agenta", asynchronní zprávy v paralelním režimu, řízené událostmi, žádné synchronní plánování, reprezentativní projekty jako AO, ICP, Cartesi atd.

  Známé schéma škálování souhrnných rolí nebo horizontálních oddílů patří k mechanismu souběžnosti na úrovni systému, nikoli k paralelním výpočtům v rámci řetězce. Dosahují škálování "paralelním provozováním více řetězců/prováděcích domén", spíše než zvyšováním paralelismu v rámci jednoho bloku/virtuálního počítače. Na tento typ škálovacího řešení se tento článek nezaměřuje, ale přesto jej budeme používat k porovnání podobností a rozdílů v architektonických konceptech.

  

  2. Paralelní řetězec vylepšení EVM: Prolomení hranice výkonu v kompatibilitě

  Od vývoje architektury sériového zpracování prošla Ethereum několika koly pokusů o škálování, jako je sharding, rollup a modulární architektura, ale úzké hrdlo propustnosti prováděcí vrstvy stále nebylo zásadně prolomeno. Zároveň jsou však EVM a Solidity stále platformami pro chytré kontrakty s největší vývojářskou základnou a ekologickým potenciálem. Paralelní řetězec vylepšení EVM se proto stává důležitým směrem pro nové kolo škálování a evoluce jako klíčová cesta, která bere v úvahu ekologickou kompatibilitu a zlepšení výkonu provedení. Monad a MegaETH jsou nejreprezentativnější projekty v tomto směru, počínaje odloženým prováděním a rozkladem stavu, až po vybudování architektury paralelního zpracování EVM pro scénáře s vysokou souběžností a vysokou propustností.

  Paralelní výpočetní analýza MonadMonad

  je vysoce výkonný blockchain vrstvy 1 přepracovaný pro virtuální stroj Ethereum (EVM), založený na základním paralelním konceptu zřetězení, s asynchronním prováděním na konsensuální vrstvě a optimistickou souběžností na prováděcí vrstvě Paralelní provádění) 。 Kromě toho Monad na konsensuální a úložné vrstvě představil vysoce výkonný protokol BFT (MonadBFT) a specializovaný databázový systém (MonadDB), aby dosáhl end-to-end optimalizace.

  Zřetězení: Vícestupňový mechanismus paralelního provádění potrubí

  Zřetězení je základním konceptem paralelního provádění Monad a jeho základní myšlenkou je rozdělit proces provádění blockchainu do několika nezávislých fází a zpracovat tyto fáze paralelně, aby se vytvořila trojrozměrná architektura potrubí, přičemž každá fáze běží na nezávislých vláknech nebo jádrech, aby se dosáhlo křížového blokového souběžného zpracování. Výsledkem je zvýšená propustnost a snížená latence. Mezi tyto fáze patří: Návrh, Konsensus, Realizace a Odevzdání.

  Asynchronní provádění: Konsensus – Provádění je asynchronně oddělenoNa

  tradičních řetězcích jsou konsensus transakcí a provádění často synchronní procesy a tento sériový model výrazně omezuje škálování výkonu. Monad implementuje konsensuální vrstvu asynchronní, prováděcí vrstvu asynchronní a úložiště asynchronní prostřednictvím "asynchronního provádění". Výrazně zkraťte dobu bloku a latenci potvrzení, čímž se systém stane odolnějším, zpracování segmentovanějším a využitím zdrojů.

  Základní design:

  • Proces konsensu (konsensuální vrstva) je zodpovědný pouze za třídění transakcí a neprovádí logiku kontraktu.
  • Proces provádění (prováděcí vrstva) je spuštěn asynchronně po dokončení konsensu.
  • Po dokončení konsensu okamžitě vstoupí do procesu konsensu dalšího bloku, aniž by se čekalo na dokončení provádění.

  Optimistické paralelní provádění: Optimistické paralelní prováděníTradiční

  Ethereum využívá striktně sériový model provádění transakcí, aby se předešlo konfliktům stavů. Monad na druhé straně přijímá strategii "optimistické paralelní exekuce", aby výrazně zvýšila rychlost zpracování transakcí.

  Mechanismus provádění:

  • Monad optimisticky provádí všechny transakce paralelně za předpokladu, že většina transakcí je bezstavová a bezkonfliktní.
  • Spusťte také "Detektor konfliktů", který sleduje, zda se mezi transakcemi přistupuje ke stejnému stavu (např. konflikty čtení/zápisu).
  • Pokud je zjištěn konflikt, konfliktní transakce je serializována a znovu provedena, aby byl zajištěn správný stav.

  Monad zvolil kompatibilní cestu: přesunout co nejméně pravidel EVM, dosáhnout paralelismu odložením stavu zápisu a dynamickou detekcí konfliktů během provádění, což je spíše jako výkonnostní verze Etherea, s úrovní vyspělosti, která usnadňuje migraci do ekosystému EVM, a je paralelním akcelerátorem ve světě EVM.

  Rozlišení paralelního výpočetního mechanismu MegaETH

  se liší od polohování L1 Monadu a MegaETH je umístěn jako modulární vysoce výkonná paralelní prováděcí vrstva kompatibilní s EVM, kterou lze použít jako nezávislý veřejný řetězec L1, jako vrstvu pro zlepšení provádění nebo modulární komponentu na Ethereu. Jeho hlavním cílem návrhu je dekonstruovat logiku účtu, spouštěcí prostředí a izolaci stavu do nejmenší jednotky, kterou lze nezávisle naplánovat, aby bylo dosaženo provádění s vysokou souběžností a schopnosti odezvy s nízkou latencí v rámci řetězce. Klíčovou inovací navrženou MegaETH je, že architektura Micro-VM + State Dependency DAG (směrovaný a acyklický graf stavových závislostí) a modulární synchronizační mechanismus společně vytvářejí paralelní prováděcí systém pro "intra-chain threading".

  Architektura Micro-VM: Účty jsou vlákna

  MegaETH zavádí model provádění "jeden mikro-VM na účet", který "vlákna" prováděcího prostředí a poskytuje minimální izolační jednotku pro paralelní plánování. Tyto virtuální počítače spolu komunikují prostřednictvím asynchronních zpráv namísto synchronních volání a velký počet virtuálních počítačů lze spouštět nezávisle, ukládat nezávisle a přirozeně paralelně.

  Stavová závislost DAG: plánovací mechanismus

  řízený grafy MegaETH vybudoval plánovací systém DAG založený na vztahu přístupu ke stavu účtu a systém udržuje globální graf závislostí v reálném čase a to, které účty jsou upraveny a které účty jsou načteny pro každou transakci, jsou všechny modelovány do závislostí. Bezkonfliktní transakce mohou být prováděny přímo paralelně a závislé transakce budou naplánovány a seřazeny sériově nebo odloženy v topologickém pořadí. Grafy závislostí zajišťují konzistenci stavu a neduplicitní zápisy během paralelního provádění.

  Mechanismus asynchronního provádění a zpětného volání

  MegaETH je postaven na paradigmatu asynchronního programování, podobně jako asynchronní předávání zpráv modelu Actor, aby vyřešil problém tradičních sériových volání EVM. Volání kontraktu jsou asynchronní (nerekurzivní provádění) a když je volána smlouva A -> B -> C, každé volání je asynchronní bez blokování čekání; Zásobník volání je rozšířen do grafu asynchronních hovorů. Transakční zpracování = procházení asynchronním grafem + řešení závislostí + paralelní plánování.

  Celkově vzato, MegaETH narušuje tradiční model stavového stroje EVM s jedním vláknem, implementuje zapouzdření mikrovirtuálních strojů na základě jednotlivých účtů, provádí plánování transakcí prostřednictvím grafů závislých na stavu a nahrazuje synchronní zásobník hovorů asynchronním mechanismem zasílání zpráv. Jedná se o paralelní výpočetní platformu, která je přepracována z plných dimenzí "struktury účtu→ architektury plánování → procesu provádění", což poskytuje novou myšlenku na úrovni paradigmatu pro vybudování vysoce výkonného on-chain systému nové generace.

  MegaETH si zvolil cestu refaktoringu: zcela abstrahuje účty a kontrakty do nezávislých virtuálních počítačů a uvolňuje maximální potenciál paralelismu prostřednictvím asynchronního plánování provádění. Teoreticky má MegaETH vyšší paralelní strop, ale je také obtížnější kontrolovat složitost a je to spíše superdistribuovaný operační systém v rámci konceptu Ethereum.

  

  Monad a MegaETH Oba mají odlišné designové koncepty než sharding: sharding horizontálně rozděluje blockchain na několik nezávislých podřetězců (shardů), z nichž každý je zodpovědný za část transakcí a stavu, čímž prolomí omezení jednoho řetězce a škálování na síťové vrstvě; Na druhou stranu Monad i MegaETH udržují integritu jednoho řetězce, horizontálně škálují pouze na prováděcí vrstvě a provádějí optimalizační průlomy paralelně na hranici jediného řetězce. Tyto dva představují dva směry: vertikální posílení a horizontální expanzi v cestě expanze blockchainu.

  Projekty paralelních výpočtů, jako jsou Monad a MegaETH, se zaměřují především na cestu optimalizace propustnosti, přičemž hlavním cílem je zlepšit TPS v řetězci a dosáhnout paralelního zpracování na úrovni transakce nebo účtu prostřednictvím odloženého provádění a architektur micro-VM. Pharos Network je modulární, full-stack paralelní L1 blockchainová síť a její základní paralelní výpočetní systém se nazývá "Rollup Mesh". Tato architektura podporuje prostředí více virtuálních strojů (EVM a Wasm) prostřednictvím synergie mainnetu a speciálních zpracovatelských sítí (SPN) a integruje pokročilé technologie, jako jsou důkazy s nulovou znalostí (ZK) a důvěryhodná prováděcí prostředí (TEE).

  Rollup Mesh Parallel Computing Analysis:

  1. Asynchronní zřetězení celého životního cyklu: Pharos odděluje různé fáze transakce (jako je konsensus, provádění a ukládání) a přijímá asynchronní zpracování, takže každá fáze může být prováděna nezávisle a paralelně, čímž se zlepší celková efektivita zpracování.
  2. Paralelní spouštění dvou virtuálních virtuálních počítačů: Pharos podporuje prostředí virtuálních strojů EVM i WASM, což umožňuje vývojářům vybrat správné spouštěcí prostředí pro jejich potřeby. Tato architektura se dvěma virtuálními počítači nejen zvyšuje flexibilitu systému, ale také zvyšuje zpracování transakcí prostřednictvím paralelního provádění.
  3. Speciální sítě pro zpracování (SPN): SPN jsou klíčové komponenty v architektuře Pharos, podobně jako modulární podsítě navržené pro zpracování specifických typů úloh nebo aplikací. S SPN umožňuje Pharos dynamickou alokaci zdrojů a paralelní zpracování úloh, což dále zvyšuje škálovatelnost a výkon systému.
  4. Modulární konsensus a restaking: Pharos zavádí flexibilní mechanismus konsensu, který podporuje více modelů konsensu (jako je PBFT, PoS, PoA) a umožňuje bezpečné sdílení a integraci zdrojů mezi mainnetem a SPN prostřednictvím protokolu restakingu.

  Kromě toho Pharos rekonstruuje model provádění od spodní vrstvy úložného modulu prostřednictvím Merkleova stromu s více verzemi, Delta kódování, verzovaného adresování a technologie ADS Pushdown a spouští Pharos Store, vysoce výkonný úložný engine pro nativní blockchain, aby dosáhl vysoké propustnosti, nízké latence a silných ověřitelných schopností zpracování v řetězci.

  Obecně platí, že architektura Rollup Mesh společnosti Pharos dosahuje vysoce výkonných paralelních výpočetních schopností díky modulární konstrukci a mechanismu asynchronního zpracování.

  Kromě paralelních prováděcích architektur Monad, MegaETH a Pharos také pozorujeme, že na trhu existují některé projekty, které zkoumají aplikační cestu akcelerace GPU v paralelních výpočtech EVM jako důležitý doplněk a špičkový experiment k paralelnímu ekosystému EVM. Mezi nimi jsou Reddio a GatlingX dva reprezentativní směry:

  • Reddio je vysoce výkonná platforma, která kombinuje architekturu paralelního provádění zkRollup a GPU a její jádro spočívá v rekonstrukci procesu provádění EVM a realizaci nativní paralelizace prováděcí vrstvy prostřednictvím vícevláknového plánování, asynchronního úložiště stavu a provádění transakčních dávek akcelerovaného GPU. Paralelní granularita na úrovni transakce + operační úroveň (vícevláknový prováděcí operační kód). Je navržen tak, aby zaváděl vícevláknové dávkové provádění, asynchronní načítání stavů a transakční logiku paralelního zpracování GPU (CUDA-Compatible Parallel EVM). Stejně jako Monad / MegaETH se Reddio také zaměřuje na paralelní zpracování na prováděcí vrstvě, s tím rozdílem, že prováděcí engine je rekonstruován prostřednictvím paralelní architektury GPU, navržené pro scénáře s vysokou propustností a výpočetně náročné scénáře, jako je inference AI. GatlingX,
  • který si říká "GPU-EVM", navrhuje radikálnější architekturu, která se pokouší migrovat model "sériového provádění na úrovni instrukcí" tradičních virtuálních strojů EVM na paralelní běhové prostředí nativní pro GPU. Základním mechanismem je dynamická kompilace bajtkódu EVM do paralelních úloh CUDA a provádění proudu instrukcí prostřednictvím vícejádrového GPU, aby se prolomilo sekvenční úzké hrdlo EVM na nejnižší úrovni. Paralelní členitost, která patří k paralelismu na úrovni instrukcí (ILP). Ve srovnání s paralelní granularitou Monad / MegaETH na úrovni "transakce/účtu" patří mechanismus paralelismu GatlingX k cestě optimalizace na úrovni instrukcí, která je blíže základnímu refaktoringu enginu virtuálního stroje. V současné době je ve fázi konceptu, byl zveřejněn whitepaper a architektonický náčrt, ale zatím neexistuje žádná sada SDK ani mainnet.

  Artela navrhuje diferencovaný, paralelní designový koncept. Se zavedením virtuálního stroje WebAssembly (WASM) s architekturou EVM++ mohou vývojáři dynamicky přidávat a spouštět rozšíření v řetězci pomocí programovacího modelu Aspect při zachování kompatibility s EVM. Používá granularitu vyvolání kontraktu (Function / Extension) jako minimální paralelní jednotku a podporuje injektáž rozšiřujících modulů (podobně jako "pluggable middleware"), když je kontrakt EVM spuštěn, aby bylo dosaženo logického oddělení, asynchronního vyvolání a paralelního provádění na úrovni modulu. Větší pozornost je věnována kompostovatelnosti a modulární architektuře prováděcí vrstvy. Tento koncept přináší nové nápady pro komplexní vícemodulové aplikace v budoucnosti.

  3. Nativní paralelní řetězec architektury: Prováděcí model EVM Etherea, prováděcí ontologie rekonstruovaného VM,

  přijal od počátku svého návrhu jednovláknovou architekturu "úplný transakční příkaz + sériové provádění", jejímž cílem je zajistit jistotu a konzistenci změn stavu pro všechny uzly v síti. Tato architektura má ale přirozené úzké hrdlo ve výkonu, omezuje propustnost a škálovatelnost systému. Naproti tomu nativní řetězce paralelní výpočetní architektury, jako jsou Solana (SVM), MoveVM (Sui, Aptos) a Sei v2 postavené na sadě Cosmos SDK, jsou přizpůsobeny pro paralelní spouštění ze základního návrhu a mají následující výhody:

  • Přirozené oddělení stavových modelů: Solana používá mechanismus deklarace zámku účtu, MoveVM zavádí model vlastnictví objektu a Sei v2 je založen na klasifikaci typu transakce. Je realizováno statické posuzování konfliktů a je podporováno souběžné plánování na úrovni transakce.
  • Virtuální stroje jsou optimalizovány pro souběžnost: Engine Sealevel Solana nativně podporuje vícevláknové provádění; MoveVM může provádět analýzu statického grafu souběžnosti. Sei v2 integruje vícevláknový párovací engine s paralelním modulem VM.

  Samozřejmě, že tento druh nativního paralelního řetězce také čelí výzvě ekologické kompatibility. Architektury bez EVM obvykle vyžadují nové vývojové jazyky (jako je Move a Rust) a toolchainy, které mají pro vývojáře určité náklady na migraci. Kromě toho si vývojáři musí osvojit řadu nových konceptů, jako jsou stavové přístupové modely, limity souběžnosti, životní cykly objektů atd., které kladou vyšší požadavky na pochopení prahových hodnot a vývojových paradigmat.

  3.1 Princip paralelního motoru na úrovni moře Solana a SVM

  Exekuční model Solana Sealevel je mechanismus paralelního plánování účtu, který je základním enginem používaným Solanou k realizaci provádění paralelních transakcí v rámci řetězce a dosahuje vysoce výkonné souběžnosti na úrovni chytrých kontraktů prostřednictvím mechanismu "deklarace účtu + statické plánování + vícevláknové provádění". Sealevel je první prováděcí model v oblasti blockchainu, který úspěšně implementoval souběžné plánování v rámci řetězce ve výrobním prostředí, a jeho architektonické nápady ovlivnily mnoho následných paralelních výpočetních projektů a je referenčním paradigmatem pro vysoce výkonný paralelní návrh vrstvy 1.

  Základní mechanismus:

  1. Explicitní přístupové seznamy účtů: Každá transakce musí při odesílání deklarovat příslušný účet (čtení/zápis) a systém určí, zda mezi transakcemi došlo ke konfliktu stavů.

  2. Detekce konfliktů a vícevláknové plánování

  • Pokud neexistuje žádný průnik mezi sadami účtů, ke kterým tyto dvě transakce přistupují→ lze je provádět paralelně;
  • Dochází ke konfliktu→ který se provádí sériově v závislém pořadí;
  • Scheduler přiděluje transakce různým vláknům na základě grafu závislostí.

  3. Kontext vyvolání programu: Každé volání kontraktu probíhá v izolovaném kontextu bez sdíleného zásobníku, aby se zabránilo rušení křížových volání.

  Sealevel je modul pro plánování paralelního provádění pokynů Solana, zatímco SVM je prostředí pro inteligentní provádění kontraktů postavené na Sealevelu (pomocí virtuálního stroje BPF). Společně tvoří technický základ vysoce výkonného paralelního spouštěcího systému Solana.

  Eclipse je projekt, který nasazuje virtuální počítače Solana na modulární řetězce, jako je Ethereum L2 nebo Celestia, a využívá paralelní prováděcí engine Solana jako vrstvu rollupového provádění. Eclipse je jedním z prvních projektů, který navrhuje odpojit prováděcí vrstvu Solana (Sealevel + SVM) od mainnetu Solana a migrovat ji na modulární architekturu a modulárním výstupem "super concurrent execution modelu" Solana je Execution Layer-as-a-Service, takže Eclipse také patří do kategorie paralelních výpočtů.

  Trasa Neonu je odlišná, zavádí EVM pro provoz v prostředí SVM / Sealevel. Vytvořte běhovou vrstvu kompatibilní s EVM, vývojáři mohou používat Solidity k vývoji smluv a běhu v prostředí SVM, ale provádění plánování používá SVM + Sealeve. Neon se přiklání spíše ke kategorii modulárního blockchainu než k inovacím v oblasti paralelních výpočtů.

  Celkově vzato, Solana a SVM spoléhají na prováděcí engine Sealevel a filozofie plánování založená na operačním systému Solana je podobná plánovači jádra, který je rychlý, ale relativně nepružný. Jedná se o nativní vysoce výkonný, paralelní výpočetní veřejný řetězec.

  3.2 Architektura MoveVM: Poháněná zdroji a objekty

  MoveVM je virtuální stroj s chytrými kontrakty navržený pro zabezpečení zdrojů v řetězci a paralelní provádění a jeho základní jazyk, Move, byl původně vyvinut společností Meta (dříve Facebook) pro projekt Libra, který zdůrazňuje koncept "zdroje jsou objekty" a všechny stavy v řetězci existují jako objekty s jasným vlastnictvím a životním cyklem. To umožňuje MoveVM analyzovat, zda dochází ke konfliktům stavů mezi transakcemi během doby kompilace, a implementovat statické paralelní plánování na úrovni objektů, které je široce používáno v nativních paralelních veřejných řetězcích, jako jsou Sui a Aptos.

  Model

  vlastnictví objektů SuiSchopnosti

  Sui v oblasti paralelních výpočtů pramení z jeho jedinečného přístupu k modelování stavů a statické analýze na jazykové úrovni. Na rozdíl od tradičních blockchainů, které používají globální stavové stromy, Sui vytvořil objektově orientovaný model založený na "objektu", který pracuje s lineárním typovým systémem MoveVM, aby se paralelní plánování stalo deterministickým procesem, který lze dokončit v době kompilace.

  • Objektový model je základem paralelní architektury Sui. Sui abstrahuje všechny stavy v řetězci do samostatných objektů, z nichž každý má jedinečné ID, jasného vlastníka (účet nebo kontrakt) a definici typu. Tyto objekty mezi sebou nesdílejí stav a jsou ze své podstaty izolované. Kontrakt musí explicitně deklarovat kolekci objektů zapojených při jeho volání, aby se předešlo problému spojování stavů tradičního "globálního stavového stromu" v řetězci. Tento návrh rozděluje stav v řetězci na několik nezávislých jednotek, čímž se souběžné provádění stává strukturálně proveditelným předpokladem plánování.
  • Statická analýza vlastnictví je mechanismus analýzy v době kompilace implementovaný s podporou lineárního typového systému jazyka Move. Umožňuje systému naplánovat paralelní provádění transakcí tím, že před provedením odvodí, které transakce nemají konflikty stavů, prostřednictvím vlastnictví objektu. Ve srovnání s detekcí konfliktů a návratem tradičních běhových prostředí mechanismus statické analýzy Sui výrazně snižuje složitost plánování a zároveň zlepšuje efektivitu provádění, což je klíčem k dosažení vysoké propustnosti a možností deterministického paralelního zpracování.

  Sui rozděluje stavový prostor na základě objektu po objektu v kombinaci s analýzou vlastnictví v době kompilace, aby bylo dosaženo nízkonákladového paralelního provádění na úrovni objektu bez vrácení zpět. Ve srovnání se sériovým prováděním nebo detekcí za běhu tradičních řetězců dosáhla společnost Sui významného zlepšení efektivity provádění, determinismu systému a využití zdrojů.

  Mechanismus provádění bloků STM společnosti AptosAptos

  je vysoce výkonný blockchain vrstvy 1 založený na jazyce Move a jeho schopnost paralelního provádění je odvozena především od vlastního vyvinutého rámce Block-STM (Block-level Software Transactional Memory). Na rozdíl od Suiovy strategie "statického paralelismu v době kompilace", Block-STM patří k dynamickému plánovacímu mechanismu "optimistická souběžnost za běhu + konfliktní rollback", který je vhodný pro práci s transakčními sadami se složitými závislostmi.

  Block-STM rozděluje provádění transakce bloku do tří fází:

  • Spekulativní provádění: Všechny transakce jsou ve výchozím nastavení před provedením bezkonfliktní a systém plánuje transakce paralelně s více vlákny, aby se pokusily provést současně, a zaznamenává stav účtu (sada pro čtení a zápis), ke kterému přistupují.
  • Fáze ověřování: Systém ověří výsledek provedení: pokud dojde ke konfliktu čtení a zápisu mezi dvěma transakcemi (například Tx1 čte stav zápisu pomocí Tx2), jedna z nich se vrátí zpět.
  • Fáze opakování: Konfliktní transakce budou přeplánovány, dokud nebudou vyřešeny jejich závislosti, a nakonec všechny transakce vytvoří platnou, deterministickou posloupnost odeslání stavu.

  Block-STM je dynamický exekuční model "optimistického paralelismu + rollbacku a opakování", který je vhodný pro stavově náročné a logicky složité scénáře dávkového zpracování transakcí v řetězci a je paralelním výpočetním jádrem pro Aptos k vybudování vysoce všestranného a vysoce výkonného veřejného řetězce.

  

  Solana je inženýrská plánovací škola, spíše jako "jádro operačního systému", vhodné pro jasné hranice států, kontrolovatelné vysokofrekvenční obchodování, je styl hardwarového inženýra, který provozuje řetězec jako hardware (paralelní provádění na hardwarové úrovni); Aptos je systémově odolný proti chybám, spíše jako "databázový souběžný engine", vhodný pro smluvní systémy se silným stavovým propojením a komplexními call chainy. Aptos a Sui jsou jako inženýři programovacích jazyků a zabezpečení zdrojů na softwarové úrovni představuje cestu technické implementace paralelních výpočtů Web3 podle různých filozofií.

  3.3 Cosmos SDK Parallel Scaling

  Sei V2 je vysoce výkonný transakční veřejný řetězec postavený na základě Cosmos SDK a jeho schopnost paralelismu se odráží především ve dvou aspektech: vícevláknový párovací engine (Parallel Matching Engine) a optimalizace paralelního provádění vrstvy virtuálního stroje, která je navržena tak, aby sloužila scénářům transakcí v řetězci s vysokou frekvencí a nízkou latencí, jako je DEX knihy objednávek, Infrastruktura výměny v řetězci atd.

  Základní mechanismus paralelismu:

  1. Paralelní párovací engine: SEI V2 zavádí vícevláknovou cestu provádění do logiky párování objednávek, rozděluje knihu čekajících objednávek a logiku párování na úrovni vláken, takže odpovídající úlohy mezi více obchodními páry mohou být zpracovány paralelně a vyhnout se úzkému hrdlu s jedním vláknem.
  2. Optimalizace souběžnosti na úrovni virtuálních strojů: Sei V2 vytváří běhové prostředí CosmWasm s možností souběžného provádění, které umožňuje paralelní běh některých volání kontraktů bez konfliktů stavů a spolupracuje s mechanismem klasifikace typu transakce pro dosažení vyšší kontroly propustnosti.
  3. Paralelní plánování konsensu a prováděcí vrstvy: Mechanismus konsensu "Twin-Turbo" je zaveden s cílem posílit propustnost a oddělení mezi vrstvou konsensu a prováděcí vrstvou a zlepšit celkovou efektivitu zpracování bloků.

  3.4 UTXO Model Reformer Fuel Fuel

  je vysoce výkonná prováděcí vrstva navržená na základě modulární architektury Ethereum a její základní mechanismus paralelismu je odvozen od vylepšeného modelu UTXO (Unspent Transaction Output). Na rozdíl od modelu účtů Ethereum používá Fuel k reprezentaci aktiv a stavů strukturu UTXO, která je ze své podstaty státně izolovaná, což usnadňuje určení, které transakce lze bezpečně provádět paralelně. Kromě toho společnost Fuel představuje svůj vlastní vyvinutý jazyk chytrých kontraktů Sway (podobný Rustu) v kombinaci s nástroji pro statickou analýzu, aby bylo možné určit konflikty vstupů před provedením transakcí, aby bylo dosaženo efektivního a bezpečného paralelního plánování na úrovni transakcí. Jedná se o alternativní prováděcí vrstvu EVM, která vyvažuje výkon a modularitu.

  4. Model aktéra: Nové paradigma souběžného provádění

  agentů Model aktéra je paradigma paralelního provádění založené na agentovi nebo procesu, které se liší od tradičních synchronních výpočtů globálního stavu v řetězci (Solana/Sui/Monad a další scénáře "paralelního výpočtu v řetězci"), které zdůrazňuje, že každý agent má nezávislý stav a chování a komunikuje a plánuje prostřednictvím asynchronních zpráv. V rámci této architektury může být on-chain systém provozován souběžně velkým počtem procesů, které jsou od sebe odděleny, a má silnou škálovatelnost a asynchronní odolnost proti chybám. Mezi reprezentativní projekty patří AO (Arweave AO), ICP (Internet Computer) a Cartesi, které pohánějí vývoj blockchainu od exekučního motoru k "on-chain operačnímu systému", který poskytuje nativní infrastrukturu pro agenty AI, multitaskingové interakce a komplexní orchestraci logiky.

  I když je návrh modelu actor podobný shardingu, pokud jde o povrchní charakteristiky (např. paralelismus, izolaci stavu a asynchronní zpracování), tyto dva v podstatě představují zcela odlišné technické cesty a systémové filozofie. Model actor klade důraz na "víceprocesové asynchronní výpočty", kde každý agent běží nezávisle, udržuje stav nezávisle a komunikuje způsobem řízeným zprávami. Sharding je naproti tomu mechanismus "horizontálního shardingu stavu a konsensu", který rozděluje celý blockchain na několik subsystémů (shardů), které zpracovávají transakce nezávisle. Actor Models jsou ve světě Web3 spíše jako "operační systém distribuovaných agentů", zatímco sharding je strukturální řešení škálování pro možnosti zpracování transakcí v řetězci. Oba dosahují paralelismu, ale mají různé počáteční body, cíle a architektury provádění.

  4.1 AO (Arweave), superparalelní počítač na úložné vrstvěAO

  je decentralizovaná výpočetní platforma běžící na trvalé úložné vrstvě Arweave, jejímž hlavním cílem je vybudovat operační systém v řetězci, který podporuje provoz rozsáhlých asynchronních agentů.

  Základní vlastnosti architektury:

  • Architektura procesu: Každý agent se nazývá proces s nezávislým stavem, nezávislým plánovačem a logikou provádění;
  • Žádná struktura blockchainu: AO není řetězec, ale decentralizovaná vrstva úložiště + multiagentní prováděcí engine řízený zprávami založený na Arweave;
  • Systém plánování asynchronních zpráv: Procesy spolu komunikují prostřednictvím zpráv, přijímají model asynchronního provozu bez zámku a přirozeně podporují souběžné rozšiřování.
  • Trvalé úložiště stavu: Všechny stavy agentů, záznamy zpráv a pokyny jsou trvale zaznamenávány v Arweave, což zajišťuje plnou auditovatelnost a decentralizovanou transparentnost.
  • Nativní pro agenty: Je vhodný pro nasazení složitých vícekrokových úloh (jako jsou agenti AI, řadiče protokolu DePIN, automatické orchestrátory úloh atd.) a může vytvořit "koprocesor AI v řetězci".

  AO se vydává konečnou cestou "agent native + storage driver + chainless architektura", zdůrazňující flexibilitu a oddělení modulů, a je "mikrokernel framework na řetězci postaveném na vrstvě úložiště", přičemž hranice systému se záměrně zmenšují, zdůrazňující odlehčené výpočty + složitelnou řídicí strukturu.

  4.2 ICP (Internet Computer), full-stack hostingová platforma Web3ICP

  je nativní full-stack on-chain aplikační platforma Web3, kterou spustila společnost DFINITY, s cílem rozšířit výpočetní výkon v řetězci na zážitky podobné Web2 a podporovat kompletní hostování služeb, vazbu doménových jmen a bezserverovou architekturu.

  Základní vlastnosti architektury:

  • Architektura Canister (kontejnery jako agenti): Každý kanystr je agent běžící na virtuálním počítači Wasm s nezávislými možnostmi stavu, kódu a asynchronního plánování;
  • Systém distribuovaného konsensu podsítě (Subnet): Celá síť se skládá z několika podsítí, z nichž každá udržuje sadu kanystrů a dosahuje konsensu prostřednictvím mechanismu podpisu BLS.
  • Model asynchronního vyvolání: Canister komunikuje s Canisterem prostřednictvím asynchronních zpráv, podporuje neblokující provádění a má přirozený paralelismus.
  • Webhosting v řetězci: Podporuje chytré smlouvy pro přímé hostování front-endových stránek, nativní mapování DNS a je první blockchainovou platformou, která podporuje prohlížeče pro přímý přístup k dApps;
  • Systém má kompletní funkce: Má systémová rozhraní API, jako je on-chain hot upgrade, ověřování identity, distribuovaná náhodnost a časovač, což je vhodné pro komplexní nasazení služeb v řetězci.

  ICP volí paradigma operačního systému s těžkou platformou, integrovaným balením a silnou kontrolou platformy a má "blockchainový operační systém", který integruje konsensus, provádění, ukládání a přístup, klade důraz na kompletní možnosti hostování služeb a rozšiřuje hranice systému na plnohodnotnou hostingovou platformu Web3.

  Kromě toho lze projekty paralelních výpočtů jiných paradigmat modelu aktéra odkázat na následující tabulku:

  

  5. Shrnutí a výhledNa základě

  rozdílů mezi architekturou virtuálních strojů a jazykovým systémem lze řešení paralelních výpočtů blockchainu zhruba rozdělit do dvou kategorií: EVM paralelní řetězec vylepšení a nativní paralelní řetězec architektury (non-EVM).

  Na základě zachování kompatibility ekosystému EVM/Solidity dosahuje první z nich vyšší propustnosti a schopností paralelního zpracování prostřednictvím hloubkové optimalizace prováděcí vrstvy, která je vhodná pro scénáře, které chtějí zdědit aktiva Ethereum a vývojové nástroje a zároveň dosáhnout průlomů ve výkonu. Mezi reprezentativní projekty patří:

  • Monad: Implementuje optimistický model paralelního provádění kompatibilní s EVM prostřednictvím detekce konfliktů odloženého zápisu a běhu, vytváří grafy závislostí a plánuje provádění po dokončení konsensu.
  • MegaETH: Abstrahuje každý účet/kontrakt do nezávislého mikro-VM a implementuje vysoce oddělené paralelní plánování na úrovni účtu na základě asynchronního zasílání zpráv a grafů závislých na stavu.
  • Pharos: Vytvořte architekturu rollup mesh pro dosažení paralelního zpracování na úrovni systému napříč procesy prostřednictvím asynchronních kanálů a modulů SPN.
  • Reddio: Používá architekturu zkRollup + GPU k urychlení procesu ověřování mimo řetězec zkEVM prostřednictvím dávkového generování SNARK a zlepšení propustnosti ověřování.

  Ten se zcela zbavuje omezení kompatibility Etherea a přepracovává paradigma provádění z virtuálního stroje, stavového modelu a plánovacího mechanismu, aby bylo dosaženo nativní vysoce výkonné souběžnosti. Mezi typické podtřídy patří:

  • Solana (SVM): model paralelního provádění na úrovni účtu založený na nárocích přístupu k účtu a plánování statických grafů konfliktů;
  • Sui / Aptos (systém MoveVM): Na základě objektového modelu zdrojů a typového systému podporuje statickou analýzu v době kompilace a realizuje paralelismus na úrovni objektů.
  • Sei V2 (trasa sady Cosmos SDK): zavádí vícevláknový modul porovnávání a optimalizaci souběžnosti virtuálních počítačů v architektuře Cosmos, která je vhodná pro transakční vysokofrekvenční aplikace.
  • Palivo (architektura UTXO + Sway): Paralelismus na úrovni transakce prostřednictvím statické analýzy vstupní sady UTXO, kombinující modulární prováděcí vrstvu s přizpůsobeným jazykem chytrých kontraktů Sway;

  Kromě toho, jako obecnější paralelní systém, model actor vytváří paradigma provádění v řetězci "multi-agent independent operation + message-driven collaboration" prostřednictvím mechanismu plánování asynchronních procesů založeného na Wasm nebo vlastních virtuálních počítačích. Mezi reprezentativní projekty patří:

  • AO (Arweave AO): Vytvoření asynchronního systému mikrojádra v řetězci založeného na běhovém prostředí agenta řízeném trvalým úložištěm;
  • ICP (Internet Computer): používá kontejnerizovaného agenta (Canister) jako nejmenší jednotku k dosažení asynchronního a vysoce škálovatelného provádění prostřednictvím koordinace podsítě.
  • Cartesi: Představuje operační systém Linux jako off-chain výpočetní prostředí, které poskytuje on-chain ověřovací cestu pro důvěryhodné výpočetní výsledky, vhodné pro složité nebo na zdroje náročné aplikační scénáře.

  Na základě výše uvedené logiky můžeme shrnout současné běžné schéma veřejných řetězců paralelních výpočtů do klasifikační struktury, jak je znázorněno na následujícím obrázku:

  

  Z širší perspektivy škálování se sharding a rollup (L2) zaměřují na horizontální škálování prostřednictvím shardingu stavu nebo provádění mimo řetězec, zatímco paralelní výpočetní řetězce (např. Monad, Sui, Solana) a systémy orientované na aktéry (např. AO, ICP) přímo rekonstruují prováděcí model a dosahují nativního paralelismu v rámci řetězce nebo na systémové vrstvě. První z nich zlepšuje propustnost v rámci řetězce prostřednictvím vícevláknových virtuálních strojů, objektových modelů, analýzy transakčních konfliktů atd.; Ten bere proces/agenta jako základní jednotku a přijímá režimy řízené zprávami a asynchronní provádění, aby dosáhl multiagentního souběžného provozu. Naproti tomu sharding a rollupy jsou spíše jako "rozdělení zátěže do více řetězců" nebo "outsourcing mimo řetězec", zatímco model paralelního řetězce a aktéra "uvolňuje výkonnostní potenciál ze samotného prováděcího enginu", což odráží důkladnější vývoj architektury.

  Paralelní výpočty vs architektura shardingu vs rollup škálování vs porovnání cesty škálování orientované na aktéry

  

  Je třeba zdůraznit, že většina nativních řetězců paralelní architektury vstoupila do fáze spuštění mainnetu, ačkoli celkový vývojářský ekosystém je stále obtížné srovnávat se systémem Solidity systému EVM, ale projekty reprezentované Solanou a Sui s jejich vysoce výkonnou prováděcí architekturou a postupnou prosperitou ekologických aplikací se staly základními veřejnými řetězci, kterým trh věnuje velkou pozornost.

  Naproti tomu, ačkoli ekosystém Ethereum Rollup (L2) vstoupil do fáze "10 000 řetězců najednou" nebo dokonce "nadbytečné kapacity", současný hlavní proud paralelního vylepšovacího řetězce EVM je stále obecně ve fázi testovací sítě a dosud nebyl ověřen skutečným prostředím mainnetu a jeho schopnost škálování a stabilitu systému je třeba ještě dále otestovat. Teprve se uvidí, zda tyto projekty mohou výrazně zlepšit výkon EVM a podpořit ekologické skoky, aniž by byla obětována kompatibilita, nebo zda mohou dále diferencovat likviditu a vývojové zdroje Etherea.