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

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

by Tim

Блокируя ликвидность для обеспечения межцепочечной маршрутизации (как сейчас делает почти каждый мост), мосты втянули себя в соревнование, которое они неизбежно проиграют

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

Мы в компании deBridge считаем, что всем межсетевым мостам не только необходимо, но и неизбежно полностью пересмотреть свой подход к агрегации ликвидности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Related Posts

Leave a Comment