Подробное объяснение технологии межсетевого взаимодействия Adaptive IBC для гетерогенных цепочек

Автор：MiX

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

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

17 декабря 2023 года второй гетерогенный IBC, разработанный командой Octopus Network ------ NEAR-IBC, официально запущен. Процесс от начала разработки до третьей стороны аудита и официального запуска занял менее года,и заслуга этого принадлежит команде Octopus Network, предложившей технологическую дорожную карту Adaptive IBC для межцепочечного взаимодействия: через инновации в архитектуре технологии IBC были устранены недостатки протокола IBC в межцепочечном взаимодействии гетерогенных цепей, что значительно расширило адаптивность протокола IBC:

1. Различные блокчейны с разными механизмами консенсуса могут использовать технологическую дорожную карту Adaptive IBC, такие как Ethereum, NEAR Protocol и Polkadot и т.д.
2. Сильно снижены затраты на межцепочечное взаимодействие, что решает главную проблему протокола IBC при расширении на гетерогенные цепи.
3. Может адаптироваться к прогрессу различных технологий верификации, например, как только технологии ZK станут зрелыми, можно будет легко обновить прокси-клиент до ZK-валидатора.

Подробности о вехах эволюции технологии Adaptive IBC см. в приложении в конце.

|Основные принципы и преимущества протокола IBC

Протокол IBC (Inter-Blockchain Communication), предложенный командой Cosmos, является полностью открытым и универсальным протоколом для межцепочечного взаимодействия блокчейнов.

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

1. Многоуровневая архитектура:

IBC разбивает межцепочечное взаимодействие на «приложенческий уровень/Application» и «коммуникационный уровень/Channel», его простота и гибкость можно сравнить с протоколом TCP/IP для блокчейнов, как заявлено на официальном сайте IBC: IBC черпает вдохновение из основного протокола интернета TCP/IP.
Рисунок 1: IBC — это протокол TCP/IP для блокчейнов

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

Рисунок 2: Архитектура технологии IBC

Цепь A имеет легкий клиент, представляющий цепь B, цепь B также имеет легкий клиент цепи A, легкий клиент отслеживает консенсусные данные другой цепи, проверяя заголовки блоков и доказательства Merkle, тем самым проверяя законность межцепочечного взаимодействия.

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

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

2. Открытость технологии

Любой может использовать протокол IBC и вносить в него свой вклад, в протоколе IBC нет комиссий или скрытых сборов.

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

Рисунок 3: Данные межцепочечного взаимодействия IBC
Источник данных: mapofzones.com

На 15 января 2024 года протокол IBC был запущен на 107 блокчейнах, за последние 30 дней общий объем транзакций составил более 4 миллиардов долларов, безопасное межцепочечное взаимодействие произошло более 8 миллионов раз. Конечно, в настоящее время подавляющее большинство межцепочечных взаимодействий происходит между блокчейнами Cosmos SDK.

В то же время многие команды работают над расширением протокола IBC на другие экосистемы, надеясь реализовать межцепочечное взаимодействие с гетерогенными цепями через IBC, включая Ethereum, Polkadot, NEAR Protocol, Avalanche, Solana и Celestia rollups.

|Сложности расширения IBC на гетерогенные цепи

Архитектура протокола IBC основана на легком клиенте, поэтому не требует привлечения сторонних верификационных услуг, обеспечивая бездоверительное/Trustless межцепочечное взаимодействие. Особенно между цепями Cosmos достигнут отличный баланс безопасности, затрат и скорости, но при расширении на гетерогенные цепи многие команды сталкиваются с заметным замедлением прогресса.

IBC и механизм консенсуса Tendermint были предложены командой Cosmos, поэтому Cosmos SDK с самого начала был очень хорошо поддержан легким клиентом.

Чтобы реализовать протокол IBC между цепями Cosmos и не-Cosmos, необходимо реализовать легкий клиент не-Cosmos на цепи Cosmos и легкий клиент Tendermint на не-Cosmos. Из-за различий в механизмах консенсуса гетерогенных цепей в процессе реализации требуется провести множество работ по совместимости и ввести соответствующие технические риски.

Это создает множество технических вызовов для реализации IBC на гетерогенных цепях:

Во-первых, верификация межцепочечных сообщений на гетерогенных цепях требует высоких затрат и может столкнуться с ограничениями вычислительных ресурсов/gas Limitation:

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

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

Во-вторых, механизмы управления активами на цепи различаются/On-chain Asset Management

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

В-третьих, ограничения песочницы виртуальной машины/Sandbox Limitation

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

В-четвертых, правила хранения данных на цепи/On Chain Storage различаются

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

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

|Принципы и преимущества Adaptive IBC

