Введение

Модульные макси говорят, что будущее криптовалюты - это миллион (или больше) взаимосвязанных доменов и пользователей, переходящих между блокчейнами, как Алиса, бродящая по Удивительной стране. Почему придерживаться одной цепи, если можно получить доступ к передовой технологии, новым приложениям, амбициозным доходам от стейкинга/предоставления ликвидности, высокой производительности и ультранизким транзакционным сборам на других блокчейнах?

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

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

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

Давайте возьмем USDC в качестве примера необратимости среди в теории идентичных ERC-20 токенов на разных цепочках. В Сети Ethereum Layer 2 (L2), например, Arbitrum, Base, Optimism, обычно используется канонический мост для перемещения популярных токенов ERC-20 с Ethereum L1 на эти цепочки. Эти версии L2-токенов, происходящих из L1, обычно называются просто "мостовые [вставьте название токена]".

В случае USDC общими символами являются USDC.e, USDC.b и так далее. С течением времени Circle расширяет свои развертывания USDC на другие цепочки, включая L2, где USDC уже работает через канонический мост. Несмотря на то, что эти два токена выпускаются одним и тем же субъектом и имеют одинаковую цену, они технически разные, непереносимые токены, поэтому они не являются «взаимосовместимыми» - в то время как исходный USDC может быть мостом через CCTP мост Circle, мостовой USDC может быть мостом только обратно к L1 через канонический мост.

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

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

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

Обновление на мостах блокчейна

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

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

Подходы к облегчению передачи активов между цепями различаются, но рабочие процессы мостов для токенов обычно следуют одному из трех высокоуровневых шаблонов:

Мосты блокировки и эмиссии

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

Сжигание и создание мостов

• Вместо блокировки токенов в счете доверия, такой подход сжигает (уничтожает) токены на исходной цепочке;
• Затем мост начинает выпускать эквивалентное количество на целевой цепи;
• Для обратной поездки мостовые токены сжигаются на целевой цепи перед тем, как на исходной цепи выпускаются новые токены;
• Это позволяет поддерживать общий объем токенов, обеспечивая кросс-чейн-трансферы.

Атомные свопы

• В этом подходе активы в исходной цепочке непосредственно обмениваются на активы в целевой цепочке с другой стороной.
• Атомные свопы работают путем взаимной блокировки средств с одинаковым секретным значением для их разблокировки, что означает, что если на одной стороне секрет был раскрыт, его также можно раскрыть и на другой стороне. Это дает свопам свойство атомарности.
• Атомарность означает, что обмен либо выполняется полностью (с обеих сторон), либо вообще не выполняется, предотвращая мошенничество или частичные/неудачные переводы.

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

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

Кросс-чейн намеренияпозволяют пользователям перемещать токены между цепочками, не беспокоясь о сложности мостовой. В мостах на основе намерений пользователи вносят средства на исходной цепочке и указывают желаемый результат на цепочке назначения (их «намерение»). Специализированные операторы, называемые «fillers» или «solvers», могут выполнить это намерение, отправив запрошенные токены пользователю на цепочке назначения заранее. Затем операторы доказывают, что перевод произошел, чтобы получить заблокированные средства на исходной цепочке в качестве возмещения.

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

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

Мост, авторизованный для блокировки базовых токенов на исходной цепи и выпуска их обернутых представлений на целевой цепи, обеспечивает постоянное общее количество токенов. За одну единицу базового токена точно выпускается одна единица соответствующего обернутого токена и наоборот. Если приложение принимает обернутый токен в качестве средства обмена или использует обернутые активы в качестве валюты, разработчики и пользователи приложения доверяют поставщику моста в обеспечении реальных активов, поддерживающих обернутый токен.

Зачем нам нужны мосты?

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

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

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

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

Чтобы решить проблему, Боб развертывает версию BobDEX на Arbitrum (низкой комиссии, высокой пропускной способности Layer 2 (L2) rollup) и развертывает обернутую версию токена BOB (wBOB) на L2 через мост Arbitrum-Ethereum. BobDEX на Arbitrum идентичен BobDEX на Ethereum, за исключением того, что он использует wBOB, а не собственные токены BOB для наград LP и управления.

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

Ситуация является выигрышной как для Боба, так и для пользователей:

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

Преимущества моста также простираются на повышение возможностей комбинированного инновационного развития и открытие новых случаев использования, которые используют ликвидность моста. Например, Элис может создать протокол займа под названием AliceLend на Arbitrum, который принимает wBOB в качестве залога от заемщиков для расширения функциональности wBOB и создания нового рынка длякредитование и заимствование.

Кредиторы, предоставляющие ликвидность AliceLend, уверены в получении депозитов: если пользователь не выплачивает кредит, AliceLend автоматически аукционирует заложенные токены wBOB в качестве компенсации кредиторам. В этом случае покупатели ликвидированных залоговых токенов wBOB принимают на себя роль LP на BobDEX и имеют ту же гарантию, что токены wBOB можно обменять 1:1 на оригинальные токены BOB.

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

Почему мостовые токены становятся нефункциональными?

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

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

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

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

Боб после ругательства на свопе

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

Ценность каждого мостового токена связана с поставщиком моста, ответственным за хранение депозитов на домашней цепочке и выпуск представлений на целевой цепочке; Поставщик моста Боба может выплатить только 200 USDC Бобу, так как это сумма, на которую у него есть средства для покрытия из его депозита; 200 USDC Алисы не может быть выведено через поставщика моста Боба, так как он никогда не получал депозит или не выдавал Алисе IOU. Алиса должна вывести свои заблокированные USDC из Arbitrum на Ethereum и пройти через поставщика моста Боба, прежде чем Боб сможет получить оставшиеся токены.

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

Используя предыдущий пример, если у нас есть axlUSDC и USDC.e на цепи и мы хотим обменять их на ETH и наоборот, нам необходимо развернуть два пула ликвидности - ETH/axlUSDC и ETH/USDC.e. Это приводит к так называемой проблеме «фрагментации ликвидности» - ситуации, когда торговые пулы имеют меньшую ликвидность, чем могли бы иметь, потому что есть несколько пулов, которые подходят в основном для одной и той же торговой пары.

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

Итак, как мы приступаем к реализации канонических версий токена на каждой цепи, на которой он ожидает использоваться и передаваться между ними? В следующем разделе объясняются некоторые популярные подходы к созданию канонических токенов на нескольких цепях.

Реализация канонических токенов на разных цепочках

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

1. Создавайте канонические токены через мосты канонического свертывания/побочных цепей
2. Создавайте канонические токены через стороннего поставщика моста
3. Создавайте канонические токены через мост токен-эмитента
4. Прямое многоцепное выпуск с атомными свопами

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

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

1. Создавайте канонические токены через мосты канонического rollup/sidechain

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

Хотя канонический мост создает каноническое представление токена, другие представления по-прежнему существуют. Это происходит просто потому, что у канонических мостов часто есть ограничения, которые мешают им предлагать пользователям лучший опыт. Например, переход от Arbitrum/Optimism к Ethereum через канонический мост rollup вызывает семидневную задержку, поскольку транзакции должны быть проверены верификаторами — и возможно оспорены доказательство мошенничества, если недействительно - до слоя расчета роллапа (Ethereum - урегулирует пакет транзакций).

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

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

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

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

1.1. Создание канонических токенов с помощью мостов ликвидности

Основная проблема использования моста роллапа для перемещения канонических токенов заключается в низкой ликвидности и задержках при перемещении активов. Протоколы обходят эту проблему, сотрудничая с мостами ликвидности для обеспечения быстрых выводов и мостов с низкой задержкой*.

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

Каноническое представление токена на целевой цепи обычно является версией, чеканенной каноническим боковым цепочным/rollup мостом, хотя существуют исключения (как мы увидим позже). Например, канонической версией USDT на Optimism является opUSDT, чеканенный мостом Optimism.

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

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

Процесс моста через мост для обеспечения ликвидности будет выглядеть следующим образом:

• Заблокировать местные токены на исходной цепи
• Представление моста между цепями монеты на целевой цепи
• Обменять связанное представление на каноническое представление на целевой цепочке через пул AMM
• Отправьте канонические токены пользователю

Этот процесс аналогичен для всех мостов ликвидности (Across, Celer, Hop, Stargate и т. д.). Тем не менее, обычно он абстрагируется от конечного пользователя, особенно с помощью решателей/заполнителей, и будет казаться одной транзакцией, несмотря на то, что в нем участвует много подвижных частей.

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

Переход ликвидности отличен, в основном, потому что он исправляет проблему задержки в мостике роллапа; например, Hop позволяет специализированным сторонам, известным как "Бондеры", подтверждать правильность транзакции вывода пользователя на L2 и фронтить затраты на вывод из L1-моста роллапа. Каждый Бондер запускает полный узел для цепи L2 и может определить, будет ли транзакция вывода пользователя в конечном итоге подтверждена на L1, уменьшая риск того, что пользователь инициирует мошеннический вывод и вызывает убытки для Бондера.

Ликвидностьные мосты также позволяют пользователям перемещаться между большим количеством цепей, в отличие от канонических мостов; например, Hop позволяет пользователям создавать мосты между Arbitrum и Optimism без необходимости выводить средства на Ethereum сначала. Как и быстрая мостовая связь L2→L1, быстрая мостовая связь L2→L2 требует, чтобы Бондеры запускали полную ноду для исходной L2 цепи, чтобы подтвердить выводы перед предоставлением средств для выпуска токенов пользователю на целевой L2 цепи. Это обеспечивает большую комбинируемость между роллапами и значительно улучшает пользовательский опыт, поскольку пользователи могут перемещать токены между роллапами без проблем.

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

Недостатки мостов ликвидности

1. Слиппаж

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

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

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

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

2. Ограничения ликвидности

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

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

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

3. Несогласованные стимулы

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

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

Мосты на основе ликвидности также не предпочитают активы с низкой торговой активностью (что делает их менее вероятными для привлечения LP). Издатели токенов с низким объемом мостовой или новых токенов с низким объемом мостовой придется либо устанавливать пулы AMM и создавать ликвидность для обмена местными токенами (связанными с помощью мостовой ликвидности) против канонического представления токена издателя, либо сотрудничать с операторами мостов, чтобы увеличить финансовые стимулы для LP, чтобы предоставить ликвидность для этого актива.

4. Плохой пользовательский интерфейс для мостиков

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

В данной ситуации у пользователей есть два варианта выбора (оба не оптимальны):

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

2. Эмитировать канонические токены через канонический мост третьей стороны

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

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

Проблема необратимых мостовых токенов также устраняется; при условии, что пользователи используют одобренного поставщика мостов, они всегда могут обменивать их 1:1 на другие мостовые токены. Такой подход дополнительно устраняет проблемы, связанные с ликвидностью в канонической модели моста:

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

Некоторые примеры монет с одним поставщиком моста в дикой природе включают Omnichain Fungible Token (OFT) от LayerZero, Interchain Token Service (ITS) от Axelar, xAsset от Celer и anyAsset от Multichain. Все примеры являются фактически собственными токенами и несовместимы с представлениями того же токена, отправленного через другого поставщика моста. Эта тонкая деталь подчеркивает некоторые проблемы с таким подходом к обработке мостовых токенов. А именно следующие:

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

Недостатки использования канонических сторонних мостов

1. Закрытый производитель

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

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

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

Для осуществления перехода Бобу необходимо убедить пользователей открывать обернутые представления монет BobToken, выпущенные через LayerZero, отправляя транзакцию, которая сжигает мостовые токены OFT и разблокирует BobToken на Ethereum. Пользователи теперь могут переключиться на новое каноническое представление BobToken, блокируя токены с помощью Axelar на Ethereum и получая канонические BobToken (сопоставленные с общим объемом контракта токена на Ethereum) на целевой цепочке. Это как дорогостоящая процедура, так и сопряжено с массовым координационным и операционным бременем для команд управления проектами DAO, поэтому придерживание выбранного поставщика обычно является наиболее безопасным вариантом.

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

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

В заключительной части предыдущего раздела, посвященной привязке к поставщику, подчеркивается еще одна проблема, связанная с использованием канонического стороннего моста: эмитенты токенов жертвуют контролем над каноническими промежуточными токенами в обмен на большее удобство и улучшение пользовательского интерфейса. Возьмем предыдущий пример: BobToken на Ethereum полностью находится под контролем Боба, поскольку он контролирует базовый контракт токена ERC-20, но BobToken на Optimism, Arbitrum и Base контролируются LayerZero, который владеет контрактом OFT, который выпускает канонические представления BobToken в этих блокчейнах.

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

3. Высокий риск отказов мостов

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

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

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

(Источник)

Потеря функций настраиваемого токена

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

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

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

Ограниченная поддержка цепей

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

• Дождитесь поддержки желаемой цепочки от поставщика моста, что может занять много времени или вообще не произойти из-за высоких затрат на интеграцию (например, неравнозначность EVM эры ZKsync, что заставило многие dapp-ы никогда не развертывать его)
• Используйте другого поставщика моста для этой конкретной цепи, что вновь вводит проблему нефункциональных токенов и фрагментации ликвидности

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

Несогласованные адреса токенов кросс-чейн

Сторонние провайдеры мостов могут развертывать токены моста с разными адресами в каждой цепочке из-за особенностей своего технологического стека — например, отсутствие поддержки CREATE2. Отсутствие согласованности адресов в свою очередь создает множество проблем с пользовательским опытом:

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

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

3. Создание основных токенов через мост между токен-эмитентом

Если разработчик хочет сохранить максимальный контроль над кросс-чейн развертыванием токена проекта, он может управлять выпуском канонических представлений токена на удаленных цепях. Это описывается как "доверять эмитенту токена", поскольку стоимость каждого мостового представления токена привязана к заблокированным токенам на домашней цепи токена по протоколу, ответственному за выпуск оригинальной версии токена на исходной цепи.

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

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

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

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

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

Эта связь (между мостовыми версиями токенов протокола и безопасностью протокола) является дружественной, поскольку безопасность собственных токенов, поддерживающих канонические представления, уже зависит от безопасности протокола, поэтому пользователи и внешние разработчики не берут на себя новых доверительных предположений. Это особенно верно длямосты стейблкоиновпринадлежащий эмитентам, таким как Circle и Maker (теперь Sky) - пользователи уже доверяют эмитентам стейблкоинов, чтобы у них было достаточно активов для покрытия их погашения стейблкоинами на фиатные валюты, поэтому доверие безопасности моста стейблкоинов не составляет труда.

Однако это также представляет собой центральную точку отказа - если инфраструктура моста выпуска токенов подвергается взлому, стоимость всех канонических представлений, циркулирующих в многоцепочечной экосистеме, находится под угрозой. Это также означает, что только централизованные хранители (например, Circle в случае USDC) могут реализовать эту модель выпуска канонических мостовых токенов.

Финальные мысли

Как показано в этом отчете, взаимозаменяемость активов межцепочечных переводов является важной частью взаимодействия с роллапами с последствиями для опыта перемещения между различными цепочками. Способность токенов оставаться взаимозаменяемыми при переходе на удаленные цепочки также влияет на опыт разработчика, так как некоторые сценарии использования зависят от этой функции.

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

Хотя эти подходы решают конкретные проблемы, они не решают все проблемы, и их использование для обеспечения возможности взаимозаменяемости активов между блокчейнами требует некоторых нежелательных компромиссов. Можем ли мы найти лучший подход? Ответ - да.

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

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

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

Оставайтесь на связи!

Отказ от ответственности:

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