Ethereum aims to become the global ledger: a platform for storing civil assets and records, serving as the foundational layer for finance, governance, high-value data certification, and more. This requires two conditions: scalability and resilience. The Fusaka hard fork aims to increase the available space for layer 2 (L2) data by ten times, and the currently proposed 2026 roadmap also suggests similar significant expansion for layer 1 (L1). Meanwhile, Ethereum has completed its merge upgrade to a Proof of Stake mechanism, leading to a rapid increase in client diversity, ongoing work on zero-knowledge proof (ZK Verifiability) verifiability, and resistance to quantum computing capabilities, with various applications becoming increasingly robust.
Este artículo tiene como objetivo centrarse en un aspecto de la resiliencia (que también afectará a la escalabilidad), un aspecto que es igualmente importante pero que a menudo es subestimado, es decir, la simplicidad del protocolo.
Una de las grandes ventajas del Bitcoin es que su protocolo es extremadamente simple y elegante.
La blockchain está compuesta por una serie de bloques, cada uno de los cuales está conectado al bloque anterior a través de un valor hash. La validez de los bloques se verifica mediante un mecanismo de prueba de trabajo, es decir, verificando si los primeros dígitos de su valor hash son ceros. Cada bloque contiene varias transacciones, y las monedas gastadas en estas transacciones provienen ya sea de la minería o de las salidas de transacciones anteriores. El mecanismo central del protocolo Bitcoin radica en esto. Incluso un estudiante de secundaria inteligente puede entender completamente este protocolo, y los programadores incluso pueden escribir un cliente como un proyecto aficionado.
Mantener la simplicidad del protocolo ofrece una ventaja clave para que Bitcoin o Ethereum se conviertan en la capa base neutral reconocida a nivel mundial:
Un protocolo simple es más fácil de analizar, lo que puede atraer a más participantes a involucrarse en la investigación, desarrollo y gobernanza del protocolo, al mismo tiempo que reduce el riesgo de monopolio tecnológico.
La simplificación de la estructura del protocolo reduce significativamente la inversión en el desarrollo para la integración con nuevas infraestructuras (como clientes, probadores, herramientas de registro y otras herramientas de desarrollo).
El diseño simplificado del protocolo reduce eficazmente los costos de mantenimiento a largo plazo.
Los riesgos de vulnerabilidades graves en la implementación y especificaciones del protocolo se han reducido significativamente, lo que facilita la verificación de la seguridad del sistema.
Reducir la superficie de ataque social: la simplificación de componentes hace que el sistema sea más fácil de proteger contra la infiltración de intereses especiales, mejorando la seguridad general.
A lo largo de la historia, Ethereum a menudo ha fallado en implementar el principio de simplicidad en el diseño del protocolo (en parte debido a decisiones personales), lo que ha llevado directamente a altos costos de desarrollo, frecuentes problemas de seguridad y una cultura de desarrollo cerrada. La raíz de estos problemas a menudo radica en la búsqueda de beneficios a corto plazo que han demostrado ser ineficaces en la práctica. Este artículo explicará cómo Ethereum puede lograr una simplicidad de protocolo cercana a la de Bitcoin en los próximos cinco años.
Capa de consenso simplificada
Simulación de la finalización de tres intervalos en 3sf - mini (código de red de prueba de Ethereum)
El nuevo esquema de capa de consenso (anteriormente denominado "cadena de haz") tiene como objetivo integrar los logros de investigación de la última década en teoría de consenso, pruebas de conocimiento cero (ZK-SNARK), economía de participación, entre otros, para construir un mecanismo de consenso óptimo orientado al desarrollo a largo plazo para Ethereum. En comparación con la actual cadena de balizas, este esquema presenta características significativamente simplificadas, que se concretan en los siguientes aspectos:
Innovación en la arquitectura de finalización en tres ranuras (3-slot finality): se eliminó la división conceptual entre ranuras independientes (slot) y épocas (epoch), se canceló el mecanismo de rotación de comités y componentes complejos como los comités de sincronización, simplificando drásticamente las especificaciones del protocolo. La implementación central requiere solo unas 200 líneas de código, alcanzando niveles de seguridad casi óptimos en comparación con el protocolo Gasper.
Optimización de la gestión de nodos de validación: al limitar el número de nodos de validación activos, se permite que las reglas de selección de bifurcación (fork choice rule) puedan adoptar un esquema de implementación más simplificado, al mismo tiempo que se garantiza la seguridad del sistema.
Actualización del protocolo de agregación: el mecanismo de agregación basado en STARK permite que cualquier nodo asuma el papel de agregador, evitando la dependencia de confianza en el agregador y el problema del desperdicio de recursos de los campos de bits (bitfield) duplicados. Aunque la criptografía de agregación en sí misma tiene una complejidad bastante alta, su característica de alta encapsulación reduce significativamente el riesgo sistémico.
Mejoras en la arquitectura de red P2P: Las dos optimizaciones anteriores ofrecen la posibilidad de construir una arquitectura de red punto a punto más simple y eficiente.
Reestructuración del proceso de verificación: rediseñar los mecanismos de acceso, salida, retiro, migración de claves y penalización por pereza de los nodos de verificación, mientras se reduce la cantidad de código y se aclaran los mecanismos de garantía de los parámetros clave (como el período subjetivo débil).
Ventajas técnicas: La característica de desacoplamiento relativo entre la capa de consenso y la capa de ejecución EVM proporciona un mayor espacio técnico para la optimización continua. En comparación, las mejoras similares en la capa de ejecución enfrentan mayores desafíos.
Capa de ejecución simplificada
La complejidad de la Máquina Virtual de Ethereum (EVM) sigue creciendo, donde muchos diseños complejos han demostrado ser innecesarios (en muchos casos, por decisiones erróneas de mi parte): una máquina virtual de 256 bits sobreoptimizadas para algoritmos criptográficos específicos, los cuales han ido perdiendo importancia; así como contratos precompilados diseñados en exceso para un único escenario de uso, cuyo uso real es muy bajo.
Intentar resolver los problemas existentes a través de parches dispersos ya no es viable. Eliminar el código de operación SELFDESTRUCT requiere un gran esfuerzo pero solo ofrece beneficios limitados; el reciente debate sobre EOF ha resaltado aún más las dificultades de realizar modificaciones progresivas en la máquina virtual.
Como alternativa, recientemente propuse un camino de transformación más agresivo: en lugar de realizar modificaciones de tamaño medio (pero aún destructivas) en el EVM a cambio de un aumento de rendimiento de 1.5 veces, sería mejor hacer una transición directa a una arquitectura de máquina virtual completamente nueva y significativamente mejor, para lograr un aumento de rendimiento de cien veces. Al igual que con la fusión (The Merge), reducimos la cantidad de cambios destructivos, pero aumentamos el valor estratégico de cada cambio. En concreto, sugiero adoptar la arquitectura RISC-V o la máquina virtual utilizada por el programa de pruebas ZK de Ethereum en lugar del EVM actual. Esta transformación traerá:
Revolución en la eficiencia: en un entorno de prueba ZK, los contratos inteligentes pueden ejecutarse directamente en la arquitectura objetivo, sin necesidad de gastos de intérprete. Los datos sucintos muestran que, en la mayoría de los escenarios, el rendimiento puede mejorar más de cien veces.
Arquitectura extremadamente simplificada: la especificación RISC-V es mucho más concisa en comparación con EVM, y otras soluciones candidatas (como Cairo) también presentan características de simplicidad.
Las principales ventajas de heredar EOF: incluyen la gestión de segmentos de código, un mejor soporte para el análisis estático y un límite de capacidad de código más grande.
Extensión de la cadena de herramientas para desarrolladores: Solidity y Vyper pueden agregar soporte de compilación para nuevas arquitecturas en el backend; si se elige RISC-V, los desarrolladores de lenguajes populares pueden migrar directamente el código existente.
Optimización de contratos precompilados: la mayoría de las funciones precompiladas ya no serán necesarias, manteniendo solo las operaciones de curva elíptica altamente optimizadas (que podrían eliminarse con el desarrollo de la computación cuántica).
Los principales desafíos son: a diferencia de la solución EOF que se puede implementar de inmediato, la nueva máquina virtual necesita más tiempo para beneficiar a los desarrolladores. Se puede implementar de manera sincronizada algunas mejoras de EVM de alto valor (como aumentar el límite de tamaño del código del contrato, optimizar el conjunto de instrucciones DUP/SWAP) como una solución de transición a corto plazo.
Esta transformación simplificará significativamente la arquitectura de la máquina virtual. La cuestión clave es: ¿cómo manejar adecuadamente el ecosistema EVM existente?
Estrategia de compatibilidad hacia atrás para la migración de máquinas virtuales
El mayor desafío al simplificar (u optimizar sin aumentar la complejidad) cualquier parte de EVM es cómo equilibrar la implementación de los objetivos esperados con el mantenimiento de la compatibilidad hacia atrás de las aplicaciones existentes.
Lo primero que se debe aclarar es que, incluso para un solo cliente, no existe un estándar único para definir qué es el "repositorio de código de Ethereum".
El objetivo es minimizar el área verde: es decir, el nodo debe ejecutar la lógica necesaria para participar en el consenso de Ethereum, incluyendo el cálculo del estado actual, la generación y verificación de pruebas, FOCIL (nota: confirmar si es una abreviatura técnica) y el proceso de construcción de bloques "fundamentales".
La zona naranja no se puede reducir: si las funciones de la capa de ejecución (ya sea la máquina virtual, contratos precompilados u otros mecanismos) se eliminan de la especificación del protocolo o sus funciones cambian, los clientes que manejan bloques históricos deben mantener esa funcionalidad; sin embargo, los nuevos clientes (incluyendo ZK-EVM o herramientas de verificación formal) pueden ignorar completamente esta parte.
Nueva área amarilla: se refiere al código que tiene un gran valor para el análisis de datos en la cadena actual o la construcción óptima de bloques, pero que no pertenece al mecanismo de consenso. Un ejemplo típico es el soporte de Etherscan y algunos constructores de bloques para las operaciones de usuario de ERC-4337. Si se reemplazan las funciones centrales de Ethereum (como las cuentas externas EOA y sus diversos tipos de transacciones antiguas) por una implementación en la cadena de RISC-V, el código de consenso se simplificará considerablemente, pero los nodos especializados pueden necesitar seguir utilizando el código original para el análisis y procesamiento.
La complejidad de las áreas naranja y amarilla pertenece a la complejidad de encapsulación; cualquier persona que desee entender el protocolo puede omitir estas secciones, y la implementación de Ethereum también puede optar por ignorarlas libremente. Además, los defectos de código en estas áreas no provocarán riesgos de consenso. Esto significa que, en comparación con la complejidad del código en el área verde, la complejidad de las áreas naranja y amarilla tiene un impacto negativo significativamente menor en el sistema en su conjunto.
La idea de migrar el código de la zona verde a la zona amarilla es similar a la solución técnica de compatibilidad a largo plazo que implementa Apple a través de la capa de traducción Rosetta.
Se requiere que todos los contratos precompilados nuevos desarrollados contengan una implementación RISC-V en la cadena conforme a las especificaciones. Este paso tiene como objetivo impulsar la adaptación gradual del ecosistema al entorno de la máquina virtual RISC-V (tomando como ejemplo la migración de EVM a RISC-V, esta solución también es aplicable a la migración de EVM a Cairo u otras máquinas virtuales más eficientes):
Soporte paralelo de dos máquinas virtuales: soporte nativo simultáneo de dos máquinas virtuales, RISC-V y EVM, a nivel de protocolo. Los desarrolladores pueden elegir libremente el lenguaje de desarrollo, y los contratos escritos en diferentes máquinas virtuales pueden interactuar sin problemas.
Reemplazo por fases de los contratos precompilados: excepto por las operaciones de curvas elípticas y el algoritmo hash KECCAK (debido a sus exigentes optimizaciones de rendimiento), todos los contratos precompilados se reemplazan por implementaciones RISC-V a través de un hard fork.
La operación específica es: eliminar el contrato precompilado original mientras se modifica el código de esa dirección (utilizando el modo de bifurcación DAO) de un estado vacío a la implementación correspondiente de RISC-V. Debido a la alta simplicidad de la arquitectura RISC-V, incluso al completar solo este paso, la complejidad general del sistema seguirá disminuyendo.
Despliegue del intérprete EVM en la cadena: Implementación del intérprete EVM basado en RISC-V (la cadena de herramientas de prueba ZK ha impulsado este tipo de desarrollo) y su despliegue como contrato inteligente en la cadena. Años después del lanzamiento de la versión inicial, los contratos EVM existentes se ejecutarán a través de este intérprete, completando así la transición fluida a la nueva máquina virtual.
Implementar simplificaciones a través de componentes de protocolo compartido
Después de completar el paso cuatro, muchas "soluciones de implementación de EVM" seguirán existiendo y se utilizarán para optimizar la construcción de bloques, herramientas para desarrolladores y análisis de datos en la cadena, entre otros escenarios, pero estas implementaciones ya no formarán parte de la norma de consenso central. En ese momento, el mecanismo de consenso de Ethereum solo soportará de manera "nativa" la arquitectura RISC-V.
Implementar simplificaciones a través de componentes de protocolo compartido
La tercera forma de reducir la complejidad general del protocolo (también la más subestimada) es compartir estándares unificados entre diferentes niveles de la pila de protocolos en la medida de lo posible. En términos generales, no es necesario ni beneficioso implementar la misma funcionalidad con diferentes protocolos en diferentes módulos, pero este patrón de diseño sigue existiendo comúnmente, principalmente debido a la falta de una colaboración efectiva entre las diferentes partes de la hoja de ruta del protocolo. A continuación se presentan ejemplos concretos de cómo se puede simplificar Ethereum fortaleciendo la reutilización de componentes a través de capas.
Esquema unificado de código de borrado compartido
Tres tipos de escenarios de aplicación de códigos de corrección de borrado:
Muestreo de disponibilidad de datos: el cliente debe utilizar códigos de corrección de errores al verificar si el bloque ha sido publicado, para asegurar la integridad de los datos.
Difusión P2P eficiente: los nodos pueden confirmar el bloque al recibir n/2 de los n fragmentos, logrando un equilibrio óptimo entre la reducción de la latencia y la redundancia.
Almacenamiento histórico distribuido: los datos históricos de Ethereum se dividen en múltiples bloques de datos, cumpliendo con:
Cada bloque de datos se puede verificar de forma independiente.
Cualquiera de los grupos puede recuperar los n/2 bloques de datos restantes.
Este diseño reduce significativamente el riesgo de pérdida de datos en un solo punto.
Si se utiliza el mismo código de corrección de errores (como el código de Reed-Solomon, código lineal aleatorio, etc.) en los siguientes tres escenarios, se obtendrán ventajas significativas:
Código simplificado;
Mejora de la eficiencia: cuando un nodo necesita descargar datos de fragmentos (en lugar de un bloque completo) debido a un escenario específico, esos datos se pueden utilizar directamente en otros escenarios, evitando la transmisión redundante;
Todos los bloques de datos en todos los escenarios se pueden verificar de manera uniforme a través del hash raíz.
Si se utilizan diferentes códigos de corrección de errores, se deben cumplir los requisitos de compatibilidad: por ejemplo, en las particiones de muestreo de disponibilidad de datos (DAS), se pueden utilizar simultáneamente códigos de Reed-Solomon horizontales y códigos lineales aleatorios verticales, pero ambos códigos deben operar sobre el mismo campo finito.
Formato de serialización unificado
El formato de serialización actual de Ethereum aún se encuentra en un estado semi-normalizado: los datos se pueden re-serializar en cualquier formato y propagarse, siendo la única excepción el hash de la firma de la transacción, que debe adoptar un formato normalizado para garantizar la consistencia del hash. Sin embargo, en el futuro, el grado de normalización del formato de serialización se reforzará aún más, y las principales razones incluyen:
Abstractización de cuentas (EIP-7701): el contenido completo de la transacción será completamente visible para la máquina virtual (VM)
Escenarios de límite de Gas alto: a medida que aumenta el límite de Gas del bloque, los datos de la capa de ejecución deben almacenarse en una estructura de blob.
Cuando se produzca la transformación anterior, podremos aprovechar esta oportunidad para unificar los estándares de serialización de los tres niveles clave de Ethereum: (i) capa de ejecución (ii) capa de consenso (iii) llamada ABI de contrato inteligente
Se sugiere adoptar el formato de serialización SSZ, que tiene las siguientes ventajas:
Decodificación eficiente, los escenarios que incluyen contratos inteligentes se pueden decodificar rápidamente, gracias a su diseño basado en 4 bytes y un manejo reducido de condiciones de frontera.
La capa de consenso se aplica ampliamente y ya ha logrado una profunda integración en la capa de consenso.
Es muy similar al ABI existente, lo que facilita la adaptación y actualización de la cadena de herramientas.
Actualmente, hay equipos técnicos relacionados que están promoviendo el trabajo de migración integral de SSZ. Se sugiere continuar esta ruta técnica en las futuras planificaciones de actualización y expandirse sobre los logros existentes.
estructura de árbol compartido unificada
Cuando se migra de EVM a RISC-V (o a otra arquitectura de máquina virtual simplificada), el árbol Merkle Patricia de seis ramas se convertirá en el mayor cuello de botella en la ejecución de pruebas de bloques (incluso en escenarios normales). Cambiar a una estructura de árbol binario basada en funciones hash más eficientes mejorará significativamente la eficiencia de la prueba y reducirá los costos de almacenamiento de datos para nodos ligeros y otros escenarios de aplicación.
Al implementar esta migración, se debe adoptar de manera sincrónica la misma estructura de árbol para lograr la unificación de la capa de consenso y la capa de ejecución. Esta medida garantiza que toda la pila de Ethereum (incluyendo la capa de consenso y la capa de ejecución) utilice el mismo conjunto de lógica de código para el acceso y análisis de datos.
La trayectoria de evolución desde el estado actual hasta el objetivo
La simplicidad tiene similitudes en muchos aspectos con la descentralización, siendo ambas condiciones fundamentales para lograr la resiliencia del sistema. Definir la simplicidad como un valor central requiere un cambio a nivel cultural: sus beneficios a menudo son difíciles de mostrar de inmediato, mientras que las ganancias a corto plazo que ofrece la búsqueda de funciones complejas son evidentes. Sin embargo, a medida que pasa el tiempo, las ventajas de la simplicidad se volverán cada vez más destacadas: la historia del desarrollo de Bitcoin es una poderosa confirmación de este punto de vista.
Propongo que el diseño del protocolo Ethereum se refiera a la experiencia práctica del proyecto TinyGrad, establezca un límite superior claro para el número de líneas de código para la especificación a largo plazo de Ethereum y se esfuerce por hacer que la simplicidad del código clave del consenso de Ethereum se acerque al nivel de Bitcoin. En concreto, el código que procesa las reglas históricas de Ethereum puede seguir conservándose, pero debe estar estrictamente aislado de la ruta crítica del consenso para garantizar que no afecte a la lógica central del consenso. Al mismo tiempo, el concepto de diseño de "dar prioridad a las soluciones más simples" debe implementarse en la selección de soluciones técnicas, dando prioridad a la complejidad del paquete en lugar de difuminar la complejidad sistémica, y asegurando que todas las decisiones de diseño puedan proporcionar características y garantías claras y verificables, a fin de formar una cultura técnica orientada a la concisión en su conjunto.
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Vitalik nuevo artículo: ¿Cómo logra Ethereum una arquitectura simplificada que compite con Bitcoin?
Título original: Simplificando el L1
Escrito por: Vitalik
Compilado por: lenaxin, ChainCatcher
Ethereum aims to become the global ledger: a platform for storing civil assets and records, serving as the foundational layer for finance, governance, high-value data certification, and more. This requires two conditions: scalability and resilience. The Fusaka hard fork aims to increase the available space for layer 2 (L2) data by ten times, and the currently proposed 2026 roadmap also suggests similar significant expansion for layer 1 (L1). Meanwhile, Ethereum has completed its merge upgrade to a Proof of Stake mechanism, leading to a rapid increase in client diversity, ongoing work on zero-knowledge proof (ZK Verifiability) verifiability, and resistance to quantum computing capabilities, with various applications becoming increasingly robust.
Este artículo tiene como objetivo centrarse en un aspecto de la resiliencia (que también afectará a la escalabilidad), un aspecto que es igualmente importante pero que a menudo es subestimado, es decir, la simplicidad del protocolo.
Una de las grandes ventajas del Bitcoin es que su protocolo es extremadamente simple y elegante.
La blockchain está compuesta por una serie de bloques, cada uno de los cuales está conectado al bloque anterior a través de un valor hash. La validez de los bloques se verifica mediante un mecanismo de prueba de trabajo, es decir, verificando si los primeros dígitos de su valor hash son ceros. Cada bloque contiene varias transacciones, y las monedas gastadas en estas transacciones provienen ya sea de la minería o de las salidas de transacciones anteriores. El mecanismo central del protocolo Bitcoin radica en esto. Incluso un estudiante de secundaria inteligente puede entender completamente este protocolo, y los programadores incluso pueden escribir un cliente como un proyecto aficionado.
Mantener la simplicidad del protocolo ofrece una ventaja clave para que Bitcoin o Ethereum se conviertan en la capa base neutral reconocida a nivel mundial:
Un protocolo simple es más fácil de analizar, lo que puede atraer a más participantes a involucrarse en la investigación, desarrollo y gobernanza del protocolo, al mismo tiempo que reduce el riesgo de monopolio tecnológico.
La simplificación de la estructura del protocolo reduce significativamente la inversión en el desarrollo para la integración con nuevas infraestructuras (como clientes, probadores, herramientas de registro y otras herramientas de desarrollo).
El diseño simplificado del protocolo reduce eficazmente los costos de mantenimiento a largo plazo.
Los riesgos de vulnerabilidades graves en la implementación y especificaciones del protocolo se han reducido significativamente, lo que facilita la verificación de la seguridad del sistema.
Reducir la superficie de ataque social: la simplificación de componentes hace que el sistema sea más fácil de proteger contra la infiltración de intereses especiales, mejorando la seguridad general.
A lo largo de la historia, Ethereum a menudo ha fallado en implementar el principio de simplicidad en el diseño del protocolo (en parte debido a decisiones personales), lo que ha llevado directamente a altos costos de desarrollo, frecuentes problemas de seguridad y una cultura de desarrollo cerrada. La raíz de estos problemas a menudo radica en la búsqueda de beneficios a corto plazo que han demostrado ser ineficaces en la práctica. Este artículo explicará cómo Ethereum puede lograr una simplicidad de protocolo cercana a la de Bitcoin en los próximos cinco años.
Capa de consenso simplificada
Simulación de la finalización de tres intervalos en 3sf - mini (código de red de prueba de Ethereum)
El nuevo esquema de capa de consenso (anteriormente denominado "cadena de haz") tiene como objetivo integrar los logros de investigación de la última década en teoría de consenso, pruebas de conocimiento cero (ZK-SNARK), economía de participación, entre otros, para construir un mecanismo de consenso óptimo orientado al desarrollo a largo plazo para Ethereum. En comparación con la actual cadena de balizas, este esquema presenta características significativamente simplificadas, que se concretan en los siguientes aspectos:
Innovación en la arquitectura de finalización en tres ranuras (3-slot finality): se eliminó la división conceptual entre ranuras independientes (slot) y épocas (epoch), se canceló el mecanismo de rotación de comités y componentes complejos como los comités de sincronización, simplificando drásticamente las especificaciones del protocolo. La implementación central requiere solo unas 200 líneas de código, alcanzando niveles de seguridad casi óptimos en comparación con el protocolo Gasper.
Optimización de la gestión de nodos de validación: al limitar el número de nodos de validación activos, se permite que las reglas de selección de bifurcación (fork choice rule) puedan adoptar un esquema de implementación más simplificado, al mismo tiempo que se garantiza la seguridad del sistema.
Actualización del protocolo de agregación: el mecanismo de agregación basado en STARK permite que cualquier nodo asuma el papel de agregador, evitando la dependencia de confianza en el agregador y el problema del desperdicio de recursos de los campos de bits (bitfield) duplicados. Aunque la criptografía de agregación en sí misma tiene una complejidad bastante alta, su característica de alta encapsulación reduce significativamente el riesgo sistémico.
Mejoras en la arquitectura de red P2P: Las dos optimizaciones anteriores ofrecen la posibilidad de construir una arquitectura de red punto a punto más simple y eficiente.
Reestructuración del proceso de verificación: rediseñar los mecanismos de acceso, salida, retiro, migración de claves y penalización por pereza de los nodos de verificación, mientras se reduce la cantidad de código y se aclaran los mecanismos de garantía de los parámetros clave (como el período subjetivo débil).
Ventajas técnicas: La característica de desacoplamiento relativo entre la capa de consenso y la capa de ejecución EVM proporciona un mayor espacio técnico para la optimización continua. En comparación, las mejoras similares en la capa de ejecución enfrentan mayores desafíos.
Capa de ejecución simplificada
La complejidad de la Máquina Virtual de Ethereum (EVM) sigue creciendo, donde muchos diseños complejos han demostrado ser innecesarios (en muchos casos, por decisiones erróneas de mi parte): una máquina virtual de 256 bits sobreoptimizadas para algoritmos criptográficos específicos, los cuales han ido perdiendo importancia; así como contratos precompilados diseñados en exceso para un único escenario de uso, cuyo uso real es muy bajo.
Intentar resolver los problemas existentes a través de parches dispersos ya no es viable. Eliminar el código de operación SELFDESTRUCT requiere un gran esfuerzo pero solo ofrece beneficios limitados; el reciente debate sobre EOF ha resaltado aún más las dificultades de realizar modificaciones progresivas en la máquina virtual.
Como alternativa, recientemente propuse un camino de transformación más agresivo: en lugar de realizar modificaciones de tamaño medio (pero aún destructivas) en el EVM a cambio de un aumento de rendimiento de 1.5 veces, sería mejor hacer una transición directa a una arquitectura de máquina virtual completamente nueva y significativamente mejor, para lograr un aumento de rendimiento de cien veces. Al igual que con la fusión (The Merge), reducimos la cantidad de cambios destructivos, pero aumentamos el valor estratégico de cada cambio. En concreto, sugiero adoptar la arquitectura RISC-V o la máquina virtual utilizada por el programa de pruebas ZK de Ethereum en lugar del EVM actual. Esta transformación traerá:
Revolución en la eficiencia: en un entorno de prueba ZK, los contratos inteligentes pueden ejecutarse directamente en la arquitectura objetivo, sin necesidad de gastos de intérprete. Los datos sucintos muestran que, en la mayoría de los escenarios, el rendimiento puede mejorar más de cien veces.
Arquitectura extremadamente simplificada: la especificación RISC-V es mucho más concisa en comparación con EVM, y otras soluciones candidatas (como Cairo) también presentan características de simplicidad.
Las principales ventajas de heredar EOF: incluyen la gestión de segmentos de código, un mejor soporte para el análisis estático y un límite de capacidad de código más grande.
Extensión de la cadena de herramientas para desarrolladores: Solidity y Vyper pueden agregar soporte de compilación para nuevas arquitecturas en el backend; si se elige RISC-V, los desarrolladores de lenguajes populares pueden migrar directamente el código existente.
Optimización de contratos precompilados: la mayoría de las funciones precompiladas ya no serán necesarias, manteniendo solo las operaciones de curva elíptica altamente optimizadas (que podrían eliminarse con el desarrollo de la computación cuántica).
Los principales desafíos son: a diferencia de la solución EOF que se puede implementar de inmediato, la nueva máquina virtual necesita más tiempo para beneficiar a los desarrolladores. Se puede implementar de manera sincronizada algunas mejoras de EVM de alto valor (como aumentar el límite de tamaño del código del contrato, optimizar el conjunto de instrucciones DUP/SWAP) como una solución de transición a corto plazo.
Esta transformación simplificará significativamente la arquitectura de la máquina virtual. La cuestión clave es: ¿cómo manejar adecuadamente el ecosistema EVM existente?
Estrategia de compatibilidad hacia atrás para la migración de máquinas virtuales
El mayor desafío al simplificar (u optimizar sin aumentar la complejidad) cualquier parte de EVM es cómo equilibrar la implementación de los objetivos esperados con el mantenimiento de la compatibilidad hacia atrás de las aplicaciones existentes.
Lo primero que se debe aclarar es que, incluso para un solo cliente, no existe un estándar único para definir qué es el "repositorio de código de Ethereum".
El objetivo es minimizar el área verde: es decir, el nodo debe ejecutar la lógica necesaria para participar en el consenso de Ethereum, incluyendo el cálculo del estado actual, la generación y verificación de pruebas, FOCIL (nota: confirmar si es una abreviatura técnica) y el proceso de construcción de bloques "fundamentales".
La zona naranja no se puede reducir: si las funciones de la capa de ejecución (ya sea la máquina virtual, contratos precompilados u otros mecanismos) se eliminan de la especificación del protocolo o sus funciones cambian, los clientes que manejan bloques históricos deben mantener esa funcionalidad; sin embargo, los nuevos clientes (incluyendo ZK-EVM o herramientas de verificación formal) pueden ignorar completamente esta parte.
Nueva área amarilla: se refiere al código que tiene un gran valor para el análisis de datos en la cadena actual o la construcción óptima de bloques, pero que no pertenece al mecanismo de consenso. Un ejemplo típico es el soporte de Etherscan y algunos constructores de bloques para las operaciones de usuario de ERC-4337. Si se reemplazan las funciones centrales de Ethereum (como las cuentas externas EOA y sus diversos tipos de transacciones antiguas) por una implementación en la cadena de RISC-V, el código de consenso se simplificará considerablemente, pero los nodos especializados pueden necesitar seguir utilizando el código original para el análisis y procesamiento.
La complejidad de las áreas naranja y amarilla pertenece a la complejidad de encapsulación; cualquier persona que desee entender el protocolo puede omitir estas secciones, y la implementación de Ethereum también puede optar por ignorarlas libremente. Además, los defectos de código en estas áreas no provocarán riesgos de consenso. Esto significa que, en comparación con la complejidad del código en el área verde, la complejidad de las áreas naranja y amarilla tiene un impacto negativo significativamente menor en el sistema en su conjunto.
La idea de migrar el código de la zona verde a la zona amarilla es similar a la solución técnica de compatibilidad a largo plazo que implementa Apple a través de la capa de traducción Rosetta.
Se requiere que todos los contratos precompilados nuevos desarrollados contengan una implementación RISC-V en la cadena conforme a las especificaciones. Este paso tiene como objetivo impulsar la adaptación gradual del ecosistema al entorno de la máquina virtual RISC-V (tomando como ejemplo la migración de EVM a RISC-V, esta solución también es aplicable a la migración de EVM a Cairo u otras máquinas virtuales más eficientes):
Soporte paralelo de dos máquinas virtuales: soporte nativo simultáneo de dos máquinas virtuales, RISC-V y EVM, a nivel de protocolo. Los desarrolladores pueden elegir libremente el lenguaje de desarrollo, y los contratos escritos en diferentes máquinas virtuales pueden interactuar sin problemas.
Reemplazo por fases de los contratos precompilados: excepto por las operaciones de curvas elípticas y el algoritmo hash KECCAK (debido a sus exigentes optimizaciones de rendimiento), todos los contratos precompilados se reemplazan por implementaciones RISC-V a través de un hard fork.
La operación específica es: eliminar el contrato precompilado original mientras se modifica el código de esa dirección (utilizando el modo de bifurcación DAO) de un estado vacío a la implementación correspondiente de RISC-V. Debido a la alta simplicidad de la arquitectura RISC-V, incluso al completar solo este paso, la complejidad general del sistema seguirá disminuyendo.
Despliegue del intérprete EVM en la cadena: Implementación del intérprete EVM basado en RISC-V (la cadena de herramientas de prueba ZK ha impulsado este tipo de desarrollo) y su despliegue como contrato inteligente en la cadena. Años después del lanzamiento de la versión inicial, los contratos EVM existentes se ejecutarán a través de este intérprete, completando así la transición fluida a la nueva máquina virtual.
Implementar simplificaciones a través de componentes de protocolo compartido
Después de completar el paso cuatro, muchas "soluciones de implementación de EVM" seguirán existiendo y se utilizarán para optimizar la construcción de bloques, herramientas para desarrolladores y análisis de datos en la cadena, entre otros escenarios, pero estas implementaciones ya no formarán parte de la norma de consenso central. En ese momento, el mecanismo de consenso de Ethereum solo soportará de manera "nativa" la arquitectura RISC-V.
Implementar simplificaciones a través de componentes de protocolo compartido
La tercera forma de reducir la complejidad general del protocolo (también la más subestimada) es compartir estándares unificados entre diferentes niveles de la pila de protocolos en la medida de lo posible. En términos generales, no es necesario ni beneficioso implementar la misma funcionalidad con diferentes protocolos en diferentes módulos, pero este patrón de diseño sigue existiendo comúnmente, principalmente debido a la falta de una colaboración efectiva entre las diferentes partes de la hoja de ruta del protocolo. A continuación se presentan ejemplos concretos de cómo se puede simplificar Ethereum fortaleciendo la reutilización de componentes a través de capas.
Esquema unificado de código de borrado compartido
Tres tipos de escenarios de aplicación de códigos de corrección de borrado:
Muestreo de disponibilidad de datos: el cliente debe utilizar códigos de corrección de errores al verificar si el bloque ha sido publicado, para asegurar la integridad de los datos.
Difusión P2P eficiente: los nodos pueden confirmar el bloque al recibir n/2 de los n fragmentos, logrando un equilibrio óptimo entre la reducción de la latencia y la redundancia.
Almacenamiento histórico distribuido: los datos históricos de Ethereum se dividen en múltiples bloques de datos, cumpliendo con:
Cada bloque de datos se puede verificar de forma independiente.
Cualquiera de los grupos puede recuperar los n/2 bloques de datos restantes.
Este diseño reduce significativamente el riesgo de pérdida de datos en un solo punto.
Si se utiliza el mismo código de corrección de errores (como el código de Reed-Solomon, código lineal aleatorio, etc.) en los siguientes tres escenarios, se obtendrán ventajas significativas:
Código simplificado;
Mejora de la eficiencia: cuando un nodo necesita descargar datos de fragmentos (en lugar de un bloque completo) debido a un escenario específico, esos datos se pueden utilizar directamente en otros escenarios, evitando la transmisión redundante;
Todos los bloques de datos en todos los escenarios se pueden verificar de manera uniforme a través del hash raíz.
Si se utilizan diferentes códigos de corrección de errores, se deben cumplir los requisitos de compatibilidad: por ejemplo, en las particiones de muestreo de disponibilidad de datos (DAS), se pueden utilizar simultáneamente códigos de Reed-Solomon horizontales y códigos lineales aleatorios verticales, pero ambos códigos deben operar sobre el mismo campo finito.
Formato de serialización unificado
El formato de serialización actual de Ethereum aún se encuentra en un estado semi-normalizado: los datos se pueden re-serializar en cualquier formato y propagarse, siendo la única excepción el hash de la firma de la transacción, que debe adoptar un formato normalizado para garantizar la consistencia del hash. Sin embargo, en el futuro, el grado de normalización del formato de serialización se reforzará aún más, y las principales razones incluyen:
Abstractización de cuentas (EIP-7701): el contenido completo de la transacción será completamente visible para la máquina virtual (VM)
Escenarios de límite de Gas alto: a medida que aumenta el límite de Gas del bloque, los datos de la capa de ejecución deben almacenarse en una estructura de blob.
Cuando se produzca la transformación anterior, podremos aprovechar esta oportunidad para unificar los estándares de serialización de los tres niveles clave de Ethereum: (i) capa de ejecución (ii) capa de consenso (iii) llamada ABI de contrato inteligente
Se sugiere adoptar el formato de serialización SSZ, que tiene las siguientes ventajas:
Decodificación eficiente, los escenarios que incluyen contratos inteligentes se pueden decodificar rápidamente, gracias a su diseño basado en 4 bytes y un manejo reducido de condiciones de frontera.
La capa de consenso se aplica ampliamente y ya ha logrado una profunda integración en la capa de consenso.
Es muy similar al ABI existente, lo que facilita la adaptación y actualización de la cadena de herramientas.
Actualmente, hay equipos técnicos relacionados que están promoviendo el trabajo de migración integral de SSZ. Se sugiere continuar esta ruta técnica en las futuras planificaciones de actualización y expandirse sobre los logros existentes.
estructura de árbol compartido unificada
Cuando se migra de EVM a RISC-V (o a otra arquitectura de máquina virtual simplificada), el árbol Merkle Patricia de seis ramas se convertirá en el mayor cuello de botella en la ejecución de pruebas de bloques (incluso en escenarios normales). Cambiar a una estructura de árbol binario basada en funciones hash más eficientes mejorará significativamente la eficiencia de la prueba y reducirá los costos de almacenamiento de datos para nodos ligeros y otros escenarios de aplicación.
Al implementar esta migración, se debe adoptar de manera sincrónica la misma estructura de árbol para lograr la unificación de la capa de consenso y la capa de ejecución. Esta medida garantiza que toda la pila de Ethereum (incluyendo la capa de consenso y la capa de ejecución) utilice el mismo conjunto de lógica de código para el acceso y análisis de datos.
La trayectoria de evolución desde el estado actual hasta el objetivo
La simplicidad tiene similitudes en muchos aspectos con la descentralización, siendo ambas condiciones fundamentales para lograr la resiliencia del sistema. Definir la simplicidad como un valor central requiere un cambio a nivel cultural: sus beneficios a menudo son difíciles de mostrar de inmediato, mientras que las ganancias a corto plazo que ofrece la búsqueda de funciones complejas son evidentes. Sin embargo, a medida que pasa el tiempo, las ventajas de la simplicidad se volverán cada vez más destacadas: la historia del desarrollo de Bitcoin es una poderosa confirmación de este punto de vista.
Propongo que el diseño del protocolo Ethereum se refiera a la experiencia práctica del proyecto TinyGrad, establezca un límite superior claro para el número de líneas de código para la especificación a largo plazo de Ethereum y se esfuerce por hacer que la simplicidad del código clave del consenso de Ethereum se acerque al nivel de Bitcoin. En concreto, el código que procesa las reglas históricas de Ethereum puede seguir conservándose, pero debe estar estrictamente aislado de la ruta crítica del consenso para garantizar que no afecte a la lógica central del consenso. Al mismo tiempo, el concepto de diseño de "dar prioridad a las soluciones más simples" debe implementarse en la selección de soluciones técnicas, dando prioridad a la complejidad del paquete en lugar de difuminar la complejidad sistémica, y asegurando que todas las decisiones de diseño puedan proporcionar características y garantías claras y verificables, a fin de formar una cultura técnica orientada a la concisión en su conjunto.