0

When injecting a transaction from a tz1 account to another one, tezos-client will add 100 to the estimated gas. We know that such operation consumes 1427 gas, why increasing it by default? What could go wrong otherwise?

1

The client always applies the same gas safety margin of 100 gas units and it is indeed useless for transactions to implicit accounts. Don't hesitate to open a feature request on https://gitlab.com/tezos/tezos if you would like the client to be smarter about this.

0

We know that such operation consumes 1427 gas

This is not true. During the Delphi protocol upgrade, gas costs were significantly reduced. You can now send to a TZ1 address for ~500 gas.

Estimating fees for each request ensures that you benefit from any changes in the latest protocol, and/or any new costs are taken into account. 100 is added to estimations as a safety buffer to help reduce the chances of an estimation error preventing a transaction from succeeding.

4
  • My question was: we know that since Delphi/Edo/Florence the gas cost was reduced, thus tezos-client could avoid adding 100 for no apparent reason and instead use the lowest value by default. – Babell May 11 at 12:52
  • @Babell I would imagine the client doesn't have specific code for every combination of transaction type. As more and more protocols get added and more features and types of transactions become available, such code would become hugely complex and difficult to maintain. Most likely it does the same thing for every transaction, in order to keep it easier to maintain: estimate, add buffer to returned value, calculate fee and then use that. Do this for everything and in theory it should never need to be updated – Simon McLoughlin May 12 at 18:12
  • Yes, that's fair. But tz1 to tz1 are the basic transaction. Devs are introducing FA1.2 transactions withing tezos-client, for example. It shouldn't be hard to avoid adding useless gas for tz1-tz1 transactions. – Babell May 12 at 19:01
  • @Babell tz1 addresses have changed a lot since they were originally created. They no longer require sub KT1 address to do such things as delegation. It is an unknown what they will become in the future, how they will change and what kind of impact that will have on transfers and fees. Adding a "safety buffer" is a future proofing mechanism. In the mobile app eco-system it takes weeks to get apps reviewed and months to get everyone up to the latest version. If a protocol update changes any aspect of tz1 to tz1 sending, the lack of a safety buffer could grind my app to a hault – Simon McLoughlin May 13 at 8:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.