https://blog.oplabs.co/fault-proof-vm/

Esta publicación blog explora el principio de descentralización social, cómo la arquitectura de L2 permite a las Layer 2 extender este principio para incluir la diversidad de pruebas, y cómo el Colectivo de Optimism está construyendo su sistema a prueba de fallas para aprovechar esta arquitectura.

Con el fin de crear la red más robusta y segura de cadenas L2 interoperables, el Colectivo de Optimism está persiguiendo la descentralización de tomando diferentes caminos.

El próximo sistema a prueba de fallas del OP Stack será un gran avance para la descentralización técnica, y el diseño de código abierto y modular de OP Stack está sentando las bases para una descentralización social sin precedentes en un ecosistema L2.

En esta publicación blog, exploraremos el principio de la descentralización social, cómo la arquitectura L2 permite a las Layer 2 extender este principio para incluir la diversidad de pruebas y la diversidad de clientes, y cómo el Colectivo de Optimism está construyendo su sistema a prueba de fallas para aprovechar esta arquitectura.

El protocolo Ethereum se beneficia de la descentralización social al permitir que una amplia gama de contribuyentes construyan una red sólida creando opciones en las soluciones. Para el software de nodo, esto significa diversidad de clientes: cuantas más implementaciones de clientes haya, menos impacto puede tener un solo punto de fallo en la red de validadores.

Los desarrolladores principales en L1 describen este modelo de contribución como el "bazaar"; ruidoso y aparentemente caótico, pero inmensamente productivo y energizante. Con un enfoque radicalmente abierto hacia el desarrollo de protocolos, el conjunto más amplio de contribuyentes puede mejorar el protocolo.

El Colectivo de Optimism está posicionado de manera única para implementar y mejorar la forma en que Ethereum aborda la descentralización social. El OP Stack permite la descentralización social, con especificaciones abiertas y software de código abierto con licencia MIT, y el Colectivo de Optimism lo itera con la creación de la Superchain.

Ethereum en L1 tiene especificaciones abiertas y una arquitectura modular de cliente que separa las capas de consenso y ejecución. OP-Stack implementa esta misma arquitectura para L2:

• El consenso está respaldado por op-node y Magi, dos clientes que siguen el L1 y derivan entradas de ejecución.

• La ejecución está respaldada por op-geth, op-erigon y op-reth.

Sin embargo, la arquitectura L2 añade una nueva capa al stack: la capa de pruebas. Esta es la capa que conecta de forma segura las salidas de L2 de nuevo a L1. Al igual que tener múltiples clientes es una buena práctica para asegurar el consenso y la ejecución en L1 y L2, un enfoque multiprueba para la capa de pruebas de un L2 asegura la mejor seguridad.

Similar a un conjunto de validadores con diversidad de clientes llegando a un consenso, un quórum de pruebas en cadena puede señalar que la afirmación del estado de L2 ha sido validada de diferentes maneras, lo que reduce significativamente el riesgo de que un error cause un fallo total.

Existen tres tipos comunes de pruebas: atestaciones (attestations), pruebas de fallas (también conocidas como pruebas de fraude) y pruebas de validez ZK. Los dos últimos comparten un patrón común. Expresan la transición de estado de L2 de forma sincrónica y demuestran la ejecución de la misma cuando se les proporcionan datos de L1 y el estado previo de L2 como entrada.

Los sistemas de pruebas pueden dividirse aún más en componentes aislados:

• Un "programa" define la transición de estado sincrónica del L2.

• Una "VM" ejecuta y demuestra el programa.

• Un "oráculo de preimagen" proporciona los datos de L1 y el estado previo de L2 como entradas.

Muchas pruebas de conocimiento cero (ZK-proofs) todavía acoplan estrechamente estos componentes, creando un ZK-EVM que opera en datos de transacciones únicos de L1. Sin embargo, OP Stack los desacopla para aislar la complejidad y permitir la diversidad de clientes que hace que el conjunto sea más robusto.

Las pruebas de fallas interactivas añaden un juego de bisección a la traza de la VM para verificar la prueba en la cadena, mientras que las pruebas de validez basadas en la VM aritmetizan y pliegan la ejecución en una prueba de validez. (Mira las pruebas basadas en la VM que Risc0 y O(1)-Labs están diseñando en respuesta a las solicitudes de propuestas de ZK RFPs de Optimism).

El programa define la transición de estado real como un "cliente", y la obtención de datos (datos de L1 y estado previo de L2) como un "servidor". Cuando se ejecuta de forma independiente con servidor/cliente, pero sin VM, el programa es muy similar a un nodo de blockchain regular y comparte mucho del código. Por ejemplo, el cliente de op-program en Go se construye importando la derivación de op-node y el EVM de op-geth, y el servidor obtiene sus datos de L1 y L2 a través de la RPC de Ethereum.

La Máquina Virtual a Prueba de Fallas (FPVM) es uno de los módulos en el stack de prueba de fallas del OP Stack.

La VM no implementa nada específico de Ethereum o L2, excepto por proporcionar las interfaces adecuadas (en particular, la interfaz con el oráculo de preimagen). El Programa a Prueba de Fallas (FPP) (lado del cliente) que se ejecuta dentro de la FPVM es la parte que expresa la transición de estado de L2.

A través de esta separación, la VM se mantiene ultra-minimalista: los cambios en el protocolo de Ethereum, como las adiciones de códigos de operación de EVM, no afectan a la VM. En su lugar, cuando cambia el protocolo, el FPP puede actualizarse simplemente importando los nuevos componentes de transición de estado del software del nodo. Similar a jugar una nueva versión de un juego en la misma consola de juegos, el sistema de pruebas de L1 se puede actualizar para demostrar un programa diferente.

La tarea de la VM es la ejecución de instrucciones a un nivel más bajo. El FPP debe ser emulado. Los requisitos de la VM son bajos: el programa es síncrono y todas las entradas se cargan a través del mismo oráculo de preimagen, ¡pero todo esto todavía debe demostrarse en el EVM de L1 onchain!

Para hacer esto, solo se demuestra una instrucción a la vez. El juego de bisección reducirá la tarea de demostrar una traza de ejecución completa a solo una instrucción.

La demostración de la instrucción puede verse diferente para cada FPVM, pero en general se parece a Cannon, que demuestra la instrucción de la siguiente manera:

Para ejecutar la instrucción, la VM emula algo similar a un ciclo de instrucción de un contexto de hilo: la instrucción se lee de la memoria, se interpreta y el archivo de registros y la memoria pueden cambiar un poco.

Para admitir el oráculo de preimagen y las necesidades básicas de tiempo de ejecución del programa, como la asignación de memoria, la ejecución también admite un subconjunto de llamadas al sistema de Linux. Las llamadas al sistema de lectura/escritura permiten la interacción con el oráculo de preimagen: el programa escribe un hash como solicitud de una preimagen y luego lee el valor en pequeños fragmentos a la vez.

Cannon, la primera FPVM, implementa una VM MIPS de esta manera. Consulta la documentación y las especificaciones de Cannon para obtener más información sobre la VM. La interfaz entre la FPVM y el programa FP está estandarizada y documentada en las especificaciones.

Las pruebas de fallas no son el único tipo de prueba de transición de estado. Las pruebas de validez ZK son una opción atractiva debido al potencial de conexión rápida (ya que no hay un juego de desafío en cadena para las pruebas de validez ZK, no hay una ventana de disputa). Para soportar un stack de Ethereum avanzada y alojar diferentes implementaciones de clientes, todavía necesitamos desacoplar la VM y el programa.

Este es el enfoque que están siguiendo los proyectos de ZK RFP, para demostrar una VM mínima de RISC-V (por Risc0) o MIPS (por O(1) Labs) que puede alojar el mismo programa como es utilizado en las pruebas de fallas.

Para admitir la ZK-VM, se requieren pequeñas adaptaciones para que el oráculo de preimagen cargue los datos de manera no interactiva, pero al generalizar la VM, la prueba ZK es mucho más resistente a cambios en OP Stack en el futuro.

OP Stack da la bienvenida a opciones adicionales de VM y programas, así como a sistemas de prueba independientes adicionales, desde atestaciones hasta ZK. ¡Al igual que la diversidad de clientes, la diversidad de pruebas es un esfuerzo colectivo!

Los complementos actuales en curso para la capa de pruebas de OP Stack incluyen:

• Una FPVM RISC-V "Asterisc" escrita en Go que está siendo desarrollada por protolambda.

• Un programa FP en rust, basado en Magi y op-reth, está siendo construido por colaboradores de Base y OP Labs.

• Un programa ZK en rust, basado en zeth, un fork de ZK-reth, está siendo construido por Risc0.

Con el desarrollo de Cannon, el op-program, el juego de bisección, los elementos anteriores y la infinita ingeniosidad de la comunidad de código abierto, habrá muchas oportunidades adicionales para contribuir al stack mediante la prueba de implementaciones y la participación en programas de recompensas por errores. Cualquier persona interesada debe marcar la página de Recompensas por Errores de Immunefi de Optimism para nuevas recompensas relacionadas con el Sistema a Prueba de Fallas del OP Stack. 👀

https://blog.oplabs.co/fault-proof-vm/

Esta publicación blog explora el principio de descentralización social, cómo la arquitectura de L2 permite a las Layer 2 extender este principio para incluir la diversidad de pruebas, y cómo el Colectivo de Optimism está construyendo su sistema a prueba de fallas para aprovechar esta arquitectura.

Con el fin de crear la red más robusta y segura de cadenas L2 interoperables, el Colectivo de Optimism está persiguiendo la descentralización de tomando diferentes caminos.

El próximo sistema a prueba de fallas del OP Stack será un gran avance para la descentralización técnica, y el diseño de código abierto y modular de OP Stack está sentando las bases para una descentralización social sin precedentes en un ecosistema L2.

En esta publicación blog, exploraremos el principio de la descentralización social, cómo la arquitectura L2 permite a las Layer 2 extender este principio para incluir la diversidad de pruebas y la diversidad de clientes, y cómo el Colectivo de Optimism está construyendo su sistema a prueba de fallas para aprovechar esta arquitectura.

El protocolo Ethereum se beneficia de la descentralización social al permitir que una amplia gama de contribuyentes construyan una red sólida creando opciones en las soluciones. Para el software de nodo, esto significa diversidad de clientes: cuantas más implementaciones de clientes haya, menos impacto puede tener un solo punto de fallo en la red de validadores.

Los desarrolladores principales en L1 describen este modelo de contribución como el "bazaar"; ruidoso y aparentemente caótico, pero inmensamente productivo y energizante. Con un enfoque radicalmente abierto hacia el desarrollo de protocolos, el conjunto más amplio de contribuyentes puede mejorar el protocolo.

El Colectivo de Optimism está posicionado de manera única para implementar y mejorar la forma en que Ethereum aborda la descentralización social. El OP Stack permite la descentralización social, con especificaciones abiertas y software de código abierto con licencia MIT, y el Colectivo de Optimism lo itera con la creación de la Superchain.

Ethereum en L1 tiene especificaciones abiertas y una arquitectura modular de cliente que separa las capas de consenso y ejecución. OP-Stack implementa esta misma arquitectura para L2:

• El consenso está respaldado por op-node y Magi, dos clientes que siguen el L1 y derivan entradas de ejecución.

• La ejecución está respaldada por op-geth, op-erigon y op-reth.

Sin embargo, la arquitectura L2 añade una nueva capa al stack: la capa de pruebas. Esta es la capa que conecta de forma segura las salidas de L2 de nuevo a L1. Al igual que tener múltiples clientes es una buena práctica para asegurar el consenso y la ejecución en L1 y L2, un enfoque multiprueba para la capa de pruebas de un L2 asegura la mejor seguridad.

Similar a un conjunto de validadores con diversidad de clientes llegando a un consenso, un quórum de pruebas en cadena puede señalar que la afirmación del estado de L2 ha sido validada de diferentes maneras, lo que reduce significativamente el riesgo de que un error cause un fallo total.

Existen tres tipos comunes de pruebas: atestaciones (attestations), pruebas de fallas (también conocidas como pruebas de fraude) y pruebas de validez ZK. Los dos últimos comparten un patrón común. Expresan la transición de estado de L2 de forma sincrónica y demuestran la ejecución de la misma cuando se les proporcionan datos de L1 y el estado previo de L2 como entrada.

Los sistemas de pruebas pueden dividirse aún más en componentes aislados:

• Un "programa" define la transición de estado sincrónica del L2.

• Una "VM" ejecuta y demuestra el programa.

• Un "oráculo de preimagen" proporciona los datos de L1 y el estado previo de L2 como entradas.

Muchas pruebas de conocimiento cero (ZK-proofs) todavía acoplan estrechamente estos componentes, creando un ZK-EVM que opera en datos de transacciones únicos de L1. Sin embargo, OP Stack los desacopla para aislar la complejidad y permitir la diversidad de clientes que hace que el conjunto sea más robusto.

Las pruebas de fallas interactivas añaden un juego de bisección a la traza de la VM para verificar la prueba en la cadena, mientras que las pruebas de validez basadas en la VM aritmetizan y pliegan la ejecución en una prueba de validez. (Mira las pruebas basadas en la VM que Risc0 y O(1)-Labs están diseñando en respuesta a las solicitudes de propuestas de ZK RFPs de Optimism).

El programa define la transición de estado real como un "cliente", y la obtención de datos (datos de L1 y estado previo de L2) como un "servidor". Cuando se ejecuta de forma independiente con servidor/cliente, pero sin VM, el programa es muy similar a un nodo de blockchain regular y comparte mucho del código. Por ejemplo, el cliente de op-program en Go se construye importando la derivación de op-node y el EVM de op-geth, y el servidor obtiene sus datos de L1 y L2 a través de la RPC de Ethereum.

