[Feature Request] supporting paying gas on behalf of other users

[0xchloe]

🚀 Feature Request

Add a new transaction type that allows a separate gas payer. The separate gas payer will sign on the same raw txn and its own account address for us to verify that this gas payer transaction is also authorized by the gas payer.

Currently in the MoveVM, to pay for gas, we essentially do two things - verify the sender's signature, and charge the sender upon successful verification.
To allow a separate gas payer, we need to also verify the gas payer's signature, and instead charge the gas payer.

Signature Verification

preprocess_transactio() checks the transaction sender's signature - for the purpose of adding a gas payer, we would need to modify the check_signature() and the verify() functions to also check the gas payer's signature on the raw transaction and the gas payer's account address.

Gas Charging

execute_user_transaction() takes in a transaction of type SignatureCheckedTransaction which includes the sender's account address, and then converts it to TransactionMetadata and passes along the sender's account address to the Move function transaction_validation::epilogue to deduct the gas amount on-chain.
For the purpose of gas payer, we will extend TransactionMetadata to also include an optional gas payer - if a transaction has a gas payer, we will then pass in the gas payer's signer to transaction_validation::epilogue.

Motivation

Is your feature request related to a problem? Please describe.

Pitch

Describe the solution you'd like

Describe alternatives you've considered

Are you willing to open a pull request? (See CONTRIBUTING)

Additional context

[raul1ro]

It would be nice to be possible to pay the gas from a different wallet.
Also, it would be nice to be available a wrap-apt(1wapt = 1apt; all the time, no exception). You can trade WAPT, and take the gas from APT.

[magnum6actual]

Thinking this is best accomplished from the SDK/API without impacting established Move framework. We could create the raw transaction like normal, but providing an alternate function to sign the transaction like:
generateBCSTransactionWithPayor(accountFrom: AptosAccount, payorAccount: AptosAccount, rawTxn: RawTransaction): Uint8Array

This would be the least disruptive way to implement. Everything about the transaction, including sequence number, would function as perviously, just the gas fees would be charged to payorAccount.

[magnum6actual]

As a quick use case example, we're doing some embedded social graph stuff on chain. We giving users the ability to "like" an item - and we want to pay the gas costs on those transactions instead of our users. Trying to accomplish that through multi agent transactions is a bit of a nightmare as the paying account would have to be the primary signer/submitter of the transaction, which causes chaos with sequence numbers when we have multiple users trying to execute transactions through that workflow simultaneously. The above approach fixes this for us. Our only alternative is to make small deposits to users accounts to cover the gas fees, but that is tedious and costs even more in gas to make the transfers.

[borispovod]

Hello,

I have reviewed it, and it appears to be a good start. However, it seems quite basic. Would it be possible to incorporate a custom gas payment logic using a function in the future?

What I don't particularly like, as seen in EIP 4337, is that someone must still sign the transaction using their private key. This solution does not seem ideal. Aptos could benefit greatly from additional work on top of the current Account.move logic, such as the ability to pay for gas using a treasury or smart contract balance.

Essentially, by moving the gas payment verification/processing logic to the level of a smart contract.

P.S. another option can be a simple thing: a new module in a framework which would contains a native method which would allow to repay gas for user. E.g.:

public entry fun do_something() {
   let gas_payment: Coin<AptosCoin> = treasury::extract_gas_for_do_something();
   gas_processor::cover(gas_payment);
}

That's a good question on how to calculate gas before gas_processor::cover. Perhaps, a small default amount of free gas could be allocated for each transaction 🤔

[magnum6actual]

Any updates on this one? This is the last big piece we need to fully deploy our model.

[wrwg]

@gerben-stavenga are you actually working on this? If not move to backlog

[gerben-stavenga]

Yes this is one of my priorities

…

On Fri, Apr 28, 2023 at 10:17 AM Wolfgang Grieskamp < ***@***.***> wrote: @gerben-stavenga <https://github.com/gerben-stavenga> are you actually working on this? If not move to backlog — Reply to this email directly, view it on GitHub <#6632 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANBGINJKFK6KPEEGKCIMZITXDP3Q5ANCNFSM6AAAAAAU5RDN5A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[the-fool]

@borispovod That's an interesting idea about having program logic cover gas -- however I have the following concern:

The main purpose of having gas is to prevent spam. A transaction should not ever be free. Since gas_processor::cover would need to be executed in order to see whether it fails or not, being able to freely submit that transaction could open the door to spam execution. Instead, how about this problem of "covering" gas is solved by custom program logic that refunds the signer from an escrow account?

What I'm driving at is that there must be a signer who pays the bill for a transaction. This signer need not be the same as the "protagonist" of a transaction.

For example: Solana has a simple model, where the "fee payer" is a separate signer in a transaction who may or may not be the same as the "protagonist". This method allows someone to sign an offline transaction, and then someone else to sign as the fee payer. doc

[magnum6actual]

Any updates on this? Branch/fork we could take a look at to preview?

[github-actions]

This issue is stale because it has been open 45 days with no activity. Remove the stale label or comment - otherwise this will be closed in 15 days.