¿Qué es la optimistic virtual machine (OVM)?

La Máquina Virtual Optimista (OVM) es el entorno de ejecución para contratos inteligentes que se ejecutan en un optimistic rollup. Los optimistic rollups son soluciones de escalamiento de capa 2 (L2) que ayudan a escalar el rendimiento y la latencia en Ethereum mediante la ejecución fuera de la cadena. Los rollups son "soluciones de escalamiento híbridas" porque, si bien ejecutan transacciones fuera de la cadena, publican en Ethereum los datos necesarios para reconstruir el estado de la cadena.

Las Máquinas Virtuales Optimistas (OVM) son fundamentales para el funcionamiento de los optimistic rollups. Las OVM permiten a los desarrolladores ejecutar aplicaciones descentralizadas en rollups de L2, tal como lo harían en Ethereum, sin diferencias notables en la experiencia del usuario.

Esta guía explica qué es una OVM y en qué se diferencia de otras máquinas virtuales, como la EVM y la zkEVM. También abordaremos la arquitectura básica de los diseños de OVM usados en optimistic rollups populares, como Optimism y Arbitrum.

¿Qué es una máquina virtual optimista?

La Máquina Virtual Optimista (OVM) es una máquina virtual compatible con la EVM para ejecutar cómputo general en protocolos de capa 2 (L2).

Una OVM ejecuta transacciones de forma "optimista", lo que significa que no impone la validez de las transacciones, sino que se apoya en la cadena L1 para arbitrar disputas sobre la corrección de las transiciones de estado. Estas disputas se conocen como pruebas de fraude.

Podemos desglosar esta definición examinando sus componentes clave.

Compatibilidad con la EVM

La Máquina Virtual de Ethereum (EVM) es una "computadora descentralizada y global" que permite la ejecución de programas en la blockchain de Ethereum. La EVM está compuesta por miles de computadoras individuales (nodos) que proveen recursos computacionales a los que cualquiera puede acceder para ejecutar software (por ejemplo, contratos inteligentes) en la red de Ethereum.

"Compatibilidad con la EVM" significa que un sistema particular está diseñado para funcionar con programas escritos o compilados para la EVM. La Máquina Virtual Optimista es compatible con la EVM porque admite el conjunto de instrucciones de la EVM (opcodes) tal como se especifica en el Ethereum Yellow Paper. Esto permite que la OVM ejecute contratos inteligentes de Ethereum sin cambios significativos en el código.

Ejecución optimista

Las máquinas virtuales también pueden funcionar como máquinas de estados, lo que les permite transitar entre distintos estados en respuesta a entradas. En las blockchains, el protocolo de consenso gobierna las transiciones de estado y establece las reglas que guían las funciones de transición de estado. Por ejemplo, las reglas para actualizar el estado de Ethereum están definidas por la EVM y se hacen cumplir mediante el consenso de proof-of-work (PoW) de la red.

La OVM se apoya en un modelo de "ejecución optimista": el protocolo no verifica si una transición de estado es válida antes de aceptarla. Esto aumenta la eficiencia, ya que la necesidad de alcanzar consenso sobre la validez de las actualizaciones de estado ralentiza el procesamiento en las blockchains de capa 1 (L1), como Ethereum. Al asumir que todas las transacciones son válidas por defecto, la OVM puede avanzar mucho más rápido.

Sin embargo, para brindar seguridad, los diseños de OVM permiten que cualquiera pueda disputar la validez de las transiciones de estado, con la cadena L1 actuando como juez. Este proceso se apoya en "pruebas de fraude", que explicamos en una sección posterior.

Cómputo general en L2

Si una máquina virtual (VM) admite cómputo general, puede realizar la mayoría de las tareas, dadas las instrucciones correctas y suficientes recursos. Como la OVM puede ejecutar lógica arbitraria (es decir, es Turing-completa), los desarrolladores pueden usarla para ejecutar distintos tipos de contratos inteligentes.

Además, la OVM se ejecuta en una blockchain de capa 2, un protocolo que opera sobre una blockchain base (Ethereum en este caso). Los protocolos de L2 son una extensión de la cadena padre y son gestionados por contratos inteligentes en la blockchain L1. Más importante aún, la cadena L1 garantiza la corrección de las transiciones de estado en la OVM de L2 y la disponibilidad de los datos que respaldan la ejecución.

¿En qué se diferencia la OVM de la EVM?

La OVM es similar a la EVM ya que ambas sirven para ejecutar cómputo. Sin embargo, la OVM funciona simplemente como una interfaz hacia la EVM.

