Discusión sobre el paquete híbrido ZK/Optimistic

Autor: kelvinfichter Compilador: MarsBit, MK

Recientemente me convencí de que el futuro de Ethereum Rollups es en realidad un híbrido de los dos enfoques principales (ZK y Optimistic). En esta publicación, intentaré explicar la arquitectura básica de lo que imagino y explicar por qué creo que este es el mejor camino a seguir.

No voy a pasar mucho tiempo discutiendo la naturaleza de ZK o Optimistic Rollups. Esta publicación asume que ya tiene una comprensión decente de cómo funcionan estas cosas. No necesita ser un experto, pero al menos debe saber qué son y cómo funcionan a un alto nivel. Si tratara de explicarte los Rollups, esta publicación sería muy, muy larga. En definitiva, ¡disfruta de la lectura!

Empezar con Optimistic Rollup

Hybrid ZK/Optimistic Rollup comenzó como Optimistic Rollup, que es muy similar a la arquitectura Bedrock de Optimism. Bedrock tiene como objetivo la máxima compatibilidad con Ethereum ("EVM Equivalente"), y lo logra ejecutando un cliente de ejecución casi idéntico a un cliente Ethereum normal. Bedrock utiliza el próximo modelo de separación de clientes de consenso/ejecución de Ethereum, lo que reduce significativamente la variación del EVM (siempre se requerirán algunos cambios, pero podemos manejar esto). Mientras escribo esto, la diferencia de Bedrock Geth es un compromiso de +388 -30.

Como cualquier buen Rollup, Optimism toma datos de bloque/transacción de Ethereum, clasifica estos datos de forma determinista dentro del cliente de consenso y luego alimenta estos datos al cliente de ejecución L2 para su ejecución. Esta arquitectura resuelve la primera mitad del rompecabezas "ideal Rollup", dándonos un EVM Equivalente L2.

Por supuesto, ahora también debemos resolver el problema de cómo decir de manera comprobable lo que está sucediendo dentro de Ethereum Optimism. Sin esta característica, los contratos no pueden tomar decisiones basadas en el estado de Optimismo. Esto significaría que los usuarios pueden depositar en Optimism pero nunca retirar sus activos. Si bien en algunos casos un resumen unidireccional podría ser realmente útil, en general, un resumen bidireccional es más útil.

Podemos decirle a Ethereum el estado de cualquier Rollup al otorgar un compromiso con ese estado y una prueba de que el compromiso se generó correctamente. Otra forma de decir esto es que estamos demostrando que el "programa Rollup" se ejecutó correctamente. La única diferencia real entre ZK y Optimistic Rollups es la forma de esta prueba. En ZK Rollup, debe proporcionar una prueba ZK explícita de que el programa se ejecuta correctamente. En Optimistic Rollup, hace afirmaciones sobre promesas, pero no pruebas explícitas. Otros usuarios pueden desafiar sus afirmaciones y forzarlo a jugar un juego iterativo en el que eventualmente descubrirá quién tiene razón.

No entraré en demasiados detalles sobre el juego de desafío Optimistic Rollup. Vale la pena señalar que el estado del arte en este juego es compilar su programa (Geth EVM + algunas partes marginales en el caso de Optimism) en una arquitectura de máquina simple como MIPS. Hacemos esto porque necesitamos construir un intérprete para nuestro programa en cadena, y es mucho más fácil construir un intérprete MIPS que un intérprete EVM. El EVM también es un objetivo móvil (tenemos bifurcaciones de actualización regulares) y no cubre los programas que queremos probar (también hay algunas cosas que no son EVM).

Una vez que haya creado un intérprete en cadena para la arquitectura de su máquina simple y haya creado algunas herramientas fuera de la cadena, debería tener un Optimistic Rollup completamente funcional.

Convertido a ZK Rollup

En general, creo que Optimistic Rollups dominará al menos durante los próximos años. Algunas personas piensan que ZK Rollups eventualmente superará a Optimistic Rollups, pero creo que esto puede estar equivocado. Creo que la relativa simplicidad y flexibilidad de Optimistic Rollups hoy significa que pueden transformarse en ZK Rollups con el tiempo. Si podemos encontrar un modelo que lo haga posible, realmente no hay un fuerte incentivo para implementar uno menos flexible y más frágil cuando simplemente puede implementar un sistema Optimistic existente y llamarlo un sistema ZK de trabajo diario.

Por lo tanto, mi objetivo es crear una arquitectura y una ruta de migración para que los sistemas optimistas modernos existentes (como Bedrock) puedan transformarse sin problemas en sistemas ZK. Así es como creo que esto no solo es posible, sino que va más allá del enfoque actual de zkEVM.

Comenzamos con la arquitectura de estilo Bedrock que describí anteriormente. Tenga en cuenta que expliqué (brevemente) cómo Bedrock tiene un juego de desafío que afirma el programa L2 (ejecutando el EVM + algunas cosas adicionales para convertirlo en un ZK Rollup

En general, creo que Optimistic Rollups dominará en los próximos años. Existe la opinión de que ZK Rollup eventualmente superará a Optimistic Rollup, pero creo que esto puede estar equivocado. Creo que la relativa simplicidad y flexibilidad de Optimistic Rollups significa que pueden transformarse en ZK Rollups con el tiempo. Si podemos encontrar un modelo para que ocurra esta transición, realmente no hay un fuerte incentivo para implementar sistemas ZK menos flexibles y más propensos a problemas.

Por lo tanto, mi objetivo es crear una arquitectura y una ruta de migración que permita que los sistemas optimistas modernos existentes (como Bedrock) realicen una transición sin problemas a los sistemas ZK. Aquí hay, creo, una manera no solo de hacer que esta transición suceda, sino de hacerlo de una manera que va más allá del enfoque actual de zkEVM.

Comenzamos con la arquitectura de estilo Bedrock que describí anteriormente. Tenga en cuenta que expliqué (brevemente) cómo Bedrock tiene un juego de desafío que puede afirmar la validez de la ejecución de un programa L2 (un programa MIPS que ejecuta el EVM + algunos extras). Uno de los principales inconvenientes de este enfoque es que debemos permitir un período de tiempo para que un usuario detecte y cuestione con éxito una propuesta de resultado de programa falsa. Esto agrega una cantidad considerable de tiempo al proceso de retiro de activos (actualmente 7 días en la red principal de Optimism).

Sin embargo, nuestro L2 es solo un programa que se ejecuta en una máquina simple (MIPS). Es completamente posible construir un circuito ZK para una máquina tan simple. Luego podemos usar este circuito para probar sin ambigüedades la ejecución correcta del programa L2. Sin realizar ningún cambio en el código base actual de Bedrock, puede comenzar a publicar pruebas de validez para Optimism. Es realmente así de simple.

Por qué este método funciona tan bien

Nota rápida: en esta sección, mencioné "zkMIPS", pero en realidad lo estoy usando para referirme a cualquier zkVM genérico "simple".

zkMIPS es más simple que zkEVM

Una gran ventaja de construir un zkMIPS (o zk[insert other machine name]) en lugar de zkEVM es que la arquitectura de la máquina de destino es simple y estática. EVM cambia con frecuencia. Los precios de la gasolina cambiarán, los códigos de operación se ajustarán y se agregarán o eliminarán cosas. Y MIPS-V no ha cambiado desde 1996. Al apuntar a zkMIPS, trabaja en un espacio de problema fijo. No necesita cambiar y posiblemente volver a auditar su circuito cada vez que se actualiza el EVM.

zkMIPS es más flexible que zkEVM

Otro punto clave de controversia es que zkMIPS es más flexible que zkEVM. Con zkMIPS, tiene más flexibilidad para modificar el código del cliente a voluntad para lograr varias optimizaciones o mejoras en la experiencia del usuario. Las actualizaciones de clientes ya no necesitan venir con actualizaciones de circuitos. También puede crear un componente central que se puede usar para convertir cualquier blockchain en un ZK Rollup, no solo Ethereum.

Tu pregunta se convierte en tiempo de prueba

El tiempo de la prueba ZK se escala a lo largo de dos ejes: número de restricciones y tamaño del circuito. Al centrarnos en los circuitos de una máquina simple como MIPS (en lugar de una máquina más compleja como EVM), pudimos reducir significativamente el tamaño y la complejidad del circuito. Sin embargo, el número de restricciones depende del número de instrucciones de máquina ejecutadas. Cada código de operación EVM se divide en múltiples códigos de operación MIPS, lo que significa que la cantidad de restricciones aumenta significativamente, al igual que el tiempo de prueba general.

Pero reducir los tiempos de prueba es un problema firmemente arraigado en el espacio Web2. Dado que la arquitectura de la máquina MIPS no cambiará en un futuro cercano, podemos optimizar altamente nuestros circuitos y programas de prueba sin preocuparnos por los cambios de EVM en una etapa posterior. Estoy bastante seguro de que el grupo de contratación para ingenieros de hardware que pueden optimizar un programa bien definido es al menos 10 (si no 100) veces mayor que el grupo de contratación para construir y auditar un objetivo zkEVM en constante cambio. Una empresa como Netflix probablemente tenga muchos ingenieros de hardware trabajando en la optimización de chips de transcodificación, y estarían encantados de aceptar un montón de dinero de capital de riesgo para abordar un interesante desafío de ZK.

El tiempo de prueba inicial para dicho circuito puede exceder el período de retiro de Optimistic Rollup de 7 días. Este tiempo de prueba solo disminuirá con el tiempo. Al introducir ASIC y FPGA, podemos acelerar considerablemente el tiempo de prueba. Con un objetivo estático, podemos construir probadores más óptimos.

Eventualmente, el tiempo de prueba para este circuito será más bajo que el período de retiro actual de Optimistic Rollup de 7 días, y podemos comenzar el proceso de desafío para considerar cancelar Optimistic. Ejecutar una prueba durante 7 días aún puede ser demasiado costoso, por lo que es posible que deseemos esperar un poco más, pero el punto sigue siendo válido. Incluso puede ejecutar ambos sistemas de prueba al mismo tiempo, de modo que podamos comenzar a usar las pruebas ZK de inmediato y, si por alguna razón el programa de prueba falla, podemos recurrir a las pruebas optimistas. Cuando esté listo, es fácil pasar a las pruebas ZK de una manera completamente transparente para la aplicación. Ningún otro sistema ofrece esta flexibilidad y esta ruta de migración fluida.

Puedes enfocarte en otros asuntos importantes

Ejecutar una cadena de bloques es una tarea difícil, y no solo implica escribir una gran cantidad de código de back-end. Gran parte de lo que hacemos en Optimism se centra en mejorar la experiencia del usuario y del desarrollador a través de herramientas útiles del lado del cliente. También invertimos mucho tiempo y energía lidiando con las cosas "suaves": hablar con los proyectos, comprender los puntos débiles, diseñar incentivos. Cuanto más tiempo pase en el software de cadena de bloques, menos tiempo pasará pensando en estas otras cosas. Siempre puede intentar contratar a más personas, pero las organizaciones no escalan de forma lineal y cada nueva contratación aumenta la carga de comunicación interna.

Dado que el trabajo del circuito ZK se puede agregar a una cadena en ejecución existente, puede trabajar en la construcción de la plataforma central y el software de prueba en paralelo. Además, dado que el cliente se puede modificar sin cambiar el circuito, puede separar los equipos de cliente y atestación. Un resumen optimista que adopte este enfoque podría estar muchos años por delante de los competidores de ZK en términos de actividad real en la cadena.

** A **** ALGUNAS CONCLUSIONES **

Para ser completamente franco, no veo ninguna desventaja significativa en este enfoque, suponiendo que el probador zkMIPS se pueda optimizar sustancialmente con el tiempo. El único impacto real que veo en la aplicación es que es posible que los costos de gas para diferentes códigos de operación deban ajustarse para reflejar el tiempo de prueba agregado por esos códigos de operación. Si es realmente imposible optimizar este probador a un nivel razonable, entonces admito la derrota. Si es realmente posible optimizar este probador, entonces el enfoque zkMIPS/zkVM parece ser mucho mejor que el enfoque zkEVM actual que podría volver completamente obsoleto a este último. Esto puede parecer una declaración radical, pero no hace mucho tiempo, las pruebas de falla optimistas de un solo paso fueron reemplazadas por completo por pruebas de varios pasos.