Вступ

Модульні макси кажуть, що майбутнє криптовалюти - це мільйон (або більше) взаємопов'язаних доменів та користувачів, які переходять між блокчейнами, як Еліс, блукаючи Вонючою країною. Чому залишатися при одному ланцюгу, якщо ви можете отримати доступ до передових технологій, новітніх застосунків, високих доходів від стейкінгу / надання ліквідності, високої продуктивності та надзвичайно низьких транзакційних комісій на інших блокчейнах?

Проте переміщення між ланцюжками набагато складніше, ніж подорож Еліс через Країну див. Це в основному пов'язано з обмеженнями, які притаманні поточним підходам до міжланцюжкової взаємодії блокчейнів (наприклад, крос-ланцюжкові мости). Зокрема, сьогодні крос-ланцюжкові мости або небезпечні (понад $2.5 млрд втрачено через взломи мостів), повільні, дорогі або обмежені в функціональності — або володіють комбінацією властивостей з цього списку.

Інші проблеми, що турбують галузь мостів, є більш витонченими, але все ще достатньо, щоб перетворити мрію про багатоланцюгову екосистему модульного максі в кошмар для користувачів та розробників. — прикладом цього є те, як фунгібельні токени (наприклад, ERC-20) стають нефунгібельними після мостінгу на різні ланцюги через різні крос-ланцюгові протоколи, тим самим ушкоджуючи їхні властивості як переказуваний актив. У цій статті ми розглянемо рішення, яке має на меті зберегти фунгібельність токенів на різних ланцюгах, незалежно від того, де знаходиться початковий контракт токена: ERC-7281: Sovereign-Bridged Tokens.

ERC-7281 розширює ERC-20 - де-факто стандарт для створення фунгібельних токенів в Ethereum - для можливості виготовлення та знищення канонічних представлень токенів ERC-20 на віддалених доменах за допомогою кількох мостів, схвалених випусковцями токенів. Це забезпечує те, що користувачі, які переносять ERC-20 токен, отримують фунгібельні версії токенів на пункті призначення (тобто два токени можуть бути обмінені 1:1), навіть коли токени відправляються через різні маршрути/мости між ланцюгами. Важливо, що протоколи, які приймають ERC-7281, зберігають контроль над мостовими токенами (на відміну від існуючого стану, коли міст контролює мостовий токен) і можуть обмежити швидкість монетарних операцій для зменшення ризику в разі відмови мосту.

Давайте використаємо USDC як приклад невзаємозамінності серед теоретично ідентичних токенів ERC-20 на різних ланцюгах.Мережі Ethereum Layer 2 (L2), такі як Arbitrum, Base, Optimism, зазвичай використовують канонічний міст, щоб перенести популярні токени ERC-20 з Ethereum L1 на ці блокчейни. Ці версії L2-токенів, які походять з L1, зазвичай називають просто «мостовими [вставте назву токена]».

У випадку USDC загальними символами є USDC.e, USDC.b і так далі. З часом Circle розширює свої розгортання USDC на інші мережі, включаючи L2, де USDC вже працює через канонічний міст. Незважаючи на те, що ці два токени карбуються однією організацією та мають однакову ціну, вони технічно різні, невзаємозамінні токени, тому не є «сумісними» — у той час як нативні USDC можуть бути перекинуті через міст CCTP Circle, мостовий USDC може бути перекинутий назад до L1 лише через канонічний міст.

ERC-7281 виправляє це, вводячи розширення ERC-20, де розробники токенів можуть призначати та параметризувати різні джерела мостів. У розглянутому вище прикладі Circle могла б розгорнути універсальний токен USDC на всіх L2, де канонічні мости (наприклад, Circle Mint, Circle CCTP та інші схвалені мости) всі призначені здатними монетизувати токени згідно їхньої логіки. Щоб зменшити ризики злому монетизаторів, розробник може обмежити кількість токенів, які кожен монетизатор може монетизувати та спалювати протягом певного періоду часу - з більш надійними мостами, такими як канонічний L2, маються більш високі обмеження, а мости з централізованою згодою - нижчі.

Хоча ERC-7281 не є першою спробою створити замінні токени міжланцюжкової, вона виправляє проблеми, пов'язані з попередніми пропозиціями - такі як в'язниця вендорів, втрата суверенітету для емітентів токенів, високі витрати на створення ліквідності для мостили токенів, інфраструктурні накладні витрати та збільшене викриття перед відмовами мостів.

