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

Потреба в кращому підході

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

• Cтворювати канонічні представлення токенів на віддалених ланцюгах через мости канонічного rollup/sidechain
• Створюйте канонічні представлення токенів на віддалених ланцюгах через сервіс моста сторонньої компанії
• Створюйте канонічні представлення токенів на віддалених ланцюгах через канонічну місткову службу, яку обслуговує емітент токенів

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

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

• Функціональність для виготовлення та знищення канонічних токенів ERC-20;
• Здатність власника токена

1) призначати операторів мосту для карбування та спалювання токенів під час мосту між ланцюгами;

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

З огляду на незначну різницю між токенами ERC-7281 та ERC-20 автори EIP описали перше як "xERC-20". Для читачів, які потребують огляду токенів ERC-20, OpenZeppelin має великупосібник з теми.

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

Додатковою функцією, яку ERC-7281 додає до специфікації ERC-20, є опціональний Lockbox, який функціонує як контракт-обгортка (аналогічно контракту WETH (Wrapped Ether)). Контракт Lockbox обгортає токени ERC-20 у токени xERC-20 за допомогою знайомих механізмів карбування та спалювання та робить ERC-7281 сумісним з існуючими контрактами токенів ERC-20, які не мають інтерфейсу спалювання/карбування та не підлягають оновленню.

Використовуючи рамки, введені в попередній статті, ми можемо класифікувати ERC-7281 як підхід "довіряйте емітенту токенів + довіряйте постачальнику (схваленому) мосту" для миття багатоланцюжкових токенів. Токен ERC-7281, розгорнутий на кількох ланцюгах, контролюється його емітентом (на відміну від альтернативних дизайнів крос-ланцюжкових токенів, які зазвичай вимагають відмови від суверенітету). Хоча емітент все ще піддається ризику того, що схвалений міст може стати жертвою інциденту забезпечення безпеки, емітент керує цим ризиком, вибираючи вручну та обмежуючи швидкість авторизованих постачальників мостів.

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

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

Огляд ERC-7281: Суверенні місткові токени

Випалювання та виготовлення токенів для користувачів

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

Для вже існуючих токенів ERC-20 застосовується логіка "lockbox": постачальник моста обгортає токени ERC-20, які були внесені користувачами, у токени xERC-20, перекладаючи їх у контракт Lockbox. Lockbox потім затверджує місту монетизацію еквівалентної кількості токенів xERC-20.

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

Щоб перевести токени назад у домашній ланцюг, оператор мосту спалює токени xERC-20 у віддаленому ланцюжку, надаючи адресу користувача та суму токена. Чек про спалювання передається на домашній ланцюг транспортним шаром. Якщо повідомлення про спалювання підтверджено, оператор мосту карбує та спалює нові токени xERC-20 у домашньому ланцюгу для користувача. Після підтвердження квитанції про спалювання контрактом токена, оператор мосту передає користувачеві депоновані токени ERC-20. Спалювання токенів xERC-20 у домашньому ланцюгу зменшує загальну пропозицію токена та ліміт спалювання мосту.

Важливий момент: контракт xERC-20 технічно може карбувати токени без доказів, що перевіряють міст. Ми описали стандартний (читай: очікуваний) підхід, але мости, які не реалізують жодного типу перевірки повідомлень — або не впроваджують нові механізми перевірки кросчейн-повідомлень — можуть бути внесені до білого списку для карбування та спалювання токенів xERC-20. Все залежить від того, що може прийняти емітент токена.

Обмеження швидкості для токенів на монетарній та знищення

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

Специфікація xERC-20 також включає функції для перевірки обмежень на зжигання та карбування для містів, схвалених для обробки токенів. «mintingMaxLimitOf» повертає максимальну кількість токенів, яку міст може відштучно виготовити, а відповідно, «burningMaxLimit» повертає максимальну кількість токенів, яку міст може зжигати протягом визначеного періоду. Крім того, ці функції показують залишкові токени, які міст може зжигати та карбувати до досягнення заданих лімітів.

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

Параметри обмеження швидкості

Специфікація інтерфейсу токена xERC-20 включає структуру "Міст", яка містить "burningParams" та "mintingParams" (параметри функції обмеження швидкості токена xERC-20 контролюють, скільки токенів міст може зжигати та мінтувати протягом попереднього періоду). "maxLimit" визначає максимальний ліміт на мінтинг і зжигання токенів та збільшується кожну секунду за попередньою ставкою ("ratePerSecond").

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

Параметри спалювання та карбування в основному актуальні для власників токенів (і операторів мостів меншою мірою). Однак максимальні та поточні граничні параметри є важливими факторами для користувачів та операторів мостів. Наприклад, поточний ліміт може вплинути на те, скільки користувач може впевнено подолати за допомогою крос-чейн протоколу, не зіткнувшись із затримками при отриманні токенів xERC-20 у пункті призначення.

xERC-20 Lockbox

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

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

Контракт Lockbox значною мірою запозичений з дизайну контракту-обгортки WETH. У ньому реалізована функція deposit() для депонування відповідного токена ERC-20 у Lockbox та функція withdraw() для операторів мосту для розблокування токенів ERC-20 після спалювання обгорнутих токенів на віддаленому домені.

Перші два типи помилок, виділені в специфікації («IXERC-20Lockbox_NotNative» і «IXERC-20Lockbox_Native»), виникають, коли користувач намагається внести токени в неправильний контракт Lockbox. Lockbox може бути рідним або нерідним, залежно від того, які типи токенів він підтримує.

Іноземні сховища носіють місцеві токени — тобто токени, які використовуються для оплати газових винагород узгоджувачів. Прикладом токену, який мав би місцеве сховище для обгортання його в токен xERC-20, є ETH: обгортання ETH в токен xERC-20 потребувало б виклику функції depositNative() сховища та внесення ETH для отримання сумісного представлення ETH за стандартом ERC7281.

Звичайні (не корінні) каси ERC-20 володіють токенами, такими як USDC, DAI, WETH, USDT та інші. Щоб викувати USDC як токен xERC-20, наприклад, користувач викликав би deposit() на контракт Lockbox після блокування USDC.

Виклик deposit() з ETH призведе до того, що ці кошти будуть заблоковані назавжди, оскільки звичайний контракт Lockbox може лише обгорнути та розгорнути токени ERC-20. Виклик depositNative() з токеном ERC-20 приведе до схожих результатів, оскільки власне контракти Lockbox призначені для роботи з власними токенами, а не ERC-20 токенами.

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

Контракти адаптера

У випадках, коли мостові протоколи не призначені для розпізнавання операцій, властивих токенам xERC-20 (карбування/спалювання, відповідне логування тощо), застосунки можуть створювати контракти на адаптери. Ці контракти функціонують як автоматизовані обгортки та розгортки, ефективно переводячи стандартну поведінку ERC-20 appprove + call у більш тонку схему mint/burn, яка вимагається xERC-20.

Це необхідно, тому що багато мостових протоколів (наприклад, CCIP від Chainlink) залишаються оптимізованими для звичайної поведінки ERC-20. Контракт адаптера може подолати (ba-dum-tss) цю прогалину в сумісності, закріпивши таку логіку: він вносить токени в Lockbox для генерації представлення xERC-20 у вихідному ланцюжку, а пізніше, після отримання повідомлення в ланцюжку призначення, запускає механізм виведення коштів, щоб повернутися до канонічного активу.

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

Чому ERC-7281? Аргумент за стандарт суверенного мостового токена

На високому рівні ERC-7281 переслідує чотири загальні цілі:

1. Фунгібельність: Користувачі, які переносять токени з відповідного ланцюжка токенів на інший (L1/L2) ланцюжок, завжди повинні отримувати канонічні представлення перенесеного токена в пункт призначення. Нескінченно нефунгібельні версії одного токена, що циркулюють на неоригінальному ланцюжку, проблематичні з тих причин, які було пояснено раніше (наприклад, фрагментація ліквідності та погана компоновка токенів).

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

