Los Rollups nativos utilizan sus propios validadores de cambio de estado de STF de L1.
Escrito por: Comunidad ChainNews
En los últimos dos años, Ethereum se ha comprometido completamente con la hoja de ruta del "centro de rollup". Esta estrategia implica bloquear ETH en contratos de puente, realizar transacciones fuera de la cadena y utilizar pruebas, ya sea pruebas de fraude o pruebas de conocimiento cero (ZKP), para verificar el estado de Layer2 (L2) y procesar retiros.
Sin embargo, existe un desafío importante: Ethereum no verifica nativamente la ejecución de EVM, lo que obliga a los rollups a implementar sus propios sistemas de prueba en la cadena para verificar las transiciones de estado.
Ethereum ha experimentado frecuentes bifurcaciones duras, lo que podría modificar el EVM, lo que significa que los equipos de rollups deben ser responsables de mantener y actualizar sus implementaciones personalizadas. Esto generalmente requiere la creación de un comité de seguridad o la adopción de un sistema de gobernanza basado en tokens para gestionar las actualizaciones de sus contratos de puente y mecanismos de prueba.
En nuestra serie anterior, discutimos Based rollup y Booster rollup. Ahora, nos centraremos en explorar más a fondo el concepto de rollup nativo.
¿Cuál es la diferencia entre Based, Booster y Native?
Entre las definiciones de rollup basado, rollup de refuerzo y rollup nativo puede haber mucha confusión. En entregas anteriores, ya hemos presentado el rollup basado y el rollup de refuerzo, por lo que se recomienda revisar ese contenido antes de leer este artículo. Sin embargo, haremos una revisión rápida de estos tres tipos.
Los rollups basados utilizan conjuntos de validadores de L1 para ordenar transacciones, fomentando la descentralización, pero pueden afectar la capacidad de transacción debido al tiempo de bloque relativamente largo de L1 (por ejemplo, 12 segundos). Sin embargo, se está trabajando arduamente para mejorar esta experiencia, utilizando tecnologías de preconfirmación para permitir a los usuarios disfrutar de confirmaciones de transacciones más rápidas mientras la comunidad continúa innovando.
Booster Rollups a través de la simulación de procesamiento en L1 en L2 para ampliar la ejecución y el almacenamiento, permite que las aplicaciones crezcan sin necesidad de volver a implementarse. Aunque este enfoque proporciona escalabilidad, en comparación con los rollups tradicionales, introduce una complejidad adicional que requiere un esfuerzo de ingeniería más complejo para el desarrollo y mantenimiento.
Los Rollups nativos utilizan la funcionalidad de transferencia de estados (STF) de L1 como validador de la transición de estados en la Capa de aplicación. Sin embargo, aunque Optimism, Arbitrum y otros rollups funcionan en un entorno EVM equivalente, a menudo contienen modificaciones personalizadas complejas o poco prácticas que no se pueden implementar directamente en Ethereum.
Los rollups nativos solían ser llamados rollups de derecho, y han sido discutidos en varios escritos. Además, el término "rollup específico" fue brevemente utilizado por @apolynya. Sin embargo, el término "de derecho" finalmente fue reemplazado por "nativo" para indicar que los rollups equivalentes a EVM existentes podrían actualizarse a este modelo. El término "nativo" fue propuesto por @danrobinson y un contribuyente anónimo de Lido.
¿Cómo funciona rollup nativo?
La propuesta nativa rollup introduce la precompilación EXECUTE, que sirve como validador de la transición de estado rollup. Esta precompilación permitirá al equipo de rollup usarla en sus contratos validadores, proporcionando un sistema de pruebas basado y permitiendo que rollup herede la validación nativa de Ethereum.
Dado que este nuevo precompilado es en cierto modo similar al concepto de 'EVM dentro de EVM'，se actualizará a través del proceso de hard fork de Ethereum bajo su consenso social. Esto garantiza que los cambios en EVM se reflejen en el precompilado，permitiendo que rollups herede la validación de Ethereum y alivie al equipo de rollup de la responsabilidad de gobernanza en comités de seguridad o firmas múltiples，lo que hace que rollup sea más seguro para los usuarios en esencia.
EJECUTAR precompilado como validador de transiciones de estado de EVM, permite que rollup utilice las instalaciones nativas de Ethereum en la Capa de aplicación. Utiliza entradas como pre_state_root, post_state_root, traza y gas_used para verificar la transición, aprovechando un mecanismo de fijación de precios de gas similar a EIP-1559. Según las necesidades de escalabilidad de rollup, los validadores pueden hacer cumplir la corrección de la transición de estado de rollup mediante la reejecución o las pruebas SNARK. Además, se integra un retraso en un slot para mitigar el riesgo de centralización, como la competencia de pruebas basadas en MEV.
Esta precompilación simplifica el desarrollo de rollups al admitir 'rollups' sin confianza en el sistema de prueba. Cuando se combina con el diseño de rollup basado, donde tanto el sistema de ordenación como el de prueba son gestionados por Ethereum, esta estructura puede lograr una completa falta de confianza, comúnmente conocida como 'rollup' ultrasonido. Mejora la composabilidad y tiene el potencial de liquidación en tiempo real, lo que fomenta un diseño de rollup más seguro y con mayor capacidad de composición.
El comportamiento precompilado propuesto es similar al de EVM, reejecutando transacciones de rollup para verificar su corrección. Esto va en contra de la ventaja central de rollup, ya que la ventaja de rollup radica en la ejecución fuera de la cadena, solo presentando pruebas de validez a Ethereum. Por el contrario, la precompilación refleja esencialmente lo que Ethereum ya está haciendo y no agrega valor en la reducción de la carga computacional de L1.
La elección de un validador similar a EVM en lugar de un validador zk se deriva de la inmadurez actual de la tecnología ZK. La zkVM actualmente ampliamente utilizada ha mostrado vulnerabilidad, y la rápida evolución de ZKP hace que codificar validadores zk específicos en la cadena sea arriesgado e inflexible. En cambio, Ethereum prioriza la diversidad y la neutralidad, lo que permite experimentar con diferentes clientes ZK sin depender de un solo validador.
Sin embargo, esto no significa que la precompilación no haya contribuido a la escalabilidad de Ethereum. A pesar de que Ethereum mantiene los verificadores de pruebas de conocimiento cero fuera de la cadena para garantizar su seguridad, utiliza esta precompilación para verificar las pruebas de conocimiento cero presentadas por rollups. Esto permite a los verificadores de Ethereum evitar simular todas las transacciones de rollup de principio a fin. En cambio, al depender de las pruebas de conocimiento cero fuera de la cadena, la red mantiene su garantía de seguridad, al tiempo que trabaja para lograr la escalabilidad en la ejecución.
¿Cuáles son las principales ventajas de rollup nativo?
A través de rollups nativos, muchos trabajos complejos pueden ser preprocesados, lo que hace que la verificación de fraude o SNARK sea más simple. Esto significa menos código para escribir y mantener, sin necesidad de sistemas adicionales como redes de prueba o comités de seguridad.
Los costos de verificación de SNARK en la cadena son altos, por lo que muchos zk-rollup no liquidan transacciones con frecuencia para ahorrar costos. La precompilación de EXECUTE puede ayudar a reducir estos costos al empaquetar múltiples pruebas juntas a través de SNARK recursivo. Este enfoque puede hacer que la verificación de transacciones en rollup sea más eficiente, lo que hace que la verificación fuera de la cadena sea más rentable.
En rollups tradicionales, asegurar operaciones sin errores es un desafío, generalmente requiere extensas comprobaciones. Muchos equipos reducen el riesgo adoptando un orden centralizado para evitar la generación de bloques maliciosos. Sin embargo, mediante la ejecución nativa precompilada, es posible lograr un mecanismo de ordenamiento más seguro y sin permisos. Este enfoque permite que los rollups hereden la seguridad de L1 y la fungibilidad de los activos, ya que las transacciones se verifican directamente en el entorno de confianza de Ethereum.
Hay muchos rollups compatibles con EVM, pero casi ninguno equivalente a EVM: mantenerse al día con los cambios en la cadena principal generalmente requiere un equipo o sistema de votación para actualizar el rollup, lo que puede conllevar riesgos. Los rollups nativos pueden actualizarse automáticamente con la cadena principal, manteniendo todo sincronizado, sin necesidad de reglas adicionales o votantes.
Para los zk-rollups, lograr un tiempo de prueba extremadamente bajo, como por ejemplo 100 milisegundos, es una tarea de ingeniería altamente desafiante. En contraste, los rollups nativos pueden permitir un cronograma de tiempo de prueba más 'relajado', extendiéndolo a un intervalo completo. Este enfoque alivia la presión de generar pruebas de inmediato, lo que podría mejorar la confiabilidad y fortalecer la integración con L1.
¿Todos los rollups serán nativos?
Actualmente, todas las pilas de rollups, como OP Stack y Arbitrum Orbit Stack, tienen el potencial de convertirse en "rollups nativos", heredando directamente las características de seguridad de Ethereum. Esta actualización hará que los usuarios se sientan más satisfechos, ya que la seguridad se verá reforzada, y los equipos de rollup se sentirán más cómodos al no necesitar más un comité de seguridad. Al mismo tiempo, los equipos de rollup aún pueden seguir compitiendo proporcionando una capa de ordenación compartida eficiente y capturando las tarifas de ordenación para maximizar el MEV.
Sin embargo, no todos los rollups harán la transición a su forma nativa. Algunas características de L2 son inherentemente incompatibles con los rollups nativos, incluyendo tipos de transacciones únicos, diferentes métodos de contabilidad de gas y precompilaciones no encontradas en la cadena de bloques principal L1. La diversidad de VM entre los rollups de L2, cada uno compartiendo un mismo fundamento de seguridad, es una gran ventaja del ecosistema de L2 hoy en día, por ejemplo
@EclipseFND es rollups SVM
@movementlabsxyzMoveVM rollup
@Starknet es rollups CairoVM
Como señaló @doganeth_en, los rollups futuros se dividirán en tres categorías: rollups empresariales, rollups orientados al rendimiento y rollups nativos 'alineados'.
Las empresas se centrarán en la gestión, clasificación y posesión de sus rollups, lo que es ideal para aquellas que deseen tener un control similar al de la web2 en el orden de las transacciones, la ejecución y las aplicaciones.
Los rollups centrados en el rendimiento utilizarán liquidaciones de Ethereum, pero dependerán de la disponibilidad de datos alternativos para lograr el mejor rendimiento, por ejemplo @megaeth_labs utiliza @eigen_da para lograr la disponibilidad de datos. Estos rollups tienen un menor grado de descentralización, pero aumentan la utilidad de ETH, aunque sacrifican algunas características de Ethereum.
Los rollups nativos se integrarán completamente con la infraestructura Based de Ethereum y proporcionarán: descentralización a nivel de Ethereum, ejecución compartida con acceso directo al estado y verificación más económica de pruebas de conocimiento cero fuera de la cadena. Estos rollups contribuyen al efecto de red de Ethereum, pueden compartir ingresos, pero su sostenibilidad depende de los incentivos económicos naturales.
Conclusión
Los rollups nativos representan un gran avance en la hoja de ruta central de rollup de Ethereum, ofreciendo un enfoque más alineado con las infraestructuras basadas en Ethereum. Al introducir la precompilación EXECUTE, los rollups nativos simplifican la gobernanza, eliminando la dependencia de las firmas múltiples, comités de seguridad o sistemas de votación basados en tokens. Este enfoque no solo mejora la seguridad, sino que también permite una escalabilidad más eficiente de los rollups, aprovechando las pruebas zk fuera de la cadena, garantizando así la minimización de la confianza y la escalabilidad.
A pesar de las amplias perspectivas de esta propuesta, no está exenta de desafíos. Aunque la mayoría de los rollups existentes se denominan equivalentes a EVM, suelen tener modificaciones ligeras en el EVM. Por lo tanto, la transición al modelo de rollup nativo podría suponer una carga adicional de desarrollo para los rollups que tienen implementaciones personalizadas de EVM.
Sin embargo, los rollups nativos ofrecen un camino llamativo para combinar la seguridad y flexibilidad de Ethereum con el diseño de rollup. Al fomentar la alineación con L1, fomentan la innovación, al tiempo que reducen la fragmentación, lo que hace que el ecosistema de Ethereum sea más sólido y resistente en el futuro.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Desglosando la próxima generación de Ethereum L2: Rollups nativos
Los Rollups nativos utilizan sus propios validadores de cambio de estado de STF de L1.
Escrito por: Comunidad ChainNews
En los últimos dos años, Ethereum se ha comprometido completamente con la hoja de ruta del "centro de rollup". Esta estrategia implica bloquear ETH en contratos de puente, realizar transacciones fuera de la cadena y utilizar pruebas, ya sea pruebas de fraude o pruebas de conocimiento cero (ZKP), para verificar el estado de Layer2 (L2) y procesar retiros.
Sin embargo, existe un desafío importante: Ethereum no verifica nativamente la ejecución de EVM, lo que obliga a los rollups a implementar sus propios sistemas de prueba en la cadena para verificar las transiciones de estado.
Ethereum ha experimentado frecuentes bifurcaciones duras, lo que podría modificar el EVM, lo que significa que los equipos de rollups deben ser responsables de mantener y actualizar sus implementaciones personalizadas. Esto generalmente requiere la creación de un comité de seguridad o la adopción de un sistema de gobernanza basado en tokens para gestionar las actualizaciones de sus contratos de puente y mecanismos de prueba.
En nuestra serie anterior, discutimos Based rollup y Booster rollup. Ahora, nos centraremos en explorar más a fondo el concepto de rollup nativo.
¿Cuál es la diferencia entre Based, Booster y Native?
Entre las definiciones de rollup basado, rollup de refuerzo y rollup nativo puede haber mucha confusión. En entregas anteriores, ya hemos presentado el rollup basado y el rollup de refuerzo, por lo que se recomienda revisar ese contenido antes de leer este artículo. Sin embargo, haremos una revisión rápida de estos tres tipos.
Los rollups basados utilizan conjuntos de validadores de L1 para ordenar transacciones, fomentando la descentralización, pero pueden afectar la capacidad de transacción debido al tiempo de bloque relativamente largo de L1 (por ejemplo, 12 segundos). Sin embargo, se está trabajando arduamente para mejorar esta experiencia, utilizando tecnologías de preconfirmación para permitir a los usuarios disfrutar de confirmaciones de transacciones más rápidas mientras la comunidad continúa innovando.
Booster Rollups a través de la simulación de procesamiento en L1 en L2 para ampliar la ejecución y el almacenamiento, permite que las aplicaciones crezcan sin necesidad de volver a implementarse. Aunque este enfoque proporciona escalabilidad, en comparación con los rollups tradicionales, introduce una complejidad adicional que requiere un esfuerzo de ingeniería más complejo para el desarrollo y mantenimiento.
Los Rollups nativos utilizan la funcionalidad de transferencia de estados (STF) de L1 como validador de la transición de estados en la Capa de aplicación. Sin embargo, aunque Optimism, Arbitrum y otros rollups funcionan en un entorno EVM equivalente, a menudo contienen modificaciones personalizadas complejas o poco prácticas que no se pueden implementar directamente en Ethereum.
Los rollups nativos solían ser llamados rollups de derecho, y han sido discutidos en varios escritos. Además, el término "rollup específico" fue brevemente utilizado por @apolynya. Sin embargo, el término "de derecho" finalmente fue reemplazado por "nativo" para indicar que los rollups equivalentes a EVM existentes podrían actualizarse a este modelo. El término "nativo" fue propuesto por @danrobinson y un contribuyente anónimo de Lido.
¿Cómo funciona rollup nativo?
La propuesta nativa rollup introduce la precompilación EXECUTE, que sirve como validador de la transición de estado rollup. Esta precompilación permitirá al equipo de rollup usarla en sus contratos validadores, proporcionando un sistema de pruebas basado y permitiendo que rollup herede la validación nativa de Ethereum.
Dado que este nuevo precompilado es en cierto modo similar al concepto de 'EVM dentro de EVM'，se actualizará a través del proceso de hard fork de Ethereum bajo su consenso social. Esto garantiza que los cambios en EVM se reflejen en el precompilado，permitiendo que rollups herede la validación de Ethereum y alivie al equipo de rollup de la responsabilidad de gobernanza en comités de seguridad o firmas múltiples，lo que hace que rollup sea más seguro para los usuarios en esencia.
EJECUTAR precompilado como validador de transiciones de estado de EVM, permite que rollup utilice las instalaciones nativas de Ethereum en la Capa de aplicación. Utiliza entradas como pre_state_root, post_state_root, traza y gas_used para verificar la transición, aprovechando un mecanismo de fijación de precios de gas similar a EIP-1559. Según las necesidades de escalabilidad de rollup, los validadores pueden hacer cumplir la corrección de la transición de estado de rollup mediante la reejecución o las pruebas SNARK. Además, se integra un retraso en un slot para mitigar el riesgo de centralización, como la competencia de pruebas basadas en MEV.
Esta precompilación simplifica el desarrollo de rollups al admitir 'rollups' sin confianza en el sistema de prueba. Cuando se combina con el diseño de rollup basado, donde tanto el sistema de ordenación como el de prueba son gestionados por Ethereum, esta estructura puede lograr una completa falta de confianza, comúnmente conocida como 'rollup' ultrasonido. Mejora la composabilidad y tiene el potencial de liquidación en tiempo real, lo que fomenta un diseño de rollup más seguro y con mayor capacidad de composición.
El comportamiento precompilado propuesto es similar al de EVM, reejecutando transacciones de rollup para verificar su corrección. Esto va en contra de la ventaja central de rollup, ya que la ventaja de rollup radica en la ejecución fuera de la cadena, solo presentando pruebas de validez a Ethereum. Por el contrario, la precompilación refleja esencialmente lo que Ethereum ya está haciendo y no agrega valor en la reducción de la carga computacional de L1.
La elección de un validador similar a EVM en lugar de un validador zk se deriva de la inmadurez actual de la tecnología ZK. La zkVM actualmente ampliamente utilizada ha mostrado vulnerabilidad, y la rápida evolución de ZKP hace que codificar validadores zk específicos en la cadena sea arriesgado e inflexible. En cambio, Ethereum prioriza la diversidad y la neutralidad, lo que permite experimentar con diferentes clientes ZK sin depender de un solo validador.
Sin embargo, esto no significa que la precompilación no haya contribuido a la escalabilidad de Ethereum. A pesar de que Ethereum mantiene los verificadores de pruebas de conocimiento cero fuera de la cadena para garantizar su seguridad, utiliza esta precompilación para verificar las pruebas de conocimiento cero presentadas por rollups. Esto permite a los verificadores de Ethereum evitar simular todas las transacciones de rollup de principio a fin. En cambio, al depender de las pruebas de conocimiento cero fuera de la cadena, la red mantiene su garantía de seguridad, al tiempo que trabaja para lograr la escalabilidad en la ejecución.
¿Cuáles son las principales ventajas de rollup nativo?
A través de rollups nativos, muchos trabajos complejos pueden ser preprocesados, lo que hace que la verificación de fraude o SNARK sea más simple. Esto significa menos código para escribir y mantener, sin necesidad de sistemas adicionales como redes de prueba o comités de seguridad.
Los costos de verificación de SNARK en la cadena son altos, por lo que muchos zk-rollup no liquidan transacciones con frecuencia para ahorrar costos. La precompilación de EXECUTE puede ayudar a reducir estos costos al empaquetar múltiples pruebas juntas a través de SNARK recursivo. Este enfoque puede hacer que la verificación de transacciones en rollup sea más eficiente, lo que hace que la verificación fuera de la cadena sea más rentable.
En rollups tradicionales, asegurar operaciones sin errores es un desafío, generalmente requiere extensas comprobaciones. Muchos equipos reducen el riesgo adoptando un orden centralizado para evitar la generación de bloques maliciosos. Sin embargo, mediante la ejecución nativa precompilada, es posible lograr un mecanismo de ordenamiento más seguro y sin permisos. Este enfoque permite que los rollups hereden la seguridad de L1 y la fungibilidad de los activos, ya que las transacciones se verifican directamente en el entorno de confianza de Ethereum.
Hay muchos rollups compatibles con EVM, pero casi ninguno equivalente a EVM: mantenerse al día con los cambios en la cadena principal generalmente requiere un equipo o sistema de votación para actualizar el rollup, lo que puede conllevar riesgos. Los rollups nativos pueden actualizarse automáticamente con la cadena principal, manteniendo todo sincronizado, sin necesidad de reglas adicionales o votantes.
Para los zk-rollups, lograr un tiempo de prueba extremadamente bajo, como por ejemplo 100 milisegundos, es una tarea de ingeniería altamente desafiante. En contraste, los rollups nativos pueden permitir un cronograma de tiempo de prueba más 'relajado', extendiéndolo a un intervalo completo. Este enfoque alivia la presión de generar pruebas de inmediato, lo que podría mejorar la confiabilidad y fortalecer la integración con L1.
¿Todos los rollups serán nativos?
Actualmente, todas las pilas de rollups, como OP Stack y Arbitrum Orbit Stack, tienen el potencial de convertirse en "rollups nativos", heredando directamente las características de seguridad de Ethereum. Esta actualización hará que los usuarios se sientan más satisfechos, ya que la seguridad se verá reforzada, y los equipos de rollup se sentirán más cómodos al no necesitar más un comité de seguridad. Al mismo tiempo, los equipos de rollup aún pueden seguir compitiendo proporcionando una capa de ordenación compartida eficiente y capturando las tarifas de ordenación para maximizar el MEV.
Sin embargo, no todos los rollups harán la transición a su forma nativa. Algunas características de L2 son inherentemente incompatibles con los rollups nativos, incluyendo tipos de transacciones únicos, diferentes métodos de contabilidad de gas y precompilaciones no encontradas en la cadena de bloques principal L1. La diversidad de VM entre los rollups de L2, cada uno compartiendo un mismo fundamento de seguridad, es una gran ventaja del ecosistema de L2 hoy en día, por ejemplo
Como señaló @doganeth_en, los rollups futuros se dividirán en tres categorías: rollups empresariales, rollups orientados al rendimiento y rollups nativos 'alineados'.
Las empresas se centrarán en la gestión, clasificación y posesión de sus rollups, lo que es ideal para aquellas que deseen tener un control similar al de la web2 en el orden de las transacciones, la ejecución y las aplicaciones.
Los rollups centrados en el rendimiento utilizarán liquidaciones de Ethereum, pero dependerán de la disponibilidad de datos alternativos para lograr el mejor rendimiento, por ejemplo @megaeth_labs utiliza @eigen_da para lograr la disponibilidad de datos. Estos rollups tienen un menor grado de descentralización, pero aumentan la utilidad de ETH, aunque sacrifican algunas características de Ethereum.
Los rollups nativos se integrarán completamente con la infraestructura Based de Ethereum y proporcionarán: descentralización a nivel de Ethereum, ejecución compartida con acceso directo al estado y verificación más económica de pruebas de conocimiento cero fuera de la cadena. Estos rollups contribuyen al efecto de red de Ethereum, pueden compartir ingresos, pero su sostenibilidad depende de los incentivos económicos naturales.
Conclusión
Los rollups nativos representan un gran avance en la hoja de ruta central de rollup de Ethereum, ofreciendo un enfoque más alineado con las infraestructuras basadas en Ethereum. Al introducir la precompilación EXECUTE, los rollups nativos simplifican la gobernanza, eliminando la dependencia de las firmas múltiples, comités de seguridad o sistemas de votación basados en tokens. Este enfoque no solo mejora la seguridad, sino que también permite una escalabilidad más eficiente de los rollups, aprovechando las pruebas zk fuera de la cadena, garantizando así la minimización de la confianza y la escalabilidad.
A pesar de las amplias perspectivas de esta propuesta, no está exenta de desafíos. Aunque la mayoría de los rollups existentes se denominan equivalentes a EVM, suelen tener modificaciones ligeras en el EVM. Por lo tanto, la transición al modelo de rollup nativo podría suponer una carga adicional de desarrollo para los rollups que tienen implementaciones personalizadas de EVM.
Sin embargo, los rollups nativos ofrecen un camino llamativo para combinar la seguridad y flexibilidad de Ethereum con el diseño de rollup. Al fomentar la alineación con L1, fomentan la innovación, al tiempo que reducen la fragmentación, lo que hace que el ecosistema de Ethereum sea más sólido y resistente en el futuro.