Вступ

Раніше випуск токена був простим: ви розгортали його на Ethereum, де всі дії були — користувачі, трейдери, капітал і ліквідність. Сьогодні ландшафт набагато складніший. Ліквідність розпорошена між Bitcoin, Ethereum, L2s, Solana та іншими ланцюгами. Отже, де слід випустити свій токен? Однозначної відповіді немає.

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

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

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

Ми розглянемо наступні фреймворки:

• Служба міжланцюгового токена Axelar (ITS)
• Перекази Нативного Токену (NTT) у Wormhole
• Omnichain Fungible Token (OFT) LayerZero
• Токен Warp Hyperlane
• xERC20 (EIP 7281: Суверенні місткі токени)

Давайте поринемо.

Як працюють фреймворки токенів

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

Палити-та-минти: для нативно багатоланцюгових токенів

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

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

• Chain A: 400 токенів
• Ланцюг B: 200 токенів
• Chain C: 200 токенів
• Chain D: 100 токенів
• Chain E: 100 токенів

Якщо користувач перекладає 50 токенів з Chain E на Chain A, ці токени знищуються на Chain E і створюються на Chain A. Оновлене розподілення буде таким:

• Ланцюг А: 450 токенів
• Ланцюг B: 200 токенів
• Ланцюг C: 200 токенів
• Chain D: 100 токенів
• Ланцюг E: 50 токенів

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

Lock-and-Mint: Для існуючих токенів

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

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

Чому важливі фреймворки токенів

Ось чому наявність токена, яким можна торгувати на єдиному ринку, що охоплює кілька ланцюгів, приносить користь командам:

• Ліквідність — Один ринок привертає більше трейдерів, що збільшує ліквідність.
• Підвищення уваги до бренду - Токени стають доступними в різних екосистемах DeFi, що збільшує попит та визнання бренду.
• Простота - керування токенами стає простішим, скорочується складність.
• Резервування — якщо один ланцюг виходить з ладу, токени все ще можуть працювати на інших, забезпечуючи мережу безпеки.
• Розширення ринку — Токен може бути швидше розгорнутий по ланцюгах, що сприяє прийняттю. Крім того, взаємопов'язані екосистеми означають більше можливостей для експериментів у сфері децентралізованих фінансів.
• Мережеві ефекти — Співпраця з іншими проектами підвищує прийняття та цінність.

ВраховуючиПротокол міжланцюжкового переказу Circle (CCTP). Запустивши CCTP, Circle дозволив USDC торгуватися безперешкодно на підтримуваних ланцюгах, вирішуючи ключові питання:

• Немає фрагментованої ліквідності — раніше у вас були різні версії USDC на кожному ланцюжку, що призводило до неефективності. Тепер USDC однаковий на всіх ланцюгах.
• Розширення ринку — Розгортання USDC на кількох ланцюгах надає їм доступ до більшої кількості користувачів та ринків.
• Ефективність капіталу - Користувачі можуть мостити великі суми USDC без необхідності пулів ліквідності або обгортання.
• Мінімальні комісії — перекази коштують мало поза платою за газ.
• Без затримки — перекази є прямими та усувають ризик затримки.

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

Порівняння фреймворків токенів

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

Безпека

Ось пояснення критичних аспектів безпеки, зазначених у таблиці:

1. Механізм перевірки

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

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

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

2. Гнучкість при верифікації

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

3.Примітні заздалегідь побудовані схеми перевірки

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

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

Наприклад, OFTs пропонують варіанти DVN, які є одиночними валідаторами поруч з більш міцними виборами, такими як CCIP або Axelar, які використовують повні набори валідаторів. Так само, Warp Token пропонує ISM, такі як Multisig ISM, в якому беруть участь валідатори, керовані спільнотою Hyperlane, і в той же час є варіанти, такі як Aggregation ISM, які дозволяють командам поєднувати безпеку з кількох ISM.

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

4. Стандартна схема верифікації

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

5. Участь у верифікації додатку

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

Наприклад, команди, такі як StarGate, Tapioca, BitGo, Cluster та Abracadabra, працюють з власними DVN на LayerZero, демонструючи, як інші команди можуть використовувати доступні налаштування.

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

6. Стійкість до цензури

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

7.Відкритий код

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

Комісії

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

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

1. Плата за протокол

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

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

Розумні контракти

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

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

1. Розгорнутий з

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

2.Перевірки

Кількість перевірок - це важливий показник безпеки. Перевірки підтверджують цілісність смарт-контрактів фреймворку, виявляють вразливості або проблеми, які можуть піддавати систему ризику.

3.Баунті

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

4. Важлива функція для дрібного контролю

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

Прийняття та розширення

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

1. Основні учасники

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

2. Прийняття

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

3. Відомі команди

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

4. Покриття VM

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

5. Ланцюги Розгорнуті На

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

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

6. Унікальні відмінності

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

Досвід розробника

Відмова від відповідальності: Цей розділ відображає статистику з @SlavaOnChain(Голова DevRel у LI.FI) і обговорення з розробниками, знайомими з різними фреймворками. Досвід розробника може варіюватися в залежності від підготовки та використання.

