- Tema
3k Popularidad
90k Popularidad
14k Popularidad
5k Popularidad
30k Popularidad
16k Popularidad
23k Popularidad
14k Popularidad
3k Popularidad
13k Popularidad
- Anclado
3k Popularidad
90k Popularidad
14k Popularidad
5k Popularidad
30k Popularidad
16k Popularidad
23k Popularidad
14k Popularidad
3k Popularidad
13k Popularidad
El camino hacia la prosperidad de Ethereum: actualización de EVM, abstracción de cuentas y optimización de precios de recursos
Posibles direcciones futuras del protocolo Ethereum: capítulo de prosperidad
En el protocolo de Ethereum, hay 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
mejora de EVM
¿Qué problema se resolvió?
Actualmente, el EVM es difícil de analizar estáticamente, lo que complica 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 hace difícil implementar 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 de código EVM, con muchas características únicas, siendo la más notable:
Los contratos antiguos seguirán existiendo y se podrán crear, aunque eventualmente podrían ser gradualmente descontinuados, y los contratos antiguos ( incluso podrían ser forzados a convertirse en código EOF ). Los nuevos contratos se beneficiarán de las mejoras de eficiencia que trae EOF: primero, mediante un bytecode ligeramente reducido gracias a las características de subrutinas, y luego con nuevas funcionalidades específicas de EOF o costos de gas reducidos.
Después de introducir 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 operaciones modulares y las coloca en un nuevo espacio de memoria al 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 en Ethereum, ha existido durante mucho tiempo, siendo propuesto por primera vez en el EIP-616 de Greg Colvin. 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 sean una pareja natural.
Enlace de investigación existente
El trabajo restante y las consideraciones
Actualmente, se planea incluir EOF en la próxima bifurcación dura. Aunque siempre es posible eliminarlo en el último momento, funciones han sido eliminadas temporalmente en bifurcaciones duras anteriores, hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura al EVM tendría que llevarse a cabo sin EOF, lo que 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. EOF es una gran cantidad de código que necesita ser agregado 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 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 necesita hacerse es implementar funciones similares a EVM-MAX y SIMD, y realizar pruebas de referencia sobre el consumo de gas de varias operaciones criptográficas.
¿Cómo interactuar con otras partes del mapa 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, esto podría causar incompatibilidades y tener efectos adversos. Además, EVM-MAX y SIMD pueden reducir los costos 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 realizar las mismas tareas, lo que podría no afectar significativamente la eficiencia.
abstracción de cuentas
¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden verificar de una manera: a través de firmas 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:
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", como por ejemplo, una cuenta que no tiene ETH pero posee algunos ERC20, puede utilizar 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 EOA. Toda la complejidad proviene de implementar esto de una manera que sea amigable para mantener redes descentralizadas y prevenir ataques de denegación de servicio.
Un desafío clave típico es el problema de múltiples fallos:
Si hay una función de validación de 1000 cuentas que depende de un único valor S, y el valor S actual hace que todas 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 que un atacante envíe transacciones basura al pool 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 expandir funcionalidad mientras se limita el riesgo de denegación de servicio (DoS), se llegó finalmente a la solución para lograr "abstracción ideal de cuentas": ERC-4337.
El funcionamiento de ERC-4337 divide el procesamiento de las operaciones del usuario en dos fases: verificación y ejecución. Toda la verificación se procesa primero, y toda la ejecución se procesa después. En el grupo de memoria, solo se aceptarán las operaciones del usuario cuya fase de verificación solo involucre su propia cuenta y no lea las variables del entorno. Esto puede prevenir ataques de doble gasto. Además, se aplica una estricta limitación de gas a 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 centraban en la fusión (Merge), sin energía adicional para manejar otras funciones. Es por eso 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 amplió dos funciones:
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
)# Enlace de investigación existente
)# Trabajo restante y 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 que ha ganado popularidad recientemente es el EIP-7701, que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una sección de código separada para la verificación; si la cuenta establece esta sección de código, este 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 validación --no se permite el acceso al estado externo, incluso los límites de gas establecidos al principio son tan bajos que son ineficaces para aplicaciones de resistencia cuántica o protección de la privacidad-- entonces la seguridad de este enfoque es muy clara: simplemente sustituir la verificación ECDSA por la ejecución de código EVM que requiere 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 intermediarios, así como la resistencia cuántica, son muy importantes. Para ello, necesitamos encontrar maneras 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 compensación parece ser "escribir rápidamente una solución que satisfaga a menos personas" frente a "esperar más tiempo, posiblemente obteniendo una solución más ideal", siendo el enfoque ideal algún tipo de método híbrido. Un método híbrido es escribir más rápido algunos casos de uso y dejar más tiempo para explorar otros casos de uso. Otro enfoque es implementar primero una versión de abstracción de cuentas más ambiciosa en L2. Sin embargo, el desafío al que se enfrenta es que el equipo de L2 necesita tener plena confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para asegurar que L1 y/o otros L2 en el futuro puedan adoptar soluciones compatibles.
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 ser utilizada en L1 y cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte opcodes como L1SLOAD o REMOTESTATICCALL, pero esto también requiere 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 necesita soportar transacciones de abstracción de cuentas. En la práctica, la necesidad de la lista de inclusión es 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 cuentas debería coordinarse tanto como sea posible entre L1 y L2. 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 cuentas debería basarse en esto.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge]###https://img-cdn.gateio.im/webp-social/moments-ec1638a809393a6ed42724fb08f534da.webp(
) mejora EIP-1559
¿Qué problema resuelve?
EIP-1559 se activó en Ethereum en 2021, mejorando significativamente el tiempo promedio de inclusión de bloques.
Sin embargo, la implementación actual de EIP-1559 no es perfecta en varios aspectos: