Las razones por las que los Rollups nativos a menudo han sido evitados y el cambio de estrategia de Vitalik

Lo que ha quedado claro en la última publicación de Vitalik Buterin es que ha dado un giro importante en su postura respecto a los Rollups nativos. En el pasado, su cautela se debía en gran medida a cuestiones relacionadas con la madurez técnica. En el núcleo de este cambio se encuentra la evolución del ecosistema en su conjunto, especialmente la aceleración en las tecnologías ZK y su implementación.

Madurez de la tecnología ZK y nuevas opciones de seguridad en L2

La principal razón por la que los Rollups nativos solían ser evitados era que las soluciones de precompilación enfrentaban una dicotomía. L2 podía «permitir retiros de activos rápidos, pero asumiendo riesgos de prueba», o bien «depender de la seguridad de Ethereum, lo que requería esperar de 2 a 7 días para retirar», enfrentándose a menudo a la segunda opción. Esta restricción impulsó la adopción de alternativas como los puentes multiseguro, lo que a su vez reducía la composabilidad (interoperabilidad) del sistema en su conjunto.

Sin embargo, actualmente, el entorno tecnológico está cambiando rápidamente. La hoja de ruta de Ethereum para aceptar ZK a nivel L1 y la implementación escalonada de precompilaciones nativas de Rollup comienzan a sincronizarse. Este avance hace prever que los obstáculos clave del pasado se vayan resolviendo paulatinamente.

La importancia de la sincronización de la composabilidad y nuevas perspectivas en el diseño de precompilaciones

Desde la perspectiva de Vitalik, se está extendiendo una tendencia en la comunidad a reconocer la «sincronización de la composabilidad» como un valor fundamental en L2. La combinación de soluciones basadas en Rollup con mecanismos de precompilación de baja latencia está acelerando los esfuerzos por superar las limitaciones tradicionales.

En cuanto a la implementación concreta de precompilaciones nativas de Rollup, Vitalik enfatiza que no se debe proceder con un diseño impulsivo. La especificación ideal que propone consiste en que los desarrolladores puedan construir Rollups «con funciones limitadas en EVM», reutilizando directamente la parte de EVM de la precompilación nativa de Rollup, y solo personalizando el sistema de pruebas para las funciones nuevas. Esto facilitaría la conexión estandarizada entre ambos.

El trasfondo de este enfoque de diseño es mantener un equilibrio entre compatibilidad y flexibilidad. Se trata de un intento de resolver de manera gradual los problemas de complejidad que los Rollups nativos han enfrentado en el pasado. Gracias a la madurez de ZK-EVM y a la evolución de las tecnologías de precompilación, estamos en la antesala de una nueva etapa en el ecosistema L2.