Eclipse Mainnet es una Capa 2 universal que combina las mejores partes de la arquitectura modular:
Capa de liquidación: Ethereum: Eclipse liquidará con Ethereum (es decir, el puente de validación estará en Ethereum) y utilizará ETH como token de gas.
Capa de ejecución: Máquina virtual Solana (SVM): Eclipse ejecutará una SVM de alto rendimiento como entorno de ejecución.
Disponibilidad de datos: Celestia: Eclipse publicará sus datos en Celestia para una disponibilidad de datos (DA) escalable.
Prueba: RISC Zero: Eclipse utilizará RISC Zero para pruebas de fraude con conocimiento cero (¡sin la necesidad de serialización de estado intermedio!)
La mayoría de los aspectos más destacados de Eclipse han girado en torno a la implementación de paquetes acumulativos de aplicaciones específicas para varios proyectos, pero ahora más que nunca está claro que Ethereum necesita una Capa 2 universal que pueda alcanzar una escala real. La mayoría de las aplicaciones no se beneficiarán de la personalización de cadenas específicas de aplicaciones, y el aislamiento y la complejidad resultantes pueden conducir a una peor experiencia para el usuario y el desarrollador.
A menudo existe una falsa dicotomía entre la visión de los paquetes acumulativos modulares y la capacidad de tener una única cadena con escalamiento masivo, ejecución paralela y estado compartido. "Modular" a menudo se combina con "específico de la aplicación", lo que lleva a pensar que la acumulación significa un mundo de muchas cadenas fragmentadas y de bajo rendimiento.
Capa de ejecución: velocidad y escala de Solana
Eclipse Mainnet utilizará el mejor entorno de ejecución de su clase, similar a Solana. Esto trae enormes ventajas:
Ejecución paralela optimizada
SVM y su tiempo de ejecución Sealevel son famosos por su soporte para la ejecución de transacciones paralelas. Las transacciones que no tocan estados superpuestos se pueden ejecutar en paralelo en lugar de en serie.
Esto permite que SVM escale directamente con el hardware a medida que el procesador continúa agregando más núcleos a menor costo. Los tiempos de ejecución de un solo subproceso (como el EVM actual) inherentemente no se benefician de un menor costo por núcleo. Durante la última década, las mejoras en el rendimiento de un solo subproceso han ido disminuyendo constantemente. Casi todas las mejoras aún provienen del aumento del número de núcleos, por lo que es fundamental aprovechar esta tendencia para la paralelización de cargas de trabajo:
Aunque ha habido algunos intentos muy tempranos de paralelizar el EVM, agregarlo manteniendo la compatibilidad conlleva compensaciones fundamentales, incluido un rendimiento subóptimo sin abordar otros cuellos de botella (como el crecimiento del estado). Los contratos que declaran dependencias estatales por adelantado (como en SVM) logran una paralelización óptima.
Mercado de tarifas nativo
La mayoría de los mercados de tarifas actuales son globales, lo que significa que una aplicación popular aumentará las tarifas para todos los usuarios de la cadena. Una acuñación de NFT no debería inutilizar toda la cadena para todo lo demás. El increíble trabajo de Solana en un mercado de tarifas nativo resuelve este problema de contención entre aplicaciones estatales. En su implementación actual, el programador prioriza las transacciones sin conflictos, lo que permite que las transacciones libres de conflictos se realicen a una tarifa más baja. A largo plazo, los mercados de tarifas nativos se implementarán a nivel de protocolo. Esto garantiza que los aumentos de tarifas para una sola solicitud no afecten a otras partes de la cadena.
El mercado de tarifas nativo se beneficia del exclusivo tiempo de ejecución de paralelización de Solana. Intentar implementar un mercado de tarifas nativo para los puntos de acceso estatales en el EVM usando heurísticas (es decir, no declarar el acceso estatal con anticipación) introduciría ineficiencias y posibles vectores de ataque.
También se están realizando algunas investigaciones iniciales para que las aplicaciones puedan internalizar fácilmente el valor nativo de la propia aplicación, lo que hoy en día a menudo requiere más creatividad en el diseño a nivel de aplicación.
Gestión del crecimiento estatal
Antes de que la EVM llegue siquiera a considerar la ejecución secuencial como un cuello de botella, el crecimiento del estado es su cuello de botella más apremiante.
Debido a que los estados no tienen árboles Merkle, Solana no introduce la sobrecarga de actualizar el árbol Merkle para cada actualización de estado. En cambio, después de cada época (2,5 días), se archiva todo el estado. Esto es más económico que el archivado en vivo (como en EVM).
Más importante aún, EVM tiene acceso dinámico a la cuenta (es decir, las transacciones pueden tocar cualquier estado bajo demanda). Esta búsqueda dinámica de estado significa que el estado no se puede cargar en la memoria antes de la ejecución. En SVM, cada transacción especifica todos los estados necesarios para su ejecución.
Por lo tanto, el tamaño del estado no afecta la ejecución de SVM. Suponiendo que los validadores actualicen sus discos de almacenamiento cada dos años, la red puede duplicar de forma segura el tamaño de la instantánea cada dos años sin encontrar problemas importantes.
Además, equipos como Helius están mejorando activamente la accesibilidad de los datos históricos y reduciendo el tamaño del estado mediante la compresión.
Compatibilidad EVM
Neon EVM es un contrato inteligente de máquina virtual Ethereum que se puede implementar en cualquier cadena SVM. Esto brinda compatibilidad total con EVM (incluido el soporte de código de bytes de EVM y Ethereum JSON-RPC) a Eclipse Mainnet, con un mayor rendimiento que el EVM de un solo subproceso. Debido a que cada instancia de Neon EVM tiene su propio mercado de tarifas nativo, las aplicaciones pueden simplemente implementar sus propios contratos para aprovechar los beneficios de la cadena de aplicaciones sin interrumpir la UX, la seguridad o la liquidez.
Además, el compilador Solang puede compilar el código de contrato inteligente de Solidity en un código de bytes SVM.
Instantáneas de MetaMask
Históricamente, guiar a los usuarios de EVM para que utilicen cadenas que no sean EVM ha sido una barrera importante, pero los MetaMask Snaps recientemente anunciados romperán esta barrera. Los usuarios de EVM pueden seguir usando MetaMask sin cambiar de billetera. Gracias a las contribuciones de código abierto de Drift para crear una excelente implementación de MetaMask Snaps, la experiencia es similar a interactuar con cualquier cadena EVM. Los usuarios de Eclipse Mainnet podrán interactuar con aplicaciones de forma nativa en MetaMask o utilizar carteras nativas de Solana como Salmon.
Bailarina de fuego
Firedancer es el muy esperado cliente de Solana desarrollado por Jump y está diseñado para mejorar en gran medida el rendimiento, la resiliencia y la eficiencia de la red. En el lanzamiento, nos mantendremos lo más cerca posible del cliente principal de Solana, pero planeamos adoptar Firedancer una vez que el código esté activo y estable.
seguridad
Solana corre con una superficie de ataque significativamente reducida, lo que evita los ataques de reentrada que hemos visto demasiadas veces. Específicamente, el tiempo de ejecución de Solana solo permite la autorrecursión del programa y no permite llamadas arbitrarias reentrantes entre programas. Además, la separación de estado y código da como resultado un código sin estado, que generalmente es más fácil de probar de manera efectiva.
Prueba más sencilla
SVM se basa en registros y el conjunto de instrucciones es mucho más pequeño que EVM, lo que hace que la ejecución de SVM sea más fácil de probar en ZK. Para resúmenes optimistas, un diseño basado en registros permite puntos de control más simples.
Capa de liquidación: seguridad y liquidez en Ethereum
Al igual que el gran resumen de hoy, Eclipse Mainnet se liquidará con Ethereum. Específicamente, esto significa que nuestro puente de verificación en Ethereum se integrará directamente en Eclipse. El nodo Eclipse observará este puente para determinar la "cadena canónica". Este 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 y evitará que se confirmen estados no válidos. Además, impondrá vitalidad final y resistencia a la censura en ciertos casos de fracaso. Incluso si el ordenador de L2 deja de funcionar o inicia la censura, los usuarios podrán forzar la inclusión de sus transacciones a través del puente.
Debido a estas propiedades de seguridad, las bibliotecas válidas y óptimas a menudo se denominan "Ethereum L2". L2BEAT define L2 como "una cadena que deriva total o parcialmente su seguridad de Ethereum Layer 1, de modo que los usuarios no necesitan depender de la honestidad de los validadores L2 para mantener los fondos seguros".
La liquidación de Ethereum refleja la importancia de los activos nativos de Ethereum en las economías DeFi y NFT de Eclipse Mainnet. ETH es claramente la mejor moneda descentralizada preferida para la mayoría de los usuarios, por lo que también usaremos ETH como nuestro token de gas. A largo plazo, la abstracción de tarifas permitirá a los usuarios pagar con cualquier token de su elección (por ejemplo, USDC). Actualmente, Eclipse Mainnet no tiene planes de emitir sus propios tokens.
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.
Lamentablemente, el rendimiento y las tarifas objetivo de Eclipse Mainnet no están respaldados por las limitaciones actuales de ancho de banda de Ethereum. Esto es cierto incluso después de EIP-4844 (también conocido como "Proto-danksharding"), que proporciona ~0,375 MB de espacio de blob por bloque (con un límite por bloque de ~0,75 MB).
Para transferencias ERC-20 con compresión básica (~154 bytes por transacción), esto equivale a ~213 TPS para todos los Rollups.
Para intercambios comprimidos (~400 bytes por transacción), esto equivale a ~82 TPS en total.
En comparación, Celestia lanzará bloques de 2 MB a finales de este año. Una vez que se conecten suficientes nodos ligeros de muestreo de disponibilidad de datos (DAS) y la red resulte estable, se espera que el espacio del blob aumente a 8 MB poco después del lanzamiento. El nodo de luz DAS cumple dos funciones clave:
Permitir a los usuarios verificar por sí mismos si los datos del bloque Eclipse están disponibles;
Ayuda a escalar de forma segura toda la red porque a medida que más nodos ligeros DAS se conectan, la capa DA puede aumentar su rendimiento de forma segura.
Se espera que Celestia sea la primera capa DA que permita DAS en producción. Esto contrasta con los Comités de Disponibilidad de Datos (DAC) tradicionales, que reintroducen el supuesto de honestidad del comité sin verificación del usuario (similar a las cadenas de bloques monolíticas existentes).
Existen supuestos de seguridad inherentes para los usuarios que conectan fondos desde la red principal de Ethereum a cualquier cadena que utilice DA fuera de la cadena. En particular, los validadores de Celestia pueden técnicamente rechazar los datos de las transacciones pero afirmar que los datos están disponibles en el puente Ethereum. De hecho, el consenso de prueba de participación de Celestia significa que la retención de datos por parte de Celestia es punible, lo que nos hace creer que este riesgo no es realista.
En general, el soporte para nodos ligeros DAS de Celestia, las propiedades de seguridad criptoeconómicas y el rendimiento DA altamente escalable desde el primer día lo convierten en la opción clara para Eclipse Mainnet en la actualidad.
También pretendemos monitorear el progreso de Ethereum en el escalado de DA después de EIP-4844. Están surgiendo nuevas investigaciones interesantes que pueden proporcionar DA de alto rendimiento antes de lo que se pensaba (este último utiliza tablas hash distribuidas más avanzadas). Si Ethereum proporciona mayor escala a nuestros usuarios, evaluaremos la posibilidad de migrar a Ethereum DA.
Prueba: prueba de fraude RISC Zero ZK (¡no se requiere serialización de estado intermedio!)
Nuestra prueba será similar al SIMD a prueba de fraude SVM de Anatoly, que a su vez es similar a la idea de John Adler de que la serialización estatal es costosa y que se puede evitar.
Específicamente, queremos evitar reintroducir árboles Merkle en SVM. Intentamos insertar un árbol Merkle disperso después de cada transacción en SVM, pero la actualización del árbol Merkle resultó en una pérdida de rendimiento significativa. No utilizar árboles Merkle excluye los marcos acumulativos de propósito general existentes (como la pila OP) como base para el resumen SVM, y también requiere arquitecturas más creativas a prueba de fallas.
En resumen, la prueba de fallo requiere:
Compromiso con la entrada de transacciones,
la transacción en sí, y
Demostrar que volver a ejecutar la transacción da como resultado una salida diferente a la especificada en la cadena.
Los compromisos de entrada generalmente se logran proporcionando una raíz Merkle del árbol de estado consolidado. Nuestro ejecutor publicará una lista de entradas y salidas (incluidos los hashes de cuenta y el estado global asociado) para cada transacción, así como un índice de la transacción que produjo cada entrada. Las transacciones se publican en Celestia, por lo que cualquier nodo completo puede autoextraer la cuenta en su propio estado, calcular la cuenta de salida y confirmar que el compromiso en Ethereum es correcto.
Hay dos tipos principales de fallas posibles:
Salida de error: en este caso, el verificador proporciona prueba de conocimiento cero en cadena de la salida correcta de la ejecución de SVM. Usamos RISC Zero para crear una prueba de conocimiento cero de ejecución SVM, que es una continuación de nuestra prueba anterior de ejecución de código de bytes BPF. Esto permite que nuestro contrato de liquidación garantice la corrección sin tener que ejecutar estas transacciones en la cadena.
Entrada incorrecta: en este caso, el validador publica una referencia a datos históricos en la cadena, lo que muestra que el estado de la entrada no coincide con lo que se afirmó. Utilizando el Puente de Gravedad Cuántica de Celestia, nuestro contrato de conciliación garantiza que estos datos históricos realmente demuestren un fraude.
Estamos sobre los hombros de gigantes. El paquete acumulativo de hoy ha avanzado el estado de la investigación en toda nuestra industria y ofrece a los usuarios de Ethereum tarifas más bajas que L1.
Sin embargo, no aprovechan al máximo las últimas tecnologías que requieren gran escala. Increíbles avances recientes han eliminado la necesidad de hacer estas concesiones que hacían los rollups anteriores, poniéndolos efectivamente en desventaja:
VM paralela de alto rendimiento (como SVM);
Extensión DA con soporte para nodos ligeros DAS (como Celestia);
Avances en la infraestructura de prueba que la hacen práctica en todas partes (por ejemplo, RISC Zero);
Portabilidad mejorada entre ecosistemas de código (por ejemplo, Neon y Solang) y usuarios (por ejemplo, MetaMask Snaps)
Podemos aprender de las limitaciones que enfrentan otras cadenas y elegir las mejores piezas para una expansión a largo plazo.
A menudo escuchamos hablar de un millón de paquetes acumulativos de aplicaciones específicas en el futuro.
La personalización a nivel de consenso puede ser muy valiosa para ciertas aplicaciones (como dYdX v4), y estaremos encantados de ayudar al equipo a lanzar paquetes acumulativos específicos de aplicaciones.
Sin embargo, estas situaciones son raras. Esta es la razón por la que la mayoría de los paquetes acumulativos nuevos siguen siendo simples bifurcaciones de EVM. Los problemas de los desarrolladores no se resolverán fragmentando la UX en más cadenas. El principal caso de uso encontrado para millones de cadenas hoy en día a menudo parece ser simplemente el lanzamiento de más monedas. Para la gran mayoría de los casos de uso, hoy en día no existe la necesidad de una personalización completa de la pila de tecnología.
Incluso si existe una demanda real, la infraestructura necesaria para respaldar muchas cadenas de aplicaciones con una UX competitiva no estará disponible durante años (si es que existe). La Superchain de Optimism (pila OP), las Hyperchains de zkSync (pila ZK), la cadena Orbit de Arbitrum, etc. tienen la visión de muchas cadenas con infraestructura compartida. Esto tiene como objetivo proporcionar una experiencia de usuario más fluida para las operaciones entre cadenas dentro del mismo ecosistema (por ejemplo, entre dos cadenas dentro de una Superchain), en lugar de cadenas completamente aisladas (por ejemplo, entre Ethereum y Solana).
Sin embargo, los planes actuales (si es que existen) están lejos de prometer competir con un único Estado compartido. Además, no abordan problemas de interoperabilidad entre ecosistemas (por ejemplo, de Superchain a Hyperchain). Construir modularidad no debería significar construir silos.
Es más complicado para los usuarios mantener cuentas en muchas cadenas. Cruzar cadenas constantemente y preocuparse por los tokens de gasolina necesarios es una peor experiencia para el usuario. Depender de proveedores de infraestructura para operar y mantener tantas cadenas también es más complejo y costoso.
Siempre hemos admirado la simplicidad de la visión de Solana. Una máquina de estado compartida altamente optimizada con la escala necesaria para admitir los casos de uso más valiosos. Esto a menudo se considera incompatible con las hojas de ruta centradas en rollups, pero en realidad no es el caso. Queríamos combinar lo mejor de ambos mundos.
Este malentendido se debe al hecho de que los paquetes acumulativos actuales ejecutan en gran medida el EVM original de un solo subproceso, que se ha mantenido prácticamente sin cambios para aprovechar los primeros efectos de la red. Por lo tanto, a menudo vemos que se cita el "espacio de bloque privado" como el motivo para implementar paquetes acumulativos de aplicaciones específicas. No deberían aumentar los precios de otras aplicaciones en su cadena debido a alguna loca acuñación de NFT, pero la respuesta no es construir su propia cadena. Hace concesiones dolorosas e innecesarias (complejidad, costo, peor experiencia de usuario, liquidez fragmentada, etc.). La mejor solución es clara: simplemente use una máquina virtual paralela con un mercado de tarifas nativo para los puntos de acceso estatales. Esto es exactamente lo que aporta SVM.
Ethereum es el centro intelectual, social y económico de las criptomonedas. Su talón de Aquiles siempre ha sido la expansión. La expansión de la disponibilidad de datos aún es un trabajo en progreso y los entornos de ejecución L2 existentes no pueden competir con innovaciones más recientes como las SVM. Nos preocupa que si el status quo actual continúa, el ecosistema Ethereum será tomado por sorpresa en caso de cualquier aumento dramático en la actividad. Las EVM de un solo subproceso y la disponibilidad limitada de datos pueden conducir rápidamente al resurgimiento de costos elevados, solo que esta vez en acumulaciones.
Creemos que Eclipse Mainnet es la solución obvia: combinar el rendimiento de Solana con la seguridad, la verificabilidad y los efectos de red de una hoja de ruta centrada en rollups.
Conclusión
La belleza de Ethereum es que está en constante innovación. Las hojas de ruta centradas en rollups ejemplifican esto, delegando la ejecución y la innovación al libre mercado. L2 tiene la asombrosa capacidad de aprovechar los efectos de red y las garantías de liquidación de Ethereum mientras experimenta con los mejores entornos de ejecución nuevos. Eclipse Mainnet es una implementación natural de esta visión.
Si algún día surgiera una capa de ejecución de mayor rendimiento, estaríamos muy emocionados de verla implementada como un Ethereum L2 competitivo. Hasta entonces, SVM sigue siendo el estándar.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Eclipse Mainnet: una capa 2 modular con seguridad Ethereum y velocidad de Solana que aprovecha las fortalezas de otros
Escrito por: Eclipse
Compilado por: Deep Wave TechFlow
Eclipse Mainnet es una Capa 2 universal que combina las mejores partes de la arquitectura modular:
La mayoría de los aspectos más destacados de Eclipse han girado en torno a la implementación de paquetes acumulativos de aplicaciones específicas para varios proyectos, pero ahora más que nunca está claro que Ethereum necesita una Capa 2 universal que pueda alcanzar una escala real. La mayoría de las aplicaciones no se beneficiarán de la personalización de cadenas específicas de aplicaciones, y el aislamiento y la complejidad resultantes pueden conducir a una peor experiencia para el usuario y el desarrollador.
A menudo existe una falsa dicotomía entre la visión de los paquetes acumulativos modulares y la capacidad de tener una única cadena con escalamiento masivo, ejecución paralela y estado compartido. "Modular" a menudo se combina con "específico de la aplicación", lo que lleva a pensar que la acumulación significa un mundo de muchas cadenas fragmentadas y de bajo rendimiento.
Capa de ejecución: velocidad y escala de Solana
Eclipse Mainnet utilizará el mejor entorno de ejecución de su clase, similar a Solana. Esto trae enormes ventajas:
Ejecución paralela optimizada
SVM y su tiempo de ejecución Sealevel son famosos por su soporte para la ejecución de transacciones paralelas. Las transacciones que no tocan estados superpuestos se pueden ejecutar en paralelo en lugar de en serie.
Esto permite que SVM escale directamente con el hardware a medida que el procesador continúa agregando más núcleos a menor costo. Los tiempos de ejecución de un solo subproceso (como el EVM actual) inherentemente no se benefician de un menor costo por núcleo. Durante la última década, las mejoras en el rendimiento de un solo subproceso han ido disminuyendo constantemente. Casi todas las mejoras aún provienen del aumento del número de núcleos, por lo que es fundamental aprovechar esta tendencia para la paralelización de cargas de trabajo:
Aunque ha habido algunos intentos muy tempranos de paralelizar el EVM, agregarlo manteniendo la compatibilidad conlleva compensaciones fundamentales, incluido un rendimiento subóptimo sin abordar otros cuellos de botella (como el crecimiento del estado). Los contratos que declaran dependencias estatales por adelantado (como en SVM) logran una paralelización óptima.
Mercado de tarifas nativo
La mayoría de los mercados de tarifas actuales son globales, lo que significa que una aplicación popular aumentará las tarifas para todos los usuarios de la cadena. Una acuñación de NFT no debería inutilizar toda la cadena para todo lo demás. El increíble trabajo de Solana en un mercado de tarifas nativo resuelve este problema de contención entre aplicaciones estatales. En su implementación actual, el programador prioriza las transacciones sin conflictos, lo que permite que las transacciones libres de conflictos se realicen a una tarifa más baja. A largo plazo, los mercados de tarifas nativos se implementarán a nivel de protocolo. Esto garantiza que los aumentos de tarifas para una sola solicitud no afecten a otras partes de la cadena.
El mercado de tarifas nativo se beneficia del exclusivo tiempo de ejecución de paralelización de Solana. Intentar implementar un mercado de tarifas nativo para los puntos de acceso estatales en el EVM usando heurísticas (es decir, no declarar el acceso estatal con anticipación) introduciría ineficiencias y posibles vectores de ataque.
También se están realizando algunas investigaciones iniciales para que las aplicaciones puedan internalizar fácilmente el valor nativo de la propia aplicación, lo que hoy en día a menudo requiere más creatividad en el diseño a nivel de aplicación.
Gestión del crecimiento estatal
Antes de que la EVM llegue siquiera a considerar la ejecución secuencial como un cuello de botella, el crecimiento del estado es su cuello de botella más apremiante.
Debido a que los estados no tienen árboles Merkle, Solana no introduce la sobrecarga de actualizar el árbol Merkle para cada actualización de estado. En cambio, después de cada época (2,5 días), se archiva todo el estado. Esto es más económico que el archivado en vivo (como en EVM).
Más importante aún, EVM tiene acceso dinámico a la cuenta (es decir, las transacciones pueden tocar cualquier estado bajo demanda). Esta búsqueda dinámica de estado significa que el estado no se puede cargar en la memoria antes de la ejecución. En SVM, cada transacción especifica todos los estados necesarios para su ejecución.
Por lo tanto, el tamaño del estado no afecta la ejecución de SVM. Suponiendo que los validadores actualicen sus discos de almacenamiento cada dos años, la red puede duplicar de forma segura el tamaño de la instantánea cada dos años sin encontrar problemas importantes.
Además, equipos como Helius están mejorando activamente la accesibilidad de los datos históricos y reduciendo el tamaño del estado mediante la compresión.
Compatibilidad EVM
Neon EVM es un contrato inteligente de máquina virtual Ethereum que se puede implementar en cualquier cadena SVM. Esto brinda compatibilidad total con EVM (incluido el soporte de código de bytes de EVM y Ethereum JSON-RPC) a Eclipse Mainnet, con un mayor rendimiento que el EVM de un solo subproceso. Debido a que cada instancia de Neon EVM tiene su propio mercado de tarifas nativo, las aplicaciones pueden simplemente implementar sus propios contratos para aprovechar los beneficios de la cadena de aplicaciones sin interrumpir la UX, la seguridad o la liquidez.
Además, el compilador Solang puede compilar el código de contrato inteligente de Solidity en un código de bytes SVM.
Instantáneas de MetaMask
Históricamente, guiar a los usuarios de EVM para que utilicen cadenas que no sean EVM ha sido una barrera importante, pero los MetaMask Snaps recientemente anunciados romperán esta barrera. Los usuarios de EVM pueden seguir usando MetaMask sin cambiar de billetera. Gracias a las contribuciones de código abierto de Drift para crear una excelente implementación de MetaMask Snaps, la experiencia es similar a interactuar con cualquier cadena EVM. Los usuarios de Eclipse Mainnet podrán interactuar con aplicaciones de forma nativa en MetaMask o utilizar carteras nativas de Solana como Salmon.
Bailarina de fuego
Firedancer es el muy esperado cliente de Solana desarrollado por Jump y está diseñado para mejorar en gran medida el rendimiento, la resiliencia y la eficiencia de la red. En el lanzamiento, nos mantendremos lo más cerca posible del cliente principal de Solana, pero planeamos adoptar Firedancer una vez que el código esté activo y estable.
seguridad
Solana corre con una superficie de ataque significativamente reducida, lo que evita los ataques de reentrada que hemos visto demasiadas veces. Específicamente, el tiempo de ejecución de Solana solo permite la autorrecursión del programa y no permite llamadas arbitrarias reentrantes entre programas. Además, la separación de estado y código da como resultado un código sin estado, que generalmente es más fácil de probar de manera efectiva.
Prueba más sencilla
SVM se basa en registros y el conjunto de instrucciones es mucho más pequeño que EVM, lo que hace que la ejecución de SVM sea más fácil de probar en ZK. Para resúmenes optimistas, un diseño basado en registros permite puntos de control más simples.
Capa de liquidación: seguridad y liquidez en Ethereum
Al igual que el gran resumen de hoy, Eclipse Mainnet se liquidará con Ethereum. Específicamente, esto significa que nuestro puente de verificación en Ethereum se integrará directamente en Eclipse. El nodo Eclipse observará este puente para determinar la "cadena canónica". Este 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 y evitará que se confirmen estados no válidos. Además, impondrá vitalidad final y resistencia a la censura en ciertos casos de fracaso. Incluso si el ordenador de L2 deja de funcionar o inicia la censura, los usuarios podrán forzar la inclusión de sus transacciones a través del puente.
Debido a estas propiedades de seguridad, las bibliotecas válidas y óptimas a menudo se denominan "Ethereum L2". L2BEAT define L2 como "una cadena que deriva total o parcialmente su seguridad de Ethereum Layer 1, de modo que los usuarios no necesitan depender de la honestidad de los validadores L2 para mantener los fondos seguros".
La liquidación de Ethereum refleja la importancia de los activos nativos de Ethereum en las economías DeFi y NFT de Eclipse Mainnet. ETH es claramente la mejor moneda descentralizada preferida para la mayoría de los usuarios, por lo que también usaremos ETH como nuestro token de gas. A largo plazo, la abstracción de tarifas permitirá a los usuarios pagar con cualquier token de su elección (por ejemplo, USDC). Actualmente, Eclipse Mainnet no tiene planes de emitir sus propios tokens.
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.
Lamentablemente, el rendimiento y las tarifas objetivo de Eclipse Mainnet no están respaldados por las limitaciones actuales de ancho de banda de Ethereum. Esto es cierto incluso después de EIP-4844 (también conocido como "Proto-danksharding"), que proporciona ~0,375 MB de espacio de blob por bloque (con un límite por bloque de ~0,75 MB).
En comparación, Celestia lanzará bloques de 2 MB a finales de este año. Una vez que se conecten suficientes nodos ligeros de muestreo de disponibilidad de datos (DAS) y la red resulte estable, se espera que el espacio del blob aumente a 8 MB poco después del lanzamiento. El nodo de luz DAS cumple dos funciones clave:
Se espera que Celestia sea la primera capa DA que permita DAS en producción. Esto contrasta con los Comités de Disponibilidad de Datos (DAC) tradicionales, que reintroducen el supuesto de honestidad del comité sin verificación del usuario (similar a las cadenas de bloques monolíticas existentes).
Existen supuestos de seguridad inherentes para los usuarios que conectan fondos desde la red principal de Ethereum a cualquier cadena que utilice DA fuera de la cadena. En particular, los validadores de Celestia pueden técnicamente rechazar los datos de las transacciones pero afirmar que los datos están disponibles en el puente Ethereum. De hecho, el consenso de prueba de participación de Celestia significa que la retención de datos por parte de Celestia es punible, lo que nos hace creer que este riesgo no es realista.
En general, el soporte para nodos ligeros DAS de Celestia, las propiedades de seguridad criptoeconómicas y el rendimiento DA altamente escalable desde el primer día lo convierten en la opción clara para Eclipse Mainnet en la actualidad.
También pretendemos monitorear el progreso de Ethereum en el escalado de DA después de EIP-4844. Están surgiendo nuevas investigaciones interesantes que pueden proporcionar DA de alto rendimiento antes de lo que se pensaba (este último utiliza tablas hash distribuidas más avanzadas). Si Ethereum proporciona mayor escala a nuestros usuarios, evaluaremos la posibilidad de migrar a Ethereum DA.
Prueba: prueba de fraude RISC Zero ZK (¡no se requiere serialización de estado intermedio!)
Nuestra prueba será similar al SIMD a prueba de fraude SVM de Anatoly, que a su vez es similar a la idea de John Adler de que la serialización estatal es costosa y que se puede evitar.
Específicamente, queremos evitar reintroducir árboles Merkle en SVM. Intentamos insertar un árbol Merkle disperso después de cada transacción en SVM, pero la actualización del árbol Merkle resultó en una pérdida de rendimiento significativa. No utilizar árboles Merkle excluye los marcos acumulativos de propósito general existentes (como la pila OP) como base para el resumen SVM, y también requiere arquitecturas más creativas a prueba de fallas.
En resumen, la prueba de fallo requiere:
Los compromisos de entrada generalmente se logran proporcionando una raíz Merkle del árbol de estado consolidado. Nuestro ejecutor publicará una lista de entradas y salidas (incluidos los hashes de cuenta y el estado global asociado) para cada transacción, así como un índice de la transacción que produjo cada entrada. Las transacciones se publican en Celestia, por lo que cualquier nodo completo puede autoextraer la cuenta en su propio estado, calcular la cuenta de salida y confirmar que el compromiso en Ethereum es correcto.
Hay dos tipos principales de fallas posibles:
Estamos sobre los hombros de gigantes. El paquete acumulativo de hoy ha avanzado el estado de la investigación en toda nuestra industria y ofrece a los usuarios de Ethereum tarifas más bajas que L1.
Sin embargo, no aprovechan al máximo las últimas tecnologías que requieren gran escala. Increíbles avances recientes han eliminado la necesidad de hacer estas concesiones que hacían los rollups anteriores, poniéndolos efectivamente en desventaja:
Podemos aprender de las limitaciones que enfrentan otras cadenas y elegir las mejores piezas para una expansión a largo plazo.
A menudo escuchamos hablar de un millón de paquetes acumulativos de aplicaciones específicas en el futuro.
La personalización a nivel de consenso puede ser muy valiosa para ciertas aplicaciones (como dYdX v4), y estaremos encantados de ayudar al equipo a lanzar paquetes acumulativos específicos de aplicaciones.
Sin embargo, estas situaciones son raras. Esta es la razón por la que la mayoría de los paquetes acumulativos nuevos siguen siendo simples bifurcaciones de EVM. Los problemas de los desarrolladores no se resolverán fragmentando la UX en más cadenas. El principal caso de uso encontrado para millones de cadenas hoy en día a menudo parece ser simplemente el lanzamiento de más monedas. Para la gran mayoría de los casos de uso, hoy en día no existe la necesidad de una personalización completa de la pila de tecnología.
Incluso si existe una demanda real, la infraestructura necesaria para respaldar muchas cadenas de aplicaciones con una UX competitiva no estará disponible durante años (si es que existe). La Superchain de Optimism (pila OP), las Hyperchains de zkSync (pila ZK), la cadena Orbit de Arbitrum, etc. tienen la visión de muchas cadenas con infraestructura compartida. Esto tiene como objetivo proporcionar una experiencia de usuario más fluida para las operaciones entre cadenas dentro del mismo ecosistema (por ejemplo, entre dos cadenas dentro de una Superchain), en lugar de cadenas completamente aisladas (por ejemplo, entre Ethereum y Solana).
Sin embargo, los planes actuales (si es que existen) están lejos de prometer competir con un único Estado compartido. Además, no abordan problemas de interoperabilidad entre ecosistemas (por ejemplo, de Superchain a Hyperchain). Construir modularidad no debería significar construir silos.
Es más complicado para los usuarios mantener cuentas en muchas cadenas. Cruzar cadenas constantemente y preocuparse por los tokens de gasolina necesarios es una peor experiencia para el usuario. Depender de proveedores de infraestructura para operar y mantener tantas cadenas también es más complejo y costoso.
Siempre hemos admirado la simplicidad de la visión de Solana. Una máquina de estado compartida altamente optimizada con la escala necesaria para admitir los casos de uso más valiosos. Esto a menudo se considera incompatible con las hojas de ruta centradas en rollups, pero en realidad no es el caso. Queríamos combinar lo mejor de ambos mundos.
Este malentendido se debe al hecho de que los paquetes acumulativos actuales ejecutan en gran medida el EVM original de un solo subproceso, que se ha mantenido prácticamente sin cambios para aprovechar los primeros efectos de la red. Por lo tanto, a menudo vemos que se cita el "espacio de bloque privado" como el motivo para implementar paquetes acumulativos de aplicaciones específicas. No deberían aumentar los precios de otras aplicaciones en su cadena debido a alguna loca acuñación de NFT, pero la respuesta no es construir su propia cadena. Hace concesiones dolorosas e innecesarias (complejidad, costo, peor experiencia de usuario, liquidez fragmentada, etc.). La mejor solución es clara: simplemente use una máquina virtual paralela con un mercado de tarifas nativo para los puntos de acceso estatales. Esto es exactamente lo que aporta SVM.
Ethereum es el centro intelectual, social y económico de las criptomonedas. Su talón de Aquiles siempre ha sido la expansión. La expansión de la disponibilidad de datos aún es un trabajo en progreso y los entornos de ejecución L2 existentes no pueden competir con innovaciones más recientes como las SVM. Nos preocupa que si el status quo actual continúa, el ecosistema Ethereum será tomado por sorpresa en caso de cualquier aumento dramático en la actividad. Las EVM de un solo subproceso y la disponibilidad limitada de datos pueden conducir rápidamente al resurgimiento de costos elevados, solo que esta vez en acumulaciones.
Creemos que Eclipse Mainnet es la solución obvia: combinar el rendimiento de Solana con la seguridad, la verificabilidad y los efectos de red de una hoja de ruta centrada en rollups.
Conclusión
La belleza de Ethereum es que está en constante innovación. Las hojas de ruta centradas en rollups ejemplifican esto, delegando la ejecución y la innovación al libre mercado. L2 tiene la asombrosa capacidad de aprovechar los efectos de red y las garantías de liquidación de Ethereum mientras experimenta con los mejores entornos de ejecución nuevos. Eclipse Mainnet es una implementación natural de esta visión.
Si algún día surgiera una capa de ejecución de mayor rendimiento, estaríamos muy emocionados de verla implementada como un Ethereum L2 competitivo. Hasta entonces, SVM sigue siendo el estándar.