1. Безпека: Щоб зменшити ризик контрагента, емітенти токенів повинні мати можливість вибирати з конкуруючих постачальників мостів відповідно до оцінки інфраструктури безпеки. Крім того, емітенти токенів повинні мати надійний захист від наслідків інцидентів безпеки, що впливають на партнерських постачальників мостів — ізольовані атаки на одну або дві служби мосту не повинні знищувати цілі TVL.

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

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

Ми можемо подальше розширити ці цілі, щоб побачити, які користі ERC-7281 надає протоколам та спільнотам.

Аналіз переваг ERC-7281

Покращення UX та усунення фрагментації ліквідності

ERC-7281 вирішує різні версії проблеми залежності від шляху, описаної в уводі.

Залежність від шляху може бути специфічною для ланцюга (наприклад, ETH, з'єднаний з Ethereum → Arbitrum → Optimism, відрізняється від ETH, з'єднаного з Ethereum → Optimism → Arbitrum) або специфічною для моста (наприклад, ETH, з'єднаний з Ethereum до Optimism через Celer, відрізняється від ETH, з'єднаного з Ethereum до Optimism через Connext).

Залежність від шляху - це цінна функція безпеки, але вона також може завдати шкоди у забезпеченні зручності використання та крос-ланцюжкової комбінабельності. Наприклад, користувач не може програмно постачати ліквідність до крос-ланцюжкової DEX, що працює на Optimism та Arbitrum, оскільки додаток повинен приймати opETH або arbETH.

ERC-7281 усуває проблему, вводячи токени xERC-20, які залишаються фунгібельними незалежно від того, скільки разів користувач переходить між ланцюгами або які постачальники мостів використовуються для мостіння токенів. Припустимо, користувач хоче перемістити обгорнутий USDT з Arbitrum на Optimism без виведення спочатку на Ethereum; постачальник моста може спалити токени xERC-20 на Arbitrum і витопити xERC-20 на Optimism - вартість токенів, витоплених на Optimism, все ще прив'язана до токенів, зарахованих на Lockbox і переналаштовується для збереження їх 1:1 резервування.

Важливо, що ERC-7281 надає переваги розгортання канонічного мостового токена, такого як CCTP (Cross-Chain Transfer Protocol) від Circle, не вимагаючи від протоколу централізованого зберігання мостових токенів. Наприклад, ліквідність консолідується навколо канонічного представлення токена проєкту, що покращує корисність токена для додатків DeFi та зменшує накладні витрати на створення різних ринків для різних версій одного й того ж активу.

Зміцнення суверенітету емітентів токенів

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

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

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

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

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

Переорієнтація інцентивів покращує відкрите конкуренцію та безпеку

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

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

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

Кращий управління ризиками для емітентів токенів

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

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

Впровадження ERC-7281 робить оцінку ризиків більш динамічною. Проєкти все ще мають завершити комплексну перевірку постачальників мостів, щоб вибрати відповідні об'єкти, що обмежують тарифи; Однак терміни оцінки ризиків можуть бути скорочені, щоб відобразити, що протоколи більше не перебувають у положенні «все або нічого». Замість того, щоб витрачати місяці на аналіз кількох мостів, щоб вибрати один варіант, проєкт може витратити вдвічі менше часу на вибір кількох постачальників мостів на початковому етапі та встановлення різних лімітів карбування на основі оцінки безпеки. Потім емітент токена може провести перевірку безпеки, щоб визначити, чи збільшувати або зменшувати ліміти карбування для вибраних партнерів по мосту або відкликати права на карбування з мосту (наприклад, у відповідь на злом або розкриття інформації про вразливість).

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

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

Покращення комбінуємості між екосистемами

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

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

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

Однак ERC-7281 все ще є покращенням у цьому відношенні з наступних причин:

1. Якщо оператор мосту досягає mintingLimit під час перекладу, трансляція мосту призупиняється і повторюється пізніше, коли параметри обмеження швидкості налаштовані. Користувачі не отримують власного обгорнутого представлення канонічного токена, на відміну від платформи обміну ліквідністю сьогодні.
2. Агрегатори мости мають більш передбачуваність того, коли виконається місткі транзакції та кількість очікуваних токенів. Оскільки mintingLimit та burningLimit налаштовані на використання блоків як одиниці виміру часу (як показано в розділі про параметри обмеження швидкості), легко обчислити, коли міст почне знову мінтити та спалювати токени; навпаки, передбачити, коли ліквідність збільшиться в мосту, еквівалентно грі в російську рулетку.

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

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

Мостові агрегатори не єдині, хто виграє від цього покращення компонування; Будь-який крос-чейн додаток може використовувати взаємозамінність токенів xERC-20 для створення більш захоплюючих додатків. Сьогодні це складніше через проблеми, пов'язані із залежністю від шляху: припустимо, розробник хоче перевести ETH з Ethereum, відкрити позицію кредитування на Arbitrum DEX і використати прибуток для покупки NFT на Optimism, перш ніж повернутися до Ethereum. Тут розробник повинен переконатися, що він інтегрується з постачальниками мостів у цих ланцюжках — оскільки ви не можете легко поміняти пропрієтарні версії — чого не відбувається, коли мостові токени проєкту стають взаємозамінними після прийняття xERC-20.

Цей робочий процес схожий на мости токен-емітент, описані раніше. Візьмемо для прикладу Circle CCTP:

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

Однак, хоча CCTP є централізованим протоколом, оскільки оператори Circle є єдиними організаціями, які мають право спалювати та карбувати його токени USDC, xERC-20 ліквідує ризик довіри, дозволяючи кільком організаціям із різними механізмами безпеки здійснювати крос-чейн перекази.

Підтримуючи візію Ethereum про майбутнє, спрямоване на роллапи та багато-ланцюгове

ERC-7281 може прискорити дорожню карту Ethereum, орієнтовану на зведення, надаючи проєктам впевненість у розгортанні токенів на нових EVM L2, яким може не вистачати надійних профілів безпеки встановлених ланцюгів L2. Наприклад, канонічний міст зведення етапу 0 є менш безпечним, оскільки Ethereum L1 не гарантує безпеку мосту. Проєкт токенів може поступово розгортатися в такому ланцюжку, надаючи обмежені права на карбування канонічному мосту та збільшуючи ліміт карбування, як тільки зведення переходить до етапу 1.

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

Можливі недоліки впровадження ERC-7281

Збільшені накладні витрати для команд управління проектами DAO

Хоча ERC-7281 дуже привабливий для протоколів, ДАО можуть сумніватися у прийнятті токенів xERC-20 через значні операційні витрати, які команди проектів ДАО повинні нести для управління токенами xERC-20 на різних розгортаннях.

Gerard Persoon’s Керуйте мосткими токенами на великій кількості ланцюгіввключає не вичерпний список одноразових та періодичних завдань, які протокол повинен виконати після міграції з ERC-20 на xERC-20:

Це дуже довгий список завдань

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

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

Наприклад окреслено основного члена команди Lido (у відповідь на пропозицію для Lido розгорнути wstETH як токен xERC-20 у всіх розгортаннях) поточні обов'язки команди PM, пов'язані з інфраструктурою сумісності, і контрастували з набором обов'язків, які ті ж члени команди повинні були б взяти на себе, якби Lido DAO проголосувала за міграцію wstETH на всіх доменах на версію xERC-20.

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

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

Наприклад, меншим проєктам може бути важче керувати накладними витратами на випуск токенів xERC-20 і вони вирішать вибрати керовану багатоланцюгову службу мосту токенів, як-от ITS (Interchain Token Service) від Axelar або NTT (Native Token Transfers) від Wormhole. Більш відомі проєкти можуть мати ресурси для управління адміністративними та операційними витратами на випуск токена xERC-20 і можуть вважати контроль, що надається ERC-7281, вартим додаткових накладних витрат на управління крос-чейн токенами.

Складнощі з міграцією існуючих токенів на стандарт xERC-20

