Futuro posible del protocolo Ethereum (seis): prosperidad

El diseño del protocolo de Ethereum tiene muchos "detalles" 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 la 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 al mismo tiempo reducir el riesgo
• Explorar la criptografía avanzada para mejorar significativamente Ethereum a largo plazo.

Mejora del EVM

¿Qué problema 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 futuras expansiones. 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 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, siendo la más destacada:

• El código ( es ejecutable, pero no se puede leer ) desde 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 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 ser creados, aunque eventualmente podrían ser eliminados gradualmente los contratos antiguos ( e incluso podrían ser convertidos forzosamente a código EOF ). Los contratos nuevos se beneficiarán de las mejoras de eficiencia que trae EOF: primero, con un bytecode ligeramente reducido gracias a las características de subrutina, y luego con nuevas funciones específicas de EOF o costos de gas reducidos.

Tras la introducción de EOF, las actualizaciones posteriores se vuelven más fáciles. Actualmente, el más desarrollado 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 utilizar 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, 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 redes. La combinación de EVM-MAX y SIMD hace que estas dos extensiones orientadas al rendimiento se conviertan en una pareja natural.

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

• Permitir (i) cualquier número impar o (ii) cualquier potencia de 2 que sea como máximo 2768 como módulo
• Para cada opcode EVM-MAX ( suma, resta, multiplicación ), añadir una versión que ya no use 3 constantes inmediatas x, y, z, sino que use 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 práctica, esto se procesará de manera paralela.

• Posiblemente se añadirán XOR, AND, OR, NOT y SHIFT(, incluyendo ciclos y no ciclos), al menos para números módulo potencias de 2. Al mismo tiempo, agregar 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 rejillas. Otras actualizaciones de EVM también pueden implementarse, pero hasta ahora han recibido menos atención.

enlace de investigación existente

• EOF:
• EVM-MAX:
• SIMD:

El trabajo restante y las consideraciones

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 se han eliminado funciones de forma temporal— hacerlo presentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura a EVM deberá realizarse sin EOF; aunque es posible, podría ser más difícil.

El principal compromiso de EVM radica en la complejidad de L1 y la complejidad de la infraestructura. EOF es una gran cantidad de código que necesita ser añadido a la implementación de 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 de EVM y obtener otros beneficios. Se puede decir que la hoja de ruta para priorizar la mejora continua de Ethereum L1 debería incluirse y construirse sobre EOF.

Una tarea importante que se necesita realizar es implementar funciones similares a EVM-MAX más SIMD, y llevar a cabo 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, puede haber incompatibilidades que traigan efectos negativos. Además, EVM-MAX y SIMD pueden reducir el costo de gas de muchos sistemas de prueba, haciendo que L2 sea más eficiente. También facilita la sustitución de más precompilados por código EVM que puede ejecutar las mismas tareas, lo que podría no afectar significativamente la eficiencia.

Abstracción de cuentas

¿Qué problema resolvió?

Actualmente, las transacciones solo se pueden verificar de una manera: firma ECDSA. Inicialmente, la abstracción de cuentas estaba destinada a 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 post-cuántica
• Rotar la clave antigua ( se considera ampliamente una práctica de seguridad recomendada )
• Billetera multifirma y billetera 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 expandido 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.

MPC( computación multipartita ) es una tecnología con 40 años de historia, utilizada para dividir claves en múltiples partes y almacenarlas en varios dispositivos, generando firmas mediante técnicas criptográficas, sin necesidad de combinar directamente estas partes de clave.

EIP-7702 es una propuesta que se planea introducir en la próxima bifurcación dura. EIP-7702 es el resultado de una creciente conciencia sobre la necesidad de proporcionar la conveniencia de la abstracción de cuentas para beneficiar a todos los usuarios (, incluidos los usuarios de EOA ). Su objetivo es mejorar la experiencia de todos los usuarios a corto plazo y evitar la división en dos ecosistemas.

Este trabajo comenzó con el EIP-3074 y finalmente se formó el EIP-7702. El EIP-7702 proporciona la "funcionalidad conveniente" de la abstracción de cuentas a todos los usuarios, incluidos los EOA( de hoy, que son cuentas externas controladas por firmas ECDSA, es decir, cuentas ).

Aunque algunos desafíos (, especialmente el desafío de "conveniencia" ), pueden resolverse mediante tecnologías progresivas como el cálculo multipartito o EIP-7702, el objetivo principal de seguridad del que se propuso originalmente la propuesta de abstracción de cuentas solo puede lograrse retrocediendo y resolviendo el problema original: permitir que el código del contrato inteligente controle la verificación de transacciones. La razón por la cual esto aún no se ha logrado radica en la implementación segura, que representa un desafío.

¿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 EOA. Toda la complejidad proviene de implementar esto 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 funciones de verificación de cuentas que dependen de un único valor S, y el valor actual S hace que todas las transacciones en el pool de memoria 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 pool de memoria sean inválidas. Esto permite a un atacante enviar transacciones basura al pool de memoria 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 funcionalidades 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 consiste en dividir 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 involucre únicamente su propia cuenta y no lea variables del entorno. Esto puede prevenir ataques de fallo múltiple. Además, se imponen estrictos límites de gas en el paso 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 estaban enfocados en la fusión (Merge), sin energía adicional para manejar otras funcionalidades. Esta es la razón por la que ERC-4337 utiliza un objeto llamado operación de usuario, en lugar de transacciones convencionales. Sin embargo, recientemente nos dimos cuenta de la necesidad de escribir al menos parte de esto en el protocolo.

Las dos razones clave son las siguientes:

1. EntryPoint como la ineficiencia inherente del contrato: cada paquete tiene un costo fijo de aproximadamente 100,000 gas, además de miles de gas adicionales por cada operación de usuario.
2. Asegurar la necesidad de las propiedades de Ethereum: como la lista de inclusión creada para garantizar la transferencia a usuarios de cuentas abstractas.

Además, ERC-4337 también amplió 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 verificación solo se puede acceder a la cuenta del remitente en sí, por lo tanto, se introdujo un tratamiento especial para garantizar la seguridad del mecanismo de agentes de pago.
• Aggregators (: 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.

) enlace de investigación existente

• Discurso sobre la historia de la abstracción de cuentas:
• ERC-4337:
• EIP-7702:
• El código BLSWallet ### utiliza la función de agregación (:
• EIP-7562) escritura de la cuenta abstracta del protocolo (:
• EIP-7701) cuenta de abstracción de escritura protocolo basado en EOF (:

) El trabajo restante y las consideraciones

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 de escritura, que ha ganado popularidad recientemente, es el EIP-7701. Esta propuesta implementa la abstracción de cuentas sobre el EOF.