¿Cómo la comprensión de la abstracción de cuentas ERC4337 conducir a la evolución de las cuentas de Ethereum?

Autor: Rui

Como muchos han dicho, la tecnología de abstracción de cuentas (AA), especialmente ERC-4337, promete revolucionar la experiencia del usuario de Wallet de autocustodia y permitir que se amplíe para su adopción masiva. Sin embargo, a medida que se acerca mayo de 2023, debemos reconocer que la norma aún se encuentra en sus primeras etapas, con oportunidades y riesgos.

Tenga en cuenta que el contenido de este artículo puede quedar obsoleto rápidamente a medida que las actualizaciones evolucionan rápidamente, y este artículo se basa únicamente en mi opinión personal.

TL; DR

ERC4337:

El estándar AA aún se encuentra en sus primeras etapas, pero muchos creadores de innovación están trabajando para desarrollarlo aún más. Con el apoyo del ecosistema y la popularidad de grandes productos como MetaMask, podemos esperar que AA acelere su proceso de desarrollo y produzca resultados emocionantes.

L2:

La adopción de AA varía en las soluciones L2. Las L2 más grandes (por ejemplo, Optimism y Arbitrum) no son compatibles de forma nativa con AA, mientras que ZKSync y Starknet sí.

Servicio de empaquetado:

• Si somos alcistas en AA y todos los equivalentes de EVM alineados con Ethereum L2 no son compatibles con AA nativos, entonces el servicio Bundler es necesario para admitir AA en la red.
• La función de código abierto hace que el servicio Bundler no sea exclusivo, lo que dificulta la monetización. Para garantizar la estabilidad de la red, es necesario utilizar diferentes servicios de Bundler.
• Los paquetes privados se pueden monetizar personalizando la privacidad, la seguridad y otras características según las necesidades específicas.

Servicio Paymaster:

• El servicio Paymaster está relativamente centralizado (en comparación con el servicio Bundler), el contrato es de código abierto, pero el backend está cerrado.
• El servicio Paymaster tiene un modelo de monetización que se puede combinar con características como depósitos en moneda fiduciaria, intercambios, puentes, pagos automáticos, sesiones, tarifas de patrocinio, etc. para mejorar los escenarios de pago y así mejorar la usabilidad de la dApp.

Billetera AA y SDK:

• AA Wallet se puede evaluar desde la perspectiva del producto, incluido el sistema de gestión de claves secretas, la recuperación social, el patrocinio de la tarifa de gas, la sincronización de cuentas multicadena y la cadena de bloques compatible.
• Los beneficios de AA van más allá de proporcionar una experiencia de inicio de sesión fluida (Web3 Auth está alojado). AA también puede proporcionar una serie de beneficios a las dApps en interacciones complejas y personalizadas en la cadena.
• BD es la clave de esta batalla. La mayoría de las billeteras se dirigen a Defi, GameFi y tienen como objetivo obtener el apoyo del ecosistema, convencer a las grandes dApps y encontrar avances.
• Los modelos de monetización deben explorarse más a fondo. Es posible que el modelo To Business (To B) no genere mucho dinero y no acumule sus propios usuarios, mientras que el modelo To Customer (To C) necesita encontrar escenarios de alto valor y obtener ganancias basadas en el volumen. La integración de capacidades de conmutación y puente puede ser rentable, pero la clave es encontrar un modelo sostenible.

Más información sobre la billetera criptográfica

Clasificación

Hay dos tipos de cuentas en la red Ethereum: la billetera de cuenta de propiedad externa (EOA), como MetaMask, y la cuenta de contrato (CA), como Safe.

La principal diferencia entre una billetera EOA y una billetera de contrato es cómo se controla. Las billeteras EOA son controladas por usuarios individuales a través de claves privadas, mientras que las billeteras de contratos están controladas por contratos inteligentes. Mientras que los monederos EOA son más sencillos y se utilizan para gestionar las tenencias personales de criptoactivos, los monederos de contrato pueden tener reglas más complejas y pueden utilizarse para fines específicos.

DeBitcoin Insider

Puntos débiles

Los usuarios de EOA Wallet deben prestar atención a la protección de las claves privadas. Cualquier error u omisión cometida en la clave privada puede resultar en la pérdida de fondos, por lo que el uso de EOA Wallet es más costoso y arriesgado. Incluso los usuarios experimentados de criptoactivos pueden perder el control de sus cuentas debido a un solo error o movimiento descuidado. La complejidad de la operación, la imposibilidad de omitir la tarifa de gas o realizar el pago de la tarifa de gas y la funcionalidad limitada de la billetera son problemas que afectan a los usuarios.

Smart ContractWallet proporciona una solución a algunos de estos problemas, pero Ethereum actualmente requiere que todas las operaciones se empaqueten en transacciones de EOA protegidas por ECDSA. Esto conlleva tarifas de transacción adicionales y 21,000 tarifas de gas adicionales, y con ello posibles riesgos y complicaciones de centralización: los usuarios deben administrar dos cuentas y depositar ETH en EOA separadas para pagar las tarifas de gas, o depender de un sistema de retransmisión centralizado para pagar.

Estos puntos débiles dieron lugar a un nuevo estándar AA, ERC-4337.

ERC4337 propuestas:

Problema de CA

Hoy en día, todas estas cosas se pueden resolver con la billetera de contrato, pero Ethereum en sí requiere que todo esté empaquetado en transacciones derivadas de EOA protegidas por ECDSA, lo que resultará:

Tarifa de transacción adicional: Cada acción del usuario debe ser iniciada por EOA, lo que resulta en una tarifa de gas adicional de 21,000. Complejidad y centralización: Los usuarios deben depositar ETH en EOA separadas para pagar las tarifas de gas y administrar los saldos en ambas cuentas, o confiar en los sistemas Relay para pagar, que a menudo están centralizados.

A lo largo de los años, ha habido varios intentos de implementar la abstracción de cuentas en la cadena de bloques basada en Ethereum, como EIP-86 y EIP-2938. Sin embargo, ninguno de estos enfoques funciona, ya que todos requieren cambios en la capa de consenso, que es difícil de implementar.

Mecanismo 4337

ERC-4337 implementa la abstracción de cuentas mediante la introducción de un objeto de pseudotransacción de nivel superior denominado UserOperation, que es similar a los resúmenes en términos de conceptos de agrupación. Afortunadamente, este estándar nos permite crear abstracciones de cuentas sin cambiar la capa de consenso.

El diseño modular de EIP 4337 divide la abstracción de la cuenta Smart ContractWallet en varios puertos:

Bündler:

• Bundler es un EOA. Dado que todas las transacciones deben ser iniciadas por un EOA, Bundler permite a los usuarios activar transacciones de Smart ContractWallet sin tener que crear y recordar una clave privada de EOA.
• Qué hace el Bundler: Validar UserOperation, empaquetar un conjunto de objetos UserOperation en una sola “transacción de paquete”. Difunda el contenido de UserOperation autenticado a un grupo de memoria público o privado.
• Bundler también se beneficia financieramente al embolsarse la diferencia entre la tarifa de mayor prioridad y la tarifa de gas real después de que se ejecute la operación de usuario. De forma similar a la retransmisión de una transacción normal, el empaquetador obtiene MEV ordenando UserOperation en la transacción agrupada.

Punto de entrada:

• El punto de entrada es un contrato global al que todos los Bundlers deben llamar para ejecutar una UserOperation. El punto de entrada actúa como intermediario entre el Bundler y el Smart ContractWallet.
• Validar y ejecutar con handleOp: La función handleOp utiliza UserOperation como parámetro de entrada para validar primero la UserOperation en la cadena, comprobar si está firmada por el Smart ContractWalletAddress especificado y Wallet suficientes tarifas de gas para compensar al Bundler. Si la validación se realiza correctamente, los parámetros de entrada se ejecutan en función de la firma de la función.

El token que necesita depositar Smart ContractWallet paga tarifas de gas al Bundler: Cuando el Bundler activa un handleOp usando EOA, se incurre en una tarifa de gas. Smart ContractWallet puede pagar la tarifa de gas con su propio saldo o pedirle a Pymaster que la pague. Posible error: la tarifa de gas es insuficiente, se produce un error en el paso de validación e incluso si la tarifa de gas es suficiente, se puede producir un error en el paso de ejecución de UserOperation, como un error en tiempo de ejecución. Independientemente de si la ejecución se realiza correctamente o no, el contrato de punto de entrada pagará una tarifa de gas al Bundler para activar la función handleOp. El contrato de punto de entrada proporciona a Smart ContractWallet la capacidad de agregar o retirar tokens como garantía.

Billetera inteligente:

El contrato principal de Smart ContractWallet separa los pasos de validación y ejecución de UserOperation. Al desacoplarlo, el Bundler puede validar el UserOperation fuera de la cadena, filtrando las transacciones maliciosas sin tener que pagar tarifas de gas.

Los pasos de validación se definen en la función validateOp: la primera llamada a validateOp, el Bundler simula la validación fuera de la cadena, verifica la firma en UserOperation y garantiza que Smart ContractWallet tenga suficiente balance de gas, y la segunda llamada a validateOp es el contrato de punto de entrada, que realiza la verificación en cadena antes de ejecutar UserOperation.

Pagador:

• Paymaster define la lógica de abstracción de gas de Smart ContractWallet, incluido el uso del token fungible ERC20 para pagar las tarifas de gas de Ethereum, así como las transacciones sin tarifas de gas.
• Paymaster es un contrato inteligente implementado por una dApp que puede activar la validación de PaymasterOp.

Fábrica de carteras:

• Wallet Factory es un contrato público que crea Smart ContractWallet. Cuando la dirección de fábrica de la billetera y los nuevos parámetros de Smart ContractWallet se implantan en el initCode, el empaquetador activará la fábrica de billetera correspondiente para crear un contrato inteligente con los parámetros especificados. Los códigos populares de Wallet Factory están completamente examinados, por lo que es más seguro crear una billetera con Wallet Factory.
• Wallet Factory necesita apostar ETH en el punto de entrada y continuar sirviendo bien a UserOperations para obtener más tráfico de Bundler.
• Los usuarios pueden enviar una UserOperation rellena con initCode y solicitar al Bundler que cree una CA Wallet.
• Los usuarios pueden elegir Wallet Factory con parámetros personalizados específicos para personalizar su CA Wallet.

Agregadores de firmas:

• Los agregadores de firmas se utilizan para agregar las firmas de múltiples transacciones en bytes para una verificación y ejecución más rápidas de las transacciones. Diferentes Smart ContractWallet usan diferentes algoritmos de firma y primero deben usar el mismo algoritmo de firma para agregar UserOperations.
• Ahorre tarifas de gas: Dado que la computación criptográfica en cadena consume muchas tarifas de gas, los esquemas de firma agregada (como BLS) pueden ahorrar tarifas de gas al verificar en cadena.
• Bundler utiliza varios contratos de agregación de firmas para generar varias firmas agregadas, en lugar de validar un UserOperations a la vez.
• El empaquetador pasa la matriz UserOperation, la firma agregada y la dirección del agregador al punto de entrada, y cada reunión de grupo UserOperation llama a la función validateSignature de su agregador de firmas correspondiente.
• Después de la validación, el Bundler ejecutará este conjunto de UserOperations en Smart ContractWallet.
• Los agregadores también deben apostar Ethereum en el contrato de punto de entrada y mantener un buen historial de servicio UserOperation.

Ventajas de AA

Extracción de gases:

La extracción de gas no contiene transacciones de tarifas de gas y paga tarifas de gas con cualquier token ERC20. La lógica se puede ejecutar en el contrato Paymaster o a través de un relé. Para AA, muchos Smart ContractWallet pueden implementar contratos Paymaster que cumplan con EIP 4337 y apostar Token en el contrato de punto de entrada para ayudar a los usuarios a pagar las tarifas de gas.

Recuperación social:

En el caso de que la Clave Privada se pierda o se vea comprometida, el usuario puede autorizar la nueva Clave Secreta como el propietario legítimo de la Billetera. La lógica del inicio de sesión social y la recuperación social se define generalmente en el contrato principal de la Billetera. Se puede hacer de varias maneras, como correo electrónico, Multisig, MPC o SWIE (inicio de sesión con Ethereum).

Lote de transacciones:

El procesamiento por lotes de transacciones es una característica exclusiva de Smart ContractWallet que permite a los usuarios de Wallet ejecutar múltiples transacciones en una sola transacción en cadena.

Interacción entre cadenas e integración de puentes de conexión:

Actualmente, muchas billeteras están trabajando con proveedores externos para integrar los canales de depósito y retiro de moneda fiduciaria y los puentes de interacción entre cadenas en las billeteras. Estos canales de depósito y retiro y los puentes de interacción entre cadenas se pueden integrar aún más con el contrato de pago (Paymaster) en la extracción de gas.

Diseño modular:

Quizás una de las mayores fortalezas de AA es su servicio modular, donde Bundler, Paymaster y otras partes se pueden combinar de manera flexible.

Defectos en AA

De la acumulación

Tarifa de procesamiento relativamente alta:

El uso de ERC-4337 para realizar una transferencia simple es mucho más costoso que el uso de una billetera tradicional (a menudo denominada EOA) porque la primera requiere una llamada al contrato.

Sin embargo, en la red Rollup, una transferencia simple usando ERC-4337 puede ser más barata que EOA porque agrega firmas para reducir la cantidad de datos en la red principal.

Criterios aún no finalizados:

Desafíos como el aumento del vector de ataque debido a la ampliación de la escalabilidad de las transacciones, la posibilidad de errores desconocidos o riesgos de seguridad al migrar a nuevos estándares, la necesidad de un contrato de punto de entrada global sólido y seguro para garantizar que todas las transacciones se firmen y verifiquen correctamente, etc.

Capa 2

✅ * e ❌ indique si se admite AA nativo. *

**Optimismo: ❌ **

La versión 1 de Optimism tiene tres códigos de operación OVM para lograr la abstracción de la cuenta Smart ContractWallet. Sin embargo, por razones de coherencia y seguridad, la versión 2 elimina estos códigos de operación y no hay ninguna declaración oficial sobre la abstracción de cuentas compatibles.

**Arbitrum: ❌ **

Si bien actualmente hay algunos Smart ContractWallet construidos sobre Arbitrum, no hay una declaración oficial sobre el soporte de abstracción de cuentas.

**Starknet: ✅ **

Starknet solo tiene cuentas de contratos inteligentes con funciones de verificación y ejecución, y todas las cuentas deben implementar estas características para verificar las firmas y garantizar las tarifas de gas. Starknet prohíbe que la función de verificación llame al estado del contrato externo para evitar transacciones no ejecutadas. Sin embargo, existen algunas diferencias entre Starknet y Ethereum, como la falta de UserOperations, un protocolo de abstracción de tarifas de transacción similar a Paymaster y la necesidad de una cuenta con saldo de tokens para crear nuevos contratos. Además, el secuenciador de Starknet no puede cobrar tarifas de gas si falla una transacción verificada, mientras que Ethereum sí.

**zkSync: ✅ **

zkSync no distingue entre cuentas EOA y cuentas de contrato. Su modelo de cuenta es similar a EIP 4337 e incluye funciones validateTransactiom y uteTransaction independientes. La interfaz de Paymaster también incluye las funciones validateAndPayForPaymasterTransaction y postOp. Sin embargo, hay algunas diferencias, como la capacidad de llamar a contratos externos implementados y almacenamiento externo durante el proceso de validación. Paymaster también puede invocar el almacenamiento externo durante la validación de la transacción.

Infraestructura AA:

Actualmente, algunos proyectos excelentes como Stackup, Etherspot, Candide, Infinistism y Pimlico están tratando de construir infraestructura.

Servicio de empaquetado:

Constructor:

• Implementación de Golang de Stackup
• Implementación de Candide en Python
• Tipo de implementación de Infinitism
• Skandha - Implementación de tipo de Etherspot

Algunos consensos:

Servicio Público

La naturaleza de código abierto de la gran mayoría de los Bundlers los hace no exclusivos y no competitivos. Cualquier punto de conexión RPC puede ejecutar Bundler copiando el código fuente abierto.

• Difícil de monetizar

Incluso si el punto final RPC que ejecuta Bundler cobra tarifas de uso del servicio a través de claves secretas de API, los servicios de Bundler son más difíciles de monetizar que otras infraestructuras como Paymaster, un contrato de pago, porque Paymaster puede ganar fácilmente la diferencia en las tarifas al asociarse con proveedores de depósitos y retiros de terceros o proveedores de agregadores de protocolos de finanzas descentralizadas.

Infraestructura crítica

La validación y ejecución de UserOperations requiere tantos Bundlers como sea posible para una mejor descentralización. Dado que los únicos proveedores de servicios de Bundler de terceros actualmente son Stackup y eth-infinitism, necesitamos más proveedores de servicios de Bundler de este tipo.

Mecanismo**

Los empaquetadores entregan mensajes y propagan las acciones del usuario por su cuenta, de forma similar a los grupos de memoria compartida, sin tener que ponerse de acuerdo sobre asuntos específicos. Bundler tiene una característica importante para filtrar el spam y, por sus propias razones financieras, Bundler quiere monitorear tanto como sea posible para garantizar la seguridad del mempool.

Diferencias entre los servicios de Bundler:

• El servicio Bundler puede ser una infraestructura general o creado específicamente para Wallet. Los proyectos de billetera pueden priorizar la creación del paquete más básico, mientras que los proveedores externos deben crear paquetes modulares para varios escenarios.
• Al igual que EthereumNode, el servicio Bundler se implementa en un lenguaje de programación diferente para evitar puntos únicos de falla y beneficiar al ecosistema.
• El servicio Bundler admite mempools privados y públicos, y proporciona opciones de personalización para mempools privados.

Servicio Paymaster

• En comparación con el servicio Bundler, el servicio Paymaster está más centralizado, el contrato es Open Source, pero el backend está cerrado.
• El servicio Paymaster tiene un modelo de monetización que puede mejorar la usabilidad de las dApps al combinarse con depósitos de moneda fiduciaria, intercambios, puentes, pagos automáticos, sesiones, tarifas de patrocinio y otras características.

Billetera AA y SDK:

Evaluación del producto

• Sistema de gestión de claves secretas:
  • Lógica Multisig (segura): Solo se puede implementar la lógica Multisig 2/3 y 3/5;
  • Gestión sencilla de permisos (secuencial): puede establecer ponderaciones para las claves secretas y, a continuación, establecer umbrales para las cuentas operativas.
  • Gestión de permisos basada en roles (Unipass): Puede establecer pesos y roles para las claves secretas. Diferentes roles pueden realizar diferentes acciones. Cada rol también tiene un umbral correspondiente. Si se supera este umbral, se pueden aplicar los permisos del rol correspondiente.
• Métodos de recuperación social
• Patrocinio de la tarifa de gas: construye tu propio Relay o configura Bundler + Paymaster
• Sincronización de cuentas multicadena
• Unidad de dirección multicadena
• Blockchain compatible

Negocios

• Modelo de negocio: To b/ To B + To C / ToC
• Asociarse con dApps: Asociarse con dApps de infraestructura gigante como Stable Coin o Decentralized Finance en cada cadena
• Utilidad: Integre mercados de tokens no fungibles, plataformas de lanzamiento, etc.
• Apoyo externo: de la Fundación Ethereum u otras instituciones de capital riesgo de renombre