Saltar al contenido principal

EOA Paymaster

Descripción general

Paymaster basado en EOA

Este documento presenta una solución Paymaster diseñada específicamente para billeteras de cuentas de propiedad externa (EOA), que difiere del Paymaster definido en EIP-4337. Con modificaciones mínimas, las billeteras pueden integrar esta solución para respaldar el patrocinio de tarifas de gas, mejorando significativamente la experiencia del usuario.

¿Qué es Paymaster basado en EOA?

El Paymaster en EIP-4337 (Abstracción de cuenta a través de la especificación del contrato de punto de entrada) es un componente crucial diseñado para mejorar la flexibilidad y la experiencia del usuario de las transacciones Ethereum. Permite que un tercero pague las tarifas de transacción de un usuario, eliminando la necesidad de que los usuarios tengan ETH para pagar el gas.

Si bien EIP-4337 introdujo el concepto revolucionario de Paymaster para billeteras de contratos inteligentes, una parte importante del ecosistema Ethereum todavía depende de EOAs. Reconociendo esto, se presenta una solución Paymaster innovadora diseñada específicamente para billeteras EOA. Esta innovación brinda los beneficios del patrocinio de transacciones y una experiencia de usuario mejorada a una base de usuarios más amplia BOT Chain, sin requerir un cambio a billeteras de contratos inteligentes. La solución EOA Paymaster tiene como objetivo democratizar el acceso a transacciones patrocinadas, haciendo que las interacciones blockchain sean más fáciles de usar y rentables para millones de usuarios de billeteras EOA existentes.

¿Cómo funciona?

Se produce un cambio significativo en el procesamiento de transacciones:

  1. Función del validador: los validadores ya no verifican los precios de las transacciones individuales del gas dentro de un bloque.

  2. Agrupación de transacciones: las transacciones privadas se agrupan en paquetes y se envían a los constructores.

  3. Priorización: los constructores priorizan según el precio agregado del gas de cada paquete.

  4. Flexibilidad dentro del paquete: dentro de un solo paquete, los precios del gas pueden variar, lo que permite que coexistan transacciones sin tarifa y con tarifas más altas.

Esta flexibilidad permite funciones innovadoras como tarifas de gas patrocinadas y transacciones sin gas.

Definiciones

Paquete: una matriz ordenada de transacciones que se ejecutan de forma atómica, lo que garantiza que todas las transacciones del paquete se procesen juntas o no se procesen en absoluto.

Constructor: una nueva parte interesada en la cadena de suministro MEV responsable de la construcción de bloques. Los constructores empaquetan paquetes de transacciones, transacciones individuales del txpool público y flujos de órdenes de transacciones privadas en bloques propuestos.

Proponente: un validador que selecciona el bloque más rentable entre las propuestas de múltiples constructores para incluirlo en la cadena de bloques.

Paymaster: un componente de infraestructura que permite el patrocinio de transacciones, lo que permite a uno mismo o a terceros cubrir las tarifas del gas.

Política del patrocinador: un conjunto de reglas definidas por el patrocinador del gas para determinar qué transacciones califican para el patrocinio. Esto puede incluir criterios como remitentes de transacciones incluidos en la lista blanca o tipos de transacciones específicos.

Flujo de trabajo general

