Abstracción de cuentas multichain: una nueva dirección para la encriptación de infraestructuras

Del 8 al 11 de julio de 2024, se llevará a cabo el evento anual de Ethereum más grande de Europa: la Conferencia de la Comunidad de Ethereum (EthCC) en Bruselas, Bélgica. Esta edición de la conferencia (EthCC 7) reunirá a más de 350 líderes de opinión de primera línea de la industria de blockchain. Un desarrollador de blockchain pronunció una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multichain".

Los puntos clave de la presentación incluyen:

• La abstracción de cuentas (AA) tiene dos núcleos: la abstracción de firmas y la abstracción de pagos. La primera permite a los usuarios elegir cualquier mecanismo de verificación, mientras que la segunda permite múltiples opciones de pago de transacciones, proporcionando así una experiencia de usuario más segura y conveniente.

• ERC-4337 y AA nativo tienen diferencias en el diseño de las funciones de punto de entrada en las etapas de verificación y ejecución. Cada solución implementada tiene características propias en la limitación de transacciones y los pasos de ejecución.

• Al implementar ERC-4337 en cadenas compatibles con EVM, es necesario prestar atención a las diferencias en el protocolo causadas por el diseño de Rollup, así como a las diferencias en la forma de calcular direcciones, ya que estos detalles pueden afectar la implementación entre L1 y L2.

Abstracción de cuentas: visión general

abstracción de cuentas(AA)principalmente incluye dos puntos clave:

1. Abstracción de firma: los usuarios pueden elegir cualquier mecanismo de verificación, sin limitarse a un algoritmo de firma digital específico.

2. Abstracción de pagos: los usuarios pueden utilizar varias opciones de pago para transacciones, como pagar con tokens ERC-20 o ser patrocinados por terceros.

Esta flexibilidad puede ofrecer una experiencia de usuario más segura y optimizada. AA tiene como objetivo lograr estos dos objetivos centrales de varias maneras.

Introducción a ERC-4337

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

Características principales:

• Estructura userOp: El usuario envía la estructura userOp al Bundler, que recopila múltiples userOp y llama a la función handleOps del contrato EntryPoint.

• Contrato EntryPoint: similar a un sistema operativo que procesa transacciones, sus principales funciones incluyen:

  1. Llama a la función validate del contrato de cuenta, asegúrate de que userOp esté autorizado
  2. Cobrar tarifas
  3. Llamar a la función execute del contrato de cuenta para ejecutar la operación objetivo de userOp

Introducción a AA nativo

En la AA nativa, cada cuenta es un contrato, y el mecanismo de procesamiento de transacciones está directamente integrado en el protocolo de blockchain.

Diseño de AA en diferentes redes de blockchain:

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

Diferencias entre ERC-4337 y AA nativo

1. Rol del sistema operativo

El sistema operativo AA necesita resolver: la fijación de precios de Gas, el orden de las transacciones, la activación de funciones de punto de entrada, el proceso de manejo de transacciones, entre otros problemas.

ERC-4337 completa estas tareas en colaboración con el Bundler y el EntryPoint Contract. En la AA nativa, los usuarios envían userOps a los operadores/ordenadores del servidor oficial.

2. Interfaz de contrato

Las interfaces de contrato de cuenta de diferentes implementaciones son similares y contienen tres pasos: verificación, pago y ejecución. En ERC-4337 y AA nativo, la función de punto de entrada de la etapa de "verificación" es fija, mientras que solo el punto de entrada de la etapa de "ejecución" en AA nativo es fijo.

3. Restricción de pasos de verificación

Para prevenir ataques DoS, cada implementación ha establecido diferentes limitaciones para la verificación de transacciones. Por ejemplo, EIP-4337 define restricciones en los códigos de operación prohibidos y el acceso al almacenamiento, mientras que zkSync Era ha relajado el uso de algunos códigos de operación.

4. Restricción de pasos de ejecución

zkSync requiere una señal de confirmación del sistema para ejecutar llamadas al sistema. No hay restricciones especiales en la fase de ejecución de ERC-4337 y StarkNet.

5. Número aleatorio

ERC-4337 distingue entre un valor de clave de 192 bits y un valor aleatorio de 64 bits. zkSync y StarkNet utilizan un nonce estrictamente creciente.

6. Despliegue de la primera transacción

ERC-4337 incluye el campo initcode en la estructura userOp, utilizado para desplegar por primera vez el contrato de cuenta userOp. StarkNet y zkSync requieren que la primera transacción del usuario se envíe al operador/ordenador para desplegar el contrato de cuenta.

Diferencias entre ERC-4337 de L1 y L2

En la implementación de ERC-4337 en cadenas compatibles con EVM, hay dos diferencias clave:

1. Diferencias de protocolo

En el diseño de Rollup, L2 debe cargar datos a L1 para garantizar la seguridad y la liquidación. Los costos relacionados (, como la tarifa de seguridad de L1 y la tarifa de blob ), deben incluirse en el Gas de prevalidación, pero determinar el costo de carga adecuado es un gran desafío.

2. Diferencias de dirección

Existen diferencias en la forma de calcular las direcciones entre diferentes cadenas. Por ejemplo, el método de codificación de direcciones en la función create de zkSync ERA es diferente al de Ethereum y OP, mientras que StarkNet utiliza una función hash única para calcular las direcciones.

Cabe destacar que los nuevos códigos de operación en un hard fork pueden provocar cambios en el bytecode, lo que a su vez afecta la consistencia de la dirección del contrato de cuenta. Por ejemplo, si la cadena L2 no admite 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 cambiará el bytecode, incluso si el código Solidity es el mismo.