В первой части мы рассказали о концепции совместимости блокчейна и о том, что ее значение будет только возрастать по мере появления альтернативных L1, L2 и appchain. Большой объем капитала, перемещаемого по мостам, делает их привлекательными мишенями для хакеров, и в 2022 году мы увидели $2,5 млрд, потерянных из-за уязвимостей в мультисигналах и смарт-контрактах. Из всех эксплойтов, произошедших в том году, ошеломляющие 69% были связаны с мостами.
В основе этих потерь лежали сбои на шаге Verification of bridging, где механизм доверия, используемый для проверки достоверности транзакций, был подкреплен людьми & multisigs:
Учитывая эти уязвимости, на этапе верификации гораздо лучше использовать методы с минимальным уровнем доверия, которые опираются на код и математику.
Именно здесь консенсусные доказательства могут стать потенциальным решением. Этот подход основан на проверке консенсуса цепочки источников в блокчейне и использовании доказательств нулевого знания для подтверждения действительности транзакции перед выдачей средств адресату.
Это очень много, поэтому давайте сначала определим, что мы подразумеваем под проверкой консенсуса блокчейна.
По своей сути блокчейн - это бухгалтерские книги, в которых записываются транзакции между счетами, ведущимися узлами, которые не доверяют друг другу. Поскольку в сети блокчейн существует множество узлов, проверяющих блокчейн, между этими проверяющими должно быть достигнуто соглашение о том, какой блок является самым последним добавленным блоком, т.е. они должны прийти к "консенсусу" относительно последнего состояния.
Источник: Адаптировано из иллюстрации Ethereum EVM
Надежная проверка консенсуса цепи источника на цепи назначения является ключевым мостом, потому что если Вы можете проверить последний блок цепи источника способом, минимальным с точки зрения доверия, Вы определяете последнюю "истину" и затем имеете возможность выполнить соответствующее действие на цепи назначения.
Проверка консенсуса цепочки источников для обеспечения мостового соединения
Для моста протокол должен определить, что транзакция 'deposit' на цепочке источника была совершена правильно. На практике это включает в себя проверку двух вещей:
После проверки обоих документов цепочка назначения может выдать активы пользователю.
Вуаля, активы соединены.
В теории это звучит просто, но сложность заключается в шаге 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.
Ключ к тому, чтобы сделать это возможным, - сделать шаг проверки вне цепи...
...и именно здесь на помощь приходят доказательства консенсуса.
Доказательства с нулевым знанием появились как жизнеспособное решение, помогающее блокчейну вывести дорогостоящие вычисления за пределы цепи и проверить результат на цепи. Это позволяет мостовому смарт-контракту в цепочке назначения перенести дорогостоящие вычисления (например, проверку консенсуса в цепочке источника) на внецепочечного проверяющего с нулевыми знаниями:
Верификация с помощью zk-доказательств позволяет нам приблизиться к минимизации доверия к мостам
После этих двух шагов смарт-контракт назначения может безопасно высвободить средства на цепочке назначения.
Использование доказательств консенсуса для проверки состояния блокчейна-источника - важный шаг на пути к минимизации доверия, но полагаться на легкий клиентский протокол & 512 валидаторов имеет некоторые ограничения (выделены в таблице ниже).
Ограничения, связанные с тем, что для проверки консенсуса необходимо полагаться на комитет по синхронизации
Поэтому некоторые команды работают над доказательством полного консенсуса ethereum, что является сложной задачей и предполагает проверку 450 000 подписей на момент написания статьи. Сделать это в условиях нулевого уровня знаний - нелегкий подвиг, но такие команды, как Polyhedra Network и Succinct, взяли на себя обязательство добиться этого.
Что может быть лучше, чем подтверждение 512 подписей? 450 000 подписей!
Недавно компания Polyhedra Network объявила о том, что ей удалось проверить 21 000 подписей валидаторов, подписывающих блок в определенном слоте в ZK, и в настоящее время она работает над проверкой всех 450 000 подписей. Более подробную информацию об их подходе и системе доказательств можно найти в статье zkBridge.
Как только мы сможем проверить полный консенсус Ethereum в режиме нулевого знания, проверка консенсуса других цепочек с меньшими наборами валидаторов в режиме нулевого знания должна быть относительно простой.
Хотя технология нулевых знаний & Consensus Proofs решает проблему человеческой ошибочности, обсуждение было бы неполным без признания некоторых рисков, возникающих при их использовании в бриджинге.
Технология "нулевого знания" быстро меняется, поскольку продолжают появляться новые алгоритмы и системы. Некоторые из этих реализаций не проверяются и могут содержать уязвимости, что делает их уязвимыми для потенциального использования при возникновении значительных стимулов. Более того, даже после аудита такие сложные криптографические системы могут содержать необнаруженные векторы атак, которые со временем будут выявлены и устранены, чтобы достичь зрелого, закаленного в боях состояния.
Более того, еще предстоит выяснить, при каком объеме транзакций затраты на создание и проверку доказательств с нулевым знанием станут достаточно амортизированными, чтобы считаться экономически эффективными.
В заключение мы расскажем о некоторых игроках, создающих решения в этой области. Несмотря на то, что у них несколько разные подходы и рынки сбыта, они расширяют границы возможностей мостов на основе zk и предвещают появление совместимости с минимальным уровнем доверия.
Среди них есть:
Команды, работающие над доказательствами консенсуса
Взаимозаменяемость - это основная часть инфраструктуры блокчейна. На первых этапах налаживания связей механизмы доверия были подкреплены мультисигмами и скомпрометированы зависимостью от людей. Сейчас мы начинаем двигаться в область мостов, защищенных криптографией и математикой, которые стали возможны благодаря применению доказательств с нулевым знанием в контексте мостов.
В этой части мы рассказали о том, как Доказательства Консенсуса помогают решить проблему перекрытия путем проверки последнего завершенного консенсуса источника блокчейна.
Однако эту технологию можно расширить, чтобы проверять исторический консенсус, что позволяет использовать более гибкие варианты использования межцепочечного взаимодействия, не ограничиваясь только мостами. И именно это мы рассмотрим в третьей части нашей серии статей о совместимости: Доказательства хранения &, какие варианты использования они открывают.
В первой части мы рассказали о концепции совместимости блокчейна и о том, что ее значение будет только возрастать по мере появления альтернативных L1, L2 и appchain. Большой объем капитала, перемещаемого по мостам, делает их привлекательными мишенями для хакеров, и в 2022 году мы увидели $2,5 млрд, потерянных из-за уязвимостей в мультисигналах и смарт-контрактах. Из всех эксплойтов, произошедших в том году, ошеломляющие 69% были связаны с мостами.
В основе этих потерь лежали сбои на шаге Verification of bridging, где механизм доверия, используемый для проверки достоверности транзакций, был подкреплен людьми & multisigs:
Учитывая эти уязвимости, на этапе верификации гораздо лучше использовать методы с минимальным уровнем доверия, которые опираются на код и математику.
Именно здесь консенсусные доказательства могут стать потенциальным решением. Этот подход основан на проверке консенсуса цепочки источников в блокчейне и использовании доказательств нулевого знания для подтверждения действительности транзакции перед выдачей средств адресату.
Это очень много, поэтому давайте сначала определим, что мы подразумеваем под проверкой консенсуса блокчейна.
По своей сути блокчейн - это бухгалтерские книги, в которых записываются транзакции между счетами, ведущимися узлами, которые не доверяют друг другу. Поскольку в сети блокчейн существует множество узлов, проверяющих блокчейн, между этими проверяющими должно быть достигнуто соглашение о том, какой блок является самым последним добавленным блоком, т.е. они должны прийти к "консенсусу" относительно последнего состояния.
Источник: Адаптировано из иллюстрации Ethereum EVM
Надежная проверка консенсуса цепи источника на цепи назначения является ключевым мостом, потому что если Вы можете проверить последний блок цепи источника способом, минимальным с точки зрения доверия, Вы определяете последнюю "истину" и затем имеете возможность выполнить соответствующее действие на цепи назначения.
Проверка консенсуса цепочки источников для обеспечения мостового соединения
Для моста протокол должен определить, что транзакция 'deposit' на цепочке источника была совершена правильно. На практике это включает в себя проверку двух вещей:
После проверки обоих документов цепочка назначения может выдать активы пользователю.
Вуаля, активы соединены.
В теории это звучит просто, но сложность заключается в шаге 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.
Ключ к тому, чтобы сделать это возможным, - сделать шаг проверки вне цепи...
...и именно здесь на помощь приходят доказательства консенсуса.
Доказательства с нулевым знанием появились как жизнеспособное решение, помогающее блокчейну вывести дорогостоящие вычисления за пределы цепи и проверить результат на цепи. Это позволяет мостовому смарт-контракту в цепочке назначения перенести дорогостоящие вычисления (например, проверку консенсуса в цепочке источника) на внецепочечного проверяющего с нулевыми знаниями:
Верификация с помощью zk-доказательств позволяет нам приблизиться к минимизации доверия к мостам
После этих двух шагов смарт-контракт назначения может безопасно высвободить средства на цепочке назначения.
Использование доказательств консенсуса для проверки состояния блокчейна-источника - важный шаг на пути к минимизации доверия, но полагаться на легкий клиентский протокол & 512 валидаторов имеет некоторые ограничения (выделены в таблице ниже).
Ограничения, связанные с тем, что для проверки консенсуса необходимо полагаться на комитет по синхронизации
Поэтому некоторые команды работают над доказательством полного консенсуса ethereum, что является сложной задачей и предполагает проверку 450 000 подписей на момент написания статьи. Сделать это в условиях нулевого уровня знаний - нелегкий подвиг, но такие команды, как Polyhedra Network и Succinct, взяли на себя обязательство добиться этого.
Что может быть лучше, чем подтверждение 512 подписей? 450 000 подписей!
Недавно компания Polyhedra Network объявила о том, что ей удалось проверить 21 000 подписей валидаторов, подписывающих блок в определенном слоте в ZK, и в настоящее время она работает над проверкой всех 450 000 подписей. Более подробную информацию об их подходе и системе доказательств можно найти в статье zkBridge.
Как только мы сможем проверить полный консенсус Ethereum в режиме нулевого знания, проверка консенсуса других цепочек с меньшими наборами валидаторов в режиме нулевого знания должна быть относительно простой.
Хотя технология нулевых знаний & Consensus Proofs решает проблему человеческой ошибочности, обсуждение было бы неполным без признания некоторых рисков, возникающих при их использовании в бриджинге.
Технология "нулевого знания" быстро меняется, поскольку продолжают появляться новые алгоритмы и системы. Некоторые из этих реализаций не проверяются и могут содержать уязвимости, что делает их уязвимыми для потенциального использования при возникновении значительных стимулов. Более того, даже после аудита такие сложные криптографические системы могут содержать необнаруженные векторы атак, которые со временем будут выявлены и устранены, чтобы достичь зрелого, закаленного в боях состояния.
Более того, еще предстоит выяснить, при каком объеме транзакций затраты на создание и проверку доказательств с нулевым знанием станут достаточно амортизированными, чтобы считаться экономически эффективными.
В заключение мы расскажем о некоторых игроках, создающих решения в этой области. Несмотря на то, что у них несколько разные подходы и рынки сбыта, они расширяют границы возможностей мостов на основе zk и предвещают появление совместимости с минимальным уровнем доверия.
Среди них есть:
Команды, работающие над доказательствами консенсуса
Взаимозаменяемость - это основная часть инфраструктуры блокчейна. На первых этапах налаживания связей механизмы доверия были подкреплены мультисигмами и скомпрометированы зависимостью от людей. Сейчас мы начинаем двигаться в область мостов, защищенных криптографией и математикой, которые стали возможны благодаря применению доказательств с нулевым знанием в контексте мостов.
В этой части мы рассказали о том, как Доказательства Консенсуса помогают решить проблему перекрытия путем проверки последнего завершенного консенсуса источника блокчейна.
Однако эту технологию можно расширить, чтобы проверять исторический консенсус, что позволяет использовать более гибкие варианты использования межцепочечного взаимодействия, не ограничиваясь только мостами. И именно это мы рассмотрим в третьей части нашей серии статей о совместимости: Доказательства хранения &, какие варианты использования они открывают.