Автор: STANFORD BLOCKCHAIN ​​CLUB Составил: Cointime: QDD.

введение

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

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

Каждое решение AMP требует двух ключевых возможностей:

1. Проверка: проверьте достоверность сообщения исходной цепочки в целевой цепочке.

2. Живучесть: способность передавать информацию из исходной цепочки в целевую цепочку.

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

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

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

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

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

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

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

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

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

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

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

Код доверия и математика

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

безопасность

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

выполнить

Реализация легкого клиента зависит от наличия криптографических примитивов, необходимых для аутентификации. Если вы подключаетесь к цепочке одного и того же типа, то есть используют одну и ту же платформу приложений и алгоритм консенсуса, то реализации легких клиентов обеих сторон будут одинаковыми. Например, все цепочки на основе Cosmos SDK используют протокол межблокчейновой связи (IBC). С другой стороны, если связаны два разных типа цепочек, например разные платформы приложений или типы консенсуса, реализация легкого клиента будет другой. Одним из примеров является Composable Finance, которая работает над подключением цепочки Cosmos SDK к Substrate экосистемы Polkadot через IBC. Для этого необходимо добавить легкий клиент Tendermint в цепочку Substrate и «мощный» легкий клиент в цепочку Cosmos SDK. Недавно они установили первую связь между Polkadot и Кусамой через IBC.

испытание

Ресурсоемкость является серьезной проблемой. Запуск пар легких клиентов во всех цепочках может быть дорогостоящим, поскольку запись в блокчейн обходится дорого. Кроме того, невозможно запускать легкие клиенты в цепочках с динамическими наборами валидаторов, таких как Ethereum.

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

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

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

Доказательства с нулевым разглашением как решение для доверия третьих сторон

Доказательство ZK можно использовать для проверки достоверности перехода состояния в исходной цепочке в целевой цепочке. Вместо того, чтобы выполнять все вычисления в цепочке, лучше выполнять только проверку вычислений в цепочке и перенести фактический процесс вычислений за пределы цепочки. Этот метод быстрее и дешевле, чем повторный запуск исходного расчета. Некоторые примеры включают Polymer ZK-IBC от Polymer Labs и Telepathy от Succinct Labs. Polymer разрабатывает IBC с поддержкой нескольких переходов для улучшения возможности подключения и уменьшения количества необходимых парных соединений.

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

безопасность

Безопасность zk-SNARK основана на эллиптических кривых, а zk-STARK — на хэш-функциях. Для zk-SNARK может потребоваться процесс доверенной установки, в ходе которого создаются исходные ключи для доказательств, используемых при проверке. Крайне важно хранить ключ в секрете для события настройки уничтожения, чтобы предотвратить совершение транзакций посредством поддельной проверки. После завершения настройки доверия дальнейшие предположения о доверии не вводятся. Кроме того, новые платформы ZK, такие как Halo и Halo2, полностью устраняют необходимость в надежной настройке.

выполнить

Существуют различные схемы доказательства ZK, такие как SNARK, STARK, VPD и SNARG, и наиболее широко используемой в настоящее время является SNARK. Различные среды доказательства SNARK, такие как Groth16, Plonk, Marlin, Halo и Halo2, имеют компромиссы в размере доказательства, времени доказательства, времени проверки, требованиях к памяти и необходимости надежной настройки. Также появились рекурсивные доказательства ZK, позволяющие распределять рабочую нагрузку доказательства по нескольким компьютерам, а не только по одному. Чтобы сгенерировать доказательство действительности, необходимо реализовать следующие основные примитивы: проверить схему подписи, используемую валидатором, включить доказательство открытого ключа валидатора в обязательство набора валидаторов, хранящееся в цепочке, и отслеживать набор валидаторов. , что может привести к тому, что изменения происходят часто.

испытание

Реализация различных схем подписи в zkSNARKs требует реализации внедоменной арифметики и сложных операций с эллиптическими кривыми, что непросто и может потребовать различных реализаций для каждой цепочки в зависимости от ее структуры и консенсуса. Аудит цепей ZK — сложная и подверженная ошибкам задача. Разработчики должны быть знакомы с предметно-ориентированными языками, такими как Circcom, Cairo и Noir, или просто реализовывать схемы самостоятельно, и то, и другое может оказаться сложной задачей и потенциально замедлить внедрение. Если время и усилия окажутся очень большими, с этим сможет справиться только выделенная команда с выделенным оборудованием, что может привести к централизации. Более длительное время генерации доказательств также приводит к задержкам. Такие методы, как инкрементные проверяемые вычисления (IVC), могут оптимизировать время проверки, но многие из них все еще находятся на стадии исследования и ожидают внедрения. Более длительное время и усилия по проверке увеличат затраты на цепочку.

