- Tema
39k Popularidad
20k Popularidad
33k Popularidad
31k Popularidad
4k Popularidad
97k Popularidad
29k Popularidad
27k Popularidad
7k Popularidad
18k Popularidad
- Anclado
39k Popularidad
20k Popularidad
33k Popularidad
31k Popularidad
4k Popularidad
97k Popularidad
29k Popularidad
27k Popularidad
7k Popularidad
18k Popularidad
Dirección de evolución del protocolo Ethereum: optimización de EVM, abstracción de cuentas y renovación del mecanismo de tarifas
El posible futuro del protocolo Ethereum ( seis ): prosperidad
Algunas cosas son difíciles de clasificar en una sola categoría. 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 diversos temas de nicho, y ese es el significado de "prosperidad".
Prosperidad: objetivo clave
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 ampliaciones adicionales. Además, la eficiencia del EVM es baja, lo que hace difícil implementar muchas formas de criptografía avanzada, a menos que se apoye explícitamente a través de la precompilación.
¿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 notable:
Los contratos antiguos continuarán existiendo y podrán ser creados, aunque eventualmente podrían ser descontinuados 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 el EOF: primero a través de un bytecode ligeramente reducido gracias a las características de subrutina, y luego con nuevas funciones específicas del EOF o costos de gas reducidos.
Después de la introducción de EOF, las actualizaciones adicionales se vuelven más fáciles. Actualmente, 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 operaciones modulares 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 nueva es combinar EVM-MAX con la característica de múltiples datos de una sola instrucción (SIMD), ya que 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 rejillas, la combinación de EVM-MAX y SIMD hace que estas dos escalas orientadas al rendimiento se conviertan en una pareja natural.
Un diseño general de un conjunto de EIP comenzará con EIP-6690, luego:
python 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 manejará de manera paralela.
Trabajo restante y 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 se han eliminado funciones temporalmente— hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura de EVM deberá realizarse sin EOF, aunque se puede hacer, podría ser más difícil.
El principal compromiso del 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 del EVM, y la verificación de código estático 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 prioritaria para la mejora continua de Ethereum L1 debería incluir y basarse en EOF.
Una tarea importante que debe realizarse es implementar funciones similares a EVM-MAX junto con SIMD, y realizar pruebas de referencia sobre el consumo de gas de varias 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, podría causar incompatibilidades 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 el reemplazo de más precompilaciones por código EVM que puede realizar las mismas tareas, lo que probablemente no afectará significativamente la eficiencia.
abstracto de cuenta
¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden verificar de una manera: mediante la 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 sea cualquier código EVM. Esto puede habilitar una serie de aplicaciones:
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 externas (EOA). Toda la complejidad proviene de implementar esto de una manera que favorezca el mantenimiento de una red descentralizada y prevenga 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 grupo de memoria sean todas válidas, entonces una única transacción que invierte el valor de S podría hacer que todas las demás transacciones en el grupo de memoria sean inválidas. Esto permite a un atacante enviar transacciones basura al grupo de memoria a un costo muy bajo, bloqueando así los recursos de los nodos de la red.
Después de años de esfuerzo, con el objetivo de ampliar 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 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 fase de verificación solo involucre su propia cuenta y no lea variables de entorno. Esto puede prevenir ataques de fallos múltiples. Además, se implementan 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 se centraban en la fusión (Merge) y no tenían energía adicional para manejar otras funciones. 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 hemos dado cuenta de la necesidad de escribir al menos parte de su contenido en el protocolo.
Las dos razones clave son las siguientes:
Además, ERC-4337 también amplía dos funciones:
![Vitalik sobre el posible futuro de Ethereum (Seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.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 que ha ganado popularidad 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 esa parte de 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:
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, 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 reemplazar la verificación ECDSA por la ejecución de código EVM que requiera un tiempo similar.
Sin embargo, a medida que pasa el tiempo, necesitamos flexibilizar estos límites, ya que permitir que las aplicaciones de protección de la privacidad funcionen sin un intermediario, 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 deban ser extremadamente simplistas.
El principal compromiso 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", siendo el enfoque ideal posiblemente algún tipo de método híbrido. Un método híbrido es escribir más rápidamente algunos casos de uso y dejar más tiempo para explorar otros casos de uso. Otro método sería implementar 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 plena confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementar, 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 L2 dedicado, pero puede ser utilizada 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 también necesita que la implementación de abstracción de cuentas en L2 soporte estas operaciones.
¿Cómo interactúa con otras partes de la hoja de ruta?
La lista de inclusión debe soportar transacciones de abstracción de cuenta. En la práctica, la necesidad de una lista de inclusión es en realidad muy similar a la necesidad de un pool de memoria descentralizado, aunque la flexibilidad es un poco mayor para la lista de inclusión. Además, la implementación de la abstracción de cuenta debe coordinarse entre L1 y L2 en la medida de lo posible. Si en el futuro esperamos que la mayoría de los usuarios utilicen Rollup de almacenamiento de claves, el diseño de la abstracción de cuenta debe basarse en esto.
![Vitalik sobre el posible futuro de Ethereum（