Presentamos Eclipse Mainnet: Ethereum SVM L2

Eclipse Mainnet es un L2 de uso general que combina las mejores piezas de la pila modular:

1. Liquidación: Ethereum: Eclipse se liquidará en Ethereum (es decir, el puente de validación consagrado estará en Ethereum) y utilizará ETH como token de gas.
2. Ejecución: Máquina virtual Solana (SVM): Eclipse ejecutará la SVM de alto rendimiento como entorno de ejecución.
3. Disponibilidad de datos: Celestia: Eclipse publicará sus datos en Celestia para una disponibilidad de datos escalable (DA).
4. Demostración: RISC Zero: Eclipse utilizará RISC Zero para pruebas de fraude ZK (¡sin serialización de estado intermedio!)

La mayoría de los titulares de Eclipse han girado en torno a nuestro trabajo para implementar paquetes acumulativos de aplicaciones específicas para una variedad de proyectos, pero ahora está más claro que nunca que Ethereum necesita una L2 de propósito general capaz de una escala verdaderamente masiva. La mayoría de las aplicaciones no se benefician de las personalizaciones de la cadena específicas de la aplicación, y el aislamiento y la complejidad resultantes pueden resultar en una peor experiencia de usuario y de desarrollador.

A menudo se presenta una falsa dicotomía entre la visión de acumulación modular y la capacidad de tener una única cadena con escala masiva, ejecución paralelizada y estado compartido. "Modular" a menudo se combina con "específico de la aplicación", lo que le llevaría a creer que los paquetes acumulativos significan un mundo de muchas cadenas fragmentadas y de bajo rendimiento. Desafiamos esa idea.

Ejecución: velocidad y escala de Solana

Eclipse Mainnet adoptará el mejor entorno de ejecución de su clase de Solana. Esto trae enormes ventajas:

Ejecución paralela optimizada

SVM y su tiempo de ejecución Sealevel permiten la ejecución de transacciones en paralelo. Las transacciones que no tocan estados superpuestos se pueden ejecutar en paralelo en lugar de secuencialmente.

Esto permite que SVM escale directamente con el hardware a medida que los procesadores continúan agregando más núcleos a menor costo. Los tiempos de ejecución de un solo subproceso (como el EVM actual) fundamentalmente no se benefician de la reducción del costo por núcleo. Desde hace más de una década, la aceleración del rendimiento de un solo subproceso ha ido disminuyendo continuamente. Casi todas las mejoras siguen proviniendo del aumento del número de núcleos, por lo que es fundamental aprovechar esta tendencia paralelizando las cargas de trabajo:

Hay algunos intentos muy iniciales no probados de paralelizar el EVM, pero agregar esto mientras se mantiene la compatibilidad genera compensaciones fundamentales, incluido un rendimiento subóptimo sin abordar otros cuellos de botella (por ejemplo, el crecimiento del estado). Los contratos que declaran dependencias estatales por adelantado (como en SVM) permiten una paralelización óptima.

Mercados de tarifas locales

La mayoría de los mercados de tarifas actuales son globales, lo que significa que una aplicación activa aumenta las tarifas para todos los usuarios de la cadena. Una menta NFT no debería inutilizar la cadena para todo lo demás. El sorprendente trabajo de Solana en los mercados de tarifas locales resuelve este conflicto estatal entre aplicaciones. En su implementación actual, el programador prioriza las transacciones sin conflictos, lo que permite realizar transacciones libres de conflictos con tarifas más bajas. A más largo plazo, los mercados de tarifas locales se implementarán a nivel de protocolo. Esto garantiza que los aumentos de tarifas para una sola aplicación no afecten al resto de la cadena.

Los mercados de tarifas locales son posibles gracias al exclusivo tiempo de ejecución paralelizado de Solana. Intentar implementar mercados de tarifas locales para los puntos críticos estatales en el EVM utilizando heurísticas (es decir, sin declarar el acceso estatal por adelantado) presentaría ineficiencias y posibles vectores de ataque.

También se están realizando investigaciones iniciales que permitirían a las aplicaciones internalizar fácilmente el valor local que se les atribuye, lo que hoy en día generalmente requiere un diseño más creativo a nivel de aplicación.

Gestión del crecimiento estatal

Antes de que la EVM se tope siquiera con la ejecución secuencial como cuello de botella, el crecimiento del Estado es su cuello de botella mucho más apremiante.

