Euclid Upgrade
Resumen
Esta actualización incluye cinco cambios principales:
- Migración al Prover OpenVM.
- Migración al compromiso de estado MPT.
- Proceso de rollup optimizado.
- Soporte para EIP-7702 y RIP-7212.
- Preparación para la Etapa 1.
Estos cambios resultarán en tarifas más bajas, mayor rendimiento, mejor seguridad, mejor compatibilidad y funciones más avanzadas que los usuarios y desarrolladores en Scroll pueden disfrutar.
Cronograma
- Scroll Sepolia
- Fase 1: 11 de marzo de 2025
- Fase 2: 13 de marzo de 2025
- Scroll Mainnet
- Fase 1: 16 de abril de 2025
- Fase 2: 22 de abril de 2025
El Distintivo
Prover OpenVM
Scroll ha sido pionero en la tecnología ZK a través de nuestro zkEVM compatible con bytecode EVM basado en halo2. La tecnología ZK ha progresado rápidamente desde entonces, y ahora los zkVMs de propósito general basados en RISC-V se están volviendo prácticos. En la actualización Euclid, estamos reemplazando nuestros circuitos halo2 por un nuevo prover construido sobre OpenVM.
El nuevo prover OpenVM ofrece numerosos beneficios. El código del prover es más fácil de razonar y auditar. Podemos reutilizar mejor el código entre diferentes componentes. También podemos reducir los costos y la latencia de prueba. Finalmente, el nuevo prover nos permitirá probar transacciones arbitrariamente complejas, lo que nos permitirá eliminar el módulo de verificación de capacidad de circuito que ha sido un gran cuello de botella en el rendimiento del secuenciador.
Compromiso de Estado MPT
Scroll actualmente utiliza una estructura de datos de compromiso de estado amigable con zk llamada zktrie. Con el nuevo prover OpenVM, ahora es práctico probar la estructura de estado de Ethereum: el Merkle-Patricia Trie, también conocido como MPT. Scroll ahora está reemplazando zktrie y adoptando MPT.
MPT desbloquea un mejor rendimiento del secuenciador y ofrece mejor compatibilidad para las dapps que dependen de pruebas de estado L2.
Proceso de Rollup Optimizado
En Euclid, estamos implementando una serie de optimizaciones en el proceso de rollup. Estas resultan en reducciones significativas en la sobrecarga de Disponibilidad de Datos (DA) y, en última instancia, tarifas más bajas para los usuarios.
Las principales optimizaciones son:
- Mover la verificación de blobs del código del contrato a los circuitos zk.
- Amortizar el costo de compromiso de la cola de mensajes.
- Mover los datos del encabezado del bloque L2 de calldata a blobs.
- Comprometer múltiples blobs en una sola transacción.
Estos cambios combinados se estiman para reducir los costos de compromiso de lotes hasta en un 90%.
Además, los nodos L2 de Scroll reemplazarán Clique (el consenso actual de Prueba de Autoridad) y comenzarán a leer el firmante autorizado del bloque L2 desde el nuevo contrato de configuración del sistema en L1.
Cuentas Inteligentes Potentes
En Euclid, Scroll está adoptando EIP-7702 y RIP-7212. Adoptar 7702 en paralelo con la actualización Pectra de Ethereum asegura que Scroll mantenga un alto grado de compatibilidad con Ethereum. Estas características también permitirán a los usuarios y desarrolladores de Scroll aprovechar las últimas tecnologías en cuentas inteligentes: los usuarios pueden agregar funcionalidades de contrato inteligente a sus cuentas existentes, usar claves de acceso para firmar autorizaciones y beneficiarse de las mejoras emergentes en la experiencia de usuario que habilitan estos nuevos estándares.
Etapa 1
En Euclid, estamos implementando garantías de seguridad importantes que permitirán a Scroll alcanzar la Etapa 1 según el estándar definido por L2BEAT.
La inclusión forzada de transacciones es un mecanismo de resistencia a la censura. Permite a los usuarios encolar una transacción directamente desde Ethereum, obligando al secuenciador a incluirla.
La presentación de lotes sin permiso es un mecanismo para prevenir fallas de disponibilidad. En el improbable escenario de que el secuenciador de Scroll deje de publicar o finalizar lotes durante un período prolongado, este mecanismo permite a cualquiera intervenir y comenzar a publicar y finalizar lotes.
Ambos mecanismos obligan al secuenciador de Scroll a hacer su trabajo. Como tal, sirven como elementos disuasorios y ofrecen garantías de seguridad importantes a los usuarios.
También hemos transferido recientemente el control al Consejo de Seguridad, un organismo independiente de 12 miembros reputados, formando una multisig de 9/12. La actualización Euclid será la primera actualización ejecutada por el Consejo de Seguridad.
Compatibilidad
Operadores de Nodo
Cambios de la Fase 1
- Los operadores de nodo deben migrar a la nueva versión MPT de l2geth. Esto requiere una resincronización completa (desde la red o desde una instantánea). Proporcionaremos una versión del nodo y instantáneas más adelante. Consulte la Guía de Migración del Estado del Nodo para obtener instrucciones detalladas.
- Los nodos zktrie seguirán operando, pero dejarán de verificar las raíces de estado en los encabezados de bloque recibidos. Recomendamos a los operadores de nodo migrar a nodos MPT poco antes de Euclid.
Cambios de la Fase 2
- Los operadores de nodo deben estar al tanto de la etapa 1 (lotes sin permisos). Aunque es poco probable que este mecanismo se active en la práctica, si lo hace, requerirá pasos manuales para recuperar los nodos. Proporcionaremos documentación detallada sobre esto en nuestras próximas notas de lanzamiento del nodo.
Dapps e Indexadores
Cambios de la Fase 1
- La estructura de compromiso de estado cambia de zktrie a MPT.
- Cualquier dapp que dependa de pruebas zktrie debe migrar a pruebas MPT.
- Las versiones de lote utilizarán v5 y v6 (formato idéntico a los lotes v4 anteriores).
Cambios de la Fase 2
- Los encabezados de lote y la carga útil del blob utilizarán una nueva codificación. Las versiones de lote utilizadas en la fase 2 serán v7.
- El calldata de compromiso de lote ya no contendrá encabezados de bloque. Los proyectos que necesiten esta información desde L1 deben obtener y decodificar el blob.
- Una sola transacción de compromiso puede transportar múltiples lotes. Los indexadores deben poder procesar múltiples lotes desde una misma transacción L1.
- En el modo de lote sin permisos, el remitente compromete y finaliza un solo lote atómicamente con
commitAndFinalizeBatch. - Las firmas de funciones cambiarán. Los proyectos deben agregar soporte para las nuevas funciones:
- Antes de Euclid fase 2:
commitBatchWithBlobProof,finalizeBundleWithProof,revertBatch - Después:
commitBatches,finalizeBundlePostEuclidV2,commitAndFinalizeBatch,revertBatch
- Antes de Euclid fase 2:
- La matriz
committedBatchesserá escasa. - Migramos a
L1MessageQueueV2, con diferentes hashes de almacenamiento de mensajes. - Los bloques L2 inseguros ya no incluirán firma o etiqueta de vanidad en
ExtraData.
