Выпуск токена раньше был простым: вы развертывали его на Ethereum, где была вся активность - пользователи, трейдеры, капитал и ликвидность. Сегодня ландшафт намного более сложный. Ликвидность разбросана по Bitcoin, Ethereum, L2s, Solana и другим цепочкам. Так где же вы должны выпустить свой токен? Нет ясного ответа.
Но что, если вам не нужно было выбирать только одну цепочку? Представьте токен, который работает везде, свободно перемещаясь по всей криптоэкономике.
Благодаряпротоколы взаимодействияТеперь, с помощью мостов (также известных как bridges), возможно выпускать токены с единой рыночной платформой, охватывающей несколько цепочек. Это создает глобальную ликвидность без границ, упрощает операции для выпускающих токены: большая ликвидность, большее принятие и более сильные сетевые эффекты — без головной боли от фрагментации. По сути, это похоже на наличие глобального банковского счета, который работает везде, интегрированный во все экосистемы DeFi.
В этой статье мы сравним ведущие фреймворки токенов, предлагаемые различными протоколами взаимодействия. Цель - оценить их уникальные особенности, преимущества и компромиссы, чтобы помочь командам выбрать лучшее решение для выпуска нативных многоканальных токенов.
Мы рассмотрим следующие фреймворки:
Давайте погрузимся.
Фреймворки токенов работают двумя основными способами, в зависимости от того, делаете ли вы существующий токен мультичейн или запускаете мультичейн токен с самого начала.
Когда токен выпускается нативно на нескольких цепях с первого дня, его предложение распределяется по этим цепям. При перемещении токенов между цепями они сжигаются на исходной цепи и чеканятся на целевой цепи, обеспечивая постоянное общее предложение.
Представьте это как систему бухгалтерского учета (как объясняли многие команды межсетевого взаимодействия). Вот пример: рассмотрим Токен X с общим количеством 1000 токенов, распределенных на основе спроса по пяти цепочкам:
Если пользователь переводит 50 токенов из Chain E в Chain A, то эти токены сжигаются на Chain E и выпускаются на Chain A. Обновленное распределение будет:
Этот процесс обеспечивает, что общее количество остается на уровне 1000 токенов, облегчая безупречные переводы между цепями без проскальзывания.
Для уже существующих токенов, которые изначально были развернуты на одной цепи, процесс немного отличается. Вся предложение существует на одной цепи, и при переводе на другую цепь часть предложения блокируется в смарт-контракте на исходной цепи, в то время как эквивалентное количество эмитируется на целевой цепи.
Этот метод похож на то, как работают обернутые токены. Токены, заблокированные на Chain A, могут быть затем созданы на Chain B в виде обернутой версии. Однако теперь эти токены также могут перемещаться с Chain B на Chain C с использованием метода сжигания-надбавки, без необходимости блокировки на нескольких цепях. Оригинальное количество остается на Chain A, что гарантирует, что переводы между цепями просто заключаются в проверке соответствия сожженных и созданных токенов.
Вот почему наличие токена, который можно торговать на объединенном рынке, охватывающем несколько цепочек, приносит пользу командам:
РассмотретьПротокол межцепочечного перевода Circle (CCTP). Запустив CCTP, Circle позволила USDC торговаться без проблем на поддерживаемых цепях, решая ключевые проблемы:
Уникальный набор функций Circle для USDC обусловлен их специальным мостом CCTP, роскошью, которой не многим проектам посчастливится обладать. Именно здесь в игру вступают фреймворки токенов, поддерживаемые протоколами взаимодействия. Эти фреймворки предоставляют решение, аналогичное тому, что предлагает CCTP для USDC, но для любого токена. Выпуская токен через эти фреймворки, проекты могут создать унифицированный рынок по множеству поддерживаемых цепей, обеспечивая простой перевод с использованием механизмов сжигания/блокировки и эмиссии.
Теперь, когда мы понимаем, как работают токеновые фреймворки и их выгоды, давайте сравним различные решения, доступные на рынке для команд, стремящихся выпустить свои токены.
Вот объяснение критических аспектов безопасности, описанных в таблице:
1. Механизм верификации
Механизм проверки является основой того, как осуществляется проверка передачи данных между цепями. Он относится к тому, как проверяются сообщения и к типу настройки в терминах механизмов проверки, которые каждая система предоставляет - будь то один вариант, модульная система с несколькими вариантами или гибкий дизайн, совместимый с любым мостом - что позволяет эмитентам токенов выбрать наиболее подходящее решение на основе их требований безопасности.
Хотя настраиваемые механизмы проверки предлагают преимущества, это настройки по умолчанию, которые остаются наиболее широко используемыми. Поэтому важно обращать внимание на безопасность схемы проверки по умолчанию. Рекомендуется, чтобы команды использовали дополнительные схемы проверки поверх стандартных, чтобы улучшить свою систему безопасности.
Когда речь идет о живости, полагаться на несколько схем проверки имеет как плюсы, так и минусы. С одной стороны, это повышает отказоустойчивость: если один провайдер перестает работать, другие могут обеспечить непрерывную работу, улучшая надежность системы. Однако это также увеличивает сложность системы. Каждая дополнительная схема представляет потенциальную точку отказа, повышая риск нарушения операций.
2. Гибкость при верификации
Подчеркивается гибкость каждой структуры в настройке ее механизма проверки - конкретно, может ли эмитент токена выбирать из различных вариантов или ограничен определенными настройками по умолчанию.
3.Заметные готовые схемы верификации
Готовые схемы представляют собой готовые к использованию механизмы проверки, которые эмитенты токенов могут использовать для проверки сообщений, упрощая развертывание. Фреймворк с широким выбором надежных готовых вариантов обычно является положительным знаком.
Хотя некоторые фреймворки предлагают больше схем проверки, чем другие, важно, чтобы оценить их на основе их спектра безопасности, который может варьироваться от одного валидатора до комплексных наборов валидаторов.
Например, OFTs предлагают варианты DVN, которые являются одними из основных проверяющих, наряду с более надежными выборами, такими как CCIP или Axelar, которые используют полные наборы проверяющих. Точно так же, Warp Token предлагает ISM, такие как Multisig ISM, которые включают проверяющих, управляемых сообществом Hyperlane, и в то же время есть варианты, такие как Aggregation ISM, которые позволяют командам объединять безопасность из нескольких ISM.
Кроме того, многие из этих схем проверки могут еще не быть широко принятыми или тщательно протестированными в реальных сценариях. Таким образом, команды должны тщательно оценить качество доступных схем проверки и выбрать ту, которая соответствует их желаемому уровню безопасности. Мы настоятельно рекомендуем использовать доступные варианты для создания безопасной и устойчивой среды для проверки токенов. В будущей исследовательской статье мы более подробно рассмотрим свойства безопасности различных схем проверки, предлагаемых каждой токен-структурой.
4. Схема верификации по умолчанию
Указывает, обеспечивает ли фреймворк механизм проверки по умолчанию. Это важно, потому что большинство команд обычно выбирают варианты по умолчанию из-за удобства. Если эмитент токена собирается выбрать вариант по умолчанию, крайне важно оценить его безопасность, а также рассмотреть возможности настройки, предлагаемые для улучшения безопасности настройки.
5. Участие в верификации приложения
Освещает, есть ли у команд возможность участвовать в процессе верификации, добавляя дополнительный уровень безопасности, или позволяет им контролировать свою безопасность. Это важно, потому что это позволяет командам улучшить безопасность, интегрируя собственную систему верификации наряду с существующими механизмами. Таким образом, если другие методы верификации не сработают, они могут полагаться на собственные средства защиты, чтобы предотвратить потенциальные проблемы.
Например, такие команды, как StarGate, Tapioca, BitGo, Cluster и Abracadabra, запускают свои собственные DVN на LayerZero, демонстрируя, как другие команды могут использовать доступные настройки.
Больше команд должны воспользоваться этим дополнительным слоем безопасности, несмотря на дополнительные усилия, которые требуются. При эффективной реализации этой функции она может быть решающей в предотвращении серьезных проблем во время критических сбоев.
6. Сопротивление цензуре
Определяет, может ли и каким образом быть цензурированы сообщения, что потенциально может привести к отключению приложений и вызвать проблемы с живучестью для команды. В большинстве случаев, даже если приложения подвергаются цензуре, они могут переключиться на другие механизмы верификации или релеи в рамках той же системы. Однако для этого требуется дополнительные усилия и может оказаться не практичным решением для краткосрочных проблем.
7.Открытость исходного кода
Открытые исходные коды позволяют разработчикам аудитировать безопасность фреймворка и общую настройку, обеспечивая прозрачность выполнения кода.
Эта таблица сравнивает структуры комиссий нескольких токен-фреймворков, фокусируясь на том, как каждый обрабатывает затраты на операции протокола, сообщения и любые дополнительные платежи. Важно отметить, что все фреймворки позволяют добавлять настраиваемые комиссии, специфичные для приложения, на уровне приложения. Более того, есть затраты, связанные с процессом проверки и передачи, включая комиссии, уплачиваемые релейщикам, трансиверам или подобным сущностям, во всех фреймворках.
В настоящее время большая часть сборов связана с проверкой и ретрансляцией сообщений. Как упоминалось ранее, все платформы маркеров предоставляют возможность использовать несколько механизмов для проверки сообщений. В то время как каждая дополнительная схема проверки повышает безопасность системы, она также увеличивает комиссии и затраты для пользователей.
1. Протокольные сборы
Это относится к комиссиям на уровне протокола, которые взимаются каждой платформой за выполнение трансферов или других операций.
Присутствие переключателя платы, управляемого DAO, означает, что эмитенты токенов могут быть вынуждены платить дополнительные сборы за протоколы взаимодействия, лежащие в основе фреймворков токенов (например, LayerZero для OFTs или Hyperlane для Warp Token). Это создает зависимость от управления DAO, так как любые изменения в переключателе платы непосредственно влияют на токены, выпущенные через эти фреймворки, делая их подверженными решениям DAO относительно структуры платы.
Эта таблица подробно описывает ключевые свойства смарт-контрактов каждой платформы, выделяя их различную степень гибкости, безопасности и настройки с акцентом на историю развертывания, проверки безопасности, предлагаемые вознаграждения и значимые настройки для гранулярного контроля.
Важно отметить, что все фреймворки позволяют приложениям устанавливать ограничения на скорость и черные списки, важные функции безопасности, которые, если используются эффективно, могут предотвратить значительные финансовые потериКроме того, каждая платформа предлагает гибкость развертывания смарт-контрактов в виде немутабельных или обновляемых в зависимости от конкретных потребностей приложения.
1. Развернуто с
Это поле показывает, когда были развернуты смарт-контракты каждого фреймворка. Это дает представление о том, как долго функционирует фреймворк.
2.Аудиты
Количество аудитов является важнейшей мерой безопасности. Аудит проверяет целостность смарт-контрактов фреймворка, выявляя уязвимости или проблемы, которые могут скомпрометировать систему.
3.Вознаграждения
Вознаграждения отражают финансовые стимулы, предлагаемые фреймворками для поощрения внешних исследователей безопасности находить и сообщать об уязвимостях.
4. Заметная особенность для точного контроля
Средства смарт-контрактов позволяют приложениям реализовывать различные настраиваемые функции безопасности в зависимости от их конкретных потребностей. В данной области рассматриваются несколько основных функций безопасности, которые каждый фреймворк предлагает для обеспечения безопасности.
Каждая рамка приносит уникальные возможности и имеет разный уровень вовлеченности разработчиков, протоколов и платформ в зависимости от их технической ориентации, интеграций и гарантий безопасности.
1. Основные участники
Этот раздел выделяет различные команды, активно участвующие в создании и поддержке каждой структуры. Разнообразный набор участников, помимо первоначальной команды разработчиков, является положительным индикатором нескольких факторов: (1) более широкий спрос на структуру и (2) доступность и простота использования структуры, независимо от разрешения или через общее сотрудничество.
2.Принятие
Внедрение отражает уровень использования и популярности каждой платформы, измеряемый количеством развернутых токенов и общей обеспеченной стоимостью. Он дает представление о том, насколько широко платформа была принята разработчиками и протоколами, а также о ее надежности в обеспечении безопасности активов.
3.Известные команды
Этот раздел подчеркивает лучшие команды и протоколы, которые приняли каждую рамку, отражая их доверие отрасли и общую привлекательность.
4.Покрытие виртуальных машин
Охват ВМ относится к количеству поддерживаемых виртуальных машин каждым фреймворком. Большее количество ВМ обеспечивает большую гибкость и совместимость с различными средами блокчейна. Это дает приложениям и эмитентам токенов больше возможностей в терминах разнообразных сообществ, в которые они могут привлечь.
5. Цепи, развернутые на
В этом поле отражается количество цепочек, на которых развернут каждый фреймворк, т. е. количество цепочек, которые может поддерживать каждое приложение или издатель токенов, если он решит использовать определенную платформу. Это напрямую связано с количеством рынков и экосистем DeFi, к которым могут подключиться приложения. Более высокий уровень развертывания цепочки означает более широкий доступ к ликвидности.
Кроме того, возможность без разрешения расширять фреймворк на разных цепях имеет большой потенциал, но может быть вызовом, если разработчикам требуется строить и поддерживать критическую инфраструктуру самостоятельно. Для некоторых, например, для команд, стремящихся создать поддержку моста для новой цепи, это усилие может быть оправданным. Но для выпускающих токены, которые просто хотят добавить еще одну цепь к охвату своего токена, это может показаться излишне сложным и ресурсоемким.
6. Уникальные отличия
Каждый фреймворк имеет уникальные отличительные особенности, часто в виде специальных функций, инструментов или интеграций, которые отличают его от других. Эти дифференциаторы обычно привлекают разработчиков и протоколы, которые ищут конкретные функциональные возможности, простоту использования или просто большее распространение своего токена.
Отказ от ответственности: Этот раздел отражает информацию от @SlavaOnChain (Руководитель DevRel в LI.FI) и дискуссии с разработчиками, знакомыми с различными фреймворками. Возможности разработчика могут различаться в зависимости от предыстории и варианта использования.
1. Легкость интеграции
Относится к тому, насколько простым было развертывание токенов с помощью фреймворка, основанное на первом опыте без поддержки команды.
2. Документация
Оценивает, насколько хорошо руководства, примеры и ссылки фреймворка поддерживают разработчиков в понимании и использовании платформы.
3. Инструменты разработчика
Рассматривает набор библиотек, пакетов SDK и служебных программ, которые упрощают создание, тестирование и развертывание маркеров с помощью платформы.
Фреймворки токенов находятся на подъеме, и они могут в конечном итоге изменить все, что связано с тем, как движется стоимость в многоцепочечном мире. В настоящее время для передачи активов между цепочками часто требуются пулы ликвидности или решатели, но фреймворки токенов устраняют эти потребности. Вместо этого активы могут быть созданы непосредственно на желаемой цепочке через протоколы взаимодействия.
На самом деле, фреймворки токенов могут стать гробовым звоном для упакованных активов. Ликвидность больше не будет разделена между цепями. Вы сможете выпускать взаимозаменяемые активы на любой цепи и торговать ими между цепями по стоимости газа. Мы уже наблюдаем признаки этого сдвига. Circle запустил CCTP, чтобы обойти проблему упакованных токенов для USDC, и многие крупные команды и токены высокой стоимости уже принимают фреймворки токенов. Это признак ускорения событий.
Однако существуют обоснованные опасения относительно риска заражения от сторонних лиц -если протоколы взаимодействия не смогутОднако они могут повлиять на все проекты, построенные на них. Несмотря на эти риски, продолжается рост принятия.
Другая точка зрения: в абстрактном будущем фреймворки токенов больше не будут иметь значения, потому что решатели будут обменивать нативные токены на пользователей за кулисами. И хотя в этом есть доля правды — пользователям не нужно думать о токенах — это упускает из виду критический аспект. А как насчет самих решателей? Для них фреймворки токенов могут быть действительно полезны. Они решают проблемы с инвентаризацией и ребалансировкой, потому что им не требуется ликвидность для перемещения между цепочками. Вот почему решатели любят использовать такие фреймворки, как CCTP, для перемещения USDC — это дешево, эффективно и идеально подходит для кроссчейн-ребалансировки.
Как все это разовьется, до сих пор только догадки. Возможно, нам понадобятся только фреймворки токенов для небольшой группы периферийных цепей, или они станут стандартом для развертывания токенов в криптовалюте. Что мы знаем сегодня, так это то, что принятие интероперабельных фреймворков растет, и растет конкуренция. Проблема с этим ростом? Фрагментация. Конкурирующие фреймворки будут разбивать активы и ликвидность, и мы не увидим универсального решения. Инцентивы просто этого не позволят.
Выпуск токена раньше был простым: вы развертывали его на Ethereum, где была вся активность - пользователи, трейдеры, капитал и ликвидность. Сегодня ландшафт намного более сложный. Ликвидность разбросана по Bitcoin, Ethereum, L2s, Solana и другим цепочкам. Так где же вы должны выпустить свой токен? Нет ясного ответа.
Но что, если вам не нужно было выбирать только одну цепочку? Представьте токен, который работает везде, свободно перемещаясь по всей криптоэкономике.
Благодаряпротоколы взаимодействияТеперь, с помощью мостов (также известных как bridges), возможно выпускать токены с единой рыночной платформой, охватывающей несколько цепочек. Это создает глобальную ликвидность без границ, упрощает операции для выпускающих токены: большая ликвидность, большее принятие и более сильные сетевые эффекты — без головной боли от фрагментации. По сути, это похоже на наличие глобального банковского счета, который работает везде, интегрированный во все экосистемы DeFi.
В этой статье мы сравним ведущие фреймворки токенов, предлагаемые различными протоколами взаимодействия. Цель - оценить их уникальные особенности, преимущества и компромиссы, чтобы помочь командам выбрать лучшее решение для выпуска нативных многоканальных токенов.
Мы рассмотрим следующие фреймворки:
Давайте погрузимся.
Фреймворки токенов работают двумя основными способами, в зависимости от того, делаете ли вы существующий токен мультичейн или запускаете мультичейн токен с самого начала.
Когда токен выпускается нативно на нескольких цепях с первого дня, его предложение распределяется по этим цепям. При перемещении токенов между цепями они сжигаются на исходной цепи и чеканятся на целевой цепи, обеспечивая постоянное общее предложение.
Представьте это как систему бухгалтерского учета (как объясняли многие команды межсетевого взаимодействия). Вот пример: рассмотрим Токен X с общим количеством 1000 токенов, распределенных на основе спроса по пяти цепочкам:
Если пользователь переводит 50 токенов из Chain E в Chain A, то эти токены сжигаются на Chain E и выпускаются на Chain A. Обновленное распределение будет:
Этот процесс обеспечивает, что общее количество остается на уровне 1000 токенов, облегчая безупречные переводы между цепями без проскальзывания.
Для уже существующих токенов, которые изначально были развернуты на одной цепи, процесс немного отличается. Вся предложение существует на одной цепи, и при переводе на другую цепь часть предложения блокируется в смарт-контракте на исходной цепи, в то время как эквивалентное количество эмитируется на целевой цепи.
Этот метод похож на то, как работают обернутые токены. Токены, заблокированные на Chain A, могут быть затем созданы на Chain B в виде обернутой версии. Однако теперь эти токены также могут перемещаться с Chain B на Chain C с использованием метода сжигания-надбавки, без необходимости блокировки на нескольких цепях. Оригинальное количество остается на Chain A, что гарантирует, что переводы между цепями просто заключаются в проверке соответствия сожженных и созданных токенов.
Вот почему наличие токена, который можно торговать на объединенном рынке, охватывающем несколько цепочек, приносит пользу командам:
РассмотретьПротокол межцепочечного перевода Circle (CCTP). Запустив CCTP, Circle позволила USDC торговаться без проблем на поддерживаемых цепях, решая ключевые проблемы:
Уникальный набор функций Circle для USDC обусловлен их специальным мостом CCTP, роскошью, которой не многим проектам посчастливится обладать. Именно здесь в игру вступают фреймворки токенов, поддерживаемые протоколами взаимодействия. Эти фреймворки предоставляют решение, аналогичное тому, что предлагает CCTP для USDC, но для любого токена. Выпуская токен через эти фреймворки, проекты могут создать унифицированный рынок по множеству поддерживаемых цепей, обеспечивая простой перевод с использованием механизмов сжигания/блокировки и эмиссии.
Теперь, когда мы понимаем, как работают токеновые фреймворки и их выгоды, давайте сравним различные решения, доступные на рынке для команд, стремящихся выпустить свои токены.
Вот объяснение критических аспектов безопасности, описанных в таблице:
1. Механизм верификации
Механизм проверки является основой того, как осуществляется проверка передачи данных между цепями. Он относится к тому, как проверяются сообщения и к типу настройки в терминах механизмов проверки, которые каждая система предоставляет - будь то один вариант, модульная система с несколькими вариантами или гибкий дизайн, совместимый с любым мостом - что позволяет эмитентам токенов выбрать наиболее подходящее решение на основе их требований безопасности.
Хотя настраиваемые механизмы проверки предлагают преимущества, это настройки по умолчанию, которые остаются наиболее широко используемыми. Поэтому важно обращать внимание на безопасность схемы проверки по умолчанию. Рекомендуется, чтобы команды использовали дополнительные схемы проверки поверх стандартных, чтобы улучшить свою систему безопасности.
Когда речь идет о живости, полагаться на несколько схем проверки имеет как плюсы, так и минусы. С одной стороны, это повышает отказоустойчивость: если один провайдер перестает работать, другие могут обеспечить непрерывную работу, улучшая надежность системы. Однако это также увеличивает сложность системы. Каждая дополнительная схема представляет потенциальную точку отказа, повышая риск нарушения операций.
2. Гибкость при верификации
Подчеркивается гибкость каждой структуры в настройке ее механизма проверки - конкретно, может ли эмитент токена выбирать из различных вариантов или ограничен определенными настройками по умолчанию.
3.Заметные готовые схемы верификации
Готовые схемы представляют собой готовые к использованию механизмы проверки, которые эмитенты токенов могут использовать для проверки сообщений, упрощая развертывание. Фреймворк с широким выбором надежных готовых вариантов обычно является положительным знаком.
Хотя некоторые фреймворки предлагают больше схем проверки, чем другие, важно, чтобы оценить их на основе их спектра безопасности, который может варьироваться от одного валидатора до комплексных наборов валидаторов.
Например, OFTs предлагают варианты DVN, которые являются одними из основных проверяющих, наряду с более надежными выборами, такими как CCIP или Axelar, которые используют полные наборы проверяющих. Точно так же, Warp Token предлагает ISM, такие как Multisig ISM, которые включают проверяющих, управляемых сообществом Hyperlane, и в то же время есть варианты, такие как Aggregation ISM, которые позволяют командам объединять безопасность из нескольких ISM.
Кроме того, многие из этих схем проверки могут еще не быть широко принятыми или тщательно протестированными в реальных сценариях. Таким образом, команды должны тщательно оценить качество доступных схем проверки и выбрать ту, которая соответствует их желаемому уровню безопасности. Мы настоятельно рекомендуем использовать доступные варианты для создания безопасной и устойчивой среды для проверки токенов. В будущей исследовательской статье мы более подробно рассмотрим свойства безопасности различных схем проверки, предлагаемых каждой токен-структурой.
4. Схема верификации по умолчанию
Указывает, обеспечивает ли фреймворк механизм проверки по умолчанию. Это важно, потому что большинство команд обычно выбирают варианты по умолчанию из-за удобства. Если эмитент токена собирается выбрать вариант по умолчанию, крайне важно оценить его безопасность, а также рассмотреть возможности настройки, предлагаемые для улучшения безопасности настройки.
5. Участие в верификации приложения
Освещает, есть ли у команд возможность участвовать в процессе верификации, добавляя дополнительный уровень безопасности, или позволяет им контролировать свою безопасность. Это важно, потому что это позволяет командам улучшить безопасность, интегрируя собственную систему верификации наряду с существующими механизмами. Таким образом, если другие методы верификации не сработают, они могут полагаться на собственные средства защиты, чтобы предотвратить потенциальные проблемы.
Например, такие команды, как StarGate, Tapioca, BitGo, Cluster и Abracadabra, запускают свои собственные DVN на LayerZero, демонстрируя, как другие команды могут использовать доступные настройки.
Больше команд должны воспользоваться этим дополнительным слоем безопасности, несмотря на дополнительные усилия, которые требуются. При эффективной реализации этой функции она может быть решающей в предотвращении серьезных проблем во время критических сбоев.
6. Сопротивление цензуре
Определяет, может ли и каким образом быть цензурированы сообщения, что потенциально может привести к отключению приложений и вызвать проблемы с живучестью для команды. В большинстве случаев, даже если приложения подвергаются цензуре, они могут переключиться на другие механизмы верификации или релеи в рамках той же системы. Однако для этого требуется дополнительные усилия и может оказаться не практичным решением для краткосрочных проблем.
7.Открытость исходного кода
Открытые исходные коды позволяют разработчикам аудитировать безопасность фреймворка и общую настройку, обеспечивая прозрачность выполнения кода.
Эта таблица сравнивает структуры комиссий нескольких токен-фреймворков, фокусируясь на том, как каждый обрабатывает затраты на операции протокола, сообщения и любые дополнительные платежи. Важно отметить, что все фреймворки позволяют добавлять настраиваемые комиссии, специфичные для приложения, на уровне приложения. Более того, есть затраты, связанные с процессом проверки и передачи, включая комиссии, уплачиваемые релейщикам, трансиверам или подобным сущностям, во всех фреймворках.
В настоящее время большая часть сборов связана с проверкой и ретрансляцией сообщений. Как упоминалось ранее, все платформы маркеров предоставляют возможность использовать несколько механизмов для проверки сообщений. В то время как каждая дополнительная схема проверки повышает безопасность системы, она также увеличивает комиссии и затраты для пользователей.
1. Протокольные сборы
Это относится к комиссиям на уровне протокола, которые взимаются каждой платформой за выполнение трансферов или других операций.
Присутствие переключателя платы, управляемого DAO, означает, что эмитенты токенов могут быть вынуждены платить дополнительные сборы за протоколы взаимодействия, лежащие в основе фреймворков токенов (например, LayerZero для OFTs или Hyperlane для Warp Token). Это создает зависимость от управления DAO, так как любые изменения в переключателе платы непосредственно влияют на токены, выпущенные через эти фреймворки, делая их подверженными решениям DAO относительно структуры платы.
Эта таблица подробно описывает ключевые свойства смарт-контрактов каждой платформы, выделяя их различную степень гибкости, безопасности и настройки с акцентом на историю развертывания, проверки безопасности, предлагаемые вознаграждения и значимые настройки для гранулярного контроля.
Важно отметить, что все фреймворки позволяют приложениям устанавливать ограничения на скорость и черные списки, важные функции безопасности, которые, если используются эффективно, могут предотвратить значительные финансовые потериКроме того, каждая платформа предлагает гибкость развертывания смарт-контрактов в виде немутабельных или обновляемых в зависимости от конкретных потребностей приложения.
1. Развернуто с
Это поле показывает, когда были развернуты смарт-контракты каждого фреймворка. Это дает представление о том, как долго функционирует фреймворк.
2.Аудиты
Количество аудитов является важнейшей мерой безопасности. Аудит проверяет целостность смарт-контрактов фреймворка, выявляя уязвимости или проблемы, которые могут скомпрометировать систему.
3.Вознаграждения
Вознаграждения отражают финансовые стимулы, предлагаемые фреймворками для поощрения внешних исследователей безопасности находить и сообщать об уязвимостях.
4. Заметная особенность для точного контроля
Средства смарт-контрактов позволяют приложениям реализовывать различные настраиваемые функции безопасности в зависимости от их конкретных потребностей. В данной области рассматриваются несколько основных функций безопасности, которые каждый фреймворк предлагает для обеспечения безопасности.
Каждая рамка приносит уникальные возможности и имеет разный уровень вовлеченности разработчиков, протоколов и платформ в зависимости от их технической ориентации, интеграций и гарантий безопасности.
1. Основные участники
Этот раздел выделяет различные команды, активно участвующие в создании и поддержке каждой структуры. Разнообразный набор участников, помимо первоначальной команды разработчиков, является положительным индикатором нескольких факторов: (1) более широкий спрос на структуру и (2) доступность и простота использования структуры, независимо от разрешения или через общее сотрудничество.
2.Принятие
Внедрение отражает уровень использования и популярности каждой платформы, измеряемый количеством развернутых токенов и общей обеспеченной стоимостью. Он дает представление о том, насколько широко платформа была принята разработчиками и протоколами, а также о ее надежности в обеспечении безопасности активов.
3.Известные команды
Этот раздел подчеркивает лучшие команды и протоколы, которые приняли каждую рамку, отражая их доверие отрасли и общую привлекательность.
4.Покрытие виртуальных машин
Охват ВМ относится к количеству поддерживаемых виртуальных машин каждым фреймворком. Большее количество ВМ обеспечивает большую гибкость и совместимость с различными средами блокчейна. Это дает приложениям и эмитентам токенов больше возможностей в терминах разнообразных сообществ, в которые они могут привлечь.
5. Цепи, развернутые на
В этом поле отражается количество цепочек, на которых развернут каждый фреймворк, т. е. количество цепочек, которые может поддерживать каждое приложение или издатель токенов, если он решит использовать определенную платформу. Это напрямую связано с количеством рынков и экосистем DeFi, к которым могут подключиться приложения. Более высокий уровень развертывания цепочки означает более широкий доступ к ликвидности.
Кроме того, возможность без разрешения расширять фреймворк на разных цепях имеет большой потенциал, но может быть вызовом, если разработчикам требуется строить и поддерживать критическую инфраструктуру самостоятельно. Для некоторых, например, для команд, стремящихся создать поддержку моста для новой цепи, это усилие может быть оправданным. Но для выпускающих токены, которые просто хотят добавить еще одну цепь к охвату своего токена, это может показаться излишне сложным и ресурсоемким.
6. Уникальные отличия
Каждый фреймворк имеет уникальные отличительные особенности, часто в виде специальных функций, инструментов или интеграций, которые отличают его от других. Эти дифференциаторы обычно привлекают разработчиков и протоколы, которые ищут конкретные функциональные возможности, простоту использования или просто большее распространение своего токена.
Отказ от ответственности: Этот раздел отражает информацию от @SlavaOnChain (Руководитель DevRel в LI.FI) и дискуссии с разработчиками, знакомыми с различными фреймворками. Возможности разработчика могут различаться в зависимости от предыстории и варианта использования.
1. Легкость интеграции
Относится к тому, насколько простым было развертывание токенов с помощью фреймворка, основанное на первом опыте без поддержки команды.
2. Документация
Оценивает, насколько хорошо руководства, примеры и ссылки фреймворка поддерживают разработчиков в понимании и использовании платформы.
3. Инструменты разработчика
Рассматривает набор библиотек, пакетов SDK и служебных программ, которые упрощают создание, тестирование и развертывание маркеров с помощью платформы.
Фреймворки токенов находятся на подъеме, и они могут в конечном итоге изменить все, что связано с тем, как движется стоимость в многоцепочечном мире. В настоящее время для передачи активов между цепочками часто требуются пулы ликвидности или решатели, но фреймворки токенов устраняют эти потребности. Вместо этого активы могут быть созданы непосредственно на желаемой цепочке через протоколы взаимодействия.
На самом деле, фреймворки токенов могут стать гробовым звоном для упакованных активов. Ликвидность больше не будет разделена между цепями. Вы сможете выпускать взаимозаменяемые активы на любой цепи и торговать ими между цепями по стоимости газа. Мы уже наблюдаем признаки этого сдвига. Circle запустил CCTP, чтобы обойти проблему упакованных токенов для USDC, и многие крупные команды и токены высокой стоимости уже принимают фреймворки токенов. Это признак ускорения событий.
Однако существуют обоснованные опасения относительно риска заражения от сторонних лиц -если протоколы взаимодействия не смогутОднако они могут повлиять на все проекты, построенные на них. Несмотря на эти риски, продолжается рост принятия.
Другая точка зрения: в абстрактном будущем фреймворки токенов больше не будут иметь значения, потому что решатели будут обменивать нативные токены на пользователей за кулисами. И хотя в этом есть доля правды — пользователям не нужно думать о токенах — это упускает из виду критический аспект. А как насчет самих решателей? Для них фреймворки токенов могут быть действительно полезны. Они решают проблемы с инвентаризацией и ребалансировкой, потому что им не требуется ликвидность для перемещения между цепочками. Вот почему решатели любят использовать такие фреймворки, как CCTP, для перемещения USDC — это дешево, эффективно и идеально подходит для кроссчейн-ребалансировки.
Как все это разовьется, до сих пор только догадки. Возможно, нам понадобятся только фреймворки токенов для небольшой группы периферийных цепей, или они станут стандартом для развертывания токенов в криптовалюте. Что мы знаем сегодня, так это то, что принятие интероперабельных фреймворков растет, и растет конкуренция. Проблема с этим ростом? Фрагментация. Конкурирующие фреймворки будут разбивать активы и ликвидность, и мы не увидим универсального решения. Инцентивы просто этого не позволят.