Op-ed: Reimagining cross-chain bridges: przestańmy próbować być protokołami płynności

Po wielu eksploatacjach mostów na dużą skalę, dużo tlenu nabiera narracji, że technologia cross-chain jest z natury wadliwa – że interoperacyjność cross-chain oznacza ryzyko. Szacuje się, że w tym roku stracono 2 miliardy dolarów w wyniku 13 włamań do mostu, a ignorowanie tego argumentu staje się coraz trudniejsze.

At deBridge, uważamy, że nie tylko konieczne, ale i nieuniknione jest, aby wszystkie mosty cross-chain całkowicie przemyśleły swoje podejście do agregacji płynności.

Ograniczenia zablokowanej płynności

Blokując płynność w celu zapewnienia routingu międzyłańcuchowego (jak to obecnie robi prawie każdy most), mosty wzięły udział w konkurencji, którą z pewnością przegrają. Widzimy, jak mosty mierzą się z ustalonymi, specjalnie opracowanymi protokołami płynności, takimi jak DUCH, Mieszanka, fraks, projekty, które bez wątpienia będą skuteczniej i bezpieczniej monetyzować płynność. Przykłady obfitują w mosty z setkami milionów dolarów w TVL, z wyjątkowo niskim wykorzystaniem zablokowanej płynności.

Dzięki temu projektowi projekty pomostowe są zmuszone do prowadzenia niezrównoważonych kampanii wydobywania płynności, które nie oferują długoterminowych rozwiązań zapewniających efektywność kapitałową. O ile symboliczne zachęty nie będą utrzymywane w nieskończoność – nierozsądna ambicja dla każdego projektu – dostawcy płynności nieuchronnie usuną kapitał, aby wykorzystać możliwości o wyższej rentowności.

Aby bezpiecznie agregować płynność, mosty musiałyby nabyć polisy ubezpieczeniowe, aby umożliwić dostawcom płynności zabezpieczenie przed ryzykiem. To kolejny wydatek, który jeszcze bardziej utrudnia monetyzację płynności. Dlatego większość istniejących mostów nie jest opłacalna, ponieważ koszty i wypłacane nagrody za wydobycie płynności często przekraczają zysk netto protokołu.

W grę wchodzą również względy architektoniczne, biorąc pod uwagę, że transfer wartości między łańcuchami jest żądaniem, które można rozwiązać na różne sposoby. Wszystkie istniejące pomosty rozliczają te zlecenia z własnych puli płynności, w których płynność jest stale zablokowana, gdy jest potrzebna, tylko w momencie, w którym transfer wartości powinien zostać zrealizowany.

Wielkość zlecenia może się również różnić — jeśli przekroczy wielkość puli płynności pomostu, nadawca skończy z opakowanymi tokenami lub transakcją zawieszoną/utkniętą na czas nieokreślony. 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 nieskuteczne i zasadniczo błędne.

Rozwiązanie problemu bezpieczeństwa

Niezrównoważony rozwój gospodarczy nie jest jedynym głównym wyzwaniem, które jest tak ważne w tej kwestii. Nawet zakładając, że mosty wymyśliły sposób na wykorzystanie podejścia z blokadą płynności i zachowanie efektywności kapitałowej, do tej pory oczywiste jest, że zbudowanie bezpiecznego protokołu płynności jest zadaniem pochłaniającym wszystko. Rzeczywiście, świadomie lub nieświadomie stając się protokołami płynności, projekty pomostowe stawiają sobie ogromne zadanie ochrony wieloaspektowej powierzchni ataku.

Aby rozpocząć od wysokiego poziomu, jednym z oczywistych problemów związanych z pomostem w stylu zablokowanej płynności jest to, że tworzy efekt mnożnikowy ryzyka, w którym podatności jednego obsługiwanego łańcucha mogą się rozlać i zagrozić kapitałowi przechowywanemu w innych ekosystemach.

Tutaj pojawia się kwestia bezpieczeństwa przez proxy. Most może mieć zagrożoną całą bazę płynności, jeśli istnieje potencjalna luka w bazie kodu jednego obsługiwanego łańcucha bloków/L2. Dostrzegliśmy tę możliwość na początku tego roku dzięki luce odkrytej w Optymizmie, która pozwoliłaby atakującym na wybicie dowolnej 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 @optymizmPBC („rozwiązanie do skalowania warstwy 2” dla Ethereum), które umożliwiłoby atakującemu wydrukowanie dowolnej liczby tokenów, za które wygrałem nagrodę w wysokości 2,000,042 XNUMX XNUMX $. https://t.co/J6KOlU8aSW

- Jay Freeman (saurik) (@saurik) 10 lutego 2022 r.

Ponownie, wszelkie problemy z mechanizmem konsensusu jednego łańcucha mogą również prowadzić do systemowego zarażenia, narażając na ryzyko płynność zamkniętą w innych obsługiwanych łańcuchach. W tym przypadku most po prostu rozsyła exploit do innych łańcuchów. Może to obejmować 51% ataków lub inne awarie na poziomie protokołu.

Oprócz tego rodzaju odziedziczonych ryzyk, coraz częściej obserwujemy sytuacje, w których błędy samych projektów pomostowych powodują, w taki czy inny sposób, utratę zablokowanej płynności. Od nieudanych uaktualnień protokołów, słabych inteligentnych projektów kontraktów lub zhakowanej infrastruktury walidatorów, istnieje wiele scenariuszy, w których źli aktorzy mogą wykorzystać luki w samym mostku.

Wszystkie te ryzyka szybko się kumulują i – jak widzieliśmy przy wielu okazjach – w końcu rodzą się u dostawców płynności, gdy tracą możliwość wymiany swoich opakowanych aktywów. Taka możliwość powinna być nie do zaakceptowania.

Niewielu zaprzecza ogromnej obietnicy interoperacyjności międzyłańcuchowej, która pchnie adopcję Web3 na nowe wyżyny. Jednak ze względu na sam rozmiar i częstotliwość eksploatowania mostów stało się boleśnie jasne, że fundamentalny projekt technologii pomostowej musi zostać zmieniony od podstaw. Projekt protokołu „most-turned-quidity-protokół” po prostu nie działa.

Czy jest jakiś sposób, w jaki możemy opracować całkowicie nowe i unikalne podejście do projektowania mostów, które całkowicie usuwa ryzyko dla dostawców płynności, eliminuje wektory ataków, a jednocześnie zachowuje najwyższy poziom efektywności kapitałowej?

Być może w niedalekiej przyszłości nastąpi to dokładnie. W deBridge pracujemy nad nowym routingiem płynności między łańcuchami, który rozwiązuje wszystkie te problemy. Bądźcie czujni.