Walidatorzy Mysten wprowadzają dzisiaj 1.52 (), co przynosi OGROMNE ulepszenie nie tylko dla @DeepBookonSui, ale także dla w pełni onchainowego produktu wieczystego Aftermath. Chciałem napisać szybki wątek, zanim jakiś cmo/sui kol napisze jakąś słabo zbadana bzdurę, która źle przedstawia tę funkcję, którą uważam za jeden z najlepszych rozwójów wychodzących z Mysten w tej chwili. Było wiele dyskusji na temat priorytetowania anulacji po sukcesie Hyperliquid (jestem dużym fanem HL). Jednak uważam, że takie podejście działa tylko w specyficznym środowisku Hyperliquid, a nie na ogólnym L1, takim jak Sui. Jedną z rzeczy, które osobiście mi się nie podobają w priorytetyzacji anulacji, jest moje zaniepokojenie potencjalnie toksycznymi anulacjami, gdzie mms mogliby oszukiwać system, czekając na anulacje lub anulując, jeśli wypełnienie nie jest dla nich dobre, lub coś, co negatywnie wpływa na biorców. Jedną z rzeczy, z których się cieszę, jest to, że angażowanie się w zachowania oszukańcze nie jest tak łatwe w Aftermath, ponieważ jesteśmy w pełni onchain. To, co ten PR faktycznie robi, to ujawnia referencyjną cenę gazu (RGP) i rzeczywistą cenę gazu dla inteligentnych kontraktów poprzez nową funkcję TxContext. Umożliwia to kontraktom dostęp do minimalnej ceny gazu bieżącej epoki (ustawionej przez walidatorów, KTÓRĄ TRZEBA OBNIŻYĆ!!) oraz tego, co użytkownicy faktycznie zapłacili. Ale oto dlaczego to dla mnie i deepbook jest dużą sprawą, to tworzy fundament dla priorytetyzacji transakcji na poziomie kontraktów. Oznacza to, że mogę wdrożyć logikę, w której makerzy, którzy płacą powyżej określonego progu ceny gazu (można dostosować w kontraktach), mają swoje anulacje przetwarzane z priorytetem nad standardowymi transakcjami biorców. Ponieważ makerzy mogą widzieć zarówno cenę referencyjną, jak i wiedzieć, że muszą zapłacić przynajmniej X kwotę powyżej niej, tworzy to sprawiedliwy, przejrzysty, rynkowy mechanizm priorytetyzacji bez toksycznego oszukiwania możliwego w zamkniętych systemach. Moim zdaniem to naprawdę dobre hybrydowe rozwiązanie!

Błąd z mojej strony. "anulowania są priorytetowe tylko nad maker, a nie nad taker"