Blokķēde, pateicoties tās decentralizētajai struktūrai, ir upurējusi efektivitāti, tāpēc izpildes ātruma palielināšana ir viena no steidzamākajām problēmām. Blokķēdes „izpildes līmenis” ir galvenā daļa, kas apstrādā katru darījumu un pievieno to ķēdei. Lai paātrinātu apstrādes jaudu, izpildes līmeņa uzlabošana ir kļuvusi par vienu no centrālajām stratēģijām, un paralēlā izpilde ir būtisks breakthroughs šajā jomā.
Tradicionālās blokķēdes parasti izmanto secīgu pieeju darījumu apstrādei, kas būtiski ierobežo darījumu ātrumu, īpaši blīvos tīklos, kas var izraisīt sastrēgumus. Tomēr, izmantojot paralēlu izpildi, vairāki darījumi var tikt apstrādāti vienlaicīgi, tādējādi ievērojami palielinot izpildes efektivitāti un samazinot slogu uz ķēdes.
Lai labāk izprastu, kas ir paralēlisms, sāksim ar izpildes ievadu un uz Ethereum pēc apvienošanas PBS modeļa piemēru, lai izskaidrotu, kas ir izpilde, kā arī parādītu izpildes vietu visā darījumu dzīves ciklā.
Darījumu izpildes specifiskie posmi
Darījums nonāk atmiņas baseinā un tiek atlasīts un kārtots: tas ir darījuma iesniegšanas priekšapstrādes posms, kurā ietilpst Mempool, Searcher un Builder mijiedarbība, pabeidzot darījumu atlasi un kārtošanu.
Builder veido bloku (bet neizpilda): Builder sakārto izdevīgus darījumus vienā blokā, lai pabeigtu darījumu iepakošanu un kārtošanu.
Proposer pārbauda un iesniedz bloku: pēc bloka izveides pabeigšanas Builder nosūta bloka priekšlikumu Proposer. Proposer pārbauda bloka struktūru un darījuma saturu, pēc tam oficiāli iesniedz bloku tīklā, lai uzsāktu izpildi.
Izpildīt darījumus: pēc bloka iesniegšanas mezgli pa vienam izpilda darījumus blokā. Tas ir stāvokļa atjaunināšanas izšķirošais posms, katrs darījums izsauc viedā līguma izsaukumu, konta bilances izmaiņas vai stāvokļa pārmaiņas.
Liecinošs liecinieks: verifikators liecina par bloka izpildes rezultātiem un stāvokļa sakni un uzskata to par galīgu apstiprinājumu. Tas nodrošina, ka bloks ir autentisks un derīgs izpildes līmenī un novērš nesakritības.
Stāvokļa sinhronizācija: katrs mezgls sinhronizēs bloka izpildes rezultātus (piemēram, konta bilances, līguma stāvokļa atjauninājumus utt.) ar savu lokālo stāvokli, pēc katra darījuma izpildes mezgls aprēķina un saglabā jaunu stāvokļa sakni, lai nākamajā blokā tā tiktu izmantota kā sākotnējais stāvoklis.
Protams, tas ir tikai darījumu stāvokļa sinhronizācija pēc blokiem, lai uzturētu jaunāko ķēdes stāvokli, parasti mezgli sinhronizē datus pa blokiem un nepārtraukti pārbauda blokos un stāvoklī. Bet, lai sasniegtu galīgumu POS mehānismā, nepieciešams, lai agregatori apvienotu katra Slot liecinieku parakstus vienā pilnīgā parakstā un nosūtītu to uz nākamo Slot priekšlikumu, un verifikatoriem pēc vienas Epoch ir jāapstiprina balsojuma skaita pamatā visu bloku stāvoklis, veidojot pagaidu konsensa stāvokļa pārbaudes punktu. Kad divi secīgi Epoch saņem lielākās daļas verifikatoru liecību atbalstu, bloki un darījumi sasniedz galīgumu.
Darījumu visā dzīves ciklā izpilde notiek pēc tam, kad Proposer ir pārbaudījis Builder nosūtīto bloku struktūru un darījumu saturu. Faktiskajā izpildes procesā ir nepieciešams apstrādāt katru darījumu un atjaunināt attiecīgos kontus vai līguma stāvokli. Pabeidzot visus darījumus, Proposer aprēķina jaunu stāvokļa sakni (Merkel sakni), kas ir pašreizējā bloka visu darījumu izpildes rezultātu un galīgā globālā stāvokļa kopsavilkums. Vienkāršoti sakot, pilnīgs bloka izpildes process ietver virkni aprēķinu, kas nepieciešami, lai pārvērstu Ethereum no iepriekšējā stāvokļa uz nākamo stāvokli, sākot no katra darījuma izpildes līdz Merkle saknes aprēķināšanai.
Secīga izpilde
Pretstatā paralēlai izpildei ir secīga izpilde, kas ir pašreizējā blokķēdes vispārpieņemtā izpildes pieeja. Parasti darījumi tiek izpildīti secīgi. Pabeidzot darījumu izpildi, Ethereum atjaunina konta stāvokli un attiecīgo informāciju (piemēram, bilanci, līguma uzglabāšanas datus) konta stāvokļa kokā, radot jaunu konta stāvokļa hash. Pabeidzot visus konta stāvokļa koka atjauninājumus, tiek izveidots stāvokļa Merkle saknes hash. Pabeidzot stāvokļa Merkle sakni, darījumu Merkle sakni un apliecinājumu Merkle sakni, bloka galva tiek hashēta, radot šī bloka bloka hash.
Un šajā starpā darījumu izpildes secība ir izšķiroša. Tā kā Merkle koks ir hash vērtību binārais koks, atšķirīgas secības dēļ izveidotie Merkle saknes vērtības būs atšķirīgas.
Paralēlā izpilde
Paralēlas izpildes vidē mezgli mēģinās paralēli apstrādāt darījumus blokā. Tie netiek izpildīti secīgi, bet tiek sadalīti pa dažādiem „izpildes ceļiem”, lai tos varētu izpildīt vienlaicīgi. Paralēlas izpildes rezultātā sistēma var efektīvāk apstrādāt darījumus blokā, palielinot caurlaidību.
Pabeidzot visus darījumus, mezgli apkopo izpildes rezultātus (proti, darījumu ietekmētus stāvokļa atjauninājumus), veidojot jaunu bloka stāvokli. Šis stāvoklis tiks pievienots blokķēdei, pārstāvot jaunāko globālo stāvokli uz ķēdes.
Stāvokļa konflikti
Tā kā paralēli darījumi vienlaikus apstrādā darījumus dažādos ceļos, viens no paralēlās izpildes galvenajiem izaicinājumiem ir stāvokļa konflikti. Tas nozīmē, ka var pastāvēt vairāki darījumi, kas vienlaicīgi nolasīs vai rakstīs uz blokķēdes to pašu datu daļu (stāvokli). Ja šo situāciju neapstrādā pareizi, tas var novest pie nenoteikta izpildes rezultāta. Jo atjauninājumu secība atšķiras, galīgie aprēķinu rezultāti arī atšķiras. Piemēram,
Pieņemsim, ka ir divi darījumi, darījums A un darījums B, kas abi mēģina atjaunināt viena un tā paša konta bilanci:
Darījums A: palielināt konta bilanci par 10.
Darījums B: palielināt konta bilanci par 20.
Konta sākotnējā bilance ir 100.
Ja mēs izpildām secīgi, izpildes secības rezultāts ir noteikts:
1. Vispirms izpildiet darījumu A, pēc tam izpildiet darījumu B:
Konta bilance vispirms palielinās par 10, sasniedzot 110.
Pievienot vēl 20, kopā būtu 130.
2. Vispirms izpildiet darījumu B, pēc tam izpildiet darījumu A:
Konta bilance vispirms palielinās par 20, sasniedzot 120.
Pievienojot vēl 10, kopā būtu 130.
Abās secībās galīgā bilance ir 130, jo sistēma nodrošina darījumu izpildes secības konsekvenci.
Bet paralēlas izpildes vidē darījums A un darījums B var vienlaicīgi nolasīt sākotnējo bilanci 100 un veikt savus aprēķinus:
Darījums A nolasīja bilanci 100, pēc aprēķina atjaunināja bilanci līdz 110.
Darījums B arī nolasīja bilanci 100, pēc aprēķina atjaunināja bilanci līdz 120.
Šajā gadījumā, tā kā darījumi tiek izpildīti vienlaicīgi, galīgā bilance tiek atjaunināta tikai līdz 120, nevis 130, jo darījuma A un darījuma B operācijas „pārklāja” viena otras rezultātus, radot stāvokļa konfliktu.
Šāda veida stāvokļa konflikti parasti tiek saukti par „datu pārklāšanos”, kad darījumi mēģina vienlaicīgi rediģēt to pašu datu, tie var savstarpēji pārklāt viena otras aprēķinu rezultātus, radot nepareizu galīgo stāvokli. Vēl viens stāvokļa konflikts var radīt problēmas ar izpildes secību. Tā kā vairāki darījumi pabeidz operācijas dažādos laika posmos, tas var radīt atšķirīgas izpildes secības. Atšķirīgas secības var novest pie atšķirīgiem aprēķinu rezultātiem, tādējādi padarot rezultātu nenoteiktu.
Lai izvairītos no šīs nenoteiktības, blokķēdes paralēlās izpildes sistēmas parasti ievieš dažus konfliktu noteikšanas un atjaunošanas mehānismus vai iepriekš veic darījumu atkarības analīzi, lai nodrošinātu, ka tie paralēli izpildās, neietekmējot galīgo stāvokļa konsekvenci.
Optimistiskais un noteiktais paralēlisms
Ir divas pieejas, kā rīkoties ar iespējamiem stāvokļa konfliktiem: noteikta paralēlismā un optimistiska paralēlismā. Šīm divām pieejām ir savi kompromisi attiecībā uz efektivitāti un dizaina sarežģītību.
Noteikta paralēlismā ir nepieciešama iepriekšēja stāvokļa piekļuves deklarācija, verifikators vai sekvenceris pārbaudīs deklarētās stāvokļa piekļuves. Ja vairāki darījumi mēģina rakstīt uz to pašu stāvokli, šie darījumi tiks atzīti par konfliktiem, lai izvairītos no vienlaicīgas izpildes. Atšķirīgas ķēdes īsteno iepriekšēju stāvokļa piekļuves deklarācijas formas, bet parasti tās ietver šādas metodes:
Izmantojot līguma specifikācijas ierobežojumus: izstrādātāji tieši nosaka stāvokļa piekļuves robežas viedajos līgumos. Piemēram, ERC-20 žetonu pārsūtīšanai ir nepieciešama piekļuve sūtītāja un saņēmēja bilances laukiem.
Izmantojot darījumu strukturēto datu deklarāciju: darījumā pievienojot speciālus laukus, lai apzīmētu stāvokļa piekļuvi.
Izmantojot kompilatora analīzi: augsta līmeņa valodu kompilatori var veikt statisku līguma koda analīzi, automātiski ģenerējot stāvokļa piekļuves kopumu.
Izmantojot ietvaru piespiedu deklarāciju: daži ietvari prasa izstrādātājiem skaidri norādīt piekļuvi nepieciešamo stāvokli, kad tiek izsaukta funkcija.
Optimistiskais paralēlisms vispirms optimistiski apstrādā darījumus, un, kad rodas konflikti, atkal secīgi izpilda ietekmētus darījumus. Lai pēc iespējas izvairītos no konfliktu situācijām, optimistiskā paralēlisma pamatā ir ātra stāvokļa prognozēšana un hipotēzes, izmantojot vēsturiskos datus, statisko analīzi utt. Tas ir, sistēma pieņem, ka noteiktas operācijas vai stāvokļa atjauninājumi ir derīgi, cenšoties izvairīties no visu verifikācijas procesu gaidīšanas, tādējādi uzlabojot veiktspēju un caurlaidību.
Lai gan optimistiskais paralēlisms var ātri prognozēt un pieņemt, lai cik iespējams izvairītos no konfliktu rašanās, tomēr pastāv arī daži neizbēgami izaicinājumi, īpaši, ja runa ir par līgumu izpildi vai starp ķēdes darījumiem, ja konflikti bieži notiek, atkārtota izpilde var būtiski palēnināt sistēmas veiktspēju un palielināt aprēķinu resursu patēriņu.
Noteiktā paralēlismā ir nepieciešama iepriekšēja stāvokļa pieejas deklarācija, verifikators vai sekvenceris pārbaudīs deklarēto stāvokļa piekļuvi darījumu kārtošanas laikā. Ja vairāki darījumi mēģina rakstīt uz to pašu stāvokli, šie darījumi tiks atzīti par konfliktiem, lai izvairītos no vienlaicīgas izpildes. Atšķirīgas ķēdes īsteno iepriekšēju stāvokļa piekļuves deklarācijas formas, bet parasti tās ietver šādas metodes:
EVM paralēlisms izaicinājumi
Attiecībā uz stāvokļa konfliktiem ir ne tikai noteikta un optimistiska pieeja, bet arī konkrētajā paralēlās izpildes procesā ir jāņem vērā blokķēdes datu bāzes arhitektūras aspekts. Stāvokļa konflikti paralēlismā, īpaši EVM ar Merkle koku struktūru, ir īpaši grūti. Merkle koks ir hierarhiska hash struktūra, un katru reizi, kad darījums maina kādu stāvokļa datu, Merkle koka saknes hash vērtība ir jāatjaunina. Šis atjaunināšanas process ir rekursīvs, aprēķinot no lapu mezgliem uz augšu līdz saknei. Tā kā hash ir neatgriezenisks, tas nozīmē, ka augstāka līmeņa aprēķini var tikt veikti tikai pēc tam, kad apakšējā līmeņa datu izmaiņas ir pabeigtas, šī īpašība apgrūtina paralēlu atjaunināšanu.
Ja divi darījumi tiek izpildīti paralēli un piekļūst tai pašai stāvokļa daļai (piemēram, konta bilance), tas radīs Merkle koka mezglu konfliktu. Šādu konfliktu risināšana parasti prasa papildu darījumu pārvaldības mehānismus, lai nodrošinātu, ka visos zaros tiek iegūta konsekventa saknes hash vērtība. EVM to var būt grūti īstenot, jo tam ir jāizdara kompromiss starp paralelizāciju un stāvokļa konsekvenci.
Ne EVM paralēlie risinājumi
Solana
Atšķirībā no Ethereum globālā stāvokļa koka, Solana izmanto kontu modeli. Katrs konts ir neatkarīga uzglabāšanas vieta, kas tiek glabāta grāmatā, tāpēc tiek novērsta ceļu konflikti.
Solana ir noteikta paralēlismā. Solana katram darījumam ir jānorāda iesniegšanas laikā, kādus kontus un nepieciešamās piekļuves tiesības (tikai lasīšanai vai lasīšanai/rakstīšanai) tas apstrādās. Šis dizains ļauj blokķēdes mezgliem iepriekš analizēt katra darījuma nepieciešamās piekļuves resursus pirms izpildes. Tā kā darījumi pirms izpildes ir skaidri norādījuši visas kontu atkarības, mezgli var noteikt, kuri darījumi piekļūs tādiem pašiem kontiem un kuri darījumi var tikt droši paralēli izpildīti, tādējādi īstenojot inteliģentu grafiku, izvairoties no konfliktiem un nodrošinot paralēlas izpildes pamatus.
Tā kā katrs darījums izpildes pirms ir deklarējis piekļuves nepieciešamos kontus un atļaujas, Solana var pārbaudīt, vai starp darījumiem pastāv kontu atkarības (Sealevel modelis). Ja darījumu starpā nav kopīgu lasīšanas un rakstīšanas kontu, sistēma var tos piešķirt dažādiem procesoriem paralēlai izpildei.
Aptos
Aptos paralēlās izpildes dizains būtiski atšķiras no Ethereum, tas ir veicis dažas svarīgas inovācijas arhitektūrā un mehānismā, galvenokārt attiecībā uz kontu modeli un stāvokļa glabāšanu.
Ethereum izpildes laikā ir nepieciešams bieži atjaunināt globālo stāvokļa koku (MPT). Visi konti un līguma stāvokļi tiek glabāti kopīgā stāvokļa kokā, un jebkuram darījumam ir jāpiekrīt un jāatjaunina šī koka daļa. Savukārt Aptos, sadalot kontus neatkarīgās stāvokļa vienībās, katrs objekts ir neatkarīgs atslēgas un vērtības pāris, objekti var pastāvēt neatkarīgi, un tie saistīsies tikai tad, ja būs skaidri norādīta atsauce. Objektiem nav kopīgu koka ceļu, tāpēc nav slēgšanas konkurences, un tie var pilnībā paralēli izpildīties.
Aptos pamatā esošā datu struktūra ir Jellyfish Merkle Tree. Katrs objekts galu galā tiek uzglabāts JMT kā neatkarīga atslēgas un vērtības pāra. Atšķirībā no Ethereum MPT, Jellyfish Merkle Tree ir pilnīgas binārās koka struktūras formā, kas vienkāršo mezglu uzglabāšanas ceļus un vaicājumu ceļus, ievērojami samazinot verifikācijas laiku. Turklāt katra konta pozīcija kokā ir fiksēta, un koka mezgli tiek neatkarīgi uzglabāti, ļaujot vairākām kontu atjauninājumiem un meklējumiem noritēt paralēli.
Aptos ir optimistiska paralēlismā, un tam nav nepieciešams iepriekš sniegt deklarācijas par visiem kontu atkarībām. Tāpēc Aptos izmanto Block-STM, Block-STM izmanto iepriekš noteiktu darījumu secību, lai novērtētu atkarības, tādējādi samazinot pārtraukumu skaitu.
Paralēlais EVM
Salīdzinājumā ar ne EVM paralēliem risinājumiem, paralēlais EVM saskaras ar lielākiem tehniskajiem izaicinājumiem, risinot stāvokļa atkarības, konfliktu noteikšanas, gāzes pārvaldības un atjaunošanas mehānismus. Lai labāk izprastu šo jautājumu, mēs varam atsaukties uz dažiem paralēlajiem EVM projektiem (piemēram, Sui, Monad, Canto), kas risina šīs problēmas.
Sui
Sui, tāpat kā Aptos, izmanto objektu modeli, lai apstrādātu stāvokli, katru objektu (piemēram, kontu, viedā līguma stāvokli) izmantojot kā neatkarīgu resursu, šie objekti tiek atšķirti ar unikāliem identifikatoriem. Kad darījumi attiecas uz dažādiem objektiem, šos darījumus var apstrādāt paralēli, jo tie darbojas ar dažādiem stāvokļiem, neradot tiešus konfliktus.
Lai gan Sui izmanto objektu modeli stāvokļa pārvaldīšanai, lai gan, lai saderētu ar EVM, Sui arhitektūra izmanto papildu pielāgošanas slāni vai abstrakcijas mehānismu, lai savienotu objektu modeli un EVM kontu modeli.
Sui izmanto optimistisku paralēlismu darījumu plānošanā, pieņemot, ka darījumu starpā nav konfliktu. Ja konflikts notiek, sistēma izmanto atjaunošanas mehānismu, lai atjaunotu stāvokli.
Sui izmanto objektu modeli un stāvokļa izolācijas tehnoloģiju, kas efektīvi novērš stāvokļa atkarības problēmas. Katrs objekts ir neatkarīgs resurs, dažādi darījumi var tikt izpildīti paralēli, tādējādi palielinot caurlaidību un efektivitāti. Tomēr šīs pieejas trade-off ir objektu modeļa sarežģītība un atjaunošanas mehānisma izmaksas. Ja starp darījumiem notiek konflikti, ir nepieciešams atjaunot daļu stāvokļa, kas palielina sistēmas slogu un var ietekmēt paralēlās apstrādes efektivitāti. Salīdzinājumā ar ne EVM paralēlām sistēmām (piemēram, Solana), Sui prasa vairāk aprēķinu un uzglabāšanas resursu, lai uzturētu efektīvu paralēlismu.
Monad
Tāpat kā Sui, Monad izmanto optimistisku paralēlismu. Bet Monad optimistiskais paralēlisms pirms faktiskās darījumu izpildes, tomēr veiks prognozes par dažiem darījumiem ar atkarībām, prognozes galvenokārt tiek veiktas, izmantojot Monad statisko koda analīzi. Prognozēm ir nepieciešama piekļuve stāvoklim, bet Ethereum datu bāzes stāvokļa glabāšanas veids padara stāvokļa piekļuvi ļoti grūtu, lai padarītu paralēlo izpildi efektīvāku stāvokļa lasīšanas procesā, Monad arī pārveidoja datu bāzi.
Monad stāvokļa koks ir sadalīts pēc apgabaliem, katrs apgabals uztur savu stāvokļa apakškoku. Atjaunināšanas laikā jāmaina tikai attiecīgā daļa, nav nepieciešams pārbūvēt visu stāvokļa koku. Ar stāvokļa indeksu tabulēm ātri var atrast stāvokli apgabalā, samazinot mijiedarbību starp apgabaliem.
Kopsavilkums
Paralēlo izpildes pamatā ir vairāku ceļu izpilde, lai palielinātu izpildes līmeņa efektivitāti, un, lai īstenotu vairāku ceļu izpildi, blokķēdei ir jāveic virkni procesu, piemēram, konfliktu noteikšana un atjaunošanas mehānisms, lai nodrošinātu, ka tās tiek izpildītas paralēli, neietekmējot galīgās stāvokļa konsekvenci, un veikt noteiktas uzlabojumus datu bāzē.
Protams, izpildes līmeņa efektivitātes uzlabošana neaprobežojas tikai ar paralēlo izpildi, izpildes posma optimizācija var notikt arī samazinot katra darījuma nepieciešamās lasīšanas un rakstīšanas operācijas datu bāzē. Bet visa ķēdes ātruma paaugstināšana ietver plašāku jomu, tostarp konsensa līmeņa efektivitātes uzlabošanu.
Katras tehnoloģijas pamatā ir specifiskas ierobežojumu nosacījumi. Paralēlisms ir tikai viens no efektivitātes palielināšanas veidiem, un galīgais lēmums par šīs tehnoloģijas izmantošanu ir jāņem vērā, vai tā ir draudzīga izstrādātājiem, vai to var īstenot, neupurējot decentralizāciju utt. Tehnoloģiju slāņošanas princips nav vienmēr labāks, vismaz attiecībā uz Ethereum paralēlisms nav tik pievilcīgs, ja ņem vērā tikai efektivitātes uzlabošanu, pievienošana paralēlismam nav optimāls risinājums Ethereum, ņemot vērā gan vienkāršību, gan pašreizējo Ethereum Rollup centrālo ceļu.