Ключевым моментом технологической дорожной карты Adaptive IBC для межцепочечного взаимодействия является инновация в многоуровневой архитектуре протокола IBC, которая дополнительно выделяет «уровень верификации», то есть вводит «верификационный прокси/Verification Proxy», развернутый на прокси-цепи ( ICP ), таким образом, обе стороны межцепочечного взаимодействия должны проверять только доказательство, созданное «верификационным прокси», без необходимости напрямую проверять заголовки блоков и все подписи другой цепи.

Рисунок 4: Архитектура NEAR-IBC на основе Adaptive IBC

В качестве примера NEAR-IBC: на прокси-цепи/Proxy Chain развернуты верификационные прокси для Cosmos и NEAR, которые поддерживают консенсус соответствующих цепей, затем на обеих сторонах межцепочечного взаимодействия развертывается прокси-клиент консенсуса другой стороны, заменяющий оригинальный легкий клиент IBC.

Например, когда Cosmos передает сообщение в NEAR, верификационный прокси Cosmos на прокси-цепи/Tendermint Verification Proxy проверяет межцепочечное сообщение, подписывает его и генерирует доказательство, затем прокси-клиент Cosmos на стороне NEAR/Tendermint Proxy Client должен проверить это доказательство, чтобы завершить верификацию межцепочечного взаимодействия.

Рисунок 5: Безопасность и расширяемость межцепочечной технологии

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

Поскольку Adaptive IBC предлагает развертывать верификационный прокси на публичной цепи, например, NEAR-IBC развернут на публичной цепи ICP, этот подход обеспечивает как децентрализацию и возможность открытой верификации, так и безопасность верификационного прокси и всей межцепочечной системы. Рисунок 6: Два взгляда на безопасность межцепочечного взаимодействия

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

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

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

2. Совместимость с различными механизмами консенсуса: архитектура верификационного прокси не имеет зависимостей между сторонами межцепочечного взаимодействия и может быть использована различными блокчейнами с разными механизмами консенсуса, такими как Ethereum, NEAR Protocol и Polkadot и т.д., что делает ее настоящим решением для межцепочечного взаимодействия гетерогенных цепей.

3. Адаптация к развитию технологий верификации: Adaptive IBC выделяет «уровень верификации» из коммуникационного уровня и развивает решение с верификационным прокси. Одно из преимуществ многоуровневой архитектуры заключается в снижении взаимозависимости между системами, поэтому Adaptive IBC может адаптироваться к прогрессу различных технологий верификации.

• Если Cosmos сможет поддерживать агрегированные подписи или NEAR поддержит предварительную компиляцию для подписей ED25519, это значительно снизит затраты на прямую верификацию на NEAR Protocol, и прокси-клиент можно будет снова обновить до действительно работающего легкого клиента.

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

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

|Приложение

1. В 2020 году предшественник Octopus Network команда Cdot получила грант от Interchain Foundation для разработки Substrate-IBC, то есть ICS10. 2. В 2022 году Substrate-IBC был завершен и стал первой в мире командой, реализовавшей IBC на блокчейне, не относящемся к Cosmos. 3. В октябре 2022 года была предложена технологическая дорожная карта Adaptive IBC для межцепочечного взаимодействия и начата разработка NEAR-IBC. 4. В октябре 2023 года разработка NEAR-IBC была завершена, и аудит был проведен третьей стороной, Blocksec. 5. В декабре 2023 года блокчейн Cosmos SDK Ottochain использовал $NEAR Rstaking для совместного обеспечения безопасности, официально запустив работу. NEAR-IBC как ключевая технология подтвердил жизнеспособность и научность технологической дорожной карты Adaptive IBC для межцепочечного взаимодействия. 6. В первом квартале 2024 года протокол конфиденциальности Secret Network будет использовать NEAR-IBC на основе Adaptive IBC для межцепочечного взаимодействия с NEAR Protocol. Затем Octopus Network продолжит исследовать технологии межцепочечного взаимодействия сообщений, позволяя смарт-контрактам NEAR напрямую использовать возможности конфиденциальных вычислений Secret Network. 7. В 2024 году планируется начать разработку ETH-IBC на основе Adaptive IBC, с целью стать первой командой, предлагающей доступный опыт межцепочечного взаимодействия IBC между Ethereum и другими блокчейнами, поддерживающими IBC.

|Ссылки

《Обзор протокола IBC 2023 года》Mary McGilvray
《Adaptive IBC: разрушитель межоперабельности гетерогенных цепей》Луи
《Введение в NEAR-IBC｜Как использовать смарт-контракты для реализации протокола IBC》Ян Чжэнь
《NEAR станет зоной Cosmos СКОРО》Луи