La EVM es la máquina virtual usada para procesar transacciones en L1, pero la VM de L1 es lenta porque cada cómputo debe ser re-ejecutado por todos los nodos de la red antes de ser aceptado. También es costosa, ya que hay muchas transacciones por procesar y los nodos solo pueden procesar una pequeña cantidad de transacciones a la vez.

La OVM (que se ejecuta en L2) permite a los usuarios usar la EVM de L1 sin actualizar directamente el estado de esta última. En su lugar, la OVM ejecuta transacciones "fuera de la cadena" (es decir, fuera de la cadena L1), pero usa los datos fuera de la cadena para garantizar lo que ocurrirá en la capa 1.

Aquí un ejemplo:

Supongamos que Alice tiene 2 ETH en el optimistic rollup y le envía 1 ETH a Bob.

Un agregador envía la transacción al contrato del rollup en la capa uno, la cual, si no es impugnada, se incluye como parte de una transacción minada en Ethereum.

De esta manera, hemos garantizado que una transacción que le paga a Bob 1 ETH en el rollup pasará el consenso en la cadena principal de Ethereum y se finalizará como parte del estado de esta última.

Esta garantía se sustenta en los siguientes hechos:

1. La OVM usa las reglas de la EVM para guiar la ejecución de las transacciones. Si el optimistic rollup ejecuta una transacción correctamente, será aceptada en L1.
2. El agregador publica los datos de la transacción en L1, lo que permite que cualquiera pueda disputar la transacción si fue ejecutada de forma incorrecta.

Bob y Alice pueden decidir retirar sus fondos del rollup o seguir realizando transacciones.

De cualquier manera, se habrán beneficiado de la EVM sin ejecutar ninguna transacción en L1.

Otras diferencias entre la OVM y la EVM incluyen:

• Imposición de la validez
• Finalidad instantánea
• Velocidad de las transacciones

Imposición de la validez

La OVM no impone la validez de una función de transición de estado. Por ejemplo, un operador malicioso puede transferirse a sí mismo el saldo de Alice y enviar la transacción a L1. Si la transacción no es impugnada, la OVM simplemente la acepta.

Por el contrario, cada transición de estado en la EVM debe seguir las reglas de consenso de la red antes de ser aceptada.

Por ejemplo, el escenario descrito anteriormente no cumpliría con estas reglas, ya que la clave de firma del remitente no coincidiría con su clave pública (lo cual es un criterio para que una transacción sea válida).

Finalidad instantánea

La EVM garantiza la finalidad instantánea. Esto significa que una transición de estado es permanente una vez aceptada en la red y no puede ser alterada ni revertida.

La OVM no puede garantizar la finalidad instantánea porque no impone la validez de las transacciones (finalizar transacciones inválidas corrompería la cadena).

En cambio, las actualizaciones del estado de la OVM solo son finales si, y solo si, son aceptadas en la cadena L1.

Velocidad de las transacciones

Como se explicó, la OVM tiene una capacidad de procesamiento mayor que la EVM debido a diferencias de diseño. Un solo nodo (el secuenciador) puede escribir en la cadena sin tener que esperar la aprobación de otros nodos.

Esto es distinto de la EVM, donde los nodos no pueden escribir en la cadena a menos que una transacción haya sido verificada y aceptada por otros nodos de la red peer-to-peer. Esto reduce la cantidad de transacciones que se pueden procesar en la EVM.

¿En qué se diferencia la OVM de las zkEVM?

Como se explicó, la OVM se centra principalmente en la ejecución y se apoya en la EVM de la capa uno para hacer cumplir las reglas sobre las actualizaciones de estado. Por lo tanto, las transacciones realizadas en la OVM simplemente se envían a L1 sin ninguna prueba de su validez. Eso aumenta la escalabilidad, pero también incrementa el riesgo de que se finalicen transacciones inválidas en L1, particularmente si nadie las impugna.

Una zkEVM (Máquina Virtual de Ethereum de Conocimiento Cero) resuelve este problema generando pruebas criptográficas que certifican la corrección del cómputo fuera de la cadena. Esto le da a L1 garantías sólidas sobre la validez de las actualizaciones de estado.

La zkEVM es compatible con la EVM, al igual que la OVM, y puede ejecutar contratos inteligentes. Sin embargo, se diferencia de la OVM en varios aspectos:

1. Finalidad casi instantánea
2. Prueba objetiva
3. Complejidad

Exploremos esto un poco más.

1. Finalidad casi instantánea

Las transiciones de estado se finalizan de inmediato porque la prueba de validez se verifica en la cadena. Esto elimina la necesidad de demoras al finalizar transacciones de L2 en L1.

2. Prueba objetiva

Las pruebas de conocimiento cero se usan para garantizar la corrección del cómputo de la VM. Esto elimina la necesidad de pruebas subjetivas (es decir, esperar a que transcurra el período de impugnación) o de pruebas de fraude para determinar la validez de una transacción.

3. Complejidad

Una zkEVM es más difícil de implementar que la OVM porque generar pruebas de validez para múltiples pasos de cómputo es costoso. Las OVM no están limitadas por la necesidad de verificar de antemano el cómputo fuera de la cadena, y solo usan pruebas de fraude cuando es necesario. Esto las hace más fáciles de implementar que las zkEVM.

¿Cómo funciona la máquina virtual optimista?

Al igual que la EVM, la Máquina Virtual Optimista funciona como un entorno de ejecución para el cómputo. Sin embargo, la OVM también debe encargarse de probar el cómputo, ya que los optimistic rollups dependen de las pruebas de fraude para detectar transiciones de estado inválidas.

Ejecución

La OVM ofrece la funcionalidad para desplegar y ejecutar contratos, monitorear saldos y realizar otras tareas que debe cumplir una plataforma de contratos inteligentes. La OVM recibe entradas en forma de transacciones enviadas por un nodo en la cadena L2. Estas entradas hacen que la OVM cambie su estado y produzca salidas, como la emisión de eventos o el procesamiento de pagos.

Otros detalles sobre la ejecución en la OVM incluyen el gas, el bytecode y las transacciones.

Gas

"Gas" se refiere a los recursos computacionales para ejecutar programas en la EVM. Al igual que la EVM, la OVM usa el concepto de gas para limitar los pasos de ejecución de cada transacción.

Los remitentes de transacciones deben establecer un límite de gas para especificar cuánto gas están dispuestos a gastar en una transacción. Esto evita que transacciones maliciosas se ejecuten infinitamente y consuman todos los recursos de la red. Las tarifas de gas también compensan a los nodos de L2 por proveer los recursos computacionales necesarios para ejecutar las transacciones.

Bytecode

El bytecode se refiere a instrucciones de bajo nivel que la Máquina Virtual Optimista (OVM) puede interpretar para ejecutar funciones. Los contratos inteligentes escritos en lenguajes de alto nivel compatibles con la EVM, como Solidity, deben ser compilados a bytecode antes de su despliegue. El bytecode en sí se ejecuta como una serie de opcodes que realizan operaciones sobre las entradas de la transacción.

La OVM es compatible con la EVM a nivel de bytecode, salvo por algunas diferencias. Esto significa que se puede desplegar bytecode compilado para la EVM en la OVM con cambios mínimos.

Transacciones

Una transacción en la OVM funciona de manera similar a como lo hace en la EVM. Una transacción puede ser iniciada por una cuenta de propiedad externa (EOA) o una cuenta de contrato. Las transacciones desde EOA pueden ser cualquiera de las siguientes:

• Transferencia de activos (por ejemplo, Alice le envía 5 ETH a Bob)
• Creación de contratos (por ejemplo, Bob envía una transacción a la red con el bytecode compilado como payload de datos)
• Ejecución de contratos inteligentes (por ejemplo, Alice paga por 5 tokens UNI)

De manera similar, las cuentas de contrato pueden iniciar transacciones (llamadas "message calls") con una EOA como destinatario o con otro contrato. Un contrato también puede crear un nuevo contrato en la OVM mediante una transacción de creación de contrato.

Pruebas de fraude

Como se mencionó, la OVM se apoya en un esquema de pruebas de fraude para detectar y revertir transiciones de estado inválidas. Para que las pruebas de fraude funcionen, el estado de la OVM se hashea como un árbol de Merkle, y la raíz se almacena en el contrato del rollup en la capa 1. Los árboles y raíces de Merkle permiten a los nodos hacer afirmaciones sobre distintas partes del estado de la OVM.

Por ejemplo, se espera que un operador de rollup, luego de iniciar una transición de estado ejecutando transacciones, publique una nueva raíz de estado al enviar bloques del rollup. La raíz de estado equivale a decir: "Esta secuencia de transacciones, al ejecutarse, hace que la VM pase de un estado anterior (referenciado en la raíz de estado antigua) a un nuevo estado (referenciado en la nueva raíz de estado)".

Sin embargo, el contrato del rollup no puede saber si la transición de estado fue válida o no (el sistema es "optimista"). Para evitar que los nodos ejecuten actualizaciones de estado inválidas en la OVM, los rollups usan pruebas de fraude.

¿Qué es una prueba de fraude?

Una prueba de fraude es simplemente una afirmación de que una transacción, si se ejecuta correctamente, lleva a una raíz de estado distinta a la calculada por el productor del bloque. Esto es posible porque cualquiera que monitoree la cadena L2 puede descargar las transacciones enviadas al operador del rollup, volver a ejecutarlas usando su propia copia del estado del rollup, y calcular la raíz de estado de manera independiente.

Supongamos que el saldo de Alice era de 5 ETH en el estado antiguo de la OVM (con huella criptográfica dada por la raíz hash: "0x67989898…"). Si ella transfiere 4 ETH, el rollup pasa a un nuevo estado (con huella criptográfica dada por la raíz hash: "0x7879056…").

Si la transacción era inválida (por ejemplo, tal vez la firma era incorrecta), entonces debería revertirse, lo que dejaría el estado de la VM sin cambios.

Sin embargo, imaginemos que un operador malicioso aplicó la actualización inválida (quizás transfiriendo el ETH de Alice a su propia billetera); podría publicar la nueva raíz de estado, aunque sea incorrecta, para finalizar la transacción.

Por lo tanto, es el rol del impugnador publicar la raíz de estado correcta y declarar inválido el bloque del rollup. Es el equivalente a decir: "Esta transacción, si se ejecuta correctamente, lleva a una raíz de estado distinta".

¿Cuáles son las dos formas de probar el fraude en rollups basados en OVM?

Generalmente hay dos enfoques para probar el fraude en rollups basados en OVM: volver a ejecutar las transacciones y el protocolo de bisección.

1. Volver a ejecutar las transacciones

Aquí, la OVM está "contenerizada" en un contrato inteligente que se ejecuta en la cadena L1. El contrato inteligente actúa como un entorno aislado (sandbox) que nos permite reproducir una transacción de la OVM dentro de la EVM para obtener la raíz de estado correcta. Esto se hace suministrando otras entradas relacionadas con el contexto, como el estado y el almacenamiento, además de la transacción en disputa.

En el ejemplo del operador malicioso descrito anteriormente, la transacción se revertiría, dejando la raíz de estado sin cambios. La raíz de estado calculada inevitablemente coincidiría con la del impugnador, exponiendo al operador malicioso y evitando la transición de estado inválida.

2. Protocolo de bisección

El protocolo de bisección es un enfoque distinto para probar el fraude que busca minimizar el trabajo que debe hacer la cadena L1 en este proceso. Se llama protocolo de bisección debido a su diseño particular:

1. El proceso comienza cuando un impugnador disputa una afirmación (los bloques del rollup se llaman "afirmaciones", ya que pueden ser disputados).
2. El afirmante divide entonces la afirmación disputada en dos afirmaciones iguales, y el impugnador elige qué parte desea impugnar.
3. Después de que el impugnador ha elegido otra afirmación para impugnar, el afirmante vuelve a dividir la afirmación.
4. Este proceso continúa hasta que ambas partes están disputando el resultado de un solo paso de cómputo realizado en la OVM.
5. Entonces se le exige al afirmante proporcionar una prueba de un solo paso que muestre que el paso de ejecución en disputa es correcto.
6. Si el afirmante no logra presentar la prueba, o si el contrato de L1 considera que la prueba es inválida, pierde la disputa.

A diferencia de volver a ejecutar transacciones, la bisección elimina la necesidad de volver a ejecutar en la cadena un bloque o transacción completa, lo cual es costoso. También hace innecesario publicar raíces de estado para cada transacción, algo necesario al volver a ejecutar transacciones para probar el fraude.

El protocolo de bisección se usa en Arbitrum, y otros optimistic rollups, como Optimism, planean usar un protocolo de bisección para probar el fraude.

Reflexiones finales

La Máquina Virtual Optimista es clave para escalar Ethereum al mover el cómputo fuera de la cadena hacia los rollups. Con la OVM, los desarrolladores pueden desplegar contratos inteligentes en cadenas de L2 sin enfrentar las altas tarifas de gas y los tiempos de procesamiento lentos que afectan a Ethereum. Además, la prueba de fraude permite que la OVM ofrezca las mismas garantías de seguridad que la EVM en la red principal de Ethereum.

Alchemy da soporte para construir sobre optimistic rollups que utilizan la Máquina Virtual Optimista, incluyendo Optimism y Arbitrum.

Regístrate para obtener una cuenta gratuita de Alchemy y empieza hoy a construir aplicaciones ultra rápidas, escalables y compatibles con la EVM.