Введение

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

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

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

Каждое AMP-решение должно обладать двумя важнейшими возможностями:

• Верификация: Возможность проверить достоверность сообщения из цепочки источника на цепочке назначения.
• Живучесть (Liveness): Способность передавать информацию от источника к месту назначения

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

Мы разделяем общий ландшафт совместимости на основе механизма доверия и архитектуры интеграции.

Механизм доверия:

1. Доверительный код/математика: Для этих решений существует доказательство на цепочке, которое может проверить каждый. Эти решения, как правило, полагаются на легкий клиент для подтверждения консенсуса исходной цепочки с целевой цепочкой или проверки достоверности перехода состояния исходной цепочки с целевой цепочкой. Верификация с помощью легких клиентов может стать намного эффективнее благодаря доказательствам Zero Knowledge, позволяющим сжимать произвольно длинные вычисления в автономном режиме и обеспечивать простую проверку на цепи для доказательства вычислений.
2. Теория доверительных игр: Существует дополнительное предположение о доверии, когда пользователю/приложению приходится доверять третьей стороне или сети третьих сторон в отношении подлинности транзакций. Эти механизмы можно сделать более безопасными с помощью сетей без разрешений в сочетании с теоретико-игровыми методами, такими как экономические стимулы и оптимистическая безопасность.
3. Доверяйте людям: Эти решения полагаются на честность большинства проверяющих или независимость организаций, передающих различную информацию. Они требуют доверия к третьим лицам в дополнение к доверию к консенсусу двух взаимодействующих цепочек. Единственное, что здесь поставлено на карту, - это репутация участвующих организаций. Если достаточное количество участвующих субъектов согласны с тем, что транзакция действительна, то она считается действительной.

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

Интеграционная архитектура:

1. Модель "точка-точка": Между каждым источником и каждым пунктом назначения должен быть установлен выделенный канал связи.
2. Модель "Концентратор и спицы": Необходимо установить канал связи с центральным узлом, который обеспечит связь со всеми остальными блокчейнами, подключенными к этому узлу.

Модель Point to Point относительно сложно масштабировать, поскольку для каждого подключенного блокчейна требуется парный канал связи. Разработка таких каналов может быть сложной задачей для блокчейнов с различными консенсусами и структурами. Однако парные мосты обеспечивают большую гибкость в настройке конфигураций, если это необходимо. Возможен и гибридный подход, например, использование протокола межблокчейновой связи (IBC) с многоходовой маршрутизацией через концентратор, что устраняет необходимость в прямой парной связи, но вновь усложняет безопасность, задержку и стоимость.

Доверительный код/математика

Как легкие клиенты проверяют консенсус исходной цепочки с целевой цепочкой?

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

1. Безопасность:

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

1. Реализация: Зависит от наличия поддержки криптографических примитивов, необходимых для проверки

• Если подключается один и тот же тип цепочки (один и тот же фреймворк приложения и алгоритм консенсуса), то реализация легкого клиента на обеих сторонах будет одинаковой. Пример: IBC для всех цепочек на базе Cosmos SDK.
• Если соединяются два разных типа цепочек (разные прикладные фреймворки или типы консенсуса), то реализация легкого клиента будет отличаться. Пример: Composable finance работает над тем, чтобы цепочки Cosmos SDK можно было подключать через IBC к Substrate (фреймворк приложений экосистемы Polkadot). Для этого требуется легкий клиент Tendermint в цепочке субстратов и так называемый "beefy" легкий клиент, добавленный в цепочку Cosmos SDK.

1. Задачи:

• Ресурсоемкость: Запускать парные легкие клиенты на всех цепочках очень дорого, поскольку запись в блокчейн стоит дорого, а на цепочках с динамическими наборами валидаторов, таких как Ethereum, это нецелесообразно.
• Расширяемость: Для каждой комбинации цепочек требуется легкая реализация клиента. Учитывая, что реализация зависит от архитектуры цепочки, трудно масштабировать и соединять различные экосистемы.
• Эксплуатация кода: Ошибки в коде могут привести к уязвимостям. Эксплойт цепочки BNB в октябре 2022 года обнаружил критическую уязвимость в системе безопасности, затрагивающую все цепочки с поддержкой IBC.

Как ZK-доказательства проверяют достоверность перехода состояния исходной цепочки в цепочку назначения?

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

1. Безопасность: безопасность zk-SNARK зависит от эллиптических кривых, а zk-STARK - от хэш-функций. zk-SNARK могут требовать или не требовать доверенной установки. Доверенная настройка нужна только на начальном этапе, который относится к событию создания ключей, используемых для создания доказательств, необходимых для проверки этих доказательств. Если секреты в событии установки не уничтожены, они могут быть использованы для подделки транзакций путем ложных проверок. После установки доверия не возникает никаких предположений о доверии.
2. Реализация: Сегодня существуют различные схемы доказательства ZK, такие как SNARK, STARK, VPD, SNARG, и в настоящее время SNARK является наиболее широко распространенной. Рекурсивные ZK-доказательства - еще одна новейшая разработка, позволяющая разделить всю работу по доказательству между несколькими компьютерами, а не только одним. Чтобы генерировать доказательства достоверности, необходимо реализовать следующие основные примитивы:

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

1. Задачи:

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

1. Примеры: Полимер ZK-IBC от Polymer Labs, Succinct Labs. Компания Polymer работает над созданием IBC с поддержкой многоходовых соединений, чтобы увеличить возможности подключения, сократив при этом количество необходимых парных соединений.

Теория доверительных игр

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

1. Экономическая безопасность: Несколько внешних участников (например, валидаторы) приходят к консенсусу относительно обновленного состояния цепочки источников. Это похоже на мультисиг, но для того, чтобы стать валидатором, участники должны поставить на кон определенное количество токенов, которые могут быть уничтожены в случае обнаружения вредоносной деятельности. В системах без разрешения любой может накапливать ставки и становиться валидатором. Существуют также вознаграждения в виде блоков, которые выступают в качестве экономических стимулов, когда участвующие валидаторы следуют протоколу. Таким образом, участники экономически заинтересованы в том, чтобы быть честными. Однако если сумма, которую можно украсть, значительно превышает сумму ставки, то участники могут попытаться сговориться, чтобы украсть средства. Примеры: Axelar, Celer IM
2. Оптимистическая безопасность: Оптимистичные решения в области безопасности опираются на предположение о доверии меньшинства, которое предполагает, что только меньшинство участников блокчейна живы, честны и следуют правилам протокола. Решение может потребовать, чтобы гарантом был только один честный участник. Наиболее распространенным примером является оптимальное решение, в котором каждый может представить доказательства мошенничества. Здесь также есть экономический стимул, но даже для честного наблюдателя практически возможно пропустить мошенническую транзакцию. Оптимистичные роллы также используют этот подход. Примеры: Nomad, ChainLink CCIP

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

Ключевыми особенностями этих механизмов являются:

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

• Средняя цепочка с собственными валидаторами: Группа внешних валидаторов следит за исходной цепочкой, достигает консенсуса в отношении действительности транзакции при обнаружении вызова и обеспечивает аттестацию цепочки назначения, если консенсус достигнут. Валидаторы обычно должны поставить на кон определенное количество токенов, которые могут быть уничтожены в случае обнаружения вредоносной деятельности. Примеры: Axelar Network, Celer IM
• С помощью агентов вне цепи: Агенты вне цепочки могут быть использованы для реализации оптимистичного решения типа roll-up, когда в течение заранее определенного времени агентам вне цепочки будет позволено представить доказательства мошенничества и отменить транзакцию. Пример: Nomad полагается на независимых агентов вне цепи для передачи заголовка и криптографического доказательства. ChainLink CCIP будет использовать свою существующую сеть оракулов для мониторинга и подтверждения межцепочечных транзакций.

1. Задачи:

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

1. Преимущества:

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

Доверяйте людям

1. Предположения о честности большинства: Эти решения полагаются на реализацию мультисигмы, когда несколько организаций проверяют и подписывают транзакции. Как только минимальный порог достигнут, транзакция считается действительной. Здесь предполагается, что большинство субъектов честны, и если большинство этих субъектов подписывает определенную транзакцию, то она действительна. Единственное, что здесь поставлено на карту, - это репутация участвующих организаций. Примеры: Multichain (Anycall V6), Wormhole. Эксплойты, связанные с ошибками в смарт-контрактах, все еще возможны, о чем свидетельствует взлом Wormhole в начале 2022 года.
2. Независимость: Эти решения разделяют весь процесс передачи сообщений на две части и полагаются на разные независимые организации для управления этими двумя процессами. Здесь предполагается, что эти две организации независимы друг от друга и не вступают в сговор. Пример: LayerZero. Заголовки блоков передаются по запросу децентрализованными оракулами, а доказательства транзакций отправляются через ретрансляторы. Если доказательство совпадает с заголовками, транзакция считается действительной. В то время как подгонка доказательств опирается на код/математику, участники должны доверять сущностям, чтобы оставаться независимыми. Приложения, созданные на основе LayerZero, имеют возможность выбрать свой Oracle и Relayer (или разместить свой собственный Oracle/Relayer), тем самым ограничивая риск сговора отдельных оракулов/релейщиков. Конечные пользователи должны верить, что либо LayerZero, либо третья сторона, либо само приложение запускает оракул и ретранслятор независимо и без злого умысла.

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

