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

Un análisis profundo de los juegos de disputas y el papel que desempeñarán en la detección de fallas en el primer sistema a prueba de fallas del OP Stack.

No es casualidad que uno de los componentes más divertidos en el Sistema a Prueba de Fallas (FPS) del OP Stack sean sus juegos de disputa. Publicaciones anteriores sobre el FPS han detallado cómo la modularidad del OP Stack hizo posible desacoplar el Programa a Prueba de Fallas (FPP) de la Máquina Virtual a Prueba de Fallas (FPVM) para permitir una componibilidad de siguiente nivel y actualizaciones eficientes paralelizadas en ambos componentes. Lo mismo es cierto, en un grado casi exponencial, para los juegos de disputa.

En esta publicación, exploraremos el papel que desempeñarán los juegos de disputa en la detección descentralizada de fallas dentro del ecosistema Superchain, cómo se construyó el juego de disputa a prueba de fallas, sobre el protocolo de disputa y las posibilidades que surgen gracias a la extensibilidad del protocolo de disputa.

Si buscas adentrarte en detalles más minuciosos sobre los juegos de disputa, compartí una versión mucho más extensa de esta publicación en mi blog personal hace unas semanas.

Un juego de disputa es un primitivo central en el protocolo de disputa. Modela una máquina de estados simple y se inicializa con un compromiso de 32 bytes con respecto a cualquier información cuya validez pueda ser objeto de disputa. Contienen una función para resolver este compromiso como verdadero o falso, y la definición de esta función queda a cargo del implementador del primitivo. La primera implementación de un juego de disputa en el OP Stack, el FaultDisputeGame, es sin permisos debido a que su función de resolución se determina a partir del resultado de la ejecución de un programa a prueba de fallas en una máquina virtual emulada.

Los juegos de disputa en sí mismos se basan en dos propiedades fundamentales:

1. Compatibilidad de incentivos: El sistema penaliza las afirmaciones falsas y recompensa las verdaderas para garantizar una participación justa.

2. Resolución: Cada juego tiene un mecanismo para validar o invalidar de manera definitiva la afirmación raíz.

En el protocolo de disputa, se pueden crear, gestionar y actualizar diferentes tipos de juegos de disputa a través de la DisputeGameFactory. Esto abre la puerta a características innovadoras, como sistemas de prueba agregados y la posibilidad de expandir el protocolo para disputar cosas más allá del estado de L2, como un FaultDisputeGame orientado a la verificación binaria en cadena.

Este es un tipo específico de juego de disputa y el primer juego construido en el protocolo de disputa del OP Stack. En este juego, los jugadores van de un lado a otro dividiendo un rastro de ejecución hasta llegar a pasos individuales. Después de que la bisección ha alcanzado compromisos con el estado en las instrucciones individuales del rastro, el FaultDisputeGame ejecuta un solo paso de instrucción en cadena utilizando una máquina virtual genérica. La función de transición de estado de la VM, a la que llamaremos T, puede ser cualquier cosa, siempre y cuando se adhiera al formato T(s, i) -> s', donde s = el estado previamente acordado, i = las entradas de transición de estado y s' es el estado posterior.

Para nuestra primera implementación completa de la VM genérica en el juego de bisección, hemos implementado un único contexto de hilo MIPS encima de la EVM para ejecutar instrucciones individuales en un rastro de ejecución generado por Cannon y el op-program.

Los reclamos representan un compromiso con el estado de la VM en la parte trasera en una instrucción dada. Estas pueden ser verdaderas o falsas, y la verdad se determina después de la fase de resolución. Si no se refutan, se asume que las reclamaciones son verdaderas.

Los reclamos existen en posiciones en un árbol binario. La posición representa a qué instrucción está relacionado el reclamo. Las posiciones son índices generalizados, que pueden definirse como 2^{depth} + index_at_depth.

Los jugadores tienen un límite de tiempo para realizar movimientos. El juego es sin permisos, lo que permite a cualquiera unirse. Cada lado comienza con 3.5 días en su reloj, lo que suma un tiempo total de juego de 7 días. En el caso de que se cree un nuevo camino o se haga una afirmación en una posición que ya ha recibido una afirmación, se hereda el tiempo del reloj del abuelo.

