aelf Tech Talks — Design and Practice of Blockchain Cross-chain Technology — Part 3

Understanding aelf’s Cross-Chain Design

Published in

aelf

5 min readNov 20, 2019

We have reached the final segment to this series, aelf’s cross-chain design. Strictly speaking, aelf also completes cross-chain based on the relay mode. The RPC service in the cross-chain part is based on GRPC.

In order to understand the cross-chain architecture of aelf, it is important to know about the aelf multi-chain structure. This can be summed up very simply, one main chain, multiple side chains, and multiple layers. In order to express this relative relationship, I will call them a parent chain and a child chain. The figure below represents the affiliation between chains, the child chain is created by the parent chain.

This multi-chain structure of aelf is based on a core concept, one chain for one contract or use-case. A main chain, only supports system modules such as the consensus, economic system and cross-chain modules. aelf has only one main chain. A variety of complex contracts are designated to individual side chains. The scene complexity of each side chain is O(1), and DApps of different scenarios are deployed on different chains. We have previously mentioned the isolation of resources. Some readers may recall the CryptoKitties situation on Ethereum near the end 2017, such a simple application caused the entire Ethereum chain to be congested beyond use for a short period. Ethereum transaction fees increased tenfold. This is a clear shortcoming of any application or asset running on the same chain. Any sudden increase of application usage will adversely affect the entire chain, unless the ecosystem is designed to accommodate one sidechain for each application. Increased use on an individual chain does not affect anny other application.

After understanding the multi-chain structure, let’s look at cross-chain verification. Cross-chain verification is to verify what happens on B-chain on A-chain. First, it is important to understand the data structure used, the Merkle tree. This is a common binary tree where each branch starts with the result of hashing the transaction data, and then travels up each level by hashing multiple groups from the previous level until you get the root hash. aelf uses the SHA256 encryption algorithm in this situation. From the structure of this tree and the characteristics of the hash algorithm, we can determine that the integrity of the root hash represents the integrity of the whole tree, and thus the most important component is this root hash. The merkle path can be easily extracted from the tree, such as the green hashes in the figure below. After extracting these, you will find that the red hash can be calculated with simplicity.

I have given a pseudo-code of a comparable image here. In fact, you only need to have the original data of a transaction, and its Merkle path on this tree, you can calculate the root of the tree, you can judge the integrity of the transaction through the integrity of the root.

With the method and structure of validation, let’s look at how the data is indexed and exchanged. First look at the parent chain index subchain, the parent chain constructs a new Merkle tree with the Tx root of all the child chains, and records it on a block of its own chain, after which the child chain is also indexed to this height, the parent chain will give the Merkle path that previously calculated the Merkle tree root and the height of the corresponding sub-chain block to the sub-chain.

There is a requirement that only the height of an irreversible block can be indexed by other chains. This is because the blockchain is a decentralized distributed ledger, and the data can be reversed before it is confirmed. Only data that is confirmed to be irreversible is credible, which effectively protects the security of the chain, reducing the impact of cross-chain data on the chain, and ensure that enough nodes are in the same state. In addition, aelf’s cross-chain index also guarantees efficiency. The indexing process we just saw is a Merkle tree root of 32 bytes, which is determined by the data structure, and the spatial complexity of the Merkle path log(n).

AElf’s multi-chain structure is based on the idea of a one use-case chain structure. Not all chains are related, so it’s important to understand the verification relationship between chains. A parent chain and their child chain can mutually verify each other. Connected sidechains can also be mutually authenticated, but unconnected chains cannot be mutually authenticated.

The image below is a summary of the characteristics of aelf’s cross-chain design.

aelf Tech Talks — Design and Practice of Blockchain Cross-chain Technology — Part 3

Understanding aelf’s Cross-Chain Design

Other Topics in aelf Tech Talks:

Written by aelf Developer