Interpretación del sistema a prueba de fallos que lanzará OP Stack: inspirado en Ethereum, un gran paso hacia la descentralización tecnológica

Autor: protolambda, investigador de OP Labs

Compilado por: Frank, Foresight News

Para crear la red de Capa 2 interoperable más poderosa y segura, Optimism Collective está buscando la descentralización a través de muchas vías diferentes.

El próximo sistema a prueba de fallos de OP Stack será un paso importante hacia la descentralización tecnológica. El código abierto y el diseño modular de OP Stack están creando un escenario sin precedentes para la descentralización social del ecosistema L2.

En este artículo, exploraremos el principio de descentralización social, cómo la arquitectura L2 permite que la Capa 2 extienda este principio para incluir diversidad de pruebas y diversidad de clientes, y describiremos cómo Optimism Collective aprovecha esta arquitectura para construir su sistema a prueba de fallas.

“Descentralización social” inspirada en Ethereum

El protocolo Ethereum se beneficia de la descentralización social, particularmente al brindar opcionalidad en soluciones que permiten que una amplia gama de contribuyentes participen en la construcción de una red descentralizada sólida.

Para el software de nodo, esto significa diversidad de clientes: cuantos más clientes tenga, menor impacto tendrá un único punto de falla en la red del validador.

Los desarrolladores principales de Layer1 describen este modelo de contribución como un “bazar”, que es ruidoso y aparentemente caótico, pero muy eficiente y dinámico. Al adoptar un enfoque radicalmente abierto para el desarrollo del protocolo, la gama más amplia de contribuyentes puede participar y mejorar el protocolo.

Optimism Collective está en una posición única para implementar e iterar el enfoque de Ethereum hacia la descentralización social: OP Stack logra la descentralización social al proporcionar especificaciones abiertas y software de código abierto bajo la licencia MIT, y Optimism Collective puede lograr la descentralización social creando supercadenas iteradas sobre ella.

Una comprensión más detallada de la arquitectura L2

Ethereum tiene una especificación abierta en L1 y una arquitectura de cliente modular que separa la capa de consenso y la capa de ejecución.

OP-Stack implementa la misma arquitectura en L2:

La capa de consenso está impulsada por op-node y Magi, dos clientes que siguen L1 y exportan entradas de ejecución;

La capa de ejecución está respaldada por op-geth, op-erigon y op-reth;

Sin embargo, la arquitectura L2 agrega una nueva capa a esta pila: la capa de prueba.

Esta es la capa que une de forma segura las salidas de L2 a L1. Así como tener múltiples clientes es una mejor práctica para garantizar el consenso y la ejecución tanto en L1 como en L2, para la capa de verificación de L2, tener múltiples métodos de certificación puede garantizar una seguridad óptima.

De manera similar a cómo los validadores con diferentes clientes llegan a un consenso, un quórum de certificaciones en cadena puede mostrar que las afirmaciones del estado L2 se han verificado de diferentes maneras, lo que reduce en gran medida la posibilidad de errores que conduzcan a un fracaso total.

Actualmente existen tres tipos comunes de pruebas: atestados, pruebas de error (también conocidas como pruebas de fraude) y pruebas de validez de conocimiento cero. Los dos últimos comparten un patrón común en el sentido de que expresan las transiciones de estado L2 de forma sincrónica y prueban su ejecución dados los datos L1 y el estado anterior L2 como entrada.

Aislar los componentes del sistema de prueba para lograr diversidad de pruebas

Demuestre que el sistema se puede descomponer aún más en componentes independientes:

• Un “programa” que define transiciones de estado L2 sincrónicas;
• Una “máquina virtual” (VM) para ejecutar y verificar el programa;
• Un “oráculo de imagen previa” que toma datos L1 y estado previo de L2 como entrada;

Muchas de las pruebas de conocimiento cero actuales todavía combinan estrechamente estos componentes, creando un ZK-EVM que se ejecuta en una única transacción L1. Sin embargo, la pila OP los desacopla para aislar la complejidad y permitir la diversidad de clientes, haciendo que el conjunto sea más poderoso.

Las pruebas de fallas interactivas agregan juegos de bisección a los rastros de las máquinas virtuales para verificar las pruebas en cadena, mientras que las pruebas de conocimiento cero basadas en máquinas virtuales realizan pruebas aritméticas y combinan la ejecución y proporcionan pruebas de validez. (Consulte las pruebas de conocimiento cero basadas en máquinas virtuales que Risc0 y O(1)-Labs están diseñando en respuesta a las RFP de Optimism ZK).

El programa define la transición del estado real como el “cliente” y la adquisición de entrada (datos L1 y estado previo L2) como el “servidor”. El programa se ejecuta independientemente del servidor/cliente sin una máquina virtual, muy parecido a un nodo blockchain normal, y comparte una gran cantidad de código.

Por ejemplo, el cliente del programa de operaciones Go se construye importando la bifurcación del nodo de operaciones y el EVM de op-geth, mientras que el servidor obtiene sus datos de los RPC de Ethereum L1 y L2.

Descripción general funcional de FPVM

La máquina virtual a prueba de fallos (FPVM) es uno de los módulos de la pila a prueba de fallos en OP Stack.

Esta VM no implementa nada específico de Ethereum o L2 aparte de proporcionar las interfaces correctas (especialmente aquellas relacionadas con oráculos previos a la imagen), y el cliente del Programa de prueba de fallas (FPP) que se ejecuta dentro del FPVM debe expresar la parte de conversión de estado L2.

Con esta separación, la máquina virtual se mantiene minimalista: los cambios en el protocolo Ethereum (como la adición de códigos de operación EVM) no afectan a la máquina virtual.

En cambio, cuando el protocolo cambia, el FPP puede simplemente actualizarse para importar los nuevos componentes de transición de estado en el software del nodo. De manera similar a jugar una nueva versión del juego en la misma consola de juegos, el sistema de certificación L1 se puede actualizar para dar fe de diferentes programas.

La máquina virtual es responsable de ejecutar instrucciones de bajo nivel y necesita simular FPP. Los requisitos de la máquina virtual son menores: los programas se ejecutan sincrónicamente y todas las entradas se cargan a través del mismo oráculo de imagen previa, pero todo esto aún debe probarse en la cadena EVM L1.

Para ello, sólo se puede probar una instrucción a la vez. El juego de bisección reducirá la tarea de demostrar trazas de ejecución completas a una sola instrucción.

La prueba de instrucción puede verse diferente para cada FPVM, pero generalmente es similar a Cannon, que prueba la instrucción de la siguiente manera:

• Para ejecutar esta instrucción, la máquina virtual simula algo similar al ciclo de instrucción de un contexto de hilo: la instrucción se lee de la memoria, se interpreta y pueden ocurrir algunos cambios en el archivo de registro y la memoria;
• Para respaldar las necesidades básicas de tiempo de ejecución del programa, como oráculos de imágenes previas y asignación de memoria, la ejecución también admite un subconjunto de llamadas al sistema Linux. Las llamadas al sistema de lectura/escritura permiten la interacción con el oráculo de la imagen previa: el programa escribe el hash como una solicitud para obtener la imagen previa y luego la lee en fragmentos a la vez;

Cannon, el primer FPVM, implementó la máquina virtual MIPS de esta manera. Para obtener más información sobre máquinas virtuales, consulte la documentación relacionada y las especificaciones de cañón. La interfaz entre los programas FPVM y FP está estandarizada y documentada en especificaciones.

De FPVM a ZKVM

Las pruebas de falla no son el único tipo de prueba de transición de estado, las pruebas de validez ZK son una opción atractiva debido a su potencial para un rápido puente entre cadenas (dado que las pruebas de validez ZK no tienen juegos de desafío en cadena, no hay ventana de disputa). Para admitir la pila avanzada de Ethereum y alojar diferentes implementaciones de clientes, aún necesitamos desacoplar la máquina virtual y el programa.

Este es el enfoque adoptado por el proyecto ZK RFP para demostrar que una máquina virtual mínima RISC-V (por Risc0) o MIPS (por O(1) Labs) puede alojar el mismo programa utilizado en la prueba de fallas.

El soporte de ZK-VM requiere algunos ajustes menores para permitir que los oráculos de imágenes previas carguen datos de forma no interactiva, pero al generalizar la máquina virtual, ZK demuestra estar más preparado para el futuro frente a los cambios de OP Stack.

Oportunidades para contribuyentes externos

OP Stack da la bienvenida a opciones adicionales de programas y máquinas virtuales, así como sistemas de prueba independientes adicionales, desde pruebas hasta pruebas sin conocimiento. Al igual que la diversidad de clientes, la diversidad de pruebas es un esfuerzo colectivo.

Las adiciones a la capa de prueba de OP Stack actualmente en progreso incluyen:

• RISC-V FPVM “Asterisc” desarrollado por protolambda y escrito en lenguaje Go;
• Programa Rust FP basado en Magi y op-reth creado por colaboradores de Base y OP Labs;
• Programa Rust ZK basado en zeth (rama ZK-reth) creado por Risc0;

A medida que evolucionen el cañón, el programa operacional, el juego de bisección y la creatividad ilimitada de la comunidad de código abierto, habrá muchas oportunidades adicionales para contribuir a la pila a través de implementaciones de prueba y participación en programas de recompensas por errores.