Взаимодействие блокчейна Часть II: Доказательства консенсуса & Доверие минимизировано.

Введение

В первой части мы рассказали о концепции совместимости блокчейна и о том, что ее значение будет только возрастать по мере появления альтернативных L1, L2 и appchain. Большой объем капитала, перемещаемого по мостам, делает их привлекательными мишенями для хакеров, и в 2022 году мы увидели $2,5 млрд, потерянных из-за уязвимостей в мультисигналах и смарт-контрактах. Из всех эксплойтов, произошедших в том году, ошеломляющие 69% были связаны с мостами.

В основе этих потерь лежали сбои на шаге Verification of bridging, где механизм доверия, используемый для проверки достоверности транзакций, был подкреплен людьми & multisigs:

1. Мост Ронина был защищен мультисигом 5 из 9. 4 валидатора управлялись одной стороной и были скомпрометированы за один раз, что сделало 5-й валидатор легким триггером
2. Harmony Bridge был защищен мультисигмой 2 из 5, которая была взломана неизвестными методами, хотя есть подозрения, что это социальная инженерия.
3. Закрытые ключи Multichain представляли собой "мультисигму", которой фактически владел один человек.

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

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

Это очень много, поэтому давайте сначала определим, что мы подразумеваем под проверкой консенсуса блокчейна.

Проверка состояния исходного блокчейна / "консенсуса

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

Источник: Адаптировано из иллюстрации Ethereum EVM

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

Проверка консенсуса цепочки источников для обеспечения мостового соединения

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

1. Шаг 1. Проверка консенсуса блокчейна, т.е. того, что запрашиваемый нами блок является действительной частью мирового состояния исходной цепочки; и
2. Шаг 2. Убедитесь, что конкретная транзакция, т.е. транзакция "депозит", включена в блок (это можно доказать с помощью доказательства включения по Мерклу)

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

Вуаля, активы соединены.

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

Современные проблемы, связанные с проверкой консенсуса для наведения мостов

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

У Ethereum большой набор валидаторов - 700,000+, из которых более 21,000 валидаторов голосуют за блок в слоте. Для достижения окончательного результата блок должен получить голоса от ⅔ набора валидаторов, что примерно равно 450 000 голосов валидаторов. Проверка полного консенсуса будет означать проверку достоверности 450 000 подписей.

Менее громоздкий метод проверки консенсуса Ethereum включает в себя "легкий клиентский протокол". При этом используется комитет синхронизации (512 валидаторов, выбираемых случайным образом каждые 27,3 часа), чтобы подтвердить, что последний предложенный блок является действительным. Здесь проверка консенсуса означает проверку достоверности 512 агрегированных подписей.

В контексте моста смарт-контракт на цепочке назначения может использовать протокол light client и действовать в качестве "легкого клиента" на цепочке, чтобы проверить последнее состояние цепочки источника и убедиться, что "депозит" был сделан. Если он удовлетворен, смарт-контракт выпускает средства на цепочку назначения.

Проверка консенсуса исходной цепочки (на Ethereum) с помощью комитета синхронизации

Такой подход не очень практичен, поскольку проверка 512 агрегированных подписей непосредственно в смарт-контракте на цепи является непомерно дорогой без предварительной компиляции, учитывая, что валидаторы Ethereum используют подписи BLS.

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

...и именно здесь на помощь приходят доказательства консенсуса.

Решение: Консенсусные доказательства подписей комитета синхронизации

Доказательства с нулевым знанием появились как жизнеспособное решение, помогающее блокчейну вывести дорогостоящие вычисления за пределы цепи и проверить результат на цепи. Это позволяет мостовому смарт-контракту в цепочке назначения перенести дорогостоящие вычисления (например, проверку консенсуса в цепочке источника) на внецепочечного проверяющего с нулевыми знаниями:

1. Проверяющий проверит подпись и сгенерирует Доказательство Консенсуса - т.е. краткое доказательство с нулевым знанием, которое подтверждает, что данный блок является следующим действительным блоком, поскольку он получил ⅔ подтверждений синхрокомитета. Это доказательство подтверждает консенсус исходного блокчейна(Шаг 1. сверху).
2. После того, как достоверность блока доказана, мы можем доказать, что транзакция была частью этого блока(Шаг 2. сверху), используя доказательства включения Меркла. (В качестве альтернативы, доказательство с нулевым знанием может быть сгенерировано вне цепочки и проверено смарт-контрактом на цепочке назначения с той же целью).

Верификация с помощью zk-доказательств позволяет нам приблизиться к минимизации доверия к мостам

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

Использование доказательств консенсуса для проверки состояния блокчейна-источника - важный шаг на пути к минимизации доверия, но полагаться на легкий клиентский протокол & 512 валидаторов имеет некоторые ограничения (выделены в таблице ниже).

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

Поэтому некоторые команды работают над доказательством полного консенсуса ethereum, что является сложной задачей и предполагает проверку 450 000 подписей на момент написания статьи. Сделать это в условиях нулевого уровня знаний - нелегкий подвиг, но такие команды, как Polyhedra Network и Succinct, взяли на себя обязательство добиться этого.

Что может быть лучше, чем подтверждение 512 подписей? 450 000 подписей!

Недавно компания Polyhedra Network объявила о том, что ей удалось проверить 21 000 подписей валидаторов, подписывающих блок в определенном слоте в ZK, и в настоящее время она работает над проверкой всех 450 000 подписей. Более подробную информацию об их подходе и системе доказательств можно найти в статье zkBridge.

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

Риски использования доказательств с нулевым знанием

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

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

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

Команды, создающие

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

Среди них есть:

1. Polyhedra Network, которая разрабатывала и внедряла протокол zkBridge, и может быть использована для подтверждения состояния другой цепочки. В настоящее время zkBridge поддерживает работу с более чем 20 L1 и L2, включая Ethereum, Polygon, Binance Smart Chain, Optimism, Arbitrum. Polyhedra Network интегрировала в LayerZero как доказательства на основе синхронного комитета, так и доказательства на основе полного консенсуса, чтобы облегчить создание мостов на основе zk.
2. Компания Succinct Labs, разрабатывающая световые клиенты на основе zk, чтобы подтвердить состояние Ethereum и облегчить соединение между Gnosis Chain & Ethereum в качестве исходной цепи и Gnosis, Arbitrum, Avax, Binance Smart Chain, Optimism и Polygon в качестве цепей назначения.
3. Electron Labs, которая занимается созданием связующих подходов между Ethereum и экосистемой Cosmos
4. Polymer Labs стремится расширить возможности подключения IBC к различным цепочкам с помощью Polymer Hub, который реализует транспортную семантику IBC или семантику TAO для всех подключенных цепочек. Polymer Hub также позволяет использовать модель сетчатого взаимодействия, которая обладает улучшенными свойствами масштабирования по сравнению с моделями p2p или hub and spoke.
5. Lagrange Labs, которые будут использовать свои собственные государственные комитеты (защищенные повторным закладкой Eigenlayer) для подтверждения состояния блокчейн. Они нацелены на оптимистичных L2 (Arbitrum, Optimism, Base) и крупных L1 в качестве своего go-to-market.

Команды, работающие над доказательствами консенсуса

Заключение

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

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

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

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

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