O usuário assina primeiro, um terceiro paga o Gas depois: quais condições verificar em Sui e Aptos?
Para facilitar o acesso de novos usuários que não têm a moeda nativa para pagar o Gas, desenvolvedores querem eliminar uma espera: o usuário pode assinar primeiro e depois entregar a transação a alguém que pague por ele? A documentação de Sui e Aptos descreve formas assíncronas de combinar essas etapas, mas os campos e pré-requisitos a verificar são diferentes. Não basta olhar se há “suporte a pagamento por terceiros”.
Esta comparação se limita à leitura da documentação oficial das duas redes; não foram criadas carteiras, feitas assinaturas, transmitidas transações nem testadas taxas. A página da Aptos indica atualização em 5 de outubro; a página da Sui não informa uma data exata. Portanto, as condições abaixo se referem à documentação consultada nesta análise e não significam que algo tenha sido lançado hoje.
Primeiro, a origem do pagamento na Sui. No exemplo que usa um objeto de moeda Gas, os dados completos da transação precisam incluir o objeto de pagamento, e tanto o usuário quanto o patrocinador assinam. Se outra transação pendente estiver usando a mesma versão do objeto, a transação poderá ser rejeitada; nesse caso, será necessário atualizar a referência e reconstruir a transação ou assiná-la novamente. Portanto, às vezes a espera ocorre enquanto o objeto é preparado ou um conflito é resolvido — não apenas porque falta a assinatura de alguém.
Uma alternativa na Sui é o pagamento por saldo de endereço. A documentação explica que não é necessário selecionar um objeto de moeda Gas e que o usuário pode assinar primeiro, seguido pelo patrocinador. Ainda assim, é preciso definir um proprietário do Gas, e uma lista vazia de objetos de pagamento não é suficiente: são necessárias restrições como um prazo de validade, e também é preciso verificar se o recurso correspondente está habilitado na rede de destino. Evitar conflitos com objetos de moeda Gas não significa que outros objetos de entrada do usuário estejam livres de riscos de conflito.
Agora, o endereço do pagador na Aptos. Segundo a documentação oficial, antes do framework 1.8, o signatário precisava saber com antecedência quem seria o pagador efetivo. A partir da versão 1.8, outros signatários podem optar por usar 0x0 como marcador, mas o pagador final ainda precisa assinar com o próprio endereço. O remetente pode entregar primeiro a transação já assinada; depois, o pagador a assina e envia. Isso não significa que seja possível alterar livremente o campo do pagador sem autorização.
A ordem de verificação é diferente em cada rede: na Sui, verifique primeiro a origem do pagamento, as referências aos objetos e os recursos disponíveis na rede; na Aptos, verifique primeiro a compatibilidade com a versão do framework, o campo do pagador e as funções dos signatários. Isso não permite concluir qual rede é mais rápida ou mais barata, nem garante que todas as interfaces de carteira já ofereçam o mesmo fluxo.
Às 07:12, SUI estava em torno de 0,9021 e APT em torno de 0,6536 USDT; entre 06:00 e 07:00, os volumes negociados à vista foram de aproximadamente 635,8 mil e 155,1 mil USDT, respectivamente. Esses dados são apenas contexto de mercado para ativos relacionados ao Gas, não evidências sobre taxas de pagamento por terceiros ou desempenho.
Se a configuração da rede de destino, o SDK ou as regras da documentação mudarem, reavalie tudo conforme a versão. As regras da blockchain e a disposição do provedor de serviços em pagar por terceiros são questões distintas; a operação também depende dos critérios de acesso do serviço, do orçamento e do tratamento de falhas. Este texto compara documentação; não é um tutorial testado. $SUI $APT
Para facilitar o acesso de novos usuários que não têm a moeda nativa para pagar o Gas, desenvolvedores querem eliminar uma espera: o usuário pode assinar primeiro e depois entregar a transação a alguém que pague por ele? A documentação de Sui e Aptos descreve formas assíncronas de combinar essas etapas, mas os campos e pré-requisitos a verificar são diferentes. Não basta olhar se há “suporte a pagamento por terceiros”.
Esta comparação se limita à leitura da documentação oficial das duas redes; não foram criadas carteiras, feitas assinaturas, transmitidas transações nem testadas taxas. A página da Aptos indica atualização em 5 de outubro; a página da Sui não informa uma data exata. Portanto, as condições abaixo se referem à documentação consultada nesta análise e não significam que algo tenha sido lançado hoje.
Primeiro, a origem do pagamento na Sui. No exemplo que usa um objeto de moeda Gas, os dados completos da transação precisam incluir o objeto de pagamento, e tanto o usuário quanto o patrocinador assinam. Se outra transação pendente estiver usando a mesma versão do objeto, a transação poderá ser rejeitada; nesse caso, será necessário atualizar a referência e reconstruir a transação ou assiná-la novamente. Portanto, às vezes a espera ocorre enquanto o objeto é preparado ou um conflito é resolvido — não apenas porque falta a assinatura de alguém.
Uma alternativa na Sui é o pagamento por saldo de endereço. A documentação explica que não é necessário selecionar um objeto de moeda Gas e que o usuário pode assinar primeiro, seguido pelo patrocinador. Ainda assim, é preciso definir um proprietário do Gas, e uma lista vazia de objetos de pagamento não é suficiente: são necessárias restrições como um prazo de validade, e também é preciso verificar se o recurso correspondente está habilitado na rede de destino. Evitar conflitos com objetos de moeda Gas não significa que outros objetos de entrada do usuário estejam livres de riscos de conflito.
Agora, o endereço do pagador na Aptos. Segundo a documentação oficial, antes do framework 1.8, o signatário precisava saber com antecedência quem seria o pagador efetivo. A partir da versão 1.8, outros signatários podem optar por usar 0x0 como marcador, mas o pagador final ainda precisa assinar com o próprio endereço. O remetente pode entregar primeiro a transação já assinada; depois, o pagador a assina e envia. Isso não significa que seja possível alterar livremente o campo do pagador sem autorização.
A ordem de verificação é diferente em cada rede: na Sui, verifique primeiro a origem do pagamento, as referências aos objetos e os recursos disponíveis na rede; na Aptos, verifique primeiro a compatibilidade com a versão do framework, o campo do pagador e as funções dos signatários. Isso não permite concluir qual rede é mais rápida ou mais barata, nem garante que todas as interfaces de carteira já ofereçam o mesmo fluxo.
Às 07:12, SUI estava em torno de 0,9021 e APT em torno de 0,6536 USDT; entre 06:00 e 07:00, os volumes negociados à vista foram de aproximadamente 635,8 mil e 155,1 mil USDT, respectivamente. Esses dados são apenas contexto de mercado para ativos relacionados ao Gas, não evidências sobre taxas de pagamento por terceiros ou desempenho.
Se a configuração da rede de destino, o SDK ou as regras da documentação mudarem, reavalie tudo conforme a versão. As regras da blockchain e a disposição do provedor de serviços em pagar por terceiros são questões distintas; a operação também depende dos critérios de acesso do serviço, do orçamento e do tratamento de falhas. Este texto compara documentação; não é um tutorial testado. $SUI $APT