Ethereum aims to become a global ledger, requiring scalability and resilience. This article focuses on the importance of protocol simplicity, proposing a significant reduction in complexity through the simplification of the consensus layer (3-slot finality, STARK aggregation) and the execution layer (replacing EVM with RISC-V or similar virtual machines), thus reducing development costs, error risks, and attack surfaces. It is suggested to facilitate a smooth transition through backward compatibility strategies (such as on-chain EVM interpreters) and to unify erasure codes, serialization formats (SSZ), and tree structures to further simplify. The goal is to bring Ethereum's consensus core code closer to Bitcoin's simplicity, enhancing resilience and participation, while culturally emphasizing simplicity and setting a maximum line of code target.
El objetivo de Ethereum es convertirse en un libro de contabilidad global: una plataforma para almacenar los activos y registros de la civilización humana, que sirve a los campos de finanzas, gobernanza, certificación de datos de alto valor, entre otros. Esto requiere apoyo en dos aspectos: escalabilidad y resiliencia. El plan de bifurcación dura Fusaka aumentará el espacio utilizable de datos L2 en 10 veces, mientras que la hoja de ruta propuesta para 2026 también planea traer aumentos similares para la capa L1. Al mismo tiempo, Ethereum ha completado su transición a prueba de participación (PoS), la diversidad de clientes está aumentando rápidamente, la verificación de conocimiento cero (ZK) y la investigación de resistencia cuántica también avanzan de manera constante, y el ecosistema de aplicaciones se vuelve cada vez más robusto.
Este artículo tiene como objetivo centrarse en un elemento de resiliencia (e incluso escalabilidad) que también es importante pero a menudo se subestima: la simplicidad del protocolo.
Lo más impresionante del protocolo de Bitcoin es su elegante simplicidad:
Existe una cadena compuesta de bloques, donde cada bloque está vinculado al bloque anterior mediante un hash.
La validez del bloque se verifica mediante prueba de trabajo (PoW), es decir, comprobando si los primeros dígitos del valor hash son ceros.
Cada bloque contiene transacciones, los fondos gastados en las transacciones provienen ya sea de recompensas por minería o de salidas de transacciones anteriores.
¡Eso es todo! Incluso un estudiante de secundaria inteligente puede entender completamente cómo funciona el protocolo de Bitcoin, y un programador incluso podría escribir un cliente como un proyecto aficionado.
La simplicidad del protocolo ha traído muchas ventajas clave que han permitido que Bitcoin (así como Ethereum) se convierta en una capa base global confiable y neutral:
1. Fácil de entender: Reducir la complejidad del protocolo para que más personas puedan participar en la investigación, desarrollo y gobernanza del protocolo, disminuyendo el riesgo de un dominio de la élite técnica.
2. Reducir los costos de desarrollo: Simplificar el protocolo reduce significativamente el costo de crear nueva infraestructura (como nuevos clientes, probadores, herramientas para desarrolladores, etc.).
3. Reducir la carga de mantenimiento: disminuir el costo del mantenimiento de acuerdos a largo plazo.
4. Reducir el riesgo de errores: Disminuir la posibilidad de errores catastróficos en las especificaciones y en la implementación del protocolo, al mismo tiempo que facilita la verificación de la inexistencia de tales errores.
5. Reducir la superficie de ataque: Disminuir los componentes complejos del protocolo para reducir el riesgo de ser atacado por grupos de interés específicos.
Históricamente, Ethereum (a veces debido a mis decisiones personales) a menudo no ha logrado mantenerse simple, lo que ha llevado a costos de desarrollo excesivos, un aumento de los riesgos de seguridad y una cultura de investigación y desarrollo cerrada, mientras que los beneficios de esta búsqueda de complejidad a menudo han demostrado ser ilusorios. Este artículo explorará cómo Ethereum, cinco años después, se acerca a la simplicidad de Bitcoin.
Capa de consenso simplificada
El nuevo diseño de la capa de consenso (históricamente conocido como "cadena de balizas") tiene como objetivo aprovechar la experiencia de la última década en teoría de consenso, desarrollo de ZK-SNARK, economía de participación, entre otros, para construir una capa de consenso a largo plazo que sea óptima y más simple. En comparación con la cadena de balizas existente, el nuevo diseño simplifica significativamente:
1. Diseño de finalización de 3 ranuras: eliminación de conceptos como ranuras (slot), ciclos (epoch) y reorganización de comités, así como mecanismos de procesamiento eficientes relacionados (como comités de sincronización). La implementación básica de la finalización de 3 ranuras solo requiere alrededor de 200 líneas de código y, en comparación con Gasper, la seguridad es casi óptima.
2. Reducir el número de validadores activos: Permitir la implementación de reglas de selección de bifurcación más simples para mejorar la seguridad.
3. Protocolo de agregación basado en STARK: Cualquiera puede convertirse en agregador sin necesidad de confiar en el agregador o pagar altos costos por el dominio duplicado. La complejidad de la criptografía de agregación es alta, pero su complejidad está altamente encapsulada, lo que reduce el riesgo sistémico.
4. Simplificación de la arquitectura P2P: Los factores mencionados pueden apoyar una arquitectura de red punto a punto más simple y robusta.
5. Rediseñar el mecanismo de validadores: incluye mecanismos de entrada, salida, retiro, intercambio de claves, fuga de inactividad, etc., simplificando el número de líneas de código y proporcionando garantías más claras (como el período de debilidad subjetiva).
La ventaja de la capa de consenso radica en su relativa independencia de la capa de ejecución EVM, lo que permite un mayor espacio para mejoras continuas. El mayor desafío radica en cómo lograr una simplificación similar en la capa de ejecución.
Capa de ejecución simplificada
La complejidad de EVM está aumentando, y muchas de estas complejidades se han demostrado innecesarias (en parte debido a errores de decisión personales míos): la máquina virtual de 256 bits ha optimizado en exceso formas criptográficas específicas que hoy en día están gradualmente quedando obsoletas, y las precompilaciones han sido optimizadas para un único caso de uso pero rara vez se utilizan.
Abordar estos problemas uno por uno tiene un efecto limitado. Por ejemplo, eliminar el código de operación SELFDESTRUCT requiere un gran esfuerzo, pero solo produce beneficios pequeños. Las recientes controversias sobre EOF (EVM Object Format) también muestran desafíos similares.
Recientemente propuse un enfoque más radical: en lugar de realizar cambios a mediana escala (pero aún destructivos) en el EVM a cambio de un rendimiento de 1.5 veces, sería mejor hacer la transición a una máquina virtual más óptima y simple para lograr un rendimiento de 100 veces. Similar a la "fusión" (The Merge), reducimos la cantidad de cambios destructivos, pero hacemos que cada cambio sea más significativo. En concreto, sugiero reemplazar el EVM por RISC-V, o por otra máquina virtual utilizada por el probador ZK de Ethereum. Esto traería:
1. Aumento significativo de la eficiencia: La ejecución de contratos inteligentes (en el probador) no requiere el costo de un intérprete, se ejecuta directamente. Los datos de Succinct muestran que en muchos escenarios el rendimiento puede mejorar más de 100 veces.
2. Simplicidad drásticamente mejorada: La especificación RISC-V es extremadamente simple en comparación con la EVM, y alternativas como Cairo son igualmente simples.
3. Motivaciones para soportar EOF: como partición de código, análisis estático más amigable, mayores límites de tamaño de código, etc.
4. Más opciones para desarrolladores: Solidity y Vyper pueden añadir un backend para compilar a una nueva máquina virtual. Si se elige RISC-V, los desarrolladores de lenguajes de programación populares también podrán portar fácilmente el código a esa máquina virtual.
5. Eliminar la mayoría de las precompilaciones: Es posible que solo se mantengan las operaciones de curva elíptica altamente optimizadas (incluso estas desaparecerán con la proliferación de las computadoras cuánticas).
La principal desventaja es que, a diferencia de un EOF listo, los beneficios de la nueva máquina virtual tardarán más en llegar a los desarrolladores. Podemos mitigar este problema implementando a corto plazo mejoras de alto valor en EVM (como aumentar el límite de tamaño del código de contrato, soportar DUP/SWAP17–32).
Esto llevará a una máquina virtual más simple. El desafío principal es: ¿cómo manejar el EVM existente?
Estrategia de compatibilidad hacia atrás para la transición de máquinas virtuales
El mayor desafío para simplificar (o mejorar sin aumentar la complejidad) EVM radica en cómo equilibrar la consecución de objetivos con la compatibilidad hacia atrás de las aplicaciones existentes.
Primero es necesario aclarar: la base de código de Ethereum (incluso dentro de un único cliente) no tiene solo una forma de definición.
El objetivo es reducir al máximo la zona verde: la lógica necesaria para que los nodos participen en el consenso de Ethereum, que incluye calcular el estado actual, pruebas, verificaciones, FOCIL (reglas de selección de bifurcaciones) y la construcción de bloques "normales".
La zona naranja no se puede reducir: si la especificación del protocolo elimina o modifica alguna función de la capa de ejecución (como máquina virtual, precompilaciones, etc.), el cliente que maneja bloques históricos aún debe conservar el código relevante. Sin embargo, nuevos clientes, ZK-EVM o probadores formales pueden ignorar completamente la zona naranja.
Nueva zona amarilla: es muy valiosa para entender la cadena actual o optimizar la construcción de bloques, pero no forma parte de la lógica de consenso. Por ejemplo, Etherscan y algunos constructores de bloques apoyan las operaciones de usuarios ERC-4337. Si reemplazamos ciertas funciones de Ethereum (como EOA y sus tipos de transacciones antiguos) con una implementación en cadena de RISC-V, el código de consenso se simplificará significativamente, pero los nodos dedicados pueden continuar utilizando el código original para el análisis.
La complejidad de las áreas naranja y amarilla es complejidad de encapsulación, las personas que entienden el protocolo pueden omitir estas partes, Ethereum puede ignorarlas, y los errores en estas áreas no provocarán riesgos de consenso. Por lo tanto, la complejidad del código en las áreas naranja y amarilla es mucho menos perjudicial que la complejidad en el área verde.
La idea de mover el código de la zona verde a la zona amarilla es similar a la estrategia de Apple de garantizar la compatibilidad a largo plazo a través de la capa de traducción Rosetta.
Inspirado por el reciente artículo del equipo de Ipsilon, propongo el siguiente proceso de cambio de máquina virtual (tomando como ejemplo de EVM a RISC-V, pero también aplicable de EVM a Cairo o de RISC-V a una máquina virtual mejor).
1. Requerir que la nueva precompilación proporcione una implementación de RISC-V en la cadena: permitir que el ecosistema se adapte gradualmente a la máquina virtual RISC-V.
2. Introducir RISC-V como opción para desarrolladores: El protocolo admite tanto RISC-V como EVM, y los contratos de ambas máquinas virtuales pueden interactuar libremente.
3. Reemplazar la mayoría de las precompilaciones: Con excepción de las operaciones de curvas elípticas y KECCAK (debido a la necesidad de velocidad extrema), se implementa el reemplazo de otras precompilaciones con RISC-V. A través de un hard fork, se eliminan las precompilaciones, mientras que el código de esa dirección (similar al fork de DAO) se cambia de vacío a una implementación de RISC-V. La máquina virtual RISC-V es extremadamente simple, incluso detenerse aquí simplifica significativamente el protocolo.
4. Implementación del intérprete EVM en RISC-V: Como contratos inteligentes en la cadena (debido a que el probador ZK necesita estar en funcionamiento). Años después de la publicación inicial, los contratos EVM existentes se ejecutan a través de este intérprete.
Después de completar el paso 4, muchas "implementaciones de EVM" seguirán utilizándose para optimizar la construcción de bloques, herramientas para desarrolladores y análisis de cadenas, pero ya no serán parte de las especificaciones clave de consenso. El consenso de Ethereum solo entenderá RISC-V "de manera nativa".
Simplificación a través de componentes de protocolo compartido
Una tercera forma de reducir la complejidad total del protocolo (también la más fácil de subestimar) es compartir estándares unificados en las diferentes partes de la pila del protocolo tanto como sea posible. Diferentes protocolos que hacen lo mismo en diferentes escenarios a menudo no son útiles, pero este patrón sigue apareciendo, principalmente porque las diferentes partes de la hoja de ruta del protocolo carecen de comunicación. A continuación, se presentan algunos ejemplos concretos de cómo simplificar Ethereum compartiendo componentes.
Código de borrado unificado
Necesitamos códigos de borrado en tres escenarios:
1. Muestreo de disponibilidad de datos: El cliente verifica que el bloque ha sido publicado.
2. Transmisión P2P más rápida: los nodos pueden aceptar bloques después de recibir n/2 fragmentos, logrando un equilibrio entre latencia y redundancia.
3. Almacenamiento histórico distribuido: Los datos históricos de Ethereum se almacenan en fragmentos, donde cada grupo de n/2 fragmentos puede recuperar los fragmentos restantes, reduciendo el riesgo de pérdida de un único fragmento.
Si se utiliza el mismo código de corrección de errores (ya sea Reed-Solomon, código lineal aleatorio, etc.) en tres escenarios diferentes, se obtendrán las siguientes ventajas:
1. Minimizar la cantidad de código: Reducir el número total de líneas de código.
2. Aumentar la eficiencia: Si un nodo descarga fragmentos de datos de un escenario, estos datos se pueden utilizar para otros escenarios.
3. Asegurar la verificabilidad: Todos los fragmentos de los escenarios se pueden verificar según la raíz.
Si se utilizan diferentes códigos de corrección de errores, al menos se debe asegurar la compatibilidad, por ejemplo, los códigos Reed-Solomon de muestreo de disponibilidad de datos en nivel y los códigos lineales aleatorios verticales operan en el mismo dominio.
Formato de serialización unificado
El formato de serialización de Ethereum actualmente está parcialmente solidificado, ya que los datos se pueden re-serializar y transmitir en cualquier formato. La excepción son los hashes de firma de transacción, que deben ser hash en un formato estandarizado. En el futuro, el grado de solidificación del formato de serialización se incrementará por las siguientes razones:
1. Abstracción de cuenta completa (EIP-7701): El contenido completo de la transacción es visible para la máquina virtual.
2. Límite de Gas más alto: Los datos de la capa de ejecución deben colocarse en bloques de datos (blobs).
En ese momento, tendremos la oportunidad de unificar los formatos de serialización de los tres niveles de Ethereum: capa de ejecución, capa de consenso y ABI de llamada a contratos inteligentes.
Propongo usar SSZ, porque SSZ:
Fácil de decodificar: incluye dentro del contrato inteligente (debido a su diseño basado en 4 bytes y menos casos extremos).
Se ha utilizado ampliamente en la capa de consenso.
Muy similar al ABI existente: la adaptación de la herramienta es relativamente simple.
Ya hay esfuerzos para la migración completa a SSZ, debemos considerar y continuar estos esfuerzos al planificar futuras actualizaciones.
Estructura de árbol unificada
Si se migra de EVM a RISC-V (u otra máquina virtual mínima opcional), el árbol Merkle Patricia en hexadecimal se convertirá en el mayor cuello de botella para probar la ejecución de bloques, incluso en el caso promedio. Migrar a un árbol binario basado en una mejor función hash mejorará significativamente la eficiencia del probador, al tiempo que reducirá los costos de datos en escenarios como los clientes ligeros.
Al migrar, se debe asegurar que la capa de consenso utilice la misma estructura de árbol. Esto permitirá que la capa de consenso de Ethereum y la capa de ejecución se accedan y se analicen a través del mismo código.
Del ahora al futuro
La simplicidad es similar a la descentralización en muchos aspectos, ambos son objetivos resilientes upstream. Valorar la simplicidad requiere un cambio cultural significativo. Sus beneficios a menudo son difíciles de cuantificar, mientras que el costo de hacer un esfuerzo adicional y renunciar a ciertas funciones llamativas es inmediato. Sin embargo, con el tiempo, los beneficios se volverán más evidentes — Bitcoin en sí mismo es un excelente ejemplo.
Propongo seguir el ejemplo de tinygrad y establecer un objetivo claro de número máximo de líneas de código para las normas a largo plazo de Ethereum, de modo que el código clave del consenso de Ethereum se asemeje a la simplicidad de Bitcoin. El código que maneja las reglas históricas de Ethereum seguirá existiendo, pero debe estar fuera del camino clave del consenso. Al mismo tiempo, debemos mantener la idea de elegir soluciones más simples, priorizando la encapsulación de la complejidad en lugar de la complejidad sistémica, y tomar decisiones de diseño que ofrezcan atributos y garantías claras.
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 Buterin: Cómo hacer que Ethereum en 5 años sea tan simple como Bitcoin
Resumen
Ethereum aims to become a global ledger, requiring scalability and resilience. This article focuses on the importance of protocol simplicity, proposing a significant reduction in complexity through the simplification of the consensus layer (3-slot finality, STARK aggregation) and the execution layer (replacing EVM with RISC-V or similar virtual machines), thus reducing development costs, error risks, and attack surfaces. It is suggested to facilitate a smooth transition through backward compatibility strategies (such as on-chain EVM interpreters) and to unify erasure codes, serialization formats (SSZ), and tree structures to further simplify. The goal is to bring Ethereum's consensus core code closer to Bitcoin's simplicity, enhancing resilience and participation, while culturally emphasizing simplicity and setting a maximum line of code target.
El objetivo de Ethereum es convertirse en un libro de contabilidad global: una plataforma para almacenar los activos y registros de la civilización humana, que sirve a los campos de finanzas, gobernanza, certificación de datos de alto valor, entre otros. Esto requiere apoyo en dos aspectos: escalabilidad y resiliencia. El plan de bifurcación dura Fusaka aumentará el espacio utilizable de datos L2 en 10 veces, mientras que la hoja de ruta propuesta para 2026 también planea traer aumentos similares para la capa L1. Al mismo tiempo, Ethereum ha completado su transición a prueba de participación (PoS), la diversidad de clientes está aumentando rápidamente, la verificación de conocimiento cero (ZK) y la investigación de resistencia cuántica también avanzan de manera constante, y el ecosistema de aplicaciones se vuelve cada vez más robusto.
Este artículo tiene como objetivo centrarse en un elemento de resiliencia (e incluso escalabilidad) que también es importante pero a menudo se subestima: la simplicidad del protocolo.
Lo más impresionante del protocolo de Bitcoin es su elegante simplicidad:
Existe una cadena compuesta de bloques, donde cada bloque está vinculado al bloque anterior mediante un hash.
La validez del bloque se verifica mediante prueba de trabajo (PoW), es decir, comprobando si los primeros dígitos del valor hash son ceros.
Cada bloque contiene transacciones, los fondos gastados en las transacciones provienen ya sea de recompensas por minería o de salidas de transacciones anteriores.
¡Eso es todo! Incluso un estudiante de secundaria inteligente puede entender completamente cómo funciona el protocolo de Bitcoin, y un programador incluso podría escribir un cliente como un proyecto aficionado.
La simplicidad del protocolo ha traído muchas ventajas clave que han permitido que Bitcoin (así como Ethereum) se convierta en una capa base global confiable y neutral:
1. Fácil de entender: Reducir la complejidad del protocolo para que más personas puedan participar en la investigación, desarrollo y gobernanza del protocolo, disminuyendo el riesgo de un dominio de la élite técnica.
2. Reducir los costos de desarrollo: Simplificar el protocolo reduce significativamente el costo de crear nueva infraestructura (como nuevos clientes, probadores, herramientas para desarrolladores, etc.).
3. Reducir la carga de mantenimiento: disminuir el costo del mantenimiento de acuerdos a largo plazo.
4. Reducir el riesgo de errores: Disminuir la posibilidad de errores catastróficos en las especificaciones y en la implementación del protocolo, al mismo tiempo que facilita la verificación de la inexistencia de tales errores.
5. Reducir la superficie de ataque: Disminuir los componentes complejos del protocolo para reducir el riesgo de ser atacado por grupos de interés específicos.
Históricamente, Ethereum (a veces debido a mis decisiones personales) a menudo no ha logrado mantenerse simple, lo que ha llevado a costos de desarrollo excesivos, un aumento de los riesgos de seguridad y una cultura de investigación y desarrollo cerrada, mientras que los beneficios de esta búsqueda de complejidad a menudo han demostrado ser ilusorios. Este artículo explorará cómo Ethereum, cinco años después, se acerca a la simplicidad de Bitcoin.
Capa de consenso simplificada
El nuevo diseño de la capa de consenso (históricamente conocido como "cadena de balizas") tiene como objetivo aprovechar la experiencia de la última década en teoría de consenso, desarrollo de ZK-SNARK, economía de participación, entre otros, para construir una capa de consenso a largo plazo que sea óptima y más simple. En comparación con la cadena de balizas existente, el nuevo diseño simplifica significativamente:
1. Diseño de finalización de 3 ranuras: eliminación de conceptos como ranuras (slot), ciclos (epoch) y reorganización de comités, así como mecanismos de procesamiento eficientes relacionados (como comités de sincronización). La implementación básica de la finalización de 3 ranuras solo requiere alrededor de 200 líneas de código y, en comparación con Gasper, la seguridad es casi óptima.
2. Reducir el número de validadores activos: Permitir la implementación de reglas de selección de bifurcación más simples para mejorar la seguridad.
3. Protocolo de agregación basado en STARK: Cualquiera puede convertirse en agregador sin necesidad de confiar en el agregador o pagar altos costos por el dominio duplicado. La complejidad de la criptografía de agregación es alta, pero su complejidad está altamente encapsulada, lo que reduce el riesgo sistémico.
4. Simplificación de la arquitectura P2P: Los factores mencionados pueden apoyar una arquitectura de red punto a punto más simple y robusta.
5. Rediseñar el mecanismo de validadores: incluye mecanismos de entrada, salida, retiro, intercambio de claves, fuga de inactividad, etc., simplificando el número de líneas de código y proporcionando garantías más claras (como el período de debilidad subjetiva).
La ventaja de la capa de consenso radica en su relativa independencia de la capa de ejecución EVM, lo que permite un mayor espacio para mejoras continuas. El mayor desafío radica en cómo lograr una simplificación similar en la capa de ejecución.
Capa de ejecución simplificada
La complejidad de EVM está aumentando, y muchas de estas complejidades se han demostrado innecesarias (en parte debido a errores de decisión personales míos): la máquina virtual de 256 bits ha optimizado en exceso formas criptográficas específicas que hoy en día están gradualmente quedando obsoletas, y las precompilaciones han sido optimizadas para un único caso de uso pero rara vez se utilizan.
Abordar estos problemas uno por uno tiene un efecto limitado. Por ejemplo, eliminar el código de operación SELFDESTRUCT requiere un gran esfuerzo, pero solo produce beneficios pequeños. Las recientes controversias sobre EOF (EVM Object Format) también muestran desafíos similares.
Recientemente propuse un enfoque más radical: en lugar de realizar cambios a mediana escala (pero aún destructivos) en el EVM a cambio de un rendimiento de 1.5 veces, sería mejor hacer la transición a una máquina virtual más óptima y simple para lograr un rendimiento de 100 veces. Similar a la "fusión" (The Merge), reducimos la cantidad de cambios destructivos, pero hacemos que cada cambio sea más significativo. En concreto, sugiero reemplazar el EVM por RISC-V, o por otra máquina virtual utilizada por el probador ZK de Ethereum. Esto traería:
1. Aumento significativo de la eficiencia: La ejecución de contratos inteligentes (en el probador) no requiere el costo de un intérprete, se ejecuta directamente. Los datos de Succinct muestran que en muchos escenarios el rendimiento puede mejorar más de 100 veces.
2. Simplicidad drásticamente mejorada: La especificación RISC-V es extremadamente simple en comparación con la EVM, y alternativas como Cairo son igualmente simples.
3. Motivaciones para soportar EOF: como partición de código, análisis estático más amigable, mayores límites de tamaño de código, etc.
4. Más opciones para desarrolladores: Solidity y Vyper pueden añadir un backend para compilar a una nueva máquina virtual. Si se elige RISC-V, los desarrolladores de lenguajes de programación populares también podrán portar fácilmente el código a esa máquina virtual.
5. Eliminar la mayoría de las precompilaciones: Es posible que solo se mantengan las operaciones de curva elíptica altamente optimizadas (incluso estas desaparecerán con la proliferación de las computadoras cuánticas).
La principal desventaja es que, a diferencia de un EOF listo, los beneficios de la nueva máquina virtual tardarán más en llegar a los desarrolladores. Podemos mitigar este problema implementando a corto plazo mejoras de alto valor en EVM (como aumentar el límite de tamaño del código de contrato, soportar DUP/SWAP17–32).
Esto llevará a una máquina virtual más simple. El desafío principal es: ¿cómo manejar el EVM existente?
Estrategia de compatibilidad hacia atrás para la transición de máquinas virtuales
El mayor desafío para simplificar (o mejorar sin aumentar la complejidad) EVM radica en cómo equilibrar la consecución de objetivos con la compatibilidad hacia atrás de las aplicaciones existentes.
Primero es necesario aclarar: la base de código de Ethereum (incluso dentro de un único cliente) no tiene solo una forma de definición.
El objetivo es reducir al máximo la zona verde: la lógica necesaria para que los nodos participen en el consenso de Ethereum, que incluye calcular el estado actual, pruebas, verificaciones, FOCIL (reglas de selección de bifurcaciones) y la construcción de bloques "normales".
La zona naranja no se puede reducir: si la especificación del protocolo elimina o modifica alguna función de la capa de ejecución (como máquina virtual, precompilaciones, etc.), el cliente que maneja bloques históricos aún debe conservar el código relevante. Sin embargo, nuevos clientes, ZK-EVM o probadores formales pueden ignorar completamente la zona naranja.
Nueva zona amarilla: es muy valiosa para entender la cadena actual o optimizar la construcción de bloques, pero no forma parte de la lógica de consenso. Por ejemplo, Etherscan y algunos constructores de bloques apoyan las operaciones de usuarios ERC-4337. Si reemplazamos ciertas funciones de Ethereum (como EOA y sus tipos de transacciones antiguos) con una implementación en cadena de RISC-V, el código de consenso se simplificará significativamente, pero los nodos dedicados pueden continuar utilizando el código original para el análisis.
La complejidad de las áreas naranja y amarilla es complejidad de encapsulación, las personas que entienden el protocolo pueden omitir estas partes, Ethereum puede ignorarlas, y los errores en estas áreas no provocarán riesgos de consenso. Por lo tanto, la complejidad del código en las áreas naranja y amarilla es mucho menos perjudicial que la complejidad en el área verde.
La idea de mover el código de la zona verde a la zona amarilla es similar a la estrategia de Apple de garantizar la compatibilidad a largo plazo a través de la capa de traducción Rosetta.
Inspirado por el reciente artículo del equipo de Ipsilon, propongo el siguiente proceso de cambio de máquina virtual (tomando como ejemplo de EVM a RISC-V, pero también aplicable de EVM a Cairo o de RISC-V a una máquina virtual mejor).
1. Requerir que la nueva precompilación proporcione una implementación de RISC-V en la cadena: permitir que el ecosistema se adapte gradualmente a la máquina virtual RISC-V.
2. Introducir RISC-V como opción para desarrolladores: El protocolo admite tanto RISC-V como EVM, y los contratos de ambas máquinas virtuales pueden interactuar libremente.
3. Reemplazar la mayoría de las precompilaciones: Con excepción de las operaciones de curvas elípticas y KECCAK (debido a la necesidad de velocidad extrema), se implementa el reemplazo de otras precompilaciones con RISC-V. A través de un hard fork, se eliminan las precompilaciones, mientras que el código de esa dirección (similar al fork de DAO) se cambia de vacío a una implementación de RISC-V. La máquina virtual RISC-V es extremadamente simple, incluso detenerse aquí simplifica significativamente el protocolo.
4. Implementación del intérprete EVM en RISC-V: Como contratos inteligentes en la cadena (debido a que el probador ZK necesita estar en funcionamiento). Años después de la publicación inicial, los contratos EVM existentes se ejecutan a través de este intérprete.
Después de completar el paso 4, muchas "implementaciones de EVM" seguirán utilizándose para optimizar la construcción de bloques, herramientas para desarrolladores y análisis de cadenas, pero ya no serán parte de las especificaciones clave de consenso. El consenso de Ethereum solo entenderá RISC-V "de manera nativa".
Simplificación a través de componentes de protocolo compartido
Una tercera forma de reducir la complejidad total del protocolo (también la más fácil de subestimar) es compartir estándares unificados en las diferentes partes de la pila del protocolo tanto como sea posible. Diferentes protocolos que hacen lo mismo en diferentes escenarios a menudo no son útiles, pero este patrón sigue apareciendo, principalmente porque las diferentes partes de la hoja de ruta del protocolo carecen de comunicación. A continuación, se presentan algunos ejemplos concretos de cómo simplificar Ethereum compartiendo componentes.
Código de borrado unificado
Necesitamos códigos de borrado en tres escenarios:
1. Muestreo de disponibilidad de datos: El cliente verifica que el bloque ha sido publicado.
2. Transmisión P2P más rápida: los nodos pueden aceptar bloques después de recibir n/2 fragmentos, logrando un equilibrio entre latencia y redundancia.
3. Almacenamiento histórico distribuido: Los datos históricos de Ethereum se almacenan en fragmentos, donde cada grupo de n/2 fragmentos puede recuperar los fragmentos restantes, reduciendo el riesgo de pérdida de un único fragmento.
Si se utiliza el mismo código de corrección de errores (ya sea Reed-Solomon, código lineal aleatorio, etc.) en tres escenarios diferentes, se obtendrán las siguientes ventajas:
1. Minimizar la cantidad de código: Reducir el número total de líneas de código.
2. Aumentar la eficiencia: Si un nodo descarga fragmentos de datos de un escenario, estos datos se pueden utilizar para otros escenarios.
3. Asegurar la verificabilidad: Todos los fragmentos de los escenarios se pueden verificar según la raíz.
Si se utilizan diferentes códigos de corrección de errores, al menos se debe asegurar la compatibilidad, por ejemplo, los códigos Reed-Solomon de muestreo de disponibilidad de datos en nivel y los códigos lineales aleatorios verticales operan en el mismo dominio.
Formato de serialización unificado
El formato de serialización de Ethereum actualmente está parcialmente solidificado, ya que los datos se pueden re-serializar y transmitir en cualquier formato. La excepción son los hashes de firma de transacción, que deben ser hash en un formato estandarizado. En el futuro, el grado de solidificación del formato de serialización se incrementará por las siguientes razones:
1. Abstracción de cuenta completa (EIP-7701): El contenido completo de la transacción es visible para la máquina virtual.
2. Límite de Gas más alto: Los datos de la capa de ejecución deben colocarse en bloques de datos (blobs).
En ese momento, tendremos la oportunidad de unificar los formatos de serialización de los tres niveles de Ethereum: capa de ejecución, capa de consenso y ABI de llamada a contratos inteligentes.
Propongo usar SSZ, porque SSZ:
Fácil de decodificar: incluye dentro del contrato inteligente (debido a su diseño basado en 4 bytes y menos casos extremos).
Se ha utilizado ampliamente en la capa de consenso.
Muy similar al ABI existente: la adaptación de la herramienta es relativamente simple.
Ya hay esfuerzos para la migración completa a SSZ, debemos considerar y continuar estos esfuerzos al planificar futuras actualizaciones.
Estructura de árbol unificada
Si se migra de EVM a RISC-V (u otra máquina virtual mínima opcional), el árbol Merkle Patricia en hexadecimal se convertirá en el mayor cuello de botella para probar la ejecución de bloques, incluso en el caso promedio. Migrar a un árbol binario basado en una mejor función hash mejorará significativamente la eficiencia del probador, al tiempo que reducirá los costos de datos en escenarios como los clientes ligeros.
Al migrar, se debe asegurar que la capa de consenso utilice la misma estructura de árbol. Esto permitirá que la capa de consenso de Ethereum y la capa de ejecución se accedan y se analicen a través del mismo código.
Del ahora al futuro
La simplicidad es similar a la descentralización en muchos aspectos, ambos son objetivos resilientes upstream. Valorar la simplicidad requiere un cambio cultural significativo. Sus beneficios a menudo son difíciles de cuantificar, mientras que el costo de hacer un esfuerzo adicional y renunciar a ciertas funciones llamativas es inmediato. Sin embargo, con el tiempo, los beneficios se volverán más evidentes — Bitcoin en sí mismo es un excelente ejemplo.
Propongo seguir el ejemplo de tinygrad y establecer un objetivo claro de número máximo de líneas de código para las normas a largo plazo de Ethereum, de modo que el código clave del consenso de Ethereum se asemeje a la simplicidad de Bitcoin. El código que maneja las reglas históricas de Ethereum seguirá existiendo, pero debe estar fuera del camino clave del consenso. Al mismo tiempo, debemos mantener la idea de elegir soluciones más simples, priorizando la encapsulación de la complejidad en lugar de la complejidad sistémica, y tomar decisiones de diseño que ofrezcan atributos y garantías claras.