Título original: "OP+ZK, ¿Hybrid Rollup se convertirá en el futuro definitivo de la expansión de Ethereum?" "
Publicación original de @kelvinfichter
Recopilación original: Jaleel, BlockBeats
Recientemente me he convencido bastante de que el futuro de Ethereum Rollup es en realidad un híbrido de los dos enfoques principales, ZK y Optimistic. En esta publicación, intentaré exponer los conceptos básicos de lo que imagino que es esta arquitectura y por qué creo que esta es la dirección que deberíamos tomar. Tenga en cuenta que paso la mayor parte de mi tiempo trabajando en Optimism, también conocido como Optimistic Rollup, pero no soy un experto en ZK. Si cometí algún error al hablar sobre ZK, no dude en comunicarse conmigo y lo corregiré.
No pretendo describir en detalle el principio de funcionamiento de ZK y Optimistic Rollups en este artículo, si dedico tiempo a explicar la esencia de los Rollups, entonces este artículo será demasiado largo. Por lo tanto, este artículo se basa en el hecho de que ya tiene una cierta comprensión de estas tecnologías. Por supuesto, no necesita ser un experto, pero al menos debe saber qué son ZK y Optimistic Rollups y su mecanismo de funcionamiento general. De todos modos, disfruta leyendo este artículo.
Comencemos con Optimistic Rollup
El sistema que mezcló ZK y Optimistic Rollup se basó originalmente en Optimistic Rollup basado en la arquitectura Bedrock de Optimism. Bedrock está diseñado para ser máximamente compatible ("equivalente a EVM") con Ethereum mediante la ejecución de un cliente de ejecución casi idéntico al cliente de Ethereum. Bedrock aprovecha el próximo modelo de división de clientes de consenso/ejecución de Ethereum, lo que reduce significativamente la variación del EVM (por supuesto, siempre habrá algunos cambios en el camino, pero podemos manejarlo).
Como todos los buenos Rollups, Optimism extrae datos de bloques/transacciones de Ethereum, luego clasifica estos datos de forma determinista en el cliente de consenso y envía estos datos al cliente de ejecución L2 para su ejecución. Esta arquitectura resuelve la primera mitad del rompecabezas "ideal Rollup" y nos brinda un L2 equivalente al EVM.
Por supuesto, el problema que aún debemos resolver ahora es decirle a Ethereum lo que sucedió dentro de Optimism de una manera verificable. Si este problema no se resuelve, los contratos inteligentes no pueden tomar decisiones basadas en el estado de Optimismo. Esto significará que los usuarios pueden depositar en Optimism, pero no pueden retirar sus activos. Aunque la acumulación unidireccional es posible en algunos casos, en la mayoría de los casos, la acumulación bidireccional es más efectiva.
Al proporcionar algún tipo de compromiso con este estado y una prueba de que este compromiso es correcto, podemos comunicar el estado de todos los acumulativos a Ethereum. En otras palabras, estamos demostrando que el "Programa Rollup" se ejecutó correctamente. La única diferencia sustancial entre ZK y Optimistic Rollups es la forma de esta prueba. En ZK Rollup, debe proporcionar una prueba explícita de conocimiento cero para demostrar la ejecución correcta del programa. En Optimistic Rollup, puede hacer una declaración sobre la promesa sin proporcionar pruebas claras. Al desafiar y cuestionar su declaración, otros usuarios pueden obligarlo a participar en un "juego" de deliberación y desafío para determinar quién es finalmente Sí.
No voy a entrar en detalles sobre los desafíos de Optimistic Rollup. Vale la pena señalar que el estado del arte en esta etapa es compilar su programa (Geth EVM + algunos bits marginales en el caso de Optimism) en una arquitectura de máquina simple como MIPS. Hacemos esto porque necesitamos construir un intérprete de 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 completamente 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 línea, debería tener un Optimistic Rollup completamente funcional.
Gire a ZK Rollup
En general, creo firmemente que Optimistic Rollups dominará durante los próximos años. Algunas personas piensan que ZK Rollups eventualmente superará a Optimistic Rollups, pero no estoy de acuerdo con esta opinión. Siento que la relativa simplicidad y flexibilidad actuales de Optimistic Rollups significa que pueden transformarse gradualmente en ZK Rollups. Si podemos encontrar un patrón para hacer esta transición, entonces, en lugar de intentar construir un ecosistema ZK más inflexible y frágil, simplemente podemos implementarlo en un ecosistema Optimistic Rollup ya existente.
Por lo tanto, mi objetivo es crear una arquitectura y una ruta de migración que permitan que un ecosistema OP moderno existente (como Bedrock) haga la transición sin problemas a un ecosistema ZK. Creo que esto no solo es posible, sino una forma de ir más allá del enfoque actual de zkEVM.
Comencemos con la arquitectura Bedrock que describí anteriormente. Tenga en cuenta que he explicado (brevemente) que Bedrock tiene un juego de desafío para verificar la validez de ciertas ejecuciones de programas L2 (programas MIPS que ejecutan EVM + algunas cosas adicionales). Una desventaja importante de este enfoque es que debemos permitir un período de tiempo para que los usuarios tengan la oportunidad de detectar y desafiar con éxito una propuesta de resultado de programa incorrecta. Esto agrega una cantidad considerable de tiempo al proceso de retiro de activos (7 días en la red principal actual de Optimism).
Sin embargo, nuestro L2 no es más que un programa que se ejecuta en una máquina simple como MIPS. Es completamente posible para nosotros construir un circuito ZK para un mecanismo 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 así de simple en la práctica.
¿Por qué este método es confiable?
Solo una aclaración rápida: aunque en esta sección menciono "zkMIPS", en realidad lo digo como un término para todas las máquinas virtuales generales y simplificadas de prueba de conocimiento cero (zkVM).
zkMIPS es más fácil que zkEVM
Construir un zkMIPS (o cualquier otro tipo de máquina virtual zk) tiene una gran ventaja sobre zkEVM: la arquitectura de la máquina de destino es simple y estática. El EVM cambia con frecuencia, los precios de la gasolina se ajustan, los códigos de operación cambian y se agregan o eliminan elementos. Y MIPS-V no ha cambiado desde 1996. Concéntrese en zkMIPS y estará lidiando con un espacio de problema fijo. No necesita cambiar o incluso volver a auditar su circuito cada vez que se actualiza el EVM.
zkMIPS es más flexible que zkEVM
Otra idea clave es que zkMIPS es más flexible que zkEVM. Con zkMIPS, puede cambiar el código del cliente a voluntad, realizar varias optimizaciones o mejorar la experiencia del usuario sin las actualizaciones de circuito correspondientes. Incluso puede crear un componente central que convierta cualquier blockchain en un ZK Rollup, no solo Ethereum.
Tu misión se convierte en tiempo de prueba
El tiempo de las pruebas de conocimiento cero escala a lo largo de dos ejes: el número de restricciones y el 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 su tiempo de prueba general.
Sin embargo, reducir los tiempos de prueba también es un problema profundamente arraigado en el dominio Web2. Dado que es poco probable que la arquitectura de la máquina MIPS cambie en el corto plazo, podemos optimizar en gran medida el circuito y el probador independientemente de los cambios futuros en el EVM. Me siento bastante seguro al contratar a un ingeniero de hardware sénior para optimizar un problema bien definido, quizás diez o incluso cien veces la cantidad de ingenieros que construyen y revisan un objetivo zkEVM en movimiento. Una empresa como Netflix probablemente tiene una gran cantidad de ingenieros de hardware que optimizan los chips de transcodificación, y es probable que estén dispuestos a gastar una gran cantidad de fondos de capital de riesgo para asumir este interesante desafío ZK.
El tiempo de prueba inicial para un circuito como este 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 significativamente el tiempo de prueba. Con un objetivo estático, podemos construir probadores más óptimos.
Eventualmente, el tiempo de prueba para este circuito será menor que el actual período de retiro de Optimism de 7 días, y podemos comenzar el proceso de desafío para considerar la eliminación de Optimism. Ejecutar un probador durante 7 días probablemente todavía sea demasiado costoso, por lo que es posible que deseemos esperar un poco más, pero el punto es defendible. Incluso puede ejecutar ambos sistemas de prueba al mismo tiempo, por lo que podemos comenzar a usar las pruebas ZK lo más rápido posible y recurrir a las pruebas Optimism si el probador falla por algún motivo. Cuando estén listas, las pruebas de Optimism se pueden eliminar de una manera completamente transparente para la aplicación, por lo que su Optimistic Rollup se convierte en un ZK Rollup.
Puedes ir y preocuparte por otros asuntos importantes
Ejecutar una cadena de bloques es un problema complejo que implica más que solo escribir una gran cantidad de código de back-end. En Optimism, gran parte de nuestro trabajo se centra en mejorar la experiencia del usuario y del desarrollador al proporcionar herramientas útiles del lado del cliente. También dedicamos mucho tiempo y energía a los temas "suaves": tener conversaciones con proyectos, comprender sus puntos débiles y diseñar incentivos. Cuanto más tiempo dedique al software de cadena, menos tiempo tendrá para ocuparse de estas otras cosas. Si bien siempre puede intentar contratar a más personas, las organizaciones no escalan linealmente y cada nueva contratación aumenta los costos de comunicación interna.
Dado que el trabajo del circuito de conocimiento cero se puede aplicar directamente a la cadena que ya se está ejecutando, puede construir la plataforma central y desarrollar el software de prueba al mismo tiempo. Dado que el cliente se puede modificar sin cambiar el circuito, puede desacoplar su cliente y el equipo de prueba. Un resumen optimista de esta manera podría estar años por delante de los competidores de conocimiento cero en términos de actividad real en la cadena.
en conclusión
Francamente, no veo ninguna desventaja significativa en el probador zkMIPS, a menos que no pueda optimizarse significativamente con el tiempo. El único impacto real que veo en la aplicación es que es posible que sea necesario ajustar el costo del gas de los diferentes códigos de operación para reflejar el mayor tiempo de prueba para estos códigos de operación. Si realmente no es posible optimizar este probador a un nivel razonable, entonces admito que he fallado. Pero si es posible optimizar este probador, entonces el enfoque zkMIPS/zkVM puede reemplazar completamente el enfoque zkEVM actual. Eso puede sonar como 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.
Enlace original
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
¿Será la mezcla de ZK y OP el futuro del Ethereum Rollup?
Título original: "OP+ZK, ¿Hybrid Rollup se convertirá en el futuro definitivo de la expansión de Ethereum?" "
Publicación original de @kelvinfichter
Recopilación original: Jaleel, BlockBeats
Recientemente me he convencido bastante de que el futuro de Ethereum Rollup es en realidad un híbrido de los dos enfoques principales, ZK y Optimistic. En esta publicación, intentaré exponer los conceptos básicos de lo que imagino que es esta arquitectura y por qué creo que esta es la dirección que deberíamos tomar. Tenga en cuenta que paso la mayor parte de mi tiempo trabajando en Optimism, también conocido como Optimistic Rollup, pero no soy un experto en ZK. Si cometí algún error al hablar sobre ZK, no dude en comunicarse conmigo y lo corregiré.
No pretendo describir en detalle el principio de funcionamiento de ZK y Optimistic Rollups en este artículo, si dedico tiempo a explicar la esencia de los Rollups, entonces este artículo será demasiado largo. Por lo tanto, este artículo se basa en el hecho de que ya tiene una cierta comprensión de estas tecnologías. Por supuesto, no necesita ser un experto, pero al menos debe saber qué son ZK y Optimistic Rollups y su mecanismo de funcionamiento general. De todos modos, disfruta leyendo este artículo.
Comencemos con Optimistic Rollup
El sistema que mezcló ZK y Optimistic Rollup se basó originalmente en Optimistic Rollup basado en la arquitectura Bedrock de Optimism. Bedrock está diseñado para ser máximamente compatible ("equivalente a EVM") con Ethereum mediante la ejecución de un cliente de ejecución casi idéntico al cliente de Ethereum. Bedrock aprovecha el próximo modelo de división de clientes de consenso/ejecución de Ethereum, lo que reduce significativamente la variación del EVM (por supuesto, siempre habrá algunos cambios en el camino, pero podemos manejarlo).
Como todos los buenos Rollups, Optimism extrae datos de bloques/transacciones de Ethereum, luego clasifica estos datos de forma determinista en el cliente de consenso y envía estos datos al cliente de ejecución L2 para su ejecución. Esta arquitectura resuelve la primera mitad del rompecabezas "ideal Rollup" y nos brinda un L2 equivalente al EVM.
Por supuesto, el problema que aún debemos resolver ahora es decirle a Ethereum lo que sucedió dentro de Optimism de una manera verificable. Si este problema no se resuelve, los contratos inteligentes no pueden tomar decisiones basadas en el estado de Optimismo. Esto significará que los usuarios pueden depositar en Optimism, pero no pueden retirar sus activos. Aunque la acumulación unidireccional es posible en algunos casos, en la mayoría de los casos, la acumulación bidireccional es más efectiva.
Al proporcionar algún tipo de compromiso con este estado y una prueba de que este compromiso es correcto, podemos comunicar el estado de todos los acumulativos a Ethereum. En otras palabras, estamos demostrando que el "Programa Rollup" se ejecutó correctamente. La única diferencia sustancial entre ZK y Optimistic Rollups es la forma de esta prueba. En ZK Rollup, debe proporcionar una prueba explícita de conocimiento cero para demostrar la ejecución correcta del programa. En Optimistic Rollup, puede hacer una declaración sobre la promesa sin proporcionar pruebas claras. Al desafiar y cuestionar su declaración, otros usuarios pueden obligarlo a participar en un "juego" de deliberación y desafío para determinar quién es finalmente Sí.
No voy a entrar en detalles sobre los desafíos de Optimistic Rollup. Vale la pena señalar que el estado del arte en esta etapa es compilar su programa (Geth EVM + algunos bits marginales en el caso de Optimism) en una arquitectura de máquina simple como MIPS. Hacemos esto porque necesitamos construir un intérprete de 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 completamente 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 línea, debería tener un Optimistic Rollup completamente funcional.
Gire a ZK Rollup
En general, creo firmemente que Optimistic Rollups dominará durante los próximos años. Algunas personas piensan que ZK Rollups eventualmente superará a Optimistic Rollups, pero no estoy de acuerdo con esta opinión. Siento que la relativa simplicidad y flexibilidad actuales de Optimistic Rollups significa que pueden transformarse gradualmente en ZK Rollups. Si podemos encontrar un patrón para hacer esta transición, entonces, en lugar de intentar construir un ecosistema ZK más inflexible y frágil, simplemente podemos implementarlo en un ecosistema Optimistic Rollup ya existente.
Por lo tanto, mi objetivo es crear una arquitectura y una ruta de migración que permitan que un ecosistema OP moderno existente (como Bedrock) haga la transición sin problemas a un ecosistema ZK. Creo que esto no solo es posible, sino una forma de ir más allá del enfoque actual de zkEVM.
Comencemos con la arquitectura Bedrock que describí anteriormente. Tenga en cuenta que he explicado (brevemente) que Bedrock tiene un juego de desafío para verificar la validez de ciertas ejecuciones de programas L2 (programas MIPS que ejecutan EVM + algunas cosas adicionales). Una desventaja importante de este enfoque es que debemos permitir un período de tiempo para que los usuarios tengan la oportunidad de detectar y desafiar con éxito una propuesta de resultado de programa incorrecta. Esto agrega una cantidad considerable de tiempo al proceso de retiro de activos (7 días en la red principal actual de Optimism).
Sin embargo, nuestro L2 no es más que un programa que se ejecuta en una máquina simple como MIPS. Es completamente posible para nosotros construir un circuito ZK para un mecanismo 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 así de simple en la práctica.
¿Por qué este método es confiable?
Solo una aclaración rápida: aunque en esta sección menciono "zkMIPS", en realidad lo digo como un término para todas las máquinas virtuales generales y simplificadas de prueba de conocimiento cero (zkVM).
zkMIPS es más fácil que zkEVM
Construir un zkMIPS (o cualquier otro tipo de máquina virtual zk) tiene una gran ventaja sobre zkEVM: la arquitectura de la máquina de destino es simple y estática. El EVM cambia con frecuencia, los precios de la gasolina se ajustan, los códigos de operación cambian y se agregan o eliminan elementos. Y MIPS-V no ha cambiado desde 1996. Concéntrese en zkMIPS y estará lidiando con un espacio de problema fijo. No necesita cambiar o incluso volver a auditar su circuito cada vez que se actualiza el EVM.
zkMIPS es más flexible que zkEVM
Otra idea clave es que zkMIPS es más flexible que zkEVM. Con zkMIPS, puede cambiar el código del cliente a voluntad, realizar varias optimizaciones o mejorar la experiencia del usuario sin las actualizaciones de circuito correspondientes. Incluso puede crear un componente central que convierta cualquier blockchain en un ZK Rollup, no solo Ethereum.
Tu misión se convierte en tiempo de prueba
El tiempo de las pruebas de conocimiento cero escala a lo largo de dos ejes: el número de restricciones y el 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 su tiempo de prueba general.
Sin embargo, reducir los tiempos de prueba también es un problema profundamente arraigado en el dominio Web2. Dado que es poco probable que la arquitectura de la máquina MIPS cambie en el corto plazo, podemos optimizar en gran medida el circuito y el probador independientemente de los cambios futuros en el EVM. Me siento bastante seguro al contratar a un ingeniero de hardware sénior para optimizar un problema bien definido, quizás diez o incluso cien veces la cantidad de ingenieros que construyen y revisan un objetivo zkEVM en movimiento. Una empresa como Netflix probablemente tiene una gran cantidad de ingenieros de hardware que optimizan los chips de transcodificación, y es probable que estén dispuestos a gastar una gran cantidad de fondos de capital de riesgo para asumir este interesante desafío ZK.
El tiempo de prueba inicial para un circuito como este 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 significativamente el tiempo de prueba. Con un objetivo estático, podemos construir probadores más óptimos.
Eventualmente, el tiempo de prueba para este circuito será menor que el actual período de retiro de Optimism de 7 días, y podemos comenzar el proceso de desafío para considerar la eliminación de Optimism. Ejecutar un probador durante 7 días probablemente todavía sea demasiado costoso, por lo que es posible que deseemos esperar un poco más, pero el punto es defendible. Incluso puede ejecutar ambos sistemas de prueba al mismo tiempo, por lo que podemos comenzar a usar las pruebas ZK lo más rápido posible y recurrir a las pruebas Optimism si el probador falla por algún motivo. Cuando estén listas, las pruebas de Optimism se pueden eliminar de una manera completamente transparente para la aplicación, por lo que su Optimistic Rollup se convierte en un ZK Rollup.
Puedes ir y preocuparte por otros asuntos importantes
Ejecutar una cadena de bloques es un problema complejo que implica más que solo escribir una gran cantidad de código de back-end. En Optimism, gran parte de nuestro trabajo se centra en mejorar la experiencia del usuario y del desarrollador al proporcionar herramientas útiles del lado del cliente. También dedicamos mucho tiempo y energía a los temas "suaves": tener conversaciones con proyectos, comprender sus puntos débiles y diseñar incentivos. Cuanto más tiempo dedique al software de cadena, menos tiempo tendrá para ocuparse de estas otras cosas. Si bien siempre puede intentar contratar a más personas, las organizaciones no escalan linealmente y cada nueva contratación aumenta los costos de comunicación interna.
Dado que el trabajo del circuito de conocimiento cero se puede aplicar directamente a la cadena que ya se está ejecutando, puede construir la plataforma central y desarrollar el software de prueba al mismo tiempo. Dado que el cliente se puede modificar sin cambiar el circuito, puede desacoplar su cliente y el equipo de prueba. Un resumen optimista de esta manera podría estar años por delante de los competidores de conocimiento cero en términos de actividad real en la cadena.
en conclusión
Francamente, no veo ninguna desventaja significativa en el probador zkMIPS, a menos que no pueda optimizarse significativamente con el tiempo. El único impacto real que veo en la aplicación es que es posible que sea necesario ajustar el costo del gas de los diferentes códigos de operación para reflejar el mayor tiempo de prueba para estos códigos de operación. Si realmente no es posible optimizar este probador a un nivel razonable, entonces admito que he fallado. Pero si es posible optimizar este probador, entonces el enfoque zkMIPS/zkVM puede reemplazar completamente el enfoque zkEVM actual. Eso puede sonar como 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.
Enlace original