Calculating Libra Transaction Fee

Testnet
#1

When a transaction is queried we have to 2 values related to the transaction fee

max_gas_amount: 10000,
gas_unit_price: 10000,

By looking at these values, how is the actual transaction feed calculated?

3 Likes
#2

Up until now I have never seen besides documentation reference to gas prices, and gas cost in trasactions (like in etherscan)
Is somehow everything free in this testnet, or gas has no incidence because the network is so little used ?

I wish to ask libra’s team members why librabrowser.io et al do not have access to that information. (https://dev.kulap.io/libra/#/ wallet also has no front end feature regarding this)

team member said this a week ago

@Diskin @korrio

Is my understanding that gas price / gas component is one of the hardest one to harvest for mainstream usage, as general audience is not used to pay fluctuating transaction fee on credit card nor for sending sms / images.
Gas Price / Max Gas / final Tx cost variability is OK for the crypto enthusiasts / believers, but for mainstream usage, it needs to be “simpler”

so my 2 questions are :

  • how to calculate or even understand how gas prices will impact transactions on testnet
  • is there a proposal on how to implement/introduce this concept to mainstream population ?

@aching @sam @bmwill @lightmark

1 Like
#3

@lbscan / @lucas, if you look at transaction.proto you can see the definition of the two fields as so:

// Maximal total gas specified by wallet to spend for this transaction.
uint64 max_gas_amount = 5;
// The price to be paid for each unit of gas.
uint64 gas_unit_price = 6;

The gas_unit_price is the amount that you are willing to pay per unit of work. So let’s say I specify 10 microlibra. The max_gas_amount is the total that you are willing to pay for this transaction. So let’s say I set this value to 1000. This means that I will pay at most 1000 microlibra for this transaction - which implies that a validator will only perform up to 100 units of work (1000/10). So let’s say that this transaction actually takes 200 units of work. In this case, a validator will execute it for 100 units of work, discard the results because you ran out of gas, and then charge you 1000 microlibra. For another example, let’s say that it took 10 units of work to finish executing. In this case, you would be charged 10 * 10 = 100 microlibra and your transaction would have finished and the transaction would take place (for example, if you were sending money, the money would have been transferred in this case).

The way that we will determine units of work is still a bit in flux, so we haven’t formally published anything there yet, but will be hopefully soon

2 Likes
What should we call the smallest unit of a libra
#4

HI, I’m Tot from KULAP. (contributors of (https://dev.kulap.io/libra/).

Refer to Move white paper:

Execution of Move programs is metered in a manner similar to the EVM [9]. Each bytecode instruction
has an associated gas unit cost, and any transaction to be executed must include a gas unit budget.
The interpreter tracks the gas units remaining during execution and halts with an error if the amount
remaining reaches zero.

So transaction fee is calculated in the same way as Ethereum do. Every instruction (line of code) consume gas. And can running out-of-gas as well (if gas used > max gas amount).

So transaction fee = gas used x gas price.

For example:

  1. I have created this account with 1,000 libras
  2. Transfering 99 Libra, with gas price: 100 micro-libras (=0.0001 libras), and 10,000 max gas amount
transfer 0 1 99 100 #sender receiver number_of_coins gas_unit_price_in_micro_libras
  1. Now balance is 900.7584 libras
  2. So actual transaction fee is 0.2416 (1000-99-900.7584)
  3. 0.2416 = gas used x 0.0001 (transaction fee = gas used x gas price)
  4. So gas used is 2,416 (good gas used still below max gas amount at 10,000)

you can view the transaction here https://librabrowser.io/version/190836

#5

@kph @lucas - long term, I think from a product perspective it is necessary to have the ability to know the total amount deducted per transaction so I think it is a must to be able to calculate it. For now we’ll wait to see the spec on how you determine units of work…

#6

@Diskin we expect that for typical transactions you will be able to easily know this. For custom scripts, this isn’t necessarily possible without locally running them through the VM (since the code could branch and run arbitrarily long)

#7

@kph - understood and agreed. As with any program that relies on a shared data source, someone could update the ledger before it was run by a validator so even the result of estimating by running locally is not 100% guaranteed to be what you pay when you submit the transaction. however from a usability perspective estimates are still necessary in my eyes.

#8

Completely agreed, from my experience in ETH ecosystem, this has to be dealt very pragmatically. As a IRL consumer, transaction fees are linear regarding :

  • time (I want it today and not in 3 business days - Amazon)
    • but in this case should time be a variable ? No one’s expecting a sms to take more than “a few seconds”
  • weight (Postal mail - ok for physical goods but this is not the case)

if anything, the best solution i’ve found is of some form of flag/color code

  • Green = TxfeeMedian / amount to transfer < 0.005 and so on
#9

What would be the typical transaction cost for a transfer of LBR between 2 accounts? It may depend on how much fees the payer is will to pay but it would bring greater trust and adoption if there is a general understanding on how much it costs to use Libra for payments in standard/normal settings.