Starknet Bolt jauninājuma izpakošana

Starknet jaunākais jauninājums (v0.13.2) ar nosaukumu Bolt ienes divas būtiskas izmaiņas: paralēlo izpildi un bloku iepakošanu . Lai gan abas funkcijas ir neatkarīgas viena no otras, tās atbalsta virzību uz ātru, lētu bloktelpu, ko kriptogrāfiski nodrošina Ethereum.

Paralēlā izpilde ļauj vienlaikus izpildīt darījumus, kas nav strīdīgi (ti, darījumi, kas nesaskaras ar vienu un to pašu stāvokli). Ieviešot paralēlo izpildi, L2, piemēram, Starknet, var samazināt izpildes laiku, nepalielinot resursu izmantošanu. Tas nozīmē zemāku darījumu maksu lietotājiem un ievērojami uzlabotu darījumu apstiprināšanas laiku.

Bloku pakotne optimizē Starknet blobspace izmantošanu Ethereum L1: izmantojot bloku pakotni, sekvenceri var ģenerēt vienu pierādījumu, lai vienlaikus pārbaudītu vairākus Starknet L2 blokus. Tas atdala blobspace izmantošanu no L2 bloku ražošanas biežuma un amortizē pierādījumu pārbaudes izmaksas. Abi samazina Starknet sekvencēra darbības izmaksas, kas nozīmē, ka lietotāji maksā mazāk par darījumu.

Kā jau teicām, Bolt padara Starknet lētāku un ātrāku! Šis ziņojums sniegs detalizētu Bolt jauninājuma analīzi, koncentrējoties uz paralēlu izpildi un bloku iepakošanu, un izpētīs ietekmi uz Starknet veiktspēju.

Ātra atsvaidzināšana par apkopojumiem

Apkopojumi ir otrā slāņa (L2) mērogošanas risinājumi , kuru mērķis ir mērogot pamata pirmā slāņa (L1) blokķēdi, pārvietojot aprēķinu ārpus ķēdes. Pārvietojot izpildi ārpus ķēdes, apkopojumi var optimizēt mērogojamību (lēti un ātri darījumi), savukārt L1 nodrošina drošību L2 darījumiem.

Bieži tiek teikts, ka apkopojumi “manto drošību no L1”. Tas būtībā nozīmē, ka viņi manto L1 sniegtās vienprātības un datu pieejamības garantijas. Papildus tam L1 nodrošina arī drošības garantiju drošas savienošanas veidā starp to un rollup.

Kad sekvencētāji publicē L2 blokus L1, L1 nodrošina šīs informācijas pieejamības garantijas, kā arī šīs informācijas secību. No šejienes L2 mezgli var neuzticami aprēķināt kanonisko L2 ķēdi, izmantojot šo informāciju, kā arī apkopojuma noteikumus par ķēdes atvasināšanu un stāvokļa pāreju, ko apraksta mezgla ieviešana.

Lai veicinātu drošu savienošanu starp L1 un L2, L1 ir nepieciešams pierādījums, ka L2 ķēde, kurai tas pašlaik seko, ir pareiza un neietver nelikumīgas stāvokļa izmaiņas (piemēram, dubultā tēriņa). Šī nepieciešamība pēc apkopojumiem, lai pierādītu stāvokļa izmaiņu derīgumu, nodrošina, ka L1 neatļauj izņemšanu no apkopojuma, pamatojoties uz nelikumīgu stāvokli.

Apkopojumi atšķiras atkarībā no tā, kā tie pierāda L1 stāvokļa izmaiņu derīgumu.

• Derīguma apkopojumi balstās uz derīguma pierādījumiem, lai objektīvi pārbaudītu izpildes pareizību. Priekšlikumu iesniedzējiem ir atļauts ierosināt jaunu apkopojuma stāvokli, ja viņi iesniedz apkopojuma līguma derīguma apliecinājumu.
• Optimistiski apkopojumi balstās uz krāpšanas pierādījumu neesamību, lai subjektīvi pārbaudītu izpildes pareizību. Priekšlikumu iesniedzēji iesniedz stāvokļa atjauninājumus bez pierādījumiem, bet apkopojuma līgums var atsaukt jebkuru stāvokļa atjauninājumu, kura derīgums ir veiksmīgi apstrīdēts ar krāpšanas pierādījumu.