El proceso de patrocinio de gas implica varios componentes y pasos clave:

  1. Iniciación del usuario:

    • Un usuario prepara una transacción utilizando cualquier billetera compatible.

    • La billetera establece el precio del gas en cero para transacciones potencialmente patrocinadas.

  2. Envío al Paymaster:

    • La billetera envía la transacción con precio de gas cero al Paymaster.
  3. Verificación de la política del patrocinador:

    • El Paymaster verifica la transacción con las políticas existentes del patrocinador.

    • Las políticas pueden incluir criterios como direcciones de remitente/destinatario, tipos de tokens o límites de transacciones.

  4. Procesamiento de patrocinio:

    • Si la transacción es elegible para patrocinio: a. El Paymaster crea una transacción de patrocinador con un precio de gas más alto. b. La transacción del usuario original y la transacción del patrocinador se combinan en un paquete.

    • Si no es elegible, la transacción se rechaza o se devuelve al usuario para su procesamiento normal.

  5. Creación y envío de paquetes:

    • Este paquete se envía a varios constructores MEV.
  6. Selección de Constructor y Propuesta de Bloque:

    • Los constructores MEV incorporan el paquete en sus propuestas de bloques.
  7. Inclusión de Blockchain:

    • Los proponentes (validadores) seleccionan el bloque más rentable de las propuestas de los constructores.

    • El bloque seleccionado, que contiene tanto la transacción original del usuario como la transacción del patrocinador, se agrega a la cadena de bloques.

    • Esto garantiza la ejecución atómica de ambas transacciones.

  8. Procesamiento posterior a la transacción:

    • El administrador de Paymaster actualiza la cuenta del patrocinador, deduciendo el monto apropiado por el gas patrocinado.

Esta solución permite un patrocinio de gas fluido sin requerir cambios significativos en las infraestructuras de billetera existentes. Proporciona un sistema flexible que puede adaptarse a varios modelos de patrocinio manteniendo al mismo tiempo la seguridad y la integridad de la red blockchain.

Infraestructura Paymaster

¿Listo para habilitar experiencias sin gas en tu aplicación o billetera? Aquí encontrará información útil sobre la infraestructura Paymaster que está disponible en BOT Chain:

  • Nodereal. MegaFuel, impulsado por Nodereal, es una implementación de Paymaster basada en BOT Chain Paymaster para billeteras EOA. Con modificaciones mínimas, las billeteras pueden integrar MegaFuel para respaldar el patrocinio de tarifas de gas, mejorando significativamente la experiencia del usuario. Al mismo tiempo, los patrocinadores pueden personalizar su patrocinio en MegaFuel, permitiendo a los usuarios patrocinados enviar transacciones sin gas.

Especificaciones de la API Paymaster

Para facilitar la adopción generalizada y garantizar la interoperabilidad entre diversas implementaciones de billeteras, es crucial establecer un conjunto estandarizado de especificaciones de interfaz para los Paymaster. Esta estandarización permitirá a los desarrolladores de billeteras integrar funciones de patrocinio de gas de manera eficiente y consistente, independientemente del servicio Paymaster específico que elijan utilizar.

API Especificaciones

Paymaster necesita implementar un JSON-RPC API llamado pm_isSponsorable, para que pueda devolver información del patrocinador y de la política a las billeteras. Paymaster también necesita implementar eth_sendRawTransaction JSON-RPC API. Las especificaciones detalladas de API se definen a continuación:

pm_isSponsorable

Solicitar parámetros

  • jsonrpc: La versión del protocolo JSON-RPC ("2.0").

  • id: Un identificador único para la solicitud (1 en este ejemplo).

  • method: El nombre del método que se invocará ("pm_isSponsorable").

  • params: una matriz que contiene un solo objeto con los siguientes campos:

    • to: La dirección del destinatario de la transacción.

    • from: La dirección del remitente de la transacción.

    • value: El valor de la transacción en hexadecimal.

    • data: Datos adicionales de la transacción en hexadecimal.

    • gas: El límite de gas de la transacción en hexadecimal.

Ejemplo:

{
"jsonrpc": "2.0",
"id": 1,
"method": "pm_isSponsorable",
"params": [
{
"to": "0x...", // an address
"from": "0x...", // an address"value": "0xa1",
"data": "0x",
"value": "0x1b4",
"gas" : "0x101b4"
}
]
}

Campos de respuesta

  • jsonrpc: La versión del protocolo JSON-RPC ("2.0").

  • id: El identificador único de la solicitud (1 en este ejemplo).

  • result: Un objeto que contiene los detalles de la política de patrocinio:

    • (Obligatorio) Sponsorable: Un booleano que indica si la transacción está patrocinada (verdadero o falso).

    • (Obligatorio) SponsorPolicy:. El nombre de la política del patrocinador.

Ejemplo:

{
"jsonrpc": "2.0",
"id": 1,
"result": {
"Sponsorable": true,
"SponsorPolicy": "a sample policy name"
}
}
eth_sendrawtransaction

El eth_sendrawtransaction API implementado por Paymaster debe seguir esta Ethereum API Spec. El cliente puede crear una nueva transacción de llamada de mensaje o una creación de contrato para transacciones firmadas a través de eth_sendrawtransaction API.

Parámetros de la solicitud

El params debe contener los datos de la transacción firmada.

Ejemplo:

{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_sendRawTransaction",
"params": [
"0x02f86a6102850df8475800850df84758000a94cd9c02358c223a3e788c0b9d94b98d434c7aa0f18080c080a0bcb0e8ffa344e4b855c6e13ee9e4e5d22cff6ad8bd1145a93b93c5d332100c2ca03765236eba5fbb357e35014fd19ba4b3c6b87f3793bd14dddf7913fc8dcc88bf"
]
}

Campos de respuesta

DATOS, 32 Bytes: el hash de la transacción.

Ejemplo:

{
"id": 1,
"jsonrpc": "2.0",
"result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
}

Integración de billetera

Esta guía describe los pasos que deben seguir los desarrolladores de billeteras para integrar los servicios Paymaster, permitiendo el patrocinio de tarifas de gas para sus usuarios. Siguiendo estos estándares, las billeteras pueden ofrecer transacciones fluidas y sin gas entre múltiples proveedores Paymaster.

Flujo de trabajo de interacción

Flujo de interacción de EOA Paymaster entre billetera, paymaster y blockchain

La integración implica modificar el proceso de creación y envío de transacciones para interactuar con los servicios Paymaster.

Los pasos principales son:

  1. Preparación de la transacción:

    • Cuando un usuario inicia una transacción, primero llame a gm_sponsorable para verificar si es elegible para patrocinio.

    • Si es patrocinable, establezca el precio del gas de la transacción en cero.

  2. Notificación de usuario:

    • Informa al usuario que la transacción será sin gas y patrocinada por la "política de patrocinio" devuelta por la API.
  3. Firma de transacción:

    • Haga que el usuario firme la transacción de precio cero del gas.
  4. Envío al Paymaster:

    • Envíe la transacción firmada al Paymaster usando eth_sendRawTransaction.
  5. Manejo de respuestas:

    • Procesa la respuesta del Paymaster:

      • Si tiene éxito, informe al usuario que la transacción se envió.

      • Si falla, considere volver al procesamiento normal de transacciones o informar al usuario de la falla.

  6. Monitoreo de transacciones:

    • Supervise el estado de la transacción como de costumbre.

Mejores prácticas

  1. Siempre verifique el patrocinio antes de modificar los precios del gas.

  2. Proporcione comentarios claros a los usuarios sobre el estado del patrocinio.

  3. Implementar un manejo de errores adecuado para los casos en los que falla el patrocinio.

  4. Considere mecanismos alternativos para transacciones no patrocinadas.

Pruebe la transacción sin gas

Experimente Paymaster en billeteras convencionales

Varias carteras de criptomonedas convencionales ya han implementado la integración de Paymaster. Este tutorial lo guiará a través de la experiencia de enviar transacciones sin gas a billeteras integradas con Paymaster.

Carteras integradas Paymaster

Las carteras con funcionalidad Paymaster integrada ofrecen una experiencia perfecta para los usuarios. Estas billeteras detectan automáticamente si una transacción es elegible para patrocinio. Cuando una transacción califica, la billetera fija el precio del gas en cero sin la intervención del usuario.

Para ilustrar esto, recorreremos el proceso transfiriendo moneda estable en BOT Chain.