Droga Ethereum do odporności na cenzurę: BRAID vs. FOCIL

W ewoluującym krajobrazie Ethereum, walka o odporność na cenzurę wprowadziła kilka innowacyjnych mechanizmów. Wśród nich BRAID i FOCIL wyróżniają się jako dwa obiecujące podejścia mające na celu ochronę integralności sieci poprzez zminimalizowanie ryzyka cenzury transakcji.

Oba te rozwiązania odnoszą się do krytycznych kwestii w procesie proponowania bloków, ale przyjmują zasadniczo różne podejścia do osiągnięcia swoich celów. Niniejszy artykuł zagłębia się w niuanse tych dwóch mechanizmów i bada, który z nich może ostatecznie okazać się bardziej skuteczny.

Zrozumienie zagrożenia cenzurą w Ethereum

Rdzeniem procesu generowania i walidacji bloków Ethereum są dwa główne podmioty: budowniczowie i proponenci. Konstruktorzy są odpowiedzialni za sortowanie transakcji i przesyłanie bloku do proponentów, którzy następnie wybierają jeden blok do podpisania i zaproponowania blockchain.

Proces ten stwarza jednak potencjalną lukę w zabezpieczeniach. Ponieważ wnioskodawcy mają ostateczny głos w sprawie tego, który blok zostanie zaproponowany, istnieje ryzyko zmowy między wnioskodawcami a twórcami w celu cenzurowania niektórych transakcji, zagrażając w ten sposób zasadzie odporności Ethereum na cenzurę.

Odporność na cenzurę ma kluczowe znaczenie dla zachowania uczciwości i przejrzystości łańcucha bloków. Jeśli wnioskodawcy mogą selektywnie uwzględniać lub wykluczać transakcje, podważa to zdecentralizowany charakter sieci i może prowadzić do wykorzystywania zamówień transakcji, co skutkuje takimi kwestiami jak wartość wydobywana przez górników (MEV).

Istniejące rozwiązania: MCP i FOCIL

Aby sprostać temu wyzwaniu, zaproponowano kilka rozwiązań odpornych na cenzurę, przy czym dwa z najczęściej omawianych to mechanizmy Force Inclusion List (FOCIL) i Multi-Concurrent Proposer (MCP).

Force Inclusion List (FOCIL)

FOCIL został zaprojektowany w celu zapewnienia uczciwości poprzez zaangażowanie losowo wybranej komisji walidatorów w każdym przedziale czasowym.

Walidatory te tworzą lokalne listy włączające w oparciu o ich poglądy na temat puli mempool i rozgłaszają te listy.

Następnie wnioskodawca łączy te lokalne listy w ostateczną listę, która jest dodawana do bloku.

Mechanizm ten zapewnia, że żaden pojedynczy wnioskodawca nie ma pełnej kontroli nad transakcjami zawartymi w bloku, zmniejszając w ten sposób ryzyko cenzury.

Walidatory weryfikują, czy blok jest zgodny z zasadami konsensusu przed zaakceptowaniem go w łańcuchu bloków.

Multi-Concurrent Proposer (MCP)

MCP wprowadza koncepcję wielu jednoczesnych wnioskodawców, co po raz pierwszy zasugerował Max Resnick w mechanizmie Multiplicity.

W tym systemie kilku wnioskodawców pracuje równolegle, a każdy z nich wybiera część transakcji z puli mempool.

Transakcje te są pakowane w „specjalne pakiety transakcji” i podpisywane przez wnioskodawców. Główny wnioskodawca musi zawrzeć co najmniej dwie trzecie tych pakietów w proponowanym bloku, aby został on uznany za ważny.

Metoda ta decentralizuje władzę pojedynczego wnioskodawcy i znacznie obniża prawdopodobieństwo cenzury transakcji.

BRAID: Ulepszona implementacja MCP

Opierając się na koncepcji MCP, Max Resnick opracował BRAID, bardziej zaawansowaną i kompletną implementację MCP.

Wprowadzony podczas seminarium „DeFi in MEV Era” zorganizowanego przez Paradigm, BRAID umożliwia wielu wnioskodawcom jednoczesne proponowanie bloków w różnych równoległych łańcuchach.

Bloki te są następnie synchronizowane za pomocą mechanizmu konsensusu w celu zapewnienia spójności między łańcuchami.

Warstwa wykonawcza Ethereum konsoliduje wszystkie bloki wygenerowane w slocie w jeden blok wykonawczy, w którym transakcje są deduplikowane, porządkowane i wykonywane zgodnie z wcześniej zdefiniowanymi regułami.

Podejście to znacznie ogranicza uprawnienia pojedynczego podmiotu do manipulowania zapisami transakcji.

