By locking liquidity to provide cross-chain routing (as almost every bridge does right now), bridges have placed themselves in a competition they’re bound to lose.
Po kilku exploitach mostów na dużą skalę, dużo tlenu dostaje narracja, że technologia cross-chain jest z natury wadliwa – że interoperacyjność cross-chain oznacza ryzyko. Przy szacowanej na 2 miliardy dolarów stracie w 13 włamaniach do mostów w tym roku, coraz trudniej jest zignorować ten argument.
W deBridge uważamy, że jest to nie tylko konieczne, ale wręcz nieuniknione, aby wszystkie mosty cross-chain całkowicie przemyślały swoje podejście do agregacji płynności.
Ograniczenia zablokowanej płynności
By zablokować płynność, aby zapewnić routing cross-chain (jak prawie każdy most robi teraz), mosty umieściły się w konkurencji, którą na pewno przegrają. Widzimy, jak mosty stają do walki z ustalonymi, celowo zbudowanymi protokołami płynności, takimi jak AAVE, Compound i Frax, projektami, które niewątpliwie będą monetyzować płynność bardziej efektywnie i bezpiecznie. Przykłady mostów z setkami milionów dolarów w TVL, z niezwykle niskim wykorzystaniem zablokowanej płynności.
Przy takiej konstrukcji, projekty mostowe są zmuszone do prowadzenia niezrównoważonych kampanii wydobywczych płynności, które nie oferują długoterminowych rozwiązań w zakresie efektywności kapitałowej. O ile zachęty tokenowe nie będą utrzymywane w nieskończoność – co nie jest rozsądną ambicją dla żadnego projektu – dostawcy płynności nieuchronnie usuną kapitał, aby realizować bardziej dochodowe możliwości.
Aby bezpiecznie agregować płynność, mosty musiałyby nabyć polisy ubezpieczeniowe, aby dać dostawcom płynności możliwość zabezpieczania się przed ryzykiem. Jest to kolejny koszt, który sprawia, że monetyzacja płynności jest jeszcze trudniejsza. Dlatego większość istniejących mostów nie jest rentowna, ponieważ koszty i nagrody za wydobycie płynności często przekraczają zysk netto protokołu.
W grę wchodzą tu również względy architektoniczne, biorąc pod uwagę, że krzyżowy transfer wartości jest żądaniem, które może być rozliczane na różne sposoby. Wszystkie istniejące mosty rozliczają te zlecenia z własnych puli płynności, w których płynność jest stale blokowana, gdy jest potrzebna tylko w dokładnym momencie, gdy transfer wartości powinien zostać zrealizowany.
Różna może być również wielkość zlecenia – jeśli przekracza ono wielkość puli płynności mostu, to nadawca skończy z zawiniętymi tokenami lub nieokreśloną, zawieszoną/stack transakcją. Z drugiej strony, jeśli zlecenie jest zbyt małe w stosunku do wielkości puli płynności, wykorzystanie płynności jest bardzo niskie i nieefektywne. To błędne koło dodatkowo podkreśla, że to podejście protokołu płynności do projektowania mostów jest nieefektywne i fundamentalnie złe.
Solving the security problem
Jakkolwiek ważny jest to problem, ekonomiczna niezrównoważoność nie jest jedynym głównym wyzwaniem. Nawet zakładając, że mosty wymyśliły sposób na wykorzystanie podejścia z zablokowaną płynnością i pozostanie efektywnym kapitałowo, jest już oczywiste, że zbudowanie bezpiecznego protokołu płynnościowego jest zadaniem pochłaniającym wszystko. W istocie, świadomie lub nieświadomie stając się protokołami płynności, projekty mostowe stawiają sobie ogromne zadanie zabezpieczenia wieloaspektowej powierzchni ataku.
Na początek, jednym z oczywistych problemów z zablokowanym mostem w stylu płynnościowym jest to, że tworzy on efekt mnożnika ryzyka, gdzie podatności jednego wspieranego łańcucha mogą rozlać się i narazić na szwank kapitał przechowywany w innych ekosystemach.
W tym miejscu pojawia się kwestia bezpieczeństwa przez pełnomocnika. Most może mieć całą swoją bazę płynności zagrożoną, jeśli istnieje potencjalna luka w bazie kodu jednego wspieranego blockchaina/L2. Widzieliśmy taką możliwość na początku tego roku z luką odkrytą w Optimism, która pozwoliłaby atakującym na wybicie arbitralnej ilości aktywów i przewidywalną wymianę ich na tokeny w innych ekosystemach.
W zeszłym tygodniu odkryłem (i zgłosiłem) krytyczny błąd (który został w pełni załatany) w @optimismPBC (rozwiązanie do skalowania warstwy 2″ dla Ethereum), który pozwoliłby atakującemu na wydrukowanie arbitralnej ilości tokenów, za co wygrałem $2,000,042 bounty. https://t.co/J6KOlU8aSW
– Jay Freeman (saurik) (@saurik) 10 lutego 2022
Again, wszelkie problemy z mechanizmem konsensusu jednego łańcucha mogą również prowadzić do systemowego zarażenia, narażając na ryzyko wszelką płynność zablokowaną w innych wspieranych łańcuchach. W tym przypadku most po prostu rozgłasza exploit do innych łańcuchów. Może to obejmować ataki 51% lub inne błędy na poziomie protokołu.
Oprócz tego typu dziedziczonych zagrożeń, coraz częściej widzimy sytuacje, w których błędy samych projektów mostowych w taki czy inny sposób spowodowały utratę zablokowanej płynności. Od spartaczonych aktualizacji protokołu, złego projektu inteligentnego kontraktu lub skompromitowanej infrastruktury walidatorów, istnieje wiele scenariuszy, w których źli aktorzy mogą wykorzystać luki w samym moście.
Wszystkie te ryzyka szybko się potęgują i – jak widzieliśmy przy zbyt wielu okazjach – są ostatecznie ponoszone przez dostawców płynności, gdy tracą możliwość wykupu swoich opakowanych aktywów. Taka możliwość powinna być nie do przyjęcia.
Niewiele osób zaprzecza ogromnej obietnicy interoperacyjności łańcucha krzyżowego, która może wynieść adopcję Web3 na nowe wyżyny. Jednak wraz z samą wielkością i częstotliwością ataków na mostki, stało się boleśnie jasne, że fundamentalny projekt technologii mostkowej musi być ponownie przemyślany od podstaw. Projekt mostu zamienionego w protokół płynności po prostu nie działa.
Czy jest jakiś sposób, aby opracować fundamentalnie nowe i unikalne podejście do projektowania mostów, takie, które całkowicie usuwa ryzyko dla dostawców płynności, eliminuje wektory ataku, a jednocześnie zachowuje najwyższy poziom efektywności kapitałowej?
W najbliższej przyszłości może być dokładnie to. W deBridge pracujemy nad nowym cross-chainowym routingiem płynności, który rozwiązuje wszystkie te problemy. Stay tuned.
