Разопаковане на Starknet Bolt Upgrade

Последният ъпгрейд на Starknet (v0.13.2), наречен носи две големи промени: и . Въпреки че са независими една от друга, и двете функции поддържат стремежа към целта за бързо, евтино блоково пространство, криптографски защитено от Ethereum. Bolt, паралелно изпълнение пакетиране на блокове Паралелното изпълнение позволява неконфликтни транзакции (т.е. транзакции, които не засягат едно и също състояние) да се изпълняват едновременно. Чрез прилагане на паралелно изпълнение, L2s като Starknet могат да намалят времето за изпълнение, без да увеличават използването на ресурси. Това означава по-ниски такси за транзакции за потребителите и значително подобрени времена за потвърждение на транзакциите. Пакетирането на блокове оптимизира използването на Starknet на blobspace на Ethereum L1: с пакетирането на блокове секвенсорите могат да генерират едно доказателство за проверка на множество блокове Starknet L2 едновременно. Това отделя използването на blobspace от честотата на производство на L2 блок и амортизира разходите за проверка на доказателство. И двете намаляват оперативните разходи за секвенсера Starknet, което означава, че потребителите плащат по-малко на транзакция. Както казахме, Bolt прави Starknet по-евтин и по-бърз! Този доклад ще предостави подробен анализ на надстройката на Bolt – фокусирайки се върху паралелното изпълнение и пакетирането на блокове – и ще проучи последиците за производителността на Starknet. Бързо опресняване на събиранията Сборните пакети са , които имат за цел да мащабират основната блокова верига на слой едно (L1) чрез преместване на изчисленията извън веригата. Чрез преместване на изпълнението извън веригата, сборните пакети могат да оптимизират за мащабируемост (евтини и бързи транзакции), докато L1 осигурява сигурност за L2 транзакции. решения за мащабиране на ниво две (L2) Често се казва, че сборните пакети „наследяват сигурността от L1“. Това по същество означава, че те наследяват гаранциите за консенсус и наличност на данни, предоставени от L1. В допълнение към това, L1 предоставя и гаранция за сигурност под формата на сигурен мост между него и сборния пакет. Когато секвенсорите публикуват L2 блокове в L1, L1 предоставя гаранции за наличността, както и за подреждането на тази информация. Оттук L2 възлите могат безнадеждно да изчислят каноничната L2 верига с тази информация заедно с правилата на сбора около извеждането на веригата и прехода на състоянието, описани от изпълнението на възела. За да се улесни сигурното свързване между L1 и L2, L1 изисква доказателство, че веригата L2, която следва в момента, е правилна и не включва незаконни промени в състоянието (напр. двойно изразходване). Тази необходимост от сборни пакети за доказване на валидността на промените в състоянието гарантира, че L1 не разрешава тегления от сборния пакет въз основа на незаконно състояние. Сборните пакети се различават в зависимост от това как доказват валидността на промените в състоянието на L1: Сборните пакети за валидност разчитат на за обективна проверка на коректността на изпълнението. На предлагащите се разрешава да предложат ново състояние на събиране, ако представят доказателство за валидност към договора за сбор. доказателства за валидност Оптимистичните събирания разчитат на липсата на за субективна проверка на коректността на изпълнението. Предложителите изпращат актуализации на състоянието без доказателства, но сборният договор може да отмени всяка актуализация на състоянието, чиято валидност е успешно оспорена от доказателство за измама. доказателство за измама Сборните пакети също предоставят на основния слой достатъчно данни за заинтересованите страни, за да реконструират състоянието L2. Докато оптимистичните сборни данни трябва да публикуват пълни данни за транзакциите, за да могат претендентите да изчислят доказателства за измами, сборните пакети за валидност нямат такива изисквания (доказателствата за валидност гарантират правилното изпълнение). Но публикуването на пълни данни за транзакциите на L1 все още е полезно от гледна точка на минимизиране на доверието (ненадеждна реконструкция на състояние и тегления без разрешение). Starknet е сборен пакет за валидност, който използва скалируем, прозрачен gument of knowledge (STARKs), за да докаже валидността на промените в състоянието. Най-новото надграждане на Starknet с кодово име Bolt добавя паралелно изпълнение и пакетиране на блокове. В следващите раздели ще обясним как работят двете функции и какви подобрения носят за потребителите на Starknet. S T AR K Какво промени надграждането на Starknet Bolt? На високо ниво надстройката на Bolt промени механизмите за изпълнение, доказване и на Starknet. наличност на данни Оптимизиране на изпълнението Преди надграждането на Bolt транзакциите на Starknet се изпълняваха последователно – една след друга – от секвенсера. Последователното изпълнение е просто, но и много неефективно. Това е неефективно, защото не се възползва от множеството независими процесорни единици, които съвременните компютри предлагат, и възможността за паралелизиране на набор от транзакции. Паралелността е мярка за това колко независими са транзакциите в даден набор. Например, разгледайте набора от три транзакции по-долу: Транзакция 1: Алис иска да изпрати на Боб 1 STRK Транзакция 2: Кейтлин иска да изпрати на Дани 100 ETH Транзакция 3: Кейтлин иска да изпрати на Ела 100 ETH Транзакция 1 е напълно независима от транзакции 2 и 3 – тъй като има достъп до различна част от състоянието (салдото на Алис) – и може да се изпълнява едновременно. Транзакция 2 и 3 обаче са в конфликт, защото искат достъп до едно и също състояние — ETH баланса на Кейтлин. Тези транзакции не могат да се изпълняват едновременно или в крайна сметка ще получим противоречиви резултати. За да илюстрирам: Да кажем, че балансът на Кейтлин е 300 ETH и транзакции 2 и 3 започват по едно и също време. И двете транзакции ще прочетат първоначалния баланс на акаунта на Кейтлин като 300 ETH, ще приспаднат сумата на превода от него (300 - 100 = 200) и ще запишат 200 ETH на мястото в паметта, където се съхранява балансът на акаунта на Кейтлин. След това транзакции 2 и 3 ще прочетат съответно балансите на Danny и Ella и ще добавят 100 ETH към балансите на двамата потребители. Балансът на Caitlyn ще намалее със 100 ETH, но 200 ETH ще бъдат кредитирани – ефективно отпечатване на 100 ETH от нищото. Избягването на тези видове конфликти (и сложната природа на механизмите за смекчаване) е причината Ethereum да избере последователно изпълнение. Въпреки това, докато последователното изпълнение намалява сложността и подобрява сигурността, то води до неефективно използване на хардуера. Още по-лошо, тенденцията в хардуерния дизайн предполага, че последователното изпълнение ще стане все по-неефективно през следващите години. Фигура 4 показва тенденцията в дизайна на хардуера през последните 50 години. Съответният извод? Производителността на една нишка (лилави кръгове) е на плато от средата на 2000-те, докато броят на логическите ядра се е увеличил приблизително по същото време. Въз основа на тези данни можем да направим два извода: Дизайнерите на хардуер мащабират компютърните чипове, като добавят повече независими процесорни единици, вместо да подобряват производителността на една единица. Всяка система, която продължава да разчита на повишена производителност на единична процесорна единица, ще претърпи забавяне в повишаването на производителността дори на по-нов хардуер. През последните години се появиха сложни алгоритми за управление на конфликти на транзакции и осигуряване на коректност на паралелното изпълнение. Block-STM (базиран на документ от Fikunmi et al*) е един такъв алгоритъм и формира основната част от новата машина за паралелно изпълнение на Starknet. Анализираме алгоритъма Block-STM в следващите раздели. Оптимизиране на доказването и наличността на данни SHARP на Starknet (съкратено от Shared Prover) винаги се е възползвал от рекурсивните доказателства, за да намали разходите за проверка възможно най-много. Рекурсивното доказателство е по същество „доказателство за доказателство“, където едно доказателство потвърждава, че едно или повече доказателства са верни. По-долу е дадена скица на това как SHARP генерира рекурсивно доказателство: Системата SHARP приема набор от програми за изпълнение („задача“) като вход и генерира доказателство за изпълнение за задачата. Тези „програми“ са L2 блокове и доказателството удостоверява коректността на транзакциите. Доказателството се изпраща до друга програма, която проверява доказателството и преобразува програмата за проверка на доказателство в задание. SHARP приема новото задание като вход и генерира друго доказателство (това доказателство потвърждава валидността на предишното доказателство). Процесът (доказателство → задание → доказателство) се рестартира и продължава до достигане на целта, в който момент окончателното доказателство (което сега е силно компресирана версия на оригиналното доказателство) се публикува в L1 Този дизайн значително амортизира разходите по две основни причини: Последващите задания* не са отделни програми или транзакции и разходите за доказване нарастват сублинейно. Това означава, че колкото по-голям е броят на програмите/транзакциите в рамките на едно задание, толкова по-големи са спестяванията. Чрез създаване на доказателства за блок, вместо за транзакция, таксите за транзакции могат да бъдат много по-евтини. Рекурсията силно компресира доказателствата, което води до „доказателство за доказателство“, което е значително по-евтино за проверка на L1 от първоначалното доказателство или някое от междинните доказателства. Въпреки че системата за доказване беше добра, бяха пропуснати шансове за допълнително спестяване на разходи. Например, всяко задание беше единичен блок на Starknet и всеки от тези блокове беше проектиран да заема един петно на L1. Това доведе до определени неефективности, както е описано по-долу: Преди Bolt, Starknet нямаше (и все още има) редовни блокове; вместо това L2 блок беше публикуван в L1 при две условия: (1) Един блок с данни беше изпълнен (2) Шест минути бяха изтекли от предишния блок. За съжаление, поради търсенето, повечето от блоковете бяха изпратени до L1 поради ограничението от шест минути (не ограниченията на DA). Горното означаваше, че петна (не блокове) често (сериозно) не се използват, което води до ненужно високи разходи за газ. Блоковете на Starknet също имаха , която теоретично можеше да бъде намалена чрез прилагане на същите техники за рекурсия, обсъдени по-горе, за създаване на доказателства за множество блокове. фиксирана цена Блоковото пакетиране се справя с тези проблеми чрез използване на двоично дърво от рекурсивни доказателства. Обсъждаме пакетирането на блокове в по-късен раздел на статията. Болт Част 1: Паралелно изпълнение Както беше обсъдено по-рано, последователното изпълнение е неефективно (и ще бъде само по-неефективно с течение на времето), а простото паралелно изпълнение води до невалидни резултати. Машините за паралелно изпълнение на производството обаче се грижат да предотвратят непоследователни резултати. Има два подхода за справяне с паралелното изпълнение: и . PCC и OCC са единици за обработка на транзакции (TPU). По-долу е дадена дефиниция на модул за обработка на транзакции от песимистичен контрол на едновременността (PCC) оптимистичен контрол на едновременността (OCC) Block-STM срещу SVM: Сравнение на машини за паралелно изпълнение: TPU обикновено е свързан с виртуалната машина (VM), но е различен от нея. Blockchain VM като EVM, SVM и MoveVM са езикови VM от високо ниво… TPU, който обикновено е обект на интерес, включва VM. Той е натоварен с управлението на целия тръбопровод за изпълнение на транзакции, включително създаване и управление на екземпляри на VM. Песимистичният контрол на паралелността е проектиран въз основа на предположението, че много от транзакциите в набора от транзакции, които трябва да бъдат изпълнени, ще бъдат в конфликт, т.е. те ще докоснат едно и също състояние. PCC тези конфликти. предотвратява За да предотврати конфликти, PCC изисква транзакцията да декларира предварително до какви части от състоянието ще има достъп по време на операции за четене/запис. Модулът за обработка на транзакции може да използва тази информация, за да планира транзакции по начин, който гарантира, че конфликтните транзакции се изпълняват последователно (вместо едновременно). Някои TPU също използват ключалки, за да наложат това поведение (заключването (известно още като mutex) е механизъм, използван за предотвратяване на едновременен достъп до място в паметта). Въпреки това изпълнението, базирано на PCC, води до определени компромиси. Първо, изискването за предоставяне на списъци за достъп (които идентифицират слота за памет, до който се докосва транзакцията) влошава опита на разработчиците и намалява обхвата на възможните приложения. Второ, планирането на транзакции може да доведе до ненужни разходи – особено когато няма конфликти. Оптимистичният контрол на паралелността е проектиран с предположението, че много от транзакциите в дадения набор няма да са в конфликт, т.е. те няма да пишат в едно и също състояние. Като такива, OCC TPU изпълняват набора от транзакции с всички налични ресурси и се опитват само да конфликти. Ако бъде конфликт, транзакциите, които са в конфликт, се изпълняват и проверяват отново, докато целият набор премине и може да бъде ангажиран. открият открит OCC TPU не поемат допълнителни разходи от планирането, така че те са склонни да работят по-добре, когато има малко конфликти. Базираните на OCC единици за обработка на транзакции също имат по-добър опит за разработчици и по-широк набор от случаи на употреба, тъй като не е необходимо зависимостите на състоянието да бъдат известни предварително. Въпреки това, когато наборът от транзакции е много спорен, OCC се представя по-зле от PCC. Ние разглеждаме дизайна на TPU (много по-подробно) и сравняваме подходите на OCC и PCC в за паралелно изпълнение. нашата статия Новият TPU на Starknet използва OCC подхода. По-конкретно, това е реализация на алгоритъма Block-STM. Block-STM изпълнява транзакциите оптимистично с всички налични ресурси, като приема, че нито един от тях няма да бъде в конфликт и проверява след изпълнението, че няма конфликтни транзакции, изпълнени едновременно. Преди да се потопим в новата архитектура на Starknet, е важно да прегледаме някои ключови дефиниции: : Състоянието е състоянието на обект в даден момент във времето. В контекста на блокчейн обикновено се отнася до стойността на част от паметта, например балансът на адрес е (част от) неговото състояние. Състояние : Твърди се, че паралелното изпълнение е запазило свойството на възможност за сериализиране, ако изпълнението на набор от транзакции последователно и едновременно води до едни и същи резултати. Възможност за сериализиране : Казва се, че две транзакции са в конфликт, ако и само ако поне една от тях иска да пише в част от състояние, до която и двете искат достъп (може да се чете или пише). Ако и двете транзакции четат само от част от състоянието, тогава няма конфликт, но ако поне една от тях пише в тази част от състоянието, тогава транзакциите не могат да бъдат изпълнени едновременно, без да се наруши възможността за сериализиране. Разкрихме примерен случай по-горе в примера с Кейтлин, Дани и Ела. Конфликт : Казва се, че транзакция е зависима от (или зависимост от) транзакция тогава и само ако и двете транзакции записват в едно и също място в паметта и идва след в серийното подреждане. Ако дойде след , ще зависи от . Зависимост txj txi txj txi txi txj txi txj : Многоверсионна структура от данни е тази, при която се създава нова версия на структурата от данни за всеки запис в структурата от данни. Вместо да се променя стойността на място, се създава нова, специфична за запис версия на местоположението, което трябва да се промени. Стойността на многоверсионните структури от данни е, че те позволяват силно едновременно четене от и записване в един и същи регион в паметта. По-късно ще проучим как това е полезно. Мултиверсионна структура от данни След като дефинициите са премахнати, можем да преминем към това как работи Block-STM. Как работи Block-STM Входът към Block-STM е опашка (подреден списък) от транзакции, този списък често се нарича БЛОК. Този списък може да бъде подреден по всякакъв начин; единственото изискване е да има ясно определен ред. И така, даден набор от транзакции T, съдържащи транзакции , транзакциите са сортирани така, че (да се чете като е с по-висок приоритет от , е с по-висок приоритет от и т.н. .) {t0…tn} {t0 > t1 > t2 … > tn} t0 t1 t1 t2 В началото на процеса на изпълнение се създават два комплекта – набор за изпълнение E и набор за валидиране V. E проследява транзакции, които тепърва ще бъдат изпълнени, докато V проследява транзакции, които са били изпълнени, но предстои да бъдат валидирани. Всяка транзакция също е свързана с номер на въплъщение n, за да се проследи колко пъти е била изпълнена (и повторно изпълнена). Първоначалното състояние на комплектите е, че E съдържа всички транзакции и V е празно, т.е. и . E = {t0,1 > t1,1 > t2,1 > … > tn,1} V = {} С тези подредени набори от транзакции всяка нишка, използвана за изпълнение, преминава през триетапен цикъл: Проверете Готово Намерете следващата задача Изпълнение на задачата Проверете Готово По време на тази стъпка нишката проверява както V, така и E. Ако и двете са празни и не се изпълнява транзакция, тогава текущата партида транзакции е изпълнена напълно и резултатите могат да бъдат ангажирани за съхранение. Намерете следващата задача Ако V или E съдържа транзакции, Block-STM избира транзакцията с най-нисък индекс (не номер на въплъщение) от двата набора транзакции, т.е. ако E съдържа и V съдържа , задачата за валидиране за транзакция ще бъде избрана като следваща задача. {t1,3 , t3,1 and t5,2} {t0,1, t2,4, t4,3} t0 Изпълнение на задачата След като бъде идентифицирана и избрана следващата задача, тя се изпълнява. В края на тази стъпка алгоритъмът се връща обратно към Check Done. Този процес продължава, докато и двата набора транзакции са празни. Нека да разгледаме какво се случва по време на изпълнение и валидиране: По време на изпълнение на транзакция алгоритъмът Block-STM попълва два набора (на транзакция); набор за четене ( ) и набор за запис ( ). Наборът за четене съдържа всички места в паметта, от които една транзакция е прочела по време на нейното изпълнение, докато наборът за запис съдържа всички места в паметта, в които е записала. По време на изпълнение транзакциите прилагат записите си към многоверсионната структура на данните, но четенето е малко нюансирано. Ri,n Wn,i В Block-STM, когато транзакция иска да прочете от структурата на данните, тя проверява за стойността, записана от транзакцията с най-нисък приоритет, която има по-висок приоритет. Например, ако всички , и са записали в място в паметта и иска да чете от това място, той чете версията на структурата от данни, съответстваща на . tx1 tx2 tx7 tx5 tx2 Това се прави, за да се наложи сериализация; тъй като трябва да се изпълнява след и преди , той трябва да използва стойностите, записани от а не . В този пример ще трябва да се изпълни отново, защото трябва да е прочел стойностите, записани от , а не от или други транзакции с по-висок приоритет. Ако се използва структура от данни с една версия, стойността, записана от ще бъде недостъпна и със сигурност ще възникне конфликт. tx5 tx2 tx7 tx2 tx7 tx7 tx5 tx2 tx2 За задача за валидиране наборът за четене на транзакцията се сравнява с текущите стойности в местата на паметта, от които се чете по време на изпълнение. Например, ако чете акаунт B по време на изпълнение, по време на валидиране, местоположението на паметта за акаунт B се чете (като се има предвид определението за четене, което установихме по-рано). Ако двете стойности са еднакви, това означава, че нито една транзакция с по-висок приоритет (да речем или ) не е записала на това място по време на изпълнението на . Това води до маркиран като валидиран, но не е безопасен за ангажиране. tx2 tx0 tx1 tx2 tx2 Транзакцията не се счита за безопасна за ангажиране, тъй като транзакция с по-нисък приоритет може, поради различни причини, да бъде изпълнена, след като транзакцията е била валидирана. В нашия работещ пример, ако докосне акаунт B и го докосне само след това, преминава проверка, тогава трябва да се изпълни отново. tx1 tx2 tx2 За да се предвиди това, всеки път, когато транзакция завърши изпълнението, всички транзакции с по-нисък приоритет, които са преминали валидиране, се проверяват повторно, за да се гарантира, че не са в конфликт с транзакцията. Например, ако , и са валидирани и завърши изпълнението, и трябва да бъдат повторно валидирани, за да се гарантира, че не са в конфликт с (както и зависимостите от) . tx1 tx3 tx4 tx2 tx3 tx4 tx2 Ако транзакция не премине проверката, т.е. транзакция с по-висок приоритет, която записва в същото състояние, е била изпълнена едновременно с нея, тогава записите, направени от транзакцията, са мръсни (защото стойностите са грешни.) Но вместо да изтриете тези стойности от базата данни, напълно, те са маркирани с флаг ESTIMATE. Флагът ESTIMATE казва на всяка транзакция, която чете това място в паметта, че стойностите там не са правилни и транзакциите спират изпълнението си. Това се прави вместо изтриване, тъй като повторното изпълнение на транзакцията, която не е преминала валидирането, вероятно ще доведе до запис в същите места в паметта като предишното изпълнение. Чрез маркиране на местоположението в паметта като приблизителна стойност, вместо изтриването му, зависимостите (на транзакцията, която не е преминала валидирането) могат да бъдат уловени дори преди повторното изпълнение, предотвратявайки ненужни повторни изпълнение. Тази евристика значително намалява загубата на работа. Сглобяване на всичко Пълният преглед на начина, по който Block-STM подхожда към паралелизирането, може да бъде обобщен като: от транзакции започва като подреден списък с ясно дефиниран сериен ред. Тези транзакции се изпълняват на всички налични ресурси в приоритетен ред. BLOCK По време на изпълнение се проследяват наборите за четене и запис на транзакциите и се извършват четения и записи от/към многоверсионна структура от данни. Когато транзакция завърши изпълнението, тя се валидира, за да се гарантира, че не е изпълнена едновременно с конфликтни транзакции. Ако дадена транзакция премине валидиране, тогава тя се премахва от E и V. И когато транзакцията е валидирана, всички транзакции с по-нисък приоритет от тази, която е преминала валидирането, се пренасрочват за валидиране. Ако дадена транзакция не премине валидирането, тя се пренасрочва за изпълнение. Когато целият набор от транзакции е изпълнен и валидиран, тогава целият БЛОК е безопасен за ангажиране и резултатите могат да бъдат записани в постоянно хранилище. По-долу е показан пример: Това е общ преглед на това как работи Block-STM, повече подробности можете да намерите в нашия доклад и в оригиналния документ на Block-STM . тук тук Как Block-STM подобрява производителността на Starknet? За да определим количествено значението на добавянето на Block-STM, изпълнихме няколко сравнителни теста, за да оценим подобренията в производителността, които предоставя в сравнение с последователното изпълнение, и резултатите са показани по-долу. Резултатите показват, че с увеличаване на броя на използваните нишки (аналогични на независими процесорни единици), производителността също се увеличава. Подобренията са по-изразени с по-големи блокове, които дават до 9 пъти подобрения на производителността в сравнение с последователно изпълнение само с 16 нишки. Установихме, че резултатите са по-изразени при по-големи блокове. Нашите тестове показват, че производителността на Block-STM значително се влошава при силно оспорвано натоварване, но стандартната практика в индустрията е да се върне към последователно изпълнение през такива периоди. Препоръчваме същия механик на Starknet, за да запази пропускателната способност при много спорни натоварвания. Но като цяло добавянето на Block-STM значително ще подобри и ще подобри Starknet в бъдеще. Втората основна промяна, включена в надстройката v0.13.2, е пакетирането на блокове и ще разгледаме това по-нататък. Болт Част 2: Опаковка на блока Както беше обсъдено по-рано, преди Bolt, всеки блок Starknet беше собствена работа, което води до фиксирана цена на блок за всеки блок. В допълнение, системата е проектирана така, че всеки блок изисква свой собствен blob, независимо от това колко данни всъщност са били консумирани от блока. В свят, в който винаги е имало голямо търсене, това не би било проблем, но Starknet в момента предлага повече блоково пространство, отколкото има търсене и затова има много пропилени ресурси, което може да доведе до в течение на един месец. За да поставим допълнително в контекста на сериозността на ситуацията преди Bolt, това са разходите, свързани с публикуването на блок на L1: загуба на стотици ETH 23K газ на фактическа регистрация – част от Проверка на доказателство и регистрация 56K газ на регистър SHARP страница с памет 136K газ на актуализация на състоянието 50K газ за предварителното компилиране на KZG за проба на петно, 86K газ за изпълнение на функцията за актуализиране на състоянието. Това възлиза на 215k газ на блок и тази цена е равна, т.е. същата е независимо от това колко данни съдържа всеки блок и е свързана с броя на блоковете по $Cost = брой блокове * 215000$. Идеалното решение на този проблем би било разходите да бъдат свързани с количеството публикувани данни, вместо с количеството блокове. И точно това постига пакетирането на блокове чрез SNAR дървета. SNAR опитва Starknet Applicative Recursive (SNAR) дървета са нов тип двоично дърво, въведено в Bolt за справяне с проблемите, подчертани по-горе. Дървото на SNAR има следната структура: всеки лист е блок на Starknet, а възлите на всички други нива са рекурсивни доказателства за своите деца. Основният възел, който е рекурсивно доказателство за всички други доказателства, е окончателното задание, което се изпраща на SHARP Prover (SHARP). Какво прави дървото SNAR? Основното предимство на SNAR Tree е, че вместо да публикувате един блок на доказателство, много блокове на Starknet могат да бъдат амортизирани в една и съща L1 актуализация. Корените на дървото на SNAR вече се публикуват в L1 само когато бъде достигнато едно от двете конфигурируеми ограничения: или ограничението на DA (данни на стойност 6 петна) или след добавяне на определен брой листа към дървото (където листът е блок) . Този дизайн отделя разходите за транзакции от броя на блоковете. Сега все още има някаква фиксирана цена за всеки блок, която възниква от стартирането на StarkNet OS (SNOS) във всеки блок – но като цяло разходите са отделени. Това са числата сега: Регистрация на паметта на SHARP за задание: 23K газ (същото както преди) Страница с памет на SHARP за задание: 36K газ (намален от 56K благодарение на оптимизацията на SHARP), Актуализация на състоянието на задание, равно на: 86K газ (същото като преди) + 50K газ × брой използвани петна. (Когато беше използвано едно петно на блок, това беше 50K x 1, което доведе до 136K газово число, цитирано по-горе). Графиката на фигура 11 по-долу показва как разходите за газ варират в зависимост от номера на блока в предишния дизайн и сега (под болт): Съвсем очевидно е, че пакетирането на блокове значително намалява разходите за проверка на L1, което несъмнено ще доведе до по-ниски цени на бензина за потребителите на Starknet. Заключение Ефектът от промените, направени в Bolt: оптимистично паралелно изпълнение чрез Block-STM и пакетиране на блокове чрез собствения SNAR може да се обобщи като: по-бързо и по-евтино. Паралелното изпълнение намалява времето за изпълнение и чрез разширяване задръстванията, което ще намали таксите за газ по време на периоди на голям трафик, докато SNAR дърветата се справят със свързаните DA и разходи за доказване. Интересното е, че това надграждане прави Starknet първия L2 с паралелно изпълнение и го превръща в основен претендент в L2 пространството. Важно е да се отбележи, че е малко вероятно ефектът от тези промени да бъде незабавно очевиден, особено този от паралелното изпълнение, но те са от решаващо значение за бъдещата защита на Starknet и цялата екосистема на Ethereum като цяло. Бележка на автора: Версия на тази статия беше публикувана преди това . тук