Los jugadores realizan bisecciones hasta que las afirmaciones se comprometen con el estado de una sola instrucción de la máquina virtual (VM). Luego ejecutan esa instrucción en cadena para verificar o refutar las afirmaciones. Los movimientos pueden ser ataques (que desafían una afirmación anterior) o defensas (acuerdos con una afirmación anterior). La defensa se realiza cada vez que un jugador está de acuerdo con el hash de la afirmación que está observando (lo que significa que el estado de las dos partes es el mismo en la instrucción dada), pero no está de acuerdo con el resultado final que están tratando de impulsar en función del acuerdo relativo de la afirmación observada con la afirmación raíz.

En los nodos hoja del árbol de posiciones, cada afirmación se compromete al estado en una sola instrucción de la VM. El único movimiento que queda es ejecutar esa instrucción de la VM para probar o refutar las afirmaciones anteriores.

Si el paso de instrucción confirma el estado posterior esperado, la afirmación queda sin refutar. Si hay un estado posterior inesperado o un código de salida, la afirmación anterior es refutada.

El juego puede resolverse después de que los relojes de ajedrez para todas las afirmaciones se hayan agotado, con un mínimo de 3.5 días. Cada afirmación dentro del juego es la raíz de su propio Subjuego. Los subjuegos son DAG con una profundidad de 1. Todos los hijos (que son raíces de subjuegos en sí mismos) que apuntan a la raíz son refutaciones de esta, y el subjuego solo puede resolverse si todos sus subjuegos hijos también se han resuelto. Una raíz de subjuego solo se considera refutada si uno o más de sus hijos se han resuelto y no han sido refutados, y esta propiedad se propaga hacia arriba hasta la raíz de afirmación del juego.

La presencia de un jugador honesto, asumiendo que todos sus movimientos se han agotado, siempre dará como resultado que el juego se resuelva favorablemente para su visión del rastro, ya sea que la afirmación raíz sea honesta o deshonesta. Las afirmaciones deshonestas siempre pueden ser refutadas por cualquier parte, aunque siempre solo existe una afirmación correcta que se puede hacer, ya que no se permiten duplicados de hashes de afirmación en la misma posición en el mismo subjuego.

https://blog.oplabs.co/content/media/2023/09/subgame_rez.mp4

Para aquellos curiosos, también hay una herramienta de visualización para el FaultDisputeGame sobre un seguimiento de ejecución simulado que tiene solo 16 instrucciones. Esta simulación utiliza una VM separada de la secuencia de hilos MIPS, la AlphabetVM, que simplemente devuelve la siguiente letra del alfabeto cuando se le da una letra como entrada.

Si estás interesado en explorar las reglas del juego con un backend más ligero, aquí tienes cómo jugar:

Clona el monorepo de Optimism, instala las dependencias y crea los binarios de devnet allocations / cannon / op-program.

Dependencias requeridas:

1. foundry

2. Conjunto de herramientas Golang

3. Docker

   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
   

   Ejecuta el juego de alfabeto:

cd op-challenger && make alphabet

1. Ve a https://disputify.optimism.io/ o ejecuta la interfaz de visualización localmente clonando https://github.com/clabby/dispute-viz e ingresa la dirección del proxy FaultDisputeGame implementado en tu devnet local arriba.

En un juego de bisección, todos los mecanismos descritos anteriormente trabajan juntos para crear un sistema que recompensa el comportamiento honesto y contrarresta eficazmente las afirmaciones deshonestas.

Hay muchas, muchas formas de construir juegos de disputas que logren el mismo objetivo. Esperamos que cuando el Sistema a Prueba de Fallas del OP Stack se despliegue en OP Goerli, los desarrolladores en nuestro ecosistema se diviertan y sean creativos al construir sus propios juegos de disputa. Cada juego de disputa creado puede desempeñar un papel en la descentralización social del OP Stack y brindar a los participantes del ecosistema opciones cuando se trata de cómo se resuelven las disputas sobre una determinada afirmación acerca de una pieza de información.

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

