SPV in Tron cross chain

Published in

TRON

10 min readJun 7, 2021

One of the hot spots of blockchain technology in 2021 is cross-chain. Here is a simple understanding of cross-chain: one blockchain is one independent ledger, two different chains are not related, and there is no way to transfer values between the two ledgers. However, for a specific user, the value on one blockchain can become the value on another chain, this is called value circulation/transfer, and cross-chain technology is to allow value to circulate between different chains.

As one of the most popular public chains in the world, TRON’s cross-chain technology can greatly expand TRON’s entire ecosystem. In the implementation of TRON’s cross-chain project, TRON has innovatively used many technologies to solve various problems encountered in the cross-chain. And this article will focus on the important role that SPV (Simрlifiеd Payment Verification) plays in the implementation of this decentralized cross-chain project.

Background

The core function of a typical cross-chain project is to support cross-chain transactions. A simple understanding of the difference between cross-chain transactions and on-chain transactions is that cross-chain transactions involve two transactions on two different chains. These two transactions are dependent on each other to meet the characteristics of cross-chain transactions such as atomicity. This introduces a big problem if the transaction on chain A (deducting Token1 from Alice’s account) has not been confirmed, and the transaction on chain B (adding Token2 to Bob’s account) has been successfully executed, so the deduction of Token1 from the Alice account may fail in the end, resulting in asset loss.

The root cause of the above problem is that when chain B is executing the transaction, it cannot know whether the deduction transaction on chain A has been solidified. Only when the transaction on chain A has been solidified, it is reasonable to execute the transaction on chain B.

How does one chain know whether a certain transaction on the other chain is already solidified? SPV technology is the answer. The role of SPV in cross-chain is to give chain B a way to know whether the transaction on chain A is confirmed (solidified), which is equivalent to verifying whether the transaction on chain A is confirmed. Only when the transaction on chain A is confirmed, chain B is allowed to execute the subsequent logic, and therefore guarantee the safety of the cross-chain transaction.

How to verify whether a transaction is confirmed on the other chain?

How to verify whether the transaction is confirmed on the other chain? The easiest way is to have a complete data copy of the other chain, which means to have a complete database of the other chain locally, and verify whether a transaction is on the chain only needs to retrieve it in this database. However, the data size of the TRON mainnet is close to 700G, and the data size will continue to expand in the future, and in the cross-chain scenario, one chain may have to interact with multiple chains, it is impractical to save the data of all other chains.

Here we will introduce the SPV, which is the “Simрlifiеd Payment Verification”. There are two keywords here, one is “simple”, and the other is “payment verification”. This concept was first mentioned in Satoshi Nakamoto’s paper. The paper pointed out that the payment can be verified without running a full node, just saving all the block headers.

Initially, SPV was used for light nodes. Light nodes refer to the technology in which nodes only store the block headers to validate the authenticity of the transactions instead of storing complete blockchain data. The full node, the complete blockchain node, is the node that synchronously saves all blockchain data.

A complete block includes a block header and a block body. The block body contains all transaction data and the block header contains one Merkle root in it. as the picture shows:

Merkle tree is a kind of hash binary tree. One of its obvious advantages is that it can use a branch(as a small tree) to verify part of the data, which is more efficient. The block structure in the above figure shows that a block body contains such a Merkle tree, which is used to summarize all transactions in the block. Each leaf node is the hash of each transaction, and the two adjacent hashes are merged into a string and then hashed, and repeat the similar operation until only one node left, that is the `Merkle root,` which is stored in the block header.

From the above definition of SPV, we can see that only need to get all the block headers of the other chain to verify the payment, no need to sync the whole block data.

In essence, SPV utilizes two basic characteristics of the blockchain:

Merkle proof: It can be used to verify whether a transaction is included in the Merkle tree, which is represented by the Merkle root;
Block header: Contains the Merkle Root of the Merkle tree composed of all transactions in the block, and uses this Merkle Root to represent this block;

Then suppose that chain A wants to verify whether a specific transaction is processed and included in the block of chain B. It only needs to know:

The latest block header list of chain B.
Merkle Proof list of the transaction.

The block header structure in the TRON cross-chain project is as below:

message BlockHeader {
  message raw {
    int64 timestamp = 1;
 bytes txTrieRoot = 2;
 bytes parentHash = 3;
 int64 number = 7;
 int64 witness_id = 8;
 bytes witness_address = 9;
 int32 version = 10;
 bytes accountStateRoot = 11;
 bytes chainId = 12;
 bytes crossTxRoot = 13;
 }
  raw raw_data = 1;
 bytes witness_signature = 2;
}

The most important attribute related to SPV in the data structure above is the txTrieRoot, which is the Merkel Root of all transactions in this block, it will be used in verification.

Another very important data structure is the Merkle path, which is also an important part of payment verification. The Merkle path is a hash path composed of node hash values, from the bottom leaf node to the top node, the node hash value is calculated by the given transaction hash value. Below is what a typical Merkle path looks like :

The Merkle path of the transaction hash K (green square) is the list of hashes in the blue square above.

In the implementation, we store all transaction hashes of the block in the Merkle tree, because the Merkle tree satisfies the following two characteristics:

High efficiency: To verify two transactions, just compare whether the Merkle Root of the two Merkle trees is the same. If the same, it means the transactions are the same.
High security: If a transaction K changes, it will lead to the Merkle Root change, so it is difficult to forge a transaction.

Back to the implementation of TRON’s cross-chain, to verify whether a transaction is on the chain, the specific steps are as follows:

A. Chain A connects to chain B to synchronize the latest block header list.

