El posible futuro del protocolo Ethereum (六): prosperidad
Escrito por: Vitalik Buterin
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 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 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 la economía de las tarifas de transacción, mejorar la escalabilidad mientras se reduce el riesgo.
Explorar la criptografía avanzada para que Ethereum mejore significativamente a largo plazo
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 expansión adicional. 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, la más notable es:
La separación entre código (ejecutable, pero no se puede leer desde EVM) y datos (legibles, pero no ejecutables)
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 continuarán existiendo y podrán ser creados, aunque eventualmente podrían ser descontinuados gradualmente (incluso podrían ser forzados a convertirse en código EOF). Los contratos nuevos se beneficiarán de las mejoras de eficiencia que trae el EOF------primero con un bytecode ligeramente reducido gracias a las características de subrutinas, y luego con nuevas funcionalidades específicas de EOF o reducción de costos de gas.
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 dirigidas a las 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 el uso de optimizaciones como la multiplicación de Montgomery.
Una idea más reciente es combinar EVM-MAX con las características de múltiples datos de una sola instrucción (SIMD), que como concepto de Ethereum ha existido durante mucho tiempo, propuesto por primera vez por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos los hash, STARKs de 32 bits y criptografía basada en rejillas. La combinación de EVM-MAX y SIMD hace que estas dos ampliaciones orientadas al rendimiento sean un emparejamiento natural.
El diseño general de un conjunto de EIP comenzará con el EIP-6690 y luego:
Permitir (i) cualquier número impar o (ii) cualquier potencia de 2 que no supere 2768 como módulo
Para cada código de operación EVM-MAX (suma, resta, multiplicación), agregar 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 de Python, el efecto de estos códigos de operación 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.
Se pueden agregar XOR, AND, OR, NOT y SHIFT (incluidos cíclicos y no cíclicos), al menos para potencias de 2 como módulo. Al mismo tiempo, agregar ISZERO (que empujará la salida a la pila principal de EVM), lo que será lo suficientemente potente como para implementar criptografía de curvas elípticas, criptografía de pequeños campos (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 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 han sido eliminadas temporalmente, pero hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura para EVM deberá llevarse a cabo sin EOF, aunque es posible, puede 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 que prioriza la mejora continua de Ethereum L1 debería incluir y construirse sobre EOF.
Una tarea importante que necesita 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, puede causar incompatibilidades y tener efectos adversos. Además, EVM-MAX y SIMD pueden reducir los costos 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 ejecutar las mismas tareas, lo que probablemente no afectará significativamente la eficiencia.
abstracción de cuentas
¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden validar 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 validación de cuentas fuera código EVM arbitrario. Esto puede habilitar una serie de aplicaciones:
Cambiar a criptografía resistente a la computación cuántica
Rotar claves antiguas (ampliamente considerado como una práctica de seguridad recomendada)
Monedero de múltiples firmas y monedero de recuperación social
Usar una clave para operaciones de bajo valor, usar 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. A continuación se presenta un resumen gráfico de estos objetivos:
MPC (cálculo multiparte) es una tecnología con 40 años de historia que se utiliza para dividir claves en múltiples partes y almacenarlas en varios dispositivos, utilizando técnicas criptográficas para generar firmas 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 conveniencia de proporcionar abstracción de cuentas para beneficiar a todos los usuarios (incluidos los usuarios de EOA), y tiene como objetivo 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 ofrece las "funciones de conveniencia" de la abstracción de cuentas a todos los usuarios, incluidas las cuentas EOA (cuentas de propiedad externa, es decir, cuentas controladas por firmas ECDSA) de hoy.
En el gráfico se puede ver que, aunque algunos desafíos (especialmente el desafío de «conveniencia») se pueden resolver mediante tecnologías progresivas como el cálculo multipartito o el EIP-7702, el principal objetivo de seguridad de la propuesta de abstracción de cuentas, presentada originalmente, solo se puede lograr 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 que esto no se ha logrado hasta ahora radica en su implementación segura, lo cual es 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 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 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 otras transacciones en el pool de memoria se vuelvan 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, 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 es 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 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 aplica un estricto límite 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) y no tenían energía adicional para manejar otras funciones. Por eso, 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:
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 del usuario.
Asegurar la necesidad de las propiedades de Ethereum: como la lista incluida que crea la garantía que necesita ser transferida a los usuarios abstractos de la cuenta.
Además, ERC-4337 también amplía dos funciones:
Agentes de pago (Paymasters): permiten 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. Por lo tanto, se introdujeron tratamientos especiales para garantizar la seguridad del mecanismo de agentes de pago.
Agregadores (Aggregators): soportan la función 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
Charla sobre la historia de la abstracción de cuentas:
ERC-4337：
EIP-7702：
Código de BLSWallet (usando la función de agregación):
EIP-7562 (abstracción de cuentas en el protocolo):
EIP-7701 (protocolo de abstracción de cuentas de escritura basado en EOF):
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
17 me gusta
Recompensa
17
5
Compartir
Comentar
0/400
TokenRationEater
· 07-22 23:46
Vitalik Buterin ya ha comenzado a soñar de nuevo, ¿verdad?
Ver originalesResponder0
AirdropBlackHole
· 07-22 00:12
Conocimiento caliente: all in Ether
Ver originalesResponder0
AirdropCollector
· 07-21 05:33
Vitalik Buterin todavía está trabajando en el protocolo
Ver originalesResponder0
SelfStaking
· 07-21 05:30
¡Vaya, V神 tiene una gran actitud! Si el análisis estático es difícil, pues lo es.
Ver originalesResponder0
CryptoTarotReader
· 07-21 05:23
¿Así de fácil se cambia el evm? Mejor bajar el gas~
El futuro próspero de Ethereum: mejoras en EVM, abstracción de cuentas y actualizaciones de protocolo
El posible futuro del protocolo Ethereum (六): prosperidad
Escrito por: Vitalik Buterin
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 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 expansión adicional. 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, la más notable es:
Los contratos antiguos continuarán existiendo y podrán ser creados, aunque eventualmente podrían ser descontinuados gradualmente (incluso podrían ser forzados a convertirse en código EOF). Los contratos nuevos se beneficiarán de las mejoras de eficiencia que trae el EOF------primero con un bytecode ligeramente reducido gracias a las características de subrutinas, y luego con nuevas funcionalidades específicas de EOF o reducción de costos de gas.
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 dirigidas a las 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 el uso de optimizaciones como la multiplicación de Montgomery.
Una idea más reciente es combinar EVM-MAX con las características de múltiples datos de una sola instrucción (SIMD), que como concepto de Ethereum ha existido durante mucho tiempo, propuesto por primera vez por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos los hash, STARKs de 32 bits y criptografía basada en rejillas. La combinación de EVM-MAX y SIMD hace que estas dos ampliaciones orientadas al rendimiento sean un emparejamiento natural.
El diseño general de un conjunto de EIP comenzará con el EIP-6690 y luego:
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.
Enlace de investigación existente
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 han sido eliminadas temporalmente, pero hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura para EVM deberá llevarse a cabo sin EOF, aunque es posible, puede 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 que prioriza la mejora continua de Ethereum L1 debería incluir y construirse sobre EOF.
Una tarea importante que necesita 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, puede causar incompatibilidades y tener efectos adversos. Además, EVM-MAX y SIMD pueden reducir los costos 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 ejecutar las mismas tareas, lo que probablemente no afectará significativamente la eficiencia.
abstracción de cuentas
¿Qué problema se resolvió?
Actualmente, las transacciones solo se pueden validar 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 validación de cuentas fuera código EVM arbitrario. 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. A continuación se presenta un resumen gráfico de estos objetivos:
MPC (cálculo multiparte) es una tecnología con 40 años de historia que se utiliza para dividir claves en múltiples partes y almacenarlas en varios dispositivos, utilizando técnicas criptográficas para generar firmas 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 conveniencia de proporcionar abstracción de cuentas para beneficiar a todos los usuarios (incluidos los usuarios de EOA), y tiene como objetivo 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 ofrece las "funciones de conveniencia" de la abstracción de cuentas a todos los usuarios, incluidas las cuentas EOA (cuentas de propiedad externa, es decir, cuentas controladas por firmas ECDSA) de hoy.
En el gráfico se puede ver que, aunque algunos desafíos (especialmente el desafío de «conveniencia») se pueden resolver mediante tecnologías progresivas como el cálculo multipartito o el EIP-7702, el principal objetivo de seguridad de la propuesta de abstracción de cuentas, presentada originalmente, solo se puede lograr 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 que esto no se ha logrado hasta ahora radica en su implementación segura, lo cual es 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 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 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 otras transacciones en el pool de memoria se vuelvan 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, 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 es 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 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 aplica un estricto límite 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) y no tenían energía adicional para manejar otras funciones. Por eso, 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:
Enlace de investigación existente
resto