Kluczową zaletą BRAID jest unikanie dodatkowych ról lub złożonych struktur motywacyjnych, które mogą zwiększać złożoność.

Jednak koordynacja synchronizacji w wielu podłańcuchach i obsługa przetwarzania danych stwarza własne wyzwania.

Wyzwania i rozważania dotyczące BRAID

Pomimo swoich mocnych stron, BRAID nie jest pozbawiony problemów. Jednym z godnych uwagi wyzwań jest model „warunkowego napiwku”, który wymaga od użytkowników posiadania płynności finansowej, aby zapewnić, że ich transakcje są odporne na cenzurę. Użytkownicy muszą ustawić dwie wartości napiwków podczas przesyłania transakcji:

1. Wyższa końcówka (T): Maksymalna kwota, jaką użytkownik jest skłonny zapłacić, aby upewnić się, że jego transakcja zostanie uwzględniona, nawet w przypadku próby cenzury. Jeśli tylko jeden wnioskodawca uwzględni transakcję, otrzyma pełną kwotę T.
2. Dolna końcówka (t): Mniejszy napiwek, który jest wypłacany, jeśli transakcję uwzględni wielu wnioskodawców. W takim przypadku napiwek jest rozdzielany między wnioskodawców, którzy zawarli transakcję.

Model ten, choć skutecznie zniechęca do cenzury, wprowadza dodatkową złożoność i koszty dla użytkowników. Muszą oni zarezerwować dodatkową płynność w momencie transakcji, która może zostać zamrożona do czasu ustalenia, czy będzie potrzebna.

Aby rozwiązać te problemy, Jonahb z Blockchain Capital sugeruje dwa potencjalne rozwiązania:

• Dowód płynności po ustaniu stanu: To podejście pozwala użytkownikom przedstawić dowód, że będą mieli wystarczającą płynność, aby zapłacić wyższy napiwek po wykonaniu transakcji. Wymaga to jednak od wnioskodawców zrozumienia stanu po transakcji, co stanowi wyzwanie w przypadku transakcji obejmujących stan współdzielony lub złożone operacje finansowe.
• Ubezpieczenie od cenzury: Koncepcja ta wprowadza zewnętrznych dostawców ubezpieczenia od cenzury (CI), którzy gwarantują napiwek użytkownika w zamian za opłatę. Zmniejsza to natychmiastowe obciążenie płynności dla użytkowników, ale wymaga rozwoju rynku między użytkownikami a dostawcami CI.

Perspektywy społeczności: FOCIL vs. BRAID

Społeczność Ethereum jest podzielona co do względnych zalet FOCIL i BRAID. Terence, deweloper klienta Ethereum Prysm, docenia fakt, że BRAID nie wymaga dodatkowych uczestników, upraszczając proces w porównaniu do FOCIL, który wprowadza dodatkowe ograniczenia czasowe na przesyłanie i weryfikację list włączenia. FOCIL jest jednak ogólnie uważany za łatwiejszy do wdrożenia i bardziej elastyczny.

Dan Robinson, badacz z Paradigm, chwali BRAID za jego podejście do priorytetyzacji transakcji, skutecznie zmniejszając ryzyko MEV. Podkreśla on również mechanizm warunkowego napiwku jako silną zachętę przeciwko cenzurze – aspekt, którego brakuje FOCIL.

I odwrotnie, deweloper Dev faworyzuje FOCIL ze względu na jego prostotę i solidną odporność na cenzurę, co sugeruje, że FOCIL oferuje prostszą implementację z mniejszą liczbą komplikacji.

Badacz Ethereum barnabe.eth przyznaje, że chociaż BRAID może oferować ulepszenia w niektórych obszarach, jest ostrożny co do całkowitego porzucenia modelu opartego na liderach, na którym opiera się FOCIL i inne projekty IL, powołując się na potrzebę dalszych badań i dowodów w celu potwierdzenia wykonalności BRAID.

Wnioski: Który mechanizm jest lepszy?

Debata między BRAID i FOCIL podkreśla złożoność osiągnięcia odporności na cenzurę w Ethereum. Innowacyjne podejście BRAID do decentralizacji władzy proponenta i zmniejszenia ryzyka MEV jest przekonujące, ale wiąże się z poważnymi wyzwaniami wdrożeniowymi i wymaga dalszego rozwoju.

FOCIL, choć prostszy i bardziej elastyczny, może nie oferować takiego samego poziomu odporności na wyrafinowane próby cenzury.

Ostatecznie wybór między BRAID i FOCIL może zależeć od konkretnych priorytetów sieci Ethereum w danym momencie. W miarę rozwoju ekosystemu oba mechanizmy mogą odgrywać rolę we wzmacnianiu odporności Ethereum na cenzurę, zapewniając, że sieć pozostanie wierna swoim zdecentralizowanym zasadom.