Ethereum II-ის მომავალი - ცენზურის წინააღმდეგობა

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

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

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

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

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

დღეს, Ethereum ბლოკების დაახლოებით 90% აშენებულია MEV-Boost-ის საშუალებით, მხოლოდ ორი ერთეული - Beaverbuild და Titan Builder - აშენებენ ამ ბლოკების 95%-ს. ეს კონცენტრაცია იწვევს შეშფოთებას ცენზურის წინააღმდეგობის, ტრანზაქციის სამართლიანობისა და Ethereum-ის ბლოკის წარმოების გრძელვადიანი დეცენტრალიზაციის შესახებ.

მიუხედავად იმისა, რომ ამ მშენებლების მიერ შეფერხებები ან მავნე ქცევა მნიშვნელოვან გავლენას არ ახდენს Ethereum ქსელის უსაფრთხოებაზე, ისინი სერიოზულ საფრთხეს უქმნიან ცენზურის წინააღმდეგობას. თუ MEV-Boost-ის ყველა შემქმნელი გადაწყვეტს ცენზურას მოახდინოს კონკრეტული მომხმარებლების ტრანზაქციები, ამ მომხმარებლებს შეეძლებათ გააგზავნონ ტრანზაქციები მხოლოდ ვალიდატორების მიერ წარმოებული ბლოკებით, რომლებიც არ იყენებენ MEV-Boost-ს, რაც მთლიანი რაოდენობის დაახლოებით 10%-ია. შედეგად, ასეთი ტრანზაქციის დამუშავებას დასჭირდება საშუალოდ 10 ბლოკი (დაახლოებით 2 წუთი).

ეს სიტუაცია ორ მთავარ საკითხს აჩენს:

1. მარეგულირებელი ხარვეზები

პირველ რიგში, ამან შეიძლება Ethereum უფრო დაუცველი გახადოს რეგულაციების მიმართ. მაგალითად, 2022 წელს OFAC-ის მიერ დაწესებულმა Tornado Cash-ის სანქციებმა გამოიწვია მშენებლებისა და ვალიდატორების მნიშვნელოვანი რაოდენობა, რომლებიც ცენზურას ახდენდნენ OFAC-ის მიერ სანქცირებული ანგარიშებთან დაკავშირებული ტრანზაქციების შესახებ.

2. არაკეთილსინდისიერი კონკურენცია პროტოკოლებში, როგორიცაა აუქციონი

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

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

შესაძლო გადაწყვეტა 1: ჩართვის სია

ფონი: Initial Inclusion List Proposal, EIP-7547

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

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

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

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

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

ჩართვის სიის განსახორციელებლად ერთ-ერთი ყველაზე ცნობილი წინადადება იყო EIP-7547 , Forward Inclusion List. ეს წინადადება საშუალებას აძლევდა წინადადებას, ჩართვის სიაში 16-მდე ტრანზაქცია. „გადამისამართების“ მექანიზმი უზრუნველყოფდა, რომ N ბლოკისთვის შემოთავაზებული Inclusion List გამოიყენებოდა N+1 ბლოკზე.

ეს წინადადება თავდაპირველად გამიზნული იყო, რომ ყოფილიყო Ethereum-ის Pectra-ს განახლების ნაწილი, მაგრამ საბოლოოდ ის გამოირიცხა და ერთ-ერთი მიზეზი იყო გადაგზავნის მექანიზმსა და EIP-3074-ს შორის თავსებადობის პრობლემები.

EIP-3074 შემოაქვს Native Account Abstraction-ის ფორმას, რომელიც იყენებს opcode-ს სახელწოდებით AUTHCALL, რომელიც საშუალებას აძლევს ერთ ანგარიშს დაარეგულიროს მრავალი EOA-ის (გარედან საკუთრებაში არსებული ანგარიშები) ნაშთები. ამ მექანიზმს შეუძლია ადვილად შეარყიოს ჩართვის სია.

მაგალითად, დავუშვათ, რომ ალისა მოიცავს ტრანზაქციას (A) ჩართვის სიაში, სადაც მისი EOA უგზავნის ETH-ს ბობს. ამავე დროს, ის ქმნის სხვა ტრანზაქციას (B) EIP-3074-ის AUTHCALL-ის გამოყენებით, რათა გადაიტანოს მისი EOA-ს ყველა ნაშთი სხვა ანგარიშზე. დავუშვათ, B ტრანზაქცია შედის N ბლოკში, ხოლო A ტრანზაქცია შედის N+1 ბლოკის Inclusion List-ში.

