Мультичейн — это будущая тенденция развития, и стремление к масштабируемости привело Ethereum к созданию технологии Rollup. При переходе к модульным блокчейнам внимание снова было обращено на Lisk. И в недалеком будущем мы слышим слухи о накопительных пакетах для конкретных приложений, L3 и суверенных цепочках. Но все это будет происходить за счет фрагментации, а текущие межсетевые мосты часто ограничены по функциональности и полагаются на доверенных подписантов для обеспечения безопасности.
Итак, как в конечном итоге будет выглядеть подключенный Web3? Мы считаем, что мосты между цепочками в конечном итоге превратятся в протоколы обмена сообщениями между цепочками или «обмена произвольными сообщениями» (AMP), чтобы разблокировать новые сценарии приложений, позволяя приложениям передавать произвольные сообщения между исходной цепочкой и целевой цепочкой. Мы также станем свидетелями появления «ландшафта механизма доверия», в котором разработчики будут идти на различные компромиссы между удобством использования, сложностью и безопасностью.
Каждое решение AMP должно реализовывать две ключевые функции:
Верификация: возможность проверки достоверности сообщений из исходной цепочки в целевой цепочке.
Живучесть: способность передавать информацию из исходной цепочки в целевую цепочку
К сожалению, 100% ненадежная проверка нереалистична, пользователи должны выбирать, доверять ли коду, теории игр, людям (или объектам) или их комбинации, в зависимости от того, осуществляется ли проверка в сети или вне сети.
В этой статье мы вертикально делим общую область взаимодействия на механизмы, основанные на доверии, и архитектуры, основанные на интеграции.
Механизм доверия:
Доверяйте коду и математике. Для этих решений существует доказательство в сети, которое может проверить любой. Эти решения обычно полагаются на легкие клиенты для проверки консенсуса исходной цепочки в целевой цепочке или проверки правильности перехода состояния исходной цепочки в целевую цепочку. Проверка через легкие клиенты может повысить эффективность за счет доказательств с нулевым разглашением, сжимая произвольно длинные вычисления для выполнения в автономном режиме, обеспечивая при этом простую проверку в цепочке для подтверждения результатов вычислений.
Теория доверительных игр. Когда пользователю/приложению необходимо доверять третьей стороне или сторонней сети, чтобы гарантировать подлинность транзакции, используются дополнительные предположения о доверии. Безопасность этих механизмов можно повысить, используя сети без разрешения и теорию игр, такие как экономические стимулы и оптимистическая безопасность.
Доверие к людям: эти решения основаны на честности или независимости большинства валидаторов, которые сообщают различную информацию. Помимо доверия к консенсусу двух интерактивных цепочек, вам также необходимо доверять третьей стороне. В этом случае единственным риском является репутация участвующих лиц. Транзакция считается действительной, если достаточное количество участвующих сторон согласны с тем, что она действительна.
Стоит отметить, что все решения в той или иной степени требуют доверия к коду и людям. Любое решение с ошибочным кодом может быть использовано хакерами, и каждое решение имеет некоторый человеческий фактор в настройке, обновлении или обслуживании базы кода.
Архитектура интеграции:
Модель «точка-точка»: необходимо установить выделенный канал связи между каждой исходной и целевой цепочками.
Модель центрального хаба: необходимо установить канал связи с центральным хабом для обеспечения взаимосвязи со всеми другими блокчейнами, подключенными к хабу.
Одноранговую модель относительно сложно масштабировать, потому что для каждого подключенного блокчейна требуется парный канал связи. Разработка этих каналов может быть сложной задачей для блокчейнов с другим консенсусом и фреймворками. Однако парные мосты предлагают больше гибкости для настройки конфигурации по желанию. Также возможны гибридные подходы, такие как маршрутизация с несколькими переходами через ретрансляторы с использованием протокола Inter-Blockchain Communication (IBC), который устраняет необходимость в прямой одноранговой связи, но вносит больше сложностей с точки зрения безопасности, задержки и расходы.
Доверяйте коду и математике
Чтобы полагаться только на код/математику для предположений о доверии, можно использовать легкие клиенты для проверки консенсуса исходной цепочки в целевой цепочке. Легкие клиенты/узлы — это программное обеспечение, которое подключается к полным узлам для взаимодействия с блокчейном. Легкие клиенты в целевой цепочке обычно хранят историю (по порядку) заголовков блоков исходной цепочки, которой достаточно для проверки транзакций. Прокси-сервер вне цепочки (например, ретранслятор) отслеживает события в исходной цепочке, генерирует криптографические доказательства включения и пересылает их вместе с заголовками блоков легким клиентам в целевой цепочке. Поскольку легкие клиенты хранят заголовки блоков последовательно, каждый из которых содержит корневой хэш Merkle, который можно использовать для проверки состояния, они могут проверять транзакции. Вот обзор основных особенностей этого подхода:
безопасность
Предположения о доверии вводятся во время инициализации легких клиентов. При создании нового легкого клиента он будет инициализирован заголовком блока определенной высоты в другой цепочке. Однако существует вероятность того, что предоставленные заголовки блоков могут быть неверными, что позволяет обмануть легкие клиенты с помощью поддельных заголовков блоков. После инициализации легкого клиента дальнейшие предположения о доверии не вводятся. Однако стоит отметить, что этот процесс инициализации основан на допущении о слабом доверии, поскольку его может проверить любой. Кроме того, предполагается живучесть непрерывной передачи информации реле.
выполнение
Реализация легких клиентов зависит от наличия криптографических примитивов, необходимых для аутентификации. Если подключены цепочки одного типа, то есть они используют одну и ту же структуру приложений и алгоритм консенсуса, реализации легкого клиента на обоих концах будут одинаковыми. Например, все цепочки на основе Cosmos SDK используют протокол Inter-Blockchain Communication (IBC). С другой стороны, такие реализации, как легкие клиенты, зависят от поддержки криптографических примитивов, необходимых для аутентификации. Если соединены цепочки одного типа, т. е. они используют одну и ту же структуру приложения и алгоритм консенсуса, то реализации легкого клиента на обеих сторонах будут одинаковыми. Например, протокол Inter-Blockchain Communication (IBC) используется для всех цепочек на основе Cosmos SDK. С другой стороны, если соединены два разных типа цепочек, например разные платформы приложений или типы консенсуса, реализация легкого клиента будет другой. Одним из примеров является Composable Finance, которая работает над подключением цепочки Cosmos SDK к платформе приложений Substrate экосистемы Polkadot через IBC. Для этого требуется легкий клиент Tendermint в цепочке Substrate и «мощный» легкий клиент в цепочке Cosmos SDK. Недавно они установили первое соединение между Polkadot и Kusama через IBC.
испытание
Ресурсоемкость является важной проблемой. Запуск пар легких клиентов во всех цепочках может быть дорогим, потому что запись в блокчейн стоит дорого. Кроме того, важной проблемой является ресурсоемкость динамических верификаторов. Запуск парных легких клиентов во всех цепочках может быть дорогим, потому что запись в блокчейн стоит дорого. Кроме того, для цепочек с динамическими наборами валидаторов (например, Ethereum) невозможно запускать облегченные клиенты.
Масштабируемость — еще одна проблема. Реализация легких клиентов зависит от архитектуры сети, что затрудняет масштабирование и подключение различных экосистем.
Уязвимости кода представляют собой потенциальный риск, поскольку ошибки в коде могут привести к уязвимостям. Например, взлом сети BNB в октябре 2022 года выявил критический недостаток безопасности, затрагивающий все сети с поддержкой IBC.
Чтобы снизить стоимость и практичность запуска парных легких клиентов во всех цепочках, можно использовать альтернативные решения, такие как доказательства с нулевым разглашением (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 — сложная и подверженная ошибкам задача. Разработчики должны быть знакомы с предметно-ориентированными языками, такими как Circom, Cairo и Noir, или напрямую реализовывать схемы, оба из которых могут быть сложными и замедлять внедрение. Если время и усилия окажутся очень большими, с этим могут справиться только выделенные команды и выделенное оборудование, что может привести к централизации. Более длительное время генерации доказательств также вызывает задержки. Такие методы, как инкрементально проверяемые вычисления (IVC), могут оптимизировать время проверки, но многие из них все еще находятся на стадии исследований и ожидают внедрения. Более длительное время проверки и рабочие нагрузки увеличат затраты на цепочку.
Доверяйте теории игр
Протоколы интероперабельности, основанные на теории игр, можно в целом разделить на две категории в зависимости от того, как они стимулируют честное поведение участвующих субъектов:
Первая категория — это механизм экономической безопасности, в котором несколько внешних субъектов (таких как валидаторы) сотрудничают для достижения консенсуса для определения обновленного состояния исходной цепочки. Чтобы стать валидатором, участникам необходимо поставить определенное количество токенов, которое может быть уменьшено в случае злонамеренной активности. При настройке без разрешений любой может накопить долю и стать валидатором. Кроме того, валидаторам, которые следуют протоколу, предоставляются экономические стимулы, такие как вознаграждение за блок, чтобы обеспечить экономические стимулы для честного поведения. Однако, если потенциальная украденная сумма превышает сумму ставок, участники могут вступить в сговор с целью кражи средств. Примеры протоколов, использующих экономичные механизмы безопасности, включают Axelar и Celer IM.
Вторая категория — это оптимистичные механизмы безопасности, где решение основано на предположении, что лишь небольшое количество участников блокчейна честны и подчиняются правилам протокола. При таком подходе гарантией выступает честный участник. Например, оптимальное решение позволяет любому предъявить доказательства мошенничества. Несмотря на наличие финансового стимула, честный наблюдатель может пропустить мошенническую транзакцию. Оптимистические накопительные пакеты также используют этот механизм. Nomad и ChainLink CCIP являются примерами протоколов, использующих оптимистичные механизмы безопасности. В случае с Nomad наблюдатели смогли доказать мошенничество, хотя на момент написания статьи они были в белом списке. ChainLink CCIP планирует использовать сеть защиты от мошенничества, состоящую из распределенной сети оракулов, для обнаружения вредоносной активности, хотя реализация сети защиты от мошенничества CCIP неизвестна.
безопасность
С точки зрения безопасности, оба механизма полагаются на несанкционированное участие верификаторов и наблюдателей для обеспечения теоретико-игровой валидности. В механизме экономической безопасности средства более уязвимы, если поставленная сумма меньше суммы, которую можно украсть. С другой стороны, в оптимистичных механизмах безопасности предположение о доверии меньшинства может быть использовано, если никто не представит доказательства мошенничества или если наблюдатели за разрешениями скомпрометированы или удалены. Напротив, механизмы экономической безопасности в меньшей степени зависят от жизнеспособности для поддержания безопасности.
выполнение
С точки зрения реализации один из подходов включает промежуточную цепочку с собственными валидаторами. В этой настройке группа внешних валидаторов отслеживает исходную цепочку и достигает консенсуса в отношении действительности транзакции при обнаружении вызова. После достижения консенсуса они предоставляют доказательства в целевой цепочке. Валидаторам обычно требуется поставить определенное количество токенов, которое может быть уменьшено в случае обнаружения вредоносной активности. Примеры протоколов, использующих этот метод реализации, включают Axelar Network и Celer IM.
Другой способ реализации предполагает использование прокси-серверов вне сети. Прокси-серверы вне сети используются для реализации оптимистичных решений, подобных Rollup. В течение заранее определенного временного окна эти прокси-серверы вне сети могут предоставлять доказательства мошенничества и при необходимости отменять транзакции. Например, Nomad полагается на независимые прокси-серверы вне сети для передачи заголовков и криптографических доказательств. С другой стороны, ChainLink CCIP планирует использовать существующую сеть оракулов для мониторинга и подтверждения межсетевых транзакций.
Преимущества и проблемы
Ключевым преимуществом решений AMP, основанных на теории игр, является оптимизация ресурсов, поскольку процесс проверки обычно выполняется вне сети, что снижает требования к ресурсам. Кроме того, эти механизмы являются масштабируемыми, поскольку механизм консенсуса остается одинаковым для различных типов цепочек и может быть легко расширен на гетерогенные блокчейны.
Есть также несколько проблем, связанных с этими механизмами. Если большинство валидаторов вступают в сговор, предположения о доверии могут быть использованы для кражи средств, что требует контрмер, таких как квадратичное голосование и доказательства мошенничества. Кроме того, решения, основанные на оптимистичной безопасности, создают сложности с точки зрения окончательности и живучести, поскольку пользователям и приложениям приходится ждать мошеннических окон, чтобы гарантировать достоверность транзакций.
Доверяйте людям
Решения, требующие доверия к людям, также можно условно разделить на две категории:
Репутационная безопасность: эти решения основаны на реализациях с несколькими подписями, где несколько объектов проверяют и подписывают транзакции. При достижении минимального порога транзакция считается действительной. Здесь предполагается, что большинство субъектов честны, и если большинство этих субъектов подписывают определенную транзакцию, то эта транзакция действительна. Единственное, что здесь находится под угрозой, — это репутация вовлеченных лиц. Некоторые примеры включают Multichain (Anycall V6) и Wormhole. Уязвимости все еще могут существовать из-за уязвимостей смарт-контрактов, о чем свидетельствует взлом Wormhole в начале 2022 года.
Независимость. Эти решения делят весь процесс обмена сообщениями на две части и полагаются на разные независимые объекты для управления двумя процессами. Здесь предполагается, что эти два объекта независимы друг от друга и не могут вступить в сговор. LayerZero является примером. Заголовки блоков передаются по запросу через распределенные оракулы, а доказательства транзакций отправляются через ретрансляторы. Если подтверждение соответствует заголовку, транзакция считается действительной. Хотя доказательство совпадения зависит от кода/математики, участники должны быть уверены, что эти объекты остаются независимыми и не имеют злого умысла. Приложения, построенные на LayerZero, могут выбирать свои оракулы и ретрансляторы (или размещать свои собственные оракулы/ретрансляторы), тем самым ограничивая риск для отдельных оракулов/ретрансляторов. Конечные пользователи должны быть уверены, что LayerZero, третьи стороны или само приложение запускают оракулы и ретрансляторы независимо друг от друга, без злого умысла.
В обоих подходах репутация участвующих сторонних организаций сдерживает злонамеренное поведение. Обычно это уважаемые лица в сообществе валидаторов и оракулов, и если они ведут себя злонамеренно, они рискуют нанести ущерб репутации и негативно повлиять на другие виды деятельности.
Дополнительные рекомендации по решениям AMP
При рассмотрении безопасности и удобства использования решения AMP нам также необходимо учитывать детали, выходящие за рамки базовой механики. Поскольку эти компоненты могут меняться со временем, мы не включали их в общее сравнение.
Целостность кода
Недавние взломы использовали ошибки кода, подчеркивая необходимость надежного аудита, вознаграждений за ошибки и разнообразных клиентских реализаций. Если все верификаторы (в экономической/оптимистической/репутационной безопасности) используют один и тот же клиент (программное обеспечение для проверки), это увеличивает зависимость от единой кодовой базы и снижает разнообразие клиентов. Например, Ethereum использует несколько клиентов исполнения, таких как geth, netermind, erigon, besu, akula. Несколько реализаций на разных языках могут увеличить разнообразие, при этом ни один клиент не будет доминировать в сети, что устраняет потенциальную единую точку отказа. Наличие нескольких клиентов также может помочь сохранить работоспособность в случае сбоя небольшого количества валидаторов/подписавших/легких клиентов из-за ошибки/атаки в конкретной реализации.
Установка и возможность обновления
Пользователям и разработчикам необходимо знать, могут ли валидаторы/наблюдатели присоединяться к сети без разрешения, иначе доверие будет скрыто субъектами, выбравшими разрешение. Обновления смарт-контрактов также могут создавать уязвимости, которые могут привести к атакам и, возможно, даже изменить предположения о доверии. Для снижения этих рисков могут быть реализованы различные решения. Например, в текущем экземпляре шлюз Axelar может быть обновлен, но для этого требуется одобрение автономного комитета (порог 4/8), однако в ближайшем будущем Axelar планирует потребовать от всех валидаторов коллективного утверждения любых обновлений шлюза. Основные контракты Wormhole можно обновлять, и ими можно управлять с помощью сетевой системы управления Wormhole. LayerZero полагается на неизменяемые смарт-контракты и неизменяемые библиотеки, чтобы избежать каких-либо обновлений, но новые библиотеки могут быть отправлены, децентрализованные приложения, которые устанавливают настройки по умолчанию, получат более новые версии, децентрализованные приложения, которые вручную устанавливают версию, должны установить ее на новую версию.
Максимальная извлекаемая ценность (MEV)
Различные блокчейны не синхронизируются общими часами и имеют разное время завершения. Таким образом, порядок выполнения и время в целевой цепочке могут варьироваться от цепочки к цепочке. В кроссчейн-мире трудно дать четкое определение MEV. Он вводит компромисс между живучестью и порядком исполнения. Упорядоченный канал обеспечивает доставку сообщений по порядку, но если сообщение истекает, канал будет закрыт. Другое приложение может предпочесть отсутствие упорядочения, но это не повлияет на доставку других сообщений.
Надежность исходной цепочки
В идеале решения AMP должны ждать завершения исходной цепочки, прежде чем передавать информацию о состоянии исходной цепочки одной или нескольким целевым цепочкам. Это гарантирует, что блоки в исходной цепочке вряд ли можно будет отменить или изменить. Однако многие решения обеспечивают обмен мгновенными сообщениями и делают доверительные предположения об окончательности, чтобы обеспечить наилучшее взаимодействие с пользователем. В этом случае, если исходная цепочка подвергается откату состояния после доставки сообщения и передачи актива моста, это может привести к таким ситуациям, как двойное расходование средств моста. Решения AMP могут управлять этим риском несколькими способами, например, устанавливая разные допущения об окончательности для разных цепочек в зависимости от того, насколько децентрализована цепочка, или путем поиска компромисса между скоростью и безопасностью. Мосты, использующие решения AMP, могут устанавливать ограничения на количество ресурсов, соединяемых до того, как исходная цепочка достигнет завершенности.
Тенденции и перспективы на будущее Настраиваемая и подключаемая безопасность
Чтобы лучше обслуживать различные варианты использования, решения AMP поощряются за предоставление большей гибкости разработчикам. Axelar представляет метод обеспечения масштабируемости обмена сообщениями и проверки без изменения логики прикладного уровня. HyperLane V2 представляет модули, которые позволяют разработчикам выбирать из нескольких вариантов, таких как экономичная безопасность, оптимистичная безопасность, динамическая безопасность и гибридная безопасность. CelerIM обеспечивает дополнительную оптимистическую безопасность в дополнение к экономической безопасности. Многие решения ждут предопределенного минимального количества подтверждений блока в исходной цепочке, прежде чем доставить сообщение. LayerZero позволяет разработчикам обновлять эти параметры. Мы ожидаем, что некоторые решения AMP по-прежнему будут предлагать большую гибкость, но эти варианты дизайна требуют некоторого обсуждения. Должны ли приложения иметь возможность настраивать свою безопасность, в какой степени и что произойдет, если архитектура приложений неоптимальна? Осведомленность пользователей об основных концепциях безопасности, вероятно, будет становиться все более важной. В конечном счете, мы предвидим агрегацию и абстракцию решений AMP, возможно, в виде какой-либо формы композиции или «дополнительной» безопасности.
Зрелость механизма «доверительного кода и математики»
В идеале на конечном этапе все межсетевые сообщения будут сведены к минимуму за счет использования доказательств с нулевым разглашением (ZK). Мы видели, как появляются подобные проекты, такие как Polymer Labs и Succinct Labs. Multichain также опубликовала технический документ zkRouter о совместимости с помощью доказательств ZK. Благодаря недавно анонсированной виртуальной машине Axelar разработчики могут использовать Interchain Amplifier для беспрепятственного установления новых подключений к сети Axelar. Например, когда для состояния Ethereum будут разработаны надежные легкие клиенты и доказательства ZK, разработчики смогут легко интегрировать их в сеть Axelar, чтобы заменить или улучшить существующие соединения. Celer Network анонсировала Brevis, кросс-цепочную платформу ZK для проверки данных, которая позволяет dApps и смарт-контрактам получать доступ, вычислять и использовать произвольные данные в нескольких блокчейнах. Celer реализовал ориентированный на пользователя актив zkBridge, используя схему легкого клиента ZK для кроссчейна между тестовой сетью Ethereum Goerli и тестовой сетью BNB Chain. LayerZero обсуждает в своей документации возможность добавления новых оптимизированных библиотек контрольных сообщений в будущем. Более новые проекты, такие как Lagrange, изучают агрегирование нескольких доказательств из нескольких цепочек источников, а Herodotus делает возможным хранение доказательств с доказательствами ZK. Однако этот переход потребует времени, так как этот подход трудно масштабировать в блокчейнах, которые полагаются на разные механизмы и структуры консенсуса.
ZK — относительно новая и сложная технология, которую трудно проверить, а текущие затраты на проверку и генерацию доказательств не оптимальны. Мы считаем, что в долгосрочной перспективе для поддержки масштабируемых межсетевых приложений на блокчейнах многие решения AMP, скорее всего, будут сочетать проверяемое программное обеспечение с доверенными людьми и организациями, потому что:
С помощью аудита и вознаграждения за ошибки можно свести к минимуму возможность эксплуатации кода. Со временем доверять этим системам станет легче, поскольку их история становится доказательством их безопасности.
Стоимость генерации ZK пруфов будет снижена. Благодаря дальнейшим исследованиям и разработкам в области ZKP, рекурсивных ZKP, агрегации доказательств, схем складывания и специализированного оборудования мы ожидаем, что временные затраты на создание и проверку доказательств существенно снизятся, что сделает этот подход более рентабельным.
Блокчейн станет больше поддерживать ZK. В будущем zkEVM сможет предоставлять краткие доказательства правильности выполнения, а легкие клиентские решения смогут легко проверять выполнение исходной цепочки и консенсус. На заключительном этапе Ethereum также планируется «zk-SNARK всего», включая механизм консенсуса.
Доказательство личности, репутация и личность
Безопасность сложной системы, такой как решение AMP, не может быть инкапсулирована одной единственной структурой и требует многоуровневого решения. Например, в дополнение к экономическим стимулам Axelar реализует механизм квадратичного голосования, чтобы предотвратить концентрацию права голоса среди подмножества узлов и способствовать децентрализации. Другие человеческие доказательства, репутация и личность также могут дополнять механизмы настройки и разрешения.
в заключение
В открытом духе Web3 мы можем увидеть плюралистическое будущее, в котором сосуществуют несколько подходов. На самом деле, приложение может выбрать использование нескольких решений взаимодействия либо с избыточностью, либо с выбором пользователем комбинации на основе компромиссов. Между маршрутами с «интенсивным трафиком» могут быть приоритетными решения «точка-точка», в то время как модели со ступицей могут доминировать в длинном хвосте цепочки. В конечном счете, мы, как сообщество пользователей, разработчиков и участников, будем формировать основную форму Интернета Web3.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Как глубокая интерпретация произвольных протоколов обмена сообщениями решает проблему доверия совместимости?
Автор：Ши Кхай Вэй，Рагхав Агарвал
Сборник: Kxp, BlockBeats
Введение
Мультичейн — это будущая тенденция развития, и стремление к масштабируемости привело Ethereum к созданию технологии Rollup. При переходе к модульным блокчейнам внимание снова было обращено на Lisk. И в недалеком будущем мы слышим слухи о накопительных пакетах для конкретных приложений, L3 и суверенных цепочках. Но все это будет происходить за счет фрагментации, а текущие межсетевые мосты часто ограничены по функциональности и полагаются на доверенных подписантов для обеспечения безопасности.
Итак, как в конечном итоге будет выглядеть подключенный Web3? Мы считаем, что мосты между цепочками в конечном итоге превратятся в протоколы обмена сообщениями между цепочками или «обмена произвольными сообщениями» (AMP), чтобы разблокировать новые сценарии приложений, позволяя приложениям передавать произвольные сообщения между исходной цепочкой и целевой цепочкой. Мы также станем свидетелями появления «ландшафта механизма доверия», в котором разработчики будут идти на различные компромиссы между удобством использования, сложностью и безопасностью.
Каждое решение AMP должно реализовывать две ключевые функции:
К сожалению, 100% ненадежная проверка нереалистична, пользователи должны выбирать, доверять ли коду, теории игр, людям (или объектам) или их комбинации, в зависимости от того, осуществляется ли проверка в сети или вне сети.
В этой статье мы вертикально делим общую область взаимодействия на механизмы, основанные на доверии, и архитектуры, основанные на интеграции.
Механизм доверия:
Доверяйте коду и математике. Для этих решений существует доказательство в сети, которое может проверить любой. Эти решения обычно полагаются на легкие клиенты для проверки консенсуса исходной цепочки в целевой цепочке или проверки правильности перехода состояния исходной цепочки в целевую цепочку. Проверка через легкие клиенты может повысить эффективность за счет доказательств с нулевым разглашением, сжимая произвольно длинные вычисления для выполнения в автономном режиме, обеспечивая при этом простую проверку в цепочке для подтверждения результатов вычислений.
Теория доверительных игр. Когда пользователю/приложению необходимо доверять третьей стороне или сторонней сети, чтобы гарантировать подлинность транзакции, используются дополнительные предположения о доверии. Безопасность этих механизмов можно повысить, используя сети без разрешения и теорию игр, такие как экономические стимулы и оптимистическая безопасность.
Доверие к людям: эти решения основаны на честности или независимости большинства валидаторов, которые сообщают различную информацию. Помимо доверия к консенсусу двух интерактивных цепочек, вам также необходимо доверять третьей стороне. В этом случае единственным риском является репутация участвующих лиц. Транзакция считается действительной, если достаточное количество участвующих сторон согласны с тем, что она действительна.
Стоит отметить, что все решения в той или иной степени требуют доверия к коду и людям. Любое решение с ошибочным кодом может быть использовано хакерами, и каждое решение имеет некоторый человеческий фактор в настройке, обновлении или обслуживании базы кода.
Архитектура интеграции:
Модель «точка-точка»: необходимо установить выделенный канал связи между каждой исходной и целевой цепочками.
Модель центрального хаба: необходимо установить канал связи с центральным хабом для обеспечения взаимосвязи со всеми другими блокчейнами, подключенными к хабу.
Одноранговую модель относительно сложно масштабировать, потому что для каждого подключенного блокчейна требуется парный канал связи. Разработка этих каналов может быть сложной задачей для блокчейнов с другим консенсусом и фреймворками. Однако парные мосты предлагают больше гибкости для настройки конфигурации по желанию. Также возможны гибридные подходы, такие как маршрутизация с несколькими переходами через ретрансляторы с использованием протокола Inter-Blockchain Communication (IBC), который устраняет необходимость в прямой одноранговой связи, но вносит больше сложностей с точки зрения безопасности, задержки и расходы.
Доверяйте коду и математике
Чтобы полагаться только на код/математику для предположений о доверии, можно использовать легкие клиенты для проверки консенсуса исходной цепочки в целевой цепочке. Легкие клиенты/узлы — это программное обеспечение, которое подключается к полным узлам для взаимодействия с блокчейном. Легкие клиенты в целевой цепочке обычно хранят историю (по порядку) заголовков блоков исходной цепочки, которой достаточно для проверки транзакций. Прокси-сервер вне цепочки (например, ретранслятор) отслеживает события в исходной цепочке, генерирует криптографические доказательства включения и пересылает их вместе с заголовками блоков легким клиентам в целевой цепочке. Поскольку легкие клиенты хранят заголовки блоков последовательно, каждый из которых содержит корневой хэш Merkle, который можно использовать для проверки состояния, они могут проверять транзакции. Вот обзор основных особенностей этого подхода:
безопасность
Предположения о доверии вводятся во время инициализации легких клиентов. При создании нового легкого клиента он будет инициализирован заголовком блока определенной высоты в другой цепочке. Однако существует вероятность того, что предоставленные заголовки блоков могут быть неверными, что позволяет обмануть легкие клиенты с помощью поддельных заголовков блоков. После инициализации легкого клиента дальнейшие предположения о доверии не вводятся. Однако стоит отметить, что этот процесс инициализации основан на допущении о слабом доверии, поскольку его может проверить любой. Кроме того, предполагается живучесть непрерывной передачи информации реле.
выполнение
Реализация легких клиентов зависит от наличия криптографических примитивов, необходимых для аутентификации. Если подключены цепочки одного типа, то есть они используют одну и ту же структуру приложений и алгоритм консенсуса, реализации легкого клиента на обоих концах будут одинаковыми. Например, все цепочки на основе Cosmos SDK используют протокол Inter-Blockchain Communication (IBC). С другой стороны, такие реализации, как легкие клиенты, зависят от поддержки криптографических примитивов, необходимых для аутентификации. Если соединены цепочки одного типа, т. е. они используют одну и ту же структуру приложения и алгоритм консенсуса, то реализации легкого клиента на обеих сторонах будут одинаковыми. Например, протокол Inter-Blockchain Communication (IBC) используется для всех цепочек на основе Cosmos SDK. С другой стороны, если соединены два разных типа цепочек, например разные платформы приложений или типы консенсуса, реализация легкого клиента будет другой. Одним из примеров является Composable Finance, которая работает над подключением цепочки Cosmos SDK к платформе приложений Substrate экосистемы Polkadot через IBC. Для этого требуется легкий клиент Tendermint в цепочке Substrate и «мощный» легкий клиент в цепочке Cosmos SDK. Недавно они установили первое соединение между Polkadot и Kusama через IBC.
испытание
Ресурсоемкость является важной проблемой. Запуск пар легких клиентов во всех цепочках может быть дорогим, потому что запись в блокчейн стоит дорого. Кроме того, важной проблемой является ресурсоемкость динамических верификаторов. Запуск парных легких клиентов во всех цепочках может быть дорогим, потому что запись в блокчейн стоит дорого. Кроме того, для цепочек с динамическими наборами валидаторов (например, Ethereum) невозможно запускать облегченные клиенты.
Масштабируемость — еще одна проблема. Реализация легких клиентов зависит от архитектуры сети, что затрудняет масштабирование и подключение различных экосистем.
Уязвимости кода представляют собой потенциальный риск, поскольку ошибки в коде могут привести к уязвимостям. Например, взлом сети BNB в октябре 2022 года выявил критический недостаток безопасности, затрагивающий все сети с поддержкой IBC.
Чтобы снизить стоимость и практичность запуска парных легких клиентов во всех цепочках, можно использовать альтернативные решения, такие как доказательства с нулевым разглашением (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 — сложная и подверженная ошибкам задача. Разработчики должны быть знакомы с предметно-ориентированными языками, такими как Circom, Cairo и Noir, или напрямую реализовывать схемы, оба из которых могут быть сложными и замедлять внедрение. Если время и усилия окажутся очень большими, с этим могут справиться только выделенные команды и выделенное оборудование, что может привести к централизации. Более длительное время генерации доказательств также вызывает задержки. Такие методы, как инкрементально проверяемые вычисления (IVC), могут оптимизировать время проверки, но многие из них все еще находятся на стадии исследований и ожидают внедрения. Более длительное время проверки и рабочие нагрузки увеличат затраты на цепочку.
Доверяйте теории игр
Протоколы интероперабельности, основанные на теории игр, можно в целом разделить на две категории в зависимости от того, как они стимулируют честное поведение участвующих субъектов:
Первая категория — это механизм экономической безопасности, в котором несколько внешних субъектов (таких как валидаторы) сотрудничают для достижения консенсуса для определения обновленного состояния исходной цепочки. Чтобы стать валидатором, участникам необходимо поставить определенное количество токенов, которое может быть уменьшено в случае злонамеренной активности. При настройке без разрешений любой может накопить долю и стать валидатором. Кроме того, валидаторам, которые следуют протоколу, предоставляются экономические стимулы, такие как вознаграждение за блок, чтобы обеспечить экономические стимулы для честного поведения. Однако, если потенциальная украденная сумма превышает сумму ставок, участники могут вступить в сговор с целью кражи средств. Примеры протоколов, использующих экономичные механизмы безопасности, включают Axelar и Celer IM.
Вторая категория — это оптимистичные механизмы безопасности, где решение основано на предположении, что лишь небольшое количество участников блокчейна честны и подчиняются правилам протокола. При таком подходе гарантией выступает честный участник. Например, оптимальное решение позволяет любому предъявить доказательства мошенничества. Несмотря на наличие финансового стимула, честный наблюдатель может пропустить мошенническую транзакцию. Оптимистические накопительные пакеты также используют этот механизм. Nomad и ChainLink CCIP являются примерами протоколов, использующих оптимистичные механизмы безопасности. В случае с Nomad наблюдатели смогли доказать мошенничество, хотя на момент написания статьи они были в белом списке. ChainLink CCIP планирует использовать сеть защиты от мошенничества, состоящую из распределенной сети оракулов, для обнаружения вредоносной активности, хотя реализация сети защиты от мошенничества CCIP неизвестна.
безопасность
С точки зрения безопасности, оба механизма полагаются на несанкционированное участие верификаторов и наблюдателей для обеспечения теоретико-игровой валидности. В механизме экономической безопасности средства более уязвимы, если поставленная сумма меньше суммы, которую можно украсть. С другой стороны, в оптимистичных механизмах безопасности предположение о доверии меньшинства может быть использовано, если никто не представит доказательства мошенничества или если наблюдатели за разрешениями скомпрометированы или удалены. Напротив, механизмы экономической безопасности в меньшей степени зависят от жизнеспособности для поддержания безопасности.
выполнение
С точки зрения реализации один из подходов включает промежуточную цепочку с собственными валидаторами. В этой настройке группа внешних валидаторов отслеживает исходную цепочку и достигает консенсуса в отношении действительности транзакции при обнаружении вызова. После достижения консенсуса они предоставляют доказательства в целевой цепочке. Валидаторам обычно требуется поставить определенное количество токенов, которое может быть уменьшено в случае обнаружения вредоносной активности. Примеры протоколов, использующих этот метод реализации, включают Axelar Network и Celer IM.
Другой способ реализации предполагает использование прокси-серверов вне сети. Прокси-серверы вне сети используются для реализации оптимистичных решений, подобных Rollup. В течение заранее определенного временного окна эти прокси-серверы вне сети могут предоставлять доказательства мошенничества и при необходимости отменять транзакции. Например, Nomad полагается на независимые прокси-серверы вне сети для передачи заголовков и криптографических доказательств. С другой стороны, ChainLink CCIP планирует использовать существующую сеть оракулов для мониторинга и подтверждения межсетевых транзакций.
Преимущества и проблемы
Ключевым преимуществом решений AMP, основанных на теории игр, является оптимизация ресурсов, поскольку процесс проверки обычно выполняется вне сети, что снижает требования к ресурсам. Кроме того, эти механизмы являются масштабируемыми, поскольку механизм консенсуса остается одинаковым для различных типов цепочек и может быть легко расширен на гетерогенные блокчейны.
Есть также несколько проблем, связанных с этими механизмами. Если большинство валидаторов вступают в сговор, предположения о доверии могут быть использованы для кражи средств, что требует контрмер, таких как квадратичное голосование и доказательства мошенничества. Кроме того, решения, основанные на оптимистичной безопасности, создают сложности с точки зрения окончательности и живучести, поскольку пользователям и приложениям приходится ждать мошеннических окон, чтобы гарантировать достоверность транзакций.
Доверяйте людям
Решения, требующие доверия к людям, также можно условно разделить на две категории:
Репутационная безопасность: эти решения основаны на реализациях с несколькими подписями, где несколько объектов проверяют и подписывают транзакции. При достижении минимального порога транзакция считается действительной. Здесь предполагается, что большинство субъектов честны, и если большинство этих субъектов подписывают определенную транзакцию, то эта транзакция действительна. Единственное, что здесь находится под угрозой, — это репутация вовлеченных лиц. Некоторые примеры включают Multichain (Anycall V6) и Wormhole. Уязвимости все еще могут существовать из-за уязвимостей смарт-контрактов, о чем свидетельствует взлом Wormhole в начале 2022 года.
Независимость. Эти решения делят весь процесс обмена сообщениями на две части и полагаются на разные независимые объекты для управления двумя процессами. Здесь предполагается, что эти два объекта независимы друг от друга и не могут вступить в сговор. LayerZero является примером. Заголовки блоков передаются по запросу через распределенные оракулы, а доказательства транзакций отправляются через ретрансляторы. Если подтверждение соответствует заголовку, транзакция считается действительной. Хотя доказательство совпадения зависит от кода/математики, участники должны быть уверены, что эти объекты остаются независимыми и не имеют злого умысла. Приложения, построенные на LayerZero, могут выбирать свои оракулы и ретрансляторы (или размещать свои собственные оракулы/ретрансляторы), тем самым ограничивая риск для отдельных оракулов/ретрансляторов. Конечные пользователи должны быть уверены, что LayerZero, третьи стороны или само приложение запускают оракулы и ретрансляторы независимо друг от друга, без злого умысла.
В обоих подходах репутация участвующих сторонних организаций сдерживает злонамеренное поведение. Обычно это уважаемые лица в сообществе валидаторов и оракулов, и если они ведут себя злонамеренно, они рискуют нанести ущерб репутации и негативно повлиять на другие виды деятельности.
Дополнительные рекомендации по решениям AMP
При рассмотрении безопасности и удобства использования решения AMP нам также необходимо учитывать детали, выходящие за рамки базовой механики. Поскольку эти компоненты могут меняться со временем, мы не включали их в общее сравнение.
Целостность кода
Недавние взломы использовали ошибки кода, подчеркивая необходимость надежного аудита, вознаграждений за ошибки и разнообразных клиентских реализаций. Если все верификаторы (в экономической/оптимистической/репутационной безопасности) используют один и тот же клиент (программное обеспечение для проверки), это увеличивает зависимость от единой кодовой базы и снижает разнообразие клиентов. Например, Ethereum использует несколько клиентов исполнения, таких как geth, netermind, erigon, besu, akula. Несколько реализаций на разных языках могут увеличить разнообразие, при этом ни один клиент не будет доминировать в сети, что устраняет потенциальную единую точку отказа. Наличие нескольких клиентов также может помочь сохранить работоспособность в случае сбоя небольшого количества валидаторов/подписавших/легких клиентов из-за ошибки/атаки в конкретной реализации.
Установка и возможность обновления
Пользователям и разработчикам необходимо знать, могут ли валидаторы/наблюдатели присоединяться к сети без разрешения, иначе доверие будет скрыто субъектами, выбравшими разрешение. Обновления смарт-контрактов также могут создавать уязвимости, которые могут привести к атакам и, возможно, даже изменить предположения о доверии. Для снижения этих рисков могут быть реализованы различные решения. Например, в текущем экземпляре шлюз Axelar может быть обновлен, но для этого требуется одобрение автономного комитета (порог 4/8), однако в ближайшем будущем Axelar планирует потребовать от всех валидаторов коллективного утверждения любых обновлений шлюза. Основные контракты Wormhole можно обновлять, и ими можно управлять с помощью сетевой системы управления Wormhole. LayerZero полагается на неизменяемые смарт-контракты и неизменяемые библиотеки, чтобы избежать каких-либо обновлений, но новые библиотеки могут быть отправлены, децентрализованные приложения, которые устанавливают настройки по умолчанию, получат более новые версии, децентрализованные приложения, которые вручную устанавливают версию, должны установить ее на новую версию.
Максимальная извлекаемая ценность (MEV)
Различные блокчейны не синхронизируются общими часами и имеют разное время завершения. Таким образом, порядок выполнения и время в целевой цепочке могут варьироваться от цепочки к цепочке. В кроссчейн-мире трудно дать четкое определение MEV. Он вводит компромисс между живучестью и порядком исполнения. Упорядоченный канал обеспечивает доставку сообщений по порядку, но если сообщение истекает, канал будет закрыт. Другое приложение может предпочесть отсутствие упорядочения, но это не повлияет на доставку других сообщений.
Надежность исходной цепочки
В идеале решения AMP должны ждать завершения исходной цепочки, прежде чем передавать информацию о состоянии исходной цепочки одной или нескольким целевым цепочкам. Это гарантирует, что блоки в исходной цепочке вряд ли можно будет отменить или изменить. Однако многие решения обеспечивают обмен мгновенными сообщениями и делают доверительные предположения об окончательности, чтобы обеспечить наилучшее взаимодействие с пользователем. В этом случае, если исходная цепочка подвергается откату состояния после доставки сообщения и передачи актива моста, это может привести к таким ситуациям, как двойное расходование средств моста. Решения AMP могут управлять этим риском несколькими способами, например, устанавливая разные допущения об окончательности для разных цепочек в зависимости от того, насколько децентрализована цепочка, или путем поиска компромисса между скоростью и безопасностью. Мосты, использующие решения AMP, могут устанавливать ограничения на количество ресурсов, соединяемых до того, как исходная цепочка достигнет завершенности.
Тенденции и перспективы на будущее Настраиваемая и подключаемая безопасность
Чтобы лучше обслуживать различные варианты использования, решения AMP поощряются за предоставление большей гибкости разработчикам. Axelar представляет метод обеспечения масштабируемости обмена сообщениями и проверки без изменения логики прикладного уровня. HyperLane V2 представляет модули, которые позволяют разработчикам выбирать из нескольких вариантов, таких как экономичная безопасность, оптимистичная безопасность, динамическая безопасность и гибридная безопасность. CelerIM обеспечивает дополнительную оптимистическую безопасность в дополнение к экономической безопасности. Многие решения ждут предопределенного минимального количества подтверждений блока в исходной цепочке, прежде чем доставить сообщение. LayerZero позволяет разработчикам обновлять эти параметры. Мы ожидаем, что некоторые решения AMP по-прежнему будут предлагать большую гибкость, но эти варианты дизайна требуют некоторого обсуждения. Должны ли приложения иметь возможность настраивать свою безопасность, в какой степени и что произойдет, если архитектура приложений неоптимальна? Осведомленность пользователей об основных концепциях безопасности, вероятно, будет становиться все более важной. В конечном счете, мы предвидим агрегацию и абстракцию решений AMP, возможно, в виде какой-либо формы композиции или «дополнительной» безопасности.
Зрелость механизма «доверительного кода и математики»
В идеале на конечном этапе все межсетевые сообщения будут сведены к минимуму за счет использования доказательств с нулевым разглашением (ZK). Мы видели, как появляются подобные проекты, такие как Polymer Labs и Succinct Labs. Multichain также опубликовала технический документ zkRouter о совместимости с помощью доказательств ZK. Благодаря недавно анонсированной виртуальной машине Axelar разработчики могут использовать Interchain Amplifier для беспрепятственного установления новых подключений к сети Axelar. Например, когда для состояния Ethereum будут разработаны надежные легкие клиенты и доказательства ZK, разработчики смогут легко интегрировать их в сеть Axelar, чтобы заменить или улучшить существующие соединения. Celer Network анонсировала Brevis, кросс-цепочную платформу ZK для проверки данных, которая позволяет dApps и смарт-контрактам получать доступ, вычислять и использовать произвольные данные в нескольких блокчейнах. Celer реализовал ориентированный на пользователя актив zkBridge, используя схему легкого клиента ZK для кроссчейна между тестовой сетью Ethereum Goerli и тестовой сетью BNB Chain. LayerZero обсуждает в своей документации возможность добавления новых оптимизированных библиотек контрольных сообщений в будущем. Более новые проекты, такие как Lagrange, изучают агрегирование нескольких доказательств из нескольких цепочек источников, а Herodotus делает возможным хранение доказательств с доказательствами ZK. Однако этот переход потребует времени, так как этот подход трудно масштабировать в блокчейнах, которые полагаются на разные механизмы и структуры консенсуса.
ZK — относительно новая и сложная технология, которую трудно проверить, а текущие затраты на проверку и генерацию доказательств не оптимальны. Мы считаем, что в долгосрочной перспективе для поддержки масштабируемых межсетевых приложений на блокчейнах многие решения AMP, скорее всего, будут сочетать проверяемое программное обеспечение с доверенными людьми и организациями, потому что:
С помощью аудита и вознаграждения за ошибки можно свести к минимуму возможность эксплуатации кода. Со временем доверять этим системам станет легче, поскольку их история становится доказательством их безопасности.
Стоимость генерации ZK пруфов будет снижена. Благодаря дальнейшим исследованиям и разработкам в области ZKP, рекурсивных ZKP, агрегации доказательств, схем складывания и специализированного оборудования мы ожидаем, что временные затраты на создание и проверку доказательств существенно снизятся, что сделает этот подход более рентабельным.
Блокчейн станет больше поддерживать ZK. В будущем zkEVM сможет предоставлять краткие доказательства правильности выполнения, а легкие клиентские решения смогут легко проверять выполнение исходной цепочки и консенсус. На заключительном этапе Ethereum также планируется «zk-SNARK всего», включая механизм консенсуса.
Доказательство личности, репутация и личность
Безопасность сложной системы, такой как решение AMP, не может быть инкапсулирована одной единственной структурой и требует многоуровневого решения. Например, в дополнение к экономическим стимулам Axelar реализует механизм квадратичного голосования, чтобы предотвратить концентрацию права голоса среди подмножества узлов и способствовать децентрализации. Другие человеческие доказательства, репутация и личность также могут дополнять механизмы настройки и разрешения.
в заключение
В открытом духе Web3 мы можем увидеть плюралистическое будущее, в котором сосуществуют несколько подходов. На самом деле, приложение может выбрать использование нескольких решений взаимодействия либо с избыточностью, либо с выбором пользователем комбинации на основе компромиссов. Между маршрутами с «интенсивным трафиком» могут быть приоритетными решения «точка-точка», в то время как модели со ступицей могут доминировать в длинном хвосте цепочки. В конечном счете, мы, как сообщество пользователей, разработчиков и участников, будем формировать основную форму Интернета Web3.