Apkopojumi arī nodrošina bāzes slāni ar pietiekami daudz datu, lai ieinteresētās puses varētu rekonstruēt L2 stāvokli. Lai gan optimistiskajiem apkopojumiem ir jāpublicē visi darījumu dati, lai ļautu izaicinātājiem aprēķināt krāpšanas pierādījumus, derīguma apkopojumiem šādu prasību nav (derīguma apliecinājumi garantē pareizu izpildi). Taču pilnu darījumu datu publicēšana L1 joprojām ir noderīga no uzticības samazināšanas perspektīvas (stāvokļa bezuzticamības rekonstrukcija un neatļauta izņemšana).

Starknet ir derīguma apkopojums, kas izmanto S mērogojamu, T caurspīdīgu K nowledge (STARK) AR , lai pierādītu stāvokļa izmaiņu derīgumu. Jaunākais Starknet jauninājums ar koda nosaukumu Bolt pievieno paralēlu izpildi un bloku iesaiņošanu. Nākamajās sadaļās mēs paskaidrosim, kā darbojas abas funkcijas un kādus uzlabojumus tās sniedz Starknet lietotājiem.

Ko mainīja Starknet Bolt jauninājums?

Augstā līmenī Bolt jauninājums mainīja Starknet izpildes, pierādīšanas un datu pieejamības mehānismus.

Izpildes optimizēšana

Pirms Bolt jaunināšanas Starknet transakcijas secīgi — vienu pēc otras — veica sekvencētājs. Secīgā izpilde ir vienkārša, bet arī ļoti neefektīva. Tas ir neefektīvs, jo neizmanto vairākas neatkarīgas apstrādes vienības, ko piedāvā mūsdienu datori, un darījumu kopas paralelizējamību.

Paralēlizējamība ir mērījums tam, cik neatkarīgi ir darījumi noteiktā kopā. Piemēram, apsveriet tālāk norādīto trīs darījumu kopu.

• 1. darījums: Alise vēlas nosūtīt Bobam 1 STRK

• 2. darījums: Keitlina vēlas nosūtīt Denijam 100 ETH

• 3. darījums: Keitlina vēlas nosūtīt Ellai 100 ETH

  
  

1. darījums ir pilnīgi neatkarīgs no 2. un 3. darījuma, jo tas piekļūst citai štata daļai (Alises bilancei) un var tikt izpildīts vienlaikus. Tomēr 2. un 3. darījums ir pretrunīgi, jo tie vēlas piekļūt vienam un tam pašam stāvoklim — Keitlinas ETH bilancei. Šos darījumus nevar veikt vienlaikus, pretējā gadījumā mēs saņemsim pretrunīgus rezultātus.

Lai ilustrētu:

• Pieņemsim, ka Keitlinas atlikums ir 300 ETH un 2. un 3. darījumi sākas vienlaikus. Abi darījumi nolasīs Keitlinas konta sākotnējo atlikumu kā 300 ETH, no tā atskaitīs pārskaitījuma summu (300 - 100 = 200) un ierakstīs 200 ETH uz vietu atmiņā, kur tiek glabāts Keitlinas konta atlikums.
• Pēc tam 2. un 3. darījumos tiks nolasīti attiecīgi Denija un Ellas atlikumi un abu lietotāju atlikumiem tiks pievienoti 100 ETH. Keitlinas atlikums samazinātos par 100 ETH, bet tiktu ieskaitīti 200 ETH, kas faktiski izdrukātu 100 ETH no zila gaisa.

Izvairīšanās no šāda veida konfliktiem (un mazināšanas mehānismu sarežģītā rakstura) ir iemesls, kāpēc Ethereum izvēlējās secīgu izpildi. Tomēr, lai gan secīgā izpilde samazina sarežģītību un uzlabo drošību, tā rada neefektīvu aparatūras izmantošanu. Vēl ļaunāk, aparatūras dizaina tendence liecina, ka turpmākajos gados secīgā izpilde kļūs arvien neefektīvāka.

4. attēlā parādīta aparatūras dizaina tendence pēdējo 50 gadu laikā. Attiecīgais takeaway? Viena pavediena veiktspēja (purpursarkani apļi) kopš 2000. gadu vidus ir nemainīga, savukārt loģisko kodolu skaits tajā pašā laikā ir palielinājies. Balstoties uz šiem datiem, varam izdarīt divus secinājumus:

• Aparatūras dizaineri mērogo datoru mikroshēmas, pievienojot vairāk neatkarīgu apstrādes vienību, nevis uzlabojot vienas vienības veiktspēju.

• Jebkura sistēma, kas turpina paļauties uz vienas procesora vienības palielinātu veiktspēju, piedzīvos veiktspējas pieauguma apstāšanos pat jaunākai aparatūrai.

  
  

Pēdējos gados ir parādījušies sarežģīti algoritmi darījumu konfliktu pārvaldīšanai un paralēlās izpildes pareizības nodrošināšanai. Block-STM (pamatojoties uz Fikunmi et al* rakstu) ir viens no šādiem algoritmiem un veido Starknet jaunā paralēlās izpildes dzinēja galveno daļu. Mēs analizēsim Block-STM algoritmu turpmākajās sadaļās.

Pierādīšanas un datu pieejamības optimizēšana

Starknet's SHARP (saīsinājums no Shared Prover) vienmēr ir izmantojis rekursīvos pierādījumus, lai pēc iespējas samazinātu verifikācijas izmaksas. Rekursīvs pierādījums būtībā ir “pierādījuma pierādījums”, kurā viens pierādījums pārbauda, vai viens vai vairāki pierādījumi ir pareizi. Zemāk ir skice, kā SHARP ģenerē rekursīvu pierādījumu:

• SHARP sistēma izmanto izpildāmo programmu kopu (“darbu”) kā ievadi un ģenerē darba izpildes apliecinājumu. Šīs “programmas” ir L2 bloki, un pierādījumi apliecina darījumu pareizību.

• Pierādījums tiek nosūtīts citai programmai, kas pārbauda pierādījumu un pārvērš pierādījumu pārbaudes programmu darbā. SHARP izmanto jauno darbu kā ievadi un ģenerē citu pierādījumu (šis pierādījums apstiprina iepriekšējā pierādījuma derīgumu).

• Process (pierādījums → uzdevums → pierādījums) tiek atsākts un turpinās, līdz tiek sasniegts mērķis, un tad galīgais pierādījums (kas tagad ir ļoti saspiesta sākotnējā pierādījuma versija) tiek ievietots L1.

  
  

Šis dizains ievērojami amortizē izmaksas divu galveno iemeslu dēļ:

• Turpmākie darbi* nav atsevišķas programmas vai darījumi, un pierādīšanas izmaksas pieaug sublineāri. Tas nozīmē, ka jo lielāks ir programmu/darījumu skaits vienā darbā, jo lielāki ietaupījumi. Izveidojot pierādījumus par bloku, nevis par katru darījumu, darījumu maksas var būt daudz lētākas.
• Rekursija ievērojami saspiež pierādījumus, kā rezultātā tiek iegūts “pierādījuma pierādījums”, kuru L1 pārbaudīt ir ievērojami lētāk nekā sākotnējo pierādījumu vai jebkuru no starppierādījumiem.

Lai gan pierādīšanas sistēma bija laba, tika zaudētas iespējas vēl vairāk ietaupīt izmaksas. Piemēram, katrs darbs bija viens Starknet bloks, un katrs no šiem blokiem bija paredzēts, lai L1 aizņemtu vienu lāsumu. Tā rezultātā radās noteiktas neefektivitātes, kā aprakstīts tālāk:

• Pirms Bolta Starknetam nebija (un joprojām nav) regulāru bloklaiku; tā vietā L2 bloks tika publicēts L1 ar diviem nosacījumiem: (1) tika izpildīti viena lāse vērti dati (2) bija pagājušas sešas minūtes no iepriekšējā bloka. Diemžēl pieprasījuma dēļ lielākā daļa bloku tika nosūtīti uz L1 sešu minūšu ierobežojuma dēļ (nevis DA ierobežojumi).
• Iepriekš minētais nozīmēja, ka lāses (nevis bloki) bieži tika (nopietni) nepietiekami izmantotas, kā rezultātā tika nevajadzīgi augstas gāzes izmaksas. Starknet blokiem bija arī fiksētas izmaksas , kuras teorētiski varētu samazināt, izmantojot tos pašus iepriekš aprakstītos rekursijas paņēmienus, lai iegūtu vairāku bloku pierādījumus.

Bloku pakotne risina šīs problēmas, izmantojot rekursīvo pierādījumu bināro koku. Par bloku iepakošanu mēs runāsim nākamajā raksta sadaļā.

Skrūves 1. daļa: Paralēlā izpilde

Kā minēts iepriekš, secīgā izpilde ir neefektīva (un tā kļūs tikai neefektīvāka, laikam ejot), un naiva paralēlā izpilde rada nederīgus rezultātus. Tomēr ražošanas paralēlās izpildes dzinēji rūpējas, lai novērstu nekonsekventus rezultātus.

Pastāv divas pieejas paralēlas izpildes risināšanai: pesimistiskā vienlaicības kontrole (PCC) un optimistiskā vienlaicīguma kontrole (OCC) . PCC un OCC ir darījumu apstrādes vienības (TPU). Tālāk ir sniegta darījumu apstrādes vienības definīcija no Block-STM vs. SVM: Paralēlās izpildes programmu salīdzinājums:

TPU parasti ir savienots ar virtuālo mašīnu (VM), bet atšķiras no tās. Blokķēdes virtuālās mašīnas, piemēram, EVM, SVM un MoveVM, ir augsta līmeņa valodu virtuālās mašīnas… TPU, kas parasti ir intereses objekts, ietver VM. Tā uzdevums ir pārvaldīt visu darījumu izpildes cauruļvadu, tostarp izveidot un pārvaldīt virtuālās mašīnas gadījumus.

Pesimistiskā vienlaicības kontrole ir veidota, balstoties uz pieņēmumu, ka daudzi no izpildāmo darījumu kopas darījumiem konfliktēs, ti, tie skars vienu un to pašu stāvokli. PCC novērš šos konfliktus.

Lai novērstu konfliktus, PCC pieprasa, lai darījums jau iepriekš deklarētu, kurām stāvokļa daļām tas piekļūs lasīšanas/rakstīšanas darbību laikā. Darījumu apstrādes vienība var izmantot šo informāciju, lai ieplānotu darījumus tā, lai nodrošinātu, ka konfliktējošās transakcijas tiek izpildītas secīgi (nevis vienlaikus). Daži TPU izmanto arī slēdzenes, lai īstenotu šo darbību (bloķēšana (aka, mutex) ir mehānisms, ko izmanto, lai novērstu vienlaicīgu piekļuvi atmiņas vietai).

Tomēr uz PCC balstīta izpilde rada zināmus kompromisus. Pirmkārt, prasība nodrošināt piekļuves sarakstus (kas identificē atmiņas slotu, kuram pieskaras darījums) pasliktina izstrādātāja pieredzi un samazina iespējamo lietojumprogrammu klāstu. Otrkārt, darījumu plānošana var radīt nevajadzīgas pieskaitāmās izmaksas, īpaši, ja nav konfliktu.

Optimistiskā vienlaicības kontrole ir veidota ar pieņēmumu, ka daudzi darījumi dotajā kopā nekonfliktēs, ti, tie netiks ierakstīti vienā stāvoklī. Tādējādi OCC TPU izpilda darījumu kopu ar visiem pieejamajiem resursiem un tikai mēģina atklāt konfliktus. Ja tiek atklāts konflikts, konfliktā esošās transakcijas tiek izpildītas un atkārtoti pārbaudītas, līdz tiek izieta visa kopa un to var veikt.

OCC TPU nerodas pieskaitāmas izmaksas no plānošanas, tāpēc tie parasti darbojas labāk, ja ir maz konfliktu. Uz OCC balstītām darījumu apstrādes vienībām ir arī labāka izstrādātāju pieredze un plašāks lietošanas gadījumu klāsts, jo stāvokļa atkarības nav jāzina iepriekš.

Tomēr, ja darījumu kopa ir ļoti strīdīga, OCC darbojas sliktāk nekā PCC. Mēs aplūkojam TPU dizainus (daudz detalizētāk) un salīdzinām OCC un PCC pieejas mūsu rakstā par paralēlo izpildi.

Starknet jaunais TPU izmanto OCC pieeju. Precīzāk, tā ir Block-STM algoritma ieviešana. Block-STM izpilda darījumus optimistiski ar visiem pieejamajiem resursiem, pieņemot, ka neviens no tiem nekonfliktēs, un pēc izpildes pārbauda, vai vienlaikus netiek izpildīti konfliktējoši darījumi. Pirms ienirt Starknet jaunajā arhitektūrā, ir svarīgi pārskatīt dažas galvenās definīcijas:

1. Stāvoklis : stāvoklis ir objekta stāvoklis konkrētā instancē laikā. Blokķēdes kontekstā tas parasti attiecas uz atmiņas daļas vērtību, piemēram, adreses līdzsvars ir (daļa no) tās stāvokļa.
2. Serializējamība : tiek uzskatīts, ka paralēlā izpilde ir saglabājusi serializējamības īpašību, ja darījumu kopas izpilde sērijveidā un vienlaikus rada tādus pašus rezultātus.
3. Konflikts : tiek uzskatīts, ka divi darījumi konfliktē tad un tikai tad, ja vismaz viens no tiem vēlas rakstīt statusa daļā, kurai abi vēlas piekļūt (var lasīt vai rakstīt). Ja abas transakcijas nolasa tikai no stāvokļa daļas, tad konflikta nav, bet, ja vismaz viens no tiem raksta uz šo stāvokļa daļu, tad darījumus nevar izpildīt vienlaikus, nepārkāpjot serializējamību. Iepriekš mēs apskatījām piemēru Caitlyn, Denny un Ella piemērā.
4. Atkarība : tiek uzskatīts, ka darījums txj ir atkarīgs no transakcijas txi (vai atkarība no tā) tad un tikai tad, ja abas transakcijas tiek ierakstītas vienā atmiņas vietā un txj nāk aiz txi sērijas secībā. Ja txi nāk aiz txj , txi būtu atkarīgs no txj .
5. Vairāku versiju datu struktūra : vairāku versiju datu struktūra ir tāda, kurā katrai ierakstīšanai datu struktūrā tiek izveidota jauna datu struktūras versija. Tā vietā, lai mainītu vērtību vietā, tiek izveidota jauna maināmās vietas rakstīšanai specifiska versija. Vairāku versiju datu struktūru vērtība ir tāda, ka tās nodrošina ļoti vienlaicīgu lasīšanu un ierakstīšanu no viena un tā paša atmiņas reģiona. Kā tas ir noderīgi, mēs izpētīsim vēlāk.

Ja definīcijas nav pieejamas, mēs varam pāriet uz Block-STM darbību.

Kā darbojas Block-STM

Block-STM ievade ir transakciju rinda (sakārtots saraksts), šo sarakstu bieži sauc par BLOKU. Šo sarakstu var pasūtīt jebkurā veidā; vienīgā prasība ir skaidri noteikta kārtība. Tātad, ņemot vērā darījumu kopu T, kas satur transakcijas {t0…tn} , transakcijas tiek sakārtotas tā, lai {t0 > t1 > t2 … > tn} (lasīt kā t0 ir augstāka prioritāte nekā t1 , t1 ir augstāka prioritāte nekā t2 utt. .)

Izpildes procesa sākumā tiek izveidotas divas kopas — izpildes kopa E un validācijas kopa V. E izseko transakcijas, kas vēl ir jāizpilda, savukārt V izseko transakcijas, kas ir izpildītas, bet vēl ir jāapstiprina. Katrs darījums ir saistīts arī ar inkarnācijas numuru n, lai izsekotu, cik reižu tas ir izpildīts (un atkārtoti izpildīts). Kopu sākotnējais stāvoklis ir tāds, ka E satur visus darījumus un V ir tukšs, ti, E = {t0,1 > t1,1 > t2,1 > … > tn,1} un V = {} .

Izmantojot šīs sakārtotās transakciju kopas, katrs izpildei izmantotais pavediens iziet cauri trīspakāpju cilpai:

1. Atzīmējiet Gatavs
2. Atrodiet nākamo uzdevumu
3. Izpildi uzdevumu

Atzīmējiet Gatavs

Šīs darbības laikā pavediens pārbauda gan V, gan E. Ja abi ir tukši un neviens darījums netiek izpildīts, pašreizējā darījumu partija ir pilnībā izpildīta un rezultātus var saglabāt glabāšanā.

Atrodiet nākamo uzdevumu

Ja V vai E satur transakcijas, Block-STM atlasa darījumu ar zemāko indeksu (nevis iemiesojuma numuru) no abām darījumu kopām, ti, ja E satur {t1,3 , t3,1 and t5,2} un V satur {t0,1, t2,4, t4,3} , transakcijas t0 validācijas uzdevums tiktu atlasīts kā nākamais uzdevums.