Цей двочастинний звіт розгляне обґрунтування введення стандарту суверенного місткого токена та надасть всебічний огляд специфікації ERC-7281 (також відомої як xERC-20). Ми також обговоримо позитивні переваги та потенційні недоліки впровадження ERC-7281 для користувачів, розробників, постачальників інфраструктури та інших учасників екосистеми Ethereum.

Оновлення засобів мостів блокчейну

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

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

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

Крій та ковтай мости

• Користувач хоче перебудувати токен з його власного або «домашнього» ланцюга (де він спочатку був виданий) на інший ланцюг. Два блокчейни не є взаємодійними, оскільки кожен ланцюг реалізує різні архітектури та протокольні розробки, що перешкоджає користувачеві безпосередньо передавати токени з гаманця на ланцюзі A на гаманець на ланцюзі B.
• Оператор мосту забезпечує заставу токенів, які користувач депонує на вихідному ланцюжку, в розумному контракті та створює «обгорнуту» репрезентацію власного токена за допомогою контракту токена, розгорнутого на цільовому ланцюжку.
• Коли користувач бажає здійснити міст у зворотному напрямку (ланцюжок пункту призначення → початковий ланцюжок), він повертає обгорнуті токени на міст на ланцюжку пункту призначення, який перевіряє це згідно з логікою в мосту (наприклад, ZK-докази або зовнішній кворум) і вивільняє початкові токени з блокування на основному ланцюжку.

Знищувати та виготовляти мости

• Замість блокування токенів на ескроу, цей підхід випалює (знищує) токени на вихідному ланцюгу;
• Міст потім чеканить еквівалентну кількість на цільовому ланцюзі;
• Для зворотньої поїздки мостові токени спалюються на цільовому ланцюгу перед тим, як на джерелі з'являються нові токени;
• Це забезпечує збереження загального обсягу токенів, дозволяючи перекази між ланцюгами.

Атомний своп

• Цей підхід безпосередньо обмінює активи на джерелі ланцюга на активи на призначеному ланцюгу з іншою стороною.
• Атомні свопи працюють за допомогою взаємного блокування коштів з такою самою секретною вартістю для їх розблокування, що означає, що якщо на будь-якому боці секрет був розкритий, його також можна розкрити на іншому. Це надає свопам властивість атомності.
• Атомарність означає, що обмін виконується повністю (на обох сторонах) або ж взагалі не відбувається, що запобігає шахрайству чи частковим/невдалим переказам.

Перший підхід (блокування та створення) наразі є найпоширенішим. Еквівалентність вартості між внутрішнім токеном та його відповідним обгорнутим представленням, створеним мостом, дозволяє користувачам «перекладати» активи між ланцюгами та використовувати токен на окремому ланцюзі від того, де він спочатку був виданий.

Однак нові дизайни, такі як міжланцюжкове з'єднання, стали досить популярними. «Наміри» дозволяють користувачам виражати бажані результати транзакцій («обміняти 100 USDC на 100 DAI»), замість того, щоб описувати конкретні кроки для досягнення результатів. Наміри виявилися потужним інструментом для полегшення користувацького досвіду на ланцюжку, оскільки вони значно спрощують використання криптовалюти, особливо у поєднанні з рішення абстракції ланцюга.

Крос-ланцюгові наміри Дозвольте користувачам передавати токени між ланцюгами, не турбуючись про основну складність мосту. У мостах, заснованих на намірах, користувачі вносять кошти в ланцюжок джерел і вказують бажаний результат у ланцюжку призначення (свій «намір»). Спеціалізовані оператори, які називаються «наповнювачами» або «розв'язувачами», можуть виконати цей намір, заздалегідь надіславши запитувані токени користувачеві в ланцюжку призначення. Потім оператори доводять, що переказ відбувся, щоб вимагати заблоковані кошти в ланцюжку джерел як відшкодування.

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

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

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

Чому нам потрібні мости?

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

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

BobDEX - це обмінник автоматизованого маркет-мейкера (AMM), який Боб створив на Ethereum, щоб забезпечити безпеку обміну між різними активами. BobDEX має власний токен, $BOB, який виступає як токен управління та токен винагороди для LP. У останньому випадку BobDEX видаватиме токени BOB постачальникам ліквідності (LP), що надає можливість користувачам, які надають ліквідність у пулі, отримувати певний відсоток від комісії, яку сплачують користувачі DEX при обміні активами, що були внесені в пул.

Частка ринку BobDEX значно зросла, але обмеження Ethereum L1 заважають подальшому зростанню. Наприклад, деякі користувачі не хочуть використовувати BobDEX на Ethereum через високі комісії за газ та затримки у транзакціях; подібно, інші користувачі бажають отримати експозицію до ціни токенів $BOB, не маючи при цьому утримувати на Ethereum власні токени $BOB.

Щоб вирішити проблему, Боб розгортає версію BobDEX на Arbitrum (L2-ролап з низькими комісіями та високою пропускною здатністю) та розгортає обгорнену версію токена BOB (wBOB) на L2 через міст Арбітрум-Ефіреум. BobDEX на Arbitrum ідентичний BobDEX на Ефіреумі, окрім того, що він використовує wBOB—а не нативні токени BOB—для винагород за LP та управління.

Різниця у токенах застосування (упакований BOB проти власного BOB) не має значення з точки зору користувачів (наприклад, постачальників ліквідності), які взаємодіють з BobDEX на Arbitrum. Оскільки токени wBOB підтримуються фактичними токенами BOB, які утримуються в мосту Arbitrum-Ethereum, власники токенів wBOB можуть легко обміняти їх на власні токени BOB ERC-20 на Ethereum, взаємодіючи з контрактом мосту.

Ситуація є вигідною як для Боба, так і для користувачів:

1. Боб може залучити більше користувачів, особливо тих, хто бажає низьких комісій за газ та швидкого підтвердження транзакцій при торгівлі на BobDEX
2. LPs можуть отримувати винагороду за постачання ліквідності на BobDEX, не стикаючись з високими витратами на газ та довгими часами підтвердження на Ethereum
3. Hodlers можуть купувати токени wBOB на ринку, щоб заробити на змінах ціни токенів BOB без взаємодії з контрактом BOB ERC-20 на Ethereum

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

Кредитори, які надають ліквідність AliceLend, мають впевненість у отриманні депозитів: якщо користувач не виконує зобов'язання з позики, AliceLend автоматично проводить аукціон з депонованими токенами wBOB як заставою, щоб відшкодувати кредиторів. У цьому випадку покупці ліквідованої застави wBOB приймають на себе роль LP на BobDEX і мають ту ж гарантію, що токени wBOB можна обміняти на початкові токени BOB в співвідношенні 1:1.

Кросчейн-мости в його нинішній формі забезпечили дієве рішення для забезпечення взаємодія між (раніше ізольованими) Ethereum L2та сприяє новаторським застосуванням (наприклад, крос-ланцюжкові позики та крос-ланцюжкові DEXes). Однак екосистема мостів наразі має справу з обмеженнями, які стримують подальший розвиток, такими як незамінність крос-ланцюжкових токенів — ми розглянемо цю проблему докладніше нижче.

Чому мостові токени стають незамінними?

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

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

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

• Аліса містить USDC з Ethereum на Arbitrum за допомогою канонічного моста Arbitrum і отримує 200 USDC.e на Arbitrum, тоді як Боб мостить USDC на Arbitrum через Axelar і отримує 200 axlUSDC на Arbitrum. Аліса і Боб укладають угоду про те, що Аліса надішле 200 USDC Бобу (в обмін на 200 USDT), щоб Боб міг зняти 400 USDC на Ethereum.
• Боб намагається вивести 400 USDC через axlUSDC і отримує лише 200 USDC, разом з повідомленням, що містить пояснення, що місто містить тільки 200 USDC, які воно може передати Бобу. Боб збентежений, оскільки замотані ERC-20-токени повинні бути «фунгібельними» і не повинні проявляти розбіжності, які перешкоджають комусь обмінювати ERC-20-токени 1:1 на будь-якому застосунку.
• Боб вивчає важке урок про перехід між ланцюгами: «функціональний токен ERC-20» не завжди означає «ви можете обміняти цей токен 1:1 на інші токени ERC-20 у різних додатках». Спроба Боба здійснити ризиковану угоду з Алісою - ризикованою, оскільки Аліса може не повернути токени - завершується катастрофічно невдачею.

Боб після того, як його обдурили на свопі

Чому Боб не може зняти 400 USDC, якщо він і Еліс отримали обгорнуті версії одного і того ж базового активу на цільовому ланцюгу? Ви пам'ятаєте, ми згадували, що токени, що випускаються на різних ланцюгах, несумісні, тому представлення звичайного токена, що випущений на зовнішньому ланцюгу, є зобов'язанням від мосту виплатити певну кількість звичайних токенів (залежно від залишків), коли користувач бажає повернутися на звичайний ланцюг токена.

Тому значення кожного мостуваного токена пов'язане з постачальником мосту, який відповідає за зберігання депозитів на домашньому ланцюгу та виготовлення представлень на цільовому ланцюзі; постачальник мосту Боба може заплатити Бобу лише 200 USDC, оскільки це єдине, що він може покрити з депозиту; 200 USDC Аліси не можуть бути виведені через постачальника мосту Боба, оскільки він ніколи не отримав депозиту або не видав IOU Алісі. Алісі потрібно вивести її заблокований USDC з Arbitrum на Ethereum і мостувати через постачальника мосту Боба, перш ніж Боб зможе отримати решту токенів.

Дилема Боба і Еліс вказує на проблему з мостом між доменами, де кілька незамінних представлень базового активу видаються конкуруючими постачальниками мостів. Ще одна проблема з різними представленнями ERC-20 одного й того ж активу полягає в тому, що їх не можна торгувати в одному ліквідному пулі.

Використовуючи попередній приклад, якщо у нас є axlUSDC та USDC.e на ланцюжку і ми хочемо їх обміняти на ETH та навпаки, нам потрібно розгорнути два пули ліквідності - ETH/axlUSDC та ETH/USDC.e. Це призводить до так званої "фрагментації ліквідності" - ситуації, коли торгові пули мають меншу ліквідність, ніж вони могли б мати, оскільки є кілька пулів, які відповідають в основному тій самій торговій парі.

Рішенням є мати єдину «канонічну» версію токена, яка циркулює на цільовому ланцюгу, щоб Боб та Еліс можуть обмінюватися токенами, не знімаючи їх з моста на джерелі ланцюга. Наявність канонічного токена для кожного ланцюгу також корисна для розробників, оскільки користувачі можуть швидко переміщатися між екосистемами, не маючи справу з питаннями щодо ліквідності токенів.

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

Впровадження канонічних токенів на різних ланцюгах

Створення канонічного токена на кожному ланцюжку не є простим завданням, і існує кілька варіантів з різними компромісами та перевагами. Коли ми створюємо канонічний токен на кожному ланцюжку, ми зазвичай повинні подумати, кому довіряти щодо існування IOUs, що підтримують вартість певного токена. Припустимо, ви є творцем токена і хочете, щоб його можна було використовувати та передавати на різних ланцюжках без проблем з обмінністю; у вас є чотири варіанти:

1. Створюйте канонічні токени через канонічні rollup/sidechain мости
2. Виготовляйте канонічні токени за допомогою постачальника моста третьої сторони
3. Створіть канонічні токени за допомогою міста-емітента токенів
4. Пряме багатоланцюгове випуск з атомними свопами

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

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

1. Створюйте канонічні токени через містки канонічних ролапів/бічних ланцюгів

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

