El futuro posible del protocolo Ethereum(se): prosperidad
En el diseño del protocolo de Ethereum, muchos "detalles" son cruciales para su éxito. 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, lo que significa "prosperidad".
Prosperidad: Objetivo clave
Convertir la EVM en un "estado final" de alto rendimiento y estabilidad
Introducir la abstracción de cuentas en el protocolo, permitiendo que todos los usuarios disfruten 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 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 expansión adicional. Además, el EVM tiene una eficiencia baja, lo que dificulta la implementación de muchos criptográficos avanzados, 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 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 destacada es:
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 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 descontinuados gradualmente ( e incluso podrían ser convertidos forzosamente a código EOF ). Los contratos nuevos se beneficiarán de la mejora en la eficiencia que trae EOF, primero por un bytecode ligeramente reducido gracias a las características de subrutinas, y luego por nuevas funciones específicas de EOF o reducción de costos de gas.
Después de introducir EOF, la actualización se vuelve más fácil, y actualmente el desarrollo más maduro es la extensión aritmética del módulo EVM ( EVM-MAX ). EVM-MAX crea un conjunto de nuevas operaciones específicamente para cálculos 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 SIMD de múltiples datos de una sola instrucción (SIMD). SIMD ha existido como un concepto en Ethereum durante mucho tiempo, propuesto originalmente por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos los funciones hash, STARKs de 32 bits y criptografía basada en rejillas. La combinación de EVM-MAX y SIMD hace que estas dos extensiones orientadas al rendimiento sean una combinación natural.
En la práctica, esto se procesará de manera paralela.
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 presentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura del EVM deberá realizarse sin EOF; aunque es posible, podría ser más difícil.
El principal equilibrio 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 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 priorizando la mejora continua de Ethereum L1 debería incluir y construirse sobre EOF.
Una tarea importante que debe realizarse 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 causar incompatibilidades y tener efectos negativos. Además, EVM-MAX y SIMD pueden reducir el costo 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 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: firma 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 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 )
Monedero de múltiples firmas y monedero de recuperación social
Utilizar una clave para operaciones de bajo valor, utilizar otra clave ( o un grupo 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", como, por ejemplo, una cuenta que no tiene ETH pero posee algunos ERC20 puede utilizar ERC20 para pagar el gas.
MPC( el cálculo multipartito ) es una técnica que tiene 40 años de historia, utilizada 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 la clave.
EIP-7702 es una propuesta que se planea introducir en la próxima bifurcación dura. EIP-7702 es el resultado de un creciente reconocimiento de la necesidad de proporcionar facilidad de 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 convirtió en el EIP-7702. El EIP-7702 proporciona la "funcionalidad conveniente" de la abstracción de cuentas a todos los usuarios, incluidos los EOA( de hoy, que son cuentas de propiedad externa controladas por firmas ECDSA, es decir, cuentas).
Aunque algunos desafíos (, especialmente el desafío de "conveniencia" ), pueden resolverse mediante tecnologías progresivas como el cálculo multiparte o EIP-7702, el principal objetivo de seguridad del que se propuso inicialmente la propuesta de abstracción de cuentas solo se puede lograr retrocediendo y resolviendo el problema original: permitir que el código de contratos inteligentes controle la validación de transacciones. La razón por la que esto aún no se ha logrado 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 las cuentas de usuario (EOA). Toda la complejidad proviene de lograr 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 invierta el valor de S podría hacer que todas las demás transacciones en el pool de memoria sean inválidas. Esto permite a un atacante enviar transacciones basura al pool de memoria a muy bajo costo, bloqueando 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 implementar "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 doble gasto. 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), ya que en ese momento los desarrolladores de clientes de Ethereum estaban enfocados en la fusión (Merge), y no tenían 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 dimos 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 se requiere la garantía de la lista creada para ser transferida a la cuenta del usuario abstracto.
Además, ERC-4337 también amplía dos funciones:
Agentes de pago ( Paymasters ): permite que una cuenta pague tarifas en nombre de otra cuenta, lo que viola la regla de que durante la fase de verificación solo se puede acceder a la cuenta del remitente en sí, por lo que se introduce un tratamiento especial para garantizar la seguridad del mecanismo de agentes de pago.
Agregadores(: soporta 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, el principal problema a resolver es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas de escritura de protocolo que ha ganado popularidad recientemente es el EIP-7701, que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una parte de código independiente para la verificación; si la cuenta ha configurado esa parte de código, entonces ese código se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.
El atractivo de este enfoque 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 periodo de validación—sin permitir el acceso al estado externo, incluso el límite de gas establecido en la fase inicial 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 reemplazar la verificación ECDSA por una ejecución de código EVM que requiere un tiempo similar.
Sin embargo, a medida que pasa el tiempo, necesitamos aflojar 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 exigir que los pasos de verificación sean extremadamente simplificados.
La principal compensación 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. Otro enfoque sería desplegar primero una versión más ambiciosa de la abstracción de cuentas en L2. Sin embargo, el desafío aquí es que el equipo de L2 necesita tener plena confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para asegurarse de que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Otra aplicación que también necesitamos considerar claramente son las cuentas de almacenamiento de claves, que almacenan el estado relacionado con la cuenta en L1 o en un L2 dedicado, pero que pueden ser utilizadas en L1 y cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte códigos de operación como L1SLOAD o REMOTESTATICCALL, pero también requiere que la implementación de la abstracción de cuentas en L2 soporte estas operaciones.
)# ¿Cómo interactúa con otras partes del mapa de ruta?
La lista de inclusión debe soportar transacciones de abstracción de cuentas. En la práctica, la necesidad de listas de inclusión es muy similar a la necesidad de memorias descentralizadas, aunque las listas de inclusión ofrecen 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
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.
11 me gusta
Recompensa
11
7
Compartir
Comentar
0/400
UnluckyMiner
· hace2h
aún son los alcistas de EVM
Ver originalesResponder0
AirdropLicker
· hace20h
Adiós, la bomba de Gas ha llegado.
Ver originalesResponder0
ChainWanderingPoet
· 08-05 23:23
Los costos deben optimizarse, ni siquiera se puede manejar el BTC.
Ver originalesResponder0
LeverageAddict
· 08-03 22:13
El shitcoin ya está corriendo en EVM, mientras que la máquina de Ether aún está atascada.
Ver originalesResponder0
FrogInTheWell
· 08-03 22:10
Entonces, ¿realmente todos quieren optimizar el EVM?
Ver originalesResponder0
Ser_This_Is_A_Casino
· 08-03 22:09
Se optimiza drásticamente, ya era hora de ponerle atención.
Perspectivas futuras del protocolo Ethereum: actualización de EVM, abstracción de cuentas y optimización de blanqueo de capitales.
El futuro posible del protocolo Ethereum(se): prosperidad
En el diseño del protocolo de Ethereum, muchos "detalles" son cruciales para su éxito. 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, lo que significa "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 expansión adicional. Además, el EVM tiene una eficiencia baja, lo que dificulta la implementación de muchos criptográficos avanzados, 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 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 destacada es:
Los contratos antiguos seguirán existiendo y podrán ser creados, aunque eventualmente podrían ser descontinuados gradualmente ( e incluso podrían ser convertidos forzosamente a código EOF ). Los contratos nuevos se beneficiarán de la mejora en la eficiencia que trae EOF, primero por un bytecode ligeramente reducido gracias a las características de subrutinas, y luego por nuevas funciones específicas de EOF o reducción de costos de gas.
Después de introducir EOF, la actualización se vuelve más fácil, y actualmente el desarrollo más maduro es la extensión aritmética del módulo EVM ( EVM-MAX ). EVM-MAX crea un conjunto de nuevas operaciones específicamente para cálculos 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 SIMD de múltiples datos de una sola instrucción (SIMD). SIMD ha existido como un concepto en Ethereum durante mucho tiempo, propuesto originalmente por Greg Colvin en el EIP-616. SIMD se puede utilizar para acelerar muchas formas de criptografía, incluidos los funciones hash, STARKs de 32 bits y criptografía basada en rejillas. La combinación de EVM-MAX y SIMD hace que estas dos extensiones orientadas al rendimiento sean una combinación natural.
En la práctica, esto se procesará de manera paralela.
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 presentará grandes desafíos. Eliminar EOF significa que cualquier actualización futura del EVM deberá realizarse sin EOF; aunque es posible, podría ser más difícil.
El principal equilibrio 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 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 priorizando la mejora continua de Ethereum L1 debería incluir y construirse sobre EOF.
Una tarea importante que debe realizarse 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 causar incompatibilidades y tener efectos negativos. Además, EVM-MAX y SIMD pueden reducir el costo 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 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: firma 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 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", como, por ejemplo, una cuenta que no tiene ETH pero posee algunos ERC20 puede utilizar ERC20 para pagar el gas.
MPC( el cálculo multipartito ) es una técnica que tiene 40 años de historia, utilizada 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 la clave.
EIP-7702 es una propuesta que se planea introducir en la próxima bifurcación dura. EIP-7702 es el resultado de un creciente reconocimiento de la necesidad de proporcionar facilidad de 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 convirtió en el EIP-7702. El EIP-7702 proporciona la "funcionalidad conveniente" de la abstracción de cuentas a todos los usuarios, incluidos los EOA( de hoy, que son cuentas de propiedad externa controladas por firmas ECDSA, es decir, cuentas).
Aunque algunos desafíos (, especialmente el desafío de "conveniencia" ), pueden resolverse mediante tecnologías progresivas como el cálculo multiparte o EIP-7702, el principal objetivo de seguridad del que se propuso inicialmente la propuesta de abstracción de cuentas solo se puede lograr retrocediendo y resolviendo el problema original: permitir que el código de contratos inteligentes controle la validación de transacciones. La razón por la que esto aún no se ha logrado 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 las cuentas de usuario (EOA). Toda la complejidad proviene de lograr 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 invierta el valor de S podría hacer que todas las demás transacciones en el pool de memoria sean inválidas. Esto permite a un atacante enviar transacciones basura al pool de memoria a muy bajo costo, bloqueando 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 implementar "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 doble gasto. 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), ya que en ese momento los desarrolladores de clientes de Ethereum estaban enfocados en la fusión (Merge), y no tenían 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 dimos 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:
)# El trabajo restante y las compensaciones
Actualmente, el principal problema a resolver es cómo introducir completamente la abstracción de cuentas en el protocolo. El EIP de abstracción de cuentas de escritura de protocolo que ha ganado popularidad recientemente es el EIP-7701, que implementa la abstracción de cuentas sobre el EOF. Una cuenta puede tener una parte de código independiente para la verificación; si la cuenta ha configurado esa parte de código, entonces ese código se ejecutará en el paso de verificación de las transacciones provenientes de esa cuenta.
El atractivo 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 periodo de validación—sin permitir el acceso al estado externo, incluso el límite de gas establecido en la fase inicial 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 reemplazar la verificación ECDSA por una ejecución de código EVM que requiere un tiempo similar.
Sin embargo, a medida que pasa el tiempo, necesitamos aflojar 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 exigir que los pasos de verificación sean extremadamente simplificados.
La principal compensación 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. Otro enfoque sería desplegar primero una versión más ambiciosa de la abstracción de cuentas en L2. Sin embargo, el desafío aquí es que el equipo de L2 necesita tener plena confianza en el trabajo de la propuesta adoptada para estar dispuesto a implementarla, especialmente para asegurarse de que L1 y/o otros L2 puedan adoptar soluciones compatibles en el futuro.
![Vitalik sobre el posible futuro de Ethereum (seis): The Splurge])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
Otra aplicación que también necesitamos considerar claramente son las cuentas de almacenamiento de claves, que almacenan el estado relacionado con la cuenta en L1 o en un L2 dedicado, pero que pueden ser utilizadas en L1 y cualquier L2 compatible. Hacer esto de manera efectiva puede requerir que L2 soporte códigos de operación como L1SLOAD o REMOTESTATICCALL, pero también requiere que la implementación de la abstracción de cuentas en L2 soporte estas operaciones.
)# ¿Cómo interactúa con otras partes del mapa de ruta?
La lista de inclusión debe soportar transacciones de abstracción de cuentas. En la práctica, la necesidad de listas de inclusión es muy similar a la necesidad de memorias descentralizadas, aunque las listas de inclusión ofrecen 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