Revelando el futuro: análisis de la abstracción de cuentas multichain
Del 8 al 11 de julio, se celebró la conferencia de la comunidad de Ethereum en Bruselas, el evento anual de Ethereum más grande de Europa, centrado en la tecnología y la comunidad.
En esta conferencia, más de 350 líderes de opinión de primera línea en la industria blockchain dieron discursos, incluyendo una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multicanal".
Puntos clave de la presentación:
La abstracción de cuentas (AA) tiene dos puntos clave: la abstracción de firma y la abstracción de pago. La abstracción de firma permite a los usuarios elegir cualquier mecanismo de verificación, mientras que la abstracción de pago admite múltiples opciones de pago para transacciones. Esta flexibilidad mejora la seguridad y la experiencia del usuario.
Las funciones de punto de entrada en la etapa de "verificación" de ERC-4337 y AA nativo son fijas, mientras que en la etapa de "ejecución", solo el punto de entrada de AA nativo es fijo. Las limitaciones para verificar transacciones y los pasos para ejecutar transacciones varían según la implementación.
Al implementar ERC-4337 en cadenas compatibles con EVM, las diferencias en el protocolo del diseño de Rollup y la forma de calcular direcciones son dos diferencias clave, lo que provoca que surjan algunos detalles de desarrollo sutiles al implementar ERC-4337 entre L1 y L2.
A continuación se presenta el texto completo del discurso:
Hola a todos, hoy voy a presentar el concepto de ERC-4337 y AA nativo, discutir las diferencias entre ellos y analizar en detalle las principales diferencias del estándar 4337 en L1 y L2.
abstracción de cuentas introducción
1. Definición de abstracción de cuentas
La abstracción de cuentas(AA) incluye principalmente dos puntos clave: la abstracción de firmas y la abstracción de pagos.
Abstracción de firmas: los usuarios pueden elegir cualquier mecanismo de verificación que deseen, no limitándose 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 de diversas maneras.
2. 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:
Llamar a la función validate en el contrato de cuenta, asegurando que userOp obtenga la autorización del propietario de la cuenta.
Cobrar tarifas.
Llamar a la función execute en el contrato de cuentas para ejecutar la operación objetivo de userOp.
3. Introducción a 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.
La abstracción de cuentas nativa sigue ERC-4337: Era de StarkNet y zkSync
Cuenta abstracta nativa con diseño de privacidad: Aztec
Diferencias entre ERC-4337 y AA nativo
1. Rol del sistema operativo
AA OS necesita resolver los siguientes problemas:
Determinante del precio del gas
El decisor del orden de las transacciones y la ubicación del pool de memoria
Activador de la función de punto de entrada
Factores determinantes del proceso de procesamiento de transacciones
En ERC-4337, estos roles se completan en colaboración a través del Bundler y el 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 Sequencer se encarga 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 nuevos bloques, 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 del contrato de cuenta es similar en diferentes implementaciones, estos puntos de entrada solo pueden ser llamados por el AA OS:
ERC-4337: validación de operaciones del usuario
zkSync: validación de transacciones, pago de transacciones, ejecución de transacciones
En ERC-4337 y AA nativa, la función del 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 restricciones de costo (en esencia, 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 bundler (EIP-4337) o los operadores/ordenadores (AA nativo).
EIP-4337 define qué códigos de operación están prohibidos y cómo se limita el acceso a la memoria. 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:
Slots de almacenamiento pertenecientes a la dirección A
espacio de almacenamiento perteneciente a cualquier otra dirección A
Almacén de almacenamiento keccak256 (A || X) perteneciente a cualquier otra dirección: esto significa usar directamente la dirección como clave en el mapeo (por ejemplo, mapping (address => value)), lo que equivale a acceder al almacén 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 a contratos externos.
4. Limitaciones de los pasos de ejecución
En zkSync, realizar 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 desplegar un contrato 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, no hay restricciones especiales en la fase de ejecución.
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 un contrato específico.
6. Usar la primera transacción para implementar
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 la cuenta del contrato.
7. diseño especial en zkSync
Si transfieres ETH directamente de un EOA de Ethereum a zkSync, no necesitas desplegar un contrato de cuenta personalizado, recibirás una cuenta predeterminada con la misma dirección. Esta cuenta puede funcionar como un EOA de Ethereum y también está controlada por la clave privada correspondiente del EOA de Ethereum.
Este tipo de cuenta es la versión None en lugar de version1. No puedes llamar a las funciones de DefaultAccount, ya que no ha desplegado ningún código en el espacio del kernel.
La diferencia entre el 4337 de L1 y el 4337 de L2
Hay dos diferencias clave en la implementación de ERC-4337 en cadenas compatibles con EVM: diferencias de protocolo y diferencias de dirección.
1. Diferencias en el 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 a 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. 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 que puede pasar desapercibido y que podría causar que las direcciones de contrato de cuenta sean diferentes entre las implementaciones de ERC-4337 en Ethereum y L2.
La cuestión clave es la adición de nuevos códigos de operación en un hard fork. Por ejemplo, si la cadena L2 no admite 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.
Conclusión
以上是关于abstracción de cuentas的一些信息。如果你有任何疑问，欢迎在Twitter上与我联系。
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.
22 me gusta
Recompensa
22
7
Compartir
Comentar
0/400
EthMaximalist
· 07-24 00:42
La conferencia no aclaró nada.
Ver originalesResponder0
RugDocScientist
· 07-23 14:29
Otra ola de clases de marketing.
Ver originalesResponder0
AirdropSweaterFan
· 07-22 12:12
¡Jugar con múltiples cadenas AA es increíble!
Ver originalesResponder0
RiddleMaster
· 07-22 12:11
¡La firma abstracta es increíble!
Ver originalesResponder0
liquidation_surfer
· 07-22 12:00
¿Otra vez cupones de clip?
Ver originalesResponder0
RugPullProphet
· 07-22 11:51
No se puede decir con certeza si el proyecto estará el próximo año.
Ver originalesResponder0
SnapshotDayLaborer
· 07-22 11:46
¿Cuándo se podrá hacer una transferencia con un solo botón?
Análisis de la tecnología de abstracción de cuentas multichain: comparación entre ERC-4337 y AA nativo
Revelando el futuro: análisis de la abstracción de cuentas multichain
Del 8 al 11 de julio, se celebró la conferencia de la comunidad de Ethereum en Bruselas, el evento anual de Ethereum más grande de Europa, centrado en la tecnología y la comunidad.
En esta conferencia, más de 350 líderes de opinión de primera línea en la industria blockchain dieron discursos, incluyendo una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multicanal".
Puntos clave de la presentación:
La abstracción de cuentas (AA) tiene dos puntos clave: la abstracción de firma y la abstracción de pago. La abstracción de firma permite a los usuarios elegir cualquier mecanismo de verificación, mientras que la abstracción de pago admite múltiples opciones de pago para transacciones. Esta flexibilidad mejora la seguridad y la experiencia del usuario.
Las funciones de punto de entrada en la etapa de "verificación" de ERC-4337 y AA nativo son fijas, mientras que en la etapa de "ejecución", solo el punto de entrada de AA nativo es fijo. Las limitaciones para verificar transacciones y los pasos para ejecutar transacciones varían según la implementación.
Al implementar ERC-4337 en cadenas compatibles con EVM, las diferencias en el protocolo del diseño de Rollup y la forma de calcular direcciones son dos diferencias clave, lo que provoca que surjan algunos detalles de desarrollo sutiles al implementar ERC-4337 entre L1 y L2.
A continuación se presenta el texto completo del discurso:
Hola a todos, hoy voy a presentar el concepto de ERC-4337 y AA nativo, discutir las diferencias entre ellos y analizar en detalle las principales diferencias del estándar 4337 en L1 y L2.
abstracción de cuentas introducción
1. Definición de abstracción de cuentas
La abstracción de cuentas(AA) incluye principalmente dos puntos clave: la abstracción de firmas y la abstracción de pagos.
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.
2. 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.
3. Introducción a 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 varias redes de blockchain:
Diferencias entre ERC-4337 y AA nativo
1. Rol del sistema operativo
AA OS necesita resolver los siguientes problemas:
En ERC-4337, estos roles se completan en colaboración a través del Bundler y el 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 Sequencer se encarga 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 nuevos bloques, 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 del contrato de cuenta es similar en diferentes implementaciones, estos puntos de entrada solo pueden ser llamados por el AA OS:
En ERC-4337 y AA nativa, la función del 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 restricciones de costo (en esencia, 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 bundler (EIP-4337) o los operadores/ordenadores (AA nativo).
EIP-4337 define qué códigos de operación están prohibidos y cómo se limita el acceso a la memoria. 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:
La lógica del contrato no puede acceder a variables globales, como el número de bloque. StarkNet tampoco permite llamadas a contratos externos.
4. Limitaciones de los pasos de ejecución
En zkSync, realizar 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 desplegar un contrato 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, no hay restricciones especiales en la fase de ejecución.
5. Número aleatorio
6. Usar la primera transacción para implementar
7. diseño especial en zkSync
Si transfieres ETH directamente de un EOA de Ethereum a zkSync, no necesitas desplegar un contrato de cuenta personalizado, recibirás una cuenta predeterminada con la misma dirección. Esta cuenta puede funcionar como un EOA de Ethereum y también está controlada por la clave privada correspondiente del EOA de Ethereum.
Este tipo de cuenta es la versión None en lugar de version1. No puedes llamar a las funciones de DefaultAccount, ya que no ha desplegado ningún código en el espacio del kernel.
La diferencia entre el 4337 de L1 y el 4337 de L2
Hay dos diferencias clave en la implementación de ERC-4337 en cadenas compatibles con EVM: diferencias de protocolo y diferencias de dirección.
1. Diferencias en el 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 a 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. 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 que puede pasar desapercibido y que podría causar que las direcciones de contrato de cuenta sean diferentes entre las implementaciones de ERC-4337 en Ethereum y L2.
La cuestión clave es la adición de nuevos códigos de operación en un hard fork. Por ejemplo, si la cadena L2 no admite 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.
Conclusión
以上是关于abstracción de cuentas的一些信息。如果你有任何疑问，欢迎在Twitter上与我联系。