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

ICS-02 определяет требования к построению легкого клиента, включая то, как IBC управляет данными легкого клиента. Клиенты необходимы для работы IBC, которые представляют собой произвольные алгоритмы верификации для доказательства информации on-chain, которая обычно закодирована в формате IBC, из одного места в другое.

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

Проверка доказательств консенсуса

Примечание о алгоритмах консенсуса

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

Алгоритмы консенсуса обычно различаются своими правилами и тем, что они приоритизируют. Однако гетерогенность двух разных алгоритмов консенсуса может затруднить коммуникацию цепочек через IBC. Например, цепочки Cosmos используют алгоритм консенсуса Tendermint, у которого есть однократная завершенность слота, иначе известная как быстрая завершенность. С другой стороны, консенсус Ethereum не имеет однократной завершенности слота и, следовательно, замедленная завершенность, потому что он ценит активность выше безопасности, в то время как IBC наиболее совместим с алгоритмами консенсуса, которые ценят безопасность. Из-за этого различия в том, когда блоки считаются 'окончательными', возникают трудности в том, как две цепочки могут отправлять и проверять блоки между собой.

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

Легкие клиенты: Состояние машины

“Стейт-машина” может быть целым блокчейном (реплицированным реестром) или отдельным процессом, который подписывает операции с помощью частного ключа (минимальное согласие), таким как ноутбук или мобильный телефон.

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

тип клиента по сравнению с экземпляром клиента

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

Легкие клиенты: Одиночные машины

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

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

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

Проверка за пределами доказательств консенсуса

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

Оптимистичный IBC: Клиенты могут оптимистично принимать входящие заголовки через внеланцетный ретранслятор, который выполняет программу на некоторой виртуальной машине. В этом сценарии существует окно вызова, в котором может быть представлено доказательство мошенничества. Положительным моментом является то, что Оптимистичный IBC снижает стоимость всей системы. Недостатки включают в себя длительный период вызова мошенничества и в зависимости от сети могут быть высокие базовые затраты на передачу активов - для Ethereum это 21 000 единиц газа.

ZK-IBC: Вычисления клиентов происходят вне цепи и проверяются в цепи с использованием ZKPs. Здесь нет минимальной задержки, и стоимость ниже, чем при наивной проверке. Однако ZK-проверка может быть дорогой в цепи, и здесь нет максимальной задержки, что означает, что пользователю может потребоваться некоторое время для подтверждения. Также могут возникнуть проблемы несовместимости, если схема подписи не является дружественной к SNARK.

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

Оптимистичная ZK: Исходная цепочка оптимистично принимает заголовки on-chain (возможно, для обеспечения безопасности установлен механизм стейкинга). Затем ZKP используются в качестве доказательств обмана в случае неправомерного поведения или доказательств правильности для динамического сокращения задержки соединения.

Безопасность и неправомерное поведение

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

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

Построение с легкими клиентами

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

Экосистема IBC активно работает над тем, чтобы сделать IBC простым решением для застройщиков. Некоторые из обсужденных нами инициатив включают рефакторинг клиента и виртуальных клиентов. Например, если цепочке нужно обновить консенсус, она должна обновить каждую цепочку, к которой подключена, а также их легкие клиенты, чтобы оставаться подключенными, что является дорогостоящим процессом управления on-chain. Клиенты WASM разрабатываются для того, чтобы упростить разработку и обновление легких клиентов путем развертывания клиентских экземпляров в качестве смарт-контрактов. Это облегчает обновление легких клиентов без остановки цепочки и создание клиентов на языках, таких как Rust, который является популярным выбором среди нескольких state-машины.

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

Эта статья была спонсирована Polymer для поддержки образования сообщества в области IBC и по-настоящему децентрализованной совместимости.

Лаборатория Polymer, состоящая из опытных инженеров распределенных систем и инфраструктуры, крипто-пионеров и опытных бизнес-операторов, находится на передовых позициях в продвижении интероперабельности Ethereum с IBC. С техническими ценностями, основанными на TCP/IP, миссия Polymer заключается в установлении следующего поколения интернета, обеспечивая, чтобы уровень интероперабельности децентрализованной сети был нейтральным, открытым, безразрешительным и однородным по всей экосистеме. Будучи создателями Хаба Интероперабельности Ethereum, первого уровня 2, сосредоточенного на обеспечении интероперабельности IBC, Polymer устанавливает новый стандарт в технологии блокчейн.

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

1. Эта статья перепечатана с [ eshitanandini]. All copyrights belong to the original author [ESHITA]. Если есть возражения против этого перепечатывания, пожалуйста, свяжитесь сGate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.