paint-brush
Starknet Bolt-ის განახლებამიერ@2077research
ახალი ისტორია

Starknet Bolt-ის განახლება

მიერ 2077 Research17m2024/12/26
Read on Terminal Reader

Ძალიან გრძელი; Წაკითხვა

Starknet Bolt-ის განახლებამ შემოიღო ორი ძირითადი ფუნქცია: პარალელური შესრულება და ბლოკის შესრულება. ეს სტატია განიხილავს, თუ როგორ აუმჯობესებს ეს ახლად დანერგილი ფუნქცია Starknet-ის მუშაობას და აუმჯობესებს ტრანზაქციის გამოცდილებას Layer 2 (L2) მომხმარებლებისთვის.
featured image - Starknet Bolt-ის განახლება
2077 Research HackerNoon profile picture


Starknet-ის უახლეს განახლებას (v0.13.2) სახელად Bolt მოაქვს ორი ძირითადი ცვლილება: პარალელური შესრულება და ბლოკის შეფუთვა . მიუხედავად იმისა, რომ ერთმანეთისგან დამოუკიდებელია, ორივე ფუნქცია მხარს უჭერს Ethereum-ის მიერ კრიპტოგრაფიულად დაცული სწრაფი, იაფი ბლოკის მიზნისკენ სწრაფვას.


პარალელური შესრულება საშუალებას აძლევს არაკონტიტუციურ ტრანზაქციებს (ანუ ტრანზაქციებს, რომლებიც არ ეხება ერთსა და იმავე მდგომარეობას) ერთდროულად შესრულდეს. პარალელური შესრულების განხორციელებით, L2-ებს, როგორიცაა Starknet, შეუძლიათ შეამცირონ შესრულების დრო რესურსების გამოყენების გაზრდის გარეშე. ეს ნიშნავს დაბალ ტრანზაქციის საკომისიოებს მომხმარებლებისთვის და მნიშვნელოვნად გაუმჯობესებულია ტრანზაქციის დადასტურების დრო.


ბლოკის შეფუთვა ოპტიმიზირებს Starknet-ის მიერ blobspace-ის გამოყენებას Ethereum L1-ზე: ბლოკის შეფუთვით, სეკვენსერებს შეუძლიათ შექმნან ერთი მტკიცებულება, რათა გადაამოწმონ მრავალი Starknet L2 ბლოკი ერთდროულად. ეს აკავშირებს blobspace-ის გამოყენებას L2 ბლოკის წარმოების სიხშირისგან და ამცირებს მტკიცებულების გადამოწმების ხარჯებს. ორივე ამცირებს Starknet sequencer-ის საოპერაციო ხარჯებს, რაც ნიშნავს, რომ მომხმარებლები იხდიან ნაკლებს თითო ტრანზაქციაზე.


როგორც ვთქვით, ბოლტი სტარკნეტს უფრო იაფს და სწრაფს ხდის! ეს ანგარიში უზრუნველყოფს Bolt-ის განახლების დეტალურ ანალიზს – ფოკუსირებულია პარალელურ შესრულებაზე და ბლოკის შეფუთვაზე – და შეისწავლის გავლენას Starknet-ის მუშაობაზე.

სწრაფი განახლება შეკრებებზე

Rollups არის ორი ფენის (L2) სკალირების გადაწყვეტილებები , რომლებიც მიზნად ისახავს ძირეული ფენის პირველი (L1) ბლოკჩეინის მასშტაბირებას გამოთვლის ჯაჭვის გარეთ გადაადგილებით. შესრულების ჯაჭვის გარეთ გადატანით, გაერთიანებებს შეუძლიათ ოპტიმიზაცია მოახდინონ მასშტაბურობისთვის (იაფი და სწრაფი ტრანზაქციები), ხოლო L1 უზრუნველყოფს L2 ტრანზაქციების უსაფრთხოებას.


ხშირად ამბობენ, რომ Rollups "მემკვიდრეობს უსაფრთხოებას L1-დან". ეს არსებითად ნიშნავს იმას, რომ ისინი მემკვიდრეობით იღებენ კონსენსუსს და მონაცემთა ხელმისაწვდომობის გარანტიებს, რომლებიც მოწოდებულია L1-ით. გარდა ამისა, L1 ასევე უზრუნველყოფს უსაფრთხოების გარანტიას მასსა და შეკრებას შორის უსაფრთხო ხიდის სახით.


როდესაც თანმიმდევრობა აქვეყნებს L2 ბლოკებს L1-ში, L1 იძლევა გარანტიებს ამ ინფორმაციის ხელმისაწვდომობისა და შეკვეთის შესახებ. აქედან, L2 კვანძებს შეუძლიათ დაუჯერებლად გამოთვალონ კანონიკური L2 ჯაჭვი ამ ინფორმაციასთან ერთად დაჯგუფების წესებთან ერთად ჯაჭვის წარმოშობისა და მდგომარეობის გადასვლის შესახებ, რომელიც აღწერილია კვანძის განხორციელებით.


