Solana partijos užsakymo pasiūlymas palieka lyderiams galimybę valdyti
Siūloma Solana taisyklė leistų tikrintojams atmesti bloką, kai operacijos vienoje įvedimo partijoje įrašomos ne mokesčių prioriteto tvarka. Ji nenuspręstų, kurios operacijos sudaro bloką. SIMD-0649 ištraukimo užklausa baigta rugsėjo 25 d. nesujungus, todėl šis siauresnis kompromisas paliekamas tolimesnėms diskusijoms, o ne naujos užsakymo taisyklės įgyvendinimui.
Skirtumas yra svarbus prekybininkams, bandantiems numatyti, kur bus užsakymas. Pagal projektą blokų gamintojas, žinomas kaip lyderis, vis tiek pasirinktų, kuriuos sandorius įtraukti ir kaip juos padalyti į partijas. Siūloma konsensuso patikra sudarytų sandorių tvarką viduje kiekvieną užbaigtą partiją galima patikrinti ir vykdyti. Tai nesudarytų vienos prioritetinės eilės visam lizdui.
Solanos knygelė sugrupuoja įrašus į partijas. Projekto projekte neapmokestinami sandoriai kiekvienoje partijoje turėtų būti rodomi nedidėjančia prioriteto tvarka. Bloką pakartojantis tikrintuvas palygintų įrašytus prioritetus ir pažeidimą traktuotų kaip netinkamą bloką. Tai neperskirstytų operacijų į tinkamą seką jas gavus. Vienodo prioriteto sandoriai gali būti rodomi bet kuria tvarka, o paprasti balsavimo sandoriai būtų neapmokestinami.
Prioriteto balas pagrįstas atlygiu, kurį lyderis gauna už įtrauktą operaciją, padalijus iš jo paprašė kaina pagal išankstinio vykdymo sąnaudų modelį. Juodraštyje nurodytas sveikųjų skaičių skaičiavimas su daugikliu ir vieno vieneto apsauga vardiklyje, todėl klientai turėtų apskaičiuoti tą patį rezultatą. Pagal pasiūlyme aprašytas mokesčio taisykles į atlygį įeina pirmenybinis mokestis ir nesudegusi bazinio mokesčio dalis. Todėl balas yra konkretesnis nei paprastas reitingas pagal naudotojo įvardytą mokestį.
Šis pakeitimas suteiktų stebėtojui patikrinamą atsakymą į vieną klausimą: ar tarp neatleistų operacijų, kurias lyderis įtraukė į tą pačią partiją, įrašyta tvarka atitiko siūlomą balą? Autorius teigia, kad bendras patikrinimas padėtų lengviau patikrinti skirtingų tikrintojų klientų ir planuotojų užsakymus. Pasiūlyme nenustatyta, ar sandoris turėjo būti įtrauktas pirmiausia.
Kai Solanos lyderiai išlaiko diskreciją
Projekto ne tikslai palieka lyderiams laisvę pasirinkti sandorius, atidėti juos vėlesniam paketui ir pasirinkti partijos ribas. Šie pasirinkimai gali nustatyti, ar dvi konkuruojančios operacijos kada nors susiduria su tuo pačiu užsakymo testu. Aukšto prioriteto operacija vėlesnėje partijoje nebūtų perkelta į žemesnio prioriteto operaciją ankstesnėje partijoje vien todėl, kad jos balas yra didesnis. Taigi partijos užsakymas yra siauresnė savybė nei užsakymas per visą lizdą arba geriausio vykdymo garantija.
Solanos pasiūlymu bandoma užkirsti kelią akivaizdžiausiam būdui ištuštinti prasmės taisyklę: padaryti partijas tokias mažas, kad beveik nėra ką lyginti. Reikėtų, kad kiekviena siunta, išskyrus paskutinę, apimtų bent du pirminio klaidų taisymo arba FEC rinkinius, duomenų paketų grupes, vadinamus skeltuvais, kurie sudaro bloką. Pagal fiksuoto dydžio FEC taisyklę, nuo kurios priklauso juodraštis, tai reiškia mažiausiai 64 duomenų skilteles. Paskutinė partija vis tiek bus tikrinama užsakymo metu, tačiau jai netaikomas minimalus dydis, nes lizdas gali baigtis nepasipildžius.
Tas minimumas nepanaikina visos diskrecijos. Rugsėjo 23 d. apžvalgoje apžvalgininkas teigė, kad lyderis vis tiek gali uždaryti paketą, kai būtų naudinga atskirti prieštaringus sandorius, ir paprašė pateikti dabartinius paketo dydžio duomenis, suskirstytus pagal planuotoją, klientą ir rinkos sąlygas. Peržiūroje taip pat buvo siekiama atlikti skirtingų minimalių dydžių jautrumo testą. Tai yra prieštaravimai praktiniam taisyklės pasiekiamumui, o ne įrodymas, kad lyderis jau naudojo šią taktiką tinkle.
Projekte teigiama, kad „Agave“ ir „Firedancer“ siekia maždaug dviejų FEC rinkinių partijų, tačiau nei pasiūlyme, nei apžvalgoje nepateikiamas išmatuotas pasiskirstymas, rodantis, kaip dažnai dabartiniai lyderiai gamina mažesnes partijas. Be šių įrodymų minimumo poveikis įprastai blokų gamybai negali būti kiekybiškai įvertintas. Tai gali panaikinti paprastą spragą, tačiau viešasis įrašas nenurodo, kiek tai pakeistų elgesį.
Rugpjūtį vykusi diskusija iškėlė susirūpinimą dėl delsos: patikrinimas, kuris turėjo laukti visos partijos, gali trukdyti Firedancer praktikai atkurti iš dalies gautus duomenis. Patikslintas projektas leidžia tikrintojams palyginti ir vykdyti operacijas, kai jos gaunamos, o tada blokas negalioja, jei vėlesnis palyginimas nepavyksta. Taip pat pripažįstama, kad privertus lyderį laukti, kol pasieks dviejų FEC nustatytų minimumą, gali padidėti transliacijos vėlavimas esant mažam pralaidumui. Šaltiniai to vėlavimo nematuoja.
SIMD-0649 taip pat netrukdys lyderiui teikti pirmenybės savo sandoriams, mokėdamas sau pirmenybinius mokesčius. Projekte teigiama, kad tie mokesčiai grąžinami lyderiui, o sudeginta bazinio mokesčio dalis lieka sąnaudomis. Tai dar viena priežastis, dėl kurios siūlomas užsakymo testas neturėtų būti traktuojamas kaip garantija nuo lengvatinio režimo, MEV ar slydimo.
Rugsėjo 25 d. uždarymas įvyko po raginimo daugiau diskutuoti ir palaikyti klientų kūrėjus. Jei peržiūrėta Solana taisyklė bus tobulinama, jos vertė vartotojams priklausys nuo to, kaip dažnai reikšmingos konkuruojančios operacijos dalijasi paketu ir ar minimalus paketo dydis keičia lyderio elgesį. Viešame pasiūlyme nurodomas būdas patikrinti jų santykinį užsakymą, tačiau trūkstami paketo duomenys palieka neišspręstą faktinio vykdymo nuspėjamumo poveikį.
