El usuario firma primero y un tercero paga el Gas después: ¿qué condiciones hay que comprobar en Sui y Aptos?
Para ofrecer una vía de acceso a nuevos usuarios que no tienen la moneda nativa para pagar el Gas, los desarrolladores quieren eliminar una espera: ¿puede el usuario firmar primero y entregar después la transacción a quien pague por él? La documentación de Sui y Aptos describe formas de hacerlo de manera asíncrona, pero los campos y requisitos que hay que comprobar son distintos. No basta con fijarse en que «admiten el pago por terceros».
En esta comparación solo consultamos la documentación oficial de ambas plataformas; no creamos carteras, no firmamos ni difundimos transacciones, ni medimos las comisiones. La página de Aptos indica que se actualizó el 5 de octubre; la de Sui no especifica una fecha exacta. Lo que sigue describe las condiciones aplicables en la documentación consultada en esta revisión, no una función recién lanzada hoy.
Empecemos por la fuente del pago en Sui. En el ejemplo que utiliza un objeto de moneda de Gas, los datos completos de la transacción deben incluir el objeto de pago, y tanto el usuario como el patrocinador deben firmar. Si otra transacción pendiente está utilizando la misma versión del objeto, la operación puede rechazarse y será necesario actualizar la referencia y reconstruir la transacción o volver a firmarla. Por tanto, a veces la espera se debe a la preparación del objeto y a la resolución de conflictos, no solo a que falte una firma.
La otra opción en Sui es el pago por terceros con el saldo de una dirección. La documentación explica que no es necesario seleccionar un objeto de moneda de Gas y que el usuario puede firmar primero y el patrocinador después. Sin embargo, sigue siendo necesario establecer un propietario del Gas, y una lista vacía de objetos de pago no basta por sí sola: también se requieren restricciones, como un plazo de validez, y hay que comprobar si la función correspondiente está habilitada en la red de destino. Evitar conflictos con objetos de moneda de Gas no significa que otros objetos incluidos por el usuario estén libres de conflictos.
Veamos ahora la dirección del pagador en Aptos. La documentación oficial explica que, antes de la versión 1.8 del framework, los firmantes debían conocer de antemano quién pagaría realmente. Desde la versión 1.8, los demás firmantes pueden optar por usar 0x0 como marcador de posición, pero el pagador final debe firmar con su propia dirección. El remitente puede entregar primero la transacción ya firmada y, después, el pagador puede firmarla y enviarla; no se puede eludir la autorización simplemente modificando a voluntad el campo del pagador.
El orden de comprobación es distinto en cada plataforma: en Sui, primero hay que verificar la fuente del pago, las referencias a los objetos y las funciones de la red; en Aptos, primero hay que verificar qué versión del framework se aplica, el campo del pagador y el rol de cada firmante. Esto no permite afirmar cuál es más rápida o más barata, ni garantiza que todas las interfaces de cartera admitan ya el mismo flujo.
Datos recopilados a las 07:12: SUI, aproximadamente 0.9021; APT, aproximadamente 0.6536 USDT. Entre las 06:00 y las 07:00, los volúmenes de negociación al contado fueron de aproximadamente 635.800 y 155.100 USDT, respectivamente. Estos datos describen el contexto de mercado de los activos relacionados con el Gas; no son pruebas del coste del pago por terceros ni del rendimiento.
Si cambian la configuración de la red de destino, el SDK o las reglas de la documentación, hay que volver a evaluar el proceso según la versión correspondiente. Las reglas de la cadena y la disposición de un proveedor de servicios a pagar por terceros son dos cuestiones distintas; la operación también depende de los criterios de acceso, el presupuesto y la gestión de fallos del servicio. Este artículo compara documentación; no es un tutorial verificado. $SUI $APT
Para ofrecer una vía de acceso a nuevos usuarios que no tienen la moneda nativa para pagar el Gas, los desarrolladores quieren eliminar una espera: ¿puede el usuario firmar primero y entregar después la transacción a quien pague por él? La documentación de Sui y Aptos describe formas de hacerlo de manera asíncrona, pero los campos y requisitos que hay que comprobar son distintos. No basta con fijarse en que «admiten el pago por terceros».
En esta comparación solo consultamos la documentación oficial de ambas plataformas; no creamos carteras, no firmamos ni difundimos transacciones, ni medimos las comisiones. La página de Aptos indica que se actualizó el 5 de octubre; la de Sui no especifica una fecha exacta. Lo que sigue describe las condiciones aplicables en la documentación consultada en esta revisión, no una función recién lanzada hoy.
Empecemos por la fuente del pago en Sui. En el ejemplo que utiliza un objeto de moneda de Gas, los datos completos de la transacción deben incluir el objeto de pago, y tanto el usuario como el patrocinador deben firmar. Si otra transacción pendiente está utilizando la misma versión del objeto, la operación puede rechazarse y será necesario actualizar la referencia y reconstruir la transacción o volver a firmarla. Por tanto, a veces la espera se debe a la preparación del objeto y a la resolución de conflictos, no solo a que falte una firma.
La otra opción en Sui es el pago por terceros con el saldo de una dirección. La documentación explica que no es necesario seleccionar un objeto de moneda de Gas y que el usuario puede firmar primero y el patrocinador después. Sin embargo, sigue siendo necesario establecer un propietario del Gas, y una lista vacía de objetos de pago no basta por sí sola: también se requieren restricciones, como un plazo de validez, y hay que comprobar si la función correspondiente está habilitada en la red de destino. Evitar conflictos con objetos de moneda de Gas no significa que otros objetos incluidos por el usuario estén libres de conflictos.
Veamos ahora la dirección del pagador en Aptos. La documentación oficial explica que, antes de la versión 1.8 del framework, los firmantes debían conocer de antemano quién pagaría realmente. Desde la versión 1.8, los demás firmantes pueden optar por usar 0x0 como marcador de posición, pero el pagador final debe firmar con su propia dirección. El remitente puede entregar primero la transacción ya firmada y, después, el pagador puede firmarla y enviarla; no se puede eludir la autorización simplemente modificando a voluntad el campo del pagador.
El orden de comprobación es distinto en cada plataforma: en Sui, primero hay que verificar la fuente del pago, las referencias a los objetos y las funciones de la red; en Aptos, primero hay que verificar qué versión del framework se aplica, el campo del pagador y el rol de cada firmante. Esto no permite afirmar cuál es más rápida o más barata, ni garantiza que todas las interfaces de cartera admitan ya el mismo flujo.
Datos recopilados a las 07:12: SUI, aproximadamente 0.9021; APT, aproximadamente 0.6536 USDT. Entre las 06:00 y las 07:00, los volúmenes de negociación al contado fueron de aproximadamente 635.800 y 155.100 USDT, respectivamente. Estos datos describen el contexto de mercado de los activos relacionados con el Gas; no son pruebas del coste del pago por terceros ni del rendimiento.
Si cambian la configuración de la red de destino, el SDK o las reglas de la documentación, hay que volver a evaluar el proceso según la versión correspondiente. Las reglas de la cadena y la disposición de un proveedor de servicios a pagar por terceros son dos cuestiones distintas; la operación también depende de los criterios de acceso, el presupuesto y la gestión de fallos del servicio. Este artículo compara documentación; no es un tutorial verificado. $SUI $APT