Escrito por Kiwi Yao, investigador @OKX Ventures
Las soluciones de abstracción de cuentas (AA) de multicadena son una forma nueva e innovadora de interactuar con múltiples blockchains. Permiten a los usuarios crear y administrar cuentas en múltiples blockchains sin tener que preocuparse por los detalles técnicos subyacentes, como tener suficientes tokens nativos para pagos de gas. Esto hace que sea mucho más fácil para los usuarios comenzar con la tecnología blockchain y usar múltiples blockchains simultáneamente. Hay dos tipos principales de soluciones de AA multicadena: soporte nativo y compatibilidad ERC-4337.
El soporte nativo se produce cuando una blockchain admite directamente AA multicadena. La compatibilidad con ERC-4337 se produce cuando una blockchain o una solución de escalado de capa 2 utiliza un contrato inteligente para implementar AA multicadena. En este artículo, exploraremos tanto el soporte nativo como la compatibilidad ERC-4337 para soluciones AA multicadena. También discutiremos los beneficios y desventajas de cada enfoque.
Redes compatibles con la abstracción de cuentas ERC-4337
Arbitrum
Arbitrum activó oficialmente los puntos finales de AA en Arbitrum One y Arbitrum Nova luego de la adopción de la propuesta AIP-2. La propuesta introduce un nuevo punto final RPC: eth_sendRawTransactionConditional: está diseñado específicamente para satisfacer las necesidades de los bundlers ERC-4337.
Polygon
Polygon cumple con ERC-4337 y lo logra aprovechando soluciones como Biconomy, Gas Station Network (GSN), Infura y Gelato para metatransacciones. Además, zkEVM de Polygon admite AA a través de ERC-4337, lo que permite a los usuarios pagar con cualquier token.
Optimism
Actualmente, varias infraestructuras de AA están disponibles en la red principal de OP a través de proyectos como Alchemy, Biconomy, CyberConnect, Pimlico y Stackup, aunque aún no se ha publicado información arquitectónica detallada.
BNB
En la hoja de ruta técnica de BNB Chain para 2023, el equipo menciona el establecimiento de una infraestructura de AA. También se confirma la compatibilidad con ERC-4337, y próximamente se publicarán más detalles.
Abstracción de cuenta nativa
Starknet
Starknet admite la AA de forma nativa al representar todas las cuentas como cuentas de contrato (CA) o cuentas inteligentes. Los objetivos de admitir la AA de forma nativa incluyen la abstracción de firmas y la abstracción de pagos. Su objetivo es permitir que diferentes contratos de cuentas utilicen diversos esquemas de validación de firmas y diferentes modelos de pago para las transacciones. Al hacerlo, la experiencia de administrar la cuenta mejorará enormemente ya que las personas ahora tienen más opciones con respecto a la validación de firmas y el pago de un tercero o contrato inteligente.
Flujo de transacciones de Starknet
Cuando se selecciona una transacción para agregarla a un bloque, el secuenciador la selecciona y la ejecuta. La ejecución de la transacción se produce en dos etapas. Primero, el secuenciador solicita al contrato de la cuenta que valide la transacción. Luego, solicita al contrato de cuenta que lo ejecute. Estas dos etapas están codificadas en dos funciones separadas en el contrato de cuenta: validación y ejecución.
La distinción entre estas etapas permite a Starknet OS garantizar el pago al secuenciador. Para evitar un ataque de denegación de servicio (DoS) en el grupo de transacciones de Starknet y llenarlo con transacciones no válidas, Starknet exige que un nodo que acepte una transacción simule localmente el estado conocido antes de agregar la transacción al grupo y transmitirla a otros nodos y secuenciadores. Al completar la simulación, la transacción se puede ingresar al grupo y propagarse en la red.
Fuente: Starknet
Starknet AA frente a ERC-4337 AA
Starknet elimina la complejidad adicional introducida por el bundler y designa al secuenciador para que cumpla la función del bundler. Esto es diferente a la solución de AA de ERC-4337, que requiere bundlers para ejecutar operaciones de usuario (operaciones de usuario)
En comparación con la solución de AA de ERC-4337, Starknet no incorpora un protocolo de abstracción de tarifas de transacción similar al de un paymaster.
Starknet tampoco distingue entre transacciones regulares y operaciones de usuario, lo que simplifica el proceso.
Una diferencia notable está en la implementación. Starknet implementa la CA primero antes de poder invocarla. Esencialmente, Starknet requiere que las cuentas con saldos de tokens creen una nueva CA llamando a una función especializada 'deploy_account'. Este contrato de cuenta implementada puede pagar gas. Comparativamente, la solución de AA de ERC-4337 no requiere implementación previa. El bundler implementa una CA ejecutando una transacción operativa de usuario con un parámetro initCode no nulo. No se requiere una cuenta con un saldo simbólico para el proceso de implementación y el paymaster puede pagar la tarifa de gas.
zkSync
zkSync admite la AA nativa y ofrece compatibilidad con la Ethereum Virtual Machine (EVM). Al igual que Starknet, zkSync apunta a la abstracción de firmas y pagos, admitiendo diferentes esquemas de verificación de firmas para varios contratos de cuentas y diversos modelos de pago y formas de tokens para transacciones.
Flujo de transacciones de zkSync
El flujo de transacciones de zkSync implica que el individuo envíe la transacción firmada al operador, que luego se envía al gestor de arranque para su validación. Después de la validación y la adquisición de la tarifa, el gestor de arranque llama a la CA para ejecutar la transacción.
AA de zkSync frente a AA de ERC-4337
A diferencia de la solución de AA de ERC-4337, zkSync no distingue entre cuentas de propiedad externa (EOA) y CA.
zkSync permite que la función validateTransaction llame a contratos externos implementados. Esta es una característica que está restringida en Ethereum ya que puede crear un cambio de estado que haga que se apruebe la validación de la transacción y que falle el aspecto de ejecución de la transacción.
Otra diferencia es que zkSync permite que la función validateTransaction y el paymaster llamen al almacenamiento externo de la CA que emitió esta transacción. Por ejemplo, el saldo de tokens de la CA en el contrato externo se puede ver gracias a la función Paymaster y ValidarTransaction. Por el contrario, Ethereum prohíbe tal función.
Comparaciones de soluciones de AA entre redes compatibles con zkSync, Starknet y ERC-4337
Similitudes
Las redes compatibles con zkSync, Starknet y ERC-4337 comparten procesos de AA similares. Estos incluyen la fase de verificación, el mecanismo de tarifas (pagado mediante contrato de cuenta o paymaster) y la fase de ejecución. Además, las interfaces de billetera de contratos inteligentes se clasifican en las funciones validateTransaction y executeTransaction.
zkSync, Starknet, y ERC-4337 manejan DoS Attacks de forma similar. La lógica de contrato de zkSync sólo puede tocar sus propios slots, y su lógica de contrato no puede usar variables globales. De manera similar, el secuenciador de Starknet requiere una emulación local antes de agregar transacciones al grupo de memoria y transmitirlas. Por último, la operación de usuario de ERC-4337 pone un límite de gas en el paso validateUserOp y requiere que el paymaster prometa tokens.
Diferencias
La mayor diferencia sería que zkSync y StarkNet son AA nativos con diferencias arquitectónicas con respecto a las redes compatibles con ERC-4337.
Con respecto al consumo de gas en cadena, zkSync y StarkNet son soluciones de escalamiento de capa 2 que deben considerar los costos acumulados.
Existen diferentes roles con respecto a la ejecución de la AA. La arquitectura zkSync tiene un operador y un gestor de arranque (contrato de sistema) que trabajan juntos para cumplir con las operaciones del usuario. Para StarkNet, el secuenciador maneja las operaciones del usuario, sin mecanismos de empaquetado ni pago. Por último, las redes compatibles con ERC-4337 tienen diferentes arquitecturas que involucran bundlers y contratos de punto de entrada.
Otra diferencia clave es si las transacciones se pueden enviar antes de implementar la CA. Tanto en StarkNet como en zkSync, el contrato de punto de entrada no tiene un campo initCode que le permita implementar la CA para el individuo. Esto hace que ninguno de ellos pueda enviar transacciones antes de que se implemente la cuenta.
Por último, existe una diferencia en la llamada de contratos externos. zkSync permite que la función validateTransaction llame a contratos externos implementados. Sin embargo, tanto las redes compatibles con ERC-4337 como Starknet no lo permiten.
Diferencia en paymasters
Starknet no tiene interfaz de pago
Para redes compatibles con ERC-4337, la interfaz de pago define validatePaymasterOp. Esto define la lógica para que el paymaster pague una transacción. La interfaz también utiliza la función postOp, que garantiza que el paymaster pueda extraer la compensación de la tarifa de gas después de ejecutar la transacción. El paymaster necesita depositar Ethereum en el contrato de punto de entrada como forma de pago de gas y promete Ethereum en el contrato de punto de entrada para evitar que los bots creen lotes maliciosos.
zkSync es similar a las redes compatibles con ERC-4337, donde la interfaz define las funciones validatePaymasterOp y postOp. Las definiciones son similares a ERC-4337 pero esta parte de la función aún no se ha implementado. A diferencia del paymaster de ERC-4337, el paymaster de zkSync no comenzará la ejecución hasta que llame a postTransaction cuando tenga suficiente gas. Por otro lado, el paymaster de ERC-4337 no llamará a postOp si validarPaymasterUserOp no devuelve un contexto.
Tabla de comparación
¿Necesitas una referencia rápida para descubrir la diferencia entre soporte nativo y redes con compatibilidad ERC-4337? Consulta nuestra tabla a continuación.
Comparación | ERC-4337 | Starknet | zkSync |
|---|---|---|---|
Cuenta AA | Contrato inteligente | Protocolo nativo | Protocolo nativo |
Lógica de proceso | Fase de verificación → Mecanismo de tarifas (pagado mediante contrato de cuenta o paymaster) → Fase de ejecución | ||
Proceso de ejecución/invocación | Bundler → punto de entrada | Secuenciador | Operador → bootloader |
Papel en la determinación del orden de las transacciones | Bundler | Secuenciador | Operador |
Papel en la determinación del gas | Bundler | Secuenciador | Operador |
Consumo de tarifa de gas | Capa 1 | Capa 1 on-chain + capa 2 | Capa 1 on-chain + capa 2 |
¿Se pueden enviar transacciones antes de implementar el contrato de cuenta? | Sí | No | No |
Reglas de validación del paymaster | Lógica definida a través de validatePaymasterOp y postOp, el paymaster necesita depositar y hacer staking de Ether | Sin paymaster | Lógica definida a través de validatePaymasterOp y postOp, donde la lógica de llamada postOp es ligeramente diferente de Ethereum |
¿Se pueden llamar contratos externos? | No | No | Sí |
Cómo mitigar las amenazas DoS | Las operaciones de usuario imponen una limitación de gas en el paso de validación de UserOp y el paymaster debe hacer staking de tokens | Las transacciones deben agregarse a mempool y simularse localmente antes de transmitirlas. | Solo se permite tocar sus propios slots, no se pueden usar variables globales. |
Conclusión
A medida que Ethereum presenta la AA, somos testigos de que muchas otras redes siguen su ejemplo al abordar muchos problemas que podrían hacer que la adopción masiva sea más desafiante. Con la AA multicadena, los ecosistemas competidores podrían estar demostrando que no se quedan atrás en la resolución de problemas como la inflexibilidad del pago de gas y la dependencia de claves privadas.
¿La AA de multicadena ha despertado tu interés en explorar el espacio Web3 con nosotros? Descubre cómo OKX integrará la AA en nuestra billetera multicadena.