L1-სა და L2-ს შორის უსაფრთხო ხიდის გასაადვილებლად, L1 მოითხოვს მტკიცებულებას, რომ L2 ჯაჭვი, რომელსაც ამჟამად მიჰყვება, არის სწორი და არ შეიცავს არალეგალურ მდგომარეობას (მაგ. ორმაგი ხარჯვა). შეერთების საჭიროება, რათა დაამტკიცოს მდგომარეობის ცვლილებების მართებულობა, უზრუნველყოფს, რომ L1 არ იძლევა არალეგალურ მდგომარეობაზე დაფუძნებული შეკრებიდან გატანის უფლებას.


შეკრებები განსხვავდება იმის მიხედვით, თუ როგორ ადასტურებენ L1-ში მდგომარეობის ცვლილებების მართებულობას:

  • ვალიდობის შეკრებები ეყრდნობა მოქმედების მტკიცებულებებს , რათა ობიექტურად გადაამოწმონ შესრულების სისწორე. პრეტენდენტებს უფლება აქვთ შესთავაზონ ახალი შემაჯამებელი მდგომარეობა, თუ ისინი წარადგენენ მოქმედების დამადასტურებელ მტკიცებულებას შეკრების ხელშეკრულებაში.
  • ოპტიმისტური შეკრებები ეყრდნობა თაღლითობის მტკიცებულების არარსებობას, რათა სუბიექტურად გადაამოწმოს შესრულების სისწორე. შემკვეთები წარადგენენ სახელმწიფო განახლებებს მტკიცებულებების გარეშე, მაგრამ შემაჯამებელ ხელშეკრულებას შეუძლია გააუქმოს ნებისმიერი სახელმწიფო განახლება, რომლის ვალიდობაც წარმატებით ეჭვქვეშ აყენებს თაღლითობის მტკიცებულებას.


Rollups ასევე აწვდის საბაზისო ფენას საკმარის მონაცემებს დაინტერესებული მხარეებისთვის, რათა აღადგინონ L2 მდგომარეობა. მიუხედავად იმისა, რომ ოპტიმისტურმა შეკრებამ უნდა გამოაქვეყნოს სრული ტრანზაქციის მონაცემები, რათა გამომწვევებმა შეძლონ თაღლითობის მტკიცებულებების გამოთვლა, ვალიდობის შეკრებებს ასეთი მოთხოვნები არ გააჩნია (მოქმედების მტკიცებულება გარანტირებულია სწორ შესრულებაზე). მაგრამ ტრანზაქციის სრული მონაცემების განთავსება L1-ზე მაინც სასარგებლოა ნდობის მინიმიზაციის პერსპექტივიდან (სახელმწიფოების უიმედო რეკონსტრუქცია და უნებართვო გატანა).


Starknet არის ვალიდობის შეკრება, რომელიც იყენებს S calable, T გამჭვირვალე AR გუმენტს K nowledge (STARKs) მდგომარეობის ცვლილებების მართებულობის დასამტკიცებლად. Starknet-ის უახლესი განახლება - კოდირებული Bolt - ამატებს პარალელურ შესრულებას და ბლოკის შეფუთვას. მომდევნო სექციებში ჩვენ აგიხსნით, თუ როგორ მუშაობს ეს ორი ფუნქცია და რა გაუმჯობესება მოაქვს მათ Starknet-ის მომხმარებლებისთვის.

რა შეცვალა 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 შემდეგ წაიკითხავს დენისა და ელას ნაშთებს შესაბამისად და დაამატებს 100 ETH ორივე მომხმარებლის ბალანსს. Caitlyn-ის ბალანსი შემცირდება 100 ETH-ით, მაგრამ 200 ETH ჩაირიცხება - ფაქტობრივად 100 ETH ჰაერიდან დაბეჭდვა.


ამ ტიპის კონფლიქტების თავიდან აცილებამ (და შემარბილებელი მექანიზმების კომპლექსური ბუნება) სწორედ ამიტომ აირჩია Ethereum-მა თანმიმდევრული შესრულება. თუმცა, მიუხედავად იმისა, რომ თანმიმდევრული შესრულება ამცირებს სირთულეს და აუმჯობესებს უსაფრთხოებას, ეს იწვევს ტექნიკის არაეფექტურ გამოყენებას. უფრო უარესი, ტექნიკის დიზაინის ტენდენცია ვარაუდობს, რომ თანმიმდევრული შესრულება უახლოეს წლებში სულ უფრო არაეფექტური გახდება.


სურათი 4 გვიჩვენებს ტექნიკის დიზაინის ტენდენციას ბოლო 50 წლის განმავლობაში. შესაბამისი წაღება? ერთი ძაფის შესრულება (იისფერი წრეები) 2000-იანი წლების შუა პერიოდიდან გაიზარდა, ხოლო ლოგიკური ბირთვების რაოდენობა დაახლოებით იმავე დროს გაიზარდა. ამ მონაცემებზე დაყრდნობით შეგვიძლია ორი დასკვნის გაკეთება:

  • ტექნიკის დიზაინერები ამცირებენ კომპიუტერის ჩიპებს მეტი დამოუკიდებელი დამუშავების ერთეულის დამატებით, ვიდრე ერთი ერთეულის მუშაობის გაუმჯობესებით.

  • ნებისმიერი სისტემა, რომელიც აგრძელებს დაყრდნობას ერთი დამუშავების ერთეულის გაზრდილ ეფექტურობაზე, განიცდის შეფერხებას ეფექტურობის მიღწევებში, თუნდაც ახალ აპარატურაზე.


სურათი 4: მიკროპროცესორული ტენდენციები


ბოლო წლებში გამოჩნდა დახვეწილი ალგორითმები ტრანზაქციის კონფლიქტების მართვისა და პარალელური შესრულების სისწორის უზრუნველსაყოფად. Block-STM (დაფუძნებულია Fikunmi et al*-ის ნაშრომზე) ერთ-ერთი ასეთი ალგორითმია და წარმოადგენს Starknet-ის ახალი პარალელური შესრულების ძრავის ძირითად ნაწილს. ჩვენ ვაანალიზებთ Block-STM ალგორითმს შემდეგ სექციებში.

დადასტურებისა და მონაცემთა ხელმისაწვდომობის ოპტიმიზაცია

Starknet-ის SHARP (შემოკლებით Shared Prover) ყოველთვის სარგებლობდა რეკურსიული მტკიცებულებებით, რათა შეძლებისდაგვარად შეემცირებინა გადამოწმების ხარჯები. რეკურსიული მტკიცებულება არსებითად არის "მტკიცებულება", სადაც ერთი მტკიცებულება ადასტურებს, რომ ერთი ან მეტი მტკიცებულება სწორია. ქვემოთ მოცემულია ესკიზი, თუ როგორ ქმნის SHARP რეკურსიულ მტკიცებულებას:

  • SHARP სისტემა იღებს შესასრულებელი პროგრამების ერთობლიობას ("სამუშაო") შეყვანის სახით და ქმნის სამუშაოს შესრულების მტკიცებულებას. ეს „პროგრამები“ არის L2 ბლოკები და მტკიცებულება ადასტურებს გარიგების სისწორეს.

  • მტკიცებულება იგზავნება სხვა პროგრამაში, რომელიც ამოწმებს მტკიცებულებას და აკონვერტებს მტკიცებულების გადამოწმების პროგრამას სამუშაოდ. SHARP იღებს ახალ სამუშაოს შეყვანის სახით და ქმნის სხვა მტკიცებულებას (ეს მტკიცებულება ადასტურებს წინა მტკიცებულების მართებულობას).

  • პროცესი (მტკიცებულება → სამუშაო → მტკიცებულება) ხელახლა იწყება და გრძელდება მანამ, სანამ მიზანს მიაღწევს, რა დროსაც საბოლოო მტკიცებულება (რომელიც ახლა ორიგინალური მტკიცებულების ძალიან შეკუმშული ვერსიაა) განთავსდება L1-ზე.


სურათი 5: რეკურსიული მტკიცებულების გენერაცია


ეს დიზაინი მნიშვნელოვნად ამცირებს ხარჯებს ორი ძირითადი მიზეზის გამო:

  • შემდგომი სამუშაოები* არ არის ინდივიდუალური პროგრამები ან ტრანზაქციები და დადასტურების ხარჯები იზრდება ქვეწრფივად. ეს ნიშნავს, რომ რაც უფრო დიდია პროგრამების/ტრანზაქციის რაოდენობა სამუშაოზე, მით მეტია დანაზოგი. თითო ტრანზაქციის ნაცვლად ბლოკზე მტკიცებულებების შექმნით, ტრანზაქციის საკომისიო შეიძლება გაცილებით იაფი იყოს.
  • რეკურსია მნიშვნელოვნად შეკუმშავს მტკიცებულებებს, რის შედეგადაც წარმოიქმნება „მტკიცებულების მტკიცებულება“, რომლის გადამოწმება L1-ზე მნიშვნელოვნად იაფია, ვიდრე საწყისი მტკიცებულება ან რომელიმე შუალედური მტკიცებულება.


მიუხედავად იმისა, რომ დამადასტურებელი სისტემა კარგი იყო, ხარჯების შემდგომი დაზოგვის შანსი ხელიდან გაუშვა. მაგალითად, თითოეული სამუშაო იყო Starknet-ის ერთი ბლოკი და თითოეული ეს ბლოკი შექმნილია L1-ზე ერთი ბლოკის დასაკავებლად. ამან გამოიწვია გარკვეული არაეფექტურობა, როგორც ეს აღწერილია ქვემოთ:

  • ბოლტამდე სტარქნეტს არ ჰქონდა (და ახლაც აქვს) რეგულარული ბლოკტაიმები; ამის ნაცვლად, L2 ბლოკი გამოქვეყნდა L1-ზე ორი პირობით: (1) შესრულდა ერთი ბლოკის ღირებულების მონაცემები (2) ექვსი წუთი იყო გასული წინა ბლოკიდან. სამწუხაროდ, მოთხოვნის გამო, ბლოკების უმეტესობა გაიგზავნა L1-ზე ექვსი წუთის ლიმიტის გამო (არა DA ლიმიტები).
  • ზემოაღნიშნული იმას ნიშნავდა, რომ ბლოკები (არა ბლოკები) ხშირად (სერიოზულად) არასაკმარისად იყო გამოყენებული, რაც იწვევს გაზის ზედმეტად მაღალ ხარჯებს. Starknet ბლოკებს ასევე ჰქონდათ ფიქსირებული ღირებულება , რომელიც თეორიულად შეიძლება შემცირდეს ზემოთ განხილული იგივე რეკურსიის ტექნიკის გამოყენებით მრავალი ბლოკის მტკიცებულების წარმოებისთვის.


ბლოკის შეფუთვა წყვეტს ამ პრობლემებს რეკურსიული მტკიცებულებების ორობითი ხის გამოყენებით. ჩვენ განვიხილავთ ბლოკის შეფუთვას სტატიის შემდეგ ნაწილში.

ჭანჭიკი ნაწილი 1: პარალელური შესრულება

როგორც ადრე განვიხილეთ, თანმიმდევრული შესრულება არაეფექტურია (და უფრო არაეფექტური იქნება დროთა განმავლობაში) და გულუბრყვილო პარალელური შესრულება აწარმოებს არასწორ შედეგებს. თუმცა, წარმოების პარალელური შესრულების ძრავები ზრუნავენ არათანმიმდევრული შედეგების თავიდან ასაცილებლად.


პარალელური შესრულების დასაძლევად ორი მიდგომა არსებობს: პესიმისტური კონკურენციის კონტროლი (PCC) და ოპტიმისტური კონკურენციის კონტროლი (OCC) . PCC და OCC არის ტრანზაქციის დამუშავების ერთეული (TPU). ქვემოთ მოცემულია ტრანზაქციის დამუშავების ერთეულის განმარტება 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 მიდგომებს ჩვენს სტატიაში პარალელური შესრულების შესახებ.


Starknet-ის ახალი TPU იყენებს OCC მიდგომას. უფრო კონკრეტულად, ეს არის Block-STM ალგორითმის იმპლემენტაცია. Block-STM ახორციელებს ოპერაციებს ოპტიმისტურად ყველა არსებული რესურსით, იმ ვარაუდით, რომ არცერთი მათგანი არ იქნება კონფლიქტი და ამოწმებს შესრულების შემდეგ, რომ არ არის შესრულებული კონფლიქტური ტრანზაქცია ერთდროულად. სანამ Starknet-ის ახალ არქიტექტურას ჩავუღრმავდებით, მნიშვნელოვანია გადავხედოთ რამდენიმე ძირითად განმარტებას:

  1. მდგომარეობა : მდგომარეობა არის ობიექტის მდგომარეობა დროში. ბლოკჩეინის კონტექსტში ის ჩვეულებრივ ეხება მეხსიერების ნაწილის მნიშვნელობას, მაგალითად, მისამართის ბალანსი არის მისი მდგომარეობის (ნაწილი).
  2. სერიულობადობა : ამბობენ, რომ პარალელურად შესრულებამ შეინარჩუნა სერიულობის თვისება, თუ ოპერაციების ნაკრების შესრულება სერიულად და ერთდროულად იძლევა იგივე შედეგებს.
  3. კონფლიქტი : ნათქვამია, რომ ორ ტრანზაქციას ეწინააღმდეგება, თუ და მხოლოდ იმ შემთხვევაში, თუ ერთ-ერთ მათგანს მაინც სურს ჩაწეროს მდგომარეობის იმ ნაწილზე, რომელზეც ორივეს სურს წვდომა (შეიძლება წაიკითხოს ან ჩაწეროს). თუ ორივე ტრანზაქცია იკითხება მხოლოდ მდგომარეობის ნაწილიდან, მაშინ კონფლიქტი არ არის, მაგრამ თუ ერთ-ერთი მათგანი მაინც წერს მდგომარეობის ამ ნაწილს, მაშინ ტრანზაქცია არ შეიძლება განხორციელდეს ერთდროულად, სერიალიზაციის დარღვევის გარეშე. ჩვენ გავაშუქეთ მაგალითი ზემოთ კეიტლინის, დენისა და ელას მაგალითში.
  4. დამოკიდებულება : ამბობენ, რომ txj ტრანზაქცია დამოკიდებულია (ან დამოკიდებულებაზე) txi ტრანზაქციაზე, თუ და მხოლოდ იმ შემთხვევაში, თუ ორივე ტრანზაქცია ჩაიწერება მეხსიერების ერთსა და იმავე ადგილას და txj მოდის txi შემდეგ სერიულ შეკვეთაში. თუ txi მოვიდა txj შემდეგ, txi დამოკიდებული იქნებოდა txj ზე.
  5. მონაცემთა მრავალ ვერსიის სტრუქტურა : მონაცემთა მრავალ ვერსიის სტრუქტურა არის ის, სადაც მონაცემთა სტრუქტურის ახალი ვერსია იქმნება მონაცემთა სტრუქტურაში თითოეული ჩაწერისთვის. ადგილზე მნიშვნელობის შეცვლის ნაცვლად, იქმნება შესაცვლელი მდებარეობის ახალი ჩაწერის სპეციფიკური ვერსია. მრავალვერსიიანი მონაცემთა სტრუქტურების მნიშვნელობა არის ის, რომ ისინი საშუალებას აძლევენ ერთდროულად წაიკითხონ და ჩაწერონ იმავე რეგიონში მეხსიერებაში. ჩვენ განვიხილავთ, თუ როგორ არის ეს სასარგებლო მოგვიანებით.

