TL;DR

Введение:

В этой статье представлена интерпретация технического описания BitVM, объясняющая подход BitVM: Данные не обязательно должны быть на цепочке изначально; они публикуются и хранятся вне цепочки, а на блокчейне хранится только Обязательство.

Пересылаемый оригинал статьи Название: Упрощенная интерпретация BitVM: как проверять доказательства мошенничества на блокчейне BTC (выполняя EVM или другие опкоды VM)

Предисловие: В настоящее время Bitcoin Layer 2 стал трендом, и десятки проектов самоидентифицируются как "Bitcoin Layer 2". Многие из них, называющие себя "Rollups", заявляют, что они используют подход, предложенный в технической статье BitVM, позиционируя BitVM как важную часть экосистемы Биткойна.

Однако большинство существующей литературы о BitVM не объясняет принципы его работы в непрофессиональных терминах. Эта статья, основанная на нашем прочтении 8-страничного технического описания BitVM и после ознакомления с ресурсами, связанными с Taproot, MAST trees и Bitcoin Script, предлагает упрощенное резюме. Чтобы облегчить понимание, мы изменили некоторые выражения по сравнению с теми, которые встречаются в документе BitVM, предполагая, что читатель обладает некоторыми знаниями об уровне 2 и может понять основную идею "доказательств мошенничества".

Предварительную концепцию BitVM можно кратко изложить в нескольких предложениях: она устраняет необходимость в данных на цепочке, изначально публикуя и храня данные вне цепочки, при этом на блокчейне хранится только Обязательство. В случае возникновения проблем или доказательства мошенничества на цепочку вносятся только необходимые данные, чтобы продемонстрировать их связь с Обязательством на блокчейне. Затем сеть BTC проверяет данные на цепочке на предмет наличия проблем и того, не занимался ли производитель данных (узел, обрабатывающий транзакции) вредоносными действиями. Этот подход соответствует принципу "бритвы Оккама" - "Сущности не следует умножать без необходимости" (если она может быть вне цепи, пусть будет вне цепи).

Основной текст: Так называемая схема проверки доказательства мошенничества в блокчейне BTC, основанная на BitVM, если говорить простыми словами:

1.Во-первых, компьютер/процессор - это система ввода-вывода, состоящая из большого количества схем логических ворот. Одна из основных идей BitVM - использовать Биткойн-скрипт для моделирования эффектов "вход-выход" схем логических ворот. Пока схемы логических ворот могут быть смоделированы, теоретически можно получить машину Тьюринга, выполняющую все вычислимые задачи. Это означает, что если у Вас достаточно ресурсов и рабочей силы, Вы можете собрать команду инженеров, чтобы сначала смоделировать схемы логических затворов с помощью рудиментарного кода Bitcoin Script, а затем использовать огромное количество схем логических затворов для реализации функциональных возможностей EVM или WASM.

(Этот снимок экрана сделан в образовательной игре: "Turing Complete", основное содержание которой заключается в создании полноценного процессора CPU, особенно с использованием логических схем, таких как NAND-гейты).

Некоторые сравнивают подход BitVM с созданием процессора M1 в игре "Minecraft" с помощью схем из красного камня. Или это сродни строительству Эмпайр Стейт Билдинг в Нью-Йорке из блоков LEGO.

(Говорят, что кто-то потратил год на создание "процессора" в игре "Minecraft").

1. Итак, зачем использовать Bitcoin Script для моделирования EVM или WASM? Разве это не очень громоздко? Причина в том, что большинство решений второго уровня для Биткойна часто выбирают поддержку языков высокого уровня, таких как Solidity или Move, в то время как единственным языком, который в настоящее время может работать непосредственно на блокчейне Биткойна, является Bitcoin Script. Этот язык примитивен, состоит из кучи уникальных опкодов и не является полным по Тьюрингу.

(Пример кода Bitcoin Script)

Если Bitcoin Layer 2 нацелен на проверку доказательств мошенничества на Уровне 1, как решения Уровня 2 в Ethereum, такие как Arbitrum, то для того, чтобы в значительной степени унаследовать безопасность BTC, ему необходимо напрямую проверять "спорную транзакцию" или "спорный опкод" на блокчейне BTC. Это означает, что опкоды языка Solidity / EVM, используемые Уровнем 2, должны быть заново выполнены на блокчейне Биткойна. Задача сводится к следующему:

Использование Bitcoin Script, родного, но рудиментарного языка программирования Биткойна, для достижения эффекта EVM или других виртуальных машин.

Поэтому, с точки зрения принципов компиляции, подход BitVM переводит опкоды EVM / WASM / JavaScript в опкоды Bitcoin Script, при этом схемы логических ворот служат промежуточным представлением (IR) между "опкодами EVM -> опкодами Bitcoin Script".

(В техническом документе BitVM обсуждается общий подход к выполнению определенных "спорных инструкций" в блокчейне Биткойна)

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

1. Давайте обсудим еще одну основную концепцию, упомянутую в техническом описании BitVM, а именно "Интерактивные доказательства мошенничества", очень похожие на те, что использует Arbitrum.

Интерактивные доказательства мошенничества включают в себя термин, известный как assert. Как правило, инициатор Уровня 2 (часто в роли секвенсора) публикует утверждение на Уровне 1, заявляя, что определенные данные транзакции и результаты перехода состояний действительны и не содержат ошибок.

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

Для этой спорной инструкции операции (OP Code) необходимо выполнить ее непосредственно на Уровне 1 вместе с ее входными параметрами и подтвердить выходной результат (узлы Уровня 1 сравнивают вычисленный ими выходной результат с выходным результатом, ранее опубликованным автором предложения). В Arbitrum это известно как "Одноэтапные доказательства мошенничества". (В интерактивном протоколе доказательства мошенничества от Arbitrum двоичный поиск используется для быстрого нахождения спорной инструкции и результата ее выполнения, а затем одноэтапное доказательство мошенничества отправляется на Уровень 1 для окончательной проверки).

Продолжение следует:

1. Процесс интерактивен, обе стороны действуют по очереди. Одна сторона сегментирует исторические данные, содержащиеся в блоке Rollup Block, а другая сторона указывает, какой сегмент данных является проблемным. Это сродни бинарному методу (в действительности, это процесс постепенного сужения диапазона, N/K).

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

3. Контракт ChallengeManager только проверяет, является ли "сегмент данных", полученный в результате разбиения исходных данных, действительным.

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

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

Ссылки:

Бывший технический посол Arbitrum объясняет структуру компонентов Arbitrum (часть 1)

(Интерактивная блок-схема доказательства мошенничества от Arbitrum, объяснение относительно приблизительное)

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

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

Arbitrum реализует вышеупомянутые эффекты с помощью контрактов на Ethereum, а BitVM стремится достичь аналогичной функциональности, используя Bitcoin Script для реализации временных блокировок, мультисиг и других возможностей.

4.После обсуждения "Интерактивных доказательств мошенничества" и "Одношаговых доказательств мошенничества" мы поговорим о деревьях MAST и доказательствах Меркла. Ранее мы уже упоминали, что в решении BitVM огромное количество данных транзакций и схем логических затворов, обрабатываемых вне цепи на Уровне 2, не попадает непосредственно в цепь. Только минимальное количество схем данных/логических ворот включается в цепь, когда это необходимо. Однако нам нужен способ доказать, что эти данные, которые изначально были вне цепи, а теперь должны быть внесены в цепь, не сфабрикованы. Именно здесь вступает в игру концепция обязательств в криптографии, и доказательство Меркла - это одна из форм таких обязательств.

Во-первых, давайте поговорим о деревьях MAST. Полное название MAST - Merkelized Abstract Syntax Trees, которые представляют собой преобразование AST (Abstract Syntax Trees) из области принципов компилятора в Merkle Trees. Итак, что же такое AST? Проще говоря, это древовидная структура данных, которая разбивает сложную команду на ряд базовых операций с помощью лексического анализа.

(Примером дерева AST может служить разбиение простых вычислений типа "x=2, y=x*3" на коды операций и данные, лежащие в основе. )

Таким образом, дерево MAST - это результат применения мерклизации к дереву AST, поддерживающий доказательства Меркла. Одним из преимуществ деревьев Меркла является их способность эффективно "сжимать" данные. Например, если Вы хотите при необходимости опубликовать сегмент данных из дерева Меркла на блокчейне BTC, при этом убедившись, что этот сегмент данных действительно существует в дереве Меркла, а не выбран произвольно, что Вам делать?

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

