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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник