Мнение: Переосмысление межцепных мостов: давайте перестанем пытаться быть протоколами ликвидности

После ряда крупномасштабных эксплойтов мостов много внимания уделяется повествованию о том, что технология кросс-чейн по своей сути ошибочна — что кросс-чейн интероперабельность означает риск. Учитывая, что в этом году в результате 2 взломов мостов было потеряно около 13 миллиардов долларов, игнорировать этот аргумент становится все труднее.

At деБридж, мы считаем не только обязательным, но и неизбежным, чтобы все кроссчейн-мосты полностью переосмыслили свой подход к агрегированию ликвидности.

Ограничения заблокированной ликвидности

Блокируя ликвидность для обеспечения маршрутизации между цепями (как сейчас делает почти каждый мост), мосты поставили себя в конкуренцию, которую они обречены проиграть. Мы видим, как мосты сталкиваются с устоявшимися, специально разработанными протоколами ликвидности, такими как AAVE, Соединениеи Frax, проекты, которые, несомненно, будут более эффективно и безопасно монетизировать ликвидность. Примеров имеется множество мостов с TVL на сотни миллионов долларов с крайне низким уровнем использования заблокированной ликвидности.

При таком дизайне мостовые проекты вынуждены проводить неустойчивые кампании по добыче ликвидности, которые не могут предложить долгосрочные решения по эффективности капитала. Если стимулы в виде токенов не будут поддерживаться на неопределенный срок — необоснованная амбиция для любого проекта — поставщики ликвидности неизбежно удалят капитал, чтобы использовать возможности с более высокой доходностью.

Чтобы безопасно аккумулировать ликвидность, мосты должны будут приобрести страховые полисы, чтобы поставщики ликвидности могли хеджировать риски. Это еще одна статья расходов, которая еще больше усложняет монетизацию ликвидности. Вот почему большинство существующих мостов нерентабельны, поскольку затраты и выплачиваемые вознаграждения за добычу ликвидности часто превышают чистую прибыль протокола.

Здесь также учитываются архитектурные соображения, учитывая, что передача стоимости между цепочками — это запрос, который можно урегулировать по-разному. Все существующие мосты рассчитываются по этим ордерам из своих собственных пулов ликвидности, где ликвидность постоянно блокируется, когда она необходима только в тот момент, когда должна быть выполнена передача стоимости.

Размер ордера также может различаться — если он превышает размер пула ликвидности моста, отправитель получит завернутые токены или транзакцию, приостановленную/застрявшую на неопределенный срок. С другой стороны, если ордер слишком мал для размера пула ликвидности, использование ликвидности будет очень низким и неэффективным. Этот порочный круг еще раз подчеркивает, что этот подход протокола ликвидности к проектированию моста неэффективен и в корне неверен.

Решение проблемы безопасности

Как бы ни был важен этот вопрос, экономическая неустойчивость — не единственная главная проблема. Даже если предположить, что мосты нашли способ использовать подход с заблокированной ликвидностью и оставаться эффективными с точки зрения капитала, к настоящему времени очевидно, что создание безопасного протокола ликвидности — это всепоглощающая задача. Действительно, сознательно или неосознанно становясь протоколами ликвидности, мостовые проекты ставят перед собой огромную задачу по защите многогранной поверхности атаки.

Начнем с высокого уровня: одна из очевидных проблем с заблокированным мостом в стиле ликвидности заключается в том, что он создает эффект мультипликатора риска, когда уязвимости одной поддерживаемой цепочки могут распространяться на компрометацию капитала, хранящегося в других экосистемах.

Здесь есть проблема безопасности через прокси. Вся база ликвидности моста может быть скомпрометирована, если есть потенциальная уязвимость в кодовой базе одного поддерживаемого блокчейна/L2. Ранее в этом году мы увидели такую ​​возможность, когда в Optimism была обнаружена уязвимость, которая позволила бы злоумышленникам чеканить произвольное количество активов и обменять их на токены в других экосистемах.

На прошлой неделе я обнаружил (и сообщил) критическую ошибку (которая была полностью исправлена) в @optimismPBC («Решение масштабирования уровня 2» для Ethereum), которое позволило бы злоумышленнику напечатать произвольное количество токенов, за что я получил вознаграждение в размере 2,000,042 XNUMX XNUMX долларов. https://t.co/J6KOlU8aSW

- Джей Фриман (Саурик) (@saurik) 10 февраля 2022

Опять же, любые проблемы с механизмом консенсуса в одной цепочке также могут привести к системному заражению, подвергая риску любую ликвидность, заблокированную в других поддерживаемых цепочках. В этом случае мост просто транслирует эксплойт другим цепочкам. Это могут быть атаки 51% или другие сбои на уровне протокола.

Помимо этих типов унаследованных рисков, мы все чаще сталкиваемся с ситуациями, когда ошибки самих бридж-проектов так или иначе приводят к потере заблокированной ликвидности. От неудачных обновлений протокола, плохого дизайна смарт-контрактов до скомпрометированной инфраструктуры валидаторов — существует множество сценариев, в которых злоумышленники могут использовать уязвимости в самом мосте.

Все эти риски быстро усугубляются и — как мы видели слишком много раз — в конечном итоге ложатся на поставщиков ликвидности, когда они теряют возможность погашения своих обернутых активов. Такая возможность должна быть неприемлемой.

Мало кто отрицает обширные перспективы взаимодействия между сетями, которые поднимут внедрение Web3 на новый уровень. Но с огромным количеством и частотой эксплойтов мостов стало до боли ясно, что фундаментальный дизайн технологии мостов должен быть переосмыслен с первых принципов. Схема моста, превратившаяся в протокол ликвидности, просто не работает.

Можем ли мы каким-либо образом разработать принципиально новый и уникальный подход к проектированию бриджей, полностью исключающий риски для поставщиков ликвидности, устраняющий векторы атак и в то же время сохраняющий высочайший уровень эффективности использования капитала?

В ближайшее время может быть именно так. В deBridge мы работаем над новой маршрутизацией ликвидности между сетями, которая решает все эти проблемы. Следите за обновлениями.