Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About Fee Limit Estimation #6154

Open
abn2357 opened this issue Jan 23, 2025 · 2 comments
Open

About Fee Limit Estimation #6154

abn2357 opened this issue Jan 23, 2025 · 2 comments

Comments

@abn2357
Copy link

abn2357 commented Jan 23, 2025

Below is an introduction about fee limit estimation from official tutorial

Image

I have 2 questions:

  1. What is the mathematical relationship between energy consumption of last transaction and estimated fee limit?
  2. Why choose the last transaction as the reference instead of the last transaction that calls the same function?
@angrynurd
Copy link

angrynurd commented Jan 23, 2025

@abn2357

1.Why choose the last transaction as the reference instead of the last transaction that calls the same function?

Indeed, using the last call to the same function would provide a more accurate estimation of the transaction fee limit. The problem with using just the last transaction is that different functions have varying complexities, and different parameters can lead to different consumption levels, making it unable to reflect actual resource requirements.
I understand that TRON's current approach is mainly a trade-off in engineering - prioritizing system simplicity and maintainability at the cost of some accuracy.

2.What is the mathematical relationship between energy consumption of last transaction and estimated fee limit?

In my own opinion, mathematical relationship between last transaction and fee limit:

EstimatedFeeLimit = LastEnergyConsumption × Buffer × EnergyPrice × UserBearingRatio

Where:

  • Buffer: typically 1.1-1.2 (10-20% extra)
  • EnergyPrice: current sun/energy rate
  • UserBearingRatio: portion user needs to pay (e.g., 10% if developer bears 90%)

@abn2357
Copy link
Author

abn2357 commented Jan 23, 2025

@abn2357

1.Why choose the last transaction as the reference instead of the last transaction that calls the same function?

Indeed, using the last call to the same function would provide a more accurate estimation of the transaction fee limit. The problem with using just the last transaction is that different functions have varying complexities, and different parameters can lead to different consumption levels, making it unable to reflect actual resource requirements. I understand that TRON's current approach is mainly a trade-off in engineering - prioritizing system simplicity and maintainability at the cost of some accuracy.

2.What is the mathematical relationship between energy consumption of last transaction and estimated fee limit?

In my own opinion, mathematical relationship between last transaction and fee limit:

EstimatedFeeLimit = LastEnergyConsumption × Buffer × EnergyPrice × UserBearingRatio

Where:

  • Buffer: typically 1.1-1.2 (10-20% extra)
  • EnergyPrice: current sun/energy rate
  • UserBearingRatio: portion user needs to pay (e.g., 10% if developer bears 90%)

Thx for your reply. What does Buffer and UserBearingRatio mean here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants