Chainlink выпустила версию 2.0 своего протокола межцепочечной интероперабельности (CCIP), представив Cross-Chain Verifiers, новые функции токен-пулов и настраиваемые параметры финальности, согласно примечаниям к релизу проекта. Дополнительный обзор безопасности объясняет более широкую архитектуру, в которую вписываются эти функции. CCIP, передающий сообщения и токены между блокчейнами, которые не могут нативно считывать состояние друг друга, развивает работу проекта, наиболее известного своей оракул-инфраструктурой в децентрализованных финансах.

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

Что изменилось

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

Межцепочечные переводы опираются на решение, которому нужно доверять

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

Сбой в этом процессе принятия решений может привести к серьёзным проблемам: действительный перевод пользователя может быть задержан, а недействительное сообщение — привести к выпуску токенов, когда этого делать не следовало.

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

Эмитенты могут добавлять собственные правила верификации

CCIP 2.0 представляет Cross-Chain Verifiers (CCV) — дополнительные компоненты верификации, которые могут использоваться наряду с существующим процессом безопасности CCIP. Примечательно, что проекту не требуется одобрение Chainlink для разработки или использования дополнительного верификатора. Такая открытость даёт эмитентам больше свободы в построении маршрута под собственные требования, но при этом перекладывает на них больше ответственности за оценку выбранного верификатора.

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

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

Более быстрое исполнение — опционально

Обновление также включает настраиваемые параметры финальности, в том числе опциональную функцию Faster Than Finality. Блокчейны достигают финальности по-разному. Некоторые транзакции могут выглядеть подтверждёнными до того, как сеть достигнет точки, после которой их реорганизация становится крайне маловероятной. Более долгое ожидание может повысить уверенность, но также замедлить межцепочечный перевод.

CCIP 2.0 даёт участвующим частям маршрута возможность использовать более раннюю точку подтверждения. В примечаниях к релизу чётко указано, что эта настройка должна поддерживаться всеми соответствующими компонентами: отправителем, пулом, верификатором, исполнителем и получателем. Более быстрый маршрут, таким образом, может опираться на иные операционные допущения, чем тот, что ждёт, пока транзакция в исходной цепочке достигнет обычного порога финальности. Если эти компоненты настроены несогласованно, примечания предупреждают, что сообщение и его токен-содержимое могут «зависнуть».

Дополнительные проверки помогают, только если у них нет общей уязвимости

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

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

CCIP 2.0 предоставляет каркас для таких проверок. Но эмитенту по-прежнему нужно решать, каковы правила, как работает его код и кто может позже их.

Почему контроль на уровне эмитента важен за пределами DeFi

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

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

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

Что пользователям следует проверить перед использованием межцепочечного маршрута

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

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

Эти вопросы не означают, что каждый пользовательский маршрут небезопасен. Они помогают объяснить, почему слово «мостовой» может описывать очень разные системы.

Провайдер моста — лишь часть системы безопасности

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

Значимость обновления станет видна в том, как маршруты будут фактически настраиваться — какие эмитенты добавляют пользовательские верификаторы и сколько включают ускоренную финальность, — поскольку эти решения принимаются на уровне каждого токена, а не Chainlink для протокола в целом.

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

Эта статья предоставлена исключительно в информационных целях и не является финансовой или инвестиционной рекомендацией. Межцепочечные переводы связаны с рисками смарт-контрактов, операционными рисками и рисками ликвидности.

Первоначально опубликовано Coindoo.