El futuro posible del protocolo Ethereum(se): prosperidad

En el diseño del protocolo Ethereum, hay muchos “detalles” que son muy importantes para el éxito de Ethereum. De hecho, aproximadamente la mitad del contenido se refiere a diferentes tipos de mejoras de EVM, mientras que el resto está compuesto por varios temas de nicho, de ahí el significado de “complejidad”.

Prosperidad: Objetivo clave

• Convertir EVM en un “estado final” de alto rendimiento y estabilidad
• Introducir la abstracción de cuentas en el protocolo, permitiendo a todos los usuarios disfrutar de cuentas más seguras y convenientes.
• Optimizar la economía de las tarifas de transacción, mejorar la escalabilidad y reducir el riesgo al mismo tiempo.
• Explorar la criptografía avanzada, para que Ethereum mejore significativamente a largo plazo.

mejora de EVM

¿Qué problema se resolvió?

Actualmente, el EVM es difícil de analizar estáticamente, lo que dificulta la creación de implementaciones eficientes, la verificación formal del código y la realización de extensiones adicionales. Además, la eficiencia del EVM es baja, lo que dificulta la implementación de muchas formas de criptografía avanzada, a menos que se soporte explícitamente a través de precompilados.

¿Qué es y cómo funciona?

El primer paso en la hoja de ruta de mejoras de EVM actual es el formato de objeto EVM (EOF), que se planea incluir en la próxima bifurcación dura. EOF es una serie de EIP que especifica una nueva versión del código EVM, con muchas características únicas, siendo la más notable:

• El código ( es ejecutable, pero no se puede leer desde EVM. La data ) se puede leer, pero no se puede ejecutar entre la separación de (.
• Prohibir redirecciones dinámicas, solo permitir redirecciones estáticas
• El código EVM ya no puede observar información relacionada con el combustible.
• Se ha añadido un nuevo mecanismo de subrutina explícita.

Los contratos antiguos continuarán existiendo y podrán crearse, aunque eventualmente podrían ser gradualmente desechados los contratos antiguos ) e incluso podrían ser forzados a convertirse en código EOF (. Los nuevos contratos se beneficiarán de la mejora de eficiencia que trae el EOF: primero a través de un bytecode ligeramente reducido gracias a las características de subrutinas, y luego con nuevas funciones específicas de EOF o costos de gas reducidos.

Tras la introducción de EOF, las actualizaciones adicionales se vuelven más fáciles, y el desarrollo más avanzado es la extensión aritmética del módulo EVM ) EVM-MAX (. EVM-MAX crea un conjunto de nuevas operaciones específicamente para la operación de módulo y las coloca en un nuevo espacio de memoria que no se puede acceder a través de otros códigos de operación, lo que hace posible el uso de optimizaciones como la multiplicación de Montgomery.

Una idea más reciente es combinar EVM-MAX con la característica de múltiples datos de una sola instrucción )SIMD(, SIMD como un concepto de Ethereum ha existido durante mucho tiempo, propuesto originalmente por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidas las funciones hash, STARKs de 32 bits y criptografía basada en rejillas. La combinación de EVM-MAX y SIMD hace que estas dos escalas orientadas al rendimiento sean una pareja natural.

Un diseño aproximado de un EIP combinado comenzará con el EIP-6690, luego:

• Permitir )i( cualquier número impar o )ii( cualquier potencia de 2 que no supere 2768 como módulo
• Para cada opcode EVM-MAX ) suma, resta, multiplicación (, se añade una versión que ya no utiliza 3 constantes inmediatas x, y, z, sino que utiliza 7 constantes inmediatas: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. En el código Python, el efecto de estos opcodes es similar a:

for i in range)count(: mem[z_start + z_skip * count] = op) mem[x_start + x_skip * count], mem[y_start + y_skip * count] (

En la implementación real, esto se procesará de manera paralela.

• Podría añadirse XOR, AND, OR, NOT y SHIFT) incluyendo ciclos y no ciclos(, al menos para potencias de 2 módulo. Al mismo tiempo, añadir ISZERO) empujará la salida a la pila principal de EVM(, lo que será lo suficientemente potente para implementar criptografía de curva elíptica, criptografía de campo pequeño) como Poseidon, Circle STARKs(, funciones hash tradicionales) como SHA256, KECCAK, BLAKE( y criptografía basada en reticulados. Otras actualizaciones de EVM también podrían implementarse, pero hasta ahora han recibido menos atención.

![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7.webp(

)# El trabajo restante y las consideraciones

Actualmente, EOF se planea incluir en la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento — en bifurcaciones duras anteriores se han eliminado temporalmente funciones, pero hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura para EVM deberá realizarse sin EOF, aunque es posible, podría ser más difícil.

La principal compensación del EVM radica en la complejidad de L1 y la complejidad de la infraestructura. El EOF requiere agregar una gran cantidad de código a la implementación del EVM, y la verificación estática del código también es relativamente compleja. Sin embargo, a cambio, podemos simplificar los lenguajes de alto nivel, simplificar la implementación del EVM y obtener otros beneficios. Se puede decir que la hoja de ruta que prioriza la mejora continua de Ethereum L1 debería incluir y basarse en el EOF.

Una tarea importante que debe realizarse es implementar funciones similares a EVM-MAX con SIMD y realizar pruebas de referencia sobre el consumo de gas de diversas operaciones criptográficas.

¿Cómo interactuar con otras partes de la hoja de ruta?

L1 ajusta su EVM para que L2 también pueda realizar ajustes correspondientes más fácilmente. Si ambos no realizan ajustes sincronizados, podría causar incompatibilidades y tener efectos negativos. Además, EVM-MAX y SIMD pueden reducir los costos de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita reemplazar más precompilados con código EVM que puede ejecutar las mismas tareas, lo que podría no afectar significativamente la eficiencia.

![Vitalik sobre el posible futuro de Ethereum (6): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(

) abstracción de cuenta

¿Qué problema se resolvió?

Actualmente, las transacciones solo pueden ser verificadas de una manera: firma ECDSA. Originalmente, la abstracción de cuentas estaba destinada a ir más allá de esto, permitiendo que la lógica de verificación de cuentas sea cualquier código EVM. Esto puede habilitar una serie de aplicaciones:

• Cambiar a criptografía resistente a quantum
• Rotar la clave antigua ### es ampliamente considerado como una práctica de seguridad recomendada (
• Billetera de firma múltiple y billetera de recuperación social
• Usar una clave para operaciones de bajo valor, usar otra clave ) o un conjunto de claves ( para operaciones de alto valor

Permitir que el protocolo de privacidad funcione sin intermediarios, reduciendo significativamente su complejidad y eliminando un punto de dependencia central clave.

Desde que se propuso la abstracción de cuentas en 2015, su objetivo también se ha ampliado para incluir una gran cantidad de “objetivos de conveniencia”, por ejemplo, una cuenta que no tenga ETH pero posea algunos ERC20 pueda usar ERC20 para pagar el gas.

)# ¿Qué es y cómo funciona?

El núcleo de la abstracción de cuentas es simple: permite a los contratos inteligentes iniciar transacciones, y no solo a las EOA. Toda la complejidad proviene de implementar esto de una manera que sea amigable para el mantenimiento de una red descentralizada y prevenir ataques de denegación de servicio.

Un desafío clave típico es el problema de múltiples fallos:

Si hay 1000 funciones de verificación de cuentas que dependen de un único valor S, y el valor actual S hace que las transacciones en el mempool sean válidas, entonces una única transacción que invierta el valor de S podría hacer que todas las demás transacciones en el mempool sean inválidas. Esto permite que un atacante envíe transacciones basura al mempool a un costo muy bajo, obstruyendo así los recursos de los nodos de la red.

Después de años de esfuerzo, con el objetivo de expandir las funciones mientras se limita el riesgo de denegación de servicio ### DoS (, finalmente se llegó a la solución para lograr “la abstracción ideal de cuentas”: ERC-4337.

El funcionamiento de ERC-4337 divide el procesamiento de las operaciones del usuario en dos etapas: verificación y ejecución. Todas las verificaciones se procesan primero, y todas las ejecuciones se procesan después. En el pool de memoria, solo se aceptarán las operaciones del usuario cuya etapa de verificación solo involucre su propia cuenta y no lea variables de entorno. Esto puede prevenir ataques de doble fallo. Además, se imponen estrictos límites de gas en los pasos de verificación.

ERC-4337 fue diseñado como un estándar de protocolo adicional )ERC(, porque en ese momento los desarrolladores de clientes de Ethereum se centraron en la fusión )Merge(, sin energía adicional para manejar otras funciones. Por eso ERC-4337 utiliza un objeto llamado operación del usuario, en lugar de transacciones convencionales. Sin embargo, recientemente nos hemos dado cuenta de la necesidad de escribir al menos parte de su contenido en el protocolo.

Las dos razones clave son las siguientes:

1. EntryPoint como la ineficiencia inherente del contrato: cada agrupamiento tiene un costo fijo de aproximadamente 100,000 gas, además de miles de gas adicionales por cada operación del usuario.
2. Asegurar la necesidad de las propiedades de Ethereum: como la lista de inclusión creada que garantiza que se necesita transferir a la cuenta de usuarios abstractos.

Además, ERC-4337 también ha ampliado dos funciones:

• Agentes de pago ) Paymasters (: permite que una cuenta pague las tarifas en nombre de otra cuenta, lo que infringe la regla de que en la fase de verificación solo se puede acceder a la cuenta del remitente en sí, por lo que se introducen tratamientos especiales para garantizar la seguridad del mecanismo de agentes de pago.
• Agregadores): Soporte para funciones de agregación de firmas, como la agregación BLS o la agregación basada en SNARK. Esto es necesario para lograr la máxima eficiencia de datos en Rollup.

(# Trabajo restante y compensaciones

Actualmente, lo que se necesita resolver principalmente es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas que ha ganado popularidad recientemente es el EIP-7701, el cual implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una parte de código separada para la verificación; si la cuenta ha configurado esa parte de código, entonces ese código se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.

El encanto de este enfoque radica en que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas locales:

1. Incluir EIP-4337 como parte del protocolo
2. Un nuevo tipo de EOA, cuyo algoritmo de firma es la ejecución de código EVM.

Si comenzamos estableciendo límites estrictos sobre la complejidad del código ejecutable durante el período de validación—sin permitir el acceso al estado externo, incluso el límite de gas establecido inicialmente es tan bajo que resulta ineficaz para aplicaciones de resistencia cuántica o protección de la privacidad—entonces la seguridad de este enfoque es muy clara: simplemente se reemplaza la verificación de ECDSA por la ejecución de código EVM que requiere un tiempo similar.

Sin embargo, con el paso del tiempo, necesitamos relajar estos límites, ya que permitir que las aplicaciones de protección de la privacidad funcionen sin intermediarios, así como la resistencia cuántica, son muy importantes. Para ello, necesitamos encontrar formas más flexibles de abordar el riesgo de denegación de servicio )DoS###, sin exigir que los pasos de verificación sean extremadamente simplistas.

La principal compensación parece ser entre “escribir rápidamente una solución que satisfaga a menos personas” y “esperar más tiempo para posiblemente obtener una solución más ideal”; el enfoque ideal podría ser algún tipo de enfoque híbrido. Un enfoque híbrido sería escribir más rápidamente algunos casos de uso y dejar más tiempo para explorar otros casos de uso. Otro enfoque sería implementar primero una versión de abstracción de cuentas más ambiciosa en L2. Sin embargo, el desafío al que se enfrenta esto es que el equipo de L2 necesita tener confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para asegurar que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.

Otra aplicación que también necesitamos considerar claramente es la cuenta de almacenamiento de claves, que almacena el estado relacionado con la cuenta en L1 o en un L2 dedicado, pero puede usarse en L1 y cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte códigos de operación como L1SLOAD o REMOTESTATICCALL, pero esto también requiere que la implementación de la abstracción de cuentas en L2 soporte estas operaciones.

(# ¿Cómo interactúa con otras partes del roadmap?

La lista de inclusión debe soportar transacciones de abstracción de cuentas. En la práctica, la necesidad de una lista de inclusión es en realidad muy similar a la necesidad de un grupo de memoria descentralizado, aunque respecto a