B. Chain B sends a transaction to chain A. This transaction includes a Merkle proof. The algorithm for constructing the Merkle proof is as follows:

1. Given a transaction hash value.
2. Obtain the transaction hash values list of the related block from the full node and mark them as leaf nodes.
3. Traverse all leaf nodes in a group of two, calculates the parent hash value of each two leaf node, adds it to the parent list, and finds the leaf node that matches the given transaction hash value.
4. Add the hash values of the other nodes in the group to the Merkle proof list and mark its parent node.
5. Iterate the parent node list in a group of two each time, calculate the hash value of each two nodes, and add it to the temporary parent node list and find the marked node.
6. Add the other node of the group to the Merkle proof list and mark its parent node.
7. Replace the left nodes list with the temporary parent node list, check the size of the node list, If it is greater than 1, go to step 5, otherwise return to the Merkle proof list

C. Chain A receives the transaction and uses the Merkle proof in the transaction and the latest block header list(synchronized from chain B) to verify the transaction.

The function signature for verifying Merkel’s proof is as follows:

public boolean validProof(Sha256Hash root, List<ProofLeaf> proofPath, Sha256Hash src)

How does TRON innovatively solve the existing problems of the SPV?

Using SPV to verify the legitimacy of transactions on the other chain is a common practice in the industry. However, there is a big problem in the above solution, that is, if chain A connected to a malicious node, the synchronized block header may have been tampered with, if the transaction is verified based on the tampered block header, the consequences are very serious. A big pain point in traditional SPV applications is traditional SPV applications (such as light wallets, light nodes, etc.) must unconditionally trust the connected node for synchronization and believe that they will not do evil. But obviously, this idea is too naive.

When the TRON cross-chain project applied the SPV technology, the TRON team innovatively gave a solution to solve the above-mentioned problem. The following will describe in detail how TRON solves the issue.

Here is a brief introduction to the TRON consensus as the solution requires us to have a deep understanding of the TRON consensus. TRON’s consensus is based on the DPOS algorithm. In the DPOS consensus, each slot is assigned to the one legal SR, after PBFT is enabled, The SR will use its slot to produce and broadcast the block and finally reach a consensus by the entire network, and then the block is solidified.

As mentioned above, if a node on chain A maliciously tampered with the block header, how to prevent it? In the blockchain world, signatures are used to verify whether a transaction has been tampered with, and learn from the idea of transaction signatures. We can sign the block headers before synchronization to prevent being tampered with. The SignedBlockHeader is designed with the following structure:

message SignedBlockHeader {
BlockHeader blockHeader = 1;
repeated bytes srs_signature = 2;
PBFTCommitResult sr_list = 3;
}

The SignedBlockHeader contains the original block header data, as well as the block header signature list and the legal SR List in the current period.

Here we first introduce a concept, threshold signature, which means a valid signature needs at least t participants in the group to generate it. Anyone who plays the role of a verifier can use the public key of the community to verify the community signature without identifying the signer’s identity.

In the TRON consensus, in each block production period, there are a total of 27 SRs, to prove the legitimacy of the block header needs more than 2/3 +1 SRs to sign the block header. Essentially, it still follows the consensus of the majority. Once the verifier has collected 2/3 +1 SR signatures for this block header, it means the block header is confirmed and reaches the consensus.

Another concept, SR List is a data structure used for block header verification, which includes a list of SR Addresses. In the maintenance period, all stakeholders will select a new SR list, and the new SR list will be signed by the SRs of the previous period. Once 2/3 +1 of the SR signatures are collected, then the new SR list can be trusted.

The data structure of the SR List are as follows:

message SRL {
repeated bytes srAddress = 1;
}

It can be seen from the above introduction that within a period if the verifier knows the legal SR list, they can easily verify each block header. Because the block header contains the list of legal SR Addresses, we only need to verify whether the Address of this SR is in the legal SR list.

As a node of chain A, it is impossible to know the legal SR list of the next period on Chain B. Chain A as a validator does not process most transactions, including the voting transactions, They have no way to know the result of the vote. In other words, they cannot know the next legal SR list.

TRON solves this problem by including the SR list in a PBFT message, which is sent by the previous legal SR. During the maintenance period, we use the previous legal SR List to sign the new SR list of the next period. Once more than 2/3 of the SR signatures are collected, it means that the new SR list for the next period is confirmed and reaches consensus.

The signature verification function of the SR List is as follows:

public boolean validSrList(PBFTCommitResult dataSign, Set<ByteString> preSRL)

To summarize here, to ensure the block header synchronized from the other chain has not been tampered with, TRON signs the block header by referring to the method of verifying whether a transaction on the blockchain has been tampered with. The block header here requires more than 2/3 of the SRs’ signature to show that chain A reaches a consensus on the block header. For chain B, to verify whether the block header has tampered with only need to verify whether the block is produced by a legal SR. The verifier only needs to check whether the SR who produced this block is in the legal SR List. And to ensure whether the SR list is legal, chain A uses the legal SRs of the previous period to sign the new legal SR list of the next period during the maintenance period to achieve this.

Summary

This article first explains the background of the TRON cross-chain project and the security issues that will inevitably occur in cross-chain transactions, and then introduces the SPV technology commonly used in the industry to solve cross-chain security issues. This article also points out the potential risk in general solutions and then described in detail how the TRON cross-chain project innovatively solves the security problems.

TRON has adopted reasonable parts of the transactions verification process and solves the potential risk that may arise in it. TRON’s solution will guarantee the security of the cross-chain transactions and establish a safe environment for TRON’s cross-chain ecosystem.