TRC-256: Cross-Chain Fee Model

[tomatoishealthy]

tip: 256
title: Cross-Chain Fee Model
author: ray<ray.wu@tron.network>
discussions to: https://github.com/tronprotocol/tips/issues/256
category: TRC
status: DRAFT
created: 2021-04-02

Cross-Chain Fee Model

Simple Summary

This TIP explains the cross-chain fee model on TRON.

Abstract

Several resources in a blockchain network are limited, such as storage and computation. Transaction fees prevent individual users from consuming too many resources. TRON uses a resource-based model, for more detail: resource-model. As such, fees are charged for every transaction executed on TRON MainNet. Meanwhile, TRON will support cross-chain communication in the future, so there needs to be a complement to the fee model for cross-chain transactions.

Motivation

Most transactions on TRON MainNet consume two types of resources: Bandwidth and Energy. While TRX and TRC10 transfers only consume bandwidth, contract calls consume both bandwidth and energy given the flexibility of their codes that protects the mainnet from being misappropriated. The amount of energy consumed is subject to the complexity of the contract. Likewise, after cross-chain transactions are enabled at TRON, there will be different parallel chains interacting with TRON's mainnet. At that time, a reasonable fee model will be critical to the security and stability of the network as a whole. Compared with an interchain fee model, designing a cross-chain fee model is more challenging due to the differences in economic models and token systems among different chains. A reasonable cross-chain fee model must meet the following requirements:

1. The new cross-chain fee model must be compatible with the existing interchain transfers
2. The cross-chain fee model needs to prevent low-value trading attacks
3. The cross-chain fee model must be reasonably designed to ensure the stable operation of the entire ecosystem in the long run

Specification

CrossContract: A cross-chain trading activity that contains all the information needed for a cross-chain transaction, such as original chain, target chain, caller, type of transaction etc. CrossDataType: The type of cross-chain transaction. There are two types of transactions, namely cross-chain token transfer and cross-chain contract call. ProxyAccount: The proxy account for contract calling on the target chain. To ensure that cross-chain contracts can only be called by cross-chain transactions, all cross-chain contracts need to set ProxyAccount as the caller on the target chain. CrossToken: The data type of the cross-chain token transfer, which contains all required information for the transfer. ContractTrigger: The data type of the cross-chain contract call, which contains all required information for the call. It consists of two parts:

• data on the original chain's contract transactions
• data on the target chain's contract transactions

Rationale

At the moment, all transactions taking place on TRON consume handling fees. Regular transfers only consume bandwidth as the fee, while contract calls charge both bandwidth and energy. Users receive free bandwidth on a daily basis and can stake TRX for the two resources. In cases where their resources are insufficient, they may alternatively burn an equivalent amount of TRX to pay the fee. Handling fees are in place to ensure the sustainable and healthy operation of the blockchain-based economy, and it is even more so for cross-chain ecosystems. Handling fees for TRC10 cross-chain transfers will be charged in the same way as before, but the fee will be deducted on both chains. Suppose Account 1 on Chain A is going to make a TRC10 transfer to Account 2 on Chain B. In this case, Account 1 is required to pay the handling fee on both Chain A and Chain B, meaning all the fees are paid by Account 1 alone.

Account 1 has to meet the following requirements to be able to pay for the fees on both chains:

1. The TIP is based on the cross-chain theory of homogenous chains, where compatible key signature algorithms are adopted for parachains.
2. The amount of assets Account 1 holds on both chains must be greater than the corresponding fees required.

Fee model for TRC10 cross-chain transfers:

For a TRC10 transfer, Account 1 will first create and initiate a cross-chain token transaction and broadcast it to Chain A. Upon receiving the message, Chain A will verify it and deduct the fee from Account 1 according to the verified message. The transaction will then be sent to Chain B after being finalized on Chain A. Similarly, Chain B will verify the transaction and deduct the fee from Account 1 in the same way Chain A does. Given that each chain has its own native token, handing fees are calculated in the token of the chain concerned. Therefore, to ensure proper execution of a cross-chain token transaction, the sender needs to have enough tokens in the account for handling fees on both chains concerned.

Fee model for cross-chain contract calls:

Handling fees for cross-chain contract calls are charged in a way similar to cross-chain token transfers. After Account 1 initiates a cross-chain contract transaction to Chain A, Chain A will first verify the transaction, and if verification succeeds, Chain A will then deduct the handling fee from Account 1 and at the same time send Chain B a message that contains information of Account 1, or the contract caller. Having received and verified the message, Chain B will call the contract and deduct the handling fee from Account 1 on Chain B. Please note here: the fee deduction logic is slightly different between cross-chain contract calls and token transfers. This is because users can call the contract directly on Chain B, which means that the contract is not necessarily called through a cross-chain transaction. Therefore, a proxy account is introduced into the cross-chain contract call model to ensure that all cross-chain contracts are triggered via the proxy account, but the handling fee will still be deducted from Account 1, or the sender's account.

Implementation

Cross-chain token transfer

Handing fees of cross-chain token transfers are charged in the same way as on the original TRON MainNet, meaning that bandwidth will be deducted if there is enough of it in the account, otherwise, MainNet tokens will be burnt to pay the handling fee.

Cross-chain contract call

A field titled caller_address is added to the blockchain metadata to ensure the target chain can be called by the proxy account during a cross-chain contract call. When users initiate a cross-chain contract transaction, it is required, when setting up the target chain contract, to set this address as the owner of the target chain's contract transaction. This move is to ensure only this account is eligible to call the cross-chain contract function in the target chain.

message CrossChainInfo {
    ...
    bytes proxy_address;
    ...    
}

Body of cross-chain contract:

message ContractTrigger {
 TriggerSmartContract source = 1;
 TriggerSmartContract dest = 2;
}

Upon receiving the cross-chain contract, Chain B will parse the contract and check if owner_address is a proxy address. Since the proxy is an address without a private key, the step of signing and validating the transaction will be skipped. The execution logic remains unchanged and the handling fee is deducted from the real_owner's account.

function processTransaction(Transaction tx) {
  if (tx is CrossContract && tx is crossSmartContract) {
     1. skip the sign validate
     2. check owner_address is equal to proxy_address
     2. exec the transaction
     3. pay the fee;
  }
}

Current logic needs to be changed when it comes to fee deduction. In the case of cross-chain contract transactions, handling fees are deducted from real_address instead of the previous owner_address. First, it is required to add a field called caller_address to transaction data structure to store information of the real caller.

type TransactionCapsule {
   ......
   byte[] caller_address;
   ......
}

When the transaction is being processed, the outer-layer cross-chain transaction will be parsed to extract the contract transaction from the target chain, and the value of the owner of the outer-layer cross-chain transaction will be assigned to caller_address on the target chain. In addition, changes are made to the deduction of handling fees, where assets are first deducted from caller_address as handling fees if it is not null, otherwise, assets will be deducted from owner_address.

function pay(Transaction tx) {
   if(tx is crossSmartContract) {
      //  use the real_address to pay the fee instead of the owner_address
   }
}

[dkealervdsf]

When will the cross-chain fee be charged and how will it be handled if the transaction fails after the charged?

[Vita-Diva]

Although the cross-chain solution is only for isomorphic chains now, I always think linking heterogeneous chains is the ultimate goal of cross chain. The question is, can this fee model be extended to support heterogeneous cross-chain?

[tomatoishealthy]

When will the cross-chain fee be charged and how will it be handled if the transaction fails after the charge?

The fee will be charged when the transaction is executed, and won't be returned to the caller even the transaction fails.

[tomatoishealthy]

Although the cross-chain solution is only for isomorphic chains now, I always think linking heterogeneous chains is the ultimate goal of cross chain. The question is, can this fee model be extended to support heterogeneous cross-chain?

hoo, good question, the fee model for heterogeneous chains is still under design, any advice is welcomed.