Энергичное развитие многоцепочечной экологии делает межцепочечные протоколы незаменимыми. Однако из-за большого количества активов, заложенных кросс-чейн-мостом, и того факта, что логика кросс-чейн-протокола более сложна, чем логика общего свопа, возможность атаки кросс-чейн-протокола со стороны хакеров становится все больше и больше. К концу 2022 года убытки, вызванные проблемами безопасности кросс-чейн мостов, достигли более 2 миллиардов долларов США.Среди них кросс-чейн мосты, потерявшие сотни миллионов долларов, включают Ronin Network, Horizon, BNB Chain, Wormhole. , Номад и т. д.
Межцепной мост в основном решает проблему межсетевого взаимодействия. Большое количество инцидентов безопасности межсетевых мостов в прошлом показали, что нынешнее решение межсетевого взаимодействия по-прежнему имеет огромные возможности для оптимизации. Недавно Multichain запустила zkRouter, не требующее доверия межсетевое решение, основанное на доказательстве с нулевым разглашением.
Multichain — ведущий проект в области кросс-чейн. В конце 2021 года он получил инвестиции в размере 60 миллионов долларов США под руководством Binance и в настоящее время занимает первое место по доле кросс-чейн-рынка. Голосование по межсетевому управлению Uniswap возникло и раньше, но Curve, король DEX стейблкоинов, уже давно использует AnyCall от Multichain для завершения распределения стимулов LP в нескольких цепочках. В таблице 1 приведено сравнение соответствующих данных текущих крупных кросс-чейн проектов.
Таблица 1. Сравнение соответствующих данных текущих крупных кросс-чейн проектов
(Источник данных: https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148)
В этой статье основное внимание будет уделено анализу последнего не требующего доверия продукта zkRouter, выпущенного Multichain на базе ZKP, а также проведено сравнение с другими отличными кросс-чейн-проектами ZK на рынке.
1. ZKP стал лучшим решением проблемы ненадежного кроссчейна.
Характеристики суверенной зоны блокчейна затрудняют внутрисетевым контрактам получение точной информации вне цепочки, и им приходится полагаться на третьи стороны для передачи активов и сообщений между цепочками для обеспечения безопасности активов и надежности передачи информации. между контрактами в разных цепочках.надежно. Это похоже на роль оракула. Это означает, что транзакции между кроссчейнами должны основываться на доверии к сторонним ретрансляционным кроссчейнам или оракулам, а ретрансляционным кроссчейнам и оракулам иногда трудно полностью доверять. Поэтому вопрос о том, как получить информацию вне сети с помощью ненадежных средств, стал важной темой исследований.
Независимо от того, достигается ли межцепочная ретрансляция посредством ретрансляционных сетей, оракулов или цепочек, частичная или даже полная децентрализация может быть достигнута, но недоверие не может быть достигнуто. В настоящее время безопасность приложений, созданных с помощью основных кросс-чейн мостов на рынке, поручена третьим лицам. появление настоящей кроссчейн-экосистемы. В каком-то смысле важнейшей особенностью перекрестного моста должно быть достижение полной недоверчивости. Если кросс-чейновые сервисы могут быть построены без доверия, а легкий клиент в цепочке сможет независимо проверять и напрямую использовать информацию о цепочке источников, это будет в значительной степени способствовать дальнейшему развитию многоцепной экологии и широкомасштабному использованию. собственных многоцепных приложений.
Появление технологии ZKP и кросс-чейн моста, построенного с помощью технологии ZKP, станет лучшим решением для достижения надежной кроссчейн.
2. Межсетевая недоверчивость на основе ZKP
Отличный кросс-чейн протокол должен, во-первых, быть безопасным, во-вторых, иметь богатую экосистему и, наконец, иметь низкие межсетевые затраты и высокую скорость. Следовательно, отличный кросс-чейн протокол должен обладать такими характеристиками, как высокая степень доверия, высокая степень децентрализации, хорошая масштабируемость, высокая скорость кросс-чейна и низкая стоимость. Большинство людей согласны с этой точкой зрения, но я думаю, что с этой точкой зрения могут возникнуть некоторые проблемы. Если межсетевой протокол обеспечивает полную надежность, нужно ли нам еще учитывать, является ли он децентрализованным?
Многие кросс-чейн-проекты теперь используют выделенную цепочку для реализации кросс-чейн-операций.Этот подход делает кросс-чейн-соглашение более децентрализованным, но не обеспечивает недоверия. Децентрализация по-прежнему означает, что инициаторы кросс-чейн размещают свою кросс-чейн-безопасность в децентрализованной сети. Но то, чего должны достичь межсетевые протоколы, — это отсутствие доверия, а не децентрализация, потому что как только недоверие в межцепочных операциях будет достигнуто, проблема децентрализации больше не будет существовать. Только представьте, когда ЗКП, сгенерированный реле, может быть легко проверен самими пользователями, нужно ли еще обсуждать необходимость децентрализации?
В процессе кросс-чейн операций доверие к консенсусу исходной цепочки и консенсусу целевой цепочки является необходимым условием существования кросс-чейн операций. Кроме того, доверие к любой организации снижает безопасность ваших активов. Лучше всего добиться недоверия в межсетевых операциях, а отсутствие доверия в конечном итоге является предположением, не требующим доверия. Для достижения не требующей доверия кросс-цепочки лучший способ — использовать ZKP для создания базового механизма доверия протокола межсетевого взаимодействия и достижения не требующей доверия кросс-цепочки.
Межцепочные мосты, построенные на основе ZKP, обычно выполняют три логические роли:
1. Генератор Proof, его функция — наблюдать за состоянием исходной цепочки и использовать данные исходной цепочки для генерации ZKP.
2. Релейер, доставляет ZKP в целевую цепочку.
3. Облегченный клиент он-чейн. Лайт-клиент он-чейн также является верификатором и может самостоятельно завершить проверку ZKP.
Доказывающим и ретранслятором может быть один и тот же человек или разные люди, поскольку именно легкий клиент в сети решает, следует ли применять ZKP. Таким образом, эта установка не создает никаких проблем с безопасностью. Кроме того, в ZKP, пока есть честный узел ретрансляции, можно гарантировать нормальную работу протокола.
Все текущие протоколы взаимодействия ZK в основном вращаются вокруг Ethereum. Некоторые реализуют взаимодействие между Ethereum и другими гетерогенными цепочками, а некоторые хотят завершить взаимодействие между Ethereum и его изоморфными цепочками. Однако независимо от того, в какой цепочке реализовано взаимодействие между Ethereum и Ethereum, необходимо сгенерировать консенсусный сертификат Ethereum и реализовать проверку консенсусного сертификата легким клиентом Ethereum в других цепочках.
3. zkRouter и другие протоколы совместимости ZK.
Межсетевой протокол, построенный на ZKP, может идеально обеспечить надежность. Наиболее типичным протоколом на данный момент, вероятно, является zkRouter, запущенный Multichain.
1. Как zkRouter реализует кроссчейн на основе ZKP
Будь то межсетевые активы, межсетевые сообщения или межсетевое взаимодействие, они, по сути, делают одно и то же, то есть пользователь инициирует действие в исходной цепочке через смарт-контракт и проверяет действие в целевой цепочке. . Пока это действие можно проверить без доверия, оно может поддерживать настоящую нативную мультицепочку и достигать истинной совместимости мультичейнов.
В официальном документе zkRouter описывается доставка сообщений Ethereum в Fantom, которая включает в себя следующие шаги:
Сначала транзакция происходит в исходной цепочке (транзакцию можно проверить по хешу заголовка блока и пути дерева Меркеля);
Ретранслятор отправляет транзакцию легкому клиенту в целевой цепочке;
Легкий клиент в сети проверяет транзакцию.
Увидев это, у читателей возникнут два вопроса:
Что такое легкие клиенты и легкие клиенты в сети?
Где ЗКП отражается в вышеуказанных шагах и какова роль ЗКП?
(1) Легкий клиент и легкий клиент в сети
С момента запуска протокола LayerZero концепция легких клиентов, похоже, стала объектом злоупотреблений.Существует разница между сверхлегкими узлами в протоколе LayerZero и легкими клиентами в обычном понимании. Сверхлегкие узлы LayerZero только проверяют, соответствуют ли данные, передаваемые реле, данным, передаваемым оракулом, и не проверяют напрямую транзакции в цепочке. В обычном смысле легкие клиенты напрямую проверяют транзакции в цепочке.
Давайте начнем с того, как проверить транзакцию в сети, и выясним, что такое настоящий легкий клиент и легкий клиент в сети.
Что такое легкий клиент? Многие транзакции будут происходить в Ethereum одновременно, и многие транзакции произошли в истории.Без легкого клиента пользователи должны синхронизировать все данные транзакций всех блоков, чтобы проверить транзакцию, что, очевидно, невозможно.
В сети Биткойн каждый блок имеет заголовок блока, который содержит указатель на предыдущий блок и корень Меркла хеша всех транзакций в текущем блокчейне. Указатель на предыдущий блок может гарантировать, что данные транзакции в предыдущем блоке не были подделаны, а дерево Меркла в каждом блоке содержит все транзакции в текущем блоке, а значение корневого хэша может проверять все текущие транзакции. Как показано на рисунке 1. Это гарантирует, что вся информация о транзакциях, содержащаяся в текущих и исторических блоках, не будет подделана. Эфириум наследует этот метод проверки. Заголовок блока сети Ethereum также содержит корень Меркла и указатель на предыдущий блок, который можно использовать для проверки любого типа хранящихся данных.
Рисунок 1. Схематическая диаграмма древовидной структуры Меркла сети Биткойн.
Как показано на рисунке 1, выполните хеш-операции над транзакциями L1, L2, L3 и L4 соответственно и получите Hsh0-0=хеш(L1), Hash0-1=хэш(L2), Hash1-0=хэш(L3), Хэш1 -1=хэш(L4).
Для получения корневого хэша (Top Hash) лёгкому клиенту достаточно вычислить:
Hash0 = хэш (Hsh0-0, Hash0-1)
Хэш1 = хеш (Хеш1-0, Хэш1-1)
Верхний хэш = хэш (Hash0, hash1)
Операция хеширования может быть только односторонней, то есть Y=Hash(X) может быть вычислена только через X, но X не может быть вычислена через Y. Таким образом, легкому клиенту необходимо только синхронизировать значение корневого хэша в блоке и запросить хеш-данные полного пути узла для проверки подлинности транзакции.
Если легкий клиент хочет проверить транзакции L1. Если легкий клиент имеет корневое значение хеш-функции, он может проверить транзакцию L1, запросив значения Hash1 и Hash0-1 из полного узла. Конкретный метод:
1. Вычислить Хэш0-0;
2. На основе Hash0-1, синхронизированного всем узлом, и Hash0-0, рассчитанного на предыдущем шаге, можно вычислить Hash0=hash(Hash0-0, Hash0-1).
3. На основе Hash1, синхронизированного всем узлом, и Hash0, рассчитанного на предыдущем шаге, вычислите корневой хеш RootH = хэш (Hash0, Hash1) и сравните, равен ли вычисленный корневой хэш RootH Top Hash, синхронизированному легким клиентом. . Если они одинаковы, это доказывает, что транзакция L1 действительно находится в цепочке и не была изменена. Именно так весь блокчейн реализует доверенные легкие клиенты.
Вышеописанный процесс демонстрирует, как легкий клиент проверяет транзакции в цепочке. Итак, если легкий клиент исходной цепочки может быть реализован в целевой цепочке, то есть легкий клиент в цепочке, можно ли будет проверить транзакции исходной цепочки в целевой цепочке?
Только представьте, в конкретном применении кроссчейна ключевая трудность заключается в том, что транзакции, происходящие в исходной цепочке, не могут быть проверены без доверия в целевой цепочке, а должны передаваться через третью сторону, что незаметно снижает безопасность перекрестные цепи. . Если вы используете смарт-контракт для реализации легкого клиента в другой цепочке, вы можете проверять транзакции, которые произошли в исходной цепочке в целевой цепочке, достигая не требующей доверия перекрестной цепочки.
(2) Почему ончейн-легким клиентам необходимо использовать технологию ZKP?
В предыдущем разделе объяснялось, как проверять транзакции исходной цепочки через легкий клиент в цепочке, который может полностью обеспечить перекрестную цепочку. Так зачем же использовать технологию ZKP?
Легкая проверка клиента включает в себя большое количество вычислений в процессе генерации консенсуса. Если эти вычисления будут завершены в цепочке, это потребует чрезвычайно высоких комиссий за газ и не поддается обобщению. Технология доказательства с нулевым разглашением может передавать большое количество вычислений в процессе генерации консенсуса, которые будут надежно выполняться вне цепочки, тем самым генерируя краткие результаты доказательства, которые можно проверить в цепочке с меньшими затратами газа.
Всякий раз, когда речь идет о реле, пользователи будут чувствовать, что их подозревают в централизованности и недостаточной надежности. Однако ретранслятор в кросс-чейн мосте, реализованном на базе ZKP, отвечает только за ретрансляцию сообщений и не отвечает за проверку сообщений.Работу по проверке выполняет легкий клиент целевой цепочки. Строгие математические и криптографические доказательства могут гарантировать, что легкий клиент целевой цепочки сможет завершить проверку и добиться надежности.
(3) Как zkRouter использует технологию ZKP для достижения перекрестной цепочки
Межсетевое решение, реализованное zkRouter, подробно описано в его официальном документе, но в настоящее время на рынке нет документа, объясняющего его. Чтобы понять zkRouter, необходимы некоторые базовые знания.
В настоящее время в области применения доказательств с нулевым разглашением существует несколько типичных алгоритмов полного доказательства с нулевым разглашением. ) и zk-Stark (краткие неинтерактивные аргументы знания с нулевым разглашением). Масштабируемый прозрачный аргумент знания с нулевым разглашением, масштабируемый прозрачный аргумент знания с нулевым разглашением). Размер файла ZKP, созданного zk-Stark, составляет около 200 КБ, а размер файла ZKP, созданного zk-Snark, — около 192 байт. Файл ZKP, созданный zk-Stark, слишком велик. Если zk-Stark используется для достижения перекрестной цепочки, газ, потребляемый целевой цепочкой, будет очень большим, поэтому он не имеет экономических преимуществ в конкретных приложениях. ZKP, созданный с помощью zk-snark, широко используется в блокчейне благодаря своим преимуществам отсутствия взаимодействия, быстрой генерации доказательств и коротких результатов доказательства. В настоящее время большинство кросс-цепных мостов ZK на рынке используют zk-Snark. вариант технологии zk-Snark, который zkRouter также использует zk-Snark.
Протокол zkRouter в основном состоит из четырех шагов.
1. Первоначальная настройка (Setup)
Чтобы легкий клиент целевой цепочки завершил проверку сертификата ZKP исходной цепочки, он должен иметь состояние консенсуса предыдущего блока исходной цепочки.Состояние консенсуса блокчейна имеет непрерывность, то есть текущий результат консенсуса блока равен на основе предыдущего блока. Обновления консенсусного результата блока. Таким образом, легкий клиент целевой цепочки должен сначала получить текущий статус консенсуса исходной цепочки, прежде чем он сможет проверить правильность последующего консенсуса блоков.
Легкому клиенту целевой цепочки в начале нужны начальные данные Initial_data. Эти данные включают в себя начальную высоту блока, хэш заголовка блока и т. д. Этот первоначальный параметр необходимо установить только один раз, и данные будут автоматически обновляться по мере возникновения межцепочного поведения.
2. Генерация консенсусного доказательства (Proof Gen)
Этот шаг происходит при определенном поведении между цепочками. Когда исходная цепочка генерирует новый блок, целевая цепочка должна синхронизировать новую информацию. Эта новая информация включает в себя статус предыдущего блока, выбор узла-производителя блока, легальность узла подписи и т. д. Для механизмов консенсуса немгновенной окончательности также необходимо установить определенное количество избыточных блоков, чтобы избежать потерь, вызванных форками. Затем ретранслятор вычисляет и генерирует оффчейн ZKP с помощью оффчейн технологии ZKP и синхронизирует его с целевой цепочкой.
3. Проверка консенсусного доказательства (ProofVerify)
После того как краткий ZKP отправлен ретранслятором в целевую цепочку, ZKP необходимо проверить. Эту часть работы выполняет легкий клиент в цепочке. После прохождения проверки возвращается результат проверки, а информация о состоянии консенсуса исходной цепочки обновляется в целевой цепочке.
4. Вызов контракта взаимодействия (InterOperCall)
Когда легкий клиент целевой цепочки проходит проверку консенсуса исходной цепочки (включая транзакции исходной цепочки), участники могут инициировать вызовы межсетевого взаимодействия контрактов для завершения межцепочного взаимодействия.
Например, при межцепочном обмене любой участник отправляет TXS, соответствующий транзакции исходной цепочки, и соответствующий путь сертификации дерева Меркеля. На основе существующей консенсусной информации исходной цепочки легкого клиента контракт может легко проверить подлинность сделка.
В официальном документе Multichain есть довольно много инструкций по реализации кросс-чейна Ethereum->Fantom ZK. Шаги аналогичны описанному выше процессу и здесь не будут повторяться.
2. Другие основные кроссчейн-решения ZK
В настоящее время многие команды работают над разработкой перекрестно-цепного моста ZK. Поскольку генерация ZKP тесно связана с консенсусом исходной цепочки, а разные цепочки достигают консенсуса по-разному и используют разные алгоритмы подписи, на практике методы, используемые легкими клиентами в разных цепочках, которые будут реализованы командой проекта, будут тоже может быть разным, но основной алгоритм в основном аналогичен алгоритму zkRouter.
（1）Электронные лаборатории
Electronlabs реализовала двусторонний перекрестный мост между тестовой сетью Ethereum и тестовой сетью Near, что показывает, что Electronlabs не только внедрила легкий клиент Ethereum в Near, но также внедрила легкий клиент Near в сети Ethereum. Cosmos поддерживает Ed25519 [Ed25519 стал предпочтительной схемой подписи для таких блокчейн-экосистем, как Cosmos, NEAR, Solana и т. д. Проверка консенсуса блокчейна требует проверки большого количества подписей Ed25519 (подписей валидаторов). Поэтому требуется краткая проверка пакета подписей Ed25519. ] алгоритм подписи, но Ethereum не поддерживает этот алгоритм. Таким образом, проверка подписей Ed25519 в Ethereum требует некоторой дополнительной работы.
Кроме того, алгоритм Ed25519 не поддерживает агрегированные подписи, поэтому Eletronlabs использует рекурсивный метод для реализации проверки большого количества алгоритмов Ed25519. Проверка подписей создает большие схемы, поэтому ключевой вопрос заключается в том, как эффективно и экономично проверить подписи Ed25519 из любого блокчейна в Cosmos SDK в цепочке Ethereum. Решение Electronlabs заключается в создании zk-Snark, который генерирует подтверждение действительности подписи вне цепочки и проверяет это доказательство только в цепочке Ethereum.
Судя по текущим результатам Electronlabs, он добился определенного прогресса в развертывании гетерогенных цепочек, включая алгоритм подписи публичной цепи серии Cosmos, то есть Ed25519. В будущем способность публичной цепи расширять алгоритм подписи Ed25519 должна будь сильным.
（2）Краткий
Succinct также запустил только односторонний кросс-чейн-мост ZK. Разница в том, что он запустил кросс-чейн-мост ZK для Goerli->Gnosis, Optimism, Polygon, Avalanch и других тестовых сетей. Единственная цепочка поставок — Goerli.
Самая сложная часть кросс-чейна ZK — настроить схему в соответствии с консенсусом исходной цепочки. Над клиентом целевой цепочки не будет слишком много работы по разработке. Таким образом, запуск Succinct кросс-чейн мостов ZK на Goerli->Gnosis, Optimism, Polygon, Avalanch и других тестовых сетях фактически находится на том же этапе, что и запуск только одностороннего кросс-чейн моста. Succinct также использует схему zk-Snark, ее базовая схема мало чем отличается от общей схемы, поэтому я не буду здесь вдаваться в подробности.
Основная цель Succinct — расширить сеть второго уровня вокруг Ethereum. Судя по текущему прогрессу, если в будущем он сможет завершить перекрестную цепочку Гнозиса, Оптимизма, Полигона, Лавины->Гёрли, у него появится много места для воображения. Однако, учитывая, что генерация исходной цепочки ZKP требует большого количества настроек схемы и консенсус сильно варьируется, эта часть работы является наиболее трудоемкой частью реализации кросс-цепочки ZK, и Succinct еще не завершил ее.
（3）ноль.фундамент
Нил реализовал проверку статуса тестовой сети Mina в тестовой сети Ethereum и тестовой сети Polygon, но не реализовал проверку статуса тестовой сети Ethereum и тестовой сети Polygon в тестовой сети Mina. , с точки зрения прогресса, Nil и другие кроссчейн-проекты ZK В том же эшелоне.
Однако проект nil.foundation получил инвестиции от Starkware и Mina, ведущих организаций на пути ZK, и его техническая мощь очевидна. Кроме того, Нил открыл исходный код продукта zkLLVM, который призван помочь разработчикам компилировать ZKP с использованием языков высокого уровня, что значительно снижает входной барьер для разработчиков. С помощью этого инструмента разработчики могут сосредоточиться на проектировании схем, используя знакомый им язык, вместо того, чтобы попасть в ловушку изучения предметно-ориентированного языка DSL. Компиляция схем с нулевым разглашением часто требует предметно-ориентированных языков и наборов инструментов и занимает много времени.
（4）Геродот
В официальном описании Геродота используется межцепной мост, реализованный «MPC+легкий клиент+ZKP», с использованием оптимистичного метода MPC для проверки сообщений, передаваемых ретрансляторами. Но поскольку любой ретранслятор может передать сгенерированный ZKP в целевую цепочку, проверка выполняется легким клиентом целевой цепочки. Если вам все же нужна надежная сеть MPC, добавление ZKP не будет иметь особого смысла: конечно, ее тестовая сеть еще не запущена, и конкретный план еще не озвучен участником проекта.
（5）Многогранники
Polyhedra в настоящее время является перекрестным мостом с большинством онлайн-тестовых сетей, в том числе Goerli, BNB Chain Testnet, Polygon Testnet, Fantom Testnet и Avalanche Testnet. В настоящее время Polyhedra запускает кросс-чейн NFT. Пользователи могут генерировать кросс-чейн NFT через Polyhedra, а затем использовать кросс-чейн NFT-мост для кросс-чейна. Polyhedra получила поддержку в размере 10 миллионов долларов от таких организаций, как Binance Labs, Polychain Capital и других.
Однако после анализа и тестирования мы обнаружили, что тестовая сеть этого проекта не использовала ZKP, а легкий клиент не проверял дерево Меркла.Подробности следующие.
Адрес исходной цепочки тестовой транзакции:
https://mumbai.polygonscan.com/tx/0xc89904563b9f26a2eaeae5da91e87f6c86a8a2ebc33ca9d23a02b9ffb0e58aca
Адрес тестовой целевой цепочки:
https://testnet.bscscan.com/tx/0xbcbe3f47ae9b2d17c38d0ee4271669690e5c5049b2dd150c90ad50efbaa9848b
Адрес промежуточного вложенного контракта:
https://testnet.bscscan.com/address/0x7b95cf4cefdd218017e0e0e4da99f3b2c6f9e2a5
Последний вызов проверяет адрес контракта дерева Меркла:
https://testnet.bscscan.com/address/0x3BBd3ECa3C1bA24603f8C8EC247f225fb629a40B
Рис. 2. Код контракта, связанного с многогранниками.
Код контракта показан на рисунке 2. Проверка хэш-заголовка напрямую возвращает true. Не существует технологии ZK, которая бы не использовалась, и хеш-заголовок не проверялся, поэтому предполагается корректность межсетевых сообщений. Судя по контракту на тестовую сеть, мы не видим ее прогресса, но, конечно, продолжим уделять внимание динамике ее тестовой сети.
4. Перспективы развития кроссчейн проектов на базе ZKP
В настоящее время кроссчейн ZK стал горячей точкой в отрасли, и существует множество сопутствующих решений.Будущая конкуренция, вероятно, будет вращаться вокруг следующих аспектов.
1. Обеспечение контракта. Хотя многие кросс-чейн-решения ZK прилагают все усилия для достижения уровня доверия, ZKP обеспечивает лишь базовую техническую архитектуру. Базовая техническая архитектура стабильна, но по-прежнему трудно избежать проблем безопасности, которые могут возникнуть при написании и работе смарт-контрактов.
2. Двунаправленное развертывание нескольких цепочек. Прогресс в этом направлении пока не ясен. Если какой-либо межцепочный мост сможет возглавить реализацию многоцепочного двунаправленного развертывания, это станет большим конкурентным преимуществом.
3. Является ли это ненадежным кросс-цепным мостом ZK. Из приведенного выше обсуждения читатели могут обнаружить, что наиболее важным преимуществом кросс-цепного моста ZK является то, что он может реализовать не требующую доверия кросс-цепочку. Если он не может реализовать не требующую доверия кросс-цепочку, Chain, то тогда приложения ZKP не будут иметь большого значения в области кросс-чейнов.
5. Резюме
Мы сравнили несколько известных проектов в кросс-чейне ZK по параметрам прогресса тестовой сети, поддержки Non-EVM, надежности продукта, технических возможностей команды и того, стоит ли им доверять, как показано в таблице 2.
Таблица 2. Сравнение нескольких текущих крупных проектов рельсовых путей zk с перекрестными цепями
Как видно из Таблицы 2, в настоящее время несколько крупных кросс-чейн проектов zk находятся, по сути, в зачаточном состоянии, и технические решения примерно одинаковы. Тем не менее, полная ненадежность ZKP в теории позволит реализовать кросс-чейн на основе недоверия ZKP в будущем, что будет иметь большее значение для содействия развитию многоцепной экологии, многоцепной вселенной и собственных многоцепочечных приложений. .
Согласно дорожной карте, объявленной Multichain, с момента рождения Anyswap было два решения: одно — кросс-чейновое решение на основе MPC, а другое — решение на основе ZKP. Что касается zkRouter, разработанного Multichain, я думаю, есть несколько моментов, на которые стоит обратить внимание:
1.Multichain имеет глубокий опыт в области межсетевых технологий. Multichain уже много лет активно участвует в кросс-чейн-бизнесе и имеет глубокий технический опыт. Исходя из этого, мы можем ожидать, что zkRouter от Multichain добьется большего прогресса в кросс-чейн-треке ZK. После того, как тестовая сеть zkRoutr будет подключена к сети, пользователи также смогут испытать zkRouter на себе. Конечно, поскольку продукт находится на стадии POC, обычным пользователям все еще сложно получить прямой опыт использования без доверия, включая скорость кросс-цепочки, комиссии за кросс-чейн и другие показатели, которых zkRouter может достичь в будущем. Это содержание все еще нуждается в изучении и оценке большего числа экспертов с более профессионального уровня и точки зрения.
2. Крупный экологический партнер. Multichain тесно сотрудничает с тысячами мультичейн-проектов, что является преимуществом, которого нет у других кросс-чейн протоколов. Таким образом, как только zkRouter выйдет на практическую стадию, с помощью огромной экосистемы Multichain, zkRouter, вполне вероятно, станет сильным конкурентом следующего поколения кроссчейнов.