აქ არის მთავარი საკითხი: როდესაც შემკვეთი ქმნის Inclusion List-ს, მათ არ იციან, რა ტრანზაქციებს შეიტანს მშენებელი მიმდინარე ბლოკში. ამ სცენარში, B ტრანზაქცია N ბლოკში აქცევს A ტრანზაქციას არასწორი. შესაბამისად, N+1 ბლოკის მშენებელი ვერ შეძლებს სწორი ბლოკის აგებას A ტრანზაქციის ბათილობის გამო Inclusion List-ში.

გაკეთდა მცდელობები ამ საკითხის გადასაჭრელად დამატებითი შეზღუდვების მეშვეობით Inclusion List-ში. თუმცა, მთავარი საკითხი რჩება: EIP-3074 არსებითად იძლევა ბალანსების მანიპულირების საშუალებას სხვა EOA-ებში. მარტივი შემოწმება, როგორიცაა "From" მისამართის დადასტურება, ვერ აღმოაჩენს ჩარევას Inclusion List ტრანზაქციებსა და სხვა ტრანზაქციებს შორის. ამას ჰქვია უფასო მონაცემთა ხელმისაწვდომობის პრობლემა, რომელიც ნახსენებია სტატიაში „უფასო სადილი არ არის - ჩართვის სიის ახალი დიზაინი“.

მიუხედავად იმისა, რომ EIP-3074 გამოირიცხა Pectra-ს განახლებიდან, მსგავსი ფუნქციონალობა - EIP-7702 - იყო ჩართული. შედეგად, ეს საკითხები უნდა მოგვარდეს EIP-7547-ის დანერგვამდე Ethereum-ის ქსელში.

უფრო მეტიც, EIP-7547 შეექმნა დამატებით გამოწვევებს, როგორიცაა შეზღუდვა, რომ მხოლოდ ერთ წინადადებას შეეძლო შეექმნა ჩართვის სია თითო ბლოკზე. ამ ფაქტორებმა გაართულა EIP-7547-ის გამოყენება Ethereum-ის ქსელში, როგორც არის. შესაბამისად, EIP-7547 გამოირიცხა Pectra-ს განახლებიდან.

FOCIL

არ არსებობს ამ საკითხების გადაწყვეტა? ახლახან გადაწყვეტამ, სახელწოდებით FOCIL (Fork-choice Enforced Inclusion Lists) მნიშვნელოვანი ყურადღება მიიპყრო Ethereum-ის ეკოსისტემაში და ითვლება ერთ-ერთ ყველაზე სავარაუდო გადაწყვეტად, რომელიც განხორციელდება Ethereum-ის მთავარ ქსელში. შემოთავაზებული როგორც EIP-7805 , FOCIL შემოაქვს მექანიზმს, სადაც არა მხოლოდ ერთი, არამედ რამდენიმე ერთეული გვთავაზობს ჩართვის სიებს. მისი დეტალები და მახასიათებლები შემდეგია:

თავის არსში, FOCIL იღებს ინკლუზიური სიის კონცეფციას, რაც იმას ნიშნავს, რომ ვინმე ქმნის ტრანზაქციების ჩამონათვალს, რომელიც უნდა იყოს შეტანილი ყველა ბლოკში და შემოთავაზებულებს მოეთხოვებათ მათი ჩართვა. თუმცა, FOCIL განსხვავდება EIP-7547-ისგან ორი მნიშვნელოვანი გზით:

1. ერთი წინადადების ნაცვლად, IL კომიტეტი 16 წევრისგან დამოუკიდებლად სთავაზობს ჩართვის სიებს.
2. N ბლოკისთვის შემოთავაზებული ჩართვის სია შედის თავად N ბლოკში და არა N+1 ბლოკში.

მექანიზმის დეტალები

N ბლოკისთვის Inclusion List-ის აგება იწყება N-1 ბლოკის სლოტით. შემთხვევით შერჩეული IL კომიტეტი 16 ვალიდატორისგან იღებს ბლოკს N-1, აყენებს მას თავის თავად, აყალიბებს შესაბამის ჩართვის სიებს და ავრცელებს მათ peer-to-peer-ის საშუალებით.