Un análisis profundo de los juegos de disputas y el papel que desempeñarán en la detección de fallas en el primer sistema a prueba de fallas del OP Stack.

No es casualidad que uno de los componentes más divertidos en el Sistema a Prueba de Fallas (FPS) del OP Stack sean sus juegos de disputa. Publicaciones anteriores sobre el FPS han detallado cómo la modularidad del OP Stack hizo posible desacoplar el Programa a Prueba de Fallas (FPP) de la Máquina Virtual a Prueba de Fallas (FPVM) para permitir una componibilidad de siguiente nivel y actualizaciones eficientes paralelizadas en ambos componentes. Lo mismo es cierto, en un grado casi exponencial, para los juegos de disputa.

En esta publicación, exploraremos el papel que desempeñarán los juegos de disputa en la detección descentralizada de fallas dentro del ecosistema Superchain, cómo se construyó el juego de disputa a prueba de fallas, sobre el protocolo de disputa y las posibilidades que surgen gracias a la extensibilidad del protocolo de disputa.

Si buscas adentrarte en detalles más minuciosos sobre los juegos de disputa, compartí una versión mucho más extensa de esta publicación en mi blog personal hace unas semanas.

Un juego de disputa es un primitivo central en el protocolo de disputa. Modela una máquina de estados simple y se inicializa con un compromiso de 32 bytes con respecto a cualquier información cuya validez pueda ser objeto de disputa. Contienen una función para resolver este compromiso como verdadero o falso, y la definición de esta función queda a cargo del implementador del primitivo. La primera implementación de un juego de disputa en el OP Stack, el FaultDisputeGame, es sin permisos debido a que su función de resolución se determina a partir del resultado de la ejecución de un programa a prueba de fallas en una máquina virtual emulada.

Los juegos de disputa en sí mismos se basan en dos propiedades fundamentales:

1. Compatibilidad de incentivos: El sistema penaliza las afirmaciones falsas y recompensa las verdaderas para garantizar una participación justa.

2. Resolución: Cada juego tiene un mecanismo para validar o invalidar de manera definitiva la afirmación raíz.

En el protocolo de disputa, se pueden crear, gestionar y actualizar diferentes tipos de juegos de disputa a través de la DisputeGameFactory. Esto abre la puerta a características innovadoras, como sistemas de prueba agregados y la posibilidad de expandir el protocolo para disputar cosas más allá del estado de L2, como un FaultDisputeGame orientado a la verificación binaria en cadena.

Este es un tipo específico de juego de disputa y el primer juego construido en el protocolo de disputa del OP Stack. En este juego, los jugadores van de un lado a otro dividiendo un rastro de ejecución hasta llegar a pasos individuales. Después de que la bisección ha alcanzado compromisos con el estado en las instrucciones individuales del rastro, el FaultDisputeGame ejecuta un solo paso de instrucción en cadena utilizando una máquina virtual genérica. La función de transición de estado de la VM, a la que llamaremos T, puede ser cualquier cosa, siempre y cuando se adhiera al formato T(s, i) -> s', donde s = el estado previamente acordado, i = las entradas de transición de estado y s' es el estado posterior.

Para nuestra primera implementación completa de la VM genérica en el juego de bisección, hemos implementado un único contexto de hilo MIPS encima de la EVM para ejecutar instrucciones individuales en un rastro de ejecución generado por Cannon y el op-program.

Los reclamos representan un compromiso con el estado de la VM en la parte trasera en una instrucción dada. Estas pueden ser verdaderas o falsas, y la verdad se determina después de la fase de resolución. Si no se refutan, se asume que las reclamaciones son verdaderas.

Los reclamos existen en posiciones en un árbol binario. La posición representa a qué instrucción está relacionado el reclamo. Las posiciones son índices generalizados, que pueden definirse como 2^{depth} + index_at_depth.

Los jugadores tienen un límite de tiempo para realizar movimientos. El juego es sin permisos, lo que permite a cualquiera unirse. Cada lado comienza con 3.5 días en su reloj, lo que suma un tiempo total de juego de 7 días. En el caso de que se cree un nuevo camino o se haga una afirmación en una posición que ya ha recibido una afirmación, se hereda el tiempo del reloj del abuelo.