За пределами предположений о доверии и будущее интероперабельности

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

• Целостность кода: Ряд взломов в недавнем прошлом использовал ошибки в коде, что требует надежного аудита, хорошо спланированных вознаграждений за ошибки и нескольких клиентских реализаций. Если все валидаторы (в экономической/оптимистической/репутационной безопасности) запускают один и тот же клиент (программное обеспечение для проверки), это увеличивает зависимость от одной кодовой базы и уменьшает разнообразие клиентов. Например, Ethereum опирается на множество клиентов исполнения, таких как geth, nethermind, erigon, besu, akula. Несколько реализаций на разных языках, скорее всего, увеличат разнообразие, при этом ни один клиент не будет доминировать в сети, тем самым устраняя потенциальную единую точку отказа. Наличие нескольких клиентов также может помочь в обеспечении оперативности, если меньшинство валидаторов/подписывающих устройств/легких клиентов выйдут из строя из-за эксплойтов/багов в одной конкретной реализации.
• Настройка и возможность обновления: Пользователи и разработчики должны знать, могут ли валидаторы/наблюдатели присоединиться к сети без разрешения, иначе доверие будет скрыто выбором разрешенных сущностей. Модернизация смарт-контрактов также может привести к появлению ошибок, которые могут стать причиной эксплойтов или даже потенциально изменить предположения о доверии. Для снижения этих рисков можно применять различные решения. Например, в текущем варианте шлюзы Axelar можно обновлять при условии одобрения со стороны автономного комитета (порог 4/8), однако в ближайшем будущем Axelar планирует потребовать, чтобы все валидаторы коллективно утверждали любые обновления шлюзов. Основные контракты Wormhole могут обновляться и управляются через систему управления цепочкой Wormhole. LayerZero полагается на неизменяемые смарт-контракты и неизменяемые библиотеки, чтобы избежать каких-либо обновлений, однако он может выпустить новую библиотеку, и dapp'ы с настройками по умолчанию получат обновленную версию, а dapp'ы, у которых версия установлена вручную, должны будут установить ее на новую.
• MEV: Различные блокчейны не синхронизированы через общие часы и имеют разное время до завершения работы. В результате, порядок и время выполнения в цепочке назначения могут различаться по цепочкам. MEV в мире кросс-цепочек сложно четко определить. Это вводит компромисс между быстротой и порядком выполнения. Упорядоченный канал обеспечит упорядоченную доставку сообщений, но канал закроется, если одно сообщение не дойдет. Другое приложение может предпочесть сценарий, при котором заказ не требуется, но на доставку других сообщений это не влияет.

Тенденции и перспективы на будущее:

• Настраиваемая и дополняемая безопасность: Чтобы лучше обслуживать разнообразные сценарии использования, решения AMP стимулируют разработчиков предлагать больше гибкости. Компания Axelar представила подход, позволяющий модернизировать передачу сообщений и верификацию без каких-либо изменений в логике прикладного уровня. В HyperLane V2 представлены модули, позволяющие разработчикам выбирать из нескольких вариантов, таких как экономическая безопасность, оптимистическая безопасность, динамическая безопасность и гибридная безопасность. CelerIM предлагает дополнительную оптимистическую безопасность наряду с экономической. Многие решения ждут заранее определенного минимального количества подтверждений блоков в цепочке источника, прежде чем передавать сообщение. LayerZero позволяет разработчикам обновлять эти параметры. Мы ожидаем, что некоторые решения AMP будут и дальше предлагать большую гибкость, но эти варианты дизайна заслуживают некоторого обсуждения. Должны ли приложения иметь возможность настраивать свою безопасность, в какой степени, и что произойдет, если в приложениях будет использована некачественная архитектура? Осведомленность пользователей об основных концепциях безопасности может приобретать все большее значение. В конечном итоге, мы предвидим объединение и абстрагирование решений AMP, возможно, в какой-то форме комбинированной или "аддитивной" безопасности.
• Рост и развитие механизмов "Trust code/math": В идеальном случае все межцепочечные сообщения будут минимизированы за счет использования доказательств нулевого знания (ZK) для проверки сообщений и состояний. Мы уже наблюдаем этот сдвиг с появлением таких проектов, как Polymer Labs и Succinct Labs. Компания Multichain также недавно опубликовала технический документ zkRouter для обеспечения совместимости с помощью ZK-доказательств. С помощью недавно анонсированной виртуальной машины Axelar Virtual Machine разработчики могут использовать усилитель Interchain Amplifier для безразрешительной установки новых соединений с сетью Axelar. Например, как только будут разработаны надежные лайт-клиенты & ZK proofs для состояния Ethereum, разработчик сможет легко интегрировать их в сеть Axelar, чтобы заменить или улучшить существующее соединение. LayerZero в своей документации говорит о возможности добавления новых оптимизированных библиотек обмена сообщениями в будущем. Новые проекты, такие как Lagrange, исследуют объединение доказательств из нескольких цепочек источников, а Herodotus делает доказательство хранения возможным с помощью ZK-доказательств. Однако этот переход потребует времени, поскольку такой подход трудно масштабировать среди блокчейнов, полагающихся на различные механизмы консенсуса и структуры. ZK - это относительно новая и сложная технология, которую трудно проверить, и в настоящее время проверка и создание доказательств не являются оптимальными с точки зрения затрат. Мы считаем, что в долгосрочной перспективе для поддержки высокомасштабируемых межцепочечных приложений на блокчейне многие решения AMP, скорее всего, будут дополнять доверенных людей и сущностей проверяемым программным обеспечением:
• Возможность использования кода может быть сведена к минимуму с помощью аудита и вознаграждений за ошибки. С течением времени доверять этим системам будет легче, так как их история будет служить доказательством их безопасности.
• Стоимость генерации доказательств ZK уменьшится. С увеличением числа R&D в ZKPs, рекурсивных ZK, агрегировании доказательств и специализированном оборудовании, мы ожидаем, что время и стоимость генерации и проверки доказательств значительно сократятся, что сделает этот подход более экономически эффективным.
• Блокчейн станет более дружелюбным к zk. В будущем zkEVM смогут предоставлять краткое доказательство валидности выполнения, а легкие клиентские решения смогут легко проверять как выполнение, так и консенсус исходной цепочки с целевой цепочкой. В конечной цели Ethereum также планируется "zk-SNARK everything", включая консенсус.
• Подтверждение человечности/репутации/личности: Безопасность сложных систем, таких как AMP-решения, не может быть обеспечена с помощью одного фреймворка и требует многоуровневых решений. Например, наряду с экономическими стимулами, Axelar внедрил квадратичное голосование, чтобы предотвратить концентрацию права голоса среди подмножества узлов и способствовать децентрализации. Другие доказательства человечности, репутации и личности также могут дополнить механизмы настройки и разрешения.

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

Мы хотели бы поблагодарить Бо Ду и Питера Кима из Polymer Labs, Галена Мура из Axelar Network, Уму Рой из Succinct Labs, Макса Глассмана и Райана Зарика из LayerZero за рецензии и ценные отзывы.

Список ссылок:

• Axelar: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP: https://blog.chain.link/introducing-the-cross-chain-interoperability-protocol-ccip/
• Дебридж: https://docs.debridge.finance/
• IBC: https://tutorials.cosmos.network/academy/3-ibc/
• LayerZero: https://layerzero.gitbook.io/docs/
• Мультицепочка: https://docs.multichain.org/getting-started/introduction
• Кочевник: https://docs.nomad.xyz/nomad-101/introduction
• Polymer Labs: https://polymerlabs.medium.com/
• Succinct Labs: https://blog.succinct.xyz/
• Червоточина: https://docs.wormhole.com/wormhole/

Список дополнительного чтения:

• Навигация по произвольным мостам обмена сообщениями: Система сравнения: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• Система рисков L2Bridge: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Гораций на мосту: https://maven11.substack.com/p/horatius-at-the-bridge

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

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