-
Los usuarios cubrirían las comisiones de red con tokens SPL, ampliando la accesibilidad de Solana.
-
Los retransmisores automatizarían el cálculo de tarifas y la preparación de transacciones.
El 7 de enero de 2025, el desarrollador Ilan Gitter presentó la propuesta denominada «sRFC-34: Standardized Relayer API» para la red Solana. Su objetivo es permitir que los usuarios puedan interactuar en esta cadena sin la necesidad de poseer SOL, su token nativo, para pagar las comisiones de red (gas fees).
Las siglas «sRFC-34 (Solana Request for Comments)” refieren a una propuesta específica dentro del ecosistema de Solana. El «34» indica el número dentro de esta serie de documentos.
Por su parte, la nomenclatura “Standardized Relayer API” se traduce como “API de Retransmisión Estandarizada”.
La propuesta sRFC-34 define un marco a través de una API específica (Interfaz de Programación de Aplicaciones) para estandarizar el funcionamiento de los relayers (retransmisores) que gestionan las transacciones de los usuarios.
¿Qué son y para qué sirven los relayers en Solana?
Inicialmente, estos relayers son un componente relevante para el ecosistema de finanzas descentralizadas (DeFi).
En el contexto de Solana, los relayers son programas computacionales operados por empresas o instituciones que actúan como intermediarios para facilitar la interacción entre los usuarios y la red.
Estos relayers pagan las comisiones de red en SOL en nombre de los usuarios y, a cambio, les cobran a estos las tarifas equivalentes en algún token SPL (Solana Program Library, un estándar para tokens en Solana, similar al ERC-20 de Ethereum).
Este método se conoce como «abstracción de gas» y apunta a que la experiencia del usuario sea más sencilla, eliminando el requisito de la tenencia de SOL para pagar tarifas de transacción.
Quitar este requisito ampliaría la accesibilidad a Solana para usuarios que no poseen SOL. Además, permitiría a los proyectos basados en Solana utilizar sus propios tokens para cubrir costos operativos.
¿Cómo funcionaría la propuesta sRFC-34?
Actualmente, cada usuario de Solana debe contar con una cantidad suficiente de SOL en su wallet para cubrir las tarifas de red, incluso cuando realiza transacciones con otros tokens SPL.
La propuesta de Gitter establece un formato común para los datos de las transacciones que deben ser retransmitidos. Así, los relayers podrían interpretar y procesar la información de manera uniforme, lo que facilitaría la comunicación entre diferentes aplicaciones y servicios que usan relayers.
Entre algunas de las funcionalidades que la API de Gitter introduciría en los relayers destacan la estimación de tarifas, la preparación de transacciones con instrucciones específicas y la firma y envío de transacciones directamente a los bloques.
Un usuario o aplicación puede enviar una transacción a un relayer mediante la API estandarizada de Gitter y el relayer, entonces, se encarga de retransmitir la transacción a la red de Solana. Luego, los retransmisores deben confirmar si las transacciones han sido procesadas y confirmadas en la red.
Si algo sale mal, el relayer puede comunicar qué fue y cómo se puede solucionar.
La estandarización de los relayers aseguraría que puedan ser integrados mediante un mismo patrón en diferentes aplicaciones para manejar las transacciones sin que los usuarios finales tengan que preocuparse por las tarifas de gas.
Esta implementación de estándar habilitaría que cualquier aplicación dentro de Solana pueda interactuar con los relayers de forma predecible, eliminando la necesidad de que cada desarrollador implemente soluciones personalizadas.
Al mismo tiempo, la API propuesta y la estandarización del comportamiento de los relayers, proveería un rendimiento y una interoperabilidad fluida entre diferentes aplicaciones dentro de Solana.
Los relayers uniformes permitirían una gestión eficiente de transacciones, como el cálculo de tarifas y la preparación de transacciones, lo que optimiza el tiempo y los recursos necesarios para procesarlas.
No obstante, la propuesta todvía debe ser discutida y aceptada por los desarrolladores y validadores de la red antes de su implementación.
Posibles casos de uso, según el desarrollador detrás de sRFC-34
Además de que un relayer pueda pagar una tarifa de red en nombre del usuario, Gitter planteó dos casos de uso adicionales para su propuesta.
En primer lugar, para las Program Derived Addresses (PDAs) en Solana. Estas son direcciones especiales que no pueden pagar por sí mismas las tarifas de transacción, y permiten crear direcciones que solo un programa puede usar para firmar transacciones. Los retransmisores no tienen autoridad para mover fondos por sí mismos. Solo pueden ejecutar transacciones que ya han sido validadas y autorizadas por el programa que controla la PDA.
La PDA actúa como un guardián que permite o bloquea las transacciones según las instrucciones programadas.
Lo que hacen los retransmisores es facilitar la ejecución de transacciones que cumplen con las condiciones preestablecidas por los programas creados por los PDAs. Aquí, el retransmisor sería esencial porque puede pagar las tarifas necesarias para que una PDAs realice acciones en Solana.
Conforme a lo dispuesto por Gitter, tener retransmisores estandarizados significa que más desarrolladores pueden integrar y utilizar PDAs en sus aplicaciones sin la preocupación de cómo manejar las tarifas, lo que podría aumentar la adopción de este tipo de billeteras inteligentes.
En segundo lugar, el desarrollador argumentó que esta funcionalidad estandarizada puede ser aprovechada por monederos integrados en aplicaciones.
¿Existen riesgos en la implementación de un estándar de retransmisores?
Aunque la propuesta presenta beneficios potenciales, su implementación podría enfrentar desafíos técnicos y operativos.
La red podría depender de la disponibilidad y el correcto funcionamiento de los relayers. Dada una interrupción en su servicio, se vería afectada la capacidad de los usuarios para realizar transacciones.
También cabría preguntarse si el hecho de que los relayers manejen los pagos de las tarifas en nombre de los usuarios abriría puertas a posibles vulnerabilidades si no se implementan correctamente.
En última instancia, aunque el cambio busca facilitar las transacciones, podría disminuir la demanda de SOL como token nativo, afectando indirectamente su uso en otros aspectos del ecosistema y, en definitiva, su cotización de mercado.
