AE tx-pay-by proposal

Protocol Features & Updates
1

Hi,
Yesterday, during Native Tokens discussions I was proposing a mechanism to allow a user (transaction sender) to ask

Motivation

One of the fundamental User Experience problems with Blockchain is gas payments. Not only user needs to be aware about his private key / wallet, but also keeping a positive token balance of his account.
Things get even more complicated when a dapp is asking user to pay in a utility token (let’s call them MYU. In that case user usually needs to go to an exchange (which is already a big hurdle for casual Jon), buy AE tokens. Find an exchange which sells MYU tokens, move all this tokens to a wallet and interact with the application.
Removing any step of above increases the user experience exponentially.

Goal

Update the Transaction protocol to allow 3rd party smart contract to pay for a gas.

Current solutions

Today, this is solved

This proposal

Add a new optional field to the transaction: tx_pay_by: address (must be a contract address).
When an aeternity node is processing transaction and will see such field, it will try to call tx_pay_for function of a contract at tx_pay_by address:

contract TxPayFor =
  @param caller Transaction originator 
  @param tx_type Type of transaction (native token, contract call, new contract ...)
  @param call Contract function call.
  entrypoint tx_pay_for(caller: address, tx_type: variant: TxType, call: string) : bool

The function should return true if it accept that the tx_pay_by contract will pay for the gas.
Otherwise the caller will be charged for the gas.

We should think what’s the best tx_pay_for interface (declaration). Maybe it should be more generic and take a serialized call details?

Example

Let’s consider dapp G which is a game. It provides a contract G_Pay which implements TxPayFor interface. tx_pay_for can do the following checks:

  1. Check if caller is registered dapp user
  2. Check if caller is calling one of the allowed G contracts
  3. Check if caller subscription is valid and he topped up enough money to the G dapp.

If all good, G_Pay will pay for the caller transaction and update his “subscription balance”.

2

I think this closely resemble how a Generalized account works, with the exception that today the GA authenticate function can’t inspect the actual transaction; it only has access to the TX-hash…

So, by extending the Auth-environment with the full transaction (and some Sophia sugar to inspect it properly) you should be able to do the things you wish for?! It would require a little bit more than just a tx_pay_by field, but on the other hand you shouldn’t need to make the actual call as bloated so in the end it would require the same amount of information and the end result would be about the same.

This shouldn’t be too big a change - I’d say it is a couple of weeks work at the core level - but it would be consensus breaking and thus needs a hard fork!

3 Likes
3

Thanks for sharing the thoughts @hanssv.chain

Yes, we will need to be careful what arguments the function takes, to make the call efficient and generic.

I’ve updated the proposal by saying that if the pay_for_tx will return false, then the caller will be charged for the transaction.

4

Isn’t that unlikely to work, there was probably a reason why the first wallet/dapp set the pay_for_tx field, namely that it doesn’t have any funds? Perhaps just failing the TX (and thus not include it on chain at all) is a better default? :thinking:

5

both options have a reason.
Anyway - if the caller account doesn’t have funds it will fail anyway.

6

Yes, but the miner will have to do work that it doesn’t get paid for :wink:
Though not much so, yeah both ones are plausible…

2 Likes