Reenviar el título original: Desempaquetando la próxima generación de Ethereum L2s (III): Rollups nativos

En los últimos dos años, Ethereum se ha comprometido plenamente con una hoja de ruta centrada en los rollups. Esta estrategia implica bloquear ETH en contratos puente, ejecutar transacciones fuera de la cadena y utilizar pruebas, ya sea pruebas de fraude o pruebas de conocimiento cero (ZKPs), para verificar el estado de la capa 2 (L2) y manejar las retiradas.

Sin embargo, hay un desafío significativo: Ethereum no valida nativamente la ejecución de EVM, lo que obliga a los rollups a implementar sus propios sistemas de prueba en cadena para validar las transiciones de estado de forma independiente.

Ethereum a menudo experimenta bifurcaciones duras que pueden modificar el EVM, lo que significa que los equipos de rollups deben asumir la responsabilidad de mantener y actualizar sus implementaciones personalizadas. Esto a menudo requiere la formación de un consejo de seguridad o la adopción de un sistema de gobierno de votación basado en tokens para gestionar las actualizaciones de sus contratos de puente y mecanismos de prueba.

En nuestra serie anterior, exploramos rollups basados y rollups de refuerzo. Ahora, dirigimos nuestra atención a adentrarnos más en el concepto de rollups nativos.

¿Basado, Booster, Nativo...Cuál es la diferencia?

Puede haber mucha confusión entre las definiciones de rollups basados, rollups de refuerzo y rollups nativos. En la serie anterior, ya pasamos por los rollups basados y los rollups de refuerzo, por lo que se recomienda verificar esos antes de leer este artículo. Sin embargo, le recordaremos rápidamente acerca de esos tres tipos.

Los Rollups basados utilizan el conjunto de validadores L1 para la secuenciación de transacciones, promoviendo la descentralización pero potencialmente afectando el rendimiento debido a los relativamente largos tiempos de bloque L1, como 12 segundos. Sin embargo, se están haciendo esfuerzos para mejorar esta experiencia con técnicas de pre-confirmación, permitiendo a los usuarios beneficiarse de una finalidad de transacción mucho más rápida a medida que la comunidad continúa innovando.

Booster Rollups escala la ejecución y el almacenamiento al imitar el procesamiento L1 en L2, lo que permite que las aplicaciones crezcan sin necesidad de volver a implementarse. Si bien este enfoque proporciona escalabilidad, introduce una complejidad adicional en comparación con los rollups tradicionales, lo que requiere esfuerzos de ingeniería más sofisticados para desarrollar y mantener.

Los Rollups nativos aprovechan la propia función de transición de estado (STF) de L1 en la capa de aplicación como verificador de las transiciones de estado. Sin embargo, si bien Optimism, Arbitrum y otros rollups operan en entornos equivalentes a EVM, a menudo incluyen modificaciones personalizadas que pueden ser complejas, o incluso inviables, de implementar directamente en Ethereum.

Los rollups nativos, antes conocidos como rollups consagrados, se han discutido en detalle en varios documentos. Además, el término "rollup canónico" se utilizó brevemente por @apolynya. Sin embargo, "enshrined" finalmente se reemplazó por "native" para indicar que los paquetes acumulativos equivalentes a EVM existentes podrían actualizarse a este modelo. El término "nativo" fue propuesto por @danrobinsony un contribuyente anónimo de Lido.

¿Cómo funcionan los rollups nativos?

La propuesta de rollup nativo introduce la precompilación EXECUTE, diseñada para actuar como un verificador para las transiciones de estado de rollup. Esta precompilación permitiría a los equipos de rollup utilizarla dentro de sus contratos verificadores, proporcionando una base para sistemas de prueba y permitiendo que los rollups hereden la validación nativa de Ethereum.

Dado que este nuevo precompilado es algo similar al concepto de 'EVM in EVM', se actualizará a través del proceso de hard-fork de Ethereum bajo su consenso social. Esto garantiza que los cambios en la EVM se reflejen en el precompilado, permitiendo que los rollups hereden la validación de Ethereum y aliviando a los equipos de rollup de responsabilidades de gobierno como consejos de seguridad o multisigs, lo que en última instancia hace que los rollups sean inherentemente más seguros para los usuarios.

El precompilado EXECUTE funciona como un verificador de transiciones de estado de EVM, lo que permite a los rollups utilizar la infraestructura nativa de Ethereum en la capa de aplicación. Valida las transiciones utilizando entradas como pre_state_root, post_state_root, trace y gas_used, aprovechando un mecanismo de fijación de precios de gas similar a EIP-1559.

Los validadores pueden hacer cumplir la corrección de las transiciones de estado de rollup mediante la reejecución o las pruebas de SNARK, según las necesidades de escalabilidad del rollup. Además, se incorpora un retraso de un slot para mitigar los riesgos de centralización, como la competencia de pruebas impulsada por MEV.

El precompilado simplifica el desarrollo de rollups al habilitar los “rollups sin confianza” en términos de sistemas de prueba. Si se combina con un diseño de rollup basado, donde tanto la secuenciación como los sistemas de prueba son gestionados por Ethereum, esta estructura podría lograr una plena falta de confianza, a menudo denominada como un “rollup de ultrasonido.” Mejora la composabilidad con el potencial de liquidación en tiempo real, fomentando así diseños de rollup más componibles y seguros.

La precompilación propuesta se comporta de manera similar al EVM, volviendo a ejecutar transacciones de rollup para verificar la corrección. Esto contradice la ventaja principal de los rollups, que es la ejecución fuera de la cadena con solo pruebas de validez enviadas a Ethereum. En cambio, la precompilación refleja esencialmente lo que Ethereum ya hace, sin agregar ningún valor en términos de aliviar la carga computacional de L1.

La elección de un verificador similar a EVM en lugar de verificadores zk se debe a la actual inmadurez de la tecnología ZK. Incluso los zkVM ampliamente utilizados han mostrado vulnerabilidades y la rápida evolución de los ZKP hace que codificar verificadores zk específicos en cadena sea arriesgado e inflexible. En cambio, Ethereum prioriza la diversidad y la neutralidad, lo que permite experimentar con varios clientes zk sin quedar bloqueado en un único verificador.

Sin embargo, esto no significa que la precompilación no contribuya a la escalabilidad de Ethereum. Si bien Ethereum garantiza su seguridad manteniendo los verificadores de zk-proof fuera de la cadena, utiliza esta precompilación para validar zk-proofs presentados por rollups. Esto permite a los validadores de Ethereum evitar emular completamente todas las transacciones de rollup de principio a fin. En su lugar, al confiar en zk-proofs fuera de la cadena, la red mantiene sus garantías de seguridad mientras se esfuerza por lograr la escalabilidad en términos de ejecución.

¿Cuáles son los principales beneficios de los rollups nativos?

Con rollups nativos, gran parte del trabajo complejo puede ser manejado por una precompilación, lo que hace que cosas como pruebas de fraude o verificaciones SNARK sean mucho más simples. Esto significa menos código para escribir y mantener, y no es necesario contar con sistemas adicionales como redes de pruebas o consejos de seguridad.

La verificación de SNARK en cadena es costosa, por lo que muchos zk-rollups liquidan transacciones con menos frecuencia para ahorrar costos. El precompilado EXECUTE podría ayudar a reducir estos costos agrupando múltiples pruebas juntas mediante la recursividad de SNARK. Este enfoque permite a los rollups validar transacciones de manera más eficiente, lo que hace que la verificación fuera de cadena sea más asequible.

Garantizar un funcionamiento sin errores en los rollups tradicionales es un desafío y a menudo requiere controles exhaustivos. Muchos equipos mitigan los riesgos mediante la utilización de secuenciación centralizada para evitar la creación de bloques maliciosos. Sin embargo, la ejecución nativa a través de una precompilación podría habilitar un mecanismo de secuenciación más seguro y sin permisos. Este enfoque puede permitir que los rollups hereden no solo la seguridad, sino también la fungibilidad de activos de L1, ya que las transacciones se validan directamente dentro del entorno de confianza de Ethereum.

Hay muchos rollups que son compatibles con EVM, pero apenas algunos son equivalentes a EVM: mantenerse al día con los cambios en la cadena principal a menudo requiere un sistema de votación o de grupo para actualizar los rollups, lo que puede ser arriesgado. Los rollups nativos pueden actualizarse automáticamente con la cadena principal, manteniendo todo sincronizado sin necesidad de reglas o votantes adicionales.

Para zk-rollups, lograr tiempos de prueba de ultra baja latencia, como 100 ms, es una tarea de ingeniería altamente desafiante. Los rollups nativos, en comparación, podrían permitir un horario de prueba más "relajado", extendiéndolo a una ranura completa. Este enfoque reduce la presión de generar pruebas al instante, mejorando potencialmente la confiabilidad y la integración con L1.

