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 vs TON Gas Management

  • Ethereum:

    • Low Gas: Transaction reverts if gas is too low, gas not refunded.
    • Sufficient Gas: Actual costs auto-calculated and deducted.

  • TON:

    • Insufficient Gas: Partial transaction execution.
    • Excess Gas: Developer’s responsibility to return.
    • Asynchronous Nature: TON can’t auto-calculate due to potential delay in transaction completion and fluctuating user balances.

Estimating Gas in TON

  1. Identify Entry Points: Examine message flow for entry points.
  2. Handler Cost Estimation: Estimate the cost for each handler.
  3. Check msg_value: Ensure sufficient msg_value at entry points.
  4. Avoid Excessive Demands: Don’t uniformly demand high gas (e.g., 1 TON); allocate gas proportionally to the intended actions.

Complexities in Gas Estimation

  • Development Changes: Update gas requirements if your contract’s message-sending behavior changes.

Returning Gas Excesses

  • Accumulation of Funds: Unreturned excess gas accumulates in contracts.
  • Standard Practice: Implement a function to return excesses (e.g., op::excesses in TON Jetton).

Mechanism in TON

  • Forward Remaining Gas: SEND_MODE_CARRY_ALL_REMAINING_MESSAGE_VALUE for linear message flows.
  • Exceptions: Avoid this mode when:
    • Contract actions reduce balance, not msg_value.
    • storage_fee depletes contract balance.
    • Emitting events or attaching value to messages reduces contract balance.

Calculating Gas Cost in TON

  • Example from TON Wallet:
    • Consider storage_fee and const::gas_consumption.
    • Adjust msg_value for these fees and forward ton amounts.
    • Return remaining msg_value to prevent partial execution.

Resume

  • Developer Responsibility: Active management of gas, considering the entire transaction process.
  • Potential Increase in Costs: Monitor for “unbounded data structure” use.
  • Return Excesses: Essential for efficient gas management.
  • Risk of Partial Execution: A critical concern if gas runs out.

Blockchain Transaction Fees

  • Economic Model: Validators are compensated in blockchain’s token (e.g., TON coin in TON blockchain).
  • Gas Analogy: Necessary for transaction execution, similar to fuel for cars.
  • User Transactions: Require gas payment, authorized via wallet signatures.
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.