Análisis de la abstracción de cuentas multichain: explorando el futuro de la encriptación de infraestructura
Recientemente, la conferencia de la comunidad de Ethereum (EthCC 7) se llevó a cabo en Bruselas, Bélgica, siendo el evento anual de Ethereum más grande de Europa, enfocado en la tecnología y la comunidad. En esta edición, más de 350 líderes de opinión de primera línea en la industria de la blockchain dieron discursos, entre ellos un desarrollador que presentó una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multichain".
Puntos clave de la presentación
La abstracción de cuentas (AA) incluye principalmente dos puntos clave: la abstracción de firmas y la abstracción de pagos. La abstracción de firmas permite a los usuarios elegir cualquier mecanismo de verificación que les guste, mientras que la abstracción de pagos permite utilizar múltiples opciones de pago para transacciones. Esta flexibilidad proporciona una experiencia de usuario más segura y óptima.
En ERC-4337 y AA nativo, 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 nativo es fijo. Las restricciones para la verificación de transacciones y los pasos para la ejecución de transacciones tienen sus propias características y limitaciones en diferentes implementaciones.
La implementación de 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 direcciones, lo que resulta en detalles de desarrollo que son difíciles de notar al implementar ERC-4337 entre L1 y L2.
Abstracción de cuentas Introducción
¿Qué es la abstracción de cuentas?
La abstracción de cuentas (AA) incluye principalmente dos puntos clave:
Abstracción de firmas: los usuarios pueden elegir cualquier mecanismo de verificación que deseen, y no están limitados 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 pagar, 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 de diversas maneras.
Introducción a ERC-4337
Actualmente, las cuentas de propiedad externa (EOA) en el protocolo de Ethereum tienen 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:
Llama a la función validate en el contrato de cuenta 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.
Introducción a AA nativa
En Ethereum, las cuentas se dividen en EOA y cuentas de contrato. Sin embargo, en la abstracción de cuentas nativa, cada cuenta es un contrato y el mecanismo de procesamiento de transacciones está directamente integrado en el protocolo de la cadena de bloques.
La abstracción de cuentas nativa sigue el ERC-4337: la era de StarkNet y zkSync
Cuenta abstracta nativa con diseño de privacidad: Aztec
Diferencias entre ERC-4337 y AA nativo
rol del sistema operativo
AA OS necesita resolver los siguientes problemas:
¿Quién decide el precio del Gas?
¿Quién decide el orden de las transacciones? ¿Dónde está el grupo de memoria?
¿Quién activa la función del punto de entrada?
¿Qué determina el proceso de procesamiento de transacciones?
En ERC-4337, estos roles se completan en colaboración a través de Bundler y EntryPoint Contract.
En el AA nativo, los usuarios envían sus userOps al operador/ordenador del servidor oficial, en lugar de al Bundler y al EntryPoint Contract.
En StarkNet, el Sequencer 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 bootloader (contrato del sistema). 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.
interfaz de contrato
Debido a la existencia de tres pasos, la interfaz del contrato de cuenta es similar en diferentes implementaciones, y estos puntos de entrada solo pueden ser llamados por el AA OS:
ERC-4337: validación de operaciones de usuarios
zkSync: verificación de transacciones, pago de transacciones, ejecución de transacciones
En ERC-4337 y AA nativo, la función de punto de entrada de la fase de "verificación" es fija, mientras que en la fase de "ejecución", solo el punto de entrada en AA nativo es fijo.
restricciones de los pasos de verificación
Dado que no hay límites de costo para validar transacciones (en esencia, validar transacciones es llamar a funciones de vista), un atacante puede llevar a cabo un ataque DoS en el pool de memoria, lo que puede dañar el empaquetador (EIP-4337) o el operador/ordenador (AA nativa).
EIP-4337 define qué códigos de operación están prohibidos y cómo se limita 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 propia ranura de almacenamiento. Si la dirección del contrato de cuenta es la dirección A, puede acceder a:
Ranura de almacenamiento perteneciente a la dirección A
espacio de almacenamiento perteneciente a cualquier otra dirección A
Almacén de ranura keccak256(A || X) perteneciente a cualquier otra dirección: esto significa usar directamente la dirección como clave en el mapeo (por ejemplo, mapeo (address => value)), lo que equivale a acceder a la ranura keccak256(A || X). Por ejemplo, el saldo de activos en un contrato ERC-20.
La lógica de contrato no puede acceder a variables globales, como el número de bloque. StarkNet tampoco permite llamadas de contratos externos.
limitaciones de los pasos de ejecución
En zkSync, la ejecución de llamadas al sistema requiere confirmar la existencia de una bandera del sistema. Por ejemplo, la única forma de aumentar el nonce es interactuando con el NonceHolder, mientras que desplegar un contrato requiere interactuar con el ContractDeployer. La bandera del sistema asegura que los desarrolladores de cuentas interactúan de manera consciente con el contrato del sistema.
En ERC-4337 y StarkNet, la fase de ejecución no tiene restricciones especiales.
número aleatorio
En el 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.
utiliza la primera transacción para el despliegue
ERC-4337 incluye el campo initcode en la estructura userOp para desplegar el remitente (contrato de cuenta) en su primer userOp.
En StarkNet y zkSync, los usuarios deben enviar la primera transacción a un operador/ordenador para desplegar el contrato de cuenta.
diseño especial en zkSync
Si transfieres ETH directamente desde una cuenta 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 correspondiente EOA de Ethereum.
Este tipo de cuenta es de versión None en lugar de version1. No puedes llamar a las funciones de DefaultAccount porque no se ha desplegado ningún código en el espacio del núcleo.
Diferencias entre L1 4337 y L2 4337
Implementar ERC-4337 en cadenas compatibles con EVM tiene dos diferencias clave: diferencias de protocolo y diferencias de dirección.
diferencia de protocolo
En el diseño de Rollup, L2 necesita cargar datos a L1 para seguridad y liquidación. En el contexto de ERC-4337, los costos relacionados 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 gran desafío.
diferencia 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. 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, normalmente asumimos que el cálculo de direcciones es consistente en todas las cadenas. Sin embargo, hay un detalle sutil que podría causar que las direcciones de contrato de cuenta entre las implementaciones de ERC-4337 en Ethereum y L2 sean diferentes.
El problema 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 Shanghái 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.
Ver originales
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
2
Compartir
Comentar
0/400
OnChainArchaeologist
· 07-09 19:30
Demasiado amor por hacer estas cosas.
Ver originalesResponder0
PriceOracleFairy
· 07-09 19:30
meh, aa es solo matemáticas elegantes de eth... pero esa abstracción de firma se ve bastante jugosa, no voy a mentir.
Análisis de la abstracción de cuentas multichain: las claves diferencias entre ERC-4337 y AA nativo
Análisis de la abstracción de cuentas multichain: explorando el futuro de la encriptación de infraestructura
Recientemente, la conferencia de la comunidad de Ethereum (EthCC 7) se llevó a cabo en Bruselas, Bélgica, siendo el evento anual de Ethereum más grande de Europa, enfocado en la tecnología y la comunidad. En esta edición, más de 350 líderes de opinión de primera línea en la industria de la blockchain dieron discursos, entre ellos un desarrollador que presentó una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multichain".
Puntos clave de la presentación
La abstracción de cuentas (AA) incluye principalmente dos puntos clave: la abstracción de firmas y la abstracción de pagos. La abstracción de firmas permite a los usuarios elegir cualquier mecanismo de verificación que les guste, mientras que la abstracción de pagos permite utilizar múltiples opciones de pago para transacciones. Esta flexibilidad proporciona una experiencia de usuario más segura y óptima.
En ERC-4337 y AA nativo, 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 nativo es fijo. Las restricciones para la verificación de transacciones y los pasos para la ejecución de transacciones tienen sus propias características y limitaciones en diferentes implementaciones.
La implementación de 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 direcciones, lo que resulta en detalles de desarrollo que son difíciles de notar al implementar ERC-4337 entre L1 y L2.
Abstracción de cuentas Introducción
¿Qué es la abstracción de cuentas?
La abstracción de cuentas (AA) incluye principalmente dos puntos clave:
Abstracción de firmas: los usuarios pueden elegir cualquier mecanismo de verificación que deseen, y no están limitados 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 pagar, 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 de diversas maneras.
Introducción a ERC-4337
Actualmente, las cuentas de propiedad externa (EOA) en el protocolo de Ethereum tienen 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:
Introducción a AA nativa
En Ethereum, las cuentas se dividen en EOA y cuentas de contrato. Sin embargo, en la abstracción de cuentas 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 las redes de blockchain
Diferencias entre ERC-4337 y AA nativo
rol del sistema operativo
AA OS necesita resolver los siguientes problemas:
En ERC-4337, estos roles se completan en colaboración a través de Bundler y EntryPoint Contract.
En el AA nativo, los usuarios envían sus userOps al operador/ordenador del servidor oficial, en lugar de al Bundler y al EntryPoint Contract.
En StarkNet, el Sequencer 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 bootloader (contrato del sistema). 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.
interfaz de contrato
Debido a la existencia de tres pasos, la interfaz del contrato de cuenta es similar en diferentes implementaciones, y estos puntos de entrada solo pueden ser llamados por el AA OS:
En ERC-4337 y AA nativo, la función de punto de entrada de la fase de "verificación" es fija, mientras que en la fase de "ejecución", solo el punto de entrada en AA nativo es fijo.
restricciones de los pasos de verificación
Dado que no hay límites de costo para validar transacciones (en esencia, validar transacciones es llamar a funciones de vista), un atacante puede llevar a cabo un ataque DoS en el pool de memoria, lo que puede dañar el empaquetador (EIP-4337) o el operador/ordenador (AA nativa).
EIP-4337 define qué códigos de operación están prohibidos y cómo se limita 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 propia ranura de almacenamiento. Si la dirección del contrato de cuenta es la dirección A, puede acceder a:
La lógica de contrato no puede acceder a variables globales, como el número de bloque. StarkNet tampoco permite llamadas de contratos externos.
limitaciones de los pasos de ejecución
En zkSync, la ejecución de llamadas al sistema requiere confirmar la existencia de una bandera del sistema. Por ejemplo, la única forma de aumentar el nonce es interactuando con el NonceHolder, mientras que desplegar un contrato requiere interactuar con el ContractDeployer. La bandera del sistema asegura que los desarrolladores de cuentas interactúan de manera consciente con el contrato del sistema.
En ERC-4337 y StarkNet, la fase de ejecución no tiene restricciones especiales.
número aleatorio
utiliza la primera transacción para el despliegue
diseño especial en zkSync
Si transfieres ETH directamente desde una cuenta 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 correspondiente EOA de Ethereum.
Este tipo de cuenta es de versión None en lugar de version1. No puedes llamar a las funciones de DefaultAccount porque no se ha desplegado ningún código en el espacio del núcleo.
Diferencias entre L1 4337 y L2 4337
Implementar ERC-4337 en cadenas compatibles con EVM tiene dos diferencias clave: diferencias de protocolo y diferencias de dirección.
diferencia de protocolo
En el diseño de Rollup, L2 necesita cargar datos a L1 para seguridad y liquidación. En el contexto de ERC-4337, los costos relacionados 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 gran desafío.
diferencia 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. 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, normalmente asumimos que el cálculo de direcciones es consistente en todas las cadenas. Sin embargo, hay un detalle sutil que podría causar que las direcciones de contrato de cuenta entre las implementaciones de ERC-4337 en Ethereum y L2 sean diferentes.
El problema 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 Shanghái 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.