Debido a que no existe un árbol Merkle para el estado, Solana no incurre en la sobrecarga de actualizar un árbol Merkle para cada actualización de estado. En cambio, después de cada época (~2,5 días), todo el estado se merkliza. Esto es mucho más económico que la merklización en tiempo real (como en EVM).

Más importante aún, el EVM tiene acceso dinámico a la cuenta (es decir, las transacciones pueden tocar cualquier estado bajo demanda). Esa búsqueda dinámica de estado significa que ese estado no se puede cargar en la memoria antes de la ejecución. En SVM, cada transacción especifica todo el estado necesario para la ejecución.

Como resultado, el tamaño del estado no afecta la ejecución de SVM. La red podría duplicar de forma segura el tamaño de la instantánea cada 2 años sin tener problemas importantes, suponiendo que los validadores actualicen sus discos de almacenamiento cada 2 años.

Además, equipos como Helius están mejorando activamente la accesibilidad de los datos históricos y reduciendo el tamaño del estado con compresión.

Compatibilidad EVM

Neon EVM es un EVM que funciona como un contrato inteligente que se puede implementar en cualquier cadena SVM. Esto brinda compatibilidad total con EVM para Eclipse Mainnet (incluido el soporte de código de bytes EVM y Ethereum JSON-RPC) con un mayor rendimiento que los EVM de un solo subproceso. Debido a que cada instancia de Neon EVM tiene su propio mercado de tarifas local, las aplicaciones pueden simplemente implementar su propio contrato para obtener los beneficios de una cadena de aplicaciones sin fragmentar la UX, la seguridad o la liquidez.

Por otra parte, el compilador Solang permite la compilación del código de contratos inteligentes de Solidity en código de bytes SVM.

Instantáneas de MetaMask

La incorporación de usuarios de EVM a cadenas que no son de EVM ha sido históricamente un obstáculo importante, pero los Metamask Snaps presentados recientemente están destinados a romper esa barrera. Los usuarios de EVM pueden seguir usando MetaMask sin necesidad de cambiar de billetera. La UX es comparable a interactuar con cualquier cadena EVM, gracias a las contribuciones de código abierto de Driftque construyeron una excelente implementación de MetaMask Snap. Los usuarios de Eclipse Mainnet podrán interactuar con aplicaciones de forma nativa en MetaMask o usar una billetera nativa de Solana como Salmon.

Aquí hay un adelanto de la UX de Drift:

bailarín de fuego

Firedancer es el muy esperado cliente de Solana desarrollado por Jump para aumentar drásticamente el rendimiento, la resiliencia y la eficiencia de la red. En el lanzamiento nos apegaremos lo más posible al cliente principal de Solana, pero planeamos adoptar Firedancer una vez que el código esté activo y estable.

Seguridad

El tiempo de ejecución de Solana tiene una superficie de ataque muy reducida, lo que evita los infames exploits de reentrada que hemos visto con demasiada frecuencia. Específicamente, el tiempo de ejecución de Solana solo permite que los programas se recurran automáticamente, en lugar de permitir invocaciones arbitrarias y reentrantes entre programas. Además, separar el estado y el código da como resultado un código sin estado, que normalmente es más fácil de probar de manera efectiva.

Prueba más fácil

El SVM se basa en registros y tiene un conjunto de instrucciones mucho más pequeño que el EVM, lo que hace que la ejecución de SVM sea más fácil de probar en ZK. Para resúmenes optimistas, el diseño basado en registros permite establecer puntos de control más fácilmente.

Acuerdo: seguridad y liquidez de Ethereum

Al igual que con los principales acumuladores de hoy, Eclipse Mainnet se instalará en Ethereum. Concretamente, esto significa que nuestro puente de validación en Ethereum quedará directamente consagrado en Eclipse. Los nodos de Eclipse buscarán este puente para determinar la "cadena canónica". El puente impone el orden correcto para Eclipse.

Esto permite a nuestros usuarios obtener ciertas propiedades de seguridad de Ethereum. El puente validará todas las transacciones de Eclipse, evitando el envío de estados no válidos. Además, impondrá una eventual vivacidad y resistencia a la censura en ciertos casos de fracaso. Incluso si el secuenciador dejara de funcionar o comenzara a censurar en L2, los usuarios podrían forzar la inclusión de sus transacciones a través del puente.