Izpildi uzdevumu

Kad nākamais uzdevums ir identificēts un izvēlēts, tas tiek veikts. Šīs darbības beigās algoritms atgriežas pie Check Done. Šis process turpinās, līdz abas darījumu kopas ir tukšas.

Apskatīsim, kas notiek izpildes un validācijas laikā:

Darījuma izpildes laikā Block-STM algoritms aizpilda divas kopas (katrai transakcijai); lasīšanas kopa ( Ri,n ) un rakstīšanas kopa ( Wn,i ). Lasīšanas komplektā ir visas atmiņas vietas, no kurām transakcija nolasīja tās izpildes laikā, savukārt rakstīšanas komplektā ir visas atmiņas vietas, uz kurām tā rakstīja. Izpildes laikā transakcijas pielieto savus ierakstus vairāku versiju datu struktūrai, taču lasīšana ir nedaudz niansēta.

Blokā-STM, kad transakcija vēlas nolasīt no datu struktūras, tā pārbauda vērtību, ko ierakstījis zemākās prioritātes darījums, kuram ir augstāka prioritāte. Piemēram, ja tx1 , tx2 un tx7 visi ir ierakstīti atmiņas vietā un tx5 vēlas lasīt no šīs vietas, tas nolasa datu struktūras versiju, kas atbilst tx2 .

Tas tiek darīts, lai nodrošinātu serializējamību; tā kā tx5 jāizpilda pēc tx2 un pirms tx7 , tam ir jāizmanto tx2 rakstītās vērtības, nevis tx7 . Šajā piemērā tx7 būs jāizpilda atkārtoti, jo tam bija jālasa tx5 rakstītās vērtības, nevis tx2 vai citas augstākas prioritātes transakcijas. Ja tiktu izmantota vienas versijas datu struktūra, tx2 rakstītā vērtība nebūtu pieejama un noteikti radīsies konflikts.

Validācijas uzdevumam transakcijas lasīšanas kopa tiek salīdzināta ar pašreizējām vērtībām atmiņas vietās, no kurām tā nolasīja izpildes laikā. Piemēram, ja tx2 izpildes laikā nolasa kontu B, validācijas laikā tiek nolasīta konta B atmiņas vieta (paturot prātā lasīšanas definīciju, ko mēs noteicām iepriekš). Ja abas vērtības ir vienādas, tas nozīmē, ka tx2 izpildes laikā šajā vietā nav ierakstīts neviens augstākas prioritātes darījums (piemēram, tx0 vai tx1 ). Tā rezultātā tx2 tiek atzīmēts kā apstiprināts, bet nav droši veikt.

Darījums netiek uzskatīts par drošu, jo zemākas prioritātes darījums dažādu iemeslu dēļ var tikt izpildīts pēc darījuma apstiprināšanas. Mūsu darbības piemērā, ja tx1 pieskaras kontam B un pieskaras tam tikai pēc tam, tx2 iztur validāciju, tad tx2 ir jāizpilda atkārtoti.

Lai to nodrošinātu, ikreiz, kad darījums pabeidz izpildi, tiek atkārtoti apstiprināti visi zemākas prioritātes darījumi, kas ir izturējuši validāciju, lai nodrošinātu, ka tie nav pretrunā ar darījumu. Piemēram, ja tx1 , tx3 un tx4 ir apstiprināti un tx2 pabeidz izpildi, tx3 un tx4 ir atkārtoti jāvalidē, lai nodrošinātu, ka tie nav pretrunā ar tx2 (un tā arī ir atkarības).

Ja transakcijas validācija neizdodas, ti, vienlaikus ar to tika izpildīts augstākas prioritātes transakcija, kas raksta vienā un tajā pašā stāvoklī, tad ieraksti, ka veiktā transakcija ir netīri (jo vērtības ir nepareizas). Bet tā vietā, lai dzēstu šīs vērtības no datu bāzes. pilnībā, tie ir atzīmēti kā ESTIMATE.

ESTIMATE karodziņš norāda jebkuram transakcijas nolasījumam šajā atmiņas vietā, ka vērtības tur nav pareizas un transakcijas aptur to izpildi. Tas tiek darīts dzēšanas vietā, jo, atkārtoti izpildot darījumu, kura validācija neizdevās, visticamāk, tiks rakstīts tajās pašās atmiņas vietās, kur tika veikta iepriekšējā izpilde.

Atzīmējot atmiņas vietu kā aptuvenu, nevis dzēšot to, atkarības (darījumam, kura validācija neizdevās) var uztvert pat pirms atkārtotas izpildes, novēršot nevajadzīgas atkārtotas izpildes. Šī heiristika ievērojami samazina izšķērdēto darbu.

Saliekot to visu kopā

Pilnīgu pārskatu par to, kā Block-STM tuvojas paralēlizācijai, var apkopot šādi:

• Darījumu BLOCK sākas kā sakārtots saraksts ar skaidri definētu sērijas pasūtījumu. Šīs transakcijas tiek izpildītas uz visiem pieejamajiem resursiem prioritārā secībā.
• Izpildes laikā tiek izsekotas transakciju lasīšanas un rakstīšanas kopas, un tiek veikta lasīšana un rakstīšana no/uz vairāku versiju datu struktūru. Kad transakcija ir pabeigta, tā tiek pārbaudīta, lai nodrošinātu, ka tā netika izpildīta vienlaikus ar konfliktējošām transakcijām.
• Ja darījums iztur validāciju, tas tiek noņemts no E un V. Un, kad transakcija ir apstiprināta, visas transakcijas, kuru prioritāte ir zemāka par to, kas bija izturējusi validāciju, tiek pārplānota apstiprināšanai.
• Ja darījuma validācija neizdodas, tā tiek pārplānota izpildei. Kad visa darījumu kopa ir izpildīta un apstiprināta, visu BLOKU var droši veikt, un rezultātus var ierakstīt pastāvīgā krātuvē.

Piemērs ir parādīts zemāk:

Šis ir pārskats par to, kā darbojas Block-STM, sīkāku informāciju var atrast mūsu ziņojumā šeit un oriģinālajā Block-STM dokumentā šeit .

Kā Block-STM uzlabo Starknet veiktspēju?

Lai noteiktu Block-STM pievienošanas nozīmi, mēs veicām dažus etalonus, lai novērtētu veiktspējas uzlabojumus, ko tas nodrošina, salīdzinot ar secīgu izpildi, un rezultāti ir parādīti tālāk.

Rezultāti liecina, ka, palielinoties izmantoto pavedienu skaitam (analogi neatkarīgām apstrādes vienībām), palielinās arī veiktspēja. Uzlabojumi ir izteiktāki ar lielākiem blokiem, kas nodrošina pat 9X veiktspējas uzlabojumus, salīdzinot ar secīgu izpildi ar tikai 16 pavedieniem. Mēs atklājām, ka rezultāti ir izteiktāki ar lielākiem blokiem.

Mūsu testi liecina, ka Block-STM veiktspēja ievērojami pasliktinās ļoti strīdīgas slodzes apstākļos, taču nozares standarta praksē šādos periodos ir jāatgriežas pie secīgas izpildes. Mēs iesakām to pašu mehāniķi Starknet, lai saglabātu caurlaidspēju ļoti strīdīgās darba slodzēs. Bet kopumā Block-STM pievienošana ievērojami uzlabos un nākotnē nodrošinās Starknet.

Otrā lielākā izmaiņa, kas iekļauta jauninājumā v0.13.2, ir bloku pakotne, un mēs to aplūkosim tālāk.

Skrūves 2. daļa: Bloku blīvējums

Kā minēts iepriekš, pirms Bolt katrs Starknet bloks bija savs uzdevums, kā rezultātā katram blokam bija noteikta maksa par bloku. Turklāt sistēma tika izstrādāta tā, ka katram blokam bija nepieciešama sava lāse neatkarīgi no tā, cik daudz datu bloks faktiski patērēja.

Pasaulē, kurā vienmēr bija liels pieprasījums, tā nebūtu problēma, taču Starknet šobrīd piedāvā vairāk bloku vietas, nekā ir pieprasījums, un tāpēc ir daudz izšķērdētu resursu, kā rezultātā var tikt zaudēti simtiem ETH. mēnesis. Lai vēl vairāk aplūkotu situācijas nopietnību pirms Bolta, šīs ir izmaksas, kas saistītas ar bloka ievietošanu L1:

