Опубліковано: Переосмислення крос-ланцюгових мостів: Давайте припинимо намагатися бути протоколами ліквідності

Вихідний вузол: 1625255

Після низки широкомасштабних подвигів мостів, багато кисню приділяється розповіді про те, що технологія крос-ланцюгів за своєю суттю має недоліки — що сумісність крос-ланцюгів означає ризик. З огляду на те, що цього року через 2 хакерських атак на мости було втрачено приблизно 13 мільярди доларів, ігнорувати цей аргумент стає все важче.

At деБрідж, ми вважаємо, що не тільки необхідно, але й неминуче, щоб усі перехресні мости повністю переосмислили свій підхід до агрегації ліквідності.

Обмеження заблокованої ліквідності

Заблокувавши ліквідність для забезпечення міжланцюгової маршрутизації (як зараз робить майже кожен міст), мости поставили себе в конкуренцію, яку вони неодмінно програють. Ми бачимо, як мости стикаються з усталеними, спеціально розробленими протоколами ліквідності, такими як НАДАЙТЕ, З'єднання та Фракс, проекти, які, безсумнівно, ефективніше та безпечніше монетизуватимуть ліквідність. Можна навести безліч прикладів бриджів із сотнями мільйонів доларів TVL із надзвичайно низьким рівнем використання заблокованої ліквідності.

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

Щоб безпечно агрегувати ліквідність, бриджам потрібно буде придбати страхові поліси, щоб дозволити постачальникам ліквідності мати можливість хеджувати ризики. Це ще одна витрата, яка ускладнює монетизацію ліквідності. Ось чому більшість існуючих мостів нерентабельні, оскільки витрати та винагороди за майнінг ліквідності часто перевищують чистий прибуток протоколу.

Тут також беруть участь архітектурні міркування, враховуючи, що передача вартості між ланцюжками є запитом, який можна вирішити різними способами. Усі існуючі мости розраховуються за цими замовленнями з власних пулів ліквідності, де ліквідність постійно блокується, коли вона потрібна, лише в той момент, коли має бути виконано переказ вартості.

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

Вирішення проблеми безпеки

Незважаючи на те, що це питання важливе, економічна нестабільність не є єдиною головною проблемою. Навіть якщо припустити, що bridges знайшли спосіб використовувати підхід до заблокованої ліквідності та залишатися ефективними з використанням капіталу, наразі стає очевидним, що створення безпечного протоколу ліквідності є всепоглинаючим завданням. Дійсно, свідомо чи несвідомо стаючи протоколами ліквідності, мостові проекти доручають собі величезне завдання захисту багатогранної поверхні атаки.

Щоб почати з високого рівня, одна з очевидних проблем із заблокованим мостом у стилі ліквідності полягає в тому, що він створює ефект мультиплікатора ризику, коли вразливі місця одного підтримуваного ланцюжка можуть перекинутися на компрометацію капіталу, що зберігається в інших екосистемах.

Тут є питання безпеки через проксі. Уся база ліквідності моста може бути скомпрометована, якщо існує потенційна вразливість у кодовій базі одного підтримуваного блокчейну/L2. Ми бачили таку можливість на початку цього року з уразливістю, виявленою в Optimism, яка дозволяла зловмисникам карбувати довільну кількість активів і передбачувано обмінювати їх на токени в інших екосистемах.

Знову ж таки, будь-які проблеми з механізмом консенсусу одного ланцюжка також можуть призвести до системного зараження, ставлячи під загрозу будь-яку ліквідність, заблоковану в інших підтримуваних ланцюгах. У цьому випадку міст просто транслює експлойт іншим мережам. Це може включати атаки 51% або інші збої на рівні протоколу.

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

Усі ці ризики швидко наростають і — як ми бачили багато разів — зрештою виникають у постачальників ліквідності, коли вони втрачають можливість погашення своїх загорнутих активів. Така можливість має бути неприйнятною.

Мало хто заперечує величезну перспективу сумісності крос-ланцюгів, яка підштовхне впровадження Web3 до нових висот. Але з величезним розміром і частотою використання мостів стало до болі очевидним, що фундаментальна конструкція технології мостів повинна бути переосмислена з початкових принципів. Дизайн протоколу ліквідності просто не працює.

Чи можемо ми якось розробити принципово новий і унікальний підхід до проектування мостів, який повністю усуває ризики для постачальників ліквідності, усуває вектори атак і в той же час зберігає найвищий рівень ефективності капіталу?

Найближчим часом може бути саме так. У deBridge ми працюємо над новим міжланцюговим маршрутом ліквідності, який вирішує всі ці проблеми. Залишайтеся на зв'язку.

Гостьовий пост Алекса Смирнова з deBridge Finance

Алекс Смирнов — математик, дослідник, розробник і ентузіаст блокчейну. Він є генеральним директором і співзасновником deBridge, загального протоколу обміну повідомленнями та міжланцюгової сумісності, де він зосереджується на розробці протоколів, управлінні продуктами, партнерствах і операціях. Алекс став співзасновником Phenom, компанії з дослідження та розробки блокчейну, а також очолив команду, яка виграла численні хакатони та розробила різноманітні блокчейн-рішення та dApps.

→ Докладніше

Часова мітка:

Більше від CryptoSlate