теория игр доверия

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

Первая категория — это экономическая безопасность, когда несколько внешних участников (например, валидаторов) сотрудничают для достижения консенсуса относительно обновленного состояния цепочки источников. Чтобы стать валидатором, участникам необходимо поставить определенное количество токенов, которое может быть сокращено в случае возникновения вредоносной активности. При настройке без прав доступа любой может накопить ставку и стать валидатором. Кроме того, финансовые стимулы для валидаторов следовать протоколу предоставляются в виде вознаграждений за блоки, обеспечивая финансовый стимул для честного поведения. Однако если потенциальная сумма, которую можно украсть, превышает сумму ставки, участники могут вступить в сговор с целью кражи средств. Примерами протоколов, использующих механизмы экономической безопасности, являются Axelar и Celer IM.

Вторая категория — это оптимистическая безопасность, где решения основаны на предположении, что лишь несколько участников блокчейна честны и следуют правилам протокола. При таком подходе гарантом выступает единственный честный участник. Например, оптимальное решение позволяет любому предоставить доказательства мошенничества. Хотя существует финансовый стимул, честные наблюдатели могут пропустить мошеннические транзакции. Оптимистическое объединение также использует этот механизм. Nomad и ChainLink CCIP являются примерами протоколов, использующих оптимистическую безопасность. В случае с Nomad наблюдателям удалось доказать факт мошенничества, хотя на момент написания статьи они были в белом списке. ChainLink CCIP планирует использовать сеть по борьбе с мошенничеством, состоящую из децентрализованной сети Oracle, для мониторинга вредоносной активности, хотя реализация сети по борьбе с мошенничеством CCIP пока не известна.

безопасность

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

осуществлять

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

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

Преимущества и проблемы

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

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

доверять людям

Решения, требующие доверия к людям, также можно разделить на две категории:

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

2. Независимость. Эти решения разделяют весь процесс обмена сообщениями на две части и полагаются на разные независимые организации для управления этими двумя процессами. Здесь предполагается, что эти две организации независимы друг от друга и не могут вступать в сговор. LayerZero является примером. Заголовки блоков могут передаваться по требованию децентрализованными оракулами, а доказательства транзакций отправляются через ретрансляторы. Если доказательство соответствует заголовку блока, транзакция считается действительной. Хотя доказательство совпадения зависит от кода/математики, участники должны верить, что эти объекты могут оставаться независимыми. Приложения, созданные на LayerZero, могут выбирать свои оракулы и ретрансляторы (или размещать свои собственные оракулы/ретрансляторы), ограничивая риск сговора отдельных оракулов/ретрансляторов. Конечные пользователи должны быть уверены, что LayerZero, третьи стороны или сами приложения используют оракулы и ретрансляторы независимо и не имеют злонамеренных намерений.

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

Помимо предположений о доверии: дополнительные соображения по решениям AMP

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

целостность кода

Недавние хакеры использовали ошибки кодирования, подчеркивая необходимость надежного аудита, вознаграждений за ошибки и разнообразных реализаций клиентов. Если все валидаторы (в экономической/оптимистической/репутационной безопасности) используют один и тот же клиент (программное обеспечение, используемое для проверки), это увеличит зависимость от единой кодовой базы и уменьшит разнообразие клиентов. Например, Ethereum полагается на несколько клиентов исполнения, таких как geth, Nethermind, erigon, besu и akula. Множественные реализации на нескольких языках могут увеличить разнообразие, при этом ни один клиент не будет доминировать в сети, что устраняет потенциальные единые точки отказа. Наличие нескольких клиентов также может повысить жизнеспособность: если несколько валидаторов/подписантов/легких клиентов будут отключены из-за уязвимостей/атак в конкретной реализации, остальные все равно будут доступны.

Настройка и возможность обновления

