Как известно, доказательства мошенничества широко используются в технических решениях в области блокчейна. Они возникли в сообществе Ethereum и были приняты известными решениями Ethereum Layer 2, такими как Arbitrum и Optimism. После подъема экосистемы Bitcoin в 2023 году Робин Линус предложил решение под названием BitVM, которое, основанное на существующих технологиях Bitcoin, таких как Taproot, сосредотачивается на доказательствах мошенничества и предоставляет новую модель безопасности для Bitcoin Layer 2 или мостов.

BitVM выпустил несколько теоретических версий, начиная с раннего BitVM0, который использовал логические вентильные схемы как примитивы, до более поздних версий, таких как BitVM2, который сосредотачивался на ZK Fraud Proofs и Groth16 верификационных схемах. Технические пути реализации, связанные с BitVM, постоянно развиваются и совершенствуются, привлекая внимание многих специалистов отрасли. Проекты, такие как Bitlayer, Citrea, BOB, Fiamma и Goat Network, все используют BitVM как одну из своих основных технологий, реализуя различные версии на основе этого фундамента.

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

Механизм интерактивного доказательства мошенничества Принципа Оптимизма

OutputRoot и StateRoot

Optimism - известный проект Optimistic Rollup, инфраструктура которого состоит из секвенсора (основные модули включают op-node, op-geth, op-batcher и op-proposer) и смарт-контрактов на цепочке Ethereum.

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

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

При упоминании термина «набор состояний» блокчейны на основе EVM обычно используют структуру данных, подобную дереву Меркля, для записи набора состояний, называемую деревом состояний мира. После выполнения транзакции состояние определенных счетов изменится, и дерево состояний мира также изменится, что приведет к изменению его конечного хэша. Ethereum называет конечный хэш дерева состояний мира StateRoot, который представляет изменения в наборе состояний.

Следующая схема иллюстрирует структуру stateRoot Ethereum. Как мы видим, балансы различных счетов, хэш кода, связанного с умными контрактными счетами, и другие данные агрегируются в World State Trie, из которого рассчитывается stateRoot.

Система учета и структура данных Optimism в целом согласуются с Ethereum, также используется поле StateRoot для представления изменений в наборе состояний. OP-последователь периодически загружает ключевое поле с названием OutputRoot в Ethereum, которое рассчитывается на основе StateRoot и двух других полей.

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

Виртуальная машина MIPS и Merkle-дерево памяти

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

Для проверки правильности OutputRoot on-chain с использованием смарт-контрактов самым простым методом будет реализация клиента OP node на цепи Ethereum с использованием тех же входных параметров, что и OP sequencer, выполнение той же программы и проверка соответствия вычисленного результата. Этот подход называется программой доказательства мошенничества. Хотя его относительно легко реализовать off-chain, на цепи Ethereum его очень сложно запустить из-за двух проблем:

1. Смарт-контракты на Ethereum не могут автоматически получать входные параметры, необходимые для доказательства мошенничества.

2. Предел газа блока Ethereum ограничен, и он не поддерживает высоко сложные вычислительные задачи. Таким образом, мы не можем полностью реализовать клиент узла OP on-chain.

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

Для второй проблемы команда разработчиков OP написала виртуальную машину MIPS на Solidity, чтобы реализовать некоторые функции клиента узла OP, достаточные для системы доказательства мошенничества. MIPS - это распространенная архитектура набора инструкций ЦП, а код OP-секвенсора написан на более высокоуровневых языках, таких как Golang/Rust. Мы можем скомпилировать программы Golang/Rust в программы MIPS и обработать их через виртуальную машину MIPS на цепочке Ethereum.

Команда разработчиков OP написала упрощенную программу на Golang для доказательства мошенничества, которая по сути имитирует модули в узле OP, выполняющие транзакции, генерирующие блоки и создающие OutputRoot. Однако эта упрощенная программа все еще не может «полностью выполниться». Другими словами, каждый блок OP содержит много транзакций. После обработки этой пакетной обработки транзакций генерируется OutputRoot. Хотя вы знаете, что OutputRoot блока определенной высоты неверен, было бы нереалистично запускать все транзакции в этом блоке на цепи, чтобы доказать, что соответствующий OutputRoot неверен. Более того, во время выполнения каждой транзакции последовательно обрабатывается серия опкодов MIPS. Было бы непрактично запускать всю эту серию опкодов на виртуальной машине MIPS, реализованной в цепочке, поскольку вычислительная нагрузка и расход газа были бы слишком большими.

(Принцип работы набора инструкций MIPS)

Для решения этой проблемы команда Optimism разработала интерактивную систему доказательства мошенничества, направленную на глубокий анализ потока обработки транзакций OP. Наблюдая за всем процессом вычисления OutputRoot, система определяет, на какой инструкции MIPS OP-секвенсора виртуальной машины MIPS произошла ошибка. Если ошибка подтверждается, то можно сделать вывод, что предоставленный секвенсором OutputRoot является недействительным.

Таким образом, проблема становится ясной: процесс упаковки транзакций OP-последователем в блоки может быть разбит на упорядоченную обработку большого количества описаний операций MIPS. После выполнения каждой операции MIPS хеш состояния виртуальной машины изменяется. Эти записи могут быть собраны в дерево Меркля.

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

В части реализации кода смарт-контракты на цепочке Ethereum, связанные с доказательством мошенничества, завершат окончательный процесс выполнения последней операции MIPS через функцию, называемую Step:

Параметры в вышеприведенной функции, _stateData и _proof, представляют зависимые данные для выполнения одного оператора MIPS, такие как состояние регистров виртуальной машины MIPS, хэш состояния памяти и т. д. Ниже показана диаграмма:

Мы можем ввести эти параметры виртуальной машины MIPS через _stateData и _proof, выполнить одну инструкцию MIPS on-chain и получить авторитетный результат. Если авторитетный результат, полученный on-chain, отличается от результатов, отправленных последователем, это указывает на то, что последователь является злонамеренным.

Мы обычно называем хэш _stateData как statehash, который можно грубо понимать как хэш всего состояния виртуальной машины MIPS. Среди нескольких полей в _stateData memRoot является самым гениальным дизайном. Как известно, во время выполнения программы используется большое количество памяти, и ЦП взаимодействует с данными по определенным адресам памяти путем чтения и записи. Поэтому, когда мы выполним операцию MIPS on-chain через функцию VM.Step, нам нужно предоставить данные с определенных адресов памяти в виртуальной машине MIPS.

ОС использует 32-битную архитектуру для виртуальной машины MIPS, и ее память содержит 2^27 адресов, которые могут быть организованы в 28-уровневое бинарное дерево Меркля. Листовые узлы на самом низком уровне нумеруются 2^27, при этом каждый лист записывает данные из определенного адреса памяти виртуальной машины. Хэш, рассчитанный из всех данных в листьях, является memRoot. Ниже показана структура дерева Меркля, которое записывает данные памяти виртуальной машины MIPS:

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

Интерактивное доказательство мошенничества

В предыдущем разделе мы рассмотрели вторую проблему, завершив выполнение операций MIPS on-chain и верификацию состояния виртуальной машины. Но как оппонент и последователь могут точно определить спорную инструкцию MIPS opcode?

Многие люди могли прочитать простые объяснения интерактивных доказательств мошенничества в Интернете и слышали о подходе бинарного поиска, лежащем в их основе. Команда OP разработала протокол под названием Игра Спора о Недостатке (FDG). Протокол FDG включает две роли: вызывающего и защитника.

Если мы обнаружим, что OutputRoot, представленный последователем on-chain, неверен, мы можем выступить в качестве вызывающего в FDG, а последователь - в качестве защитника. Чтобы помочь найти операцию MIPS opcode, которую необходимо обработать on-chain, протокол FDG требует, чтобы участники локально построили дерево Меркля, называемое GameTree, структура которого определена следующим образом:

Мы видим, что GameTree довольно сложен, с иерархической вложенной структурой, состоящей из дерева первого уровня и поддеревьев второго уровня. Иными словами, листовые узлы дерева первого уровня содержат поддерево.

