Análisis de la abstracción de cuentas multichain: explorando el futuro de la encriptación de infraestructura
Del 8 al 11 de julio de 2024, se llevará a cabo en Bruselas, Bélgica, la conferencia anual de Ethereum (EthCC), el evento más grande de Ethereum en Europa, con un enfoque en el desarrollo técnico y comunitario.
La séptima conferencia de la comunidad de Ethereum (EthCC 7) invitó a más de 350 líderes de opinión de primera línea en la industria de la blockchain a dar conferencias. Alfred, un desarrollador de imToken Labs, fue invitado a participar y dio una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multichain".
Resumen de los puntos de la presentación
Los dos núcleos de la abstracción de cuentas (AA): abstracción de firmas y abstracción de pagos. La abstracción de firmas permite a los usuarios elegir cualquier mecanismo de verificación, mientras que la abstracción de pagos ofrece múltiples opciones de pago para las transacciones, mejorando así la seguridad y la experiencia del usuario.
Las funciones de punto de entrada en la etapa de "verificación" de ERC-4337 y AA nativa son fijas, pero en la etapa de "ejecución", solo AA nativa mantiene un punto de entrada fijo. Las diferentes formas de implementación tienen características particulares en las restricciones de transacciones de verificación y en los pasos de ejecución de transacciones.
Al implementar ERC-4337 en cadenas compatibles con EVM, existen dos diferencias clave: las diferencias en el protocolo del diseño de Rollup y las diferencias en la forma de calcular las direcciones. Estas diferencias conducen a algunos detalles de desarrollo que son fácilmente pasados por alto al implementar ERC-4337 entre L1 y L2.
Abstracción de cuentas: introducción
1. Definición de la abstracción de cuentas
La abstracción de cuentas (AA) incluye principalmente dos puntos clave:
Abstracción de firma: los usuarios pueden elegir libremente el mecanismo de verificación, ya no limitándose a algoritmos de firma digital específicos (como ECDSA).
Abstracción de pagos: los usuarios pueden utilizar diversas opciones de pago de transacciones, como pagar con activos ERC-20 en lugar de activos nativos, o ser patrocinados por terceros para realizar transacciones.
Esta flexibilidad mejora significativamente la seguridad y la experiencia del usuario. La abstracción de cuentas tiene como objetivo lograr estos dos objetivos fundamentales de diversas maneras.
2. Análisis de ERC-4337
Actualmente, las cuentas de propiedad externa (EOA) en el protocolo de Ethereum tienen algunas limitaciones, como métodos de firma fijos y diseño de pagos. ERC-4337 resuelve 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 llamando a la función handleOps.
Contrato EntryPoint: Este contrato es similar a un sistema operativo, y las principales funciones que maneja en el procesamiento de transacciones 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 cuenta 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. 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.
Seguimiento de la abstracción de cuentas nativas de ERC-4337: StarkNet y zkSync Era
Cuenta nativa de abstracción 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:
¿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 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 a los operadores/ordenadores del servidor oficial, en lugar de a Bundler y EntryPoint Contract.
En StarkNet, el Sequencer es responsable de manejar todas estas tareas.
La principal diferencia entre zkSync 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 de contrato de cuenta es similar en diferentes implementaciones, estos puntos de entrada solo pueden ser llamados por AA OS:
ERC-4337: verificación de operaciones del usuario
zkSync: validación de transacciones, pago de transacciones, ejecución de transacciones
En ERC-4337 y AA nativo, 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 nativo es fijo.
3. Limitaciones de los pasos de verificación
Dado que no hay límites de costo para validar transacciones, un atacante podría llevar a cabo un ataque DoS en el pool de memoria, afectando así al agrupador (EIP-4337) o a los operadores/ordenadores (AA nativo).
EIP-4337 define los códigos de operación prohibidos y cómo limitar el acceso al almacenamiento. zkSync Era ha relajado el uso de algunos OpCode:
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:
ranura de almacenamiento perteneciente a la dirección A
espacio de almacenamiento perteneciente a cualquier otra dirección A
Almacén de la ranura keccak256(A || X) que pertenece a cualquier otra dirección: esto significa usar directamente la dirección como clave en el mapeo, 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 del contrato no puede acceder a variables globales, como el número de bloque. StarkNet tampoco permite llamadas de contratos externos.
4. Limitaciones de los pasos de ejecución
En zkSync, ejecutar 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 de manera consciente 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 diferencia 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 la implementación
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.
7. diseño especial en zkSync
Si transfieres ETH directamente desde un 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 un EOA de Ethereum y está controlada por la clave privada del EOA de Ethereum correspondiente.
Este tipo de cuenta es de la versión None en lugar de version1. No puedes llamar a las funciones de DefaultAccount porque no se ha implementado ningún código en el espacio del núcleo.
Diferencias entre L1 4337 y L2 4337
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 cargar datos a L1 para la seguridad y la liquidación. En el contexto de ERC-4337, los costos asociados con este proceso de carga, como las tarifas de seguridad de L1 y las tarifas de blob, deben incluirse en el Gas de prevalidación. Determinar los costos de carga apropiados en el Gas de prevalidación es un desafío importante.
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, 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 contratos de cuentas en las implementaciones de ERC-4337 entre Ethereum y L2 sean diferentes.
La cuestión clave es agregar 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 dará lugar a 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.
7 me gusta
Recompensa
7
4
Compartir
Comentar
0/400
SigmaValidator
· hace11h
La abstracción de cuentas es solo para divertirse.
Ver originalesResponder0
NeverPresent
· hace11h
¿Es tan alcista la abstracción de pagos?
Ver originalesResponder0
GateUser-beba108d
· hace11h
No sirve de nada, solo es hablar sin hacer.
Ver originalesResponder0
StableNomad
· hace11h
meh, otra charla de AA... me recuerda a las afirmaciones de "seguridad" de Celsius, para ser sincero
Análisis de la abstracción de cuentas multichain: diferencias y desafíos entre ERC-4337 y AA nativo
Análisis de la abstracción de cuentas multichain: explorando el futuro de la encriptación de infraestructura
Del 8 al 11 de julio de 2024, se llevará a cabo en Bruselas, Bélgica, la conferencia anual de Ethereum (EthCC), el evento más grande de Ethereum en Europa, con un enfoque en el desarrollo técnico y comunitario.
La séptima conferencia de la comunidad de Ethereum (EthCC 7) invitó a más de 350 líderes de opinión de primera línea en la industria de la blockchain a dar conferencias. Alfred, un desarrollador de imToken Labs, fue invitado a participar y dio una charla titulada "Revelando el futuro: análisis de la abstracción de cuentas multichain".
Resumen de los puntos de la presentación
Los dos núcleos de la abstracción de cuentas (AA): abstracción de firmas y abstracción de pagos. La abstracción de firmas permite a los usuarios elegir cualquier mecanismo de verificación, mientras que la abstracción de pagos ofrece múltiples opciones de pago para las transacciones, mejorando así la seguridad y la experiencia del usuario.
Las funciones de punto de entrada en la etapa de "verificación" de ERC-4337 y AA nativa son fijas, pero en la etapa de "ejecución", solo AA nativa mantiene un punto de entrada fijo. Las diferentes formas de implementación tienen características particulares en las restricciones de transacciones de verificación y en los pasos de ejecución de transacciones.
Al implementar ERC-4337 en cadenas compatibles con EVM, existen dos diferencias clave: las diferencias en el protocolo del diseño de Rollup y las diferencias en la forma de calcular las direcciones. Estas diferencias conducen a algunos detalles de desarrollo que son fácilmente pasados por alto al implementar ERC-4337 entre L1 y L2.
Abstracción de cuentas: introducción
1. Definición de la abstracción de cuentas
La abstracción de cuentas (AA) incluye principalmente dos puntos clave:
Esta flexibilidad mejora significativamente la seguridad y la experiencia del usuario. La abstracción de cuentas tiene como objetivo lograr estos dos objetivos fundamentales de diversas maneras.
2. Análisis de ERC-4337
Actualmente, las cuentas de propiedad externa (EOA) en el protocolo de Ethereum tienen algunas limitaciones, como métodos de firma fijos y diseño de pagos. ERC-4337 resuelve 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. 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:
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 a los operadores/ordenadores del servidor oficial, en lugar de a Bundler y EntryPoint Contract.
En StarkNet, el Sequencer es responsable de manejar todas estas tareas.
La principal diferencia entre zkSync 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 de contrato de cuenta es similar en diferentes implementaciones, estos puntos de entrada solo pueden ser llamados por AA OS:
En ERC-4337 y AA nativo, 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 nativo es fijo.
3. Limitaciones de los pasos de verificación
Dado que no hay límites de costo para validar transacciones, un atacante podría llevar a cabo un ataque DoS en el pool de memoria, afectando así al agrupador (EIP-4337) o a los operadores/ordenadores (AA nativo).
EIP-4337 define los códigos de operación prohibidos y cómo limitar el acceso al almacenamiento. zkSync Era ha relajado el uso de algunos OpCode:
4. Limitaciones de los pasos de ejecución
En zkSync, ejecutar 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 de manera consciente 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 la implementación
7. diseño especial en zkSync
Si transfieres ETH directamente desde un 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 un EOA de Ethereum y está controlada por la clave privada del EOA de Ethereum correspondiente.
Este tipo de cuenta es de la versión None en lugar de version1. No puedes llamar a las funciones de DefaultAccount porque no se ha implementado ningún código en el espacio del núcleo.
Diferencias entre L1 4337 y L2 4337
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 cargar datos a L1 para la seguridad y la liquidación. En el contexto de ERC-4337, los costos asociados con este proceso de carga, como las tarifas de seguridad de L1 y las tarifas de blob, deben incluirse en el Gas de prevalidación. Determinar los costos de carga apropiados en el Gas de prevalidación es un desafío importante.
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, 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 contratos de cuentas en las implementaciones de ERC-4337 entre Ethereum y L2 sean diferentes.
La cuestión clave es agregar 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 dará lugar a un cambio en el bytecode, incluso si el código de Solidity es el mismo.