Пользователи и разработчики должны понимать, могут ли валидаторы/наблюдатели присоединяться к сети без разрешения, иначе доверие будет скрыто выбранным уполномоченным объектом. Обновления смарт-контрактов также могут приводить к ошибкам, которые приводят к атакам или даже могут изменить предположения о доверии. Для снижения этих рисков могут быть реализованы различные решения. Например, в текущей реализации шлюз Axelar может быть обновлен на основе одобрения автономного комитета (порог 4/8), однако в ближайшем будущем Axelar планирует потребовать от всех валидаторов коллективно утверждать любые обновления шлюза. Основные контракты Wormhole можно обновлять и управлять ими через систему управления цепочкой Wormhole. LayerZero полагается на неизменяемые смарт-контракты и неизменяемые библиотеки, чтобы избежать каких-либо обновлений, но можно развернуть новые библиотеки, dApps, использующие настройки по умолчанию, получат обновленные версии, dApps с установленными вручную версиями необходимо будет установить новую версию.

Максимальная извлекаемая ценность (MEV)

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

завершенность исходной цепочки

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

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

Настраиваемая и дополнительная безопасность

Чтобы лучше соответствовать различным сценариям использования, решения AMP призваны обеспечить большую гибкость разработки. Axelar представляет метод обновления обмена сообщениями и проверки без изменения логики уровня приложения. HyperLane V2 представляет модули, которые позволяют разработчикам выбирать из нескольких вариантов, включая экономическую безопасность, оптимистическую безопасность, динамическую безопасность и гибридную безопасность. CelerIM обеспечивает дополнительную оптимистическую безопасность в дополнение к финансовой безопасности. Многие решения перед отправкой сообщения ждут заранее определенного минимального количества подтверждений блоков в исходной цепочке. LayerZero позволяет разработчикам обновлять эти параметры. Мы ожидаем, что некоторые решения AMP по-прежнему будут обеспечивать большую гибкость, но эти варианты дизайна требуют некоторого обсуждения. Могут ли приложения настраивать свою безопасность, в какой степени и что произойдет, если приложение спроектировано с неоптимальной архитектурой? Осведомленность пользователей об основных концепциях безопасности, вероятно, станет все более важной. В конечном итоге мы предвидим агрегацию и абстракцию решений AMP, возможно, в форме некоторой комбинации или «дополнительной» безопасности.

Зрелость механизма «кода доверия и математики»

В идеальной конечной цели все сообщения между цепочками должны быть сведены к минимуму за счет использования доказательств с нулевым разглашением. Мы уже наблюдаем этот сдвиг в таких проектах, как Polymer Labs и Succinct Labs. Multichain также опубликовала официальный документ под названием zkRouter, обеспечивающий совместимость посредством доказательств ZK. Благодаря недавно анонсированной виртуальной машине Axelar разработчики могут использовать Interchain Amplifier для установления новых подключений к сети Axelar без разрешения. Например, как только будут разработаны мощные легкие клиенты и ZK-доказательства состояния Ethereum, разработчики смогут легко интегрировать их в сеть Axelar, чтобы заменить или улучшить существующие соединения. Celer Network анонсировала платформу ZK для проверки данных между цепочками под названием Brevis, которая позволяет dApps и смарт-контрактам получать доступ, вычислять и использовать произвольные данные в нескольких блокчейнах. Celer использует схему легкого клиента ZK для реализации zkBridge, видимого пользователю актива, который соединяет тестовые сети Ethereum Goerli и BNB Chain. В документации LayerZero говорится о возможности добавления в будущем новых библиотек обмена сообщениями, устойчивых к оптимизации. Новые проекты, такие как «Лагранж», исследуют возможность агрегирования нескольких доказательств из нескольких цепочек источников, а Геродот делает возможным сохранение доказательств с помощью доказательств ZK. Однако этот переход займет время, поскольку этот подход сложно масштабировать между блокчейнами, которые полагаются на разные механизмы и структуры консенсуса.

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

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

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

3. Блокчейн будет более дружелюбен к ЗК. В будущем zkEVM сможет предоставлять краткие доказательства достоверности выполнения, а легкие клиентские решения смогут легко проверять выполнение и согласованность исходной цепочки. На заключительном этапе Ethereum также планируется «конвертировать все в zk-SNARK», включая консенсус.

Человечность, репутация и идентичность

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

в заключение

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

Рекомендации

https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702

https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e

https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges

https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps

https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725

https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ

https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability

https://twitter.com/CelerNetwork/status/1638330932603109379?s=20

https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade