Futuro posible del protocolo Ethereum (VI): Prosperidad
Hay cosas que son difíciles de clasificar. En el diseño del protocolo de Ethereum, muchos "detalles" son cruciales para el éxito de Ethereum. 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 verdadera esencia 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 tarifas de transacción, aumentar la escalabilidad y al mismo tiempo reducir el riesgo
Explorar la criptografía avanzada para mejorar significativamente Ethereum 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 ampliación adicional. Además, la eficiencia del EVM es baja, y es difícil implementar muchas criptografías avanzadas, 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 la nueva versión de código de EVM, con muchas características únicas, siendo la más destacada:
El código ( es ejecutable, pero no se puede leer desde EVM. Los datos ) se pueden leer, pero no se pueden ejecutar la separación de (.
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 subrutinas explícitas.
Los contratos antiguos seguirán existiendo y podrán ser creados, aunque eventualmente podrían ser gradualmente descontinuados los contratos antiguos ) e incluso podrían ser forzados a convertirse en código EOF (. Los contratos nuevos se beneficiarán de las mejoras de eficiencia que trae EOF, primero con un 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 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 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 un concepto de Ethereum, ha existido durante mucho tiempo, siendo propuesto inicialmente por Greg Colvin en el EIP-616. SIMD se puede usar 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 escalaciones orientadas al rendimiento sean una pareja natural.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Un diseño general de un EIP combinado comenzará con EIP-6690 y luego:
Permitir )i( cualquier número impar o )ii( cualquier potencia de 2 que sea como máximo 2768 como módulo
Para cada código de operación EVM-MAX ) suma, resta, multiplicación (, se debe agregar una versión que ya no use 3 literales x, y, z, sino que use 7 literales: 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:
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 implementación real, esto se procesará de manera paralela.
Posiblemente añadir XOR, AND, OR, NOT y SHIFT) incluyendo ciclos y no ciclos(, al menos para potencias de 2 módulo. Al mismo tiempo, añadir ISZERO) empujará la salida a la pila principal de EVM(, lo que será lo suficientemente poderoso 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 reticulados. Otras actualizaciones de EVM también pueden ser implementadas, pero hasta ahora han tenido menor atención.
)# El trabajo restante y las compensaciones
Actualmente, EOF está planeado para ser incluido en la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento —en bifurcaciones duras anteriores, algunas funcionalidades han sido eliminadas temporalmente— hacerlo presentará 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.
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 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 basarse en EOF.
Una tarea importante que debe 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 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 haber incompatibilidades que traigan efectos adversos. Además, EVM-MAX y SIMD pueden reducir significativamente los costos de gas de muchos sistemas de prueba, haciendo que L2 sea más eficiente. También facilita reemplazar más precompilados por código EVM que puede realizar las mismas tareas, lo que probablemente no afectará drásticamente la eficiencia.
abstracción 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 tenía como objetivo superar esto, permitiendo que la lógica de verificación de cuentas sea cualquier código EVM. Esto puede habilitar una serie de aplicaciones:
Cambiar a criptografía post-cuántica
Rotar las claves antiguas ### se considera ampliamente una práctica de seguridad recomendada (
Billetera multifirma y billetera de recuperación social
Utiliza una clave para operaciones de bajo valor, utiliza 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 posee algunos ERC20 puede pagar el gas usando ERC20.
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, aprovechando técnicas criptográficas para generar firmas sin necesidad de combinar directamente estas partes de clave.
![Vitalik sobre el posible futuro de Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
EIP-7702 es una propuesta que se planea introducir en la próxima bifurcación dura. EIP-7702 es el resultado de un reconocimiento creciente de la necesidad de proporcionar comodidad de abstracción de cuentas para beneficiar a todos los usuarios ), incluidos los usuarios de EOA (, y está diseñado para 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 las "funciones de conveniencia" de la abstracción de cuentas a todos los usuarios, incluidos los EOA) de hoy, es decir, las cuentas externas controladas por firmas ECDSA (.
Aunque algunos desafíos ), especialmente el desafío de "conveniencia" (, pueden ser abordados mediante tecnologías progresivas como el cálculo multipartito o EIP-7702, el principal objetivo de seguridad del que se propuso inicialmente el concepto de abstracción de cuentas solo puede lograrse retrocediendo y resolviendo el problema original: permitir que el código del contrato inteligente 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 lograr 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 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 todas 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 se vuelvan inválidas. Esto permite a un atacante enviar transacciones basura al pool de memoria a un costo muy bajo, lo que bloquea los recursos de los nodos de la red.
Después de años de esfuerzo, con el objetivo de ampliar las funcionalidades mientras se limita el riesgo de denegación de servicio ###DoS(, finalmente se llegó a la solución para lograr "abstracción de cuentas ideal": 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. Toda la verificación se procesa primero, y toda la ejecución se procesa después. 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 del entorno. Esto puede prevenir ataques de doble gasto. Además, se imponen estrictos límites de gas en el paso de verificación.
ERC-4337 fue diseñado como un estándar de protocolo adicional )ERC(, ya que en ese momento los desarrolladores de clientes de Ethereum se enfocaban 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 de usuario.
Asegurar la necesidad de las propiedades de Ethereum: como la lista incluida que crea la garantía que necesita ser transferida a la cuenta del usuario abstracto.
Además, ERC-4337 también ha ampliado dos funciones:
Agentes de pago ) Paymasters (: permite que una cuenta pague 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 introducen tratamientos especiales para garantizar la seguridad del mecanismo de agentes de pago.
Agregadores): admite 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.
(# El trabajo restante y las 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 de escritura en protocolo que ha ganado popularidad recientemente es el EIP-7701, el cual implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una sección de código separada para la validación; si la cuenta ha configurado esa sección de código, entonces dicho código se ejecutará en el paso de validación de las transacciones provenientes de esa cuenta.
El atractivo de este método radica en que muestra claramente dos perspectivas equivalentes de la abstracción de cuentas locales:
Incluir EIP-4337 como parte del protocolo
Un nuevo tipo de EOA, donde el algoritmo de firma es la ejecución del código EVM
Si comenzamos estableciendo límites estrictos sobre la complejidad del código ejecutable durante el período de validación—sin permitir el acceso al estado externo, e incluso con un límite de gas establecido en etapas iniciales 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 de 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 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 sean extremadamente simplistas.
La principal compensación parece ser "escribir rápidamente una solución que satisface a menos personas" frente a "esperar más tiempo
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.
18 me gusta
Recompensa
18
5
Republicar
Compartir
Comentar
0/400
LonelyAnchorman
· Hace48m
¿Cuándo podrá ser más fluido este trasto llamado EVM...
Ver originalesResponder0
GateUser-2fce706c
· hace14h
Aprovechando la oportunidad de mejora de EVM para establecer un gran esquema... ya había anticipado esta dirección de desarrollo.
Ver originalesResponder0
PoetryOnChain
· hace14h
¿Va a haber un límite? Al final, el Señor V finalmente lo entendió.
Perspectivas futuras del protocolo Ethereum: mejoras en EVM y la abstracción de cuentas lideran la prosperidad
Futuro posible del protocolo Ethereum (VI): Prosperidad
Hay cosas que son difíciles de clasificar. En el diseño del protocolo de Ethereum, muchos "detalles" son cruciales para el éxito de Ethereum. 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 verdadera esencia 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 ampliación adicional. Además, la eficiencia del EVM es baja, y es difícil implementar muchas criptografías avanzadas, 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 la nueva versión de código de EVM, con muchas características únicas, siendo la más destacada:
Los contratos antiguos seguirán existiendo y podrán ser creados, aunque eventualmente podrían ser gradualmente descontinuados los contratos antiguos ) e incluso podrían ser forzados a convertirse en código EOF (. Los contratos nuevos se beneficiarán de las mejoras de eficiencia que trae EOF, primero con un 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 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 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 un concepto de Ethereum, ha existido durante mucho tiempo, siendo propuesto inicialmente por Greg Colvin en el EIP-616. SIMD se puede usar 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 escalaciones orientadas al rendimiento sean una pareja natural.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-e607936b4195e92945aa6ebd5f969276.webp(
Un diseño general de un EIP combinado comenzará con EIP-6690 y 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 implementación real, esto se procesará de manera paralela.
)# El trabajo restante y las compensaciones
Actualmente, EOF está planeado para ser incluido en la próxima bifurcación dura. Aunque siempre existe la posibilidad de eliminarlo en el último momento —en bifurcaciones duras anteriores, algunas funcionalidades han sido eliminadas temporalmente— hacerlo presentará 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.
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 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 basarse en EOF.
Una tarea importante que debe 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 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 haber incompatibilidades que traigan efectos adversos. Además, EVM-MAX y SIMD pueden reducir significativamente los costos de gas de muchos sistemas de prueba, haciendo que L2 sea más eficiente. También facilita reemplazar más precompilados por código EVM que puede realizar las mismas tareas, lo que probablemente no afectará drásticamente la eficiencia.
abstracción 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 tenía como objetivo superar 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 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 usando ERC20.
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, aprovechando técnicas criptográficas para generar firmas sin necesidad de combinar directamente estas partes de clave.
![Vitalik sobre el posible futuro de Ethereum (6): The Splurge])https://img-cdn.gateio.im/webp-social/moments-8930b556d169a2bc7168ddc2e611d3df.webp(
EIP-7702 es una propuesta que se planea introducir en la próxima bifurcación dura. EIP-7702 es el resultado de un reconocimiento creciente de la necesidad de proporcionar comodidad de abstracción de cuentas para beneficiar a todos los usuarios ), incluidos los usuarios de EOA (, y está diseñado para 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 las "funciones de conveniencia" de la abstracción de cuentas a todos los usuarios, incluidos los EOA) de hoy, es decir, las cuentas externas controladas por firmas ECDSA (.
Aunque algunos desafíos ), especialmente el desafío de "conveniencia" (, pueden ser abordados mediante tecnologías progresivas como el cálculo multipartito o EIP-7702, el principal objetivo de seguridad del que se propuso inicialmente el concepto de abstracción de cuentas solo puede lograrse retrocediendo y resolviendo el problema original: permitir que el código del contrato inteligente 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 lograr 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 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 todas 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 se vuelvan inválidas. Esto permite a un atacante enviar transacciones basura al pool de memoria a un costo muy bajo, lo que bloquea los recursos de los nodos de la red.
Después de años de esfuerzo, con el objetivo de ampliar las funcionalidades mientras se limita el riesgo de denegación de servicio ###DoS(, finalmente se llegó a la solución para lograr "abstracción de cuentas ideal": 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. Toda la verificación se procesa primero, y toda la ejecución se procesa después. 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 del entorno. Esto puede prevenir ataques de doble gasto. Además, se imponen estrictos límites de gas en el paso de verificación.
ERC-4337 fue diseñado como un estándar de protocolo adicional )ERC(, ya que en ese momento los desarrolladores de clientes de Ethereum se enfocaban 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 ha ampliado dos funciones:
(# El trabajo restante y las 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 de escritura en protocolo que ha ganado popularidad recientemente es el EIP-7701, el cual implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una sección de código separada para la validación; si la cuenta ha configurado esa sección de código, entonces dicho código se ejecutará en el paso de validación de las transacciones provenientes de esa cuenta.
El atractivo 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—sin permitir el acceso al estado externo, e incluso con un límite de gas establecido en etapas iniciales 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 de 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 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 sean extremadamente simplistas.
La principal compensación parece ser "escribir rápidamente una solución que satisface a menos personas" frente a "esperar más tiempo