Для проєктів, які не мають інтерфейсу карбування/спалювання або не можуть оновити контракти на токени для використання IERC20 через успадкування, і вже мають канонічні представлення нативних токенів, що циркулюють у нерідних ланцюгах, міграція на токени xERC-20 є тривалим процесом, який вимагає великої координації та включає складну мережу учасників — починаючи від власників токенів, біржі (DEX і CEX), партнерські мости та додатки, інтегровані з застарілим токеном ERC-20. Навіть з урахуванням цієї частини, протоколи все одно несуть витрати на розгортання ERC-20 у xERC-20 для завершення процесу міграції.

Як пояснено в обговоренні специфікації ERC-7281, існуючі токени потрібно буде заблокувати в Lockbox, щоб виготовити упаковані xERC-20 для користувачів. Спливання легасі ERC-20 відбувається незабаром після цього і включає ще один тривалий процес спільного спілкування з громадськістю щодо графіка заморожування виготовлення нових (легасі) токенів ERC-20. Знову ж таки, це може бути варто витрати з точки зору протоколу — хоча переваги також можуть бути недостатніми для виправдання витрат на координацію міграції на всю екосистему до сумісного з xERC20 представленням токена протоколу.

Більша ризикова поверхня для управління DAO

Управління токенами xERC-20 на кількох доменах за допомогою ERC-7281 вимагає активного управління з боку DAO, яка контролює протокол. Це включає встановлення таких параметрів, як ліміти на карбування, оновлення контракту Lockbox і призупинення карбування або спалювання токенів. Ці рішення стосуються безпеки і повинні регулюватися DAO, щоб уникнути відповідальності за рішення в закритій залі засідань.

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

Наприклад, такі гучні проекти, як Lido, стикаються з пильною увагою з питань управління. Додавання контролю над управлінням токенами збільшує ризик поглинання управління. Атака на управління може мати широкомасштабні наслідки, якщо проєкт консолідує всі токени ERC-20 у Lockbox, а DAO керує ним. Зловмисник може отримати контроль над Lockbox і впровадити шкідливого провайдера мосту без обмежень на карбування, що зробить токени xERC-20 в інших ланцюгах нічого не вартими.

Цей сценарій має паралелі з експлуатацією Multichain, де вразливість інфраструктури підпису мультисторонніх обчислень (MPC) дозволила хакерам підірвати основні адреси Multichain, які були опікуючими нативні токени на Ethereum та Dogecoin - ці токени підтримували токени, створені на не-нативних ланцюгах, таких як Fantom і Moonriver, що створило ефект доміно, який призвів до втрат проектів в інших місцях в результаті атаки на розумні контракти Multichain на Ethereum та Dogecoin.

Несумісність з максимально децентралізованими протоколами

ERC-7281 відповідає меті, коли токен випускається протоколом з управлінням токенами або централізованою організацією (наприклад, USDC Circle або стабільна монета CZKC). Однак це не так цінно, якщо протокол максимально децентралізований і не має формального управління — стейблкоїн LUSD від Liquity є прикладом токена, який було б важко зробити сумісним зі стандартом xERC-20.

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

Більший ризик від використання, що впливають на основні компоненти (контракт Lockbox та постачальники мостів)

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

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

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

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

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

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

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

Висновок

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

Кілька ключових гравців у сфері мостового зв'язку, включаючи Hyperlane, Omni, Sygma, Router Protocol і Everclear, взяли на себе зобов'язання прийняти ERC-7281, що вказує на значну привабливість цієї пропозиції. Навіть досвідчені емітенти токенів (які мають робочі механізми для з'єднання токенів) — такі як Circle — проявили інтерес до ERC-7281 для вирішення проблем, пов'язаних із несхваленими токенами, що впливають на користувачів і розробників.

ERC-7281 addresses these issues while mitigating many trade-offs associated with previous approaches to minting canonical tokens on remote domains. It provides liquidity-free bootstrapping, unlike enshrined bridges, does not require custom infrastructure like token-issuer bridges, and avoids vendor lock-in by allowing multi-bridge canonical token minting by approved bridge providers.

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

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

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