Shared Sequencers, Inclusion Lists i PBS 2.0: cicha rewolucja MEV na L2, która zmieni DeFi do 2026

Czy „tanie i szybkie” L2 naprawdę rozwiązały problem MEV? Na horyzoncie pojawiają się trzy narzędzia, które mogą przetasować karty w handlu on-chain: shared sequencers, inclusion lists i ewolucja PBS 2.0 (en-shrined PBS) w ekosystemie Ethereum. Wspólnie tworzą one nową mapę przepływu zleceń, cenzuroodporności i dystrybucji wartości pomiędzy walidatorami, budowniczymi bloków, wyszukiwarkami MEV i zwykłymi użytkownikami. Poniżej wyjaśniamy, co to znaczy w praktyce dla giełd DEX, agregatorów, portfeli i traderów.

Co to są shared sequencery i po co powstały?

Shared sequencer to zewnętrzna, współdzielona warstwa kolejkująca (sequencing layer) dla wielu rollupów. Zamiast własnego, pojedynczego sequencera w każdym L2, kilka łańcuchów korzysta z tej samej sieci wstępnego porządkowania transakcji. Celem jest:

• Atomowość międzyłańcuchowa – możliwość łączenia operacji na wielu L2 w jednym, niepodzielnym pakiecie (atomic batch).
• Lepsza cenzuroodporność – węzły shared sequencera mogą mieć mechanizmy rotacji i konsensusu, co utrudnia selektywną cenzurę jednego operatora.
• Spójny rynek MEV – zamiast rozdrobnionych, lokalnych rynków MEV na każdym L2 powstaje wspólny orderflow, który można uczciwiej dzielić i optymalizować.

W praktyce projekty takie jak Espresso, Astria czy Radius eksplorują różne konstrukcje shared sequencing. Równolegle inicjatywy w stylu SUAVE (prywatna warstwa koordynacji zamówień) próbują zbudować neutralny „rynek zamówień” z ochroną prywatności, który może współpracować z wieloma L1/L2. Nie wszystkie podejścia są tożsame, ale łączy je dążenie do ucywilizowania MEV i zagwarantowania użytkownikom przewidywalności realizacji zleceń.

Inclusion Lists i Forced Inclusion — czym różnią się mechanizmy w L1 i L2?

Inclusion lists to propozycja z ekosystemu Ethereum, w której proposer bloku deklaruje listę transakcji „wymaganych do włączenia” w określonym horyzoncie czasowym. Cel: ograniczyć trwałą cenzurę i dać użytkownikom pewność włączenia.

Ethereum (L1): Inclusion Lists (propozycja)

• Proposer publikuje listę transakcji, które muszą zostać zawarte przez builderów.
• Mechanizm współgra z koncepcją PBS (rozdzielenia roli proponującego i budującego blok), aby nie pogorszyć efektywności budowy bloków.
• Korzyść: zwiększona odporność na cenzurę długoterminową, ważna dla zgodności z zasadą neutralności protokołu.

Rollupy (L2): Forced Inclusion i kolejki L1

• Wiele L2 (np. OP Stack, Arbitrum) ma już ścieżki awaryjne – transakcje można „wymusić” przez publikację do L1 inbox, jeśli lokalny sequencer zwleka.
• To gwarancja liveness, ale nie zapewnia priorytetu czy prywatności. Inclusion lists dążą do bardziej proaktywnego włączania.
• W shared sequencerach pojawia się możliwość globalnych inclusion lists – obejmujących wiele L2, co jest nowe i niedostatecznie opisane w literaturze.

PBS 2.0, prywatne orderflow i aukcje przepływu zleceń

Proposer-Builder Separation (PBS) odseparował rolę proponującego blok od budującego go w celu ograniczenia centralizacji MEV. Dyskusje nad wersją ePBS/PBS 2.0 koncentrują się na enshrining (wbudowaniu) mechanizmu w protokół oraz na lepszej obsłudze prywatnego orderflow i prekonfirmacji.

• Prywatny orderflow: użytkownicy i portfele przekazują transakcje do prywatnych mempooli, aby uniknąć sandwichingu, a jednocześnie negocjują lepsze wypełnienia (tzw. orderflow auctions).
• Prekonfirmacje: wstępne gwarancje włączenia, przydatne dla DeFi (np. likwidacje), ale wymagające rygorystycznych warunków odpowiedzialności.
• Integracja z L2: shared sequencer + PBS 2.0 + inclusion lists tworzą spójny łańcuch dostawy zleceń, w którym cenzuroodporność i prywatność można parametryzować.

Jak nowa architektura zmieni MEV na L2: 3 kluczowe wnioski

• MEV stanie się międzyłańcuchowy „z natury”. Zamiast lokalnych sandwichy i backrunów na jednym DEX-ie, rośnie znaczenie atomowych arbitraży pomiędzy rollupami (np. swap na L2-A + pożyczka na L2-B w jednej paczce).
• Ochrona przed sandwichingiem przesunie się do warstwy protokołu. Prywatne mempoole i inclusion lists utrudnią ataki opierające się na jawności mempoola, wymuszając na searcherach bardziej złożone, mniej szkodliwe strategie (np. batch auctions).
• Przewaga „geograficzna” i kolokacja stracą na znaczeniu. Gdy shared sequencer kształtuje globalny porządek, decydująca stanie się jakość algorytmów i integracji z prywatnym orderflow, a nie tylko milisekundy opóźnień w jednym regionie.

Porównanie architektur: lokalny sequencer vs. shared sequencer vs. warstwa koordynacji prywatnego orderflow

Aspekt	Lokalny sequencer L2	Shared sequencer	Prywatna warstwa koordynacji (np. SUAVE-typu)
Opóźnienie	Niskie, lokalne	Niskie–średnie (sieć między L2)	Zależne od ścieżki prywatnej i negocjacji
Atomowość cross-L2	Brak natywnie	Tak (pakiety obejmujące wiele L2)	Możliwa przez prywatne bundlingi
Cenzuroodporność	Ograniczona (pojedynczy operator)	Wyższa (konsensus/rotacja)	Wysoka, jeśli integruje inclusion lists i audyty
Prywatność orderflow	Niska (publiczny mempool lub brak)	Średnia–wysoka (opcjonalne kanały prywatne)	Wysoka (prywatne mempoole, aukcje)
Ryzyko reorg/„theft” MEV	Średnie (lokalne optymalizacje)	Niższe dzięki regułom dystrybucji	Zależne od umów i kryptografii (np. TEEs/MPC)
Udział użytkowników w wartości	Niski	Średni (MEV-smoothing, refundy)	Wysoki (aukcje przepływu, rabaty dla portfeli)

Mini‑case: Atomowy „swap + pożyczka” między Optimism i Base

Wyobraźmy sobie strategię arbitrażową: na Optimism kupujesz token A, a równolegle na Base zaciągasz pożyczkę pod zastaw A, aby sfinansować krótką sprzedaż na innym DEX-ie. W klasycznej architekturze to dwa ryzyka:

• Ryzyko realizacji – jeden leg wchodzi, drugi nie, przez co tracisz spread.
• Ryzyko front‑runningu – jawny mempool zdradza intencję.

W shared sequencerze możesz spakietować obie operacje w atomowy batch z prywatnym ujawnieniem do momentu finalizacji. Jeśli jedna część nie może zostać zrealizowana po zadanej cenie, całość się wycofuje. Dla DEX‑ów oznacza to większą głębokość efektywną, a dla pożyczkodawców mniejsze ryzyko niespójności wyceny zabezpieczeń między L2.

Ryzyka i wektory ataku, o których mało się mówi

• Spam inclusion lists – napastnik może masowo nadawać transakcje „wymagane do włączenia”, aby przeciążyć kolejkę i wymusić niekorzystne priorytety.
• Latentne kartele opóźnień – grupy węzłów mogą wymieniać się wczesnym podglądem prywatnych bundli, jeśli brak jest silnych mechanizmów prywatności/rozliczeń.
• DoS na shared sequencer – choć sieć jest bardziej odporna niż pojedynczy operator, ataki na mosty dostępowe (gateways) mogą zatrzymać dopływ transakcji z części ekosystemu.
• Nieprecyzyjne prekonfirmacje – jeśli warunki anulowania nie są jasne, protokoły likwidacji mogą „ufać” obietnicom, które nie materializują się w finalnym bloku.

Roadmapa wdrożeń: co robić już dziś?

Dla protokołów DeFi

• Moduł prywatnego orderflow: dodaj integrację z dostawcami prywatnych mempooli i prekonfirmacji; zadbaj o tryb awaryjny (publiczny mempool + ograniczenie wielkości slippage).
• Tryb batch‑auction: dla dużych zleceń wprowadzaj okna aukcyjne (co X sekund) zamiast ciągłego AMM, by zmniejszyć przewagę latencji.
• Cross‑L2 intent API: zaprojektuj endpoint, który przyjmie intencję użytkownika i pozwoli egzekwować ją atomowo na wielu L2 przez shared sequencer.

Dla traderów i searcherów

• Rewizja strategii MEV: przenieś uwagę z lokalnych sandwichy na arbitraż międzyłańcuchowy i backruny likwidacji w atomowych pakietach.
• Pomiar ścieżek prywatnych: benchmarkuj czas od submit do prekonfirmacji w różnych kanałach – przewaga to nie tylko ms, ale gwarancje realizacji.
• Ryzyko anulowania: modeluj „fall‑through” – ile transakcji z prekonfirmacją jednak nie wchodzi i jaki ma to koszt dla strategii.

Dla portfeli (Wallets)

• Preferencje użytkownika: przełącznik „ochrona przed sandwichingiem” domyślnie włączony; wyjaśnij wpływ na czas i cenę.
• Transparentność rabatów: jeśli korzystasz z aukcji przepływu zleceń, jasno pokazuj użytkownikowi zwroty z MEV i prowizje.
• Alerty cenzury: informuj, gdy inclusion list lub forced inclusion zostały użyte do wstawienia transakcji.

Dla giełd i mostów

• Mosty z finalnością warunkową: integruj się z prekonfirmacjami shared sequencera, by skrócić czas blokady środków bez pogorszenia bezpieczeństwa.
• Hermetyzacja routingu: używaj prywatnych kanałów dla dużych przepływów, a publicznego mempoola dla drobnicy z limitami rozmiaru.

Słownik pojęć (krótko i konkretnie)

• Shared sequencer – współdzielona sieć porządkowania transakcji dla wielu L2, umożliwiająca atomowość cross‑chain i lepszą cenzuroodporność.
• Inclusion list – lista transakcji, które muszą zostać włączone w określonym oknie czasowym, aby utrudnić cenzurę.
• PBS (Proposer‑Builder Separation) – rozdział roli proponowania i budowy bloków, by ograniczyć centralizację MEV.
• Prekonfirmacja – wstępna gwarancja włączenia transakcji udzielona przed finalizacją bloku.
• Orderflow auction – aukcja prawa do obsługi przepływu zleceń, często z elementami prywatności i rabatami dla użytkowników.

Metryki, które warto śledzić (Narzędzia & Kalkulatory)

• ELT (Entry‑to‑Lock‑in Time) – czas od wysłania transakcji do nieodwracalnej prekonfirmacji.
• FRR (Failed Reservation Rate) – odsetek prekonfirmacji, które nie materializują się w finalnym bloku.
• MEV refund per tx – średni zwrot z aukcji przepływu zleceń przypadający na użytkownika.
• Cross‑L2 slippage – różnica cen aktywów pomiędzy L2 w czasie okna egzekucji atomowego batcha.

Regulacje & Prawo: cienka granica między optymalizacją a manipulacją

Gdy orderflow staje się prywatny i międzyłańcuchowy, definicje „manipulacji rynkowej” i „niewłaściwego uprzywilejowania” mogą uzyskać nowe interpretacje. Operatorzy shared sequencerów i dostawcy prywatnych mempooli powinni:

• Ustanowić polityki równego dostępu oraz logi audytowe (z poszanowaniem prywatności),
• Transparentnie ujawniać opłaty, rabaty i kryteria priorytetyzacji,
• Wdrożyć mechanizmy rozliczeń w przypadku naruszenia prekonfirmacji lub nadużyć.

Podsumowanie i wnioski operacyjne

Shared sequencers, inclusion lists i PBS 2.0 nie są wyłącznie modyfikacją w architekturze – to nowy łańcuch dostawy zleceń dla całego Web3. Zmienia się to, kto widzi transakcję, kiedy ją widzi i na jakich warunkach może ją włączyć. Wygrywać będą ci, którzy połączą ochronę użytkownika (prywatność, anty‑sandwich) z możliwością atomowych operacji między L2.

• Jeśli budujesz DeFi: zaprojektuj ścieżkę prywatnego orderflow i batch auctions już dziś.
• Jeśli tradujesz: przenieś modele zysków na cross‑L2 i mierz ELT/FRR różnych dostawców.
• Jeśli tworzysz portfel: włącz ochronę domyślnie i dziel z użytkownikami korzyści z orderflow.

CTA: Chcesz wiedzieć, które L2 jako pierwsze zaoferują atomowe batch‑e międzyłańcuchowe i prekonfirmacje z refundem MEV? Zapisz się do naszego newslettera i otrzymuj kwartalne raporty „MEV & L2 Architecture Watch”.