The Asset Cross-chain in BTTC

Published in

TRON

11 min readNov 11, 2021

Introduction

The article SPV in TRON cross chain mentioned that the cross-chain is the value circulation/transfer between different chains, and the circulation is realized by cross-chain transactions. This article will continue to discuss another interesting topic in cross-chain area: the asset cross-chain in BTTC(BitTorrent-Chain). The main content of this article includes:

Background
Technical difficulties of asset cross-chain
The implementation of asset cross-chain in BTTC
The core principles
Summary

Background

The cross-chain we usually talk about has a very wide coverage. however, this article will simply divide cross-chain into information cross-chain (such as Polkadot) and asset cross-chain according to the types of cross-chain entities. With the vigorous development of public chains such as Matic Network, BSC, Solana, and TRON (there are a large number of Defi applications and various assets on these chains, among which the staking volume of Defi on Ethereum has exceeded 100 billion U.S. dollars). The assets volume of these public chains is already quite large, but different chains are like islands, and assets on different chains cannot be exchanged freely, therefore, there is a demand for asset cross-chain. In simple words, the asset cross-chain means the assets within different chains can be safely, freely, and conveniently transferred and circulated between different chains.

First of all, let’s take a look at what a typical asset cross-chain process looks like. Let us use the simplest and most mature asset cross-chain solution wBTC to explain, as shown in the figure below.

Alice wants to transfer 1 BTC to her Ethereum account via wBTC. The steps are as follows:

Alice stake 1 BTC to a staking address managed by the wBTC team via multi-signatures in the Bitcoin network;
The wBTC detects Alice’s staking record on the Bitcoin network, and informs its smart contract in the Ethereum network of this staking;
The smart contract of wBTC in Ethereum mints a wBTC in the Ethereum network after receiving the cross-chain information, and transfers it to Alice’s Ethereum address to complete Alice’s cross-chain request.

Technical difficulties of asset cross-chain

From the above process, asset cross-chain seems to be very simple. But is this really the case? the answer is negative. Let us continue to use Alice’s BTC asset cross-chain process as an example. Many issues need to be considered in the whole process, which also means the technical difficulties in the assets cross-chain.

How to let the target chain (the target network in the above process is the Ethereum network) know the specific information and progress of Alice’s cross-chain request? In other words, how does the target chain know that an asset cross-chain request has been initiated on the Bitcoin network?
How to give Alice the assets in the target Ethereum network? in simple words, Alice has deposited a BTC asset on the Bitcoin network, so how does the Ethereum network issue the corresponding asset and transfer it to Alice?
When Alice wants to withdraw wBTC from Ethereum to the Bitcoin network, how to make the Bitcoin network believe that Alice’s withdrawal request on Ethereum is reasonable and correct?
When the target chain network is threatened, how to ensure the security of users’ assets on the Bitcoin chain and ensure that the assets can be withdrawn?

Regarding the above four issues, this article will introduce the current common solutions one by one.

Issue 1. At present, the simplest and most common solution is to introduce multiple nodes to monitor events on the blockchain at the same time. When the majority of nodes agree that they have seen the event, it can be considered that these nodes have reached a consensus on this event and then trigger the next step. The key point here is how to reach a consensus on the coming events, many consensuses were used to achieve this: the first category is the centralized methods, for example, exchange cross-chain, such as WBTC; the second is the decentralized category, such as Matic, xDAI, and other solutions which are based on PoS(Proof of Stake).
Issue 2. To explain this issue, let us take USDC from Ethereum to Fantom (a high-performance public chain based on DAG technology and support smart contracts) as an example to introduce several mainstream asset cross-chain solutions:

1. Balance Flow: When the initiator’s 1 USDC is staked in the cross-chain contract on Ethereum, the oracle will notify the cross-chain contract on Fantom, and the contract on Fantom will send 1 USDC to the receivers’ Fantom address; this method is more common in centralized cross-chain bridges, such as Binance Bridge;2. Mint/Burn: When the initiator’s 1 USDC is staked in the cross-chain contract on Ethereum, the oracle will notify the cross-chain contract on Fantom, and the contract on Fantom will mint the corresponding 1 USDC and send it to the recipient’s address in Fantom (the USDC minted on Fantom will be destroyed when the user withdraws USDC from Fantom to Ethereum); for example: The Dai on the xDAI chain by Token Bridge.3. Liquidity Swap: When the initiator’s 1 USDC is staked in the cross-chain contract on Ethereum, the oracle will notify the cross-chain contract on Fantom, and the contract on Fantom will send 1 anyUSDC(Assuming the anyUSDC is swapped through Anyswap) to the recipient’s address in Fantom, and the anyUSDC can be swapped to USDC in Fantom.

