Если вы еще не читали часть I серии How To Make кросс-чейн токены снова обменяемыми, вам может захотетьсяВзглянитеСначала разберем, почему мостовые токены теряют сходство и какие вызывает это проблемы. Во второй части мы рассмотрим ERC-7281, новый стандарт, который упрощает передачу токенов между блокчейнами, повышает надежность и дает эмитентам больший контроль.

Необходимость лучшего подхода

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

• Создание канонических представлений токена на удаленных цепях через канонические мосты роллапа/сайдчейна
• Чеканка канонических представлений токена в удаленных цепочках через сторонний мостовой сервис
• Создание канонических представлений токена на удаленных цепях через канонический мостовой сервис, управляемый эмитентом токена

Каждый из этих подходов имеет свои компромиссы, поэтому неудивительно, что предложение 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 применяется логика "сейфа": поставщик моста обертывает токены ERC-20, внесенные пользователями, в xERC-20 токены, переводя их в контракт сейфа. Затем сейф одобряет мост для чеканки эквивалентного количества токенов xERC-20.

Токены xERC-20, созданные мостом на целевой цепи, сжигаются на исходной цепи с использованием функции сжигания burn(). Этот процесс гарантирует, что количество токенов не превышает предельного значения сжигания моста, увеличивает его и уменьшает общее предложение токенов 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 использует механизм mint-and-burn, который сегодня предпочитают большинство (если не все) мосты, устаревшие или необновляемые токены ERC-20 не могут работать «из коробки» с ERC-7281.

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

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

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

Нативные криптокошельки хранят нативные токены — то есть токены, используемые для оплаты комиссий за газ валидаторам. Примером токена, для которого есть нативный криптокошелек для упаковки в xERC-20 токен, является ETH: упаковка ETH в xERC-20 токен потребует вызова функции депозита Lockbox и депонирования ETH для получения совместимого с ERC7281 представления ETH.

Обычные (не нативные) депозитарные сейфы токенов ERC-20, таких как USDC, DAI, WETH, USDT и т. д. Например, чтобы выпустить USDC в виде токена xERC-20, пользователь должен вызвать deposit() в контракте Lockbox после блокировки USDC.

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

Таким образом, упаковывая канонические токены ERC-20 в токены xERC-20 с поддержкой mint/burn, Lockbox обеспечивает важный уровень совместимости для стандарта. Однако в некоторых случаях, таких как интеграция других решений моста в xERC-20, использование только защищенного ящика и возврат обернутого токена не подходят. По этой причине в проектах могут быть реализованы контракты адаптеров.

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

В случаях, когда протоколы моста не предназначены для распознавания операций, присущих токенам xERC-20 (создание/сжигание, соответствующее ведение журнала и т. д.), приложения могут создавать адаптерные контракты. Эти контракты функционируют как автоматизированные обертки и распаковщики, эффективно переводя стандартное поведение ERC-20 approve + call в более тонкую схему создания/сжигания, необходимую для xERC-20.

Это необходимо, потому что многие протоколы мостов (например, CCIP от Chainlink) остаются оптимизированными для обычного поведения ERC-20. Контракт адаптера может преодолеть этот разрыв в совместимости, закрепив такую логику: он помещает токены в Lockbox для генерации представления xERC-20 в исходной цепочке, а позже, после получения сообщения в цепочке назначения, запускает механизм вывода для возврата к каноническому активу.

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

Почему ERC-7281? Аргументы в пользу стандарта суверенного мостового токена

На высоком уровне ERC-7281 имеет четыре основных цели:

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

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

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

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

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

Мы можем дополнительно расширить эти цели, чтобы увидеть, какие преимущества предоставляет ERC-7281 для протоколов и сообществ.

Анализ преимуществ ERC-7281

Улучшение пользовательского опыта и устранение фрагментации ликвидности

ERC-7281 решает различные версии проблемы путевой зависимости, описанной во введении.

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

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

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

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

Укрепление суверенитета эмитентов токенов

xERC-20 описываются как «суверенно-мостовые токены», поскольку эмитенты токенов не ограничены в использовании конкретной опции для создания канонических представлений токена и сохраняют контроль над дизайном и администрированием бридж-токенов при развертывании. 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. Не устанавливайте параметр допустимого проскальзывания; вместо этого создайте логику для поиска ликвидности on-chain (например, через DEX), если количество полученных токенов на одной или нескольких цепях меньше ожидаемого количества.

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

Однако ERC-7281 все еще является улучшением в этом отношении по следующим причинам:

1. Если оператор моста достигает mintingLimit во время выполнения транзакции, транзакция моста удерживается и повторяется позже, когда параметры ограничения скорости корректируются. Пользователи не получают проприетарное обернутое представление канонического токена, в отличие от современных мостов ликвидности.
2. Агрегаторы мостов имеют большую предсказуемость в том, когда будет выполнена операция моста и сколько токенов ожидать. Поскольку mintingLimit и burningLimit настроены на использование блоков в качестве единицы измерения времени (как показано в разделе о параметрах ограничения скорости), легко рассчитать, когда мост начнет снова выпускать и сжигать токены; в отличие от предсказания увеличения ликвидности в мосту, что эквивалентно игре в русскую рулетку.

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

Поскольку мост xERC-20 токенов не подвержен движениям ликвидности, пользователи могут быть уверены, что кросс-чейн транзакции не будут понести скольжение, даже если они не будут выполнены немедленно.

Не только агрегаторы мостов получат выгоду от этого улучшения в композабельности; любое кросс-чейн-приложение может использовать фунгибельность токенов xERC-20 для создания более увлекательных приложений. Сегодня это сложнее из-за проблем с зависимостью от пути: предположим, что разработчик хочет мостить ETH с Ethereum, открыть позицию в займе на DEX Arbitrum и использовать прибыль для покупки NFT на Optimism перед возвращением в Ethereum. Здесь разработчик должен обеспечить интеграцию с поставщиками мостов на этих цепочках — поскольку нельзя легко обменивать собственные версии — что не является таковым в случае, когда мостовые токены проекта становятся фунгибельными после принятия xERC-20.

Этот рабочий процесс аналогичен мостам между токенами и эмитентами, описанным ранее. В качестве примера возьмем Circle CCTP:

Протокол кроссчейн-передачи Circle позволяет пользователям иметь унифицированную, каноническую версию токена USDC, не попадая в ловушку экосистемы своих цепочек. Все кроссчейн-переводы обрабатываются через его протокол по схеме burn-and-mint.

Однако, в то время как 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 очень привлекателен для протоколов, DAO могут колебаться в принятии токенов xERC-20 из-за значительных операционных издержек, с которыми команды проектов DAO должны столкнуться при управлении токенами xERC-20 на различных развертываниях.

Герард ПерсонУправляйте бридж-токенами в большом количестве цепочек включает в себя неполный перечень разовых и повторяющихся задач, которые протокол должен выполнять после миграции с ERC-20 на xERC-20:

Это очень длинный список задач

Предложенным решением является то, чтобы DAO передавали некоторые из этих административных задач, связанных с управлением кросс-чейн xERC-20 токенами, сторонним сервисам, но это всего лишь обмен одного компромисса (затраты на человеческие ресурсы) на другой (затраты на услуги найма).

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

Например Обозначен основной член команды Lido(в ответ на предложение Лидо развернуть wstETH в качестве токена xERC-20 на всех развертываниях) текущие обязанности команды PM, занимающейся инфраструктурой взаимодействия, и сравнивает их с набором обязанностей, которые те же члены команды должны были бы принять, если Лидо 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 в защищенном ящике, а 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)

Мы уже упоминали, как работает путь зависимости, и почему это помогает обеспечить гарантии того, что эксплойт, влияющий на цепочку A, не повлияет на цепочку B, или что эксплойт, связанный с мостом A на цепочке A, не повлияет на мост B на цепочке B. ERC-7281 устраняет путь зависимости, что имеет преимущества, но также вводит компромисс в области безопасности:

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

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

Контракт Lockbox, управляемый DAO, может вызвать негативные каскадные эффекты в случае атаки на управление. Но даже при безопасном управлении DAO ошибка в контрактах на чужом/родном языке Lockbox на домашней цепи токена может вызвать столько же проблем (Сифу теперь владелец контракта Lockbox для проекта, и средства больше не SAFU). По сравнению с этим проблема снижается в статус-кво поскольку контракты хранилища (эквивалент контракта Lockbox поставщика моста) содержат только токены, переброшенные через соответствующий сервис моста. Таким образом, ошибка в контракте хранилища для одного поставщика влияет только на пользователей, которые внесли токены через этот мост.

Накладные расходы на интеграцию экосистем

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

Риск связан с тем, что злоумышленники могут добавлять вредоносные контракты в реестр токенов и обманывать пользователей и разработчиков, заставляя их отправлять токены на неправильный адрес. Это может привести к краже токенов как в сетях L2, так и в сетях L1. Биржи сталкиваются с аналогичными проблемами, поскольку поддельные токены могут вызвать серьезные проблемы, такие как неожиданное поведение токенов, которое отличается от проверенных канонических токенов.

Заключение

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

Несколько ключевых участников в области мостиков, включая Hyperlane, Omni, Sygma, Router Protocol и Everclear, обязались принять ERC-7281, что указывает на значительное движение по предложению. Даже установленные эмитенты токенов (у которых есть рабочие механизмы для моста токенов), такие как Circle, проявили интерес к ERC-7281, чтобы решить проблемы, вызванные неодобренными токенами, влияющими на пользователей и разработчиков.

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

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

Отказ:

1. Эта статья перепечатана с [2077 Исследование]. Все авторские права принадлежат оригинальному автору [Исследование 2077]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Обучение у ворот команде, и они оперативно с этим справятся.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не представляют собой инвестиционных советов.
3. Команда Gate Learn занимается переводом статьи на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.