(Взаимосвязь между доказательством/разветвлением Меркле и корнем)

Таким образом, нет необходимости хранить полное дерево MAST в блокчейне BTC; достаточно заранее раскрыть его Корень в виде Обязательства. При необходимости достаточно представить сегмент данных + доказательство Меркла/разветвление. Это значительно сокращает объем данных на цепи, гарантируя, что данные на цепи действительно существуют в дереве MAST. Более того, раскрытие только небольшой части сегментов данных + Merkle Proof на блокчейне BTC, а не всех данных, может значительно усилить защиту конфиденциальности.

Ссылки:Сохранение данных и защита от мошенничества: Почему Plasma не поддерживает смарт-контракты

(Пример дерева MAST)

В решении BitVM все схемы логических ворот выражаются с помощью Биткойн-скриптов, организованных в массивное дерево MAST. Нижние листья этого дерева, обозначенные на диаграмме как Content, соответствуют схемам логических ворот, реализованным в скрипте Bitcoin. Предложивший уровень 2 часто публикует корень дерева MAST в блокчейне BTC, при этом каждое дерево MAST ассоциируется с транзакцией, включающей все его входные параметры/коды операций/схемы логических ворот. Это в какой-то степени похоже на то, как Arbitrum's Proposer публикует Rollup Blocks на блокчейне Ethereum.

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

(Источник:https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca）

1. До этого момента самые важные аспекты решения BitVM были в основном рассмотрены. Хотя некоторые детали могут оставаться несколько неясными, мы полагаем, что читатели смогут уловить суть и основные моменты BitVM. Что касается "обязательства по битовым значениям", упомянутого в документе, то оно призвано предотвратить присвоение Предложителем как 0, так и 1 входным значениям логического затвора, когда его оспаривают и заставляют проверить схему логического затвора на цепи, создавая тем самым двусмысленность и путаницу.

В общем, схема BitVM начинается с использования Bitcoin-скрипта для выражения схем логических затворов, затем использует эти схемы для выражения опкодов EVM/других виртуальных машин, которые, в свою очередь, выражают поток обработки любой данной инструкции транзакции, и, наконец, организует их в дерево Меркла/MAST-дерево. Если поток обработки транзакций, представленный таким деревом, очень сложен, он может легко превысить 100 миллионов листьев, поэтому очень важно минимизировать пространство блоков, занимаемое обязательствами, и объем, затрагиваемый доказательствами мошенничества.

Хотя для одношагового доказательства мошенничества требуется лишь очень небольшой объем данных и скрипт логических ворот на цепи, полное дерево Меркла должно храниться вне цепи в течение длительного времени, чтобы к нему можно было в любой момент обратиться, если кто-то его оспорит. Каждая транзакция на уровне 2 генерирует большое дерево Меркла, и можно представить себе, какое давление на узлы оказывают вычисления и хранение данных. Большинство людей, возможно, не захотят запускать узлы (однако, такие исторические данные можно постепенно уничтожить, и сеть B^2 специально вводит доказательства zk-хранения, подобные Filecoin, чтобы стимулировать узлы хранения сохранять исторические данные в течение длительного времени).

Однако оптимистичные сворачивания, основанные на доказательствах мошенничества, не нуждаются в большом количестве узлов, поскольку их модель доверия равна 1/N, что означает, что пока один из N узлов честен и может инициировать доказательство мошенничества в критический момент, сеть уровня 2 будет безопасной.

Тем не менее, при разработке решений уровня 2 на базе BitVM возникает множество проблем, таких как:

1) Теоретически, для дальнейшего сжатия данных нет необходимости проверять опкоды непосредственно на Уровне 1. Поток обработки опкодов может быть дополнительно сжат в zk-доказательство, позволяя претендентам оспаривать шаги проверки zk-доказательства. Это может значительно сократить объем данных в цепи. Однако конкретные детали разработки могут быть очень сложными.

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

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

1. Эта статья перепечатана с сайта[Geek Web3], Forward Оригинальное название "A minimalist interpretation of BitVM: How to verify fraud proof on BTC chain (execute the operation code of EVM or other VM)", авторские права принадлежат оригинальному автору [Faust & Misty Moon].
   . Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.