Issue 3 is to solve the credibility of target chain information. The current mainstream solutions are fraud proof and validity proof.
Issue 4 is essentially the data availability. To ensure the data availability of the target chain, the target chain must be as decentralized as possible. When the target chain has enough nodes, it can effectively prevent the security risk.

The implementation of asset cross-chain in BTTC

Let’s first look at the overall architecture of the Bittorrent-Chain, as shown below.

The entire Bittorrent-Chain is divided into three layers. The top layer is the contract layer on the main chain (Ethereum, TRON, BSC). These contracts manage all user assets and manage all the staking. In the middle is the validator layer, which is responsible for aggregating the blocks of the side chain layer into a merkel tree and periodically sending the merkel root to the main chain in the form of checkpoints. The bottom layer is the block production layer, which is responsible for aggregating transactions into blocks. This layer is 100% compatible with the Ethereum network.

The typical scenario for users to use the BTTC network to achieve assets cross-chain includes:

Users stake certain assets on the main network (Ethereum, TRON, or BSC) and obtain corresponding tokens on the side chain.
Users conduct various transactions (transfer/contract interactions, etc.) on the side chain.
In the opposite of step 1, the user withdraws the assets from the side chain to the main chain.

The detailed deposit and withdrawal processes are as follows:

As shown in the figure, the whole process is mainly divided into two-part, the left side of the above figure is the deposit process, and the right side is the withdrawal process.

The deposit process (the left part of the figure above)

Users can choose to deposit tokens on Ethereum, TRON, or BSC. By interacting with the RootchainManager contract on the corresponding main chain, the assets will be staked in the contract. Here we assumed that the user has staked a certain amount of ETH on the ETH chain.
A deposit event will be generated after the staking is executed in the smart contract.
The deposit event will be broadcasted to other validators and reach a consensus later after the validator layer monitored the deposit event. Here BTTC uses a PoS based consensus mechanism, which mainly solves the first issue mentioned in the previous section(how does the target chain discover the deposit events on the main chain), as long as there are more than 2/3+1 signatures collected from the BTTC chain Validators, then this deposit event will be treated as a consensus event on BTTC.
The deposit event will be on chain and stored on the validator layer after the validator layer reaches a consensus.
The side chain regularly pulls these deposit events from the validator layer and calls the depositTokenmethod of the ChildChain contract on the side chain to mint a certain amount of assets for the user.

Regarding the issue 2(mentioned above), BTTC chooses to use mint/burn solution to transfer the corresponding token to the user on the target chain. This solution is more flexible and compatible with existing tokens.

At this point, the user deposited a certain amount of ETH on Ethereum, and finally obtained the corresponding token on the side chain (here we call the ETH on the side chain as bETH), and the user can use these tokens to conduct transactions on the side chain, Participate in various Defi applications. Here we assumed that the user converts bETH into bTRX on the side chain (here we call the side chain TRX as bTRX). In the follow-up, we will use bTRX as an example to describe how to withdraw TRX on the TRON network from bTRX.

Withdrawal process (the right part of the figure above)

The user initiates a withdrawal transaction on the side chain (converting bTRX to TRX) and triggers the withdrawTokens method of the ChildChain contract on the side chain. This method will burn the user’s tokens on the side chain.
The Validator layer monitored the block header of the block which contains the token burning transaction and packs it into the checkpoint. Note: checkpoint is a very important concept in the deposit and withdrawal process, which will be introduced in detail in the next section.
The Validators broadcast the checkpoint to other validators and reach a consensus.
The checkpoint will be submitted to the main chain after the Validator layer reached a consensus, and the contract on the main chain will verify whether(The staking amount of validators who signed the checkpoint)/(total staking amount of all validators) > 2/3 based on the signatures in the checkpoint.
The user obtains the burn proof from the side chain via the BTTC sdk after the checkpoint was submitted to the main chain. (here BTTC use the burning proof to solve Issue 3 mentioned above)
The user submits the burning proof to the main chain via transaction, and the contract on the main chain will verify the validity of the burning transaction.
Once the mainnet verification is passed, the corresponding assets will be transferred to the user address.

The Core principles

Checkpoint

Checkpoint is the most important concept in the entire asset cross-chain. Checkpoint has two purposes here.

Providing the finality of the side chain block.
Providing proof of burn when users withdraw assets to the main chain.