Debido a estas propiedades de seguridad, los validiums y optimiums a menudo se denominan "Ethereum L2". L2BEAT define una L2 como "una cadena que deriva total o parcialmente su seguridad de la capa uno de Ethereum para que los usuarios no tengan que depender de la honestidad de los validadores de L2 para la seguridad de sus fondos".

El acuerdo de Ethereum reconoce la importancia que probablemente tendrán los activos nativos de Ethereum en las economías DeFi y NFT de Eclipse Mainnet. ETH es el mejor dinero descentralizado que la mayoría de los usuarios claramente prefieren, por lo que también usaremos ETH como nuestro token de gas. A más largo plazo, la abstracción de tarifas permitirá a los usuarios pagar con cualquier token de su elección (por ejemplo, USDC). No hay planes para que Eclipse Mainnet tenga su propio token en este momento.

Disponibilidad de datos: ancho de banda y verificabilidad de Celestia

Eclipse Mainnet utilizará Celestia para la disponibilidad de datos (también conocido como publicación de datos o publicación de datos). Celestia ha sido un socio del ecosistema de Eclipse desde hace mucho tiempo.

Desafortunadamente, el rendimiento objetivo y las tarifas de Eclipse Mainnet no son compatibles con el ancho de banda actual de Ethereum. Esto seguirá siendo así incluso después de EIP-4844 (también conocido como “Proto-danksharding”), que proporciona un promedio de ~0,375 MB de espacio de blob por bloque (con un límite de ~0,75 MB por bloque).

1. Para transferencias ERC-20 con compresión básica (~154 bytes por transacción), esto se traduce en ~213 TPS en todos los paquetes acumulativos combinados.
2. Para swaps con compresión (~400 bytes por transacción), esto se traduce en ~82 TPS en todos los paquetes acumulativos combinados.

En comparación, Celestia se lanzará con bloques de 2 MB a finales de este año. Se espera que Blobspace aumente a 8 MB poco después del lanzamiento, una vez que se conecten suficientes nodos ligeros de muestreo de disponibilidad de datos (DAS) y la red resulte estable. Los nodos de luz DAS cumplen dos funciones críticas:

1. Permitir a los usuarios verificar por sí mismos que los datos del bloque de Eclipse estén disponibles
2. Contribuya a escalar de forma segura toda la red, ya que las capas DA pueden aumentar de forma segura su rendimiento a medida que más nodos ligeros DAS se conecten.

Se espera que Celestia sea la primera capa DA que se lance con DAS en producción. Esto contrasta con los Comités de Disponibilidad de Datos (DAC) tradicionales, que reintroducen supuestos de honestidad del comité sin verificación del usuario (similar a las cadenas de bloques monolíticas existentes).

Existe una suposición de seguridad inherente para los usuarios que conectan sus fondos desde Ethereum Mainnet a cualquier cadena que utilice DA fuera de la cadena. En particular, es técnicamente posible que los validadores de Celestia retengan los datos de las transacciones pero afirmen ante el puente Ethereum que los datos están disponibles. En la práctica, el consenso de prueba de participación de Celestia significa que la retención de datos sobre la propia Celestia se puede reducir, lo que hace que, en nuestra opinión, este riesgo sea poco realista.

En general, el soporte del nodo ligero DAS de Celestia desde el primer día, las propiedades de seguridad criptoeconómicas y el rendimiento DA altamente escalable lo convierten en la opción clara para Eclipse Mainnet en la actualidad.

Tenga en cuenta que algunos ven Ethereum DA en cadena como un requisito para ser un verdadero "L2" aquí por las razones descritas anteriormente. Nos basamos en la terminología L2 más común citada anteriormente y queremos ser claros en las consideraciones de seguridad.

También tenemos la intención de monitorear el progreso de Ethereum en el escalado de DA después de EIP-4844. Continúan apareciendo nuevas e interesantes investigaciones que potencialmente ofrecen DA de alto rendimiento antes que las ideas anteriores (que utilizan tablas hash distribuidas más avanzadas). Si Ethereum ofrece una mayor escala para Eclipse en beneficio de nuestros usuarios, evaluaríamos la posibilidad de migrar a Ethereum DA.

Prueba: Pruebas de fraude RISC Zero ZK (¡sin serialización de estado intermedio!)

Nuestras pruebas serán similares a las pruebas de fraude SVM SIMD de Anatoly, que en sí mismas son similares a la idea de John Adler de que la serialización estatal es costosa y es posible evitarla.