Как упоминалось ранее, каждый блок, сгенерированный последователем, содержит OutputRoot, а листья первоуровневого дерева в GameTree представляют OutputRoots различных блоков. Испытуемый и защитник должны взаимодействовать в дереве Меркла, образованном OutputRoots, чтобы определить, чей OutputRoot блока находится в споре.

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

После многократного взаимодействия on-chain стороны в конечном итоге сосредотачиваются на точном оспариваемом операторе, определяя конкретный оператор MIPS, который должен быть выполнен on-chain.

На данном этапе мы завершили весь процесс интерактивного доказательства мошенничества. Для краткости, два основных механизма интерактивного доказательства мошенничества:

1. FDG (Fault Dispute Game) сначала находит операцию MIPS, которую необходимо выполнить on-chain, вместе с информацией о состоянии ВМ на тот момент;

2. Виртуальная машина MIPS, реализованная на цепочке Ethereum, выполняет опкод, приводя к конечному результату.

ZK доказательство мошенничества

Доказательство мошенничества ZK Как мы видим, традиционный подход к доказательству мошенничества включает в себя очень сложные взаимодействия, требующие многократных раундов в процессе FDG и повторного выполнения отдельных инструкций on-chain. Однако у этого решения есть несколько вызовов:

Несколько раундов взаимодействия должны быть запущены на цепи Ethereum, что приводит к десяткам взаимодействий, сопряженных с значительными затратами на газ. 2. Процесс интерактивного доказательства мошенничества занимает много времени, и после начала взаимодействия Rollup не может обрабатывать транзакции нормально. 3. Реализация конкретной виртуальной машины на цепи для повторения инструкций достаточно сложна и сопряжена с высокой сложностью разработки.

Для решения этих проблем Optimism представил концепцию ZK Fraud Proof. Основная идея заключается в том, что когда оппонент поднимает вызов, он указывает транзакцию, которую, по его мнению, необходимо повторно передать по цепочке. Rollup sequencer предоставляет ZK-доказательство для оспариваемой транзакции, которое затем проверяется смарт-контрактом на цепочке Ethereum. Если проверка прошла успешно, заключается, что при обработке транзакции ошибок не было, и Rollup-узел не виновен.

На диаграмме, Испытаниеотносится к стороне, которая выдвигает вызов, иЗащитникOP-секвенсор. В обычных условиях OP-секвенсор генерирует блоки на основе полученных транзакций и отправляет коммитменты состояния различных блоков в Ethereum. Эти коммитменты состояния можно просто рассматривать как хэш-значения блоков. Челленджер может оспорить на основе хэша блока. После принятия вызова Защитник генерирует доказательство ZK для демонстрации правильности результатов генерации блока. На диаграмме, Бонсайфактически является инструментом генерации доказательства ZK. По сравнению с интерактивными доказательствами мошенничества, основное преимущество доказательства мошенничества ZK заключается в том, что оно заменяет несколько раундов взаимодействия одним раундом генерации доказательства ZK и проверкой на цепи. Это значительно экономит время и снижает затраты на газ. Кроме того, в отличие от ZK Rollups, OP Rollups на основе доказательства мошенничества ZK не требуют генерации доказательств при каждом производстве блока. Вместо этого они временно генерируют доказательство ZK при вызове, что также снижает вычислительные затраты для узлов Rollup.

Концепция доказательства мошенничества ZK также применяется в BitVM2. Проекты, использующие BitVM2, такие как Bitlayer, Goat Network, ZKM и Fiama, реализуют программу верификации ZK Proof через скрипты Bitcoin, значительно упрощая размер программ, которые необходимо перенести на цепь. Из-за ограничений места в этой статье не будет дано дальнейшего описания этой темы. Следите за нашей предстоящей статьей о BitVM2, чтобы получить более глубокое понимание его пути внедрения!

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

1. Эта статья воспроизведена с [GodRealmX], авторские права принадлежат оригинальному автору [Шев и Ноа], если у вас есть возражения к перепечатке, пожалуйста, свяжитесь с Gate Learnкоманда, и команда обработает его как можно скорее в соответствии с соответствующими процедурами.

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

3. Другие языковые версии статьи переведены командой Gate Learn и не упоминаются в Gate.io, переведенная статья не может быть воспроизведена, распространена или использована в качестве плагиата.