Los jugadores realizan bisecciones hasta que las afirmaciones se comprometen con el estado de una sola instrucción de la máquina virtual (VM). Luego ejecutan esa instrucción en cadena para verificar o refutar las afirmaciones. Los movimientos pueden ser ataques (que desafían una afirmación anterior) o defensas (acuerdos con una afirmación anterior). La defensa se realiza cada vez que un jugador está de acuerdo con el hash de la afirmación que está observando (lo que significa que el estado de las dos partes es el mismo en la instrucción dada), pero no está de acuerdo con el resultado final que están tratando de impulsar en función del acuerdo relativo de la afirmación observada con la afirmación raíz.

En los nodos hoja del árbol de posiciones, cada afirmación se compromete al estado en una sola instrucción de la VM. El único movimiento que queda es ejecutar esa instrucción de la VM para probar o refutar las afirmaciones anteriores.

Si el paso de instrucción confirma el estado posterior esperado, la afirmación queda sin refutar. Si hay un estado posterior inesperado o un código de salida, la afirmación anterior es refutada.

El juego puede resolverse después de que los relojes de ajedrez para todas las afirmaciones se hayan agotado, con un mínimo de 3.5 días. Cada afirmación dentro del juego es la raíz de su propio Subjuego. Los subjuegos son DAG con una profundidad de 1. Todos los hijos (que son raíces de subjuegos en sí mismos) que apuntan a la raíz son refutaciones de esta, y el subjuego solo puede resolverse si todos sus subjuegos hijos también se han resuelto. Una raíz de subjuego solo se considera refutada si uno o más de sus hijos se han resuelto y no han sido refutados, y esta propiedad se propaga hacia arriba hasta la raíz de afirmación del juego.

La presencia de un jugador honesto, asumiendo que todos sus movimientos se han agotado, siempre dará como resultado que el juego se resuelva favorablemente para su visión del rastro, ya sea que la afirmación raíz sea honesta o deshonesta. Las afirmaciones deshonestas siempre pueden ser refutadas por cualquier parte, aunque siempre solo existe una afirmación correcta que se puede hacer, ya que no se permiten duplicados de hashes de afirmación en la misma posición en el mismo subjuego.

https://blog.oplabs.co/content/media/2023/09/subgame_rez.mp4

Para aquellos curiosos, también hay una herramienta de visualización para el FaultDisputeGame sobre un seguimiento de ejecución simulado que tiene solo 16 instrucciones. Esta simulación utiliza una VM separada de la secuencia de hilos MIPS, la AlphabetVM, que simplemente devuelve la siguiente letra del alfabeto cuando se le da una letra como entrada.

Si estás interesado en explorar las reglas del juego con un backend más ligero, aquí tienes cómo jugar:

Clona el monorepo de Optimism, instala las dependencias y crea los binarios de devnet allocations / cannon / op-program.

Dependencias requeridas:

1. foundry

2. Conjunto de herramientas Golang

3. Docker

   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
   

   Ejecuta el juego de alfabeto:

cd op-challenger && make alphabet

1. Ve a https://disputify.optimism.io/ o ejecuta la interfaz de visualización localmente clonando https://github.com/clabby/dispute-viz e ingresa la dirección del proxy FaultDisputeGame implementado en tu devnet local arriba.

En un juego de bisección, todos los mecanismos descritos anteriormente trabajan juntos para crear un sistema que recompensa el comportamiento honesto y contrarresta eficazmente las afirmaciones deshonestas.

Hay muchas, muchas formas de construir juegos de disputas que logren el mismo objetivo. Esperamos que cuando el Sistema a Prueba de Fallas del OP Stack se despliegue en OP Goerli, los desarrolladores en nuestro ecosistema se diviertan y sean creativos al construir sus propios juegos de disputa. Cada juego de disputa creado puede desempeñar un papel en la descentralización social del OP Stack y brindar a los participantes del ecosistema opciones cuando se trata de cómo se resuelven las disputas sobre una determinada afirmación acerca de una pieza de información.