Específicamente, queremos evitar reintroducir un árbol Merkle en SVM. Experimentamos con la inserción de un árbol Sparse Merkle en el SVM desde el principio, pero actualizar el árbol Merkle después de cada transacción genera mejoras sustanciales en el rendimiento. La prueba sin un árbol Merkle descarta los marcos acumulativos generalistas existentes, como OP Stack, como base para los acumuladores SVM, y también requiere una arquitectura a prueba de fallas más creativa.

A alto nivel, una prueba de fallo requiere:

1. Un compromiso de insumos para una transacción,
2. La transacción en sí y
3. Prueba de que volver a ejecutar la transacción genera un resultado diferente al especificado en la cadena.

El compromiso de entrada normalmente se realiza proporcionando la raíz de Merkle para el árbol de estado del resumen. En cambio, nuestro ejecutor publicará una lista de entradas y salidas (incluidos los hashes de cuenta y el estado global relevante) para cada transacción, junto con un índice de la transacción que produjo cada entrada. Las transacciones se publican en Celestia, por lo que cualquier nodo completo puede seguirlas para extraer cuentas de entrada de su propio estado, calcular las cuentas de salida y confirmar que el compromiso en Ethereum es correcto.

Hay dos tipos posibles de fallas mayores:

1. Salidas incorrectas: en este caso, el verificador proporciona una prueba ZK en cadena de las salidas correctas. Estamos utilizando RISC Zero para crear pruebas ZK de ejecución SVM, continuando con nuestro trabajo anterior que demuestra la ejecución de código de bytes BPF. Esto permite que nuestro contrato de liquidación garantice la corrección sin tener que ejecutar las transacciones en cadena.
2. Entradas incorrectas: en este caso, el verificador publica en la cadena una referencia a los datos históricos que muestran que el estado de la entrada no es el afirmado. Utilizando el Puente de Gravedad Cuántica de Celestia, nuestro contrato de conciliación garantiza que estos datos históricos realmente demuestran fraude.

Por qué Eclipse, por qué Ethereum, por qué ahora

Estamos sobre los hombros de gigantes. Los paquetes acumulativos de hoy han avanzado el estado de la investigación para toda nuestra industria y han proporcionado a los usuarios de Ethereum tarifas más económicas en comparación con el L1.

Sin embargo, no aprovechan al máximo la última tecnología que se necesita para llegar a las masas. Los primeros paquetes acumulativos priorizaron en gran medida la compatibilidad con EVM y/o las optimizaciones para una prueba ZK más eficiente. Sin embargo, más recientemente hemos visto un progreso increíble que obvia la necesidad de hacer las concesiones que eligieron los primeros rollups y, de hecho, los pone en desventaja:

1. VM paralelizadas de alto rendimiento (p. ej., SVM)
2. Escalado de DA con soporte para nodos ligeros DAS (p. ej., Celestia)
3. Avances en la infraestructura de prueba para que sea práctico en cualquier lugar (por ejemplo, RISC Zero)
4. Mayor portabilidad del código (p. ej., Neon y Solang) y de los usuarios (p. ej., MetaMask Snaps) en todos los ecosistemas.

Eclipse tiene el enorme beneficio de la visión retrospectiva. Podemos aprender de las limitaciones que han enfrentado otras cadenas y luego seleccionar las mejores piezas para escalarlas a largo plazo.

https://twitter.com/0xMert?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680271128537726976%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

https://twitter.com/colludingnode?refsrc=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1680285353662468097%7Ctwgr%5E9336eadfb24c400b8686ae67184014bab31080f1%7Ctwcon%5Es1&ref_url=https%3A%2F%2Fmirror.xyz%2Feclipsemainnet.eth%2Fme7bXLWJDS177V6nl8j1uzF1mxpX6nbGOLNeyBAwXgs

A menudo escuchamos acerca de un futuro con un millón de paquetes acumulativos de aplicaciones específicas.

Las personalizaciones a nivel de consenso pueden ser increíblemente valiosas para ciertas aplicaciones (por ejemplo, dYdX v4), y estamos entusiasmados de ayudar a los equipos a lanzar paquetes acumulativos específicos de aplicaciones.