მშენებლობის პროცესი 12 წამიან N-1 სლოტში 9 წამში მთავრდება, რის შემდეგაც კომიტეტი სიას ვეღარ დაამატებს. P2P ქსელის მეშვეობით ამ სიების მიღების შემდეგ, N ბლოკის მშენებელმა უნდა შეიცავდეს ისინი ბლოკის აგებისას. N სლოტის დაწყებიდან მალევე, ბლოკი მიეწოდება წინადადებას.

ვალიდატორები, რომლებიც ამოწმებენ N ბლოკს, ადარებენ ტრანზაქციებს მათ მიერ ადრე მიღებულ ჩართვის სიებში და N ბლოკში შეტანილ ტრანზაქციებს შესაბამისობის უზრუნველსაყოფად.

FOCIL-ის უპირატესობები EIP-7547-თან შედარებით

ადრე შემოთავაზებულ EIP-7547-თან შედარებით, FOCIL გთავაზობთ შემდეგ სარგებელს:

1. უფრო მაღალი წინააღმდეგობა ცენზურის მიმართ

თითოეული სლოტი მოიცავს IL კომიტეტს 16 ვალიდატორებისგან, რომლებიც ქმნიან ჩართვის სიას. ეს უზრუნველყოფს უფრო ძლიერ წინააღმდეგობას ცენზურის მიმართ, ვიდრე EIP-7547, სადაც მხოლოდ ერთი ვალიდატორი იყო პასუხისმგებელი.

2. უწყვეტი განხორციელება

კონსენსუსის კლიენტების მიერ გამოყენებული სტანდარტული API forkChoiceUpdate-ის გამოყენებით, ჩართვის სიები შეიძლება უფრო მარტივად და შეუფერხებლად იყოს ინტეგრირებული პროტოკოლში.

3. "რეალურ დროში" ცენზურის წინააღმდეგობა

EIP-7547-ისგან განსხვავებით, სადაც N+1 ბლოკისთვის შემოთავაზებული Inclusion List იწვევს შეფერხებას, FOCIL მოიცავს IL-ს თავად N-სთვის შემოთავაზებულ ბლოკში, რაც საშუალებას აძლევს ტრანზაქციებს შეუფერხებლად ჩაერთოს.

ბლოკების და ჩართვის სიების ეს ერთდროული კონსტრუქცია უზრუნველყოფს თავსებადობას ადრე შემოთავაზებულ ანგარიშის აბსტრაქციის მექანიზმებთან, როგორიცაა EIP-3074 ან EIP-7702. წინა ბლოკებმა არ შეიძლება გააუქმოს ტრანზაქციები ჩართვის სიაში.

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

FOCIL-ის როლი ბლოკებში

FOCIL საშუალებას გაძლევთ შექმნათ 16-მდე ჩართვის სია თითო ბლოკზე, თითოეული სიით შემოიფარგლება 8 კბ (8192 ბაიტი) მაქსიმალური ზომით. თუ 16 ჩართვის სიით შემოთავაზებულ ტრანზაქციებში არ არის გადახურვა, ერთ ბლოკში IL ტრანზაქციის მაქსიმალური ზომა შეიძლება მიაღწიოს 128 KB-ს. ეს შეზღუდვა შექმნილია იმისათვის, რომ მინიმუმამდე დაიყვანოს რესურსების გამოყენება ვალიდატორებისთვის, რადგანაც ჩართვის სიები ვრცელდება P2P ქსელში.

ასე რომ, რამდენი Ethereum ბლოკი შეიძლება აშენდეს IL-ების გამოყენებით FOCIL-ის ქვეშ? ისტორიულად, Ethereum ბლოკის საშუალო ზომა იყო დაახლოებით 80–100KB, მაქსიმუმ დაახლოებით 300KB. თუ 16 ჩართვის სიით შემოთავაზებულ ტრანზაქციებში არ არის გადახურვა, თეორიულად შესაძლებელია მთელი Ethereum ბლოკის აგება მხოლოდ IL ტრანზაქციების გამოყენებით.

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

მოკლედ, FOCIL-ის ჩართვის სიებში ტრანზაქციები სავარაუდოდ დაიკავებს Ethereum-ის ბლოკის 6-10%-დან 100%-მდე, ხოლო საქმეები მიუახლოვდება 6-10%-ის დიაპაზონს, იმ პირობით, რომ IL კომიტეტის წევრები ათვალიერებენ იმავე საჯარო მემპულს.

