Interpretation of aelf cross - chain transfer implementation

Original title: "aelf technical point interpretation of | cross-chain transfer implementation"

Source: aelf 

Cross-chain is one of the hottest topics in the field of blockchain. Due to the natural isolation between chains and the sharp increase in the demand for data interaction between chains, cross-chain technology has become an important technical demand for the underlying environment of blockchain. The development concept of Interoperability of blockchain is also regarded as an important exploration direction of blockchain technology. Aelf, as a cross-chain project independently developed, has a complete set of cross-chain solutions. This paper will specifically introduce the important features and design concepts of aelf in cross-chain.

Across the chain briefly

Before we get into the subject, let's take a look at what cross-linking is. The process by which the data or behavior generated on the A chain is applied in some form to the B chain is called cross-chain. Interoperability is an attribute description of the above cross-chain process. For the sake of understanding, the following sections use the term "cross-chain" to represent this process and property. Current cross-chain application scenarios include but are not limited to cross-chain transfer, cross-chain asset exchange and chain expansion. According to application protocol compatibility, the implementation of cross-chain can be divided into two categories: the first category is the implementation of cross-chain between blocks that are compatible with each other, and the second category is the implementation of cross-chain between blocks that are incompatible with the application protocol.

The definition of cross-chain is broad and there is no strict cross-chain standard, but all cross-chain solutions are designed to break through the isolation between chains and realize the data interaction between chains. So can we get rid of chain isolation altogether? Of course not. In addition to the block chain projects that are naturally isolated due to protocol incompatibility, a more important meaning of inter-chain isolation lies in the realization of resource isolation. Resource isolation enables different distributed application scenarios to run on different chains, and different application scenarios will not affect each other. The cross-chain process is to realize data association and interaction between chains on the premise of ensuring resource isolation to the greatest extent, which is also the design concept of multi-chain platform aelf.

Aelf multi-chain structure

Aelf is a multi - chain network based on multi - stage main - side chain system. Firstly, the multi-chain structure of aelf is analyzed: a main chain, multi-side chain and multi-hierarchy. Figure 1 shows the subordination relationship between chains. Each side chain is created based on the previous chain, and this structural relationship is expressed in terms of parent and child chains. This structural relationship means that each chain can create its own subchain. The advantage of aelf's multi-chain structure is that it can not only realize the chain isolation of different application scenarios, but also create more sub-chains to extend the application scenarios by using the chain dependency.

Figure 1

& have spent

The multi-chain structure of aelf is designed based on the core concept of one chain one scene. The main chain only supports system contracts such as consensus module, economic system module and cross-chain module, and the aelf community does not recommend deploying too many scenarios on the main chain, but instead deploys a rich variety of scenarios to the side chain. The scene complexity of each side chain is O(1), and DApp of different scenes can be deployed on different side chains. Based on this design philosophy, aelf implements the previously mentioned resource isolation. Some male chain often encounter a problem at present: a single hot style application which may lead to blockages in the whole chain, chain in a short time on transaction fees several times, the fundamental reason is that all applications and assets are deployed on the same chain, but a chain mechanism can effectively avoid the problem of a scenario, a chain block does not affect the normal operation of the other chain.

& have spent

The life cycle of the chain

& have spent

The main chain is the backbone of the aelf ecosystem and the first chain for the whole ecosystem to start running. Several system contracts are deployed on the main chain, and other specific application scenarios need to apply to create and deploy on the side chain. When the side chain is created, an application needs to be submitted to the community, at the same time, a certain amount of ELF token is needed to mortgage, and information such as index cost and related resource token usage plan is provided, waiting for the approval of the community. After the side chain creation application is approved, the side chain can be created and started to run, and the side chain will be immediately cited by the main chain (the contents of the index will be introduced later). After the application of the side chain can be used to recharge the chain index fee to ensure that the main chain provides stable index service. If it is necessary to stop the index of the side chain, it is also necessary to submit an application to the community, after the approval of the main chain officially stop the index of the side chain. The process of creating a subordinate child chain based on the side chain is consistent with the above process, where the side chain ACTS as the parent chain.

& have spent

Across the chain index

& have spent

An index is the passing of data from one chain to another in a defined structure. The cross chain lead is the precondition to realize any cross chain function. Aelf adopts the concept of "joint mining", in which miners complete the indexing process on their own.

Design like aelf can effectively solve two problems:

The first question is whether a chain can be trusted. This is a common problem in cross-chain processes, where only a functioning blockchain is considered safe to index. Aelf adopts the concept of "joint mining" to fundamentally solve this problem, which can give consideration to the normal operation of the main chain and the side chain, and does not need to design redundant trust mechanism on the chain itself.

The second question is whether data indexing is decentralized. This is a tricky problem in the cross-chain process. How to ensure decentralization is a major challenge for cross-chain solutions. The strategy of aelf is that miners complete the index independently, and the index data participate in the verification process such as consensus as common data, so the index process and data source of aelf are completely decentralized, which can guarantee the security of the index data to the greatest extent.

& have spent

Aelf cross chain lead is divided into two parts: parent chain lead chain and child chain lead parent chain

The parent fetches data from the child. The parent chain requests data for the subchain it needs to index, as shown in figure 2. The subchain passes Transaction status merkle tree root in the block to the main chain.

The parent chain processes all the subchain data of the index, generates Merkle tree, and stores it inside the chain, as shown in figure 3. At this point, the sub-chain block has been cited by the parent chain, just wait for the data to be confirmed by the network.

The child chain lead to the parent chain block, that is, from the parent chain request data. As shown in figure 4, the data returned by the subchain: 1. The calculated merkle tree root; 2. 2. Merkle path.

& have spent

The above steps include the complete process of parent chain chain block and subchain reindex parent chain block. It is important to note that only irreversible blocks can be induced by other chains. This is because blockchain is a decentralized distributed ledger, and data can be reversed before being confirmed. Only data that is confirmed to be irreversible can be trusted, which can effectively protect the security of cross-chain, ensure that there are enough nodes in the same state, and avoid the impact of cross-chain data on this chain.

& have spent

Figure 2

Figure 3

Figure 4.

& have spent

Chain cross validation

& have spent

Cross-chain validation intuitively means verifying what's happening on chain A and chain B. The design concept of aelf multi-chain structure is one chain one scene, and not all the chains are connected. The verification relationship between chains also conforms to the principles related to scenario deployment, as follows:

Parent and child chains can verify each other

Sibling chains can verify each other

Chains of other relationships may not validate each other

Aelf USES a common data structure: the merkeltree. This data structure is also mentioned in the above indexing process. It is a normal tree structure, in which the leaf node contains the result value of Hash operation for certain data, and then the leaf node hashes up in pairs to the root node. Here aelf USES the SHA256 encryption algorithm.

Figure 5

& have spent

The merkel tree was chosen because this process can be done at a small cost. As shown in figure 6, the calculation Path from the red leaf node to the root node in the tree is extracted and set as Merkle Path. Merkle Path can be easily extracted from the tree, as shown in the green nodes in figure 6. As mentioned above, Merkle tree root in the indexing process is a fixed-length data structure of 32 bytes, and Merkle path only requires the space complexity of log(n), which greatly reduces the load pressure of cross-chain data transmission and ensures cross-chain efficiency.

The structure of the tree and the SHA256 algorithm together ensure the correctness of the entire tree through the consistency of the root node. Cross-chain validation is also designed based on this feature. According to the characteristics of the murkle tree, the final yellow root node can be calculated using only the leaf node and the extracted Merkle Path. In the process of cross-chain verification, the accuracy of data, time complexity log(n), and efficiency of verification can be verified by only one calculation from leaf node to root node using Merkle Path.

The above structure can be used to efficiently prove the existence of data, so as to realize cross-chain verification. The existence proof is the core of the aelf cross-chain mechanism. The aelf cross-chain module is not limited to a specific application scenario, but provides an efficient platform for developing cross-chain applications with proof of existence. Based on the existence proof, aelf can explore and realize more application scenarios in the future.

Figure 6.

& have spent

conclusion

Aelf aims to build decentralized cross-chain platforms by providing viable cross-chain solutions. Based on the design concept of "one chain one scenario", aelf cross-chain mechanism can effectively and safely realize cross-chain data interaction, and ensure effective isolation of resources between chains. The index service is provided by the block node of the main chain to ensure its degree of decentralization. Low load of index data can ensure efficient cross-chain; Only irreversible block can be led by other chain rules, & NBSP; Ensure the security of cross - chain; The classic Merkle Proof method can guarantee the cross-chain verification efficiency.

The original address: https://mp.weixin.qq.com/s/JdsW-Ulc10mMPQmqfXThnw

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia