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 la Conferencia de la Comunidad de Ethereum (EthCC) en Bruselas, Bélgica. Como el evento anual más grande de Ethereum en Europa, esta conferencia se centrará en el desarrollo tecnológico y comunitario.
En la presente Conferencia de la Comunidad de Ethereum (EthCC 7), más de 350 líderes de opinión de primera línea de la industria blockchain dieron discursos. Entre ellos, un desarrollador de blockchain fue invitado a participar y pronunció un discurso sobre el tema "Revelando el futuro: análisis de la abstracción de cuentas multichain".
Resumen de los puntos de la presentación
La abstracción de cuentas (AA) incluye 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 ofrece múltiples opciones de pago para transacciones. Esta flexibilidad mejora significativamente la seguridad y la experiencia del usuario.
ERC-4337 y AA nativa tienen funciones de punto de entrada fijas en la fase de verificación, pero en la fase de ejecución, solo AA nativa mantiene un punto de entrada fijo. Diferentes formas de implementación tienen características propias 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, se enfrentan principalmente a dos grandes desafíos: las diferencias de protocolo en el diseño de Rollup y las diferencias en la forma de calcular direcciones. Estas diferencias resultan en algunos detalles de desarrollo que son difíciles de detectar al implementar ERC-4337 entre L1 y L2.
Abstracción de cuentas: introducción
Definición de la abstracción de cuentas
La abstracción de cuentas (AA) incluye principalmente dos conceptos clave:
Abstracción de firma: los usuarios pueden elegir libremente cualquier mecanismo de verificación que deseen, sin estar limitados a algoritmos de firma digital específicos (como ECDSA).
Abstracción de pagos: los usuarios pueden utilizar múltiples formas de pagar las tarifas de transacción, como usar tokens ERC-20 en lugar de tokens nativos, o ser patrocinados por un tercero para la transacción.
Esta flexibilidad no solo mejora la seguridad, sino que también optimiza la experiencia del usuario. El objetivo de la abstracción de cuentas es lograr estos dos conceptos centrales de múltiples maneras.
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 un diseño de pago. ERC-4337 aborda estos problemas al introducir métodos más flexibles de gestión de cuentas y procesamiento de transacciones.
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 asegurarte de que userOp obtenga la autorización del propietario de la cuenta.
Cobro de tarifas.
Llamar a la función execute del contrato de cuenta para ejecutar la operación objetivo de userOp.
Introducción a AA nativo
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.
Cumplimiento de la abstracción de cuentas nativa ERC-4337: StarkNet y la era de zkSync
Cuenta nativa con diseño de privacidad: Aztec
Diferencias entre ERC-4337 y AA nativo
rol del sistema operativo
El sistema operativo AA necesita resolver los siguientes problemas:
Decisor del precio del gas
Decisor del orden de las transacciones y posición en la memoria del pool
El activador de la función del punto de entrada
Factores determinantes del proceso de procesamiento de transacciones
En ERC-4337, estos roles son realizados en conjunto por el Bundler y el EntryPoint Contract.
En AA nativo, 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 característica de zkSync Era es que el operador necesita trabajar en conjunto con el bootloader (contrato del sistema). El bootloader se encarga de abrir nuevos bloques, definir los parámetros del bloque y los parámetros de Gas, y recibir las transacciones del operador para su verificación.
interfaz de contrato
Debido a que hay 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 de usuario
zkSync: verificación de transacciones, pago de transacciones, ejecución de transacciones
En ERC-4337 y AA nativa, la función de punto de entrada de 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.
limitaciones de los pasos de verificación
Debido a que la verificación de transacciones no tiene límites de costos, un atacante podría llevar a cabo un ataque DoS en el grupo de memoria, lo que afectaría a los empaquetadores (EIP-4337) o a los operadores/ordenadores (AA nativa).
EIP-4337 define los códigos de operación prohibidos y las restricciones de 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.
La lógica del contrato no puede acceder a variables globales, como el número de bloque.
StarkNet no permite llamadas de contratos externos.
restricciones de los pasos de ejecución
En zkSync, ejecutar una llamada del sistema requiere confirmar la existencia de una bandera del sistema. Por ejemplo, aumentar el nonce requiere interactuar con el NonceHolder, mientras que implementar un contrato requiere interactuar con el ContractDeployer.
ERC-4337 y StarkNet no tienen restricciones especiales en la fase de ejecución.
procesamiento de números aleatorios
ERC-4337: El diseño del punto de entrada distingue entre valores de clave de 192 bits y valores de número aleatorio de 64 bits.
zkSync: el contrato del sistema NonceHolder gestiona el nonce, asegurando un incremento estricto.
StarkNet: el nonce también es estrictamente creciente, pero no hay un contrato específico que lo gestione.
primera implementación de transacción
ERC-4337: la estructura userOp incluye el campo initcode, que se utiliza para desplegar el remitente (contrato de cuenta) en el primer userOp.
StarkNet y zkSync: los usuarios deben enviar la primera transacción al operador/ordenador para desplegar el contrato de cuenta.
diseño especial de zkSync
En zkSync, si se transfiere ETH directamente desde una EOA de Ethereum, no es necesario desplegar un contrato de cuenta personalizado, el usuario recibirá una cuenta predeterminada con la misma dirección. Esta cuenta puede funcionar como una EOA de Ethereum y es controlada por la clave privada de la EOA de Ethereum correspondiente.
Este tipo de cuenta es version None en lugar de version1. Los usuarios no pueden llamar a las funciones de DefaultAccount porque no se ha desplegado ningún código en el espacio del núcleo.
Diferencias entre L1 y L2 de 4337
La implementación de ERC-4337 en cadenas compatibles con EVM presenta dos diferencias clave: diferencias de protocolo y diferencias de dirección.
diferencias en el protocolo
En el diseño de Rollup, L2 necesita subir datos a L1 para garantizar la seguridad y la liquidación. En ERC-4337, los costos relacionados con este proceso de carga (como la tarifa de seguridad de L1 y la tarifa 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 significativo.
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 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, normalmente asumimos que el cálculo de direcciones es consistente en todas las cadenas. Sin embargo, un detalle fácil de pasar por alto puede llevar a que las direcciones de contrato de cuenta entre la implementación de ERC-4337 en Ethereum y en L2 sean diferentes.
La cuestión clave radica en la adición de nuevos códigos de operación en el 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 durante la compilación, la introducción de push0 provocará un cambio en el bytecode, incluso si el código Solidity es el mismo.
Ver originales
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
8 me gusta
Recompensa
8
5
Compartir
Comentar
0/400
StableGenius
· hace15h
*bosteza* otra charla aa... he visto esta película antes, hablando empíricamente, son solo maxies de eth coping
Ver originalesResponder0
OfflineNewbie
· hace15h
Mira quién más está saltando.
Ver originalesResponder0
TokenVelocity
· hace15h
Hablaremos de todos los proyectos en la cadena más tarde...
Ver originalesResponder0
PessimisticLayer
· hace16h
Siento que es solo un tratamiento superficial y no aborda el problema de fondo.
La conferencia EthCC discute la abstracción de cuentas multichain: comparación técnica entre ERC-4337 y AA nativo.
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 la Conferencia de la Comunidad de Ethereum (EthCC) en Bruselas, Bélgica. Como el evento anual más grande de Ethereum en Europa, esta conferencia se centrará en el desarrollo tecnológico y comunitario.
En la presente Conferencia de la Comunidad de Ethereum (EthCC 7), más de 350 líderes de opinión de primera línea de la industria blockchain dieron discursos. Entre ellos, un desarrollador de blockchain fue invitado a participar y pronunció un discurso sobre el tema "Revelando el futuro: análisis de la abstracción de cuentas multichain".
Resumen de los puntos de la presentación
La abstracción de cuentas (AA) incluye 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 ofrece múltiples opciones de pago para transacciones. Esta flexibilidad mejora significativamente la seguridad y la experiencia del usuario.
ERC-4337 y AA nativa tienen funciones de punto de entrada fijas en la fase de verificación, pero en la fase de ejecución, solo AA nativa mantiene un punto de entrada fijo. Diferentes formas de implementación tienen características propias 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, se enfrentan principalmente a dos grandes desafíos: las diferencias de protocolo en el diseño de Rollup y las diferencias en la forma de calcular direcciones. Estas diferencias resultan en algunos detalles de desarrollo que son difíciles de detectar al implementar ERC-4337 entre L1 y L2.
Abstracción de cuentas: introducción
Definición de la abstracción de cuentas
La abstracción de cuentas (AA) incluye principalmente dos conceptos clave:
Abstracción de firma: los usuarios pueden elegir libremente cualquier mecanismo de verificación que deseen, sin estar limitados a algoritmos de firma digital específicos (como ECDSA).
Abstracción de pagos: los usuarios pueden utilizar múltiples formas de pagar las tarifas de transacción, como usar tokens ERC-20 en lugar de tokens nativos, o ser patrocinados por un tercero para la transacción.
Esta flexibilidad no solo mejora la seguridad, sino que también optimiza la experiencia del usuario. El objetivo de la abstracción de cuentas es lograr estos dos conceptos centrales de múltiples maneras.
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 un diseño de pago. ERC-4337 aborda estos problemas al introducir métodos más flexibles de gestión de cuentas y procesamiento de transacciones.
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 nativo
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:
Diferencias entre ERC-4337 y AA nativo
rol del sistema operativo
El sistema operativo AA necesita resolver los siguientes problemas:
En ERC-4337, estos roles son realizados en conjunto por el Bundler y el EntryPoint Contract.
En AA nativo, 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 característica de zkSync Era es que el operador necesita trabajar en conjunto con el bootloader (contrato del sistema). El bootloader se encarga de abrir nuevos bloques, definir los parámetros del bloque y los parámetros de Gas, y recibir las transacciones del operador para su verificación.
interfaz de contrato
Debido a que hay 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 de punto de entrada de 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.
limitaciones de los pasos de verificación
Debido a que la verificación de transacciones no tiene límites de costos, un atacante podría llevar a cabo un ataque DoS en el grupo de memoria, lo que afectaría a los empaquetadores (EIP-4337) o a los operadores/ordenadores (AA nativa).
EIP-4337 define los códigos de operación prohibidos y las restricciones de acceso a la memoria. zkSync Era ha relajado el uso de algunos códigos de operación:
restricciones de los pasos de ejecución
En zkSync, ejecutar una llamada del sistema requiere confirmar la existencia de una bandera del sistema. Por ejemplo, aumentar el nonce requiere interactuar con el NonceHolder, mientras que implementar un contrato requiere interactuar con el ContractDeployer.
ERC-4337 y StarkNet no tienen restricciones especiales en la fase de ejecución.
procesamiento de números aleatorios
primera implementación de transacción
diseño especial de zkSync
En zkSync, si se transfiere ETH directamente desde una EOA de Ethereum, no es necesario desplegar un contrato de cuenta personalizado, el usuario recibirá una cuenta predeterminada con la misma dirección. Esta cuenta puede funcionar como una EOA de Ethereum y es controlada por la clave privada de la EOA de Ethereum correspondiente.
Este tipo de cuenta es version None en lugar de version1. Los usuarios no pueden llamar a las funciones de DefaultAccount porque no se ha desplegado ningún código en el espacio del núcleo.
Diferencias entre L1 y L2 de 4337
La implementación de ERC-4337 en cadenas compatibles con EVM presenta dos diferencias clave: diferencias de protocolo y diferencias de dirección.
diferencias en el protocolo
En el diseño de Rollup, L2 necesita subir datos a L1 para garantizar la seguridad y la liquidación. En ERC-4337, los costos relacionados con este proceso de carga (como la tarifa de seguridad de L1 y la tarifa 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 significativo.
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 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, normalmente asumimos que el cálculo de direcciones es consistente en todas las cadenas. Sin embargo, un detalle fácil de pasar por alto puede llevar a que las direcciones de contrato de cuenta entre la implementación de ERC-4337 en Ethereum y en L2 sean diferentes.
La cuestión clave radica en la adición de nuevos códigos de operación en el 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 durante la compilación, la introducción de push0 provocará un cambio en el bytecode, incluso si el código Solidity es el mismo.