უცვლელი განმარტებებით, ჩვენ შეგვიძლია გადავიდეთ იმაზე, თუ როგორ მუშაობს Block-STM.

როგორ მუშაობს Block-STM

Block-STM-ის შეყვანა არის ტრანზაქციების რიგი (შეკვეთილი სია), ამ სიას ხშირად BLOCK-ს უწოდებენ. ამ სიის შეკვეთა შესაძლებელია ნებისმიერი გზით; ერთადერთი მოთხოვნაა, რომ არსებობდეს მკაფიოდ განსაზღვრული წესრიგი. ასე რომ, თუ გავითვალისწინებთ 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 = {} .


ტრანზაქციების ამ მოწესრიგებული კომპლექტებით, თითოეული ძაფი გამოიყენება შესრულების ციკლისთვის სამსაფეხურიანი მარყუჟის მეშვეობით:

  1. შეამოწმეთ შესრულებულია
  2. იპოვეთ შემდეგი დავალება
  3. დავალების შესრულება

შეამოწმეთ შესრულებულია

ამ ნაბიჯის დროს ძაფი ამოწმებს V და E. თუ ორივე ცარიელია და არანაირი ტრანზაქცია არ სრულდება, მაშინ ტრანზაქციების მიმდინარე პარტია მთლიანად შესრულებულია და შედეგები შეიძლება დაიდოს შესანახად.

იპოვნეთ შემდეგი დავალება

თუ რომელიმე V ან E შეიცავს ტრანზაქციას, Block-STM ირჩევს ტრანზაქციას ყველაზე დაბალი ინდექსით (არა ინკარნაციის ნომერი) ორივე ტრანზაქციის სიმრავლიდან, ანუ, თუ E შეიცავს {t1,3 , t3,1 and t5,2} და V შეიცავს {t0,1, t2,4, t4,3} , ტრანზაქციის ვალიდაციის დავალება t0 შეირჩევა შემდეგ ამოცანად.

დავალების შესრულება

შემდეგი დავალების იდენტიფიცირებისა და არჩევის შემდეგ ის სრულდება. ამ ნაბიჯის დასასრულს, ალგორითმი ბრუნდება შესრულებულია შემოწმებაზე. ეს პროცესი გრძელდება მანამ, სანამ ტრანზაქციის ორივე ნაკრები ცარიელი არ იქნება.


მოდით შევხედოთ რა ხდება შესრულებისა და ვალიდაციის დროს:


ტრანზაქციის შესრულებისას Block-STM ალგორითმი ავსებს ორ კომპლექტს (თითო ტრანზაქციაზე); წაკითხვის ნაკრები ( Ri,n ) და ჩაწერის ნაკრები ( Wn,i ). წაკითხვის ნაკრები შეიცავს მეხსიერების ყველა ადგილს, საიდანაც წაიკითხა ტრანზაქცია მისი შესრულების დროს, ხოლო ჩაწერის ნაკრები შეიცავს მეხსიერების ყველა ადგილს, სადაც მან დაწერა. შესრულების დროს, ტრანზაქციები ახორციელებენ ჩაწერებს მრავალ ვერსიის მონაცემთა სტრუქტურაზე, მაგრამ კითხვა ცოტა ნიუანსია.


Block-STM-ში, როდესაც ტრანზაქციას სურს წაიკითხოს მონაცემთა სტრუქტურიდან, ის ამოწმებს ყველაზე დაბალი პრიორიტეტული ტრანზაქციის მიერ დაწერილ მნიშვნელობას, რომელსაც აქვს უმაღლესი პრიორიტეტი. მაგალითად, თუ tx1 , tx2 და tx7 ყველა ჩაწერილია მეხსიერების ადგილას და tx5 სურს წაიკითხოს ამ მდებარეობიდან, ის კითხულობს მონაცემთა სტრუქტურის ვერსიას, რომელიც შეესაბამება tx2 .


ეს კეთდება სერიალიზაციის განსახორციელებლად; ვინაიდან tx5 უნდა შესრულდეს tx2 შემდეგ და tx7 მდე, მან უნდა გამოიყენოს tx2 და არა tx7 მიერ დაწერილი მნიშვნელობები. ამ მაგალითში tx7 ხელახლა უნდა შესრულდეს, რადგან მას უნდა წაეკითხა tx5 ით დაწერილი მნიშვნელობები და არა tx2 ან რაიმე უფრო მაღალი პრიორიტეტული ტრანზაქცია. თუ გამოყენებული იქნებოდა მონაცემთა ერთი ვერსიის სტრუქტურა, tx2 ით დაწერილი მნიშვნელობა მიუწვდომელი იქნებოდა და კონფლიქტი აუცილებლად წარმოიქმნება.