Here is the structure of Checkpoint:

type Checkpoint struct {// Proposer is selected based on stake
Proposer types.HeimdallAddress `json:"proposer"`// StartBlock: The block number on sidechain layer from which this checkpoint starts
StartBlock uint64 `json:"startBlock"`// EndBlock: The block number on sidechain layer from which this checkpoint ends
EndBlock uint64 `json:"endBlock"`// RootHash is the Merkle root of all the leaves containing the 
// block headers starting from start to the end block
RootHash types.HeimdallHash `json:"rootHash"`// Account root hash for each validator 
// Hash of data that needs to be passed from Validator layer to Ethereum chain like slashing, withdraw topup etc.
AccountRootHash types.HeimdallHash `json:"accountRootHash"`// Timestamp when checkpoint was created on Validator layer
TimeStamp uint64 `json:"timestamp"`}

The roothash is one of the core structures of checkpoint, it is the Merkel root which includes all the side chain block headers from the start block to the end block, and roothash plays a very important role in the process of assets withdrawal.

Next, we will explain how the burning transaction mentioned above is ‘aggregated’ into Checkpoint. The blockhash of a block is calculated from all transactions in this block, as shown in the following formula:

// Multiple transactions in a block calculate blockhash
blockHash = keccak256([number, time, tx hash, receipt hash])

The burning transaction used for withdrawal is included in this block and used to calculate the blockhash. After a certain number of blocks have been accumulated (from startblock to endblock, see the checkpoint structure above), the roothash will be generated based on these blockhash, as shown in the following formula:

// checkpoint is Merkle root of all block hash
checkpoint’s roothash = Merkel[B(1), B(2), ….., B(n)]

Here roothash is a Merkel root containing block headers in a certain range.

At this point, we can see that when a user wants to withdraw an asset to the main chain, the user initiates a withdrawal transaction. This transaction is a burning transaction and is packaged into a block on the side chain, and then we have the blockhash, after accumulating multiple blocks, the roothash of these blocks is calculated, and other necessary information is also calculated and packaged together into the checkpoint. This checkpoint will be submitted to the contract on the main chain to verify the submitted proof of burn.

The proof of Burn

The checkpoint submitted to the main chain contract will be used to verify the proof of burn, and what does the proof of burn do? In simple words, it is used to prove that the user really did an asset withdrawal transaction on the side chain. After the main chain verifies that the burning proof is valid, the asset will be sent to the user’s address. On the contrary, if the verification fails, the user’s withdrawal will fail.

A burning proof mainly contains the following fields, which include all the information needed for the coming verification process.

1. headerNumber - Checkpoint header block number containing the burn tx
2. blockProof - Proof that the block header (in the child chain) is a leaf in the submitted merkle root
3. blockNumber - Block number containing the burn tx on child chain
4. blockTime - Burn tx block time
5. txRoot - Transactions root of block
6. receiptRoot - Receipts root of block
7. receipt - Receipt of the burn transaction
8. receiptProof - Merkle proof of the burn receipt
9. branchMask - 32 bits denoting the path of receipt in merkle patricia tree
10. receiptLogIndex - Log Index to read from the receipt

The core concept of these fields is the Merkel proof. as we know, to verify a transaction with Merkel proof, the key is constructing the Merkel path of that transaction. and in the verification phase, compare the Merkel root of the block with the hash calculated through the transaction and the Merkel path. as you can see there are several proofs in the above structure, namely blockProof, txRoot, and receiptProof.

We can understand the verification process of this burning proof in this way. First, verify that the transaction does exist in this block through txRoot, and receiptProof, and then use blockProof to verify that the block does exist in the submitted checkpoint. If they all exist, then it can be proved that the burning transaction does exist in this checkpoint and is confirmed on the side chain.

Summary

This article first introduces the background of asset cross-chain, the basic concepts of asset cross-chain, and puts forward several major technical difficulties that asset cross-chain may encounter with a typical asset cross-chain process. Then introduces how Bittorrent-Chain realizes asset cross-chain and describes in detail the process of deposit and withdraw of asset cross-chain, finally, focus on the checkpoint and burning proof.

At present, the mainstream asset cross-chain solutions in the industry generally can only transfer assets between the Ethereum chain and the side chain. The biggest advantage of Bittorrent-Chain is that it supports asset cross-chain between multiple mainstream public chains, not just limited to Ethereum. This will greatly facilitate the circulation and transfer of assets between different chains, forming an effect of 1+1+1>3.