1. 23K gāzes uz faktu reģistrācija — daļa no Verify Proof and Register
2. 56K gāzes vienā reģistrā SHARP atmiņas lapa
3. 136 000 gāzes katrā štata atjauninājumā
4. 50 000 gāzes KZG priekškompilēšanai, lai ņemtu lāses paraugu,
5. 86K gāze stāvokļa atjaunināšanas funkcijas palaišanai.

Tas veido 215 000 gāzes blokā, un šīs izmaksas ir nemainīgas, ti, tās ir vienādas neatkarīgi no tā, cik daudz datu katrā blokā ir, un ir saistītas ar bloku skaitu ar $ Izmaksa = bloku skaits * 215 000 $. Ideāls risinājums šai problēmai būtu, ja izmaksas būtu saistītas ar ievietoto datu apjomu, nevis bloku skaitu. Un tieši to bloku iepakošana panāk, izmantojot SNAR kokus.

SNAR mēģinājumi

Starknet Applicative Recursive (SNAR) koki ir jauna veida binārie koki, kas ieviesti Boltā, lai risinātu iepriekš izceltās problēmas. SNAR kokam ir šāda struktūra: katra lapa ir Starknet bloks, un mezgli visos citos līmeņos ir rekursīvi to bērnu pierādījumi. Saknes mezgls, kas ir visu pārējo pierādījumu rekursīvs pierādījums, ir pēdējais darbs, kas tiek nosūtīts uz SHARed Prover (SHARP).

Ko dara SNAR koks?

SNAR Tree galvenā priekšrocība ir tāda, ka tā vietā, lai ievietotu vienu bloku katram pierādījumam, daudzus Starknet blokus var amortizēt vienā L1 atjauninājumā. SNAR koku saknes tagad tiek publicētas L1 tikai tad, ja tiek sasniegts viens no diviem konfigurējamiem ierobežojumiem: vai nu DA ierobežojums (6 lāsumu vērti dati) vai pēc tam, kad kokam ir pievienots noteikts lapu skaits (ja lapa ir bloks). .

Šis dizains atdala darījumu izmaksas no bloku skaita. Tagad katram blokam joprojām ir noteiktas fiksētas izmaksas, kas rodas, darbojoties StarkNet OS (SNOS) katrā blokā, taču kopumā izmaksas ir atsaistītas. Tagad šie ir skaitļi:

1. SHARP atmiņas reģistrācija uz vienu darbu: 23K gāzes (tā pati kā iepriekš)
2. SHARP atmiņas lapa vienam darbam: 36 000 gāzes (samazināta no 56 000, pateicoties SHARP optimizācijai),
3. Stāvokļa atjauninājums katram darbam vienāds ar:
4. 86K gāze (tā pati kā iepriekš) +
5. 50 K gāzes × izmantoto lāsumu skaits. (Kad katrā blokā tika izmantots viens lāse, tas bija 50 000 x 1, kā rezultātā tika iegūts 136 K gāzes skaitlis, kas minēts iepriekš).

Zemāk redzamajā 11. attēlā parādīts, kā gāzes izmaksas mainās atkarībā no bloka numura iepriekšējā projektā un tagad (zem Bolt):

Ir diezgan skaidrs, ka bloku iepakošana ievērojami samazina verifikācijas izmaksas L1, kas neapšaubāmi radīs zemākas gāzes cenas Starknet lietotājiem.

Secinājums

Bolt veikto izmaiņu ietekmi: optimistiska paralēla izpilde, izmantojot Block-STM, un bloku iepakošana, izmantojot patentēto SNAR, var apkopot šādi: ātrāk un lētāk.

Paralēlā izpilde samazina izpildes laiku un līdz ar to arī sastrēgumus, kas samazinās gāzes maksu intensīvas satiksmes periodos, savukārt SNAR koki risina saistītos DA un pierādīšanas izmaksas. Interesanti, ka šis jauninājums padara Starknet par pirmo L2 ar paralēlu izpildi un padara to par galveno sāncensi L2 telpā. Ir svarīgi atzīmēt, ka ir maz ticams, ka šo izmaiņu ietekme būs uzreiz pamanāma, jo īpaši paralēlās izpildes gadījumā, taču tām ir izšķiroša nozīme, lai nodrošinātu Starknet un visas Ethereum ekosistēmu kopumā.

Autora piezīme: šī raksta versija iepriekš tika publicēta šeit .