Autor oryginału: APRIORI ⌘
Oryginalna kompilacja: Shenchao TechFlow
wprowadzić
W procesie poprawy wydajności blockchain w celu osiągnięcia zastosowań na dużą skalę, Monad skutecznie optymalizuje model maszyny wirtualnej Ethereum (EVM). Te ulepszenia rozwiązują wąskie gardła w wykonywaniu i problemy z nieefektywnym dostępem do stanu na platformach takich jak Ethereum, bez poświęcania decentralizacji.
W tym artykule zbadano możliwość zbudowania solidnej infrastruktury aukcyjnej o wartości wydobywczej (MEVA) na Monadach, opierając się na cennym doświadczeniu Flashbotów na Ethereum i Jito Network na Solanie.
Chcielibyśmy podkreślić kilka kluczowych punktów:
MEV jest nieodłączną właściwością każdej sieci blockchain. Solidna infrastruktura MEVA ma kluczowe znaczenie dla uniknięcia negatywnych skutków zewnętrznych i nieprawidłowego dostosowania motywacji w procesie produkcji bloków.
Projekt MEVA jest ściśle powiązany z mechanizmem leżącym u podstaw łańcucha bloków, zwłaszcza z fazą realizacji konsensusu. Przyszłe ulepszenia będą zależeć od ewolucji tych czynników i działania sieci pod różnymi obciążeniami.
Historyczne trendy w produkcji bloków na Ethereum i Solanie mogą stanowić punkt odniesienia przy projektowaniu MEVA na Monadach.
W przypadku wysokowydajnego łańcucha bloków o opóźnionym wykonywaniu, takiego jak Monad, MEVA może wymagać probabilistycznej konstrukcji bloków i strategii wyszukiwania podobnych do handlu o wysokiej częstotliwości, aby poradzić sobie z ograniczeniami czasowymi.
Badając te pytania, mamy nadzieję dostarczyć wglądu w projektowanie infrastruktury MEVA, która uwzględnia unikalne potrzeby architektoniczne i wydajnościowe firmy Monad.
Tło MEVA w Ethereum
MEVA na etapie realizacji konsensusu Ethereum
W Ethereum najpierw należy osiągnąć konsensus. Kiedy węzły zgadzają się co do bloku, uzgadniają nie tylko listę transakcji w bloku, ale także pierwiastek Merkle, który jest podsumowywany po wykonaniu bloku. Dlatego też wnioskodawca musi wykonać wszystkie transakcje w bloku przed rozpowszechnieniem propozycji. Jednocześnie węzły weryfikacyjne również muszą wykonać te transakcje przed głosowaniem.
Rysunek 1: Przepływ pracy konstruktora w przypadku separacji proponującego i budującego (PBS) w MEV-Boost
Rysunek 1 przedstawia typowy przepływ pracy konstruktora w przypadku separacji proponującego i budującego (PBS) w MEV-Boost. Gdy konstruktor ukończy budowę bloku, przesyła go do przekaźnika, który przekazuje blok do klienta warstwy wykonawczej (EL) w celu symulacji i sprawdzenia poprawności.
Ponieważ wykonanie jest warunkiem wstępnym konsensusu, budowniczy budujący blok musi przekazać go do klienta warstwy wykonawczej (EL) i przeprowadzić symulację bloku, aby sprawdzić jego ważność. Oprócz swojej niezbędnej roli w fazie osiągania konsensusu, faza symulacji przynosi również korzyści konstruktorom i poszukiwaczom.
Z perspektywy konstruktora: symulując każdą transakcję, konstruktorzy mogą dokładnie oszacować wartość bloku dla siebie i walidatorów. Mogą także spróbować zmienić kolejność transakcji, aby zminimalizować wycofania i zmaksymalizować opłaty za gaz lub napiwki podstawowe pobierane z puli pamięci i transakcji pakietowych. Dokładne szacunki pozwalają im oferować wyższe stawki w przypadku walidatorów.
Z perspektywy wyszukującego: Ponieważ kreator odfiltrowuje transakcje łączone, które mogą zostać wycofane przed umieszczeniem transakcji w łańcuchu, wyszukujący może zapewnić wykonanie strategii, zwiększając pewność. Dodatkowo osoby wyszukujące mogą uzyskać dostęp do najnowszego statusu bloku. Kiedy warstwa konsensusu (CL) propaguje nowy blok, osoby wyszukujące mogą wykorzystać stan tego bloku jako punkt wyjścia do konstruowania zyskownych transakcji łączonych. Jednocześnie istnieją oznaki, że kreatorzy oferują obecnie więcej transakcji poza protokołem lub funkcji, które umożliwiają wyszukiwarkom uzyskanie informacji o statusie nadchodzących bloków w celu dodania strategii awaryjnych do nadchodzących bloków.
Jednakże rozwój PBS doprowadził do zwiększonej centralizacji budowy bloków, podobnie jak to ma miejsce w tradycyjnym handlu, gdzie firmy konkurują o dedykowane kanały sieci mikrofalowej, aby nadać priorytet realizacji strategii arbitrażowych.
W miarę dojrzewania sieci produkty ulegają iteracji
Teraz badamy, jak ewoluowała MEVA wraz z ewolucją Ethereum, jak pokazano na rysunku 2.
Rysunek 2: Chronologiczny widok MEVA w miarę ewolucji sieci Ethereum
Era priorytetowej aukcji gazu (PGA).
Jak pokazano na rysunku 3, wyszukiwarki identyfikują zyskowne możliwości MEV i przesyłają inteligentne transakcje kontraktowe do publicznej pamięci. Ta widoczność publiczna prowadzi do przetargów publicznych i aukcji jednej ceny w sieci, w przypadku których nawet nieudane transakcje wiążą się z opłatami za gaz.
W tym okresie pojawiła się wysoce konkurencyjna i kosztowna nieustrukturyzowana działalność MEV, taka jak transakcje z identycznymi parami (konto, ogłoszenie) i rosnące stawki, co prowadziło do przeciążenia sieci lub niestabilności konsensusu.
Rysunek 3: Prosty schemat aukcji gazu priorytetowego
Flashboty i EIP-1559
Aby rozwiązać te problemy, Flashboty wprowadziły przekaźniki jako pośredniczące domy aukcyjne pomiędzy poszukiwaczami a producentami bloków (górnikami w epoce PoW). Posunięcie to przekształca rynek pojazdów MEV z aukcji pierwszej ceny z licytacją otwartą w licytację zapieczętowaną. Jak pokazano na rysunku 4, przekaźniki pomagają zapobiegać eskalacji ofert w publicznej puli pamięci i ustanawiają bardziej uporządkowany i bezpieczny proces produkcji bloków.
Struktura opłat EIP-1559 również odgrywa tutaj rolę. Upraszcza to licytację poprzez opłaty podstawowe, ale nie rozwiązuje problemu kolejności transakcji w blokach, który nadal napędza MEV poprzez opłaty priorytetowe. W rzeczywistości wielu wyszukiwarek wcześniej licytowało bezpośrednio górników za pośrednictwem transferów z bazy monet. Skończyło się na tym, że mieli więcej skarg dotyczących opłat za korzystanie z bazy monet, ponieważ nie mogli już przesyłać transakcji pakietowych bez gazu.
Rysunek 4: MEVA z przekaźnikami
Oddzielenie oferentów i budowniczych (PBS)
Po zakończeniu fuzji Ethereum i przejściu na Proof-of-Stake (PoS), wdrożono separację wnioskodawców i konstruktorów (PBS), aby jeszcze bardziej zoptymalizować rozdział ról w rurociągu produkcji bloków. Jak wspomniano wcześniej, przekaźniki działają obecnie jako pośrednicy między twórcami bloków a wnioskodawcami, odpowiedzialni za zapewnienie dostępności danych i ważności bloków. Ponieważ oferenci mogą łączyć wielu wykonawców w celu realizacji różnych transakcji prywatnych, budowniczowie muszą konkurować, płacąc oferentom opłaty. Dynamikę tę przedstawiono na rysunku 5.
Rysunek 5: MEVA w erze PBS
ryzyko koncentracji
Pomimo tych historycznych osiągnięć należy podkreślić rosnące ryzyko koncentracji na rynku budowlanym. W ciągu ostatniego roku dziewięciu największych producentów konsekwentnie zdobywało ponad 50% rynku, co pokazuje wysoki stopień koncentracji rynku, jak pokazano na rysunku 6. Obecny stan koncentracji jest jeszcze bardziej wyraźny – trzech najlepszych budowniczych pokrywa ponad 90% bloków.
Rysunek 6: Udział w rynku producentów materiałów budowlanych, liczba ta ilustruje wysoki stopień koncentracji panujący na rynku materiałów budowlanych (źródło zdjęcia)
Jito na Solanie
Architektura systemu Jito
Jako standardowy MEVA w Solanie, Jito został stworzony, aby zaradzić wysokiemu poziomowi spamu transakcyjnego w Solanie ze względu na niskie koszty transakcji. Dopóki opłata za nieudaną transakcję (około 0,000005 SOL) nie przekracza oczekiwanego zysku, spamowanie jest skutecznie zachęcane.
Według raportu Jito Labs z 2022 r. w tym roku nie powiodło się ponad 96% prób arbitrażu i likwidacji, a bloki zawierały ponad 50% transakcji związanych z MEV. W raporcie stwierdzono również, że boty likwidacyjne wysłały do sieci miliony zduplikowanych pakietów tylko po to, aby dokończyć tysiące udanych likwidacji, co skutkowało wskaźnikiem awaryjności przekraczającym 99%.
Rysunek 7: MEVA Jito na Solanie
Powaga problemu zewnętrznego MEV na Solanie skłoniła Jito do opracowania warstwy MEVA zaprojektowanej w celu wprowadzenia porządku i pewności w procesie produkcji bloków. Przyjrzyjmy się oryginalnej architekturze MEVA zaproponowanej przez Jito, pokazanej na rysunku 7.
Jito składa się z następujących komponentów:
Relayer – działa jako serwer proxy do odbierania transakcji i przekazywania ich do silnika blokowego (lub łańcucha dostaw MEVA) i walidatorów.
Block Engine - odbiera transakcje od przekaźników, koordynuje wyszukiwania, akceptuje paczki, wykonuje symulacje paczek i przekazuje najlepsze transakcje i paczki do walidatorów w celu przetworzenia. Warto zauważyć, że Jito prowadzi aukcje częściowego bloku w celu włączenia do pakietów, a nie aukcje pełnego bloku i historycznie przetwarzało ponad 80% pakietów w dwóch przedziałach.
Pula pseudopamięci — tworzy okno czasowe operacji trwające około 200 milisekund za pośrednictwem klienta Jito-Solana, uruchamiając dyskretną aukcję przepływu zamówień. Jito zamknął tę pamięć 9 marca 2024 r.
Wybory projektowe Jito
Przyjrzyjmy się konkretnym komponentom projektu systemu Jito i zastanówmy się, w jaki sposób te wybory projektowe wynikają z procesu produkcji bloków Solany.
Jito obsługuje tylko aukcje częściowych bloków, a nie kompilacje pełnych bloków, prawdopodobnie ze względu na brak globalnego harmonogramu w wielowątkowym modelu wykonywania Solany. W szczególności rysunek 8 przedstawia równoległe wątki wykonujące transakcje, przy czym każdy wątek utrzymuje własną kolejkę transakcji oczekujących na wykonanie. Transakcje są losowo przydzielane do wątków i porządkowane lokalnie według opłaty priorytetowej i czasu. Bez globalnego uporządkowania po stronie harmonogramu (przed aktualizacją 1.18.x) transakcje Solany z natury podlegałyby niedeterminizmowi z powodu zakłócania harmonogramu. Dlatego w MEVA osoba wyszukująca lub weryfikator nie może wiarygodnie określić bieżącego stanu.
Rysunek 8: Wielowątkowy model wykonania klienta Solana. Należy zauważyć, że faza łączenia MEVA jest dołączona do kolejki wielowątkowej jako oddzielny wątek
Z inżynierskiego punktu widzenia równoległe uruchamianie silnika blokowego Jito jako dodatkowego wątku dobrze pasuje do wielowątkowej architektury Solany. Chociaż aukcja pakietów zapewnia priorytetowe zamawianie w oparciu o opłaty w ramach wątku silnika blokowego Jito, nie ma gwarancji, że pakiety będą zawsze na całym świecie miały pierwszeństwo przed transakcjami użytkowników.
Aby rozwiązać ten problem, Jito wstępnie przydziela część przestrzeni bloku do wątku łączenia, aby zapewnić miejsce w bloku na wiązanie. Chociaż niepewność pozostaje, podejście to zwiększa prawdopodobieństwo pomyślnej realizacji strategii. Zachęca to również wyszukujących do wzięcia udziału w aukcji zamiast spamowania sieci transakcjami. Rezerwując miejsce w blokach na łączenie, Jito jest w stanie osiągnąć równowagę pomiędzy promowaniem uporządkowanych aukcji a łagodzeniem chaotycznych skutków spamu transakcyjnego.
Usuń pseudopulę pamięci
Powszechne przyjęcie Jito przyniosło pozytywne rezultaty w łagodzeniu problemów ze spamem w Solanie. Według badań p2p i danych pokazanych na rysunku 9, względna produktywność bloków znacznie wzrasta po przyjęciu klienta Jito. Pokazuje to, że przetwarzanie transakcji stało się wydajniejsze dzięki wprowadzonemu przez Jito w 2023 roku zoptymalizowanemu silnikowi blokowemu.
Rysunek 9: Dowód na to, że Jito skutecznie łagodzi problem spamu na platformie Solana. Ten diagram pochodzi z badania przeprowadzonego przez zespół p2p
Chociaż poczyniono znaczne postępy, pozostaje wiele wyzwań. Ponieważ pakiety Jito tylko częściowo wypełniają bloki, transakcje wywołane MEV mogą w dalszym ciągu ominąć kanał aukcyjny Jito. Część dowodów można znaleźć w panelu Dune Dashboard na rysunku 10, z którego wynika, że od 2024 r. w sieci nadal średnio ponad 50% transakcji nie powiodło się z powodu transakcji spamowych typu bot.
Rysunek 10: Panel Dune przedstawiający aktywność spamową botów w Solanie od maja 2022 r. (szczegóły można znaleźć w Dune)
9 marca 2024 roku Jito zdecydowało się zawiesić swoją flagową pulę pamięci. Decyzja ta wynikała ze wzrostu liczby transakcji memecoinami i wynikającego z tego wzrostu liczby ataków kanapkowych (w których osoby wyszukujące umieszczają transakcje przed transakcją docelową i po niej), co ostatecznie miało wpływ na wygodę użytkownika. Podobnie jak w przypadku kanału przepływu zamówień prywatnych MEVA w Ethereum, zamknięcie publicznego mempool może ułatwić rozwój przepływu zamówień prywatnych poprzez współpracę z usługami front-end, takimi jak dostawcy portfeli i boty Telegram. Wyszukiwacze mogą nawiązać współpracę bezpośrednio z walidatorem, aby uzyskać pierwszeństwo w zakresie realizacji, włączenia lub wykluczenia.
W rzeczywistości Rysunek 11 pokazuje godzinne zyski bota kanapkowego największej prywatnej wyszukiwarki pamięci po zamknięciu pamięci.
Największa prywatna wyszukiwarka pamięci:
3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81
(Nota tłumacza: robot kanapkowy to powszechne narzędzie ataku front-run, wykorzystywane głównie w celu uzyskania zysków w transakcjach typu blockchain).
Rysunek 11: Zysk bota kanapkowego na godzinę przy użyciu prywatnej pamięci dla wyszukiwarki „3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”
Decyzja Jito o zamknięciu mempoolu pokazuje zaangażowanie zespołu w rozwiązywanie podstawowych problemów w ekosystemie Solana. Oprócz iteracji MEVA lub ulepszania mechanizmu opłat za gaz Solany, Jito pomaga protokołowi zmniejszyć ryzyko ataku poprzez wybory w zakresie projektowania interfejsu użytkownika, takie jak ograniczenie domyślnych parametrów poślizgu. Niezależnie od tego, czy poprzez zmiany w strukturze opłat, które powodują, że transakcje spamowe będą droższe, czy też poprzez modyfikacje protokołu komunikacyjnego, infrastruktura Jito będzie nadal odgrywać kluczową rolę w utrzymaniu dobrego stanu i stabilności sieci Solana.
Projekt MEVA na Monadzie
Opóźnione wykonanie i jego wpływ na MEVA
W przeciwieństwie do Ethereum, gdzie uzgodnienie bloku wymaga listy transakcji (wraz z kolejnością) i korzenia Merkle podsumowującego wszystkie stany po zdarzeniu, Monady oddzielają poprzednie wykonanie od konsensusu. Protokół węzła musi jedynie rozwiązać oficjalny problem porządkowania. Jak pokazano na rysunku 12, każdy węzeł niezależnie realizuje transakcje w bloku N, gdy zaczyna osiągać konsensus w bloku N+1. Takie rozwiązanie pozwala na budżet gazu odpowiadający pełnemu czasowi bloku, ponieważ wykonanie musi jedynie dotrzymywać kroku konsensusowi. Ponieważ węzeł wiodący nie jest wymagany do obliczenia pierwiastka stanu de facto, wykonanie może wykorzystać cały okres konsensusu do przetworzenia następnego bloku.
Rysunek 12: Opóźnione wykonanie Monady w porównaniu z fazą konsensusu wykonania w Ethereum. Operacyjne okna czasowe pokazane są również z punktu widzenia projektu MEVA
Definiujemy operacyjne okno czasowe jako ramy czasowe, które pozwalają MEVA na ukończenie propozycji budowy bloków na Monadzie, która jest wykonalna i opłacalna w porównaniu z domyślną metodą budowania bloków. Model opóźnionego wykonania ma dwie bezpośrednie konsekwencje:
Kiedy MEVA jest tworzona dla N-tego bloku w oknie czasu operacji, walidatory jednocześnie osiągają konsensus w sprawie listy transakcji dla N-tego bloku, próbując zakończyć wykonanie N-1-go bloku. Zatem w N-tym oknie czasowym działania możliwy dostępny stan nadal znajduje się na poziomie N-2-tym. Oznacza to, że w przypadku architektury z opóźnionym wykonaniem nie ma gwarancji, że przekaźnik lub konstruktor ma „najnowszy stan”. Dlatego nie jest możliwa symulacja najnowszego bloku, dopóki nie zostanie wygenerowany następny blok, co prowadzi do niepewności.
Biorąc pod uwagę 1-sekundowy czas blokowania Monady, okno czasowe działania MEVA jest niezwykle ograniczone. Oznacza to, że konstruktorzy mogą nie mieć wystarczająco dużo czasu na symulację transakcji i łączenie pełnych bloków po kolei, jak to zwykle ma miejsce w Ethereum. Wiele zmiennych może mieć wpływ na czas wymagany do przeprowadzenia symulacji handlowej na EVM. Jednakże zakładając, że symulowanie transakcji zajmuje od 10^1 do 10^2 mikrosekund (przybliżone szacunki) i że Monada celuje w 10^4 transakcji na sekundę, symulowanie pełnego bloku w samym oknie czasowym operacji może zająć około 1 sekundy . Biorąc pod uwagę czas blokowania Monady wynoszący 1 sekundę, dla konstruktora lub przekaźnika wykonanie wielu symulacji pełnych bloków w celu optymalizacji bloków będzie wyzwaniem.
Strategie probabilistycznego konstruktora a strategie poszukiwacza
Biorąc pod uwagę te ograniczenia, niepraktyczne jest przeprowadzanie pełnej symulacji blokowej w operacyjnym oknie czasowym i przeprowadzanie symulacji w oparciu o najnowszy stan. Ponieważ konstruktorom brakuje teraz zarówno czasu, jak i najnowszego statusu, aby poznać dokładną końcówkę każdej transakcji, muszą wywnioskować wskazówkę osoby poszukującej na podstawie prawdopodobieństwa wycofania transakcji, opierając się na reputacji lub (prawdopodobnie najlepiej) obierając za cel symulację statusu N-2. . To sprawia, że wycena bloku jest mniej pewna.
Ze względu na brak teoretycznych gwarancji przed wycofywaniem transakcji, osoby wyszukujące stają w obliczu większej niepewności wykonania, gdy walidatory zaakceptują blok zbudowany przez konstruktora. Kontrastuje to z Ethereum, gdzie wyszukiwarki konkurują w dedykowanych kanałach przepływu zamówień prywatnych do konstruktorów, realizując stosunkowo deterministyczne strategie. Przy tym ustawieniu prawdopodobieństwa względnego w Monadach wyszukujący są teraz narażeni na większe ryzyko wycofania pakietów, co skutkuje bardziej niepewnym profilem PnL wykonania. Przypomina to sytuację traderów o wysokiej częstotliwości, którzy realizują transakcje w oparciu o sygnały probabilistyczne i z czasem osiągają nieco wyższe oczekiwane zyski.
Rysunek 13: Konceptualny diagram widma ilustrujący różne paradygmaty projektowania MEVA, sklasyfikowany zgodnie z zakresem kontroli lub symulacji proponowanych bloków
Jak pokazano na rys. 13, zakres wcześniejszej kontroli pakietowania/blokowania przez wykonawcę stwarza spektrum niepewności w zakresie wyceny lub wyceny proponowanych bloków. Z jednej strony znajduje się model PBS w stylu Ethereum z dokładnymi cenami, w którym konstruktorzy muszą używać klientów warstwy wykonawczej (EL) do symulowania transakcji w proponowanych blokach. Muszą poruszać się po szerokim portfolio przesłanych pakietów. Na drugim końcu znajduje się optymistyczny model konstruktora [16], z asynchronicznym sprawdzaniem bloków. W tym modelu konstruktorzy omijają czas wymagany na jakąkolwiek symulację w oknie czasowym operacyjnym i wypłacają napiwki pokazane weryfikatorom lub przekaźnikom, składając zabezpieczenie (które może zostać obniżone). Probabilistyczne podejście do sprawdzania lub częściowej symulacji zaproponowane tutaj w Monadach leży gdzieś pośrodku, zwiększając prawdopodobieństwo, że poszukiwacz pomyślnie wykona strategię pomimo pewnej niepewności.
Na przykład animator rynku księgi zamówień w ramach łańcucha DEX może z wyprzedzeniem zmieniać swoje pozycje za pośrednictwem MEVA po wykryciu głównych jednokierunkowych ruchów cen, aby uniknąć niekorzystnej selekcji. Ta probabilistyczna strategia pozwala im działać szybko, nawet bez najnowszych informacji o statusie, równoważąc ryzyko i nagrodę w dynamicznym środowisku handlowym.
Wniosek
MEVA odgrywa kluczową rolę w optymalizacji produkcji bloków, łagodzeniu wpływów zewnętrznych i poprawie stabilności systemu. Ciągły rozwój platformy MEVA, takiej jak Jito w Solanie i różne wdrożenia w Ethereum, znacznie ułatwił rozwiązywanie problemów ze skalowalnością i bardziej dostosowane zachęty dla uczestników sieci.
Monad to obiecująca sieć w powijakach, która oferuje społeczności wyjątkową możliwość zaprojektowania najlepszego możliwego MEVA. Biorąc pod uwagę wyjątkowe oddzielenie wykonania od konsensusu w Monad, zapraszamy badaczy, programistów i walidatorów do współpracy i dzielenia się spostrzeżeniami. Ta współpraca pomoże stworzyć solidny i wydajny proces produkcji bloków, pomagając Monad zrealizować obietnicę jako wysokoprzepustowa sieć blockchain.