La Máquina Virtual a Prueba de Fallas (FPVM) es uno de los módulos en el stack de prueba de fallas del OP Stack.

La VM no implementa nada específico de Ethereum o L2, excepto por proporcionar las interfaces adecuadas (en particular, la interfaz con el oráculo de preimagen). El Programa a Prueba de Fallas (FPP) (lado del cliente) que se ejecuta dentro de la FPVM es la parte que expresa la transición de estado de L2.

A través de esta separación, la VM se mantiene ultra-minimalista: los cambios en el protocolo de Ethereum, como las adiciones de códigos de operación de EVM, no afectan a la VM. En su lugar, cuando cambia el protocolo, el FPP puede actualizarse simplemente importando los nuevos componentes de transición de estado del software del nodo. Similar a jugar una nueva versión de un juego en la misma consola de juegos, el sistema de pruebas de L1 se puede actualizar para demostrar un programa diferente.

La tarea de la VM es la ejecución de instrucciones a un nivel más bajo. El FPP debe ser emulado. Los requisitos de la VM son bajos: el programa es síncrono y todas las entradas se cargan a través del mismo oráculo de preimagen, ¡pero todo esto todavía debe demostrarse en el EVM de L1 onchain!

Para hacer esto, solo se demuestra una instrucción a la vez. El juego de bisección reducirá la tarea de demostrar una traza de ejecución completa a solo una instrucción.

La demostración de la instrucción puede verse diferente para cada FPVM, pero en general se parece a Cannon, que demuestra la instrucción de la siguiente manera:

Para ejecutar la instrucción, la VM emula algo similar a un ciclo de instrucción de un contexto de hilo: la instrucción se lee de la memoria, se interpreta y el archivo de registros y la memoria pueden cambiar un poco.

Para admitir el oráculo de preimagen y las necesidades básicas de tiempo de ejecución del programa, como la asignación de memoria, la ejecución también admite un subconjunto de llamadas al sistema de Linux. Las llamadas al sistema de lectura/escritura permiten la interacción con el oráculo de preimagen: el programa escribe un hash como solicitud de una preimagen y luego lee el valor en pequeños fragmentos a la vez.

Cannon, la primera FPVM, implementa una VM MIPS de esta manera. Consulta la documentación y las especificaciones de Cannon para obtener más información sobre la VM. La interfaz entre la FPVM y el programa FP está estandarizada y documentada en las especificaciones.

Las pruebas de fallas no son el único tipo de prueba de transición de estado. Las pruebas de validez ZK son una opción atractiva debido al potencial de conexión rápida (ya que no hay un juego de desafío en cadena para las pruebas de validez ZK, no hay una ventana de disputa). Para soportar un stack de Ethereum avanzada y alojar diferentes implementaciones de clientes, todavía necesitamos desacoplar la VM y el programa.

Este es el enfoque que están siguiendo los proyectos de ZK RFP, para demostrar una VM mínima de RISC-V (por Risc0) o MIPS (por O(1) Labs) que puede alojar el mismo programa como es utilizado en las pruebas de fallas.

Para admitir la ZK-VM, se requieren pequeñas adaptaciones para que el oráculo de preimagen cargue los datos de manera no interactiva, pero al generalizar la VM, la prueba ZK es mucho más resistente a cambios en OP Stack en el futuro.

OP Stack da la bienvenida a opciones adicionales de VM y programas, así como a sistemas de prueba independientes adicionales, desde atestaciones hasta ZK. ¡Al igual que la diversidad de clientes, la diversidad de pruebas es un esfuerzo colectivo!

Los complementos actuales en curso para la capa de pruebas de OP Stack incluyen:

• Una FPVM RISC-V "Asterisc" escrita en Go que está siendo desarrollada por protolambda.

• Un programa FP en rust, basado en Magi y op-reth, está siendo construido por colaboradores de Base y OP Labs.

• Un programa ZK en rust, basado en zeth, un fork de ZK-reth, está siendo construido por Risc0.

Con el desarrollo de Cannon, el op-program, el juego de bisección, los elementos anteriores y la infinita ingeniosidad de la comunidad de código abierto, habrá muchas oportunidades adicionales para contribuir al stack mediante la prueba de implementaciones y la participación en programas de recompensas por errores. Cualquier persona interesada debe marcar la página de Recompensas por Errores de Immunefi de Optimism para nuevas recompensas relacionadas con el Sistema a Prueba de Fallas del OP Stack. 👀