Ethereum aims to become a global ledger, requiring scalability and resilience. This article focuses on the importance of protocol simplicity, proposing to significantly reduce 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), thereby reducing development costs, error risks, and attack surfaces. It is recommended to smooth the transition through backward compatibility strategies (such as on-chain EVM interpreters) and unify erasure codes, serialization formats (SSZ), and tree structures to further simplify. The goal is to bring Ethereum's consensus critical code closer to Bitcoin's simplicity, enhancing resilience and participation, while culturally emphasizing simplicity and setting a maximum code line count 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, al servicio de campos como las finanzas, la gobernanza y la certificación de datos de alto valor. Esto requiere apoyo en dos áreas: escalabilidad y resistencia. El plan de bifurcación dura de Fusaka aumentará el espacio utilizable de los datos de L2 en 10 veces, mientras que la hoja de ruta propuesta para 2026 también planea traer un aumento similar para la capa L1. Mientras tanto, Ethereum ha completado la transición a la 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 están avanzando de manera constante, y el ecosistema de aplicaciones se vuelve cada vez más robusto.
Este artículo se centra en un elemento de resiliencia (e incluso escalabilidad) que es igualmente importante pero a menudo subestimado: la simplicidad del protocolo.
Lo más impresionante del protocolo de Bitcoin es su elegante simplicidad:
Existe una cadena formada por bloques, cada bloque está conectado al bloque anterior a través de un hash.
La validez del bloque se verifica mediante prueba de trabajo (PoW), es decir, comprobando si los primeros dígitos del hash son ceros.
Cada bloque contiene transacciones, las monedas gastadas en las transacciones provienen ya sea de recompensas de minería o de salidas de transacciones anteriores.
¡Eso es todo! Incluso un estudiante de secundaria inteligente puede entender completamente el funcionamiento del protocolo de Bitcoin, y un programador incluso puede escribir un cliente como un proyecto personal.
La simplicidad del protocolo aporta una serie de ventajas clave a Bitcoin (y Ethereum) como base global neutral y de confianza:
Fácil de entender: reducir la complejidad del protocolo, permitir que más personas participen en la investigación, el desarrollo y la gobernanza del protocolo, y reducir el riesgo de que una élite técnica domine.
Reducir los costos de desarrollo: Simplificar los protocolos reduce significativamente el costo de crear nueva infraestructura (como nuevos clientes, probadores, herramientas para desarrolladores, etc.).
Reducir la carga de mantenimiento: disminuir el costo del mantenimiento de acuerdos a largo plazo.
Reducir el riesgo de errores: disminuir la posibilidad de que ocurran errores catastróficos en las especificaciones y la implementación del protocolo, al mismo tiempo que facilita la verificación de que tales errores no existen.
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.
A lo largo de la historia, Ethereum (a veces debido a mis decisiones personales) a menudo no ha logrado mantener la simplicidad, lo que ha llevado a un aumento en los costos de desarrollo, mayores 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 acercará 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ías de consenso, desarrollo de ZK-SNARK, economía de staking, entre otros, para construir una capa de consenso a largo plazo que sea óptima y más sencilla. En comparación con la cadena de balizas existente, el nuevo diseño simplifica significativamente:
Diseño de finalización de 3 ranuras: eliminación de conceptos como ranura (slot), período (epoch), reconfiguración del comité, 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 requiere aproximadamente 200 líneas de código y, en comparación con Gasper, la seguridad es casi óptima.
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.
Protocolo de agregación basado en STARK: cualquier persona puede convertirse en agregador, sin necesidad de confiar en el agregador o pagar altos costos por el dominio de repetición. La complejidad de la criptografía de agregación es alta, pero su complejidad está altamente encapsulada, lo que reduce el riesgo sistémico.
Simplificación de la arquitectura P2P: Los factores mencionados anteriormente pueden respaldar una red punto a punto más simple y robusta.
Rediseñar el mecanismo de validadores: incluye mecanismos de entrada, salida, retiro, conversión de claves, fuga por inactividad, etc., simplificando el número de líneas de código y proporcionando garantías más claras (como el ciclo 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 es cómo lograr una simplificación similar en la capa de ejecución.
Capa de ejecución simplificada
La complejidad del EVM está aumentando cada vez más, y muchas de estas complejidades han demostrado ser innecesarias (en parte debido a errores de decisión personales míos): una máquina virtual de 256 bits ha optimizado en exceso formas criptográficas específicas que están quedando obsoletas, y las precompilaciones se han optimizado para un único caso de uso, pero rara vez se utilizan.
Resolver estos problemas uno por uno tiene un efecto limitado. Por ejemplo, eliminar el opcode SELFDESTRUCT requiere un gran esfuerzo, pero solo aporta beneficios menores. Las recientes discusiones sobre EOF (EVM Object Format) también muestran desafíos similares.
Recientemente propuse un enfoque más radical: en lugar de hacer cambios de tamaño mediano (pero aún destructivos) en el EVM a cambio de un 1.5 veces de rendimiento, sería mejor transitar a una máquina virtual más óptima y simple para lograr un 100 veces de rendimiento. Similar a la "fusión" (The Merge), reducimos el número de cambios destructivos, pero hacemos que cada cambio sea más significativo. En concreto, sugiero reemplazar el EVM por RISC-V, o alguna otra máquina virtual utilizada por el probador ZK de Ethereum. Esto traería:
Mejora significativa en 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.
Mejora significativa en la simplicidad: La especificación de RISC-V es extremadamente simple en comparación con EVM, y las alternativas (como Cairo) también son concisas.
Motivos para soportar EOF: como la partición de código, un análisis estático más amigable, mayores límites de tamaño de código, etc.
Más opciones para desarrolladores: Solidity y Vyper pueden añadir backend para compilar en una nueva máquina virtual. Si se elige RISC-V, los desarrolladores de lenguajes populares también pueden portar fácilmente el código a esa máquina virtual.
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 después de la popularización de las computadoras cuánticas).
La principal desventaja es que, a diferencia del EOF ya preparado, los beneficios de la nueva máquina virtual tardarán más tiempo en beneficiar a los desarrolladores. Podemos mitigar este problema implementando mejoras de EVM de alto valor a corto plazo (como aumentar el límite de tamaño del código de contrato y apoyar DUP/SWAP17–32).
Esto llevará a una máquina virtual más simple. El desafío central es: ¿cómo manejar el EVM existente?
Estrategia de compatibilidad hacia atrás de la transición de la máquina virtual
El mayor desafío para simplificar (o mejorar sin aumentar la complejidad) la EVM es cómo equilibrar la realizació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 una única forma de definición.
El objetivo es reducir al mínimo la zona verde: la lógica necesaria para que los nodos participen en el consenso de Ethereum, incluyendo el cálculo del estado actual, la prueba, la verificación, FOCIL (reglas de selección de bifurcación) y la construcción de bloques "normales".
La zona naranja no se puede reducir: si la especificación del protocolo elimina o cambia alguna función de la capa de ejecución (como la máquina virtual, precompilaciones, etc.), el cliente que procesa bloques históricos aún debe conservar el código relevante. Sin embargo, los nuevos clientes, ZK-EVM o probadores formales pueden ignorar por completo la zona naranja.
Área amarilla añadida: es muy valiosa para comprender la cadena actual o para 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 usuario ERC-4337. Si reemplazamos ciertas funciones de Ethereum (como EOA y sus tipos de transacciones antiguos) con una implementación RISC-V en la cadena, el código de consenso se simplificaría significativamente, pero los nodos dedicados podrían seguir utilizando el código original para el análisis.
La complejidad de las áreas naranja y amarilla es la complejidad de encapsulación; las personas que entienden el protocolo pueden omitir estas partes, y Ethereum puede ignorarlas. 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 dañina 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 hacia atrás 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 puede aplicarse de EVM a Cairo o de RISC-V a una máquina virtual superior):
Se requiere 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.
Introducir RISC-V como opción para desarrolladores: el protocolo admite tanto RISC-V como EVM, los contratos de ambas máquinas virtuales pueden interactuar libremente.
Reemplazo de la mayoría de las precompilaciones: excepto por las operaciones de curva elíptica y KECCAK (debido a la necesidad de velocidad extrema), se implementan las otras precompilaciones mediante RISC-V. Se elimina la precompilación a través de un hard fork, y el código de esa dirección (similar al fork de DAO) se cambia de vacío a la implementación de RISC-V. La máquina virtual RISC-V es extremadamente simple, incluso detenerse aquí simplifica netamente el protocolo.
Implementar un intérprete EVM en RISC-V: como contratos inteligentes en la cadena (debido a que el probador ZK necesita haber sido realizado). Después de varios años 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 de consenso clave. El consenso de Ethereum solo comprenderá "nativamente" RISC-V.
Simplificar a través de componentes de protocolo compartido
La tercera forma de reducir la complejidad total del protocolo (y la más fácil de subestimar) es compartir estándares unificados tanto como sea posible entre las diferentes partes de la pila del protocolo. Los diferentes protocolos que hacen lo mismo en diferentes escenarios suelen ser inú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 mediante la compartición de componentes.
código de borrado unificado
Necesitamos códigos de corrección y eliminación en tres escenarios:
Muestreo de disponibilidad de datos: el cliente verifica que el bloque ha sido publicado.
Transmisión P2P más rápida: los nodos pueden aceptar bloques después de recibir n/2 fragmentos, equilibrando la latencia y la redundancia.
Almacenamiento histórico distribuido: el almacenamiento en fragmentos de los datos históricos de Ethereum permite que cada grupo de n/2 fragmentos pueda recuperar los fragmentos restantes, reduciendo el riesgo de pérdida de un solo fragmento.
Si se utiliza el mismo código de corrección de errores en tres escenarios diferentes (ya sea Reed-Solomon, códigos lineales aleatorios, etc.), se obtendrán las siguientes ventajas:
Minimizar la cantidad de código: reducir el número total de líneas de código.
Aumentar la eficiencia: si un nodo descarga fragmentos de una escena, estos datos se pueden utilizar en otras escenas.
Asegurar la verificabilidad: todos los fragmentos de los escenarios son verificables según la raíz.
Si se utilizan diferentes códigos de corrección, al menos se debe garantizar la compatibilidad, por ejemplo, el código Reed-Solomon de muestreo de disponibilidad de datos en nivel y el código lineal aleatorio vertical operan en el mismo dominio.
Formato de serialización unificado
El formato de serialización de Ethereum actualmente está parcialmente consolidado, ya que los datos se pueden volver a serializar y transmitir en cualquier formato. La excepción son los hash de las firmas de las transacciones, que deben ser hashed en un formato estándar. En el futuro, el grado de consolidación del formato de serialización aumentará debido a las siguientes razones:
Abstracción completa de cuentas (EIP-7701): El contenido completo de la transacción es visible para la máquina virtual.
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).
Ha sido ampliamente utilizado en la capa de consenso.
Muy similar al ABI existente: la adaptación de la herramienta es relativamente sencilla.
Ya se han realizado esfuerzos para migrar completamente a SSZ, y debemos considerar y continuar estos esfuerzos al planificar futuras actualizaciones.
estructura de árbol unificado
Si se migra de EVM a RISC-V (u otra máquina virtual mínima opcional), el árbol Merkle Patricia hexadecimal se convertirá en el mayor cuello de botella para probar la ejecución de bloques, incluso en el caso promedio. La migración a un árbol binario basado en una mejor función hash mejorará significativamente la eficiencia del probador, al mismo tiempo que reducirá el costo de datos en escenarios como 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.
De ahora al futuro
La simplicidad es similar a la descentralización en muchos aspectos, ambos son objetivos resilientes de upstream. La necesidad de valorar la simplicidad requiere un cambio cultural. Sus beneficios a menudo son difíciles de cuantificar, mientras que el costo de hacer un esfuerzo adicional y renunciar a ciertas funciones brillantes es inmediato. Sin embargo, con el tiempo, los beneficios serán cada vez más significativos — el mismo Bitcoin es un excelente ejemplo.
Propongo imitar a tinygrad y establecer un objetivo claro de número máximo de líneas de código para la normativa a largo plazo de Ethereum, acercando el código clave de consenso de Ethereum a la simplicidad de Bitcoin. El código que maneja las reglas históricas de Ethereum continuará existiendo, pero debe estar fuera de la ruta clave de consenso. Al mismo tiempo, debemos mantener la filosofía de optar por soluciones más simples, priorizando el encapsulamiento de la complejidad en lugar de la complejidad sistémica, y hacer elecciones 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 Blog: Cómo hacer que Ethereum dentro de 5 años sea tan simple como Bitcoin
Autor | Vitalik Buterin
Compilado | GaryMa Wu habla sobre blockchain
Enlace original:
Resumen
Ethereum aims to become a global ledger, requiring scalability and resilience. This article focuses on the importance of protocol simplicity, proposing to significantly reduce 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), thereby reducing development costs, error risks, and attack surfaces. It is recommended to smooth the transition through backward compatibility strategies (such as on-chain EVM interpreters) and unify erasure codes, serialization formats (SSZ), and tree structures to further simplify. The goal is to bring Ethereum's consensus critical code closer to Bitcoin's simplicity, enhancing resilience and participation, while culturally emphasizing simplicity and setting a maximum code line count 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, al servicio de campos como las finanzas, la gobernanza y la certificación de datos de alto valor. Esto requiere apoyo en dos áreas: escalabilidad y resistencia. El plan de bifurcación dura de Fusaka aumentará el espacio utilizable de los datos de L2 en 10 veces, mientras que la hoja de ruta propuesta para 2026 también planea traer un aumento similar para la capa L1. Mientras tanto, Ethereum ha completado la transición a la 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 están avanzando de manera constante, y el ecosistema de aplicaciones se vuelve cada vez más robusto.
Este artículo se centra en un elemento de resiliencia (e incluso escalabilidad) que es igualmente importante pero a menudo subestimado: la simplicidad del protocolo.
Lo más impresionante del protocolo de Bitcoin es su elegante simplicidad:
Existe una cadena formada por bloques, cada bloque está conectado al bloque anterior a través de un hash.
La validez del bloque se verifica mediante prueba de trabajo (PoW), es decir, comprobando si los primeros dígitos del hash son ceros.
Cada bloque contiene transacciones, las monedas gastadas en las transacciones provienen ya sea de recompensas de minería o de salidas de transacciones anteriores.
¡Eso es todo! Incluso un estudiante de secundaria inteligente puede entender completamente el funcionamiento del protocolo de Bitcoin, y un programador incluso puede escribir un cliente como un proyecto personal.
La simplicidad del protocolo aporta una serie de ventajas clave a Bitcoin (y Ethereum) como base global neutral y de confianza:
Fácil de entender: reducir la complejidad del protocolo, permitir que más personas participen en la investigación, el desarrollo y la gobernanza del protocolo, y reducir el riesgo de que una élite técnica domine.
Reducir los costos de desarrollo: Simplificar los protocolos reduce significativamente el costo de crear nueva infraestructura (como nuevos clientes, probadores, herramientas para desarrolladores, etc.).
Reducir la carga de mantenimiento: disminuir el costo del mantenimiento de acuerdos a largo plazo.
Reducir el riesgo de errores: disminuir la posibilidad de que ocurran errores catastróficos en las especificaciones y la implementación del protocolo, al mismo tiempo que facilita la verificación de que tales errores no existen.
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.
A lo largo de la historia, Ethereum (a veces debido a mis decisiones personales) a menudo no ha logrado mantener la simplicidad, lo que ha llevado a un aumento en los costos de desarrollo, mayores 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 acercará 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ías de consenso, desarrollo de ZK-SNARK, economía de staking, entre otros, para construir una capa de consenso a largo plazo que sea óptima y más sencilla. En comparación con la cadena de balizas existente, el nuevo diseño simplifica significativamente:
Diseño de finalización de 3 ranuras: eliminación de conceptos como ranura (slot), período (epoch), reconfiguración del comité, 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 requiere aproximadamente 200 líneas de código y, en comparación con Gasper, la seguridad es casi óptima.
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.
Protocolo de agregación basado en STARK: cualquier persona puede convertirse en agregador, sin necesidad de confiar en el agregador o pagar altos costos por el dominio de repetición. La complejidad de la criptografía de agregación es alta, pero su complejidad está altamente encapsulada, lo que reduce el riesgo sistémico.
Simplificación de la arquitectura P2P: Los factores mencionados anteriormente pueden respaldar una red punto a punto más simple y robusta.
Rediseñar el mecanismo de validadores: incluye mecanismos de entrada, salida, retiro, conversión de claves, fuga por inactividad, etc., simplificando el número de líneas de código y proporcionando garantías más claras (como el ciclo 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 es cómo lograr una simplificación similar en la capa de ejecución.
Capa de ejecución simplificada
La complejidad del EVM está aumentando cada vez más, y muchas de estas complejidades han demostrado ser innecesarias (en parte debido a errores de decisión personales míos): una máquina virtual de 256 bits ha optimizado en exceso formas criptográficas específicas que están quedando obsoletas, y las precompilaciones se han optimizado para un único caso de uso, pero rara vez se utilizan.
Resolver estos problemas uno por uno tiene un efecto limitado. Por ejemplo, eliminar el opcode SELFDESTRUCT requiere un gran esfuerzo, pero solo aporta beneficios menores. Las recientes discusiones sobre EOF (EVM Object Format) también muestran desafíos similares.
Recientemente propuse un enfoque más radical: en lugar de hacer cambios de tamaño mediano (pero aún destructivos) en el EVM a cambio de un 1.5 veces de rendimiento, sería mejor transitar a una máquina virtual más óptima y simple para lograr un 100 veces de rendimiento. Similar a la "fusión" (The Merge), reducimos el número de cambios destructivos, pero hacemos que cada cambio sea más significativo. En concreto, sugiero reemplazar el EVM por RISC-V, o alguna otra máquina virtual utilizada por el probador ZK de Ethereum. Esto traería:
Mejora significativa en 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.
Mejora significativa en la simplicidad: La especificación de RISC-V es extremadamente simple en comparación con EVM, y las alternativas (como Cairo) también son concisas.
Motivos para soportar EOF: como la partición de código, un análisis estático más amigable, mayores límites de tamaño de código, etc.
Más opciones para desarrolladores: Solidity y Vyper pueden añadir backend para compilar en una nueva máquina virtual. Si se elige RISC-V, los desarrolladores de lenguajes populares también pueden portar fácilmente el código a esa máquina virtual.
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 después de la popularización de las computadoras cuánticas).
La principal desventaja es que, a diferencia del EOF ya preparado, los beneficios de la nueva máquina virtual tardarán más tiempo en beneficiar a los desarrolladores. Podemos mitigar este problema implementando mejoras de EVM de alto valor a corto plazo (como aumentar el límite de tamaño del código de contrato y apoyar DUP/SWAP17–32).
Esto llevará a una máquina virtual más simple. El desafío central es: ¿cómo manejar el EVM existente?
Estrategia de compatibilidad hacia atrás de la transición de la máquina virtual
El mayor desafío para simplificar (o mejorar sin aumentar la complejidad) la EVM es cómo equilibrar la realizació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 una única forma de definición.
El objetivo es reducir al mínimo la zona verde: la lógica necesaria para que los nodos participen en el consenso de Ethereum, incluyendo el cálculo del estado actual, la prueba, la verificación, FOCIL (reglas de selección de bifurcación) y la construcción de bloques "normales".
La zona naranja no se puede reducir: si la especificación del protocolo elimina o cambia alguna función de la capa de ejecución (como la máquina virtual, precompilaciones, etc.), el cliente que procesa bloques históricos aún debe conservar el código relevante. Sin embargo, los nuevos clientes, ZK-EVM o probadores formales pueden ignorar por completo la zona naranja.
Área amarilla añadida: es muy valiosa para comprender la cadena actual o para 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 usuario ERC-4337. Si reemplazamos ciertas funciones de Ethereum (como EOA y sus tipos de transacciones antiguos) con una implementación RISC-V en la cadena, el código de consenso se simplificaría significativamente, pero los nodos dedicados podrían seguir utilizando el código original para el análisis.
La complejidad de las áreas naranja y amarilla es la complejidad de encapsulación; las personas que entienden el protocolo pueden omitir estas partes, y Ethereum puede ignorarlas. 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 dañina 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 hacia atrás 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 puede aplicarse de EVM a Cairo o de RISC-V a una máquina virtual superior):
Se requiere 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.
Introducir RISC-V como opción para desarrolladores: el protocolo admite tanto RISC-V como EVM, los contratos de ambas máquinas virtuales pueden interactuar libremente.
Reemplazo de la mayoría de las precompilaciones: excepto por las operaciones de curva elíptica y KECCAK (debido a la necesidad de velocidad extrema), se implementan las otras precompilaciones mediante RISC-V. Se elimina la precompilación a través de un hard fork, y el código de esa dirección (similar al fork de DAO) se cambia de vacío a la implementación de RISC-V. La máquina virtual RISC-V es extremadamente simple, incluso detenerse aquí simplifica netamente el protocolo.
Implementar un intérprete EVM en RISC-V: como contratos inteligentes en la cadena (debido a que el probador ZK necesita haber sido realizado). Después de varios años 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 de consenso clave. El consenso de Ethereum solo comprenderá "nativamente" RISC-V.
Simplificar a través de componentes de protocolo compartido
La tercera forma de reducir la complejidad total del protocolo (y la más fácil de subestimar) es compartir estándares unificados tanto como sea posible entre las diferentes partes de la pila del protocolo. Los diferentes protocolos que hacen lo mismo en diferentes escenarios suelen ser inú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 mediante la compartición de componentes.
código de borrado unificado
Necesitamos códigos de corrección y eliminación en tres escenarios:
Muestreo de disponibilidad de datos: el cliente verifica que el bloque ha sido publicado.
Transmisión P2P más rápida: los nodos pueden aceptar bloques después de recibir n/2 fragmentos, equilibrando la latencia y la redundancia.
Almacenamiento histórico distribuido: el almacenamiento en fragmentos de los datos históricos de Ethereum permite que cada grupo de n/2 fragmentos pueda recuperar los fragmentos restantes, reduciendo el riesgo de pérdida de un solo fragmento.
Si se utiliza el mismo código de corrección de errores en tres escenarios diferentes (ya sea Reed-Solomon, códigos lineales aleatorios, etc.), se obtendrán las siguientes ventajas:
Minimizar la cantidad de código: reducir el número total de líneas de código.
Aumentar la eficiencia: si un nodo descarga fragmentos de una escena, estos datos se pueden utilizar en otras escenas.
Asegurar la verificabilidad: todos los fragmentos de los escenarios son verificables según la raíz.
Si se utilizan diferentes códigos de corrección, al menos se debe garantizar la compatibilidad, por ejemplo, el código Reed-Solomon de muestreo de disponibilidad de datos en nivel y el código lineal aleatorio vertical operan en el mismo dominio.
Formato de serialización unificado
El formato de serialización de Ethereum actualmente está parcialmente consolidado, ya que los datos se pueden volver a serializar y transmitir en cualquier formato. La excepción son los hash de las firmas de las transacciones, que deben ser hashed en un formato estándar. En el futuro, el grado de consolidación del formato de serialización aumentará debido a las siguientes razones:
Abstracción completa de cuentas (EIP-7701): El contenido completo de la transacción es visible para la máquina virtual.
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).
Ha sido ampliamente utilizado en la capa de consenso.
Muy similar al ABI existente: la adaptación de la herramienta es relativamente sencilla.
Ya se han realizado esfuerzos para migrar completamente a SSZ, y debemos considerar y continuar estos esfuerzos al planificar futuras actualizaciones.
estructura de árbol unificado
Si se migra de EVM a RISC-V (u otra máquina virtual mínima opcional), el árbol Merkle Patricia hexadecimal se convertirá en el mayor cuello de botella para probar la ejecución de bloques, incluso en el caso promedio. La migración a un árbol binario basado en una mejor función hash mejorará significativamente la eficiencia del probador, al mismo tiempo que reducirá el costo de datos en escenarios como 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.
De ahora al futuro
La simplicidad es similar a la descentralización en muchos aspectos, ambos son objetivos resilientes de upstream. La necesidad de valorar la simplicidad requiere un cambio cultural. Sus beneficios a menudo son difíciles de cuantificar, mientras que el costo de hacer un esfuerzo adicional y renunciar a ciertas funciones brillantes es inmediato. Sin embargo, con el tiempo, los beneficios serán cada vez más significativos — el mismo Bitcoin es un excelente ejemplo.
Propongo imitar a tinygrad y establecer un objetivo claro de número máximo de líneas de código para la normativa a largo plazo de Ethereum, acercando el código clave de consenso de Ethereum a la simplicidad de Bitcoin. El código que maneja las reglas históricas de Ethereum continuará existiendo, pero debe estar fuera de la ruta clave de consenso. Al mismo tiempo, debemos mantener la filosofía de optar por soluciones más simples, priorizando el encapsulamiento de la complejidad en lugar de la complejidad sistémica, y hacer elecciones de diseño que ofrezcan atributos y garantías claras.