FOCIL-ის მიღმა: APS-ის FOCIL-თან კომბინაცია

APS-ის ფონი

ერთ-ერთი მიზეზი, რის გამოც FOCIL გახდა წამყვანი გადაწყვეტა, არის მისი პოტენციური სინერგია ატესტერ-პროპოსერის განცალკევების (APS) წინადადებებთან, როგორიცაა Execution Tickets . რა არის APS და როგორ ავსებს ის FOCIL-ს?

APS გვთავაზობს გამიჯვნას ბლოკების შემოთავაზებისა და შემმოწმებლის როლები.

Ethereum-ში, PBS-ის ქვეშ ბლოკის აგება გულისხმობს როლების გაყოფას პროპოსტერებს შორის, რომლებიც გვთავაზობენ ბლოკებს და მშენებლებს, რომლებიც ქმნიან ბლოკის შიგთავსს. ეს ხელს უშლის პროპონანტ-მშენებლის ალიანსების მიერ შექმნილ ცენტრალიზებულ ფსონების აუზებს MEV მოგების მონოპოლიზებაში და გაცილებით მაღალი აპრილის აღრიცხვისგან, ვიდრე ჩვეულებრივი ვალიდატორები, რამაც შეიძლება მოახდინოს ვალიდატორის ოპერაციების ცენტრალიზება.

ეს საკითხი მოგვარდა MEV-Boost-ის მეშვეობით და შემოთავაზებულია პროტოკოლის შიდა სარელეო სისტემა (ePBS) ცენტრალიზაციის დარჩენილი პრობლემების გადასაჭრელად. თუმცა, არის PBS ნამდვილად ოპტიმალური სტრუქტურა?

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

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

ამასთან დაკავშირებით, Ethereum-ის ფილოსოფია არის ის, რომ „კონსენსუსის მონაწილეები არ უნდა იყვნენ წახალისებული, განახორციელონ რთული ამოცანები ინდივიდუალური მოგებისთვის“.

PBS-ის საშუალებით Ethereum გამოყოფს ვალიდატორებს MEV მსახიობებისგან (მშენებლები, მაძიებლები), რათა MEV მოგება თანაბრად გაანაწილოს მთელ ქსელში.

მიუხედავად ამისა, წინადადებებს შეუძლიათ გამოიყენონ არატრადიციული სტრატეგიები დამატებითი მოგების მისაღებად:

1. შეთქმულება წინადადებებსა და მშენებლებს შორის

მშენებლები უკვე ცენტრალიზებულები არიან, მაგრამ წინადადებები ასევე აჩვენებენ გარკვეულ ცენტრალიზაციას. მაგალითად, Coinbase ფლობს მთლიანი ფსონის ETH-ის დაახლოებით 10%-ს. თუ Coinbase შეთანხმებული იყო კონკრეტულ მშენებელთან, რომ მიეღო მხოლოდ მისი ბლოკები, ეს ეკოსისტემაში მნიშვნელოვან ცენტრალიზაციის ვექტორს შემოიღებდა.

2. შემოთავაზებული დროის თამაშები

Ethereum-ის შედარებით გრძელი 12 წამიანი ბლოკის დრო შემოაქვს საინტერესო დინამიკას სახელწოდებით დროული თამაშები, სადაც შემოთავაზებები აყოვნებენ ბლოკის გამოქვეყნებას, რათა მაქსიმალურად გაზარდონ MEV მოგება.

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

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

მიმდინარე Ethereum mainnet-ზე, წერტილი, როდესაც მიიღება ვალიდატორული ხმების 40%, ხდება სლოტში დაახლოებით 3.8 წამში.

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

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

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

მოკლედ, შემოთავაზებული დროის თამაშები შეიძლება უარყოფითად იმოქმედოს Ethereum-ის კონსენსუსის შედეგებზე და თავიდან უნდა იქნას აცილებული.

APS-ის როლი

APS არის გამოსავალი, რომელიც შექმნილია ამ პრობლემის გადასაჭრელად. APS გვთავაზობს შექმნას ცალკე წინადადება შესრულების ფენისთვის, რომელიც მთლიანად გამოყოფს კონსენსუსის ფენას MEV-ისგან.

