Looking for a good approach for transaction fee payment

[luizstacio]

WIP: #400

Introduction

I'm currently working on enabling users from the TS SDK, to query
transaction cost and better set gasLimit.

For now, we take the path of giving the tools for the user to get the transaction cost,
but not make it automatically.

Context

Today the best way to measure gasUsed is by executing a transaction on dryRun mode,
with utxoValidation false, against a valid online provider. This returns an approximation for the gas to be consumed on
the real transaction.

With the gasUsed returned we need to apply a tolerance margin to avoid cases where the future submission
of the tx can use a bit more gas, like a concurrently state change on the contract.

Use cases

Use case 1:

The user creates a contract call without adding txParams.

const {value} = await contract.functions.foo(1336).call();
constole.log(value);

In this case, the txParams are going to be the default SDK values;
Note: If the node requires gasPrice and bytePrice to be bigger than 0 it will fail

gasPrice: 0
bytePrice: 0
gasLimit: 1_000_000

Use case 2:

The user creates a contract call and sets gasPrice and bytePrice.

const {value} = await contract.functions.foo(1336).txParams({
    gasPrice: 1,
    bytePrice: 1
}).call();
constole.log(value);

In this case, the txParams set by the user are going to be overridden;
Note: If the node requires gasPrice and bytePrice to be bigger than 1 it will fail.

gasPrice: 1
bytePrice: 1
gasLimit: 1_000_000

Use case 3:

The user creates a contract call and wants to have control of the gasLimit;

const gasPrice = 2;
const bytePrice = 2;
const invokeScope = contract.functions.foo(1336);

const txCost = await invokeScope.getTransactionCost({
  gasPrice, bytePrice
});
// The information returned will include
// gasPrice - the gasPrice set from the user or minGasPrice 
// bytePrice - the bytePrice set from the user
// gasUsed - the returned gasUsed + 20% tolerance margin
// fee - ((gasUsed / gasPriceFactor) * gasPrice) + ((byteSize / gasPriceFactor) * bytePrice)

// Transaction cost in native coins
console.log(txCost.fee);

const { value } = invokeScope.txParams({
    gasPrice: txCost.gasPrice,
    bytePrice: txCost.bytePrice,
    gasLimit: txCost.gasUsed,
}).call();

constole.log(value);

Important points

• tolerance margin: A fixed margin on top of the gasUsed.
• bytePrice: and gasPrice default 0
• gasLimit: default 1_000_000

Questions

• Should we automatically set the gasLimit? Or we should just provide the tools?
• Should we add tolerance margin automatically? If yes 20% is a good amount?
• Should TX fail before submitting if bytePrice and gasPrice are lower than the node requirement?

[digorithm]

Should we automatically set the gasLimit? Or we should just provide the tools?
Should we add tolerance margin automatically? If yes 20% is a good amount?

W.r.t those two points, I think we should have defaults but also provide an interface to configure these values and override the default -- kinda like we're already doing with some configurations.

Should TX fail before submitting if bytePrice and gasPrice are lower than the node requirement?

This makes sense to me!

[luizstacio]

@digorithm I didn't describe it, but it is possible to override tolerance by using:

const txCost = await invokeScope.getTransactionCost({
  gasPrice, bytePrice, tolerance: 0.5
});

About the default, can you expand on that? Like should we set gasPrice, bytePrice and gasLimit? or just gasPrice and bytePrice?

[camsjams]

1. Should we automatically set the gasLimit? Or we should just provide the tools?

The tools sound useful. I think this may be a common issue when wanting to show a preview of all these values to the end user. For instance I was trying to transfer a coin between wallets with some equivalent USD value of like $0.50, but the fee ended up being $7.35! So I opted just to keep it in the first wallet 😒

2. Should we add tolerance margin automatically? If yes 20% is a good amount?

Yes this should be an overridable option and default to sensible percentage. 20% seems fine (I don't have any stats), though maybe 5-10% is more realistic?

3. Should TX fail before submitting if bytePrice and gasPrice are lower than the node requirement?

I feel like this would be something they'd want returned - does the TX automatically fail if they are too low? Assuming a user doesn't know what any values of the three are, then they'd want an easy way to get all three in one function invocation. See question 1.

[luizstacio]

3. If the user submits the tx, it will fail... no changes.

[QuinnLee]

Just a heads up, we do have calculateFee on the transaction request and it returns 1n atm

[luizstacio]

@QuinnLee thanks for remember I think it should be removed, when including this.