В первой части серии углубленного изучения Fault Proof с Coinbase рассматривается смарт-контракт FPVM MIPS.sol и то, как он работает в системе Fault Proof System OP Stack.
Серия Fault Proof Deep-Dive — это результат сотрудничества команды Coinbase Blockchain Security (BlockSec) и OP Labs, целью которого является предоставление подробной информации обо всех основных компонентах Fault Proofs. Делясь этой информацией, мы надеемся побудить других узнать больше об архитектуре и технических аспектах Fault Proofs. Вместе мы можем двигаться к децентрализованному будущему блокчейнов OP Stack L2.
В этом сообщении блога мы рассмотрим смарт-контракт MIPS.sol для отказоустойчивой виртуальной машины (FPVM).
Что такое MIPS.sol?
Смарт-контракт MIPS.sol — это ончейн-реализация виртуальной машины (ВМ), которая включает в себя 32-битную архитектуру набора инструкций MIPS III (ISA) с прямым порядком байтов. Этот смарт-контракт является аналогом реализации MIPSEVM golang вне цепочки той же ISA. Вместе реализации ончейн и офчейн виртуальных машин составляют Cannon, первую FPVM OP.
Cannon — это экземпляр FPVM, который используется как часть игры по устранению неисправностей для оптимистичных объединенных блокчейнов L2, использующих стек OP. Сама игра по спорам является модульной, что позволяет использовать любую FPVM; однако Cannon в настоящее время является единственной реализованной FPVM и, следовательно, будет использоваться во всех спорах.
Поток управления защитой от сбоев
Сделав шаг назад, давайте кратко сосредоточимся на том, где находится контракт MIPS.sol в процессе Fault Proof.
На приведенной выше диаграмме, воссозданной на основе видео Fault Proof Walkthrough от Clabby, мы видим, что контракт MIPS.sol взаимодействует с двумя другими контрактами: FaultDisputeGame.sol и PreimageOracle.sol. FaultDisputeGame.sol — это развернутый экземпляр игры Fault Dispute Game для активного спора. PreimageOracle.sol — это развернутый экземпляр Oracle предварительного образа, который будет хранить предварительные изображения для всех игр-диспутов, использующих одну и ту же FPVM. Итак, в нашем случае существует один контракт PreimageOracle.sol для всех игр, использующих MIPS.sol в качестве FPVM.
Контракт MIPS.sol вызывается запущенным экземпляром спорной игры и вызывается только тогда, когда спорная игра достигает конечного узла в дереве перехода состояний, который в данный момент оспаривается. Листовой узел представляет собой одну инструкцию MIPS (в случае, если мы используем Cannon в качестве FPVM), которую затем можно запустить в цепочке. Учитывая предварительное состояние, которое является ранее согласованным состоянием L2 до этой инструкции, и состояние инструкции для выполнения в контракте MIPS.sol, игра по разрешению ошибок может определить истинное состояние после. Это истинное состояние публикации затем будет использоваться для разрешения игры со спором о неисправности путем сравнения состояния оспариваемой публикации на листовом узле с состоянием публикации, предложенным оппонентом в экземпляре игры со спором.
Поток управления смарт-контрактом
В смарт-контракте MIPS.sol есть единственная точка входа: функция Step(). Это функция, вызываемая запущенной игрой в споре, которая выполняет одну инструкцию MIPS в цепочке. На высоком уровне будут выполнены следующие операции:
-
Входные данные о состоянии выполнения виртуальной машины анализируются и загружаются в память. Эти данные генерируются аналогом Cannon golang, который участники игры запускают вне цепочки через OP-Challenger.
-
Ввод проверки памяти считывается и проверяется. Это доказательство использования памяти указывает на место в памяти, откуда должна быть загружена и запущена следующая инструкция MIPS.
-
Выполняется следующая инструкция MIPS. Большая часть логики контракта MIPS.sol отвечает за выполнение инструкции MIPS в соответствии со спецификацией MIPS III. При обработке инструкций MIPS единственной инструкцией, которая не соответствует строгой спецификации, является инструкция SYSCALL (системный вызов). Поведение системных вызовов уникально для операционной системы, и в случае MIPS.sol системные вызовы, которые можно выполнить, составляют лишь часть от общего числа системных вызовов. Основная цель системных вызовов — обработка чтения из контракта PreimageOracle.sol и имитация записи в контракт.
-
Результаты команды могут быть записаны обратно в регистр или в память. В случае записи в память второе доказательство памяти будет предоставлено в качестве входных данных игры-спора. Второе доказательство памяти должно совпадать с местом в памяти, в которое ожидается запись, и смарт-контракт MIPS.sol будет использовать новое значение и доказательство памяти для вычисления нового корня Меркла в памяти.
По завершении инструкции MIPS хэш состояния будет возвращен экземпляру спорной игры. Хэш состояния — это хеш keccak256 состояния выполнения виртуальной машины, где первый байт не соответствует хешу, а вместо этого переопределяется значением, указывающим состояние виртуальной машины. В спорной игре для разрешения спора будет использоваться хэш состояния и статус виртуальной машины.
Состояние контракта MIPS.sol
Как упоминалось ранее, контракт MIPS.sol взаимодействует с двумя другими смарт-контрактами: FaultDisputeGame.sol и PreimageOracle.sol. Контракт FaultDisputeGame.sol предоставляет текущее состояние выполнения виртуальной машины и до двух доказательств памяти. Контракт PreimageOracle.sol предоставляет предварительные изображения, которые MIPS.sol может использовать для определения истинного состояния L2. Содержимое, полученное в предварительном изображении, может включать в себя данные как из L1, так и из L2, которые могут быть заголовками блоков, транзакциями, квитанциями, состоянием контракта и т. д.
Вместе эти два контракта предоставляют всю необходимую информацию, необходимую для выполнения одной инструкции MIPS. Контракт MIPS.sol не хранит в памяти никакой информации о выполнении инструкции. Таким образом, контракт может использоваться в любой игре по разрешению споров без необходимости сброса каких-либо значений. Следовательно, контракт MIPS.sol гарантирует, что вычисленный корень Меркла на основе предоставленных доказательств памяти равен корню Меркла в состоянии выполнения виртуальной машины. В противном случае контракт FaultDisputeGame.sol должен обеспечить корректность предоставленной информации и действий участника спорной игры.
Документация для MIPS.sol
На этом мы завершаем подробное изучение смарт-контракта MIPS.sol. В дополнение к этому сообщению в блоге Coinbase создали подробную документацию, в которой подробно описана каждая функция смарт-контракта, перечислены инструкции MIPS, поддерживаемые FPVM, и многое другое. Проверьте это на сайте Fault Proofs - MIPS.sol | Документы по оптимизму .
Перевод оригинальной статьи от 15 февраля 2024 года
评论 (0)