¿Será cada rollup nativo?

Todas las pilas de rollup actuales, como OP Stack y Arbitrum Orbit Stack, tienen el potencial de transformarse en “rollups nativos”, heredando directamente las características de seguridad de Ethereum. Esta actualización haría más felices a los usuarios debido a una seguridad mejorada y los equipos de rollup estarían más satisfechos al eliminar la necesidad de consejos de seguridad. Mientras tanto, los equipos de rollup pueden seguir compitiendo ofreciendo una capa de secuenciación compartida eficiente, capturando aún las tarifas del secuenciador y maximizando el MEV.

Sin embargo, no todas las rollups harán la transición a ser nativas. Algunas características de L2 son inherentemente incompatibles con las rollups nativas, incluyendo tipos de transacción únicos, métodos de contabilización de gas distintos y precompilados que no se encuentran en la cadena principal L1. La variedad en las MV entre las rollups de L2, que comparten una base de seguridad común, es una de las fortalezas del ecosistema L2 actual, como @EclipseFNDsiendo un rollup SVM @movementlabsxyzsiendo un rollup de MoveVM, o @Starknetsiendo un rollup de CairoVM.

Como se señaló por @doganeth_en, los futuros rollups se dividirán en tres categorías: rollups empresariales, rollups centrados en el rendimiento y rollups nativos "alineados".

Las empresas se centrarán en gestionar, secuenciar y poseer sus rollups, perfecto para las empresas que desean tener un control similar a web2 sobre el orden de las transacciones, la ejecución y las aplicaciones.

Los rollups centrados en el rendimiento utilizarán el sistema de liquidación de Ethereum pero dependerán de una disponibilidad de datos alternativa para obtener un rendimiento óptimo, como @megaeth_labsusar @eigen_dapara la disponibilidad de datos. Menos descentralizados, estos rollups aumentan $ETHutilidad pero compromiso en algunas características de Ethereum.

Los rollups nativos se integrarán completamente con la infraestructura de Ethereum y ofrecerán: descentralización a nivel de Ethereum, ejecución compartida con acceso directo al estado y verificación más barata de pruebas ZK fuera de la cadena. Estos rollups contribuyen a los efectos de red de Ethereum, compartiendo potencialmente ingresos, pero la sostenibilidad depende de incentivos económicos naturales.

Conclusión

Los rollups nativos representan un avance importante en la hoja de ruta centrada en rollups de Ethereum, ofreciendo un enfoque más alineado con la infraestructura de Ethereum. Al introducir la precompilación EXECUTE, los rollups nativos simplifican la gobernanza, eliminando la dependencia de multisigs, consejos de seguridad o sistemas de votación basados en tokens. Este enfoque no solo mejora la seguridad, sino que también permite que los rollups se escalen de manera más eficiente utilizando pruebas zk fuera de la cadena, asegurando tanto la minimización de la confianza como la escalabilidad.

Si bien la propuesta promete mucho, no está exenta de desafíos. La mayoría de los rollups existentes, a pesar de estar etiquetados como equivalentes al EVM, a menudo incluyen ligeras modificaciones al EVM. Como resultado, la transición a un modelo de rollup nativo podría introducir una carga adicional de desarrollo para rollups con implementaciones personalizadas del EVM.

Sin embargo, los rollups nativos ofrecen un camino convincente para integrar 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 cohesivo y resistente para el futuro.

Si aún no lo has hecho, asegúrate de revisarparte Iyparte IIde nuestra serie Rollups 2.0 que se centran en rollups basados y rollups impulsores, respectivamente. En nuestra próxima publicación, nos adentraremos más en el concepto de rollups gigagas y exploraremos cómo este enfoque innovador de diseño de rollup podría empujar los límites de la escalabilidad de Ethereum y mejorar aún más el ecosistema de rollups.

Descargo de responsabilidad:

1. Este artículo se reproduce de [2077 Investigación]. Adelante el Título Original: Desempaquetando La Próxima Generación De Ethereum L2s (III): Rollups Nativos. Todos los derechos de autor pertenecen al autor original [2077 Investigación]. Si hay objeciones a esta reimpresión, por favor contacte al Aprender sobre Gateequipo, y ellos lo manejarán rápidamente.
2. Aviso de responsabilidad: Las opiniones expresadas en este artículo son exclusivamente del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Aprende de Gate.io. Queda prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se mencione.