Sin embargo, estos casos son pocos y espaciados. Es por eso que la mayoría de los paquetes acumulativos nuevos siguen siendo simplemente bifurcaciones EVM básicas. Los problemas de los desarrolladores no se resuelven fragmentando la UX en más cadenas. El principal caso de uso de un millón de cadenas hoy en día parece ser el lanzamiento de un millón de tokens más. La demanda de personalización completa simplemente no existe hoy en día para la gran mayoría de los casos de uso.

Incluso si la demanda real estuviera ahí, la infraestructura necesaria para soportar muchas cadenas de aplicaciones con una UX competitiva está a años de distancia (si es que alguna vez llega a estar a la par). La Superchain de Optimism (OP Stack), las Hyperchains de zkSync (ZK Stack), las cadenas Orbit de Arbitrum, etc., tienen visiones de muchas cadenas con infraestructura compartida. Esto tiene como objetivo proporcionar una experiencia de usuario más fluida entre cadenas en el mismo ecosistema (por ejemplo, entre dos cadenas dentro de la Superchain) frente a cadenas completamente aisladas (por ejemplo, entre Ethereum y Solana).

Sin embargo, los planes actuales (donde existen) todavía están muy lejos de ser competitivos con un único Estado compartido. Además, no abordan la interoperabilidad entre ecosistemas (por ejemplo, de Superchain a Hyperchain). Construir modulares no debería significar construir islas.

Es más complicado para los usuarios mantener cuentas en muchas cadenas. Es peor UX seguir uniendo y preocupándose por qué token de gasolina necesita. Es más complicado y costoso depender de proveedores de infraestructura para operar y mantener tantas cadenas.

Siempre hemos apreciado la simplicidad de la visión de Solana. Una máquina de estado compartida altamente optimizada con la escala necesaria para admitir la mayoría de casos de uso valiosos. Esto a menudo se considera incompatible con una hoja de ruta centrada en el resumen, pero ese simplemente no es el caso. Queremos combinar lo mejor de ambos mundos.

Esta idea errónea surge debido al hecho de que los paquetes acumulativos actuales ejecutan en gran medida el EVM estándar de un solo subproceso sin cambios para aprovechar los primeros efectos de la red. Como resultado, a menudo vemos que se cita el “espacio de bloques dedicado” como motivo para implementar un paquete acumulativo específico de la aplicación. Esas locas mentas de NFT no deberían aumentar los precios de todas las demás aplicaciones de su cadena, pero la respuesta no es crear su propia cadena. Esto es como usar un mazo para partir un maní. Haces concesiones dolorosas e innecesarias (complejidad, costo, peor UX, liquidez fragmentada, etc.). La solución óptima es increíblemente clara: simplemente use una máquina virtual paralelizada con mercados de tarifas locales para puntos de acceso estatales. Eso es exactamente lo que trae el SVM.

Ethereum es el centro intelectual, social y económico de las criptomonedas. Su talón de Aquiles ha ido escalando. El escalado de DA todavía está en proceso y los entornos de ejecución L2 existentes no pueden competir con innovaciones más recientes como SVM. Tememos que el ecosistema Ethereum se vea sorprendido por cualquier aumento brusco de la actividad tal como está hoy. Los EVM de un solo subproceso y los DA restringidos conducirían rápidamente a un resurgimiento de tarifas elevadas, excepto esta vez en los rollups.

Creemos que Eclipse Mainnet es la solución obvia: unir el rendimiento de Solana con la seguridad, la verificabilidad y los efectos de red de la hoja de ruta centrada en el resumen.

Pensamientos de despedida

La belleza de Ethereum es que se come la innovación. La hoja de ruta centrada en rollups es el epítome de esto, delegando la ejecución y la innovación al libre mercado. Los L2 tienen la increíble capacidad de aprovechar los efectos de red y las garantías de liquidación de Ethereum mientras experimentan con los mejores entornos de ejecución nuevos. Eclipse Mainnet es el cumplimiento natural de esta visión.

Si algún día aparece una capa de ejecución con mejor rendimiento, estaremos increíblemente emocionados de verla implementada como un Ethereum L2 competitivo. Hasta entonces, el SVM sigue siendo el estándar.

Para participar, comuníquese con nosotros enhttp://mailto:[email protected]/[email protected] para obtener instrucciones sobre la testnet.

Descargo de responsabilidad:

1. Este artículo se reimprime de [Espejo]. Todos los derechos de autor pertenecen al autor original [Eclipse]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.