El futuro posible del protocolo Ethereum ( seis ): prosperidad

El diseño del protocolo de Ethereum tiene muchos "detalles" importantes que son cruciales para su éxito. 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, que es el significado de "prosperidad".

Prosperidad: Objetivo Clave

• Convertir el 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 los costos de transacción, mejorar la escalabilidad y reducir el riesgo al mismo tiempo
• Explorar la criptografía avanzada, para mejorar significativamente Ethereum 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 apoye explícitamente a través de precompilaciones.

¿Qué es y cómo funciona?

El primer paso en la hoja de ruta de mejora 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, la más notable es:

• El código ( se puede ejecutar, pero no se puede leer ) desde el EVM y los datos ( se pueden leer, pero no se pueden ejecutar entre la separación de ).
• Prohibido el salto dinámico, solo se permite el salto estático
• 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 seguirán existiendo y podrán crearse, aunque eventualmente podrían ser descontinuados gradualmente, y los contratos antiguos ( incluso podrían ser forzados a convertirse en código EOF ). Los nuevos contratos se beneficiarán de la mejora en la eficiencia que trae EOF: primero, con 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.

Después de la introducción de EOF, las actualizaciones posteriores se vuelven más fáciles, y el desarrollo más completo en este momento es la expansión aritmética del módulo EVM ( EVM-MAX ). EVM-MAX crea un conjunto de nuevas operaciones específicamente dirigidas a la operación modular 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 concepto de Ethereum, ha existido durante mucho tiempo, siendo propuesto por primera vez por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluyendo funciones hash, STARKs de 32 bits y criptografía basada en retículos. La combinación de EVM-MAX y SIMD hace que estas dos extensiones orientadas al rendimiento sean una pareja natural.

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

• Permitir (i) cualquier número impar o (ii) cualquier potencia de 2 que no exceda 2768 como módulo
• Para cada opcode EVM-MAX ( suma, resta, multiplicación ), agregar una versión que ya no use 3 literales x, y, z, sino que use 7 literales: 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.

• Puede agregar XOR, AND, OR, NOT y SHIFT(, incluidos bucles y no bucles), al menos para módulos de potencia de 2. Al mismo tiempo, agregar ISZERO( enviará la salida a la pila principal de EVM), lo que será lo suficientemente potente como 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 redes. Otras actualizaciones de EVM también pueden implementarse, pero hasta ahora han recibido menos atención.

El trabajo restante y las compensaciones

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

El principal compromiso del EVM radica en la complejidad del L1 y la complejidad de la infraestructura. El EOF es una gran cantidad de código que necesita ser añadido 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 afirmar que la hoja de ruta prioritaria para la mejora continua de Ethereum L1 debería incluir y basarse en el EOF.

Una tarea importante que debe realizarse es implementar funcionalidades similares a EVM-MAX más 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 se sincronizan en sus ajustes, puede causar incompatibilidad y tener efectos adversos. Además, EVM-MAX y SIMD pueden reducir el costo de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita la sustitución de más precompilados por código EVM que puede realizar las mismas tareas, lo que puede no afectar significativamente la eficiencia.

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 tenía como objetivo ir más allá de esto, permitiendo que la lógica de verificación de cuentas fuera cualquier código EVM. Esto puede habilitar una serie de aplicaciones:

• Cambiar a criptografía resistente a la computación cuántica
• Rotar las claves antiguas ( se considera ampliamente una práctica de seguridad recomendada )
• Monedero de múltiples firmas y monedero de recuperación social
• Utilizar una clave para operaciones de bajo valor, utilizar 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 se ha ampliado para incluir una gran cantidad de "objetivos de conveniencia", por ejemplo, una cuenta que no tiene ETH pero posee algunos ERC20 puede usar ERC20 para pagar el gas.

¿Qué es y cómo funciona?

El núcleo de la abstracción de cuentas es simple: permite que los contratos inteligentes inicien transacciones, y no solo las cuentas de usuario externas (EOA). Toda la complejidad proviene de implementarlo de una manera que sea amigable para mantener 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 cuentas cuya función de verificación depende de un único valor S, y el valor S actual hace que las transacciones en el pool de memoria sean válidas, entonces una única transacción que invierte el valor de S podría hacer que todas las demás transacciones en el pool de memoria sean inválidas. Esto permite a un atacante enviar transacciones basura al pool de memoria a un costo muy bajo, lo que bloquea los recursos de los nodos de la red.

Después de años de esfuerzo, destinado a 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 posteriormente. 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 aplican estrictos límites de gas a los pasos de verificación.

ERC-4337 fue diseñado como un estándar de protocolo adicional (ERC), ya que en ese momento los desarrolladores de clientes de Ethereum se centraban en la fusión (Merge), sin energía adicional para manejar otras funciones. Es por eso que ERC-4337 utilizó un objeto llamado operación de 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 de los contratos: cada agrupación 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 incluida que crea la garantía que necesita ser transferida a la cuenta del usuario abstracto.

Además, ERC-4337 también amplía dos funciones:

• Agentes de pago ( Paymasters ): permite que una cuenta pague las tarifas en nombre de otra cuenta, lo que viola la regla de que en la fase de validación solo se puede acceder a la cuenta del remitente, por lo tanto, se introdujeron tratamientos especiales para garantizar la seguridad del mecanismo de agentes de pago.
• Aggregadores(: Soporta 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.

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

)# 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 más popular recientemente es el EIP-7701, que 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 esta parte de código, entonces este código se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.

El atractivo 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, en el que el 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 verificación--sin permitir el acceso al estado externo, e incluso con un límite de gas establecido en las etapas iniciales que es tan bajo que resulta ineficaz para aplicaciones de resistencia cuántica o protección de privacidad--entonces la seguridad de este enfoque es muy clara: simplemente reemplazar la verificación ECDSA por la ejecución de código EVM que requiere un tiempo similar.

Sin embargo, con el 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 requerir que los pasos de verificación sean extremadamente simplistas.

La principal consideración parece ser "escribir rápidamente una solución que satisfaga a menos personas" frente a "esperar más tiempo para posiblemente obtener una solución más ideal", y el enfoque ideal podría ser algún tipo de método híbrido. Un método 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 desplegar primero una versión de abstracción de cuentas más ambiciosa en L2. Sin embargo, el desafío que enfrenta esto es que el equipo de L2 necesita tener confianza en el trabajo de adopción de la propuesta para estar dispuesto a implementarla, especialmente para garantizar que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.

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

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 que se puede utilizar en L1 y en cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte funciones como L1SLOAD o REMOTESTATI.