1.Легкість інтеграції

Стосується того, наскільки просто було розгорнути токени за допомогою рішення на основі першого досвіду без підтримки команди.

2.Документація

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

3.Інструменти розробника

Розглядає набір бібліотек, SDK та утиліт, які дозволяють легше будувати, тестувати та розгортати токени за допомогою фреймворку.

Основні висновки

A. Тенденції в міжоператорському взаємодії

1. Механізми кастомізації та верифікації — Усі фреймворки пропонують можливість налаштування механізмів верифікації, що знаменує нову тенденцію в протоколах взаємодії. Дискусія на форумі управління Lido DAO щодо wstETH стала ключовим моментом, який підкреслив попит на цю функцію.
2. Практики безпеки - функції, такі як обмеження швидкості, білий/чорний список і можливість видачі токенів взяти участь у верифікації повідомлень та налаштуванні безпеки через користувацькі політики та ролі, стали стандартними практиками у фреймворках, що свідчить про позитивний напрямок у сфері інтероперабельності.
3. Виклики відмови від типових налаштувань - Хоча індивідуальні механізми перевірки є корисними, прийняття за замовчуванням залишається низьким, що потребує кращої освіти з питань безпеки. Фокус на забезпеченні високої безпеки для типових схем перевірки є критичним, оскільки вони найбільш поширені.
4. Механізми перевірки - набір перевірювачів Axelar та мережа Guardian Wormhole широко застосовуються як механізми перевірки, що пропонуються у різних фреймворках.

B. Ведучі фреймворки токенів

1. OFT від LayerZero — лідирує у прийнятті, як для розгорнутих токенів, так і для загальної захищеної вартості. Вони були першими, хто розгорнув фреймворки токенів з OFT (V1) у 2022 році, і вони продовжують зміцнювати свої позиції, а основні активи, такі як WBTC, нещодавно прийняли структуру OFT. Вони також пропонують широку підтримку більшості мереж і вичерпні ресурси для розробників.
2. Warp Token від Hyperlane — Команда зосереджена на тому, щоб зробити фреймворк та інструменти розробника зручними для інклюзивних операцій. Про це свідчать численні реалізації віртуальних машин, створені та підтримувані зовнішніми командами, що демонструє простоту роботи з фреймворком без дозволу.
3. NTT by Wormhole — Швидко набув популярності за допомогою високоцінних токенів, розгорнутих по ланцюжках і пропонує кілька унікальних властивостей у своєму дизайні, таких як вимикач плати на рівні протоколу. Це популярний варіант для команд, які бажають розширити свої токени на Solana або токени Solana в екосистему EVM.
4. ITS by Axelar — З обсягом заблокованих активів (TVL) більше400 мільйонів доларів, Axelar посідає місце серед 25 найкращих ланцюгів PoS. Каркас ITS є ключовим фактором зростання, що сприяє як TVL, так і обсягу повідомлень, які надсилаються через мережу Axelar.
5. xERC20 Framework — єдиний повністю незалежний від мосту фреймворк, на відміну від інших, які більше схожі на продукти. Багато протоколів взаємодії, які не мають власних фреймворків, заохочують команди використовувати xERC20 для розгортання токенів, а деякі пропонують готові шаблони для інтеграції.
6. Різниця в структурі комісій - xERC20 та NTT - дві рамки, які не мають комутаційного переключателя на рівні протоколу.

Висновок

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

Насправді, фреймворки токенів можуть стати останнім дзвінком для упакованих активів. Ліквідність більше не потрібно розподіляти по різних ланцюжках. Ви можете створювати обмінні активи на будь-якому ланцюжку, і їх можна буде торгувати на різних ланцюжках лише за вартість газу. Ми вже бачимо ознаки цього зміщення. Circle запустив CCTP, щоб уникнути проблеми з упакованим токеном для USDC, і багато великих команд та активів високої вартості зараз використовують фреймворки токенів. Це свідчить про прискорення подій.

Однак, є обґрунтовані обурення стосовно ризику зараження від третіх осіб —Якщо протоколи сумісності виходять з ладу, вони можуть вплинути на всі проекти, побудовані на них. Незважаючи на ці ризики, прийняття продовжує зростати.

Інша точка зору: у майбутньому, абстрактному від ланцюга, фреймворки токенів більше не матимуть значення, тому що розв'язувачі обмінюватимуть нативні токени на користувачів за лаштунками. І хоча в цьому є частка правди — користувачам не потрібно буде думати про токени — він упускає критичний кут. А як щодо самих розв'язувачів? Для них фреймворки токенів можуть бути дуже корисними. Вони вирішують головний біль із запасами та ребалансуванням, оскільки їм не потрібна ліквідність для переміщення між ланцюгами. Ось чому вирішувачам подобається використовувати такі фреймворки, як CCTP, для переміщення USDC — це дешево, ефективно та ідеально підходить для крос-чейн ребалансування.

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

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

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