Un agradecimiento especial a Fede, Danno Ferrin, Justin Drake, Ladislaus y Tim Beiko por sus comentarios y revisiones.

El objetivo de Ethereum es convertirse en un libro mayor global - una plataforma que almacena activos y registros humanos, y es la capa subyacente para aplicaciones como finanzas, gobernanza y verificación de datos de alto valor. Para lograr este objetivo, debe tener tanto escalabilidad como resistencia. El plan de bifurcación dura de Fusaka aumentará el espacio de disponibilidad de datos L2 en 10 veces, mientras queEl plan propuesto para 2026También incluye una escala similar de expansión de datos L1. Mientras tanto, 'The Merge' ha actualizado Ethereum a un mecanismo de consenso de participación (PoS).La diversidad de clientes está aumentando rápidamente, la verificabilidad ZK (Prueba de Conocimiento Cero) y la resistencia a los ataques cuánticos también están progresando de manera constante, y el ecosistema de aplicaciones está creciendo cada vez másMaduro y robusto.

El objetivo de este artículo es enfatizar un aspecto igualmente crítico pero a menudo subestimadoResiliencia (y en última instancia escalabilidad)Elementos:
Simplicidad del protocolo.

Uno de los aspectos más elogiados de Bitcoin es su diseño de protocolo, que es extremadamente elegante y simple:

El sistema es una cadena de bloques, compuesta por una serie de bloques. Cada bloque está vinculado al anterior a través de un hash. La validez de cada bloque se verifica a través de la Prueba de Trabajo (PoW), lo que significa… solo necesitas comprobar si los dígitos principales de su hash son ceros. Cada bloque contiene transacciones, que bien gastan las monedas obtenidas a través de la minería, o gastan las monedas resultantes de transacciones anteriores. Básicamente, eso es todo.
Incluso un estudiante inteligente de secundaria tiene la capacidad de comprender completamente los principios de funcionamiento del protocolo de Bitcoin. E incluso un programador puede desarrollar un cliente de Bitcoin como un proyecto de hobby.

Mantener el protocolo simple trae una serie de ventajas clave, lo que potencialmente hace a Bitcoin y EthereumNeutralidad confiableLa capa fundamental de confianza global:

• Hacer que la lógica del protocolo sea más fácil de entender, ampliar el grupo que puede participar en la investigación, desarrollo y gobernanza del protocolo, reducir las barreras técnicas y evitar el dominio de una 'clase burocrática tecnológica' en el protocolo.
• Reducir significativamente el costo de desarrollo de nueva infraestructura integrada con protocolos (como nuevos clientes, nuevos verificadores, nuevas herramientas de registro, etc.).
• Reducir el costo de mantenimiento a largo plazo del protocolo.
• Reducir el riesgo de vulnerabilidades catastróficas, ya sea en las especificaciones del protocolo o en el código de implementación; también facilita verificar que el protocolo no contiene tales vulnerabilidades.
• Reducir la superficie de ataque social: cuanto menos componentes, menos lugares pueden ser explotados y controlados por partes interesadas específicas.

En el pasado, Ethereum no ha tenido un buen desempeño en este sentido (a veces incluso debido a mis decisiones personales), lo que ha llevado a nuestros gastos excesivos de desarrollo,@vbuterin/selfdestruct”>Various security risks and the closed nature of R&D culture, and these efforts often only bring illusory returns.
Este artículo explicará cómo Ethereum podría alcanzar un nivel de simplicidad cercano al de Bitcoin en cinco años.

Capa de consenso simplificado

3-slot finality（3槽终结性）模拟图 — 3sf-mini

El nuevo diseño de la capa de consenso (anteriormente conocido como 'cadena de rayos') tiene como objetivo integrar la experiencia que hemos acumulado en teoría de consenso, desarrollo de ZK-SNARK, economía de staking y otras áreas en la última década, para crear una capa de consenso Ethereum óptima a largo plazo. Se espera que esta nueva capa de consenso, en comparación con la Beacon Chain existente, logre una mayor simplicidad. Esto es particularmente evidente en:

• reestructuración de finalidad de 3 slots
  Este diseño elimina la distinción entre 'slot' y 'epoch', el reordenamiento de comités y otros detalles de especificación del protocolo relacionados con estos mecanismos (como comités sincrónicos). Una versión básica de finalidad de 3 'slots'Solo se necesitan alrededor de 200 líneas de códigoSe puede lograr. En comparación con el protocolo Gasper actual, la finalidad de 3 slots también tiene una seguridad cercana a la óptima.
• El número de validadores activos ha disminuido
  Hace que sea más seguro y factible adoptar una regla de elección de bifurcación más simple.
• Protocolo de agregación basado en STARK
  Significa que cualquier persona puede convertirse en un agregador sin preocuparse de confiar en el agregador, de tarifas excesivas por campos de bits repetidos, etc. Aunque la encriptación de la agregación en sí misma tiene cierta complejidad, estoComplejidad altamente encapsuladaEl riesgo sistemático general del protocolo es mucho menor.
• Los dos puntos anteriores también son probablemente compatibles con una arquitectura peer-to-peer (p2p) más simple y robusta.
• Tenemos la oportunidad de repensar los mecanismos de entrada, salida, retiro, cambio de clave, penalización por inercia, etc., y simplificarlos, no solo reduciendo el número de líneas de código (LoC), sino también proporcionando garantías de mecanismos más claras, como una fecha límite de 'subjetividad débil' más explícita.

La ventaja de la capa de consenso es que está relativamente desacoplada de la ejecución de EVM, por lo que tenemos mucho espacio para seguir impulsando estas mejoras hacia adelante.
Más desafiante es: cómo lograr la misma simplificación en la capa de ejecución.

Simplificar Capa de Ejecución

La complejidad de la Máquina Virtual Ethereum (EVM) está aumentando continuamente, y gran parte de esta complejidad se ha demostrado innecesaria (a menudo también relacionada con mis decisiones personales): tenemos una máquina virtual de 256 bits que está excesivamente optimizada para formas criptográficas muy específicas, que ahora se están marginando gradualmente; y algunos contratos precompilados se centran excesivamente en muy pocos casos de uso únicos.

Intentar solucionar gradualmente estos problemas prácticos no es factible.Eliminar @vbuterinLa instrucción SELFDESTRUCT consume una gran cantidad de energía, pero los resultados son limitados. El reciente debate sobre EOF (Formato de Objeto EVM) demuestra aún más la dificultad de realizar cambios similares en la máquina virtual.

Por lo tanto, como alternativa, recientemente propuse una idea más radical: en lugar de realizar cambios incrementales (pero aún destructivos) para una mejora de 1.5x, es mejor migrar directamente a una máquina virtual completamente nueva, mucho superior y más simple, apuntando a un rendimiento de 100x. Al igual que 'La Fusión', reducimos el número de transformaciones, pero cada una es significativa. Específicamente, sugiero reemplazar el EVM existente con RISC-V (u otra máquina virtual que será utilizada por el probador ZK de Ethereum). De esta manera, lograremos:

• Mejora significativa de la eficiencia: debido a que los contratos inteligentes pueden ejecutarse directamente en el probador sin la sobrecarga de un intérprete. Los datos concisos indican que el rendimiento puede mejorar en más de 100 veces en muchos escenarios.
• Sencillez definitiva: comparado con la especificación de RISC-V, EVMExtremadamente simple. Otras soluciones alternativas (como Cairo) son igualmente concisas.
• Heredando las ventajas esperadas de EOF: como la segmentación de código, un análisis estático más amigable, un límite de capacidad de código más grande, etc.
• Los desarrolladores tienen más opciones: Solidity y Vyper pueden compilarse al nuevo backend de la máquina virtual. Si se elige RISC-V, los desarrolladores de lenguajes mainstream también pueden portar fácilmente su código.
• Reducir significativamente la necesidad de precompilación: posiblemente conservando solo algunas operaciones de curva elíptica altamente optimizadas (aunque estas dejarán de existir una vez que la computación cuántica se vuelva popular).

El principal inconveniente de este enfoque es que, a diferencia de EOF (implementación inmediata), la nueva máquina virtual tarda más en beneficiar a los desarrolladores. Para mitigar esto, podemos introducir algunas mejoras pequeñas pero de gran valor en EVM a corto plazo.Aumentar el límite de tamaño del código del contrato、Aumentar las instrucciones DUP/SWAP17-32, etc.)

En última instancia, esto nos dará una máquina virtual muy simplificada. Pero la pregunta más importante es: ¿qué pasa con el EVM existente?

Estrategia de compatibilidad hacia atrás transicional de VM

Al simplificar significativamente (o incluso mejorar sin añadir complejidad) cualquier parte de la Máquina Virtual Ethereum (EVM), el mayor desafío es: cómo mantener la compatibilidad con las aplicaciones existentes al tiempo que se logra el objetivo.

En primer lugar, debe quedar claro que no hay una única forma de definir el alcance del “código base de Ethereum” (incluso dentro del mismo cliente).

El objetivo es minimizar el alcance del área verde tanto como sea posible: es decir, la lógica que los nodos deben ejecutar para participar en el consenso de Ethereum, incluyendo el cálculo del estado actual, la prueba, la validación, FOCIL (Capa de Integridad de Consenso de Primer Orden), construcción básica de bloques, etc.

El área naranja no se puede reducir: si se elimina una característica de capa de ejecución específica (ya sea una máquina virtual, precompilación u otro mecanismo) de la especificación del protocolo, o si su funcionalidad cambia, el cliente encargado de procesar bloques históricos aún debe retenerlo, pero es importante destacar que los nuevos clientes (como ZK-EVMs o verificadores formales) pueden ignorar completamente el área naranja.

La nueva categoría es el área amarilla: este tipo de código es muy importante para entender y analizar el estado actual de la cadena, y para construir los mejores bloques, pero no forma parte del consenso. Un ejemplo es Etherscan(Y algunosConstructor de Bloques) Soporte para operaciones de usuario ERC-4337. Si utilizamos una implementación RISC-V en cadena para reemplazar ciertas funciones grandes de Ethereum (como las cuentas EOA y su soporte para varios tipos de transacciones antiguas), entonces, a pesar de la simplificación significativa del código de consenso, algunos nodos profesionales aún pueden seguir utilizando el código original para analizar estas funciones.

Es importante que las áreas naranjas y amarillas pertenezcan a "Gate"Complejidad de encapsulamientoCualquiera que desee entender el protocolo puede omitirlos, los clientes de Ethereum también pueden optar por no implementarlos, y los errores en estas áreas no representarán un riesgo para el consenso. Esto significa que la complejidad del código y el impacto negativo causado por las áreas de naranja y amarillo son mucho menores que el área verde.

Transferir el código de la zona verde a la zona amarilla, este enfoque es similar a Apple Inc.Traducir a través de la capa de traducción de RosettaPara garantizar la compatibilidad a largo plazo.

Propuse (tomado de@ipsilon/eof-ethereums-gateway-to-risc-v”> El reciente proceso de migración de máquina virtual del equipo Ipsilon (utilizando la migración de EVM a RISC-V como ejemplo, pero también aplicable a la migración de EVM a Cairo, e incluso a la futura migración a una máquina virtual más óptima):

1. Todos los nuevos precompilados deben estar escritos en la implementación estándar en cadena de RISC-V, para que el ecosistema pueda empezar a familiarizarse y utilizar RISC-V como la máquina virtual.
2. Introduciendo RISC-V como una opción para el desarrollo de contratos en paralelo a EVM para los desarrolladores. El protocolo soporta nativamente tanto RISC-V como EVM, permitiendo que los contratos escritos en ambos lenguajes interactúen libremente.
3. Reemplace todos los precompilados (excepto las operaciones de curva elíptica y KECCAK) con una implementación RISC-V. Eliminamos estos precompilados a través de un hard fork y al mismo tiempo cambiamos el código en la dirección correspondiente (al estilo de la bifurcación DAO) para que sea una implementación RISC-V. Debido a que la máquina virtual RISC-V es extremadamente concisa, incluso solo con hacer esto se simplifica la estructura general.
4. Implementar un intérprete EVM escrito en RISC-V y desplegarlo como un contrato inteligente en la cadena. Después de varios años de su lanzamiento inicial, los contratos EVM existentes serán procesados a través de este intérprete.

Después de completar el paso 4, seguirá habiendo muchas 'implementaciones de EVM' que se utilizarán para optimizar la construcción de bloques, las herramientas de desarrollo y el análisis en cadena, pero ya no formarán parte de las especificaciones clave del consenso. En ese momento, el consenso de Ethereum solo entenderá 'nativamente' RISC-V.

Simplificar compartiendo componentes de protocolo

El tercer, y quizás el método de simplificación más subestimado, es compartir un estándar unificado en diversas partes de la pila de protocolos tanto como sea posible. Por lo general, no hay razón para utilizar diferentes protocolos para el mismo propósito en diferentes escenarios, pero esta situación aún ocurre con frecuencia en la realidad, principalmente debido a la falta de comunicación entre las diferentes partes de la hoja de ruta del protocolo. Aquí hay algunos ejemplos específicos de simplificación de Ethereum a través de la 'maximización del intercambio de componentes'.

Un código de borrado unificado

Necesitamos corregir el código de eliminación en tres escenarios:

• Muestreo de disponibilidad de datos - El cliente verifica si el bloque ha sido publicado
• Transmisión P2P más rápida: los nodos pueden aceptar bloques después de recibir n/2 de n bloques, estableciendo así el equilibrio óptimo entre reducir la latencia y la redundancia.
• Almacenamiento de Historia Distribuida - Cada pieza de historia de Ethereum se almacena en muchos bloques, por lo que (i) estos bloques pueden ser verificados de forma independiente y (ii) la mitad de los bloques en cada grupo puede recuperar la otra mitad, reduciendo significativamente el riesgo de pérdida de cualquier bloque único.

Si usamos el mismo código de borrado (ya sea Reed-Solomon, código lineal aleatorio u otro) en tres casos de uso, obtendremos algunas ventajas importantes:

1. Minimizar el total de líneas de código
2. Mejorar la eficiencia porque si cada nodo debe descargar varias partes de un bloque para un caso de uso (en lugar de todo el bloque), los datos se pueden utilizar para otro caso de uso
3. Garantizar la verificabilidad: los tres bloques en el contexto pueden ser verificados basados en la raíz

Si de hecho se requieren diferentes códigos de corrección de errores, al menos se debe garantizar la 'compatibilidad': por ejemplo, en el escenario de DAS, se utiliza Reed-Solomon horizontalmente y el código lineal aleatorio se utiliza verticalmente, pero ambos se basan en el mismo campo matemático.

Un formato de serialización unificado

Actualmente, el formato de serialización de Ethereum es estrictamente hablando, solo "semi-estandarizado", ya que los datos pueden volver a serializarse y transmitirse en cualquier formato. La única excepción es el hash de firma de transacción, donde se requiere un formato estandarizado para el cálculo del hash.
Pero la estandarización de los formatos de serialización futuros se mejorará aún más, por dos razones:

• Abstracción de cuenta integral (EIP-7701): La máquina virtual podrá ver el contenido completo de la transacción
• Aumento del límite de gas: Se necesita empaquetar los datos del bloque de ejecución en blob

En ese momento, tenemos la oportunidad de unificar las soluciones de serialización requeridas para los tres aspectos actuales: 1) capa de ejecución; 2) capa de consenso; 3) ABI de invocación de contrato inteligente.

Sugiero adoptar SSZ(Simple Serialize), porque SSZ tiene las siguientes ventajas:

• Fácil de descifrar: incluyendo dentro de contratos inteligentes (basado en un diseño de 4 bytes, pocos casos límite)
• Ampliamente utilizado en consenso
• Altamente similar al ABI existente: bajo costo de migración de herramientas

Actualmente se han añadido más componentesMigraciónA SSZTrabajoAl planificar las futuras actualizaciones, debemos considerar y utilizar plenamente estos desarrollos.

Una estructura de árbol unificada

Una vez que nos mudemos de EVM a RISC-V (u otra MV minimalista), el árbol de Merkle Patricia hexadecimal se convertirá en el mayor cuello de botella para probar la ejecución de bloques, incluso en escenarios promedio. Migrar a una función de hashÁrbol Binario, mejorará considerablemente la eficiencia del verificador y reducirá el costo de datos de nodos ligeros y otros escenarios.

Al completar la migración de la estructura del árbol, también debemos asegurarnos de que la capa de consenso utilice la misma estructura de árbol para garantizar que se pueda acceder y analizar todo Ethereum, tanto las capas de consenso como de ejecución, utilizando el mismo conjunto de código.

Desde ahora hacia el futuro

La simplificación y la descentralización tienen muchas similitudes. Ambas son requisitos previos necesarios para lograr el objetivo superior de la resiliencia del sistema. Enfatizar la simplificación explícitamente requiere un cambio cultural. Los beneficios de la simplificación a menudo son difíciles de ver en las etapas iniciales, pero los costos de oportunidad y la carga de trabajo adicional de rechazar esas 'nuevas características brillantes' son inmediatamente evidentes. Sin embargo, con el tiempo, el valor a largo plazo de la simplificación se vuelve cada vez más evidente: Bitcoin en sí mismo es un excelente ejemplo.

Sugiero queAprende del enfoque de tinygradPara establecer un objetivo claro de límite de líneas de código para la especificación a largo plazo de Ethereum, el objetivo es hacer que el código crítico de consenso de Ethereum se acerque lo más posible al estilo minimalista de Bitcoin. El código que trata de las reglas históricas de Ethereum seguirá existiendo pero debería estar aislado del camino crítico del consenso. Al mismo tiempo, deberíamos formar un principio de diseño universal: elegir soluciones más simples siempre que sea posible, priorizar la complejidad encapsulada sobre la complejidad sistémica y inclinarse hacia decisiones de diseño que proporcionen propiedades y garantías claras verificables.

Descargo de responsabilidad:

1. Este artículo ha sido reimpreso de [vitalik]. Todos los derechos de autor pertenecen al autor original [vitalikTodo. Si tiene alguna objeción a esta reimpresión, por favor contacteGate LearnEl equipo lo manejará de manera oportuna.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. El equipo de Gate Learn traduce artículos a otros idiomas. Está prohibido copiar, distribuir o plagiar los artículos traducidos a menos que se especifique lo contrario.