ვალიდაციის ამოცანისთვის, ტრანზაქციის წაკითხვის ნაკრები შედარებულია მიმდინარე მნიშვნელობებთან მეხსიერების ადგილებზე, საიდანაც წაიკითხა შესრულების დროს. მაგალითად, თუ tx2 კითხულობს B ანგარიშს შესრულებისას, ვალიდაციის დროს, მეხსიერების მდებარეობა B ანგარიშისთვის იკითხება (წაკითხვის განმარტების გათვალისწინებით, რომელიც ადრე დავადგინეთ). თუ ორი მნიშვნელობა ერთნაირია, მაშინ ეს ნიშნავს, რომ tx2 ის შესრულებისას არცერთი უფრო მაღალი პრიორიტეტული ტრანზაქცია (ვთქვათ tx0 ან tx1 ) არ დაწერილა ამ ადგილას. ეს იწვევს tx2 მონიშნულს, როგორც დადასტურებულ, მაგრამ არაუსაფრთხო ჩადენას.


ტრანზაქცია არ ითვლება უსაფრთხოდ შესასრულებლად, რადგან უფრო დაბალი პრიორიტეტის ტრანზაქცია შეიძლება, ნებისმიერი მიზეზის გამო, განხორციელდეს ტრანზაქციის დადასტურების შემდეგ. ჩვენს გაშვებულ მაგალითში, თუ tx1 ეხება B ანგარიშს და მხოლოდ მას შემდეგ შეეხება, tx2 გაივლის ვალიდაციას, მაშინ tx2 ხელახლა უნდა შესრულდეს.


ამის უზრუნველსაყოფად, ნებისმიერ დროს, როდესაც ტრანზაქცია დაასრულებს შესრულებას, ყველა ქვედა პრიორიტეტის ტრანზაქცია, რომლებმაც გაიარეს ვალიდაცია, ხელახლა გადაირიცხება, რათა არ ეწინააღმდეგებოდეს ტრანზაქციას. მაგალითად, თუ tx1 , tx3 და tx4 დამოწმებულია და tx2 დაასრულებს შესრულებას, tx3 და tx4 ხელახლა უნდა დადასტურდეს, რათა უზრუნველყოფილი იყოს, რომ ისინი არ ეწინააღმდეგებიან (და ასევე დამოკიდებულებებს) tx2 თან.


თუ ტრანზაქცია ვერ დამოწმებულია, ანუ, უფრო პრიორიტეტული ტრანზაქცია, რომელიც იწერება იმავე მდგომარეობაში, შესრულდა მასთან ერთად, მაშინ წერს, რომ შესრულებული ტრანზაქცია ბინძურია (რადგან მნიშვნელობები არასწორია.) მაგრამ ნაცვლად იმისა, რომ წაშალოთ ეს მნიშვნელობები მონაცემთა ბაზიდან. მთლიანად, ისინი მონიშნულია ESTIMATE.


ESTIMATE დროშა ეუბნება ნებისმიერ ტრანზაქციას, რომელიც კითხულობს მეხსიერების ადგილს, რომ მნიშვნელობები არ არის სწორი და ტრანზაქცია შეაჩერებს მათ შესრულებას. ეს კეთდება წაშლის ნაცვლად, რადგან ტრანზაქციის ხელახალი შესრულება, რომლის ვალიდაცია ვერ მოხერხდა, სავარაუდოდ გამოიწვევს მეხსიერების იმავე ადგილებში ჩაწერას, როგორც წინა შესრულება.


მეხსიერების მდებარეობის შეფასებით აღნიშვნით მისი წაშლის ნაცვლად, დამოკიდებულებები (ტრანზაქცია, რომელიც ვერ დადასტურდა) შეიძლება დაიჭიროს ხელახლა შესრულებამდეც, რაც თავიდან აიცილებს არასაჭირო ხელახლა შესრულებას. ეს ევრისტიკა მნიშვნელოვნად ამცირებს ფუჭად მუშაობას.

ყველაფერს ერთად ათავსებ

სრული მიმოხილვა იმის შესახებ, თუ როგორ უახლოვდება Block-STM პარალელიზებას, შეიძლება შეჯამდეს:

  • ტრანზაქციების BLOCK იწყება შეკვეთილი სიით მკაფიოდ განსაზღვრული სერიული შეკვეთით. ეს ტრანზაქციები შესრულებულია ყველა არსებულ რესურსზე პრიორიტეტული თანმიმდევრობით.
  • შესრულების დროს, ტრანზაქციების წაკითხვისა და ჩაწერის კომპლექტების თვალყურის დევნება ხდება და წაკითხვა და ჩაწერა ხორციელდება მონაცემთა მრავალ ვერსიის სტრუქტურაში. როდესაც ტრანზაქცია ასრულებს შესრულებას, ის დამოწმებულია იმის უზრუნველსაყოფად, რომ იგი არ განხორციელებულა ერთდროულად რაიმე კონფლიქტურ ტრანზაქციასთან.
  • თუ ტრანზაქცია გაივლის ვალიდაციას, მაშინ ის ამოღებულია E-დან და V-დან. და როდესაც ტრანზაქცია დამოწმებულია, ყველა ტრანზაქცია უფრო დაბალი პრიორიტეტით, ვიდრე მას, რომელმაც გაიარა ვალიდაცია, გადაიგეგმება ვალიდაციისთვის.
  • თუ ტრანზაქცია ვერ დადასტურდა, ის ხელახლა დაიგეგმება შესასრულებლად. როდესაც ტრანზაქციების მთელი ნაკრები შესრულდება და დამოწმებულია, მაშინ მთელი BLOCK უსაფრთხოა ჩადენისთვის და შედეგები შეიძლება ჩაიწეროს მუდმივ საცავში.


მაგალითი ნაჩვენებია ქვემოთ:


სურათი 6: Block-STM მაგალითი


ეს არის მიმოხილვა, თუ როგორ მუშაობს Block-STM, მეტი დეტალები შეგიძლიათ იხილოთ ჩვენს ანგარიშში აქ და ორიგინალური Block-STM ქაღალდი აქ .

როგორ აუმჯობესებს Block-STM Starknet-ის მუშაობას?

Block-STM-ის დამატების მნიშვნელოვნების რაოდენობრივად შესაფასებლად, ჩვენ შევასრულეთ რამდენიმე საორიენტაციო მაჩვენებელი, რათა შევაფასოთ მისი შესრულების გაუმჯობესება თანმიმდევრულ შესრულებაზე და შედეგები ნაჩვენებია ქვემოთ.


სურათი 7: Block-STM შესრულება 1k ბლოკის ზომით


სურათი 8: Block-STM შესრულება 10k ბლოკის ზომაზე


შედეგები აჩვენებს, რომ ძაფების (დამოუკიდებელი დამუშავების ერთეულების ანალოგიური) რაოდენობის ზრდასთან ერთად, იზრდება შესრულებაც. გაუმჯობესებები უფრო გამოხატულია უფრო დიდი ბლოკებით, რაც იძლევა 9X-მდე გაუმჯობესების შესრულებას მხოლოდ 16 ძაფით თანმიმდევრულ შესრულებასთან შედარებით. ჩვენ აღმოვაჩინეთ, რომ შედეგები უფრო გამოხატულია უფრო დიდი ბლოკებით.


ჩვენი ტესტები აჩვენებს, რომ Block-STM-ის შესრულება მნიშვნელოვნად მცირდება უაღრესად საკამათო დატვირთვის პირობებში, მაგრამ ინდუსტრიის სტანდარტული პრაქტიკა არის ის, რომ დაუბრუნდეს თანმიმდევრულ შესრულებას ასეთ პერიოდებში. ჩვენ ვურჩევთ იგივე მექანიკოსს Starknet-ს, რათა შეინარჩუნოს გამტარუნარიანობა ძალიან საკამათო დატვირთვის პირობებში. მაგრამ, ზოგადად, Block-STM-ის დამატება მნიშვნელოვნად გააუმჯობესებს და მომავალს გამძლე Starknet-ს.


მეორე ძირითადი ცვლილება, რომელიც შეფუთულია v0.13.2 განახლებაში, არის ბლოკის შეფუთვა და ჩვენ ამას შემდეგში გავაშუქებთ.

ჭანჭიკი ნაწილი 2: ბლოკის შეფუთვა

როგორც ადრე განვიხილეთ, Bolt-მდე, Starknet-ის თითოეული ბლოკი იყო საკუთარი სამუშაო, რის შედეგადაც ფიქსირებული იყო თითო ბლოკის ღირებულება თითოეული ბლოკისთვის. გარდა ამისა, სისტემა შეიქმნა ისე, რომ თითოეულ ბლოკს სჭირდებოდა საკუთარი ბლოკი, მიუხედავად იმისა, თუ რამდენ მონაცემს მოიხმარდა ბლოკი.


მსოფლიოში, სადაც ყოველთვის დიდი მოთხოვნა იყო, ეს არ იქნებოდა პრობლემა, მაგრამ Starknet ამჟამად გთავაზობთ უფრო მეტ ბლოკს, ვიდრე მოთხოვნაა და, შესაბამისად, არსებობს უამრავი უაზრო რესურსი, რამაც შეიძლება გამოიწვიოს ასობით ETH დაკარგვა . თვეში. ბოლტამდე სიტუაციის სიმძიმის კონტექსტში გასაგებად, ეს არის ხარჯები, რომლებიც დაკავშირებულია ბლოკის L1-ზე გამოქვეყნებასთან:


  1. 23K გაზი ფაქტის რეგისტრაციაზე – Verify Proof and Register- ის ნაწილი
  2. 56K გაზი თითო რეგისტრის SHARP მეხსიერების გვერდზე
  3. 136K გაზი სახელმწიფო განახლებაზე
  4. 50K გაზი KZG წინასწარ კომპილისთვის ბლომის სინჯისთვის,
  5. 86K გაზი სახელმწიფო განახლების ფუნქციის გასაშვებად.


ეს არის 215 ათასი გაზი თითო ბლოკზე და ეს ღირებულება არის ერთნაირი, ანუ იგივეა, მიუხედავად იმისა, თუ რამდენ მონაცემს შეიცავს თითოეული ბლოკი და დაკავშირებულია ბლოკების რაოდენობასთან $Cost = ბლოკების რაოდენობა * 215000$. ამ პრობლემის იდეალური გადაწყვეტა იქნება, რომ ხარჯები დაკავშირებული იყოს გამოქვეყნებული მონაცემების რაოდენობასთან, ბლოკების რაოდენობის ნაცვლად. და ეს არის ზუსტად ის, რასაც ბლოკის შეფუთვა აღწევს SNAR ხეების მეშვეობით.

SNAR ცდილობს

Starknet Applicative Recursive (SNAR) ხეები არის ორობითი ხის ახალი ტიპი, რომელიც დაინერგა Bolt-ში ზემოთ ხაზგასმული პრობლემების გადასაჭრელად. SNAR ხეს აქვს შემდეგი სტრუქტურა: თითოეული ფოთოლი არის Starknet ბლოკი და ყველა სხვა დონეზე არსებული კვანძები მათი შვილების რეკურსიული მტკიცებულებაა. ძირეული კვანძი, რომელიც არის ყველა სხვა მტკიცებულების რეკურსიული მტკიცებულება, არის საბოლოო სამუშაო, რომელიც იგზავნება SHARed Prover-ში (SHARP).


სურათი 9: SNAR ხე


სურათი 10: SNAR ხე ბლოკში შეფუთვის სამუშაო პროცესი

რას აკეთებს SNAR ხე?

SNAR Tree-ის მთავარი უპირატესობა ის არის, რომ იმის ნაცვლად, რომ გამოქვეყნდეს ერთი ბლოკი თითო მტკიცებულებაში, ბევრი Starknet ბლოკის ამორტიზირება შესაძლებელია იმავე L1 განახლებაში. SNAR ხის ფესვები ახლა განთავსდება L1-ზე მხოლოდ მაშინ, როდესაც ორი კონფიგურირებადი ლიმიტი მოხვდება: ან DA ლიმიტი (მონაცემების ღირებულების 6 ბლოკი) ან მას შემდეგ, რაც ხეს დაემატება ფოთლების გარკვეული რაოდენობა (სადაც ფოთოლი არის ბლოკი) .


ეს დიზაინი აშორებს ტრანზაქციების ღირებულებას ბლოკების რაოდენობისგან. ახლა, ჯერ კიდევ არის გარკვეული ფიქსირებული ღირებულება თითოეული ბლოკისთვის, რომელიც წარმოიქმნება StarkNet OS-ის (SNOS) ყველა ბლოკში გაშვების შედეგად – მაგრამ, ძირითადად, ხარჯები განცალკევებულია. ახლა ეს ნომრებია:


  1. SHARP მეხსიერების რეგისტრაცია თითოეულ სამუშაოზე: 23K გაზი, (იგივე როგორც ადრე)
  2. SHARP მეხსიერების გვერდი თითოეულ სამუშაოზე: 36K გაზი (შემცირებულია 56K-დან SHARP ოპტიმიზაციის წყალობით),
  3. სახელმწიფო განახლება თითო სამუშაოზე ტოლია:
  4. 86K გაზი (იგივე როგორც ადრე) +
  5. 50K გაზი × გამოყენებული ბლოკის რაოდენობა. (როდესაც თითო ბლოკი გამოიყენებოდა, ეს იყო 50K x 1, რის შედეგადაც ზემოთ ციტირებული გაზის რიცხვი 136K იყო).


ნახაზი 11 ქვემოთ გვიჩვენებს, თუ როგორ იცვლება გაზის ხარჯები ბლოკის ნომრის მიხედვით წინა დიზაინში და ახლა (ბოლტის ქვეშ):


სურათი 11: გადამოწმების ხარჯები ბლოკის შეფუთვის გარეშე


აშკარაა, რომ ბლოკის შეფუთვა მნიშვნელოვნად ამცირებს L1-ზე გადამოწმების ხარჯებს, რაც უდავოდ გამოიწვევს Starknet-ის მომხმარებლებისთვის გაზის დაბალ ფასებს.

დასკვნა

Bolt-ში განხორციელებული ცვლილებების ეფექტი: ოპტიმისტური პარალელური შესრულება Block-STM-ის მეშვეობით და ბლოკის შეფუთვა საკუთრების SNAR-ის საშუალებით შეიძლება შეჯამდეს: უფრო სწრაფად და იაფად.


პარალელური შესრულება ამცირებს შესრულების დროს და გაფართოებულ გადატვირთულობას, რაც შეამცირებს გაზის საფასურს მაღალი ტრაფიკის პერიოდებში, ხოლო SNAR ხეები აგვარებენ დაკავშირებულ DA-ს და დადასტურების ხარჯებს. საინტერესოა, რომ ეს განახლება Starknet-ს აქცევს პირველ L2-ად პარალელური შესრულებით და აყენებს მას L2 სივრცეში მთავარ კონკურენტად. მნიშვნელოვანია აღინიშნოს, რომ ნაკლებად სავარაუდოა, რომ ამ ცვლილებების ეფექტი დაუყოვნებლივ შესამჩნევი იქნება, განსაკუთრებით პარალელური შესრულებისას, მაგრამ ისინი გადამწყვეტია მომავლის დამცავი Starknet-ისთვის და მთლიანად Ethereum-ის ეკოსისტემისთვის.


ავტორის შენიშვნა: ამ სტატიის ვერსია ადრე გამოქვეყნდა აქ .