Tiempo estimado: 7 minutos de lectura
¿Qué es un proveedor de infraestructura de abstracción de cuentas?
El estándar de abstracción de cuentas, ERC-4337, define el protocolo y los bloques fundamentales para desarrollar el mecanismo de abstracción de cuentas en redes blockchain de tipo EVM.
Si bien se trata de una norma abierta a la que cualquier desarrollador puede adherirse, a efectos prácticos, la integración de la abstracción de cuentas en una DApp resulta más conveniente a partir de las funciones suministradas por los proveedores de infraestructura.
Un proveedor de infraestructura de abstracción de cuentas es habitualmente una compañía que contribuye a la evolución de la tecnología, habitualmente colaborando en los distintos grupos de trabajo web3 encargados del desarrollo y la implementación de la norma.
Se pueden distinguir proveedores en todos los bloques funcionales definidos en el estándar ERC-4337, desde los desarrolladores de factorías de Smart Accounts hasta los bundlers y los paymasters.
Estos dos portales representan excelentes recursos para conocer los principales actores involucrados, la evolución de su implantación y su uso a lo largo del tiempo:
Para conocer más detalles sobre esta tecnología, se puede consultar mi artículo sobre la abstracción de cuentas en redes compatibles con la EVM.
Proveedores de Smart Account Factory
En el ecosistema de la ERC-4337, la smart account es el contrato que ejecutará la transacción en la blockchain, desempeñando el papel del wallet del usuario con toda la lógica adicional propia de la abstracción de cuentas que permite mejorar la experiencia de usuario.
La lista de proveedores de Smart Account es muy amplia, desde la implementación de referencia de la SimpleSmartAccount han surgido numerosas instancias con distinto grado de evolución y funcionalidad.
Los criterios para decantarse por una implementación en particular podrían atender a la siguiente clasificación:
- Grado de implantación: número de cuentas desplegadas en las distintias blockchains. Se trata de una métrica muy variable en el tiempo: el impacto de una DApp con mucha tracción de usuarios en un momento dado puede condicionar los porcentajes de reparto entre los distintos proveedores. A medida que la adopción de la abstracción de cuentas por parte de los usuarios crezca, los resultados se podrán interpretar como tendencias más estables en el tiempo.
- Eficiencia en el uso de gas: se trata de una métrica compleja pues la comparativa debería efectuarse analizando los smart contracts particulares del proyecto en que se esté integrando la abstracción de cuentas. Valga como muestra el siguiente estudio efectuado hace ya algunos años comparando algunas de las principales Smart Account del momento en relación con ciertas operaciones comunes como la transferencia de moneda nativa, el traspaso de tokens entre usuarios o un intercambio de pares al estilo de un DEX.
- Versión del Entrypoint soportada: actualmente la versión más moderna es la 0.8 aunque no todas las factorías de Smart Account son compatibles.
- Soporte de algún estandar de modularización como EIP-7579 o EIP-6900.
- Funciones adicionales como recuperación de contraseña social, login mediante passkeys, múltiples firmantes…
- Auditorías de seguridad que den respaldo al smart contract de la factoría.
Proveedores del servicio de bundler
Los bundlers son actores que empaquetan las operaciones de usuario desde una mempool alternativa y las envían al EntryPoint.
De entre todas las opciones disponibles, se analizan algunos de los proveedores que permiten el acceso a las funciones del bundler a partir de un endpoint público y sin ataduras a una SDK propietaria, con un plan de precios favorable que permite su uso en fases tempranas de un proyecto.
En general es preciso efectúar dos llamadas al API RPC del proveedor:
- eth_estimateUserOperationGas para estimar los costes de gas de la operación.
- eth_sendUserOperation para enviar la UserOperation al mempool.
Existen no obstante muchas otras alternativas que por el momento no se analizan por presentar costes de uso mayores o requerir de la instalación de un SDK propietario para su utilización.
Por ejemplo en este enlace se puede consultar una lista de compatibilidades de algunos de los bundlers disponibles con las distintas versiones del entrypoint.
Etherspot
Se trata del bundler Skandha. Soporta las versiones 0.6 y 0.7 del EntryPoint, actualmente con una beta para las versión 0.8. Existe una versión pública no permisionada y otra privada para instalaciones propias.
La configuración del acceso a través de API se efectúa desde su dashboard de usuario, con opción de definir distintos API KEYs para restringir el uso del servicio en varios entornos.
En cuanto a su plan de precios, actualmente por 49$/mes es posible disponer de 20M de créditos mensuales pudiendo conocer aquí el coste en créditos de cada operación.
Las primeras pruebas restringidas a redes testnet se pueden efectuar en el plan gratuito, sin ningún coste.
Thirdweb
Dispone de una infraestructura de abstracción de cuentas compatible igualmente con las versiones 0.6 y 0.7 del entrypoint. Desde el dashboard de usuario se definen los API KEY que dan acceso al servicio y permiten restringir el uso en función de la configuración de seguridad.
Su plan de precios es muy favorable ya que de entrada por 5$/mes se dispone de 3M de peticiones sobre sus endpoints. El uso del bundler en sí no supone ningún sobrecoste sobre el gas de la transacción.
Para el uso en redes de prueba, se puede dar de alta una cuenta gratuita.
Biconomy
Su infraestructura de abstracción de cuentas fue de las primeras en soportar el EntryPoint 0.7 mediante Nexus, su propia factoría de Smart Account.
El bundler presenta los métodos habituales a través del API pública de su endpoint. Para conseguir el API KEY hay que registrarse a través de su dashboard de usuario.
El plan de precios es el más ventajoso de los presentados puesto que no hay costes fijos mensuales ni límites en el máximo número de peticiones sobre el endpoint. El coste asociado al bundler se paga como parte de la comisión de gas de la red.
Proveedores del servicio de paymaster
El paymaster es un smart contract que permite entre otras funciones patrocinar los costos de gas de las transacciones en nombre del usuario. El subsiguiente análisis se hará considerando esa funcionalidad particular.
Se analizan igualmente los tres proveedores del apartado de los bundlers puesto que admiten las llamadas normalizadas al API RPC propias de la norma ERC-7677 :
- pm_getPaymasterStubData: devuelve las estimaciones de gas necesarias para posteriormente invocar el servicio «eth_estimateUserOperationGas» del Bundler.
- pm_getPaymasterData: devuelve los valores relativos al paymaster para incluir en una UserOperation ya firmada.
Como apunte mencionar que en la mayoría de los casos se ha logrado mezclar el bundler y el paymaster de distintos proveedores con éxito, dotando a la solución de cierta independencia del vendedor.
Etherspot
Se trata del paymaster Arka. Comparte las mismas compatibilidades que su bundler emparejado, los entrypoint en las versiones 0.6, 0.7 y una beta de la nueva versión 0.8, así como el mismo plan de precios.
Desde el dashboard de usuario, asociado a cada API KEY configurada, se debe crear una política de patrocinio asociada al paymaster. Esta política permite entre otras cosas deshabilitar completamente el paymaster, elegir con qué versión de entrypoint será compatible y elegir en qué blockchains estará disponible.
Una vez creada la política de patrocionio es necesario transferir fondos en la criptomoneda nativa de la blockchain elegida al address del patrocinador definido en el dashboard. Con esos fondos se podrá desplegar en la red el contrato del paymaster que se ocupará de patrocinar nuestras transacciones así como depositar balance para poder llevar a cabo los patrocinios.
Como medida de seguridad, para cada paymaster desplegado se admite definir una lista de direcciones origen a las que se admitirán los patrocinios.
Thirdweb
El paymaster se rige por el mismo plan de precios que se ha detallado para el bundler emparejado.
Desde el dashboard de usuario es posible definir la políticas de patrocinio: máxima cantidad mensual a patrocinar en USD, restringir los smart contract sobre los que poder patrocinar transacciones, limitar las direcciones origen de las transacciones (permitidas y bloqueadas) e incluso configurar un servidor externo a modo de «webhook» para decidir en el momento si el patrocinio está permitido.
Respecto de los costes extra, el uso del paymaster conlleva un 10% adicional al costo de gas de la transacción.
La cantidad total mensual patrocinada junto con el 10% extra se factura mensualmente a partir de los datos de facturación suministrados desde el portal de usuario, requisito indispensable para poder usar el paymaster en redes mainnet.
Biconomy
El paymaster se crea y configura desde el dashboard de usuario. De entrada es preciso escoger la versión compatible de Entrypoint y la blockchain. A partir de ahí es preciso conectar un wallet para depositar fondos en la cripto nativa para permitir el patrocinio de transacciones.
Como medidas de seguridad se pueden fijar límites de patrocinio de forma global o por dirección origen, así como restringir el patrocinio a determinados smart contracts (incluso solo a algunos métodos en particular) y finalmente configurar «webhooks» externos para tener un control más fino.
El plan de precios de nuevo es el más ventajoso ya que no presenta ningún coste por el uso del API ni sobreprecios de gas.
Conclusión: facilitando la integración de la abstracción de cuentas
Si bien la abstracción de cuentas se presenta como un elemento clave en el impulso de la adopción del uso de aplicaciones descentralizadas, a efectos prácticos llegar a integrar las funciones del estandar ERC-4337 en las aplicaciones no es tarea sencilla.
En artículos precedentes se han tratado conceptos relacionados como la conexión de la wallet de usuario, la propia abstracción de cuentas y el patrocinio de transacciones como medidas en favor de una mejor experiencia de usuario en el mundo web3.
En este artículo final de la serie se han analizado algunos de los actores principales del ecosistema web3 que permiten a los desarrolladores integrar y probar en sus aplicaciones las Smart Account Wallets y los servicios de bundler y paymaster, como ejes centrales de la abstracción de cuentas, a un coste asequible.
Dado que el estandar está en continua evolución (al escribir estas líneas acaba de implantarse la versión del entrypoint 0.8) es muy posible que en un tiempo parte de la información contenida quede obsoleta. Sin embargo es previsible que la esencia se mantenga y siga siendo de utilidad a otros desarrolladores en la tesitura de adoptar las funciones de la abstracción de cuentas.
¿Has integrado la abstracción de cuentas en tus DApps? ¿Usas algún otro proveedor distinto a los citados en el artículo? ¿Cuáles son tus criterios para escoger entre las múltiples opciones disponibles?
Si necesitas consejo sobre estos aspectos u otros relacionados con el desarrollo blockchain, contáctame y vemos cómo podemos colaborar. ¡Gracias!