Глубокое погружение в игры по разрешению споров и их роль в обнаружении сбоев в первой системе Fault Proof Stack OP Stack.

Не случайно одним из самых интересных компонентов системы защиты от сбоев (FPS) OP Stack являются игры-споры. В предыдущих публикациях о FPS было описано, как модульность стека OP позволила отделить программу Fault Proof Program (FPP) от Fault Proof Virtual Machine (FPVM), чтобы обеспечить возможность компоновки следующего уровня и эффективные параллельные обновления обоих компонентов. То же самое, почти в геометрической прогрессии, справедливо и для игр в спорах.

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

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

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

Сами игры-споры основаны на двух фундаментальных свойствах:

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

2. Решение : в каждой игре есть механизм окончательной проверки или аннулирования корневого утверждения.

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

Это особый тип игры для споров и первая игра, созданная на основе протокола споров OP Stack. В этой игре игроки ходят взад и вперед, разделяя след выполнения до тех пор, пока не достигнут отдельных шагов. После того, как bisection достиг фиксации состояния в отдельных инструкциях трассировки, он FaultDisputeGameвыполняет один шаг инструкции в цепочке с использованием общей виртуальной машины. Функция перехода состояния виртуальной машины, которую мы назовем T , может быть чем угодно, если она соответствует форме T(s, i) -> s' , где s = согласованное предварительное состояние, i = входные данные перехода состояния. , и s' = состояние публикации.

Для нашей первой полной реализации универсального VM в игре пополам мы реализовали один контекст потока MIPS поверх EVM для выполнения отдельных инструкций в пределах трассировки выполнения, сгенерированной Cannonи op-program.

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

Утверждения существуют в позициях в двоичном дереве. Позиция показывает, к какой инструкции относится утверждение. Позиции представляют собой обобщенные индексы, которые можно определить как2^{depth} + index_at_depth.

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

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

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

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

Игра может быть решена после того, как закончатся шахматные часы для всех претензий, минимальный срок - 3,5 дня. Каждая заявка в игре является корнем отдельной дополнительной игры . Подигры представляют собой группы DAG с глубиной 1. Все дочерние элементы (которые сами являются корнями подигр), указывающие на корень, являются его противоположностями, и подигра может быть решена только в том случае, если все ее дочерние подигры также были решены. Корень подигры можно считать противодействующим только в том случае, если один или несколько его дочерних элементов разрешены и не противодействуются, и это свойство распространяется вверх вплоть до корневого утверждения игры.

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

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

Если вы заинтересованы в изучении правил игры с более простым интерфейсом, вот как играть:

Клонируйте монорепозиторий Optimism, установите зависимости и создайте двоичные файлы devnetlocations/cannon/op-program.

Необходимые зависимости:

1. foundry

2. Инструментарий Голанга

3. Докер

git clone git@github.com:ethereum-optimism/optimism.git && \\
    cd optimism && \\
  pnpm i && \\
  (cd packages/contracts-bedrock && forge install) && \\
  make cannon-prestate && \\
  make devnet-allocs

Запустите игру «Алфавит»:

cd op-challenger && make alphabet

1. Перейдите по адресу https://disputify.optimism.io/ или запустите интерфейс визуализации локально, клонировав https://github.com/clabby/dispute-viz , и введите адрес прокси- FaultDisputeGameсервера, развернутого в вашей локальной сети разработчиков, указанной выше.

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

Существует множество способов создания игр-споров, преследующих одну и ту же цель. Мы надеемся, что когда FPS OP Stack будет развернут на OP Goerli, строители в нашей экосистеме получат удовольствие и проявят творческий подход к созданию своих собственных игр-споров. Каждая созданная игра по разрешению споров может сыграть роль в социальной децентрализации стека OP и предоставить участникам экосистемы варианты разрешения споров по любому заданному требованию относительно части информации.

Перевод оригинальной статьи от 28 сентября 2023 г.

https://blog.oplabs.co/dispute-games/