As DApp developer, how to effectively estimate approximate transaction fee for simple and complex transactions?
Instead of a constant like 0.1 TON.
As DApp developer, how to effectively estimate approximate transaction fee for simple and complex transactions?
Instead of a constant like 0.1 TON.
As a DApp developer working with blockchain transactions, it’s essential to effectively estimate transaction fees for both simple and complex transactions. Here’s a professional and concise summary with highlighted key points, based on the provided article, focusing on TON blockchain but also touching upon Ethereum:
Ethereum:
TON:
msg_value
: Ensure sufficient msg_value
at entry points.op::excesses
in TON Jetton).SEND_MODE_CARRY_ALL_REMAINING_MESSAGE_VALUE
for linear message flows.msg_value
.storage_fee
depletes contract balance.storage_fee
and const::gas_consumption
.msg_value
for these fees and forward ton amounts.msg_value
to prevent partial execution.Aspect | Ethereum | TON (The Open Network) |
---|---|---|
Gas Management on Low Gas | Transaction is reverted, gas is not refunded. | Transaction is partially executed. |
Gas Management on Sufficient Gas | Actual costs are auto-calculated and deducted. | Excess gas must be returned; responsibility lies with the developer. |
Automatic Gas Calculation | Automatic due to synchronous nature. | Not automatic due to asynchronous nature and fluctuating user balances. |
Estimating Gas Costs | Not a major concern for contract developers; users bear the responsibility. | Developers need to estimate the cost of each handler and check sufficiency of msg_value at entry points. |
Gas Excess Management | Not applicable as excess gas is automatically handled. | Excess gas accumulates in contracts if not returned; practice of returning excesses is recommended. |
Special Mechanisms | Not applicable for handling gas excess. | SEND_MODE_CARRY_ALL_REMAINING_MESSAGE_VALUE used for linear message flows but with exceptions. |
Gas Deduction | From gas provided by the user. | From the contract balance in certain actions (e.g., emitting events, attaching value to messages). |
Handling Complex Transactions | Simplified due to synchronous execution and automatic gas calculation. | Requires careful planning and adjustment based on contract behavior changes. |
Risk of Partial Execution | Not applicable, as transactions either complete entirely or revert. | A critical concern; can occur if gas runs out. |
In summary, estimating transaction fees in TON requires a careful assessment of the message flow, handler costs, and proactive management of gas, considering the asynchronous and distributed nature of the blockchain. Ensuring efficient gas use and returning excesses are crucial practices for optimal contract operation.