Front-running w Ethereum to niemały problem, który (w opinii niektórych specjalistów) sprawia, że korzystanie z sieci króla smart kontraktów jest co najmniej niebezpieczne. O co chodzi we front-runningu i jak sobie z tym poradzić?
Smart kontrakty, które wiążą się z płatnościami, muszą być bezpieczne. Jak podkreślili Dan Robinson i Georgios Konstantopoulos w poście z 2020 r., wiele łańcuchów bloków, w tym Ethereum, jest pod tym względem słabo zabezpieczonych. Badacze porównali tę sytuację do ciemnego lasu, spopularyzowanego przez autora science fiction Cixin Liu, w którym ujawnienie się zachęca napastnika do ataku.
W przypadku smart kontraktów, gdy jedna z jego stron emituje żądanie zapłaty, może to zostać zauważone przez kogoś, kto zechce przejąć środki dla siebie. To tak, jakby za każdym razem, gdy w restauracji zostawiasz na stole pieniądze za posiłek, ktoś wpadał znienacka i zabierał kasę. To oczywiste, że w takiej sytuacji restauracja nie pociągnęłaby zbyt długo…
W jednym ze swoich ostatnich opracowań, Joshua Gans i Richard Holden opisali nowe i proste do wdrożenia rozwiązanie do zapobiegania atakom typu front-running nakierowanym na blockchainowe smart kontrakty. Wymaga to dodania pewnego fragmentu kodu (którego przykład znajdziesz tutaj), które panowie nazwali Solomonic Clause (klauzulą salomońską). Nazwa – rzecz jasna – inspirowana jest sposobem, w jaki 3000 lat temu problemy miał rozwiązywać słynący ze swej mądrości króla Salomon.
Gans i Holden zwrócili uwagę, że w przeciwieństwie do innych rozwiązań, zaproponowany przez nich sposób nie wymaga zmian protokołu bazowego w łańcuchach bloków ani stosowania kryptografii. „Jesteśmy ekonomistami specjalizującymi się w teorii wdrożeń – gałęzi teorii gier – która koncentruje się na projektowaniu procedur zapewniających bezpieczeństwo transakcji i kontraktów bez egzekwowania ich z zewnątrz” – napisali badacze.
Front-running a mempool
Mówiąc najprościej, front-running to atak, w którym bot uprzedza normalną transakcję podczas oczekiwania na dodanie jej do bloku, ustawiając wyższy koszt gazu, aby zakończyć transakcję po preferencyjnej stawce, zanim jeszcze zaatakowana transakcja dojdzie do skutku.
Mempool to zestaw transakcji Ethereum, które zostały rozesłane do sieci i czekają na to, aby zostać „zapakowanymi” w bloki. Tu właśnie leży przesłanka do realizacji front-runningu. Front-runningowy bot analizuje i znajduje cele, które mogą zostać zaatakowane, nieprzerwanie skanując transakcje w mempool. Poniższy obrazek pokazuje przeglądarkę mempool, która umożliwia subskrybowanie transakcji w puli i przeglądanie wszystkich ich szczegółów za pomocą rozmaitych filtrów:
Tło problemu
Problem został zauważony już w 2014 roku przez pmcgoohan na Reddit:
Górnicy widzą oczywiście cały kod kontraktu, który uruchamiają, a kolejność uruchamiania transakcji zależy od poszczególnych minerów.
Co można zrobić, aby powstrzymać front-running ze strony górnika w dowolnej implementacji kontraktu w Ethereum?
Przykładowo, na zdecentralizowanej giełdzie ethereum mógłbym uruchomić instancję górnika (a raczej wielu górników) przetwarzającego transakcje giełdowe. Kiedy pojawia się duże zlecenie kupna, mogę je opóźnić we wszystkich moich węzłąch, złożyć u siebie zlecenie kupna jednocześnie u wszystkich moich górników, a następnie przetworzyć pierwotną transakcję. Uzyskałbym najlepszą cenę i prawdopodobnie mógłbym nawet sprzedać z natychmiastowym zyskiem.
Nie potrzebowałbyś niczego bliskiego 50% mocy wydobywczej, ponieważ nie łamiesz żadnych zasad sieci. Prawdopodobnie byłoby to opłacalne, nawet gdyby działało tylko przez krótki czas, ponieważ w środowisku niskich opłat transakcyjnych można byłoby pozwolić sobie na wiele chybień w zamian za kilka trafień.
Jak podkreślili Gans i Holden, powyższe wywołało dyskusję, za którą nie poszło zbyt wiele konkretnych działań. Naturę i skale problemu unaocznia poniższy film Scotta Bigelowa:
W jaki sposób inicjowany jest front-running?
Oto, co ma się stać w odniesieniu do smart kontraktu:
- W łańcuchu bloków zapisywany jest kontrakt, w myśl którego środki zostaną wysłane do portfela w chwili, gdy dostarczony zostanie dowód wykonania cyfrowej umowy.
- Ktoś spełnia wymagania, a następnie przesyła transakcję wraz z powiązanymi opłatami transakcyjnymi do mempool.
- Memopool jest publiczny i jest źródłem transakcji, które górnicy (lub walidatorzy w PoS) wykorzystują w celu dołączenia do łańcucha bloków. Decyzję o nadaniu pierwszeństwa transakcjom, które mają być rejestrowane w bloku, górnicy opierają na wysokości swojej „nagrody” wyrażonej w opłacie transakcyjnej.
- Wraz z dostarczeniem dowodu wykonania, smart kontrakt zwalnia środki.
Do front-runningu może dojść pomiędzy realizacją kroków 2 i 3. To właśnie wtedy transmitowana transakcja może być obserwowana i nieznacznie zmieniana przez innych – w szczególności boty – w celu skierowania płatności do alternatywnego portfela.
Pod każdym innym względem, łącznie z dowodami wykonania, transakcja jest taka sama. Zapewnia to okres czasu, w którym górnik może zarejestrować swoje roszczenia w łańcuchu bloków, a ponieważ proces ten wiąże się z pewnym opóźnieniem, może on potencjalnie zostać zarejestrowany z wcześniejszym znacznikiem czasu, na tym samym lub wcześniejszym bloku niż prawowita strona wnosząca roszczenie. Co ważne, taki scenariusz może zostać znacząco uprawdopodobniony w przypadku oferowania wyższych opłat transakcyjnych.
Taki front-running jest bardzo podobny do opisanego Michaela Lewisa we Flashboys. Tam front-running polegał na ściganiu się, aby skorzystać z możliwości arbitrażu, które powstają w ciągu nanosekund po tym, jak ktoś zaangażuje się w zakup aktywów na rynkach finansowych, ale zanim jeszcze transakcja zdoła dotrzeć na rynek. Ten sam rodzaj front-runningu ma miejsce w łańcuchach bloków, aby wykorzystać podobne możliwości arbitrażu między giełdami kryptowalut. W ciągu ostatnich kilku lat dało to górnikom, którzy sprawują ostateczną kontrolę nad zlecaniem transakcji, możliwość „wydobycia” wartości przekraczającej pół miliarda dolarów. Zjawisko to określane jest również często jako MEV (Miner Extraction Value) (więcej na ten temat w sekcji linków na końcu artykułu).
Próby rozwiązania problemu
Front-running, który stał się przedmiotem zainteresowania Gansa i Holdena jest tak problematyczny, że w rzeczywistości sprawia, że zawieranie smart kontraktów jest po prostu bardzo niebezpieczne.
W próby rozwiązania tego problemu zaangażowało się wielu prominentnych przedstawicieli społeczności deweloperskiej Ethereum. Jedno z takich rozwiązań zostało zaproponowane przez Vitalika Buterina w komentarzach do posta na Reddicie z 2014 roku:
Jednym z pomysłów jest przetwarzanie żądań w partiach, a nie sekwencyjnie. Mogłyby one być gromadzone w ramach kilku bloków, a następnie w liście wszystkich żądań, które pojawiły się w tym czasie, posortowanej według ceny i dopasowującej je jedno po drugim. Jeśli przyjąć, że „kilka” bloków to około 5, to będzie wystarczająco dużo różnych górników, aby każde z tych żądań zostało rozpatrzone.
Pomysł dotyczy w pewnym sensie „kompresji” czasu. Po wykonaniu tej czynności można przeprowadzić bardziej przejrzystą aukcję priorytetów, która potencjalnie zmniejszyłaby przeciążenie sieci. Nie zapobiega to bezpośrednio front-runningowi, ale – jak sugerowali niektórzy – opłaty pobierane z takich aukcji można by wykorzystać na finansowanie pewnego rodzaju „dóbr publicznych”. Są jednak tacy, którzy się na takie rozwiązania nie zgadzają (Ed Felten).
Innym rozwiązaniem, które mogłoby pomóc wyeliminować front-running, jest użycie kryptografii do ukrycia transakcji w pamięci i odszyfrowania ich po zapisaniu w bloku. Tego typu rozwiązanie jest na celowniku ekosystemu Cosmos. To rozwiązałoby problem, aczkolwiek wdrożenie wymagałoby zmian na poziomie protokołu. Odchodzi również od ducha publicznego łańcucha bloków, co dla niektórych użytkowników może być dość niepokojące:
Salomonowe rozwiązanie Gansa i Holdena
W przypadku wielu stron ubiegających się o płatność z tytułu kontraktu, mamy do czynienia z sporem dotyczącym własności zasobów cyfrowych.
Kiedy król Salomon stanął w obliczu sporu dotyczącego tego, która z dwóch kobiet jest prawdziwą matką dziecka, zgodnie z przekazem biblijnym ujawnił prawdę, proponując przecięcie dziecka na dwoje. To zadziałało, ponieważ prawdziwa matka sprzeciwiła się, podczas gdy fałszywa pozostała tej propozycji obojętna. Ostatecznie Salomon oddał dziecko prawdziwej matce.
Badacze teorii gier zauważyli, że gdyby fałszywa matka rozumiała ten mechanizm, najpewniej również by się sprzeciwiła, a Solomon nadal musiałby nieco bardziej pogłowić się na temat tego, co zrobić z dzieckiem.
Projektując takie mechanizmy wypada musimy założyć, że wszystkie zaangażowane osoby rozumieją mechanizm. Gans i Holden proponują, aby transakcje były gromadzone w partiach (jak sugerował Buterin) i tworzyły pulę potencjalnych transakcji.
- Wszyscy, których roszczenia są zarejestrowane w łańcuchu bloków, muszą uiścić pewną opłatę transakcyjną.
- Uprawniony „powód” jest siłą rzeczy (z konieczności) częścią tej puli, ponieważ bez jego udziału górnicy nie mogliby procesować zadanych transakcji.
- Zarówno „uprawniony” jak i „nieuprawniony” do otrzymania transakcji wiedzą o swoim istnieniu.
Innymi słowy, ta sytuacja jest taka sama jak w przypadku sądu Salomona – wszyscy poza nim znają prawdę. Sztuczka mechanizmu polega na wykorzystaniu tego faktu do ujawnienia prawdy.
Takie mechanizmy mają bogatą historię zastosowania w ekonomii (John Moore i Rafael Repullo 1988). Samo rozwiązanie problemu wydaje się zależeć od cech zaangażowanych podmiotów.
Co wiemy o cechach w naszym przypadku? Można zakładać, że strony nieuprawnione obchodzą wyłącznie zyski. Jakie są ich oczekiwania dotyczące uzyskania tokenów i czy to wystarczy, aby uzasadnić opłaty transakcyjne, które muszą ponieść? Ta część jest zatem relatywnie prosta – zależy im na pieniądzach.
Ale co ze stroną uprawnioną? Oczywiście, ta również dba o pieniądze. Jest jednak coś więcej: wykonała ona bowiem również „pracę”, aby oczekiwać zapłaty z tytułu wywiązania się z umowy. Badacze przypuszczają, że prawdopodobnie nie jest jej obojętne, kto otrzyma zapłatę. Zakłada się więc, że gdyby miała wybierać, wolałaby na przykład spalić tokeny niż pozwolić, aby trałiły one w ręce podmiotów nieuprawnionych.
Biorąc to pod uwagę, Gans i Holden proponują następujący mechanizm:
- Jeśli w puli jest jeden pretendent, to właśnie on otrzymuje tokeny (sprawa załatwiona).
- Jeśli jest więcej niż jeden zainteresowany, przechodzimy do etapu wyzwania (challenge state).
Na etapie wyzwania może wydarzyć się kilka rzeczy. W mechanizmie Gansa i Holdena wybiera się losowo jednego interesanta i prosi się go (chociaż odpowiedź może być wcześniej zaprogramowana) o zgłoszenie roszczenia lub wycofanie się z wyzwania. W przypadku potwierdzenia, tokeny ulegałyby spaleniu. W przypadku wycofania się, zgłaszający roszczenie byłby usuwany z puli, a jego miejsce zajmowałby kolejny. On – rzecz jasna – otrzymywałby takie samo pytanie.
Pytanie brzmi: w jaki sposób etap wyzwania wpływa na zachęty do ubiegania się o tokeny?
Strona roszcząca bezprawnie wie, że prawdziwy powód jest w puli i będzie dochodzić swojego roszczenia. Nie ma więc możliwości, aby kiedykolwiek otrzymała tokeny. Front-running nie zadziała. Podmiot nieuprawniony będzie wydawać opłaty transakcyjne, aby dostać się do puli pretendentów, która nigdy nie da jej tokenów.
Symulację tak zaproponowanego rozwiązania możesz przeanalizować tutaj:
Wniosek
Gans i Holden wierzą, że „salomonowy mechanizm” jest bardzo obiecujący, jeśli chodzi o bezpieczeństwo smart kontraktów. Jest zakorzeniony w solidnej teorii ekonomicznej i relatywnie prosty do wdrożenia.
Daj znać w komentarzach, co sądzisz na ten temat.
Chcesz wiedzieć więcej?
***
Artykuł został opracowany na podstawie tłumaczenia opracowania zat. Lighting up the Ethereum Dark Forest, którego autorami są Joshua Gans i Richard Holden; źródło: link
Źródła: