Ya sea un mercado alcista o un mercado bajista, el ecosistema Ethereum está en constante construcción y optimización automática. Entre ellos, Account Abstraction (AA) ha logrado un progreso importante en los últimos años y ha penetrado en todas las partes del ecosistema Ethereum, incluidas las aplicaciones, la infraestructura, los usuarios y los desarrolladores. Podemos prever que la adopción a gran escala de AA reducirá el umbral de uso de blockchain en su conjunto e introducirá la experiencia del usuario de web2 en la industria web3.
Para aprovechar la oportunidad del mercado AA potencialmente multimillonario, BlockPI planea integrar AA en sus servicios de infraestructura. A través de la integración y la innovación en el campo de AA, BlockPI se compromete a proporcionar a los usuarios de AA una forma más conveniente y eficiente de interactuar con las cuentas de billetera de contrato de blockchain, y espera convertirse en líder en esta industria.
En este artículo, el equipo de BlockPI profundizará en su comprensión de AA y compartirá ideas desde la perspectiva de un proveedor de servicios de infraestructura.
EOA y billetera de contrato
El concepto de AA se deriva de las limitaciones de las cuentas EOA. Una cuenta EOA (cuenta de propiedad externa) es una cuenta de usuario en Ethereum, representada por una clave pública (dirección de cadena de bloques) y a la que se accede a través de una clave privada. Es un componente importante del ecosistema Ethereum, que permite a los usuarios transferir dinero en blockchain o interactuar con contratos inteligentes. Sin embargo, para muchas personas, usar un EOA puede ser una tarea desafiante en sí misma. Además, la cuenta EOA actual todavía tiene algunos inconvenientes en el uso, lo que afecta la experiencia del usuario.
El primero es el tema de las tarifas del gas. Cada transacción le costará al usuario una cantidad considerable de ETH como tarifa de Gas (tome el precio de Gas de 25 Gwei como ejemplo, la tarifa de Gas para una simple transferencia de ETH es de aproximadamente 0,5 dólares estadounidenses, y será más costosa para la interacción del contrato o cuando el precio del Gas es más alto). Esto hace que las transacciones pequeñas sean muy costosas, especialmente durante los períodos de congestión severa de la red. Además, solo se puede usar ETH para pagar Gas, lo que significa que los usuarios deben tener ETH en sus billeteras, lo que constituye una alta barrera de entrada para muchos usuarios.
En segundo lugar, para algunas operaciones complejas que los usuarios quieren lograr, EOA debe confiar en otros contratos inteligentes. Por ejemplo, si un usuario desea establecer una transferencia periódica programada, el usuario debe transferir ETH a un contrato inteligente con esta función para lograr esta operación.
El tercer problema con EOA es el algoritmo de cifrado de firma fijo. La red Ethereum utiliza un algoritmo de firma digital llamado secp256k1 para garantizar la autenticidad y seguridad de las transacciones. Este algoritmo está codificado en el sistema y los usuarios no pueden optar por utilizar otros algoritmos de cifrado.
Además de los tres problemas anteriores, la relación vinculante entre la clave pública y la clave privada de EOA también es un problema. La clave privada es la única forma de que los usuarios accedan a EOA; si se pierde la clave privada, no se recuperará. Esto también significa que todos los activos dentro de la EOA asociados con ella serán irrecuperables.
Al mismo tiempo, EOA también tiene limitaciones a la hora de realizar ciertas tareas lineales. Por ejemplo, si un usuario desea aprobar (aprobar), intercambiar (intercambiar) y desaprobar tokens (desaprobar token) en una operación, se deben realizar tres transacciones separadas, lo cual es ineficiente y requiere mucho tiempo.
La buena noticia es que las billeteras de contrato pueden resolver todos los problemas anteriores. Una billetera de contrato es esencialmente un tipo específico de cuenta de contrato inteligente que implementa AA, que se puede usar como billetera de usuario en Ethereum. Y puede proporcionar a los usuarios una forma más flexible y personalizada de administrar fondos. Siempre que sea la lógica que puede realizar el contrato inteligente de Ethereum, la billetera del contrato puede realizar y proporcionar las funciones correspondientes.
Específicamente, las operaciones de billetera de contrato múltiple se pueden empaquetar en una transacción en cadena, y estas operaciones pueden compartir el costo de Gas de esta transacción. Si el tercero está dispuesto a pagar la tarifa de Gas, no hay necesidad de pagar Gas para los usuarios que utilizan la billetera de contrato. Las billeteras de contrato también pueden completar múltiples tareas lineales a la vez. Además, la billetera de contrato también es compatible con el algoritmo de cifrado de firmas personalizadas y establece la función de recuperación de billetera, etc.
A medida que continúa la discusión sobre las ventajas de las billeteras de contrato, la comunidad de Ethereum ha llevado a cabo una investigación a largo plazo sobre las billeteras de contrato. Aunque muchos EIP han explorado problemas relacionados con la abstracción de cuentas, a partir de 2021 no se ha establecido un estándar unificado. A continuación se muestran varios EIP representativos.
####EIP-86
Propuesto originalmente en 2017 por Vitalik Buterin. Este esquema implementa una serie de cambios con el propósito común de "resumir" la verificación de firma y la verificación de nonce, lo que permite a los usuarios crear "contratos de cuenta" que pueden realizar una verificación arbitraria de firma/nonce.
####EIP-2938
Presentado en 2020. El título de este EIP es Abstracción de cuenta. El concepto de AA está bien descrito en este EIP. Introduce un nuevo tipo de transacción, la transacción AA. La transacción es iniciada por la dirección del punto de entrada (dirección EntryPoint) y llama a la billetera de contrato AA. EIP-2938 proporciona una especificación unificada e introduce oficialmente la abstracción de la cuenta AA en el consenso de Ethereum. Específicamente, presenta dos nuevos códigos de operación, tres variables globales y una estructura de carga útil diferente al consenso de Ethereum.
####EIP-3074
Presentado en 2020. Este EIP introduce dos instrucciones EVM, AUTH y AUTHCALL. AUTH establece las variables de entorno de acuerdo con la autoridad de firma ECDSA. AUTHCALL envía la llamada como una cuenta autorizada. Esto permite que los contratos inteligentes envíen transacciones en nombre de EOA. Pero esto todavía no es una solución perfecta para AA. En el proceso de transacción de autorización, EIP-3074 tiene ciertas restricciones en la transmisión del valor original. Y si el usuario pierde el acceso al EOA, aún no hay forma de recuperar sus activos. Si se filtra la clave privada, el usuario debe transferir todos los activos a la nueva cuenta.
Ninguna de las propuestas anteriores se incorporó formalmente al protocolo Ethereum debido a la necesidad de cambios en la capa de consenso o porque las propuestas no eran lo suficientemente completas. Por lo tanto, la comunidad de Ethereum continuó explorando cómo introducir AA en el protocolo de Ethereum sin cambiar el consenso y finalmente propuso EIP4337.
ERC-4337
EIP-4337 se propuso originalmente en septiembre de 2021 y se autorizó como ERC-4337 en marzo de 2023. Sus autores incluyen a Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson y Tjaden Hess.
EIP-4337 es una propuesta disruptiva que introduciría AA sin cambiar el protocolo central de Ethereum. EIP-4337 eventualmente se convirtió en el estándar ERC-4337, que los constructores pueden usar para implementar sus propias billeteras de contratos inteligentes. Al mismo tiempo, el estándar también introduce una infraestructura adicional que incluye "Bundlers" y "UserOperation mempool". De esta forma, en realidad replica un mempool de Ethereum con funciones similares en la capa superior del sistema blockchain. Lo que envía el usuario ya no es una sola transacción, sino una UserOperation. Estas operaciones de usuario pueden empaquetarse en una sola transacción y enviarse a Ethereum.
La siguiente es una explicación técnica detallada de ERC-4337 en Ethereum [documentación oficial], con algunos comentarios útiles.
Roles clave de ERC-4337 y sus definiciones
UserOperation: describe la estructura de una transacción enviada en nombre de un usuario. Para evitar confusiones, no se denomina "transacción" y se enviará al Bundler para que se empaquete junto con otras operaciones de usuario como un paquete. Luego, el paquete se envía en cadena como una sola transacción.
Remitente: la cuenta del contrato que envía UserOperation. El contrato de billetera debe seguir el estándar ERC-4337 para configurar la interfaz IAccount.
EntryPoint: el contrato único global que ejecuta el paquete UserOperations. Puntos de entrada admitidos en la lista blanca de Bundlers/Clients. El equipo de Infinitism audita y aprueba el contrato para su implementación, y es responsable de manejar todas las operaciones de usuario y conectar los contratos con otros roles, incluidos Wallet Factory, Aggregator y Paymaster. El contrato está todo en la misma dirección en la cadena compatible con EVM.
Bundler: el nodo que empaqueta varias operaciones de usuario del mempool y crea la transacción EntryPoint.handleOps() (el nodo productor de bloques actual). El servicio Bundler puede ejecutarse independientemente de los nodos de blockchain y enviar operaciones de usuario empaquetadas a través de RPC.
Agregador: un contrato auxiliar en el que confían las cuentas para verificar las firmas agregadas. Agregadores de firmas admitidos en la lista blanca de Bundlers/Clients. Los agregadores deben configurar la interfaz IAggregator siguiendo el estándar ERC-4337.
Paymaster: un contrato inteligente que puede pagar Gas en su nombre. Si deposita suficiente ETH en el contrato EntryPoint, puede pagar al remitente el contrato inteligente por la tarifa de gas de UserOperation, implementando efectivamente la extracción de gas. Paymaster debe seguir el estándar ERC-4337 para configurar la interfaz de Paymaster. Paymaster puede llegar a un acuerdo con Sender. Por ejemplo, Sender paga USDC a Paymaster, y Paymaster usa ETH para pagar el gas de las operaciones de usuario que envía. De hecho, Paymaster puede elegir admitir cualquier
Simbólico
, incluyendo ERC-20
Simbólico
incluso otras cadenas
Simbólico
。
Wallet Factory: un contrato inteligente que puede crear carteras de contratos para los usuarios de ERC-4337. La implementación de Wallet Factory no requiere licencia. Como contrato inteligente en cadena, su código está abierto al público y cualquiera puede revisarlo. Una Wallet Factory ampliamente utilizada debe ser completamente auditada por profesionales.
El siguiente diagrama explica cómo el contrato de EntryPoint interactúa con otros actores.
Los empaquetadores llaman a la función handleOps del contrato EntryPoint, que acepta una operación de usuario como entrada.
handleOps verificará UserOperation en la cadena, verificará si está firmado por la dirección de billetera de contrato inteligente especificada y confirmará si la billetera tiene suficiente Gas para compensar a Bundler.
Si se pasa la verificación, handleOps ejecutará la función de billetera de contrato inteligente de acuerdo con la función y los parámetros de entrada definidos en los datos de llamada de UserOperation.
Por otro lado, cuando Bundler usa EOA para activar la función handleOps, se incurrirá en una tarifa de gas. La billetera de contrato inteligente puede pagar las tarifas de Bundlers Gas desde el saldo de su propia cuenta, o solicitar el contrato de Paymaster para pagarlo. UserOperations no puede pasar el paso de verificación fuera de la cadena sin suficiente gas, es decir, falla antes de ejecutar la transacción en la cadena. Incluso si hay suficiente gas, las operaciones de usuario aún pueden fallar debido a errores de tiempo de ejecución y otras razones durante la ejecución. Para una UserOperation, independientemente de si la ejecución del contrato es exitosa o no, el contrato EntryPoint pagará la tarifa de Gas al Bundler que activa la función handleOps.
Después de que ERC-4337 entre en vigencia, los usuarios ahora pueden iniciar transacciones de blockchain de dos maneras. Una es la forma tradicional, es decir, el EOA inicia directamente la transacción. La otra es usar el estándar ERC-4337 para iniciar UserOperation a través de Bundler, y luego Bundler lo empaquetará con otras UserOperations y lo enviará a la cadena de red. El siguiente diagrama de flujo ilustra la diferencia entre una transacción de envío EOA normal y una operación de usuario de envío de billetera de contrato ERC-4337.
El camino ha sido pavimentado, pero todavía no hay muchos peatones
ERC-4337 proporciona un marco poderoso para que los usuarios y desarrolladores usen y creen AA en Ethereum. Si bien este marco es un avance importante, todavía existen algunos desafíos e incertidumbres que deben abordarse y resolverse.
La adopción de AA todavía está en pañales. Según el panel de análisis Dune ERC-4337 [Abstracción de cuenta ERC-4337], solo se ejecutaron más de 65 000 operaciones de usuario en la cadena, el 90 % de las cuales provino de Polygon. Por lo tanto, la cantidad de UserOperations que se realizan actualmente es aún muy pequeña, la mayoría de las cuales son pruebas de desarrolladores y solo una pequeña parte proviene de usuarios reales. Notamos que los productos que tienen AA integrado todavía están en sus primeras etapas. En la actualidad, podemos observar que Bundlers en su conjunto todavía se encuentra en un estado de pérdida, y la pérdida actual es de más de 700 MATIC. Esto se debe principalmente a que algunos Bundlers en Polygon estimaron mal el gas requerido, lo que resultó en que el gas devuelto por EntryPoint sea menor que el gas consumido por el paquete enviado. Este problema debe resolverse a nivel de cliente de Bundler.
Más allá de eso, hay algunos problemas que deben abordarse. Uno de esos problemas es cómo los Bundlers manejan las fallas en las transacciones.
Después de empaquetar varias operaciones de usuario juntas, Bundlers primero simulará la transacción, detectará si habrá una falla en la ejecución del contrato y calculará si la tarifa de gas devuelta por Sender o Paymaster es mayor que la tarifa de gas pagada.
Si es rentable, Bundler envía este lote de operaciones de usuario al nodo de bloque como una transacción. Sin embargo, aún es posible que la transacción falle y que el Bundler pague la tarifa de Gas pero no reciba el reembolso de Gas del EntryPoint. Por ejemplo, un usuario puede enviar acciones a diferentes Bundlers. Si hay espacio para obtener ganancias y la simulación es exitosa, los Bundlers lo asignan a la cadena. En este caso, si diferentes Bundlers envían una UserOperation al nodo de bloque al mismo tiempo, solo una transacción tendrá éxito, lo que significa que solo un Bundler recibirá la tarifa de gas devuelta por EntryPoint, y todos los demás Bundlers fallarán debido para encadenar y perder gasolina. Aunque se podría argumentar que este comportamiento debería considerarse un ataque malicioso y argumentar que Bundler puede prohibir la dirección del remitente y rechazar cualquier solicitud futura de esa dirección, esta no es una solución razonable porque los usuarios pueden realizar esta acción sin querer. Este problema debe abordarse correctamente en el código, quizás a través de una red pública de mempool que está en desarrollo. Además, los Bundlers pueden sufrir pérdidas debido a fluctuaciones repentinas de gas, incluso si la transacción se envía con éxito y los resultados de la simulación muestran que hay espacio para obtener ganancias.
Otro problema es el valor máximo extraíble (MEV) que se puede obtener de AA. En el contexto de Ethereum, MEV generalmente se refiere al valor que extraen los mineros u otros procesadores de transacciones manipulando el orden de las transacciones en un bloque o insertando sus propias transacciones en un bloque. Uno podría notar que la lógica de MEV también se puede aplicar a AA. Esto se debe a que en AA, los Bundlers pueden solicitar UserOps libremente, lo que les brinda la posibilidad de adquirir MEV. Sin embargo, si Bundler puede extraer MEV depende de si se pueden agrupar suficientes operaciones de usuario. Ahora todo el mercado de AA todavía está en sus inicios, por lo que Bundler MEV también puede considerarse en sus inicios. Se puede ver que el MEV de AA puede desarrollarse en dos direcciones: una es similar a la red principal de Ethereum, con la participación de participantes como Flashbots, Ultra Sound y BloXroute; la otra dirección es formar un consenso de Bundler para implementar una clasificación justa. Esto último eliminaría por completo la posibilidad de extraer MEVs en AA.
desarrollo futuro
grupo de miembros público
Si bien el ecosistema AA ya está operativo, todavía queda mucho trabajo de desarrollo por hacer. Mirando todo el ecosistema de AA, la pieza más grande que falta en este momento es el mempool público. El equipo de Etherspot, desarrolladores del cliente Skandha Bundler, actualmente está desarrollando una red p2p con un mempool público. Se espera que una red p2p de mempools públicos se lance en agosto de este año.
Algoritmo de paquete
En el camino, la Fundación Ethereum ha financiado varios equipos de desarrollo de AA destacados. Hasta el momento, se han desarrollado varios clientes de Bundler y actualmente están disponibles. Entre ellos, algunos son muy maduros. Son Candide (Voltaire Bundler escrito en Python), Pimlico (Alto Bundler escrito en Type), Etherspot (Skandha Bundler escrito en Type), Stackup (Stackup-Bundler escrito en Go), etc.
Aquí viene el tema de la estrategia de empaque. Actualmente, debido a la pequeña cantidad de UserOperations, los Bundlers pueden adoptar una lógica de empaquetamiento simple, como intervalos de tiempo fijos o una cierta cantidad de UserOperations en cada paquete. Sin embargo, a medida que aumenta el número de UserOperations, especialmente después de la introducción del mempool público, la estrategia para seleccionar y empaquetar UserOperations se vuelve más compleja. La razón es simple: en el ecosistema AA no existe un mecanismo similar al protocolo de consenso blockchain, y el grupo Bundler se ha convertido en un bosque oscuro, cada Bundler prioriza tareas de acuerdo a sus propios intereses y compite entre sí. A diferencia de los mempools públicos, los mempools privados pueden aparecer antes. Porque cuando no es rentable empaquetar UserOperations desde el mempool público, aún es posible empaquetar UserOperations en el mempool privado. En este caso, el Bundler es más competitivo con otros Bundlers a la hora de empaquetar.
Además, con la popularización gradual del mempool público, las operaciones de usuario en él tienen varias características, como diferentes expectativas de ganancias de gas y complejidad de ejecución en cadena. Los empaquetadores realizarán simulaciones fuera de la cadena para evaluar la rentabilidad de varias combinaciones de UserOperations para establecer sus respectivas estrategias de agrupación. Empaquetar más UserOperations tiene el potencial de generar mayores ganancias, pero también aumenta el riesgo de fallas de validación. Incluso si se pasa la verificación, el riesgo de falla de ejecución en la cadena aún existe. Por el contrario, UserOperations con menos empaquetado es todo lo contrario.
Los empaquetadores deben establecer sus propios parámetros de gas de transacción, lo que afectará la prioridad de los productores de bloques para ejecutar esta transacción. Bajo diferentes condiciones estimadas de precio y volatilidad del Gas, los Bundlers pueden tener diferentes estrategias de empaque. Al mismo tiempo, también es necesario considerar el costo de los recursos informáticos del hardware local y los recursos del nodo de la cadena de bloques para estos cálculos de políticas y verificación. Además, los Bundlers también deben garantizar una buena experiencia de usuario para los usuarios y asegurarse de que los usuarios no enfrenten demoras excesivas después de enviar UserOperations.
Aunque las soluciones a estos desafíos aún no están claras, podemos decir con confianza que el desarrollo de la industria de AA y los esfuerzos conjuntos de los desarrolladores eventualmente resolverán estos problemas. Como constructor de infraestructura, BlockPI espera desempeñar el papel de solucionador de problemas en el desarrollo de la industria de AA, ya sea como desarrollador o para proporcionar una infraestructura compatible con AA para otros desarrolladores.
*La infraestructura debe adaptarse a AA
AA abstrae los diversos roles involucrados en las transacciones en cadena, incluidos el remitente, los empaquetadores, los pagadores de gas, las carteras de contratos y los firmantes, para que los usuarios tengan un mayor grado de libertad al usar la cadena de bloques. Al mismo tiempo, los proveedores de infraestructura pueden desplegar estos servicios de forma independiente según su propio juicio en el mercado.
Para adaptarse a la adopción a gran escala de AA, los proveedores de infraestructura primero deben proporcionar al menos dos servicios básicos: el servicio Bundler y el servicio Paymaster.
En el servicio Bundler, es posible que el proveedor de infraestructura deba desarrollar un mempool privado junto con Bundlers para brindar una buena experiencia de usuario. Específicamente, los proveedores de infraestructura necesitan integrar varios clientes de Bundler para garantizar la estabilidad de los servicios de Bundler. Estos clientes de Bundler actualmente brindan a los usuarios varios métodos JSON RPC estándar proporcionados por el grupo de desarrollo central ERC-4337. Es previsible que haya más métodos RPC disponibles para los usuarios en el futuro. Los proveedores de servicios de infraestructura deben actualizar el soporte para estos métodos de manera oportuna durante este proceso.
Además, es importante optimizar entre la API de Bundler y el RPC del cliente del nodo de origen. El cliente de nodo actual no está optimizado para AA. Algunos métodos de la API de Bundler requieren un índice contra los datos proporcionados para el AA. Por ejemplo, cuando el cliente actual busca UserOperation por hash, necesita escanear los registros de contratos de EntryPoint en todos los bloques. Si no hay un índice de datos, el consumo de recursos de hardware de esta única solicitud será bastante grande y el tiempo de devolución de la solicitud también será muy largo.
Además, para brindarles a los usuarios una experiencia de usuario sin gas y servicios diversificados, los proveedores de infraestructura deben cooperar con diferentes proveedores de servicios de Paymaster para integrar diferentes servicios de Paymaster. Al mismo tiempo, de acuerdo con la demanda del mercado, los proveedores de infraestructura también pueden diseñar soluciones integradas más convenientes basadas en los servicios Paymaster existentes. Otros servicios, como firmas agregadas, fábricas de billeteras, etc., también son direcciones potenciales para el futuro desarrollo e integración de la infraestructura.
En resumen, para adaptarse a la aplicación a gran escala de AA, los proveedores de infraestructura necesitan mejorar y ampliar continuamente sus servicios. Esto incluye la optimización de los servicios de Bundler, la cooperación con diferentes proveedores de servicios de Paymaster, la integración de varias interfaces API y el desarrollo de otros servicios potenciales. A medida que la industria de AA continúa desarrollándose, estos esfuerzos ayudarán a brindar una experiencia de blockchain más eficiente, segura y conveniente.
Actualmente, BlockPI está trabajando arduamente para lograr los objetivos anteriores. No solo eso, nos hemos comunicado con casi todos los clientes de Bundler y los proveedores de servicios de Paymaster en la comunidad, e integraremos AA en la red BlockPI como nuestra principal tarea de desarrollo. Al mismo tiempo, también llevamos a cabo una comunicación profunda con los desarrolladores de billeteras AA para comprender las necesidades de los usuarios. Damos la bienvenida sinceramente a todos los Bundlers, Paymasters y wallets para que se comuniquen y cooperen con nosotros.
El objetivo de BlockPI es construir y desarrollar el ecosistema AA junto con la comunidad y hacer todo lo posible para promover el progreso y la prosperidad del ecosistema AA. Esperamos que, a través de la cooperación con la comunidad, contribuyamos a toda la industria de AA como líder de la industria y apoyemos su proceso de desarrollo posterior, para que los usuarios de Web2 puedan experimentar la tecnología blockchain sin barreras.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
¿Cómo admite la infraestructura a miles de millones de usuarios a través de la abstracción de cuentas?
Ya sea un mercado alcista o un mercado bajista, el ecosistema Ethereum está en constante construcción y optimización automática. Entre ellos, Account Abstraction (AA) ha logrado un progreso importante en los últimos años y ha penetrado en todas las partes del ecosistema Ethereum, incluidas las aplicaciones, la infraestructura, los usuarios y los desarrolladores. Podemos prever que la adopción a gran escala de AA reducirá el umbral de uso de blockchain en su conjunto e introducirá la experiencia del usuario de web2 en la industria web3.
Para aprovechar la oportunidad del mercado AA potencialmente multimillonario, BlockPI planea integrar AA en sus servicios de infraestructura. A través de la integración y la innovación en el campo de AA, BlockPI se compromete a proporcionar a los usuarios de AA una forma más conveniente y eficiente de interactuar con las cuentas de billetera de contrato de blockchain, y espera convertirse en líder en esta industria.
En este artículo, el equipo de BlockPI profundizará en su comprensión de AA y compartirá ideas desde la perspectiva de un proveedor de servicios de infraestructura.
EOA y billetera de contrato
El concepto de AA se deriva de las limitaciones de las cuentas EOA. Una cuenta EOA (cuenta de propiedad externa) es una cuenta de usuario en Ethereum, representada por una clave pública (dirección de cadena de bloques) y a la que se accede a través de una clave privada. Es un componente importante del ecosistema Ethereum, que permite a los usuarios transferir dinero en blockchain o interactuar con contratos inteligentes. Sin embargo, para muchas personas, usar un EOA puede ser una tarea desafiante en sí misma. Además, la cuenta EOA actual todavía tiene algunos inconvenientes en el uso, lo que afecta la experiencia del usuario.
El primero es el tema de las tarifas del gas. Cada transacción le costará al usuario una cantidad considerable de ETH como tarifa de Gas (tome el precio de Gas de 25 Gwei como ejemplo, la tarifa de Gas para una simple transferencia de ETH es de aproximadamente 0,5 dólares estadounidenses, y será más costosa para la interacción del contrato o cuando el precio del Gas es más alto). Esto hace que las transacciones pequeñas sean muy costosas, especialmente durante los períodos de congestión severa de la red. Además, solo se puede usar ETH para pagar Gas, lo que significa que los usuarios deben tener ETH en sus billeteras, lo que constituye una alta barrera de entrada para muchos usuarios.
En segundo lugar, para algunas operaciones complejas que los usuarios quieren lograr, EOA debe confiar en otros contratos inteligentes. Por ejemplo, si un usuario desea establecer una transferencia periódica programada, el usuario debe transferir ETH a un contrato inteligente con esta función para lograr esta operación.
El tercer problema con EOA es el algoritmo de cifrado de firma fijo. La red Ethereum utiliza un algoritmo de firma digital llamado secp256k1 para garantizar la autenticidad y seguridad de las transacciones. Este algoritmo está codificado en el sistema y los usuarios no pueden optar por utilizar otros algoritmos de cifrado.
Además de los tres problemas anteriores, la relación vinculante entre la clave pública y la clave privada de EOA también es un problema. La clave privada es la única forma de que los usuarios accedan a EOA; si se pierde la clave privada, no se recuperará. Esto también significa que todos los activos dentro de la EOA asociados con ella serán irrecuperables.
Al mismo tiempo, EOA también tiene limitaciones a la hora de realizar ciertas tareas lineales. Por ejemplo, si un usuario desea aprobar (aprobar), intercambiar (intercambiar) y desaprobar tokens (desaprobar token) en una operación, se deben realizar tres transacciones separadas, lo cual es ineficiente y requiere mucho tiempo.
La buena noticia es que las billeteras de contrato pueden resolver todos los problemas anteriores. Una billetera de contrato es esencialmente un tipo específico de cuenta de contrato inteligente que implementa AA, que se puede usar como billetera de usuario en Ethereum. Y puede proporcionar a los usuarios una forma más flexible y personalizada de administrar fondos. Siempre que sea la lógica que puede realizar el contrato inteligente de Ethereum, la billetera del contrato puede realizar y proporcionar las funciones correspondientes.
Específicamente, las operaciones de billetera de contrato múltiple se pueden empaquetar en una transacción en cadena, y estas operaciones pueden compartir el costo de Gas de esta transacción. Si el tercero está dispuesto a pagar la tarifa de Gas, no hay necesidad de pagar Gas para los usuarios que utilizan la billetera de contrato. Las billeteras de contrato también pueden completar múltiples tareas lineales a la vez. Además, la billetera de contrato también es compatible con el algoritmo de cifrado de firmas personalizadas y establece la función de recuperación de billetera, etc.
A medida que continúa la discusión sobre las ventajas de las billeteras de contrato, la comunidad de Ethereum ha llevado a cabo una investigación a largo plazo sobre las billeteras de contrato. Aunque muchos EIP han explorado problemas relacionados con la abstracción de cuentas, a partir de 2021 no se ha establecido un estándar unificado. A continuación se muestran varios EIP representativos.
####EIP-86
Propuesto originalmente en 2017 por Vitalik Buterin. Este esquema implementa una serie de cambios con el propósito común de "resumir" la verificación de firma y la verificación de nonce, lo que permite a los usuarios crear "contratos de cuenta" que pueden realizar una verificación arbitraria de firma/nonce.
####EIP-2938
Presentado en 2020. El título de este EIP es Abstracción de cuenta. El concepto de AA está bien descrito en este EIP. Introduce un nuevo tipo de transacción, la transacción AA. La transacción es iniciada por la dirección del punto de entrada (dirección EntryPoint) y llama a la billetera de contrato AA. EIP-2938 proporciona una especificación unificada e introduce oficialmente la abstracción de la cuenta AA en el consenso de Ethereum. Específicamente, presenta dos nuevos códigos de operación, tres variables globales y una estructura de carga útil diferente al consenso de Ethereum.
####EIP-3074
Presentado en 2020. Este EIP introduce dos instrucciones EVM, AUTH y AUTHCALL. AUTH establece las variables de entorno de acuerdo con la autoridad de firma ECDSA. AUTHCALL envía la llamada como una cuenta autorizada. Esto permite que los contratos inteligentes envíen transacciones en nombre de EOA. Pero esto todavía no es una solución perfecta para AA. En el proceso de transacción de autorización, EIP-3074 tiene ciertas restricciones en la transmisión del valor original. Y si el usuario pierde el acceso al EOA, aún no hay forma de recuperar sus activos. Si se filtra la clave privada, el usuario debe transferir todos los activos a la nueva cuenta.
Ninguna de las propuestas anteriores se incorporó formalmente al protocolo Ethereum debido a la necesidad de cambios en la capa de consenso o porque las propuestas no eran lo suficientemente completas. Por lo tanto, la comunidad de Ethereum continuó explorando cómo introducir AA en el protocolo de Ethereum sin cambiar el consenso y finalmente propuso EIP4337.
ERC-4337
EIP-4337 se propuso originalmente en septiembre de 2021 y se autorizó como ERC-4337 en marzo de 2023. Sus autores incluyen a Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson y Tjaden Hess.
EIP-4337 es una propuesta disruptiva que introduciría AA sin cambiar el protocolo central de Ethereum. EIP-4337 eventualmente se convirtió en el estándar ERC-4337, que los constructores pueden usar para implementar sus propias billeteras de contratos inteligentes. Al mismo tiempo, el estándar también introduce una infraestructura adicional que incluye "Bundlers" y "UserOperation mempool". De esta forma, en realidad replica un mempool de Ethereum con funciones similares en la capa superior del sistema blockchain. Lo que envía el usuario ya no es una sola transacción, sino una UserOperation. Estas operaciones de usuario pueden empaquetarse en una sola transacción y enviarse a Ethereum.
La siguiente es una explicación técnica detallada de ERC-4337 en Ethereum [documentación oficial], con algunos comentarios útiles.
Roles clave de ERC-4337 y sus definiciones
UserOperation: describe la estructura de una transacción enviada en nombre de un usuario. Para evitar confusiones, no se denomina "transacción" y se enviará al Bundler para que se empaquete junto con otras operaciones de usuario como un paquete. Luego, el paquete se envía en cadena como una sola transacción.
Remitente: la cuenta del contrato que envía UserOperation. El contrato de billetera debe seguir el estándar ERC-4337 para configurar la interfaz IAccount.
EntryPoint: el contrato único global que ejecuta el paquete UserOperations. Puntos de entrada admitidos en la lista blanca de Bundlers/Clients. El equipo de Infinitism audita y aprueba el contrato para su implementación, y es responsable de manejar todas las operaciones de usuario y conectar los contratos con otros roles, incluidos Wallet Factory, Aggregator y Paymaster. El contrato está todo en la misma dirección en la cadena compatible con EVM.
Bundler: el nodo que empaqueta varias operaciones de usuario del mempool y crea la transacción EntryPoint.handleOps() (el nodo productor de bloques actual). El servicio Bundler puede ejecutarse independientemente de los nodos de blockchain y enviar operaciones de usuario empaquetadas a través de RPC.
Agregador: un contrato auxiliar en el que confían las cuentas para verificar las firmas agregadas. Agregadores de firmas admitidos en la lista blanca de Bundlers/Clients. Los agregadores deben configurar la interfaz IAggregator siguiendo el estándar ERC-4337.
Paymaster: un contrato inteligente que puede pagar Gas en su nombre. Si deposita suficiente ETH en el contrato EntryPoint, puede pagar al remitente el contrato inteligente por la tarifa de gas de UserOperation, implementando efectivamente la extracción de gas. Paymaster debe seguir el estándar ERC-4337 para configurar la interfaz de Paymaster. Paymaster puede llegar a un acuerdo con Sender. Por ejemplo, Sender paga USDC a Paymaster, y Paymaster usa ETH para pagar el gas de las operaciones de usuario que envía. De hecho, Paymaster puede elegir admitir cualquier
Simbólico
, incluyendo ERC-20
Simbólico
incluso otras cadenas
Simbólico
。
El siguiente diagrama explica cómo el contrato de EntryPoint interactúa con otros actores.
Los empaquetadores llaman a la función handleOps del contrato EntryPoint, que acepta una operación de usuario como entrada.
handleOps verificará UserOperation en la cadena, verificará si está firmado por la dirección de billetera de contrato inteligente especificada y confirmará si la billetera tiene suficiente Gas para compensar a Bundler.
Si se pasa la verificación, handleOps ejecutará la función de billetera de contrato inteligente de acuerdo con la función y los parámetros de entrada definidos en los datos de llamada de UserOperation.
Por otro lado, cuando Bundler usa EOA para activar la función handleOps, se incurrirá en una tarifa de gas. La billetera de contrato inteligente puede pagar las tarifas de Bundlers Gas desde el saldo de su propia cuenta, o solicitar el contrato de Paymaster para pagarlo. UserOperations no puede pasar el paso de verificación fuera de la cadena sin suficiente gas, es decir, falla antes de ejecutar la transacción en la cadena. Incluso si hay suficiente gas, las operaciones de usuario aún pueden fallar debido a errores de tiempo de ejecución y otras razones durante la ejecución. Para una UserOperation, independientemente de si la ejecución del contrato es exitosa o no, el contrato EntryPoint pagará la tarifa de Gas al Bundler que activa la función handleOps.
Después de que ERC-4337 entre en vigencia, los usuarios ahora pueden iniciar transacciones de blockchain de dos maneras. Una es la forma tradicional, es decir, el EOA inicia directamente la transacción. La otra es usar el estándar ERC-4337 para iniciar UserOperation a través de Bundler, y luego Bundler lo empaquetará con otras UserOperations y lo enviará a la cadena de red. El siguiente diagrama de flujo ilustra la diferencia entre una transacción de envío EOA normal y una operación de usuario de envío de billetera de contrato ERC-4337.
El camino ha sido pavimentado, pero todavía no hay muchos peatones
ERC-4337 proporciona un marco poderoso para que los usuarios y desarrolladores usen y creen AA en Ethereum. Si bien este marco es un avance importante, todavía existen algunos desafíos e incertidumbres que deben abordarse y resolverse.
La adopción de AA todavía está en pañales. Según el panel de análisis Dune ERC-4337 [Abstracción de cuenta ERC-4337], solo se ejecutaron más de 65 000 operaciones de usuario en la cadena, el 90 % de las cuales provino de Polygon. Por lo tanto, la cantidad de UserOperations que se realizan actualmente es aún muy pequeña, la mayoría de las cuales son pruebas de desarrolladores y solo una pequeña parte proviene de usuarios reales. Notamos que los productos que tienen AA integrado todavía están en sus primeras etapas. En la actualidad, podemos observar que Bundlers en su conjunto todavía se encuentra en un estado de pérdida, y la pérdida actual es de más de 700 MATIC. Esto se debe principalmente a que algunos Bundlers en Polygon estimaron mal el gas requerido, lo que resultó en que el gas devuelto por EntryPoint sea menor que el gas consumido por el paquete enviado. Este problema debe resolverse a nivel de cliente de Bundler.
Más allá de eso, hay algunos problemas que deben abordarse. Uno de esos problemas es cómo los Bundlers manejan las fallas en las transacciones.
Después de empaquetar varias operaciones de usuario juntas, Bundlers primero simulará la transacción, detectará si habrá una falla en la ejecución del contrato y calculará si la tarifa de gas devuelta por Sender o Paymaster es mayor que la tarifa de gas pagada.
Si es rentable, Bundler envía este lote de operaciones de usuario al nodo de bloque como una transacción. Sin embargo, aún es posible que la transacción falle y que el Bundler pague la tarifa de Gas pero no reciba el reembolso de Gas del EntryPoint. Por ejemplo, un usuario puede enviar acciones a diferentes Bundlers. Si hay espacio para obtener ganancias y la simulación es exitosa, los Bundlers lo asignan a la cadena. En este caso, si diferentes Bundlers envían una UserOperation al nodo de bloque al mismo tiempo, solo una transacción tendrá éxito, lo que significa que solo un Bundler recibirá la tarifa de gas devuelta por EntryPoint, y todos los demás Bundlers fallarán debido para encadenar y perder gasolina. Aunque se podría argumentar que este comportamiento debería considerarse un ataque malicioso y argumentar que Bundler puede prohibir la dirección del remitente y rechazar cualquier solicitud futura de esa dirección, esta no es una solución razonable porque los usuarios pueden realizar esta acción sin querer. Este problema debe abordarse correctamente en el código, quizás a través de una red pública de mempool que está en desarrollo. Además, los Bundlers pueden sufrir pérdidas debido a fluctuaciones repentinas de gas, incluso si la transacción se envía con éxito y los resultados de la simulación muestran que hay espacio para obtener ganancias.
Otro problema es el valor máximo extraíble (MEV) que se puede obtener de AA. En el contexto de Ethereum, MEV generalmente se refiere al valor que extraen los mineros u otros procesadores de transacciones manipulando el orden de las transacciones en un bloque o insertando sus propias transacciones en un bloque. Uno podría notar que la lógica de MEV también se puede aplicar a AA. Esto se debe a que en AA, los Bundlers pueden solicitar UserOps libremente, lo que les brinda la posibilidad de adquirir MEV. Sin embargo, si Bundler puede extraer MEV depende de si se pueden agrupar suficientes operaciones de usuario. Ahora todo el mercado de AA todavía está en sus inicios, por lo que Bundler MEV también puede considerarse en sus inicios. Se puede ver que el MEV de AA puede desarrollarse en dos direcciones: una es similar a la red principal de Ethereum, con la participación de participantes como Flashbots, Ultra Sound y BloXroute; la otra dirección es formar un consenso de Bundler para implementar una clasificación justa. Esto último eliminaría por completo la posibilidad de extraer MEVs en AA.
desarrollo futuro
grupo de miembros público
Si bien el ecosistema AA ya está operativo, todavía queda mucho trabajo de desarrollo por hacer. Mirando todo el ecosistema de AA, la pieza más grande que falta en este momento es el mempool público. El equipo de Etherspot, desarrolladores del cliente Skandha Bundler, actualmente está desarrollando una red p2p con un mempool público. Se espera que una red p2p de mempools públicos se lance en agosto de este año.
Algoritmo de paquete
En el camino, la Fundación Ethereum ha financiado varios equipos de desarrollo de AA destacados. Hasta el momento, se han desarrollado varios clientes de Bundler y actualmente están disponibles. Entre ellos, algunos son muy maduros. Son Candide (Voltaire Bundler escrito en Python), Pimlico (Alto Bundler escrito en Type), Etherspot (Skandha Bundler escrito en Type), Stackup (Stackup-Bundler escrito en Go), etc.
Aquí viene el tema de la estrategia de empaque. Actualmente, debido a la pequeña cantidad de UserOperations, los Bundlers pueden adoptar una lógica de empaquetamiento simple, como intervalos de tiempo fijos o una cierta cantidad de UserOperations en cada paquete. Sin embargo, a medida que aumenta el número de UserOperations, especialmente después de la introducción del mempool público, la estrategia para seleccionar y empaquetar UserOperations se vuelve más compleja. La razón es simple: en el ecosistema AA no existe un mecanismo similar al protocolo de consenso blockchain, y el grupo Bundler se ha convertido en un bosque oscuro, cada Bundler prioriza tareas de acuerdo a sus propios intereses y compite entre sí. A diferencia de los mempools públicos, los mempools privados pueden aparecer antes. Porque cuando no es rentable empaquetar UserOperations desde el mempool público, aún es posible empaquetar UserOperations en el mempool privado. En este caso, el Bundler es más competitivo con otros Bundlers a la hora de empaquetar.
Además, con la popularización gradual del mempool público, las operaciones de usuario en él tienen varias características, como diferentes expectativas de ganancias de gas y complejidad de ejecución en cadena. Los empaquetadores realizarán simulaciones fuera de la cadena para evaluar la rentabilidad de varias combinaciones de UserOperations para establecer sus respectivas estrategias de agrupación. Empaquetar más UserOperations tiene el potencial de generar mayores ganancias, pero también aumenta el riesgo de fallas de validación. Incluso si se pasa la verificación, el riesgo de falla de ejecución en la cadena aún existe. Por el contrario, UserOperations con menos empaquetado es todo lo contrario.
Los empaquetadores deben establecer sus propios parámetros de gas de transacción, lo que afectará la prioridad de los productores de bloques para ejecutar esta transacción. Bajo diferentes condiciones estimadas de precio y volatilidad del Gas, los Bundlers pueden tener diferentes estrategias de empaque. Al mismo tiempo, también es necesario considerar el costo de los recursos informáticos del hardware local y los recursos del nodo de la cadena de bloques para estos cálculos de políticas y verificación. Además, los Bundlers también deben garantizar una buena experiencia de usuario para los usuarios y asegurarse de que los usuarios no enfrenten demoras excesivas después de enviar UserOperations.
Aunque las soluciones a estos desafíos aún no están claras, podemos decir con confianza que el desarrollo de la industria de AA y los esfuerzos conjuntos de los desarrolladores eventualmente resolverán estos problemas. Como constructor de infraestructura, BlockPI espera desempeñar el papel de solucionador de problemas en el desarrollo de la industria de AA, ya sea como desarrollador o para proporcionar una infraestructura compatible con AA para otros desarrolladores.
*La infraestructura debe adaptarse a AA
AA abstrae los diversos roles involucrados en las transacciones en cadena, incluidos el remitente, los empaquetadores, los pagadores de gas, las carteras de contratos y los firmantes, para que los usuarios tengan un mayor grado de libertad al usar la cadena de bloques. Al mismo tiempo, los proveedores de infraestructura pueden desplegar estos servicios de forma independiente según su propio juicio en el mercado.
Para adaptarse a la adopción a gran escala de AA, los proveedores de infraestructura primero deben proporcionar al menos dos servicios básicos: el servicio Bundler y el servicio Paymaster.
En el servicio Bundler, es posible que el proveedor de infraestructura deba desarrollar un mempool privado junto con Bundlers para brindar una buena experiencia de usuario. Específicamente, los proveedores de infraestructura necesitan integrar varios clientes de Bundler para garantizar la estabilidad de los servicios de Bundler. Estos clientes de Bundler actualmente brindan a los usuarios varios métodos JSON RPC estándar proporcionados por el grupo de desarrollo central ERC-4337. Es previsible que haya más métodos RPC disponibles para los usuarios en el futuro. Los proveedores de servicios de infraestructura deben actualizar el soporte para estos métodos de manera oportuna durante este proceso.
Además, es importante optimizar entre la API de Bundler y el RPC del cliente del nodo de origen. El cliente de nodo actual no está optimizado para AA. Algunos métodos de la API de Bundler requieren un índice contra los datos proporcionados para el AA. Por ejemplo, cuando el cliente actual busca UserOperation por hash, necesita escanear los registros de contratos de EntryPoint en todos los bloques. Si no hay un índice de datos, el consumo de recursos de hardware de esta única solicitud será bastante grande y el tiempo de devolución de la solicitud también será muy largo.
Además, para brindarles a los usuarios una experiencia de usuario sin gas y servicios diversificados, los proveedores de infraestructura deben cooperar con diferentes proveedores de servicios de Paymaster para integrar diferentes servicios de Paymaster. Al mismo tiempo, de acuerdo con la demanda del mercado, los proveedores de infraestructura también pueden diseñar soluciones integradas más convenientes basadas en los servicios Paymaster existentes. Otros servicios, como firmas agregadas, fábricas de billeteras, etc., también son direcciones potenciales para el futuro desarrollo e integración de la infraestructura.
En resumen, para adaptarse a la aplicación a gran escala de AA, los proveedores de infraestructura necesitan mejorar y ampliar continuamente sus servicios. Esto incluye la optimización de los servicios de Bundler, la cooperación con diferentes proveedores de servicios de Paymaster, la integración de varias interfaces API y el desarrollo de otros servicios potenciales. A medida que la industria de AA continúa desarrollándose, estos esfuerzos ayudarán a brindar una experiencia de blockchain más eficiente, segura y conveniente.
Actualmente, BlockPI está trabajando arduamente para lograr los objetivos anteriores. No solo eso, nos hemos comunicado con casi todos los clientes de Bundler y los proveedores de servicios de Paymaster en la comunidad, e integraremos AA en la red BlockPI como nuestra principal tarea de desarrollo. Al mismo tiempo, también llevamos a cabo una comunicación profunda con los desarrolladores de billeteras AA para comprender las necesidades de los usuarios. Damos la bienvenida sinceramente a todos los Bundlers, Paymasters y wallets para que se comuniquen y cooperen con nosotros.
El objetivo de BlockPI es construir y desarrollar el ecosistema AA junto con la comunidad y hacer todo lo posible para promover el progreso y la prosperidad del ecosistema AA. Esperamos que, a través de la cooperación con la comunidad, contribuyamos a toda la industria de AA como líder de la industria y apoyemos su proceso de desarrollo posterior, para que los usuarios de Web2 puedan experimentar la tecnología blockchain sin barreras.