Futuro posible del protocolo Ethereum ( seis ): prosperidad
Escrito por: Vitalik Buterin
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 varios temas de nicho, y esa es la importancia de la "prosperidad".
Prosperidad: objetivo clave
Transformar 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 tarifas de transacción, mejorar la escalabilidad y reducir el riesgo al mismo tiempo
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 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 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 notable:
El código ( se puede ejecutar, pero no se puede leer ) desde el 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 ya no puede observar la información relacionada con el combustible.
Se ha añadido un nuevo mecanismo de rutina de subtipo explícito
Prosperidad: mejora de EVM ( continuación )
Los contratos antiguos seguirán existiendo y podrán crearse, aunque eventualmente podrían ser gradualmente descontinuados, y los contratos antiguos ( incluso podrían ser forzados a convertirse en código EOF ). Los contratos nuevos se beneficiarán de la mejora de eficiencia que trae EOF------primero con el bytecode ligeramente reducido gracias a la característica de subrutinas, y luego con nuevas funciones específicas de EOF o costos de gas reducidos.
Después de la introducción de EOF, las actualizaciones posteriores 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 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 retículos, la combinación de EVM-MAX y SIMD hace que estas dos ampliaciones orientadas al rendimiento sean una pareja natural.
Un diseño aproximado de un conjunto de EIP comenzará con EIP-6690, 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 ), añade una versión que ya no usa 3 literales x, y, z, sino que utiliza 7 literales: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. En el código 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 implementación real, esto se manejará de manera paralela.
Puede agregar XOR, AND, OR, NOT y SHIFT( incluyendo ciclos y no ciclos), al menos para potencias de 2 módulo. Al mismo tiempo, agregar ISZERO( enviará 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 retículas. Otras actualizaciones de EVM también pueden ser implementadas, pero hasta ahora han tenido menos atención.
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, algunas funciones han sido eliminadas temporalmente, pero hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura del EVM debe llevarse a cabo sin EOF; aunque es posible, puede resultar más difícil.
El principal compromiso del EVM radica en la complejidad de L1 y la complejidad de la infraestructura. El 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 para priorizar la mejora continua de Ethereum L1 debería incluir y construirse sobre el EOF.
Una tarea importante que se necesita realizar es implementar funciones similares a EVM-MAX + 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 provocar incompatibilidades y tener efectos negativos. Además, EVM-MAX y SIMD pueden reducir considerablemente el costo de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita reemplazar más precompilados con 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, la validación de las transacciones solo se puede realizar 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 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 )
Monedero de múltiples firmas y monedero 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 también se ha ampliado para incluir una gran cantidad de "objetivos de conveniencia", por ejemplo, una cuenta que no tiene ETH pero que posee algunos ERC20 puede usar ERC20 para pagar el gas.
MPC( el cálculo multipartito) es una tecnología con 40 años de historia, utilizada para dividir una clave 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 EIP-3074 y finalmente se convirtió en EIP-7702. EIP-7702 proporciona la "funcionalidad conveniente" de la abstracción de cuentas a todos los usuarios, incluidos los EOA( de hoy, es decir, cuentas externas controladas por firmas ECDSA).
En el gráfico se puede ver que, aunque algunos desafíos (, especialmente el desafío de la "conveniencia" ), pueden ser resueltos mediante tecnologías progresivas como la computación multipartita o EIP-7702, el principal objetivo de seguridad del propuesta de abstracción de cuentas, que fue planteada inicialmente, solo puede lograrse retrocediendo y resolviendo el problema original: permitir que el código de los contratos inteligentes controle la validación de transacciones. La razón por la cual esto aún no se ha logrado se debe a la 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 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 una función de validación de 1000 cuentas que depende de un único valor S, y el valor S actual hace que 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 que un atacante envíe 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 las funcionalidades mientras se limita el riesgo de denegación de servicio ( DoS ), finalmente se llegó a una solución para lograr "abstracto 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, las operaciones del usuario solo se aceptan cuando la etapa de verificación solo involucra su propia cuenta y no lee variables de entorno. Esto puede prevenir ataques de fallos múltiples. Además, también se aplica un estricto límite 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 funciones. Esta es la razón por la que ERC-4337 utiliza un objeto llamado operación del 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 los listados que crean la garantía que debe transferirse a los usuarios abstractos de la cuenta.
Además, ERC-4337 también amplía 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, por lo que se introduce un tratamiento especial para garantizar la seguridad del mecanismo de agentes de pago.
Agregadores(: Soporte para 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.
![Vitalik sobre el posible futuro de Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Trabajo restante y compensaciones
Actualmente, el principal desafío 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 ha establecido dicha sección de código, este código se ejecutará durante el paso de verificación de las transacciones provenientes de esa cuenta.
El encanto de este método radica en que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas locales:
Incorporar EIP-4337 como parte del protocolo
Un nuevo tipo de EOA, cuyo algoritmo de firma es la ejecución de código EVM.
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, e incluso el límite de gas establecido en las etapas iniciales 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 se reemplaza la verificación ECDSA por la ejecución de código EVM que requiere un tiempo similar.
Sin embargo, con el tiempo, necesitamos flexibilizar estos límites, ya que permitir aplicaciones de protección de la privacidad sin intermediarios...
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
6
Compartir
Comentar
0/400
LuckyBlindCat
· 07-20 01:39
Vitalik Buterin finalmente no pudo quedarse quieto.
El futuro del protocolo Ethereum: nuevas oportunidades traídas por la actualización de EVM y la abstracción de cuentas
Futuro posible del protocolo Ethereum ( seis ): prosperidad
Escrito por: Vitalik Buterin
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 varios temas de nicho, y esa es la importancia de la "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 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 notable:
Prosperidad: mejora de EVM ( continuación )
Los contratos antiguos seguirán existiendo y podrán crearse, aunque eventualmente podrían ser gradualmente descontinuados, y los contratos antiguos ( incluso podrían ser forzados a convertirse en código EOF ). Los contratos nuevos se beneficiarán de la mejora de eficiencia que trae EOF------primero con el bytecode ligeramente reducido gracias a la característica de subrutinas, y luego con nuevas funciones específicas de EOF o costos de gas reducidos.
Después de la introducción de EOF, las actualizaciones posteriores 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 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 retículos, la combinación de EVM-MAX y SIMD hace que estas dos ampliaciones orientadas al rendimiento sean una pareja natural.
Un diseño aproximado de un conjunto de EIP comenzará con EIP-6690, 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 implementación real, 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, algunas funciones han sido eliminadas temporalmente, pero hacerlo enfrentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura del EVM debe llevarse a cabo sin EOF; aunque es posible, puede resultar más difícil.
El principal compromiso del EVM radica en la complejidad de L1 y la complejidad de la infraestructura. El 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 para priorizar la mejora continua de Ethereum L1 debería incluir y construirse sobre el EOF.
Una tarea importante que se necesita realizar es implementar funciones similares a EVM-MAX + 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 provocar incompatibilidades y tener efectos negativos. Además, EVM-MAX y SIMD pueden reducir considerablemente el costo de gas de muchos sistemas de prueba, lo que hace que L2 sea más eficiente. También facilita reemplazar más precompilados con 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, la validación de las transacciones solo se puede realizar 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 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 también se ha ampliado para incluir una gran cantidad de "objetivos de conveniencia", por ejemplo, una cuenta que no tiene ETH pero que posee algunos ERC20 puede usar ERC20 para pagar el gas.
MPC( el cálculo multipartito) es una tecnología con 40 años de historia, utilizada para dividir una clave 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 EIP-3074 y finalmente se convirtió en EIP-7702. EIP-7702 proporciona la "funcionalidad conveniente" de la abstracción de cuentas a todos los usuarios, incluidos los EOA( de hoy, es decir, cuentas externas controladas por firmas ECDSA).
En el gráfico se puede ver que, aunque algunos desafíos (, especialmente el desafío de la "conveniencia" ), pueden ser resueltos mediante tecnologías progresivas como la computación multipartita o EIP-7702, el principal objetivo de seguridad del propuesta de abstracción de cuentas, que fue planteada inicialmente, solo puede lograrse retrocediendo y resolviendo el problema original: permitir que el código de los contratos inteligentes controle la validación de transacciones. La razón por la cual esto aún no se ha logrado se debe a la 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 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 una función de validación de 1000 cuentas que depende de un único valor S, y el valor S actual hace que 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 que un atacante envíe 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 las funcionalidades mientras se limita el riesgo de denegación de servicio ( DoS ), finalmente se llegó a una solución para lograr "abstracto 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, las operaciones del usuario solo se aceptan cuando la etapa de verificación solo involucra su propia cuenta y no lee variables de entorno. Esto puede prevenir ataques de fallos múltiples. Además, también se aplica un estricto límite 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 funciones. Esta es la razón por la que ERC-4337 utiliza un objeto llamado operación del 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 (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# Trabajo restante y compensaciones
Actualmente, el principal desafío 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 ha establecido dicha sección de código, este código se ejecutará durante el paso de verificación de las transacciones provenientes de esa cuenta.
El encanto de este método 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, e incluso el límite de gas establecido en las etapas iniciales 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 se reemplaza la verificación ECDSA por la ejecución de código EVM que requiere un tiempo similar.
Sin embargo, con el tiempo, necesitamos flexibilizar estos límites, ya que permitir aplicaciones de protección de la privacidad sin intermediarios...