Ya sea un mercado alcista o bajista, el ecosistema Ethereum se ha estado construyendo y autooptimizando continuamente. Entre ellos, la abstracción de cuentas (AA) se ha convertido en un avance muy importante en los últimos años y ha penetrado en varios componentes del ecosistema Ethereum, incluidas las aplicaciones, la infraestructura, los usuarios y los desarrolladores.
Podemos prever que la adopción generalizada de AA puede reducir las barreras de entrada para los casos de uso de blockchain, lo que lleva la experiencia del usuario web2 a la industria web3.
Para aprovechar la posibilidad de formar un mercado de AA multimillonario, BlockPI planea dedicar recursos a la integración de AA en sus servicios de infraestructura. Al desarrollar la integración de AA, nuestro objetivo es proporcionar formas más convenientes y eficientes para que los usuarios de AA interactúen con sus cuentas de billetera de contrato en la cadena de bloques, al mismo tiempo que posicionan a BlockPI como líder de la industria.
En esta publicación, profundizaré en nuestra comprensión de AA y compartiré pensamientos desde la perspectiva de un proveedor de servicios de infraestructura.
EOA y billetera de contrato inteligente
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 típica en Ethereum, representada por una clave pública (dirección de cadena de bloques) y accesible a través de una clave privada. Es un componente importante del ecosistema Ethereum, que permite a los usuarios interactuar con contratos inteligentes y ejecutar transacciones en la red. Sin embargo, usar EOA puede ser un desafío para las personas y algunos inconvenientes pueden afectar la experiencia del usuario.
El primer inconveniente de EOA está relacionado con el uso de Gas. Cada transacción le costará al usuario una gran cantidad de ETH como tarifa de Gas (una tarifa de transferencia ETH simple de 25 Gwei por el precio del Gas es de 0,5 USD, y más por la interacción del contrato o el precio del Gas más alto). Esto hace que las tarifas de transacción sean muy caras para transacciones pequeñas, especialmente durante los períodos pico de congestión de la red. Además, solo se puede usar ETH para pagar el gas, lo que significa que los usuarios deben tener ETH en sus billeteras, lo que es una barrera de entrada importante para muchos usuarios.
El segundo inconveniente de EOA es que no se pueden realizar transacciones condicionales a menos que se implemente alguna lógica utilizando otros contratos inteligentes. Por ejemplo, si un usuario desea establecer una transferencia periódica programada, debe transferir ETH a un contrato inteligente de terceros con esta función para lograr esta función.
El tercer inconveniente de EOA es el algoritmo de cifrado de firma. La red Ethereum utiliza un algoritmo de firma digital específico llamado secp 256 k 1 para garantizar la autenticidad y seguridad de las transacciones. Esto está codificado en el sistema y el usuario no puede elegir usar otro algoritmo.
Por lo tanto, a partir de estos problemas, la gente comenzó a tratar de encontrar soluciones. Las carteras de contratos inteligentes como MetaMask y Argent son el resultado de estos esfuerzos, y abordan muchas de las limitaciones de EOA mediante el uso de contratos inteligentes de Ethereum para mejorar la funcionalidad de la cuenta de usuario. Sin embargo, dicha solución todavía tiene algunas desventajas, principalmente que requiere que los usuarios paguen tarifas de gas por las transacciones y la popularidad de las billeteras de contrato inteligente.
En base a estos desafíos, Ethereum comenzó a intentar introducir un nuevo concepto, a saber, la abstracción de cuenta. El objetivo de la abstracción de cuentas es resolver estos problemas a nivel de protocolo, en lugar de depender de contratos inteligentes u otro software intermedio. Esto es lo que ahora llamamos abstracción de cuentas (AA).
En el resto de esta publicación, profundizaré en el concepto de abstracción de cuentas y cómo podemos usarlo para optimizar la infraestructura de BlockPI.
Además de los tres inconvenientes de EOA mencionados anteriormente, la relación vinculante entre la clave pública y la clave privada también es un problema. La clave privada es la única forma de acceder al EOA y, si se pierde, no hay forma de recuperar la clave privada. Esto significa que si se pierde la clave privada, todos los activos asociados con ella serán irrecuperables.
Además, EOA también enfrenta restricciones al realizar tareas lineales en una sola transacción. Por ejemplo, si un usuario desea aprobar, intercambiar y desaprobar tokens en una sola acción, debe realizar tres transacciones separadas, lo que es ineficiente y requiere mucho tiempo.
La buena noticia es que todos los problemas anteriores se pueden resolver con carteras de contratos inteligentes. Una billetera de contrato inteligente es un tipo especial de contrato inteligente que implementa AA. Está diseñado para actuar como la billetera de un usuario en la red Ethereum y proporcionar una forma más adaptable y personalizada de administrar sus fondos. Siempre que se pueda realizar la lógica del contrato inteligente de Ethereum, la billetera de contrato inteligente puede proporcionar las funciones requeridas.
Específicamente, las transacciones de la billetera de contrato inteligente se pueden empaquetar en una transacción en cadena para compartir el costo del combustible.Si un tercero está dispuesto a pagar, es posible que incluso no haya costo del combustible. Una operación puede facilitar la ejecución de tareas secuenciales dentro de su billetera de contrato inteligente. La billetera de contrato inteligente puede admitir cualquier algoritmo de cifrado de firma y establecer códigos de recuperación, etc.
Con toda la charla sobre los beneficios de las billeteras de contratos inteligentes, la comunidad Ethereum ha estado trabajando en billeteras de contratos desde el principio. Aunque se han propuesto muchos EIP para explorar la abstracción de cuentas, no se ha establecido ningún estándar unificado hasta 2021. A continuación se presentan algunas de las propuestas más representativas.
###EIP-86
Creado originalmente en 2017 por Vitalik Buterin. Se implementó un conjunto de cambios en la verificación de firma "abstracta" y los servicios de verificación de nonce, lo que permite a los usuarios crear "contratos de cuenta" que realizan cualquier verificación de firma/nonce deseada.
###EIP-2938
Creado en 2020. El título de este EIP es Abstracción de cuenta. Este EIP detalla el concepto de AA. Introduce un nuevo tipo de transacción, la transacción AA. Esta transacción será inicializada por la dirección de EntryPoint y llamará al contrato de billetera AA. Al hacerlo, proporciona una especificación unificada e introduce AA en el consenso de Ethereum. Más específicamente, agrega dos nuevos códigos de operación, tres variables globales y una estructura de carga útil diferente al consenso de Ethereum.
###EIP-3074
Creado en 2020. Este EIP introduce dos instrucciones EVM, AUTH y AUTHCALL. AUTH establece una variable de contexto llamada autorizada según la firma ECDSA. AUTHCALL envía una llamada en nombre de una cuenta autorizada. Esto permite que un contrato inteligente envíe transacciones en nombre de EOA. Pero esta no es una solución perfecta para AA. EIP-3074 impone ciertas limitaciones a las transferencias de valores nativos durante las transacciones de patrocinio. Si pierde el acceso a la EOA, no podrá recuperar sus activos y, en caso de robo, todos los activos deberán transferirse a una nueva cuenta.
Ninguna de las ideas anteriores se adoptó formalmente en el protocolo Ethereum debido a razones importantes, como requerir cambios en la capa de consenso o no ser integral. Por lo tanto, la comunidad de Ethereum continuó explorando cómo introducir AA en el protocolo de Ethereum sin cambiar el consenso y finalmente creó EIP 4337.
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 innovadora que presenta AA sin realizar ningún cambio en el protocolo central de Ethereum. EIP-4337 guía el estándar ERC-4337, que los constructores pueden usar para implementar sus propias billeteras de contratos inteligentes, e incluye alguna infraestructura adicional, incluidos "Bundlers" y grupos de memoria de UserOperation. Al hacer esto, esencialmente replica la funcionalidad del mempool de transacciones en un sistema más avanzado. En lugar de enviar transacciones, los usuarios envían objetos UserOperation, que luego pueden empaquetarse en una sola transacción e incluirse en la cadena Ethereum.
La siguiente es una explicación técnica más específica de ERC-4337 de la documentación oficial, así como algunos comentarios para una mejor comprensión.
Definición y funciones clave de ERC-4337
UserOperation: estructura que describe las transacciones enviadas en nombre de un usuario. Para evitar confusiones, no se denomina "transacción". Se envía al Bundler para que se empaquete con otras operaciones de usuario. Luego, el paquete se envía al creador del bloque como una sola transacción.
Remitente: la cuenta del contrato que envía la nueva UserOperation. La billetera de contrato inteligente debe implementar la interfaz IAccount de ERC-4337.
EntryPoint: un contrato único que implementa el paquete UserOperations. Puntos de entrada admitidos en la lista blanca de Bundlers/Clients. Este contrato es aprobado y revisado por el equipo de Infinitism y es responsable de manejar todas las operaciones de usuario y conectar otros contratos, incluidos Wallet Factory, Aggregator, Paymaster. Tendrá la misma dirección en la mayoría de las cadenas compatibles con EVM.
Bundler: un nodo (constructor de bloques) que agrupa varias operaciones de usuario de un mempool y crea transacciones EntryPoint.handleOps(). Todos los validadores en la capa de protocolo no tienen que ser Bundlers. El servicio Bundler puede ejecutarse independientemente del generador de bloques y usa RPC para enviar operaciones de usuario agrupadas.
Agregador: un contrato auxiliar en el que confían las cuentas para verificar las firmas agregadas. Agregadores admitidos en la lista blanca de Bundlers/Clients. Los agregadores deben implementar la interfaz ERC-4337 IAggregator.
Paymaster: un contrato que puede pagar la tarifa de gas de UserOperation para el Remitente si se deposita suficiente ETH en el contrato EntryPoint. Paymaster implementa una extracción de gas eficiente. Paymaster debe implementar la interfaz Paymaster de ERC-4337. Paymaster puede tener su propia lógica para hacer un trato con Sender. Por ejemplo, Sender paga USDC a Paymaster y Paymaster patrocina sus operaciones de usuario con ETH. De hecho, se puede admitir cualquier token ERC 20 o incluso tokens en otras cadenas siempre que Paymaster esté de acuerdo y sea técnicamente factible.
Wallet Factory: un contrato al que se puede llamar para crear billeteras de contratos inteligentes para los usuarios de ERC-4337. La implementación de una fábrica de carteras no requiere permiso. Como componente de la cadena, está abierto a la auditoría pública y al escrutinio transparente. Wallet Factory ampliamente utilizado debe ser completamente auditado 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 toma una operación de usuario como entrada.
handleOps verifica la operación de usuario en la cadena, verifica si está firmada por la dirección de billetera de contrato inteligente especificada y si la billetera tiene suficiente gas para compensar a Bundler.
Si la verificación es exitosa, handleOps ejecutará la función de billetera de contrato inteligente de acuerdo con la firma de 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 la tarifa de Gas a Bundlers desde el saldo de su propia cuenta, o solicitar el contrato de Paymaster para pagar en su nombre. Las operaciones de usuario que no tienen suficiente gas no pueden pasar el proceso de verificación en la billetera de contrato inteligente de destino y, por lo tanto, fallan antes de la ejecución. Incluso si hay suficiente gas, UserOperations puede fallar durante la ejecución, por ejemplo, debido a errores de tiempo de ejecución. Ya sea que la ejecución sea exitosa o no, el contrato EntryPoint pagará la tarifa de Gas al Bundler que activa la función handleOps.
(Fuente: Documentación Oficial:
Después de que ERC-4337 entre en vigencia, los usuarios ahora tienen dos formas de iniciar transacciones de blockchain. Una es la forma original, donde el EOA inicia 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 iniciará en la cadena. El siguiente diagrama de flujo ilustra la diferencia entre la transacción de envío normal de EOA y la operación de usuario de envío de billetera de contrato ERC-4337.
El camino está pavimentado, pero no hay muchos pasajeros
ERC-4337 proporciona un marco poderoso para que los usuarios y desarrolladores usen y creen AA en la plataforma Ethereum. Si bien este marco es un importante paso adelante, aún deben abordarse y resolverse varios desafíos e incertidumbres.
La adopción de AA todavía está en pañales. Según el panel de análisis Dune ERC-4337 (ERC-4337 Account Abstraction de @niftytable), solo se ejecutan más de 65 k UserOperations en la cadena, el 90 % de las cuales provienen de Polygon. Por lo tanto, la cantidad de UserOperations realizadas en este momento es aún muy pequeña, la mayoría de las cuales son pruebas de desarrolladores y solo una pequeña parte se atribuye a los usuarios. Notamos que los productos que tienen AA integrado todavía están en sus primeras etapas. Al mismo tiempo, puede ver que la ganancia de Bundler es negativa (-700 en términos MATIC). Esto se debe a que algunos empaquetadores en Polygon no calculan correctamente el gas de prevalidación. Este algoritmo de verificación todavía necesita optimización.
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 que Bundler empaquete varias operaciones de usuario, Bundler primero simula la transacción para verificar si se revertirá y luego calcula si la tarifa de gas devuelta por el remitente o el pagador es mayor que la tarifa de gas pagada por la transacción. Si es rentable, Bundler envía este lote de operaciones de usuario juntas como una transacción al generador de bloques. Sin embargo, la transacción aún puede fallar, lo que hace que el Bundler pague la tarifa del gas pero no reciba el gas del EntryPoint. Por ejemplo, un usuario puede enviar acciones a diferentes Bundlers. Los empaquetadores están dispuestos a enviar cualquier operación en cadena si son rentables y su simulación es exitosa. Esto significa que si una UserOperation es enviada por diferentes Bundlers al mismo tiempo. Solo una transacción tendrá éxito, solo un Bundler recibirá la tarifa de gas de EntryPoint, todos los demás Bundlers perderán gas debido a una falla en la cadena. Si bien se podría argumentar que los usuarios no deberían hacer esto, tal comportamiento se consideraría un ataque malicioso y que Bundler podría prohibir la dirección del remitente y rechazar cualquier solicitud futura de esta dirección, este no es un enfoque razonable porque los usuarios pueden tener esta operación. sido enviado sin darse cuenta. Estos problemas deben abordarse adecuadamente en el código, posiblemente mediante el desarrollo de una red pública de mempool sin terminar. Además, debido a las fluctuaciones repentinas del gas, los Bundlers pueden enfrentar pérdidas a pesar de que las transacciones se hayan presentado con éxito y se hayan simulado como rentables.
Otra cosa es el valor máximo extraíble (MEV) que se puede extraer de AA. En el contexto de Ethereum, MEV generalmente se refiere al valor que los mineros u otros procesadores de transacciones pueden extraer manipulando el orden de las transacciones en un bloque o incluyendo sus propias transacciones en un bloque. ¿Alguien ha notado que la lógica de MEV también se puede aplicar a AA, ya que los Bundlers son libres de ordenar UserOperations? Sin embargo, esto es condicional, es necesario agrupar suficientes UserOperations para que los Bundlers extraigan MEV. Ahora todo el mercado de AA todavía está en sus inicios, por lo que Bundler MEV también puede considerarse en sus inicios. En general, la industria de AA puede desarrollarse en dos direcciones: una es similar a la red principal de Ethereum, con participantes como Flashbots, Ultra Sound y BloXroute, y la otra es formar un consenso de Bundler para hacer cumplir los pedidos justos. El último enfoque eliminaría por completo la posibilidad de MEV en AA.
desarrollo futuro
grupo de miembros público
Aunque el ecosistema AA ya está funcionando, todavía queda mucho trabajo de desarrollo por hacer. Mirando todo el ecosistema de AA, la brecha más grande en la actualidad es el grupo público de miembros. El equipo de Etherspot, desarrolladores del cliente Skandha Bundler, actualmente está desarrollando una red p2p con un mempool público. Se espera que la red p2p del mempool público esté disponible en agosto de este año.
Algoritmo de embalaje
En el camino, la Fundación Ethereum ha financiado varios equipos de desarrollo de AA de desarrolladores dedicados y trabajadores. Hasta la fecha, se han desarrollado varias versiones del cliente Bundler y ya están disponibles. Algunos de ellos están muy desarrollados en términos de madurez del producto. 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) y muchos más.
Ahora, profundicemos en el algoritmo de empaquetado con más detalle. Actualmente, debido a la baja cantidad de UserOperations, los Bundlers pueden emplear una lógica de empaquetamiento simple y directa, como intervalos de tiempo fijos o la 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: sin un protocolo de consenso como blockchain, los Bundlers forman un bosque oscuro, cada uno priorizando el trabajo de acuerdo con sus propios intereses y compitiendo entre sí. Los mempools privados, correspondientes a los mempools públicos, tienen más probabilidades de aparecer primero. Porque cuando no es rentable empaquetar UserOperations desde el mempool público, puede ser rentable empaquetar UserOperations juntas en el mempool privado. De esta manera, Bundler tiene una ventaja competitiva cuando se trata de empaques.
Además, a medida que se acepte gradualmente el mempool público, las operaciones de usuario en él tendrán diferentes 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 estrategias únicas de empaquetado. 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. Las UserOperations menos empaquetadas hacen lo contrario. Los empaquetadores deben establecer sus propios parámetros de gas de transacción, lo que afectará la prioridad de los constructores de bloques para ejecutar transacciones. Bajo diferentes precios de gas de mercado y condiciones de volatilidad del gas, los empaquetadores pueden tener diferentes estrategias de empaque. Al mismo tiempo, estos cálculos de políticas y verificación deben consumir recursos informáticos de hardware locales y recursos de nodos de cadena de bloques. Los empaquetadores también deben asegurarse de que los usuarios tengan una buena experiencia y de que no enfrenten retrasos excesivos después de enviar una UserOperation.
Si bien las soluciones a estos desafíos siguen siendo inciertas, podemos estar seguros de que la evolución de la industria de AA y los esfuerzos combinados de los desarrolladores eventualmente encontrarán soluciones. Como constructor de infraestructura, BlockPI espera resolver problemas en el desarrollo de la industria AA, ya sea como desarrollador o para proporcionar una infraestructura AA amigable para otros desarrolladores.
La infraestructura debe adaptarse
AA abstrae varios roles en el comportamiento de las transacciones en la cadena, incluidos los remitentes, los empaquetadores, los pagadores de gasolina, las carteras de contratos y los firmantes, lo que permite a los usuarios tener un mayor grado de libertad al usar la cadena de bloques. Además, los servicios dentro de un AA se pueden implementar por separado.
Para adaptarse a la adopción a gran escala de AA, los proveedores de infraestructura primero deben proporcionar al menos dos servicios básicos, a saber, el servicio Bundler y el servicio Paymaster.
En el servicio Bundler, es posible que el proveedor de infraestructura deba desarrollar un mempool privado con Bundlers para garantizar una buena experiencia de usuario. Específicamente, los proveedores de infraestructura necesitan integrar varios clientes de Bundler para garantizar la solidez de los servicios de Bundler. Estos clientes de Bundler se desarrollan en diferentes lenguajes de programación, pero todos proporcionan un conjunto estándar de métodos JSON RPC especificados por el equipo central de ERC-4337. Actualmente, no hay muchos métodos disponibles, pero se agregarán más métodos en el futuro. Los proveedores de servicios de infraestructura deben brindar soporte continuo y completo para estas API.
Además, es importante optimizar y adaptar la relación entre la API de Bundler y el RPC del cliente del nodo de origen. Sabemos que el cliente de nodo actual no está bien optimizado para la capacidad de respuesta y adaptabilidad de AA. Ciertos métodos de la API de Bundler requieren el índice de datos de AA para funcionar. Por ejemplo, buscar una UserOperation por hash requiere indexar todas las UserOperations. De lo contrario, el consumo de hardware de esta única solicitud será muy alto y la solicitud tardará mucho tiempo en devolverse.
Además, los proveedores de infraestructura también deben integrar diferentes servicios de Paymaster para brindar a los clientes una experiencia de usuario sin gas y brindarles diferentes opciones de servicio. Esto requiere una buena comunicación e integración con los proveedores de servicios de Paymaster de terceros Al mismo tiempo, de acuerdo con la demanda del mercado, también se pueden diseñar soluciones de integración más convenientes basadas en los servicios de Paymaster existentes. Otros servicios, como firmas agregadas, fábricas de billeteras, etc., también son posibles direcciones para el desarrollo y la integración futuros.
Actualmente, BlockPI está tratando de lograr todos los objetivos anteriores. No solo eso, nos estamos comunicando con casi todos los clientes de Bundler y los proveedores de servicios de Paymaster en la comunidad, y hemos hecho de la integración del servicio AA en BlockPI Network nuestra principal prioridad. También estamos teniendo discusiones profundas con los desarrolladores de billeteras AA para comprender las necesidades de los usuarios. Por lo tanto, agradecemos sinceramente la cooperación y los intercambios con todos los Bundlers, Paymasters y wallets a medida que avanzamos. Nuestro objetivo general es construir y desarrollar el ecosistema de AA con otros, impulsando su crecimiento y desarrollo lo mejor que podamos. Al trabajar juntos, esperamos hacer una contribución significativa a la industria de AA en su conjunto y apoyar su desarrollo continuo. Porque al fin y al cabo, nuestra misión final es ser pioneros en la industria y promover el desarrollo del ecosistema AA para que los usuarios de web2 puedan disfrutar de su experiencia blockchain sin barreras.
Resumir
Desde la perspectiva de AA, estamos en un nuevo momento histórico. Aunque tenemos caminos pavimentados en el bulevar, todavía no hay muchos ciclistas. En la actualidad, la aplicación de AA aún está en su infancia. ERC-4337 proporciona un marco poderoso para que los usuarios y desarrolladores usen y construyan AA en la plataforma Ethereum. Sin embargo, todavía hay muchos desafíos e incertidumbres que deben resolverse.
El proveedor de infraestructura de AA debe proporcionar el servicio Bundler y el servicio Paymaster para sus usuarios, y debe integrar varios clientes Bundler y proveedores de servicios Paymaster para garantizar la solidez del servicio. Para optimizar la capacidad de respuesta entre la API y los clientes del nodo, es posible que sea necesario indexar los datos de AA para reducir el consumo de hardware para una sola solicitud. Para brindar una mejor experiencia de usuario, los proveedores de infraestructura también deben brindar a los usuarios más opciones de servicio.
En el futuro, a medida que el ecosistema AA siga creciendo y surjan mempools públicos, la estrategia para seleccionar y empaquetar UserOperations será más compleja. Cada Bundler prioriza su trabajo de acuerdo a sus propios intereses y compite con otros Bundlers. Los empaquetadores deben establecer sus propios parámetros de gas de transacción, lo que afecta la prioridad de los constructores de bloques para ejecutar transacciones. Bajo diferentes precios de gas de mercado y condiciones de volatilidad del gas, los empaquetadores pueden tener diferentes estrategias de empaque.
Si bien las soluciones a estos desafíos son inciertas, podemos estar seguros de que la evolución de la industria de AA y los esfuerzos combinados de los desarrolladores eventualmente encontrarán soluciones. Como constructor de infraestructura, BlockPI espera ser un solucionador de problemas en el desarrollo de la industria AA, ya sea como desarrollador o proporcionando una infraestructura AA amigable para otros desarrolladores. Nuestra misión es promover el desarrollo del ecosistema AA para que los usuarios de Web2 puedan disfrutar de su experiencia blockchain sin barreras.
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.
¿Cómo abstraer cuentas para potenciar la infraestructura y servir a miles de millones de usuarios?
Autor: Albert He, científico jefe de BlockPI
Compilación original: MarsBit, MK
Ya sea un mercado alcista o bajista, el ecosistema Ethereum se ha estado construyendo y autooptimizando continuamente. Entre ellos, la abstracción de cuentas (AA) se ha convertido en un avance muy importante en los últimos años y ha penetrado en varios componentes del ecosistema Ethereum, incluidas las aplicaciones, la infraestructura, los usuarios y los desarrolladores.
Podemos prever que la adopción generalizada de AA puede reducir las barreras de entrada para los casos de uso de blockchain, lo que lleva la experiencia del usuario web2 a la industria web3.
Para aprovechar la posibilidad de formar un mercado de AA multimillonario, BlockPI planea dedicar recursos a la integración de AA en sus servicios de infraestructura. Al desarrollar la integración de AA, nuestro objetivo es proporcionar formas más convenientes y eficientes para que los usuarios de AA interactúen con sus cuentas de billetera de contrato en la cadena de bloques, al mismo tiempo que posicionan a BlockPI como líder de la industria.
En esta publicación, profundizaré en nuestra comprensión de AA y compartiré pensamientos desde la perspectiva de un proveedor de servicios de infraestructura.
EOA y billetera de contrato inteligente
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 típica en Ethereum, representada por una clave pública (dirección de cadena de bloques) y accesible a través de una clave privada. Es un componente importante del ecosistema Ethereum, que permite a los usuarios interactuar con contratos inteligentes y ejecutar transacciones en la red. Sin embargo, usar EOA puede ser un desafío para las personas y algunos inconvenientes pueden afectar la experiencia del usuario.
El primer inconveniente de EOA está relacionado con el uso de Gas. Cada transacción le costará al usuario una gran cantidad de ETH como tarifa de Gas (una tarifa de transferencia ETH simple de 25 Gwei por el precio del Gas es de 0,5 USD, y más por la interacción del contrato o el precio del Gas más alto). Esto hace que las tarifas de transacción sean muy caras para transacciones pequeñas, especialmente durante los períodos pico de congestión de la red. Además, solo se puede usar ETH para pagar el gas, lo que significa que los usuarios deben tener ETH en sus billeteras, lo que es una barrera de entrada importante para muchos usuarios.
El segundo inconveniente de EOA es que no se pueden realizar transacciones condicionales a menos que se implemente alguna lógica utilizando otros contratos inteligentes. Por ejemplo, si un usuario desea establecer una transferencia periódica programada, debe transferir ETH a un contrato inteligente de terceros con esta función para lograr esta función.
El tercer inconveniente de EOA es el algoritmo de cifrado de firma. La red Ethereum utiliza un algoritmo de firma digital específico llamado secp 256 k 1 para garantizar la autenticidad y seguridad de las transacciones. Esto está codificado en el sistema y el usuario no puede elegir usar otro algoritmo.
Por lo tanto, a partir de estos problemas, la gente comenzó a tratar de encontrar soluciones. Las carteras de contratos inteligentes como MetaMask y Argent son el resultado de estos esfuerzos, y abordan muchas de las limitaciones de EOA mediante el uso de contratos inteligentes de Ethereum para mejorar la funcionalidad de la cuenta de usuario. Sin embargo, dicha solución todavía tiene algunas desventajas, principalmente que requiere que los usuarios paguen tarifas de gas por las transacciones y la popularidad de las billeteras de contrato inteligente.
En base a estos desafíos, Ethereum comenzó a intentar introducir un nuevo concepto, a saber, la abstracción de cuenta. El objetivo de la abstracción de cuentas es resolver estos problemas a nivel de protocolo, en lugar de depender de contratos inteligentes u otro software intermedio. Esto es lo que ahora llamamos abstracción de cuentas (AA).
En el resto de esta publicación, profundizaré en el concepto de abstracción de cuentas y cómo podemos usarlo para optimizar la infraestructura de BlockPI.
Además de los tres inconvenientes de EOA mencionados anteriormente, la relación vinculante entre la clave pública y la clave privada también es un problema. La clave privada es la única forma de acceder al EOA y, si se pierde, no hay forma de recuperar la clave privada. Esto significa que si se pierde la clave privada, todos los activos asociados con ella serán irrecuperables.
Además, EOA también enfrenta restricciones al realizar tareas lineales en una sola transacción. Por ejemplo, si un usuario desea aprobar, intercambiar y desaprobar tokens en una sola acción, debe realizar tres transacciones separadas, lo que es ineficiente y requiere mucho tiempo.
La buena noticia es que todos los problemas anteriores se pueden resolver con carteras de contratos inteligentes. Una billetera de contrato inteligente es un tipo especial de contrato inteligente que implementa AA. Está diseñado para actuar como la billetera de un usuario en la red Ethereum y proporcionar una forma más adaptable y personalizada de administrar sus fondos. Siempre que se pueda realizar la lógica del contrato inteligente de Ethereum, la billetera de contrato inteligente puede proporcionar las funciones requeridas.
Específicamente, las transacciones de la billetera de contrato inteligente se pueden empaquetar en una transacción en cadena para compartir el costo del combustible.Si un tercero está dispuesto a pagar, es posible que incluso no haya costo del combustible. Una operación puede facilitar la ejecución de tareas secuenciales dentro de su billetera de contrato inteligente. La billetera de contrato inteligente puede admitir cualquier algoritmo de cifrado de firma y establecer códigos de recuperación, etc.
Con toda la charla sobre los beneficios de las billeteras de contratos inteligentes, la comunidad Ethereum ha estado trabajando en billeteras de contratos desde el principio. Aunque se han propuesto muchos EIP para explorar la abstracción de cuentas, no se ha establecido ningún estándar unificado hasta 2021. A continuación se presentan algunas de las propuestas más representativas.
###EIP-86
Creado originalmente en 2017 por Vitalik Buterin. Se implementó un conjunto de cambios en la verificación de firma "abstracta" y los servicios de verificación de nonce, lo que permite a los usuarios crear "contratos de cuenta" que realizan cualquier verificación de firma/nonce deseada.
###EIP-2938
Creado en 2020. El título de este EIP es Abstracción de cuenta. Este EIP detalla el concepto de AA. Introduce un nuevo tipo de transacción, la transacción AA. Esta transacción será inicializada por la dirección de EntryPoint y llamará al contrato de billetera AA. Al hacerlo, proporciona una especificación unificada e introduce AA en el consenso de Ethereum. Más específicamente, agrega dos nuevos códigos de operación, tres variables globales y una estructura de carga útil diferente al consenso de Ethereum.
###EIP-3074
Creado en 2020. Este EIP introduce dos instrucciones EVM, AUTH y AUTHCALL. AUTH establece una variable de contexto llamada autorizada según la firma ECDSA. AUTHCALL envía una llamada en nombre de una cuenta autorizada. Esto permite que un contrato inteligente envíe transacciones en nombre de EOA. Pero esta no es una solución perfecta para AA. EIP-3074 impone ciertas limitaciones a las transferencias de valores nativos durante las transacciones de patrocinio. Si pierde el acceso a la EOA, no podrá recuperar sus activos y, en caso de robo, todos los activos deberán transferirse a una nueva cuenta.
Ninguna de las ideas anteriores se adoptó formalmente en el protocolo Ethereum debido a razones importantes, como requerir cambios en la capa de consenso o no ser integral. Por lo tanto, la comunidad de Ethereum continuó explorando cómo introducir AA en el protocolo de Ethereum sin cambiar el consenso y finalmente creó EIP 4337.
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 innovadora que presenta AA sin realizar ningún cambio en el protocolo central de Ethereum. EIP-4337 guía el estándar ERC-4337, que los constructores pueden usar para implementar sus propias billeteras de contratos inteligentes, e incluye alguna infraestructura adicional, incluidos "Bundlers" y grupos de memoria de UserOperation. Al hacer esto, esencialmente replica la funcionalidad del mempool de transacciones en un sistema más avanzado. En lugar de enviar transacciones, los usuarios envían objetos UserOperation, que luego pueden empaquetarse en una sola transacción e incluirse en la cadena Ethereum.
La siguiente es una explicación técnica más específica de ERC-4337 de la documentación oficial, así como algunos comentarios para una mejor comprensión.
Definición y funciones clave de ERC-4337
UserOperation: estructura que describe las transacciones enviadas en nombre de un usuario. Para evitar confusiones, no se denomina "transacción". Se envía al Bundler para que se empaquete con otras operaciones de usuario. Luego, el paquete se envía al creador del bloque como una sola transacción.
Remitente: la cuenta del contrato que envía la nueva UserOperation. La billetera de contrato inteligente debe implementar la interfaz IAccount de ERC-4337.
EntryPoint: un contrato único que implementa el paquete UserOperations. Puntos de entrada admitidos en la lista blanca de Bundlers/Clients. Este contrato es aprobado y revisado por el equipo de Infinitism y es responsable de manejar todas las operaciones de usuario y conectar otros contratos, incluidos Wallet Factory, Aggregator, Paymaster. Tendrá la misma dirección en la mayoría de las cadenas compatibles con EVM.
Bundler: un nodo (constructor de bloques) que agrupa varias operaciones de usuario de un mempool y crea transacciones EntryPoint.handleOps(). Todos los validadores en la capa de protocolo no tienen que ser Bundlers. El servicio Bundler puede ejecutarse independientemente del generador de bloques y usa RPC para enviar operaciones de usuario agrupadas.
Agregador: un contrato auxiliar en el que confían las cuentas para verificar las firmas agregadas. Agregadores admitidos en la lista blanca de Bundlers/Clients. Los agregadores deben implementar la interfaz ERC-4337 IAggregator.
Paymaster: un contrato que puede pagar la tarifa de gas de UserOperation para el Remitente si se deposita suficiente ETH en el contrato EntryPoint. Paymaster implementa una extracción de gas eficiente. Paymaster debe implementar la interfaz Paymaster de ERC-4337. Paymaster puede tener su propia lógica para hacer un trato con Sender. Por ejemplo, Sender paga USDC a Paymaster y Paymaster patrocina sus operaciones de usuario con ETH. De hecho, se puede admitir cualquier token ERC 20 o incluso tokens en otras cadenas siempre que Paymaster esté de acuerdo y sea técnicamente factible.
Wallet Factory: un contrato al que se puede llamar para crear billeteras de contratos inteligentes para los usuarios de ERC-4337. La implementación de una fábrica de carteras no requiere permiso. Como componente de la cadena, está abierto a la auditoría pública y al escrutinio transparente. Wallet Factory ampliamente utilizado debe ser completamente auditado 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 toma una operación de usuario como entrada.
handleOps verifica la operación de usuario en la cadena, verifica si está firmada por la dirección de billetera de contrato inteligente especificada y si la billetera tiene suficiente gas para compensar a Bundler.
Si la verificación es exitosa, handleOps ejecutará la función de billetera de contrato inteligente de acuerdo con la firma de 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 la tarifa de Gas a Bundlers desde el saldo de su propia cuenta, o solicitar el contrato de Paymaster para pagar en su nombre. Las operaciones de usuario que no tienen suficiente gas no pueden pasar el proceso de verificación en la billetera de contrato inteligente de destino y, por lo tanto, fallan antes de la ejecución. Incluso si hay suficiente gas, UserOperations puede fallar durante la ejecución, por ejemplo, debido a errores de tiempo de ejecución. Ya sea que la ejecución sea exitosa o no, el contrato EntryPoint pagará la tarifa de Gas al Bundler que activa la función handleOps.
(Fuente: Documentación Oficial:
Después de que ERC-4337 entre en vigencia, los usuarios ahora tienen dos formas de iniciar transacciones de blockchain. Una es la forma original, donde el EOA inicia 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 iniciará en la cadena. El siguiente diagrama de flujo ilustra la diferencia entre la transacción de envío normal de EOA y la operación de usuario de envío de billetera de contrato ERC-4337.
El camino está pavimentado, pero no hay muchos pasajeros
ERC-4337 proporciona un marco poderoso para que los usuarios y desarrolladores usen y creen AA en la plataforma Ethereum. Si bien este marco es un importante paso adelante, aún deben abordarse y resolverse varios desafíos e incertidumbres.
La adopción de AA todavía está en pañales. Según el panel de análisis Dune ERC-4337 (ERC-4337 Account Abstraction de @niftytable), solo se ejecutan más de 65 k UserOperations en la cadena, el 90 % de las cuales provienen de Polygon. Por lo tanto, la cantidad de UserOperations realizadas en este momento es aún muy pequeña, la mayoría de las cuales son pruebas de desarrolladores y solo una pequeña parte se atribuye a los usuarios. Notamos que los productos que tienen AA integrado todavía están en sus primeras etapas. Al mismo tiempo, puede ver que la ganancia de Bundler es negativa (-700 en términos MATIC). Esto se debe a que algunos empaquetadores en Polygon no calculan correctamente el gas de prevalidación. Este algoritmo de verificación todavía necesita optimización.
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 que Bundler empaquete varias operaciones de usuario, Bundler primero simula la transacción para verificar si se revertirá y luego calcula si la tarifa de gas devuelta por el remitente o el pagador es mayor que la tarifa de gas pagada por la transacción. Si es rentable, Bundler envía este lote de operaciones de usuario juntas como una transacción al generador de bloques. Sin embargo, la transacción aún puede fallar, lo que hace que el Bundler pague la tarifa del gas pero no reciba el gas del EntryPoint. Por ejemplo, un usuario puede enviar acciones a diferentes Bundlers. Los empaquetadores están dispuestos a enviar cualquier operación en cadena si son rentables y su simulación es exitosa. Esto significa que si una UserOperation es enviada por diferentes Bundlers al mismo tiempo. Solo una transacción tendrá éxito, solo un Bundler recibirá la tarifa de gas de EntryPoint, todos los demás Bundlers perderán gas debido a una falla en la cadena. Si bien se podría argumentar que los usuarios no deberían hacer esto, tal comportamiento se consideraría un ataque malicioso y que Bundler podría prohibir la dirección del remitente y rechazar cualquier solicitud futura de esta dirección, este no es un enfoque razonable porque los usuarios pueden tener esta operación. sido enviado sin darse cuenta. Estos problemas deben abordarse adecuadamente en el código, posiblemente mediante el desarrollo de una red pública de mempool sin terminar. Además, debido a las fluctuaciones repentinas del gas, los Bundlers pueden enfrentar pérdidas a pesar de que las transacciones se hayan presentado con éxito y se hayan simulado como rentables.
Otra cosa es el valor máximo extraíble (MEV) que se puede extraer de AA. En el contexto de Ethereum, MEV generalmente se refiere al valor que los mineros u otros procesadores de transacciones pueden extraer manipulando el orden de las transacciones en un bloque o incluyendo sus propias transacciones en un bloque. ¿Alguien ha notado que la lógica de MEV también se puede aplicar a AA, ya que los Bundlers son libres de ordenar UserOperations? Sin embargo, esto es condicional, es necesario agrupar suficientes UserOperations para que los Bundlers extraigan MEV. Ahora todo el mercado de AA todavía está en sus inicios, por lo que Bundler MEV también puede considerarse en sus inicios. En general, la industria de AA puede desarrollarse en dos direcciones: una es similar a la red principal de Ethereum, con participantes como Flashbots, Ultra Sound y BloXroute, y la otra es formar un consenso de Bundler para hacer cumplir los pedidos justos. El último enfoque eliminaría por completo la posibilidad de MEV en AA.
desarrollo futuro
grupo de miembros público
Aunque el ecosistema AA ya está funcionando, todavía queda mucho trabajo de desarrollo por hacer. Mirando todo el ecosistema de AA, la brecha más grande en la actualidad es el grupo público de miembros. El equipo de Etherspot, desarrolladores del cliente Skandha Bundler, actualmente está desarrollando una red p2p con un mempool público. Se espera que la red p2p del mempool público esté disponible en agosto de este año.
Algoritmo de embalaje
En el camino, la Fundación Ethereum ha financiado varios equipos de desarrollo de AA de desarrolladores dedicados y trabajadores. Hasta la fecha, se han desarrollado varias versiones del cliente Bundler y ya están disponibles. Algunos de ellos están muy desarrollados en términos de madurez del producto. 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) y muchos más.
Ahora, profundicemos en el algoritmo de empaquetado con más detalle. Actualmente, debido a la baja cantidad de UserOperations, los Bundlers pueden emplear una lógica de empaquetamiento simple y directa, como intervalos de tiempo fijos o la 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: sin un protocolo de consenso como blockchain, los Bundlers forman un bosque oscuro, cada uno priorizando el trabajo de acuerdo con sus propios intereses y compitiendo entre sí. Los mempools privados, correspondientes a los mempools públicos, tienen más probabilidades de aparecer primero. Porque cuando no es rentable empaquetar UserOperations desde el mempool público, puede ser rentable empaquetar UserOperations juntas en el mempool privado. De esta manera, Bundler tiene una ventaja competitiva cuando se trata de empaques.
Además, a medida que se acepte gradualmente el mempool público, las operaciones de usuario en él tendrán diferentes 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 estrategias únicas de empaquetado. 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. Las UserOperations menos empaquetadas hacen lo contrario. Los empaquetadores deben establecer sus propios parámetros de gas de transacción, lo que afectará la prioridad de los constructores de bloques para ejecutar transacciones. Bajo diferentes precios de gas de mercado y condiciones de volatilidad del gas, los empaquetadores pueden tener diferentes estrategias de empaque. Al mismo tiempo, estos cálculos de políticas y verificación deben consumir recursos informáticos de hardware locales y recursos de nodos de cadena de bloques. Los empaquetadores también deben asegurarse de que los usuarios tengan una buena experiencia y de que no enfrenten retrasos excesivos después de enviar una UserOperation.
Si bien las soluciones a estos desafíos siguen siendo inciertas, podemos estar seguros de que la evolución de la industria de AA y los esfuerzos combinados de los desarrolladores eventualmente encontrarán soluciones. Como constructor de infraestructura, BlockPI espera resolver problemas en el desarrollo de la industria AA, ya sea como desarrollador o para proporcionar una infraestructura AA amigable para otros desarrolladores.
La infraestructura debe adaptarse
AA abstrae varios roles en el comportamiento de las transacciones en la cadena, incluidos los remitentes, los empaquetadores, los pagadores de gasolina, las carteras de contratos y los firmantes, lo que permite a los usuarios tener un mayor grado de libertad al usar la cadena de bloques. Además, los servicios dentro de un AA se pueden implementar por separado.
Para adaptarse a la adopción a gran escala de AA, los proveedores de infraestructura primero deben proporcionar al menos dos servicios básicos, a saber, el servicio Bundler y el servicio Paymaster.
En el servicio Bundler, es posible que el proveedor de infraestructura deba desarrollar un mempool privado con Bundlers para garantizar una buena experiencia de usuario. Específicamente, los proveedores de infraestructura necesitan integrar varios clientes de Bundler para garantizar la solidez de los servicios de Bundler. Estos clientes de Bundler se desarrollan en diferentes lenguajes de programación, pero todos proporcionan un conjunto estándar de métodos JSON RPC especificados por el equipo central de ERC-4337. Actualmente, no hay muchos métodos disponibles, pero se agregarán más métodos en el futuro. Los proveedores de servicios de infraestructura deben brindar soporte continuo y completo para estas API.
Además, es importante optimizar y adaptar la relación entre la API de Bundler y el RPC del cliente del nodo de origen. Sabemos que el cliente de nodo actual no está bien optimizado para la capacidad de respuesta y adaptabilidad de AA. Ciertos métodos de la API de Bundler requieren el índice de datos de AA para funcionar. Por ejemplo, buscar una UserOperation por hash requiere indexar todas las UserOperations. De lo contrario, el consumo de hardware de esta única solicitud será muy alto y la solicitud tardará mucho tiempo en devolverse.
Además, los proveedores de infraestructura también deben integrar diferentes servicios de Paymaster para brindar a los clientes una experiencia de usuario sin gas y brindarles diferentes opciones de servicio. Esto requiere una buena comunicación e integración con los proveedores de servicios de Paymaster de terceros Al mismo tiempo, de acuerdo con la demanda del mercado, también se pueden diseñar soluciones de integración más convenientes basadas en los servicios de Paymaster existentes. Otros servicios, como firmas agregadas, fábricas de billeteras, etc., también son posibles direcciones para el desarrollo y la integración futuros.
Actualmente, BlockPI está tratando de lograr todos los objetivos anteriores. No solo eso, nos estamos comunicando con casi todos los clientes de Bundler y los proveedores de servicios de Paymaster en la comunidad, y hemos hecho de la integración del servicio AA en BlockPI Network nuestra principal prioridad. También estamos teniendo discusiones profundas con los desarrolladores de billeteras AA para comprender las necesidades de los usuarios. Por lo tanto, agradecemos sinceramente la cooperación y los intercambios con todos los Bundlers, Paymasters y wallets a medida que avanzamos. Nuestro objetivo general es construir y desarrollar el ecosistema de AA con otros, impulsando su crecimiento y desarrollo lo mejor que podamos. Al trabajar juntos, esperamos hacer una contribución significativa a la industria de AA en su conjunto y apoyar su desarrollo continuo. Porque al fin y al cabo, nuestra misión final es ser pioneros en la industria y promover el desarrollo del ecosistema AA para que los usuarios de web2 puedan disfrutar de su experiencia blockchain sin barreras.
Resumir
Desde la perspectiva de AA, estamos en un nuevo momento histórico. Aunque tenemos caminos pavimentados en el bulevar, todavía no hay muchos ciclistas. En la actualidad, la aplicación de AA aún está en su infancia. ERC-4337 proporciona un marco poderoso para que los usuarios y desarrolladores usen y construyan AA en la plataforma Ethereum. Sin embargo, todavía hay muchos desafíos e incertidumbres que deben resolverse.
El proveedor de infraestructura de AA debe proporcionar el servicio Bundler y el servicio Paymaster para sus usuarios, y debe integrar varios clientes Bundler y proveedores de servicios Paymaster para garantizar la solidez del servicio. Para optimizar la capacidad de respuesta entre la API y los clientes del nodo, es posible que sea necesario indexar los datos de AA para reducir el consumo de hardware para una sola solicitud. Para brindar una mejor experiencia de usuario, los proveedores de infraestructura también deben brindar a los usuarios más opciones de servicio.
En el futuro, a medida que el ecosistema AA siga creciendo y surjan mempools públicos, la estrategia para seleccionar y empaquetar UserOperations será más compleja. Cada Bundler prioriza su trabajo de acuerdo a sus propios intereses y compite con otros Bundlers. Los empaquetadores deben establecer sus propios parámetros de gas de transacción, lo que afecta la prioridad de los constructores de bloques para ejecutar transacciones. Bajo diferentes precios de gas de mercado y condiciones de volatilidad del gas, los empaquetadores pueden tener diferentes estrategias de empaque.
Si bien las soluciones a estos desafíos son inciertas, podemos estar seguros de que la evolución de la industria de AA y los esfuerzos combinados de los desarrolladores eventualmente encontrarán soluciones. Como constructor de infraestructura, BlockPI espera ser un solucionador de problemas en el desarrollo de la industria AA, ya sea como desarrollador o proporcionando una infraestructura AA amigable para otros desarrolladores. Nuestra misión es promover el desarrollo del ecosistema AA para que los usuarios de Web2 puedan disfrutar de su experiencia blockchain sin barreras.