Хоча канонічний міст все ж таки створює канонічне представлення токена, інші представлення все ще існують. Це відбувається просто тому, що канонічні мости часто мають обмеження, які заважають надати користувачам найкращий досвід. Наприклад, міст з Arbitrum/Optimism на Ethereum через канонічний міст має затримку у семь днів, оскільки транзакції повинні бути перевірені верифікаторами і, можливо, спростовані...доказ шахрайства, якщо недійсний—перед розрахунковим шаром роллапу (Ethereum—проводить розрахунок пакета транзакцій.

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

Сайдчейни з незалежними наборами валідаторів мають меншу затримку, оскільки зняття коштів виконується після того, як протокол консенсусу сайдчейна підтверджує блок, що містить транзакцію зняття. Міст Polygon PoS є прикладом канонічного мосту, що з'єднує сайдчейн з різними доменами (включаючи зведення Ethereum і основну мережу Ethereum).

Примітка: Ми посилаємося на оригінальний ланцюг Polygon PoS, а не напланований ланцюг валідіумякий буде використовувати Ethereum для розрахунків. Polygon стане L2 після переходу від бічного ланцюга, що забезпечувався зовнішніми валідаторами до валідуму, що забезпечується консенсусом Ethereum.

Однак, мосты між підланками також мають слабкість, спільну з канонічними мостами rollup: користувачі можуть мостити лише між парою з'єднаних ланцюгів. Вони не можуть мостити до інших блокчейнів, використовуючи канонічний міст. Наприклад, ви не можете мостити з Arbitrum до Optimism сьогодні, використовуючи міст Arbitrum, або мостити з Polygon до Avalanche через міст PoS Polygon.

1.1. Виготовляйте канонічні токени за допомогою місткості місткості

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

Згідно з цією угодою, затверджені мости ліквідності (a) створюють упаковані представлення токенів протоколу на джереловому ланцюгу (b) обмінюють упаковані токени на канонічне представлення на пункті призначення через пул ліквідності, що належить протоколу.

Канонічне представлення токена на цільовому ланцюжку зазвичай є версія, створена канонічним міжланцюжковим/ролап-мостом, хоча існують винятки (про які ми побачимо пізніше). Наприклад, канонічна версія USDT на Optimism - це opUSDT, створена Optimism Bridge.

Кожний міст ліквідності працює як DEX з автоматичним маркет мейкером (AMM) для виконання обмінів між парами активів, які зберігаються в різних пулах ліквідності. Для стимулювання надання ліквідності пули AMM діляться часткою комісій за обмін між власниками, які блокують канонічні токени у контрактах пулів.

Це схоже на модель Uniswap; єдине помітне відмінність полягає в тому, що пари активів зазвичай є представленням моста ліквідності токену проти канонічного представлення. Наприклад, користувач, який переходить від USDT до Optimism через Hop, повинен буде обміняти hUSDT на Optimism через пул huSDT:opUSDT.

Робочий процес для зв'язування через містковий міст буде виглядати так:

• Заблокуйте власні токени на початковому ланцюгу
• Представлення мосту монети національного токена на цільовому ланцюгу
• Переміщення мостового представлення на цільовому ланцюгу за допомогою пула AMM
• Надіслати канонічні токени користувачеві

Цей процес схожий для всіх місткісних мостів (Across, Celer, Hop, Stargate, і т.д.). Однак, він зазвичай абстрагується від кінцевого користувача - особливо з боку розв'язувачів/заповнювачів - і буде відчуватися як одна транзакція, незважаючи на багато рухомих деталей.

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

Мости ліквідності чудові, головним чином тому, що вони усувають проблему затримки при зведенні мостів; наприклад, Hop дозволяє спеціалізованим сторонам, відомим як «Bonders», підтверджувати дійсність транзакції виведення коштів користувачем на L2 і покривати витрати на зняття коштів з мосту L1 rollup. Кожен бондер запускає повний вузол для ланцюжка L2 і може визначити, чи буде транзакція виходу користувача в кінцевому підсумку підтверджена на L1, зменшуючи ризик того, що користувач ініціює шахрайське зняття коштів і завдасть збитків Бондеру.

Мости для ліквідності також дозволяють користувачам переміщатися між більшою кількістю ланцюгів, на відміну від канонічних мостів; наприклад, Hop дозволяє користувачам створювати містки між Arbitrum та Optimism без необхідності зняття грошей спершу на Ethereum. Так само, як швидке мостінг L2→L1, швидке мостінг L2→L2 вимагає, щоб Bonder запускав повний вузол для вихідного ланцюга L2, щоб підтверджувати зняття перед витратою коштів на виготовлення токенів для користувача на призначеному ланцюзі L2. Це дозволяє більше композиції між rollups та драматично покращує користувацький досвід, оскільки користувачі можуть переміщувати токени між rollups без проблем.

Але також є й недоліки ліквідності, які впливають на корисність використання моста забезпечення ліквідності ланцюга для виготовлення канонічного представлення токена на ланцюзі L2/L1.

Недоліки міжланцюжкової ліквідності

1. Слипаж

Slippage - це різниця між очікуваною та отриманою кількістю токенів при взаємодії з AMM. Сліпедж виникає через те, що AMM ціноутворює свопи залежно від поточної ліквідності в пулі - ціноутворення таке, що забезпечує рівновагу між балансом кожного активу у парі в пулі після завершення свопу, що може змінитися між моментом, коли користувач ініціює торгівлю, та виконанням обміну.

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

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

Додатки, такі як агрегатори мостів (які не можуть знати, чи буде достатньо ліквідності на містку для покриття свопа на призначенні без зносу), працюють над проблемою, вказуючи максимальну межу зносу та використовуючи її для надання котирувань користувачам. Це, хоч і запобігає поверненню транзакції, проте користувачі завжди втрачають певний відсоток змостуваного токену - незалежно від ліквідності в AMM-пулах мосту.

2. Обмеження ліквідності

Фундаментальним викликом для місткості місткості є абсолютна необхідність у достатній місткості на цільовому ланцюгу. У відміну від традиційних мостів блокування та видобування, де монетизація токенів забезпечується безпосередньо заблокованими активами, місткості мостів залежать від наявних токенів у басейнах AMM для здійснення міжланцюжкових переказів. Коли ліквідність падає нижче критичних порогів, весь механізм мостування може фактично припинити свою роботу.

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

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

3. Невирівняні стимули

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

Хоча це забезпечує користувачам, які мігрують токени проєкту або використовують агрегатор мостів для надсилання токенів через ланцюжки, кращий UX, вибір мостів на основі ліквідності ставить мости, які не можуть витрачати на стимули для постачальників ліквідності (LP), в невигідне становище. Крім того, вибір мостів на основі чистих транзакційних комісій спотворює конкуренцію на користь мостів, які приймають централізований підхід для зменшення операційних витрат і можуть стягувати менші комісії за мостові транзакції. У обох випадках мости не конкурують на, мабуть, найважливішому показнику: безпека.

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

4. Погана UX переходу між ланцюгами

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

Користувачі мають два варіанти в цій ситуації (обидва неоптимальні):

• Зачекайте, поки міст має достатню ліквідність для завершення обміну та виведення канонічних токенів. Це підоптимально через затримку, що зазнається в мостових транзакціях, та тому, що користувач не може знати, чи отримає він ту саму кількість токенів, зазначених на початку, оскільки ліквідність пулу може змінюватися довільно в дуже короткі періоди.
• Отримайте власний токен-представлення моста (наприклад, hUSDT для Hop Bridge). Це не є оптимальним, оскільки більшість додатків віддають перевагу інтеграції з канонічним представленням власного токена (наприклад, opUSDT, випущений мостом Optimism), і можуть не приймати упакований актив користувача.

2. Карбуйте канонічні токени за допомогою канонічного стороннього мосту

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

Використання одного постачальника мостів надає більше гнучкості командам проекту, особливо оскільки сторонні мости мають стимули для підтримки мостіння між більш широким спектром екосистем порівняно з канонічними мостами, які з'єднуються максимум з одним ланцюгом. Якщо міст існує на всіх ланцюгах, де застосовується додаток, користувачі можуть швидко переміщатися через ланцюги без потреби у виведенні назад на домашній ланцюг; постачальник мостів повинен лише забезпечити, що токени, які випущені на призначеному ланцюзі А, знищуються, перш ніж користувач випустить токени на призначеному ланцюзі Б, і канонічні токени на ланцюзі Б (пере)відображаються на токен на домашньому ланцюзі.

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

• Користувачі не страждають від зміни курсу при місткових транзакціях, оскільки постачальник моста не повинен конвертувати свою представленість відносно канонічного представлення через AMM - токен постачальника моста є канонічним представленням мостового токена на кожному домені. Значення цих представлення пов'язане зі значенням токенів, заблокованих постачальником моста на власному ланцюжку токенів.
• Користувачі майже не зазнають затримок при мостінгу, оскільки постачальник моста може мити упаковані представлення на цільовому ланцюжку негайно після отримання повідомлення mint() на цільовому ланцюжку.
• Розробники можуть замовити у операторів мостів управління розгортанням багатьох ланцюгів токенів без хвилювання про створення ліквідності AMM або програми стимулювання надання ліквідності.

Деякі приклади токенів одиночного моста в дикій природі включають Омніланцюговий функціональний токен (OFT) LayerZero, Службу міжланцюжкових токенів Axelar (ITS), xAsset від Celer та anyAsset від Multichain. Усі приклади фактично є пропрієтарними токенами і несумісні з представленнями того ж токена, відправленого через іншого постачальника моста. Ця невелика деталь підкреслює деякі проблеми з таким підходом до обробки токенів моста. А саме наступне:

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

Недоліки використання канонічних бріджів сторонніх учасників

1. Захоплення виробником

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

Можливо перемикнутися на постачальників мостів, але витрати на перемикання настільки високі, що вони зневажають більшість проектів від підходу до цього. Щоб дати орієнтовне уявлення, припустимо, що розробник (якого ми назвемо Боб) випустив токен (BobToken) на Ethereum і вибрав LayerZero OFT для надання канонічних версій BobToken на Optimism, Arbitrum і Base. BobToken має фіксовану кількість 1 000 000 токенів, і мостики, випущені через LayerZero, становлять 50% загальної кількості BobToken, що перебувають в обігу.

Діловий договір успішно продовжується, поки Боб не вирішує, що користувачі краще моститимуть BobTokens через конкуруючий сервіс моста (наприклад, Axelar). Однак Боб не може просто так сказати: «Я перехожу на Axelar ITS, щоб відтворювати канонічні представлення BobToken на Optimism, Base та Arbitrum», оскільки токени OFT та ITS несумісні, Боб ризикує створити головні болі для як старих, так і нових користувачів, оскільки два BobTokens потенційно не є замінними (повторне надання проблеми, яку ми описали раніше). Крім того, програми, інтегровані з версією BobToken LayerZero, не можуть приймати версію BobToken від Axelar як заміну, що розшаровує ліквідність для BobToken на різних ланцюгах, де співіснують конкуруючі представлення BobToken.

Для здійснення переходу Бобу потрібно переконати користувачів розкрити обгортки BobToken, випущені через LayerZero, надіславши транзакцію, яка спалює перекинуті токени OFT та розблоковує BobToken на Ethereum. Тепер користувачі можуть перейти до нового канонічного представлення BobToken, заблокувавши токени з Axelar на Ethereum та отримавши канонічні BobToken (прив'язані до поставки контракту токенів на Ethereum) на цільовому ланцюжку. Це вимагає значних витрат і призводить до великої координації та надмірних операційних витрат для команд управління проектами DAO, тому зазвичай краще залишатися при обраному постачальнику.

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

2. Втрата суверенітету для протоколів

Заключна частина попереднього розділу про в'язкість постачальника підкреслює інше питання, пов'язане з використанням канонічного стороннього моста: випускачі токенів обмінюють контроль над канонічними мостовими токенами на більш зручність та поліпшення користувацького досвіду. Для використання попереднього прикладу: BobToken на Ethereum повністю знаходиться під контролем Боба, оскільки він контролює базовий ERC-20 контракт токена, але BobToken на Optimism, Arbitrum та Base контролює LayerZero, яка володіє контрактом OFT, що випускає канонічні представлення BobToken на цих блокчейнах.

Хоча Боб може очікувати, що LayerZero вирівняє канонічні представлення з оригінальним дизайном власного токену, це не завжди може бути правдою. У найгірших сценаріях поведінка токену BobToken на Ethereum може значно відрізнятися від поведінки токену BobToken на Optimism, оскільки постачальник моста реалізує радикально відмінну версію контракту токену, що створює проблеми для користувачів протоколу. Цю проблему також може загострити динаміка принципал-агент, де цілі та інтереси протоколу та постачальника моста розходяться.

3. Висока вразливість до вибоїв мостів

У першому підході, де токени з'єднані міжланцюжково через канонічний міст кожного ланцюжка, ризик для емітента токена від атаки, що впливає на один міст, обмежений самим цим мостом. Наприклад, припустимо, що хакеру вдалося компрометувати один ліквідності міст і витворити нескінченні кількості обгорнутого токена без забезпечення депозиту. У цьому випадку він може вивести тільки максимальну наявну ліквідність для обгорнутого активу в ліквіднісних пулах (наприклад, виготовлення cUSDT на Optimism → обмін cUSDT на канонічний opUSDT → виведення opUSDT на Ethereum через швидкий міст → обмін на основний USDT на Ethereum).

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

Припустимо, що зловмисник скомпрометував міст сторонньої ланцюга на ланцюзі B та вибив 1000 токенів (де токен спочатку випускається на ланцюгу A) без застави. Токени зловмисника на ланцюзі B не відображені на домашньому контракті ланцюгу, тому він не може вивести їх з ланцюгу A. Однак він може перейти на ланцюг C та обміняти 1000 токенів ланцюгу B на 1000 токенів ланцюгу C - пам'ятайте, кожен крос-ланцюжок токен сумісний і замінний, оскільки вони походять з одного й того ж міста сервісу. Токени ланцюгу C відображені на домашньому контракті ланцюгу, оскільки вони були законно вибиті користувачами, які заблокували токени на ланцюзі A (домашній ланцюг токена), що дозволяє зловмисникові знищити токени на ланцюзі C та вивести місцеві токени на ланцюзі A та, можливо, завершити маршрут, обмінюючи токени через CEX або фіатний вихід.

(Джерело)

Втрата функцій настроювання митниці

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

Загальні функції токенів, такі як делегування голосів (ZK), механізми ребейсінгу (stETH, USDM), можливості комісії при передачі (мем-монети), функції чорного та білого списку (USDT, USDC), призупинення передач та особливі правила або дозволи на створення, часто відсутні під час мостінгу токенів через постачальника сторонніх послуг, оскільки мостінгова версія, як правило, використовує базову реалізацію ERC-20. Ця втрата функціональності створює непослідовності в роботі токена на різних ланцюгах і може потенційно порушити інтеграції, які залежать від цих користувацьких функцій.

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

Обмежена підтримка ланцюгів

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

• Зачекайте, поки постачальник моста додасть підтримку бажаного ланцюга, що може зайняти багато часу або ніколи не відбутись через високі витрати на інтеграцію (наприклад, нерівність ЕВМ ZKsync Era, яка змусила багато додатків ніколи не розгортатися на ньому)
• Використовуйте іншого постачальника мосту для цього конкретного ланцюга, що знову вводить проблему нефункціональних токенів та фрагментації ліквідності

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

Неспівпадаючі адреси токенів для крос-ланцюгових токенів

Постачальники сторонніх містків можуть розгортати місткові токени з різними адресами на кожному ланцюзі через особливості їх технічного стеку, наприклад, відсутність підтримки для CREATE2Відсутність послідовності адрес спричиняє багато проблем UX:

• Ризики безпеки: Користувачі повинні перевіряти різні адреси токенів на кожному ланцюжку, що збільшує ризик взаємодії з шахрайськими токенами;
• Складність інтеграції: Розробники повинні підтримувати списки дійсних адрес токенів для кожної мережі;
• Збільшений ризик фішингу: шахраї легше можуть обдурити користувачів фальшивими токенами, оскільки немає постійної адреси для перевірки.

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

3. Створити канонічні токени за допомогою мосту токен-випуску

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

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

Відомі приклади канонічних представлень токена, виданого його творцем, єТелепорт MakerDAOта Circle'sПротокол міжланцюжкового переказу (CCTP). Teleport дозволяє користувачам переміщувати канонічний DAI між Ethereum та різними ефір-ролапіви через операції швидкого шляху та повільного шляху. DAI спалюється на одному ланцюжку та видобувається на цільовому ланцюжку. CCTP працює аналогічно і дозволяє переказувати міжланцюжково природні USDC (видані Circle) за допомогою механізму спалювання та видобування. В обох випадках випускач токена контролює видобуток та спалювання канонічних представлень токена.

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

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

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

Ця взаємодія (між мостики версій токенів протоколу та безпекою протоколу) є доброзичливою, оскільки безпека власних токенів, які підтримують канонічні представлення, вже залежить від безпеки протоколу, тому користувачі та зовнішні розробники не приймають на себе нових довірчих припущень. Це особливо справджується для.стабільні місткипрацює на основі емітентів, таких як Circle та Maker (тепер Sky) - користувачі вже довіряють емітентам стейблкоїнів, що вони мають достатньо активів для покриття викупу стейблкоїнів за фіатні валюти, тому довіряти безпеці мосту стейблкоїнів нескладно.

Але вона також представляє собою центральний пункт непрацездатності, якщо інфраструктура мосту емітента токенів піддається атакам, то вартість всіх канонічних представлень, що циркулюють у багатоланцюжковій екосистемі, перебуває під загрозою. Це також означає, що цей модель емісії канонічних міжланцюжкових токенів можуть реалізувати лише централізовані кастодії (наприклад, Circle у випадку USDC).

Заключні думки

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

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

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

ERC-7281 - новий підхід до функціональності крос-ланцюгового активу, який зменшує компроміси, пов'язані з існуючими підходами. Також відомий як xERC-20, ERC-7281 дозволяє протоколам ефективно розгортати канонічні токени на кількох ланцюгах без втрати безпеки, суверенітету чи користувацького досвіду.

Унікальний дизайн ERC-7281 дозволяє декільком мостам (з білого списку) карбувати канонічні версії токенів протоколу в кожному підтримуваному ланцюжку, дозволяючи розробникам протоколів динамічно регулювати ліміти карбування для кожного мосту. Ця функція вирішує багато проблем, пов'язаних з історичними пропозиціями щодо багатоланцюгових канонічних токенів, включаючи фрагментацію ліквідності, вирівнювання стимулів, проблеми UX, ризики безпеки мостів, можливість налаштування (крос-чейн токенів) тощо.

Наступна — і остання — частина нашої двочастинної звітності про функціональність активів на перетині ланцюгів буде детально розглядати ERC-7281 та досліджувати, як стандарт токенів xERC-20 може бути корисним для розробників та користувачів. Ми порівняємо ERC-7281 з іншими конструкціями для канонічних токенів багатоланцюжкового типу, дослідимо підхід xERC-20 до канонічних токенів багатоланцюжкового типу та виділимо аспекти, які слід враховувати протоколам та розробникам, які планують побудувати на цьому стандарті.

Залишайтесь на зв'язку!

Відмова від відповідальності:

1. Ця стаття розміщена з ...[2077 дослідження]. Усі права на авторські права належать оригінальному автору [Алекс ХукіЕммануель Авосіка]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно вирішать це.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови здійснюються командою Gate Learn. Якщо не зазначено інше, заборонено копіювання, поширення або плагіат перекладених статей.