- Tema
88k Popularidad
41k Popularidad
14k Popularidad
4k Popularidad
5k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
- Anclado
88k Popularidad
41k Popularidad
14k Popularidad
4k Popularidad
5k Popularidad
29k Popularidad
16k Popularidad
22k Popularidad
13k Popularidad
3k Popularidad
El camino hacia la prosperidad del protocolo Ethereum: mejoras en EVM, abstracción de cuentas y Gas multidimensional
Futuro posible del protocolo Ethereum (VI): Capítulo de prosperidad
Hay algunas cosas que 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 implica diferentes tipos de mejoras EVM, mientras que el resto se compone de 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 dificulta la creación de implementaciones eficientes, la verificación formal del código y la realización de futuras ampliaciones. 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 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 de EVM, con muchas características únicas, la más notable es:
Los contratos antiguos seguirán existiendo y se podrán crear, aunque eventualmente podrían ser gradualmente descontinuados (incluso podrían ser forzados a convertirse en código EOF). Los contratos nuevos se beneficiarán de la mejora de eficiencia que trae el EOF.
Tras 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 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 características de múltiples datos de una sola instrucción (SIMD). SIMD, como un concepto de Ethereum, ha existido durante mucho tiempo, siendo propuesto originalmente por Greg Colvin en EIP-616. SIMD puede utilizarse para acelerar muchas formas de criptografía, incluidos 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 expansiones orientadas al rendimiento sean una pareja natural.
Enlace de investigación existente
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, hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier futura actualización de EVM deberá realizarse sin EOF, aunque es posible, podría ser más difícil.
La principal compensación 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 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 de EVM y otros beneficios. Se puede decir que la hoja de ruta para la mejora continua de Ethereum L1 debería incluirse y basarse en 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 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 ajustan de manera sincronizada, 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 el reemplazo de más precompilados con código EVM que puede realizar la misma tarea, lo que podría no afectar significativamente la eficiencia.
abstracción de cuentas
¿Qué problema se resolvió?
Actualmente, la transacción solo se puede validar de una manera: firma ECDSA. Inicialmente, la abstracción de cuentas tenía como objetivo ir más allá de esto, permitiendo que la lógica de validación de la cuenta sea cualquier código EVM. Esto puede habilitar una serie de aplicaciones:
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 tiene ETH pero posee algunos ERC20 puede pagar el gas con ERC20.
¿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 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.
Después de años de esfuerzo, con el objetivo de expandir las funcionalidades mientras se limita el riesgo de denegación de servicio (DoS), finalmente se llegó a la solución para implementar 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 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 falla múltiple. Además, se imponen restricciones estrictas de gas en el paso de verificación.
Enlace de investigación existente
Trabajo restante y compensaciones
Actualmente, el principal problema a resolver es cómo integrar 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 establece esa parte de código, este código se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.
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 sería escribir más rápido algunos casos de uso y reservar más tiempo para explorar otros casos de uso. Otra opción es desplegar primero una versión de abstracción de cuentas más ambiciosa en L2.
¿Cómo interactúa con otras partes del mapa de ruta?
La lista de inclusión necesita soportar transacciones de abstracción de cuentas. En la práctica, la necesidad de listas de inclusión es en realidad muy similar a la necesidad de una piscina de memoria descentralizada, aunque para las listas de inclusión hay un poco más de flexibilidad. 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.
EIP-1559 mejora
¿Qué problema resuelve?
EIP-1559 se activó en 2021 en Ethereum, 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:
La fórmula para blobs (EIP-4844) está diseñada específicamente para abordar el primer problema y, en general, es más sencilla. Sin embargo, EIP-1559 en sí mismo y EIP-4844 no intentan resolver el segundo problema.
Además, existen otras debilidades en la fijación de precios de recursos de Ethereum que no están relacionadas con EIP-1559, pero que pueden resolverse mediante ajustes a EIP-1559. Uno de los problemas principales es la diferencia entre la situación promedio y la peor situación: el precio de los recursos en Ethereum debe establecerse para poder manejar la peor situación, es decir, el consumo total de gas de un bloque ocupa un recurso, pero el uso promedio real está muy por debajo de esto, lo que conduce a la ineficiencia.
¿Qué es el Gas multidimensional y cómo funciona?
La solución a estos problemas de ineficiencia es el Gas multidimensional: establecer diferentes precios y límites para diferentes recursos. Este concepto es técnicamente independiente de EIP-1559, pero la existencia de EIP-1559 facilita la implementación de esta solución. Sin EIP-1559, empaquetar de manera óptima un bloque que contenga múltiples restricciones de recursos sería un complejo problema de mochila multidimensional. Con EIP-1559, la mayoría de los bloques no alcanzan la carga máxima en ningún recurso, por lo que un algoritmo simple como "aceptar cualquier transacción que pague una tarifa suficiente" es suficiente.
Actualmente ya tenemos Gas multidimensional para la ejecución y los bloques de datos; en principio, podemos expandirlo a más dimensiones: como calldata (datos de transacción), lectura/escritura de estado y expansión del tamaño del estado.
EIP-7706 introduce una nueva dimensión de gas, específicamente para calldata. Al mismo tiempo, simplifica el mecanismo de Gas multidimensional al unificar tres tipos de gas en un marco (estilo EIP-4844), lo que también resuelve las deficiencias matemáticas de EIP-1559. EIP-7623 es una solución más precisa que aborda los problemas de recursos en situaciones promedio y peores, limitando de manera más estricta el máximo de calldata sin introducir toda una nueva dimensión.
Enlace de investigación existente