მაგალითად, ერთ-ერთი წარმომადგენლობითი APS წინადადება, Execution Ticket, წარმოგიდგენთ "აღსრულების წინადადებას", რომელიც განსხვავდება შუქურის ჯაჭვის შემოთავაზებისგან. ამ სისტემაში პროტოკოლი წარმოქმნის და ყიდის შესრულების ბილეთებს, რაც მათ მფლობელებს ანიჭებს უფლებას, შემთხვევითი წესით აირჩიონ, როგორც შესრულების შემოთავაზებები თითოეული ბლოკისთვის. აღსრულების ეს შემოთავაზებები მიიღებენ როლის ნაწილებს, რომლებსაც ამჟამად ასრულებენ შუქურების ჯაჭვის პროპოსტერები MEV-Boost-ში, მიიღებენ შესრულების დატვირთვას და შესთავაზებენ მათ.

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

მაშინ, რა ამოცანებს გაუმკლავდება შუქურის ჯაჭვის შემოთავაზებული APS-ის ქვეშ?

გარდა ვალიდატორის დეპოზიტების, ჯილდოებისა და ჯარიმების მართვისა (მდგომარეობების გადასვლები შუქურ ჯაჭვში), კონსენსუსის ფენის შემოთავაზებას აქვს დამატებითი საკვანძო როლი APS-ში: ჩართვის სიების შექმნა და მათი გადაცემა აღსრულების ფენაზე.

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

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

შეჯამებით, Inclusion List-ზე დაფუძნებული ცენზურის წინააღმდეგობის გადაწყვეტილებები შეუფერხებლად შეესაბამება Ethereum-ის ხედვას APS-ისთვის. შესაბამისად, FOCIL ითვლება ცენზურის წინააღმდეგობის ერთ-ერთ ყველაზე პერსპექტიულ გადაწყვეტად.

FOCIL-ის უპირატესობები

FOCIL უზრუნველყოფს ეფექტურ ცენზურის წინააღმდეგობას, ხოლო ქსელის რესურსების გამოყენებას გონივრულ დონეზე ინარჩუნებს, თითოეული IL-ის 8KB-მდე შეზღუდვით და 16 ვალიდატორისგან შემდგარი IL კომიტეტის არსებობით (რაც იგივეა, რაც ერთი ბლოკის ზომა).

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

შესაძლო გადაწყვეტა 2: მრავალჯერადი თანმხლები წინადადება/მშენებელი

რას იტყვით მრავალ მონაწილეს ერთად შესთავაზონ მთელი ბლოკი? ეს კონცეფცია ცნობილია როგორც "მრავალჯერადი კონკურენტი წინადადება".

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

გარკვეულ პირობებში, ასეთი გადაწყვეტის მიღებამ შეიძლება მნიშვნელოვნად გაზარდოს ცენზურის ღირებულება. Ethereum-ს აქვს მექანიზმი, სადაც ერთდროულად ვლინდება თითოეულ ეპოქაში 32 ბლოკის მომწოდებლები. ეს კონფიგურაცია იძლევა სცენარებს, როდესაც ვინმეს შეუძლია შეეცადოს „მოისყიდოს“ წინადადებები კონკრეტული ტრანზაქციების ცენზურის მიზნით. მაგრამ რა მოხდება, თუ ბლოკები შესთავაზეს არა ერთმა ადამიანმა, არამედ N მომწოდებელმა ერთდროულად? ამ სცენარში, ისეთი მექანიზმის გამოყენება, როგორიცაა პირობითი რჩევები, შესაძლებელს ხდის N წინადადებებს შორის „პატიმრის დილემის“ დანერგვას, რითაც მკვეთრად გაზრდის ცენზურის ღირებულებას.

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

1. თუ ორი ან მეტი წინადადება მოიცავს ტრანზაქციას, ალისა თითოეულ მათგანს აძლევს t-ს მცირე წვერით.
2. თუ მხოლოდ ერთი წინადადება მოიცავს ტრანზაქციას, ალისა ანიჭებს T-ის დიდ წვერს ამ პროპონენტს.

ამ შემთხვევაში, წინადადების მომწოდებლები აღმოჩნდებიან „პატიმრის დილემის“ მსგავს სცენარში. ოპტიმალური სტრატეგია თითოეული შემოთავაზებისთვის ამ თამაშში არის ტრანზაქციის ჩართვა და არა ცენზურა. იმისათვის, რომ ბობმა წარმატებით შეძლოს ალისის ტრანზაქციის ცენზურა, მას დასჭირდებოდა ყველა N შემოთავაზების მოსყიდვა, რაც მას NT დაუჯდა. მეორეს მხრივ, ალისს მხოლოდ Nt-ის დახარჯვა სჭირდება, რათა უზრუნველყოს მისი ტრანზაქციის ჩართვა. ეს მნიშვნელოვნად ზრდის ცენზურის ღირებულებას.

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

ამ განყოფილებაში მოცემულია ორი მექანიზმი ამის მისაღწევად PBS სტრუქტურაში:

1. BRAID - მრავალჯერადი კონკურენტი წინადადება
2. BuilderNet - მრავალჯერადი კონკურენტი აღმაშენებელი

ლენტები

BRAID-ის მიმოხილვა

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

მექანიზმი დაფუძნებულია მარტივ, მაგრამ მძლავრ კონცეფციაზე: იმის ნაცვლად, რომ აწარმოოს ერთი ჯაჭვი, როგორც ამას ახლა აკეთებს Ethereum, k სინქრონიზებული LMD-GHOST ჯაჭვები იმუშავებს პარალელურად. სხვა სიტყვებით რომ ვთქვათ, BRAID-ით, k წინადადებები ერთდროულად აწარმოებენ საკუთარ ბლოკებს თითოეული სლოტისთვის.

როგორ მუშაობს BRAID

ჩნდება აშკარა კითხვა: როგორ მუშავდება k ბლოკები? იმის გამო, რომ ბლოკები საბოლოოდ უნდა იყოს კონსოლიდირებული ერთში ერთი ბლოკჩეინის შესანარჩუნებლად, BRAID იყენებს წინასწარ განსაზღვრულ შეკვეთის წესს მათი შერწყმისთვის.

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

უპირატესობები და შეზღუდვები

BRAID გთავაზობთ რამდენიმე უპირატესობას:

1. ძლიერი ცენზურის წინააღმდეგობა

რამდენიმე წინადადების ერთდროულად მუშაობის მიცემით, BRAID მნიშვნელოვნად ზრდის ცენზურის ღირებულებას, რადგან რამდენიმე სუბიექტს დასჭირდება მოსყიდვა.

2. აღსრულებული ტრანზაქციის შეკვეთა

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

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

თუმცა, BRAID-საც აქვს შეზღუდვა. ვინაიდან ყველა k ჯაჭვი უნდა დარჩეს სინქრონიზებული, ვალიდატორები საჭიროებენ დამატებით ქსელურ რესურსებს. ეს ეწინააღმდეგება Ethereum-ის მიზანს, შემცირდეს ვალიდატორის მოთხოვნები.

BuilderNet

BuilderNet-ის მიმოხილვა

BuilderNet არის გამოსავალი, რომელიც შემოთავაზებულია Flashbots-ის მიერ ცენზურის წინააღმდეგობის გასაზრდელად, რაც საშუალებას აძლევს მრავალ ერთეულს ერთდროულად იმოქმედონ ბლოკის შემქმნელად.

BuilderNet-ის თავდაპირველი ვერსია ახორციელებს მრავალ ოპერატორის მოდელს, სადაც რამდენიმე ერთეული ამუშავებს ერთ მშენებელს სხვადასხვა მარეგულირებელი გაიდლაინების მიხედვით. ეს უზრუნველყოფს ცენზურის უფრო მაღალ წინააღმდეგობას ერთი ოპერატორის შემქმნელთან შედარებით. BuilderNet წარმოადგენს ნაბიჯს Multiple Concurrent Builder გადაწყვეტის შექმნისკენ.

BuilderNet-ის პირველ გამოშვებას ერთობლივად მართავენ Flashbots, Beaverbuild და Nethermind, და სამომავლოდ იგეგმება უფრო მეტი მშენებლის ჩართვა.

მომავალი დეცენტრალიზაციის გეგმები BuilderNet-ისთვის

ამჟამინდელი მულტიოპერატორი მოდელი კვლავ ეჩვენება როგორც ერთი შემქმნელი გარე დამკვირვებლებისთვის, რაც ზღუდავს ცენზურის წინააღმდეგობის დონეს, რომლის მიღწევაც შესაძლებელია. BuilderNet-ის მომავალი გამოშვებები მიზნად ისახავს მისი ქსელის შემდგომ დეცენტრალიზაციას და ცენზურის წინააღმდეგობის გაძლიერებას შემდეგი ცვლილებებით:

1. შეკვეთების გაზიარება მშენებლებს შორის

BuilderNet-ის მომავალი ვერსიები მოახდენს ბლოკების შექმნის პროცესს დეცენტრალიზებას, რაც საშუალებას მისცემს ერთ მშენებელს, შეარჩიოს ტრანზაქციები, რომლებიც ცენზურირებულია სხვა მშენებლის მიერ. თეორიულად, სანამ არსებობს მინიმუმ ერთი არაცენზური მშენებელი, მომხმარებლის ყველა ტრანზაქცია მაინც შეიძლება ჩართული იყოს ბლოკში. მოსალოდნელია, რომ ეს მიდგომა BuilderNet-ს გადააქცევს ნამდვილ Multiple Concurrent Builder მოდელად.

2. დეცენტრალიზებული ინფრასტრუქტურა

BuilderNet-ის ამჟამინდელი ვერსია ეყრდნობა ცენტრალიზებულ ინფრასტრუქტურას ტრანზაქციის შეყვანისა და მონაცემთა შესანახად და მონაწილეობა მოითხოვს ნებართვას. მომავალი ვერსიები მიზნად ისახავს ამის მოგვარებას BuilderNet-ის უნებართვო გახდომით.

TEE უკეთესი UX და DX-ისთვის

BuilderNet ასევე ქმნის უფრო კომფორტულ გარემოს აპებისთვის, საფულეებისთვის, მაძიებლებისთვის და მომხმარებლებისთვის სანდო აღსრულების გარემოს გამოყენებით.

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

მაძიებლების გარდა, აპლიკაციებსა და საფულეებს, რომლებიც მიზნად ისახავს MEV-ის დაჭერას, ასევე შეუძლიათ ისარგებლონ BuilderNet-ის არქიტექტურით.

BuilderNet L2-ში

BuilderNet-ის საყურადღებო ასპექტია მისი პოტენციური გამოყენებადობა Layer 2 გადაწყვეტილებებზე.

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

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

BuilderNet-ისთვის ბლოკის აუთსორსინგით, L2-ებს შეეძლოთ მიაღწიონ ცენზურის უფრო მაღალ წინააღმდეგობას, ვიდრე ცალკეული სეკვენსერები, ხოლო MEV-ის გადანაწილების ჩართვა TEE-ით ტრანზაქციის იძულებითი შეკვეთით, არქიტექტურის მსგავსი, როგორიცაა Unichain.

დასკვნა

იდეალურ შემთხვევაში, ბლოკჩეინებმა წინააღმდეგობა უნდა გაუწიონ ცენზურას და Ethereum-ის საზოგადოებამ შემოგვთავაზა სხვადასხვა გადაწყვეტილებები მშენებლების ცენტრალიზებით გამოწვეული ცენზურის წინააღმდეგობის საკითხების გადასაჭრელად. ყველაზე პერსპექტიულ გადაწყვეტებს შორის არის FOCIL, სადაც 16 ვალიდატორი გვთავაზობს ჩართვის სიებს თითოეული ბლოკისთვის, რომელიც გთავაზობთ ეფექტურ ცენზურის წინააღმდეგობას და თავსებადობას APS-თან. სავარაუდოდ, FOCIL განიხილება Fusaka-ს განახლებაში ჩართვისთვის, რომელიც დაგეგმილია 2025 წლის ბოლოს ან 2026 წლის დასაწყისში.

პარალელურად, მიმდინარეობს დისკუსიები Multiple Concurrent Builder-ის მოდელებზე, რომელსაც ხელმძღვანელობს Flashbots. მშენებლების დეცენტრალიზებამ შეიძლება მნიშვნელოვნად გააუმჯობესოს Ethereum-ის ცენზურის წინააღმდეგობა და შეიძლება განხორციელდეს Ethereum-ის ძირითადი განვითარებისგან დამოუკიდებლად, რაც უფრო სწრაფად მიღების საშუალებას იძლევა.

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

ამ სტატიის ვერსია თავდაპირველად გამოქვეყნდა აქ .