Análisis de la abstracción de cuentas multicanal: explorando el futuro de la encriptación de infraestructura

Del 8 al 11 de julio de 2024, la conferencia de la comunidad de Ethereum (EthCC) se llevará a cabo en Bruselas, Bélgica, siendo el evento anual más grande de Ethereum en Europa, enfocado en la tecnología y la comunidad.

La conferencia de la comunidad Ethereum de este año ( EthCC 7) contó con más de 350 líderes de opinión activos en la primera línea de la industria blockchain que dieron charlas, entre ellos un desarrollador de blockchain fue invitado a participar y presentó una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multichain".

Resumen de la presentación:

• Abstracción de cuentas(AA) incluye principalmente dos puntos clave: abstracción de firma y abstracción de pago. La abstracción de firma permite a los usuarios elegir cualquier mecanismo de verificación que prefieran, mientras que la abstracción de pago permite el uso de múltiples opciones de pago para transacciones. Esta flexibilidad proporciona una experiencia de usuario más segura y óptima.
• En ERC-4337 y AA nativa, la función del punto de entrada en la fase de "verificación" es fija, mientras que en la fase de "ejecución", solo el punto de entrada en AA nativa es fijo. Las limitaciones de la verificación de transacciones y los pasos de ejecución de transacciones tienen características y restricciones propias en diferentes implementaciones.
• Implementar ERC-4337 en cadenas compatibles con EVM tiene dos diferencias clave: las diferencias en el protocolo del diseño de Rollup y las diferencias en la forma de calcular las direcciones, lo que resulta en detalles de desarrollo difíciles de notar al implementar ERC-4337 entre L1 y L2.

A continuación se presenta el texto completo del discurso:

Hola a todos, hoy les voy a presentar el concepto de ERC-4337 y Native AA, discutir las diferencias entre ellos y analizar detenidamente las principales diferencias del estándar 4337 en L1 y L2.

Introducción a la abstracción de cuentas

1. ¿Qué es la abstracción de cuentas?

abstracción de cuentas(AA) incluye principalmente dos puntos clave: abstracción de firma y abstracción de pago.

• Abstracción de firmas: los usuarios pueden elegir cualquier mecanismo de verificación que deseen, no limitado a ciertos algoritmos de firma digital ( como ECDSA ).
• Abstracción de pagos: los usuarios pueden utilizar múltiples opciones de pago para transacciones, como usar activos ERC-20 en lugar de activos nativos para el pago, o permitir que un tercero patrocine la transacción.

Esta flexibilidad ofrece una experiencia de usuario más segura y óptima. El objetivo de la abstracción de cuentas es lograr estos dos puntos clave a través de diversas maneras.

2. ¿Qué es ERC-4337?

Actualmente, en el protocolo de Ethereum, la cuenta externa poseída (EOA) presenta algunas limitaciones, como un método de firma fijo y un diseño de pago. ERC-4337 aborda estos problemas al introducir métodos de gestión de cuentas y procesamiento de transacciones más flexibles.

• Estructura userOp: en ERC-4337, el usuario envía la estructura userOp al Bundler. El Bundler recopila múltiples userOp y las envía al contrato EntryPoint mediante la llamada a la función handleOps.
• Contrato EntryPoint: Este contrato maneja las transacciones como un sistema operativo, y sus funciones principales incluyen:

• Llamar a la función validate en el contrato de cuentas para asegurar que userOp obtenga la autorización del propietario de la cuenta.
• Cobrar tarifas.
• Llamar a la función execute en el contrato de cuenta para ejecutar la operación objetivo de userOp.

3. ¿Qué es AA nativa?

En Ethereum, las cuentas se dividen en EOA y cuentas de contrato. Sin embargo, en la AA nativa, cada cuenta es un contrato, y el mecanismo de procesamiento de transacciones está directamente integrado en el protocolo de la cadena de bloques.

Diseño de AA en diversas redes de blockchain:

• Abstracción de cuentas ERC-4337: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
• La abstracción de cuentas nativa sigue ERC-4337: Era de StarkNet & zkSync
• Cuenta de abstracción nativa con diseño de privacidad: Aztec

Si estás interesado en Aztec Native AA o EIP-3074, EIP-7702, hoy nos centraremos en la AA nativa después de ERC-4337.

La diferencia entre ERC-4337 y AA nativo

1. Rol del sistema operativo

AA OS necesita responder las siguientes preguntas:

• ¿Quién decide el precio del Gas?
• ¿Quién decide el orden de las transacciones? ¿Dónde está el pool de memoria?
• ¿Quién activa la función del punto de entrada?
• ¿Qué determina el proceso de manejo de transacciones?

En ERC-4337, estos roles se completan de manera colaborativa a través de Bundler y EntryPoint Contract.

En la AA nativa, los usuarios envían sus userOps al operador/ordenador del servidor oficial, en lugar de al Bundler y al EntryPoint Contract.

En StarkNet, el Secuenciador es responsable de manejar todas estas tareas.

En zkSync, la principal diferencia entre Era y otras implementaciones de AA es que el Operador necesita trabajar en conjunto con el contrato del sistema bootloader(. El bootloader abre un nuevo bloque, define sus parámetros), incluidos los parámetros del bloque y otros parámetros de Gas(, y recibe transacciones del Operador para su verificación.

2. Interfaz de contrato

Debido a la existencia de tres pasos, la interfaz de contrato de cuenta es similar en diferentes implementaciones, y estos puntos de entrada solo pueden ser llamados por el AA OS:

• ERC-4337: Validar operaciones del usuario
• zkSync: verificación de transacciones, pago de transacciones, ejecución de transacciones
• StarkNet: ejecutar, validar, validar_declarar, validar_desplegar

En ERC-4337 y AA nativa, la función de punto de entrada en la etapa de "verificación" es fija, mientras que en la etapa de "ejecución", solo el punto de entrada en AA nativa es fijo.

3. Restricciones de los pasos de verificación

Debido a que la validación de transacciones no tiene límites de costo) esencialmente, validar transacciones es invocar funciones de vista(, un atacante puede llevar a cabo un ataque DoS en el pool de memoria, lo que puede dañar el agrupador)EIP-4337( o el operador/ordenador) AA nativa(.

EIP-4337 define qué códigos de operación están prohibidos y cómo restringir el acceso al almacenamiento. zkSync Era ha relajado el uso de algunos códigos de operación:

• La lógica del contrato solo puede acceder a su propio espacio de almacenamiento. Si la dirección del contrato de cuenta es la dirección A, puede acceder a:

• Slot de almacenamiento perteneciente a la dirección A
• ranura de almacenamiento perteneciente a cualquier otra dirección A
• Almacén de ranura keccak256)A || X( que pertenece a cualquier otra dirección: esto significa usar directamente la dirección como clave en el mapeo ), por ejemplo, mapeo (address => value(), equivalente a acceder a la ranura keccak256)A || X(. Por ejemplo, el saldo de activos en un contrato ERC-20.

• La lógica del contrato no puede acceder a variables globales, como el número de bloque. StarkNet tampoco permite llamadas de contratos externos.

4. Limitaciones en los pasos de ejecución

En zkSync, la ejecución de llamadas al sistema requiere confirmar la existencia de las banderas del sistema. Por ejemplo, la única forma de aumentar el nonce es interactuando con el NonceHolder, mientras que el despliegue de contratos requiere interactuar con el ContractDeployer. Las banderas del sistema aseguran que los desarrolladores de cuentas interactúen conscientemente con los contratos del sistema.

En ERC-4337 y StarkNet, la fase de ejecución no tiene restricciones especiales.

5. Número aleatorio

• En ERC-4337, el diseño del número aleatorio del punto de entrada distingue entre un valor de clave de 192 bits y un valor aleatorio de 64 bits.
• En zkSync, el contrato del sistema NonceHolder gestiona el nonce, asegurando un incremento estricto, es decir, aumentando el número aleatorio en 1.
• En StarkNet, el nonce también es estrictamente creciente, pero no hay un nonce abstracto gestionado por contratos específicos.

6. Usar la primera transacción para el despliegue

• ERC-4337 incluye el campo initcode en la estructura userOp para desplegar el contrato de cuenta del remitente ) en su primer userOp (.
• En StarkNet y zkSync, los usuarios deben enviar la primera transacción al operador/ordenador para desplegar el contrato de cuenta.

7. Diseño especial en zkSync

Si transfieres ETH directamente desde una EOA de Ethereum a zkSync, sin necesidad de desplegar un contrato de cuenta personalizado, recibirás una cuenta predeterminada con la misma dirección. Esta cuenta puede funcionar como una EOA de Ethereum y también está controlada por la clave privada de la EOA de Ethereum correspondiente.

Este tipo de cuenta es de la versión None en lugar de version1. No puedes llamar a la función DefaultAccount, porque no se ha desplegado ningún código en el espacio del núcleo.

![¿El futuro de la infraestructura de encriptación? Análisis de la abstracción de cuentas multichain])https://img-cdn.gateio.im/webp-social/moments-52ccc7ebff94f6c548dd55bc61aad309.webp(

) La diferencia entre L1 4337 y L2 4337

La implementación de ERC-4337 en cadenas compatibles con EVM tiene dos diferencias clave: diferencias de protocolo y diferencias de dirección.

1. Diferencias de protocolo

En el diseño de Rollup, L2 necesita subir datos a L1 para la seguridad y liquidación. En el contexto de ERC-4337, los costos asociados con este proceso de carga, como la tarifa de seguridad de L1 y la tarifa de blob, deberían incluirse en el Gas de prevalidación. Determinar los costos de carga apropiados en el Gas de prevalidación es un desafío significativo.

2. Diferencias de dirección

El método de codificación de direcciones en la función create de zkSync ERA es diferente al de Ethereum y OP rollups. Además, StarkNet utiliza una función hash única para el cálculo de direcciones. En el contexto de ERC-4337 en cadenas compatibles con EVM, generalmente asumimos que el cálculo de direcciones es consistente en todas las cadenas. Sin embargo, hay un detalle difícil de notar que puede llevar a que las direcciones de los contratos de cuenta entre las implementaciones de ERC-4337 en Ethereum y L2 sean diferentes.

La cuestión clave es añadir nuevos códigos de operación en un hard fork. Por ejemplo, si la cadena L2 no soporta el hard fork de Shanghai y no se especifica la versión de EVM en el momento de la compilación, la introducción de push0 provocará un cambio en el bytecode, incluso si el código de Solidity es el mismo.

conclusión

以上是关于abstracción de cuentas的一些信息。如果你有任何疑问,可以在Twitter上找到我。

![¿El futuro de la encriptación de infraestructura? Análisis de la abstracción de cuentas multicanal]###https://img-cdn.gateio.im/webp-social/moments-180475deec41c605ac65be9b2b494048.webp(