aelf Tech Talks —Cross-Chain Mechanism Breakdown
Abstract
Cross-chain interaction is one of the hottest topics in the blockchain industry. Due to the natural isolation between blockchains and the rapid increase in the demand for data interaction between chains, cross-chain technology becomes very important for the underlying blockchain framework. Achieving blockchain interoperability is also considered to be an important step forward in new blockchain development and application. As a self-developed cross-chain project, aelf has a complete set of cross-chain solutions. This article will specifically introduce aelf’s important cross-chain characteristics and design concepts.
Cross-chain Introduction
Let’s take a look at what cross-chain interactivity is. The data or behavior generated in chain A can be applied to chain B in some way, and this process is called cross chain interaction or blockchain interoperability. For better understanding, ‘cross-chain’ interaction is used uniformly to represent this process and attributes. Current cross-chain applications include but are not limited to cross-chain transfers, cross-chain asset exchanges and chain capacity expansions. Implementation can be broken into two categories according to the compatibility of Application Protocols: The first one is to achieve cross-chain interoperability between blockchains that are compatible with each other’s Application Protocols, and the second one is to achieve cross-chain interoperability between blockchains that do not have compatible Application Protocols. There is no universal definition of cross-chain interoperability and no strict cross-chain standard, but all cross-chain solutions are designed to break through blockchain isolation and achieve data interaction between chains. Is it possible to completely remove chain-to-chain isolation? Of course not. In addition to blockchain projects that are naturally isolated due to protocol incompatibility, the more important significance of chain-to-chain isolation is achieving resource isolation. This enables different distributed applications to run on different chains, while not affecting each other. The process of cross chain interoperability achieves data association and interaction between chains under the premise of ensuring resource isolation to the greatest extent — this is also the design concept of aelf multi-chain platform.
aelf’s Multi-Chain Structure
Aelf is a multi-chain network based on a multi-level main-side chain system. Firstly, aelf’a Multi Chain Structure: one main chain, multiple side chain and multiple levels. Figure 1 shows the dependency relationship between chains. Each side chain is created based on their direct parent chain. The parent chain and child chain will be used to express this structural relationship and this means that each chain can create its own child chain. The advantages of aelf’s multi-chain structure are not only that it can achieve application specific chain isolation, but also it creates more child chains to expand the application requirements by using chain dependency.
aelf’s multi chain structure is based on the core idea of ‘one chain — one scenario’. The main chain only supports system contracts such as consensus module, economic system module and cross chain module. The aelf community does not recommend deploying too many scenarios on the main chain, but to deploy a variety of scenarios to side chains. The scenario complexity of each side chain is O(1). Dapps of different types can be deployed on different side chains. Based on this design concept, aelf achieves resource isolation. At present, certain public chains often encounter a problem: a popular application may cause the whole blockchain to become congested, resulting in transaction costs on the chain to increase several times in a short period of time. The core reason is that all applications and assets are deployed on the same chain, in contrast, the design mechanism of one chain and one scene can effectively avoid this problem. The congestion of one chain will not affect the activity of all other chains.
Chain’s Life Cycle
The main-chain is the center of aelf’s ecosystem, and the first chain of the whole ecosystem. A number of system contracts are deployed on the main-chain, but all other specific applications need to deploy on designated side-chains. When creating a side chain, you need to mortgage a set amount of ELF tokens, provide information such as index fees and related resource token usage plans, and finally wait for the community to approve the submission. After the side-chain creation submission is approved, the side-chain can be created and launched, it will then be indexed by the main-chain (the content of the index will be introduced later). After approval, the chain’s index fee should be regularly replenished to ensure that the main-chain provides stable indexing services. If you need to stop indexing the side-chain, it is also necessary to obtain the community’s approval, after which the main-chain will officially stop indexing the side-chain. The process of creating a child-chain based on the side-chain is the same process as above. At this time, any side-chain will act similarly to the parent-chain.
Cross-chain index
An index is the transfer of data from one chain to another in a defined structure. Cross-chain indexing is the premise to achieve any cross-chain functionality. aelf adopts the concept of “joint mining” , in which miners complete the indexing process on their own. This 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 effectively run blockchains are considered safe to index. The idea of ‘joint mining’ adopted by aelf fundamentally solves the problem, and takes into account the normal running of the main-chain and side-chains, instead of designing redundant trust mechanisms for the chain itself.
- The second problem is whether the data index is decentralized. This is a more difficult problem in the cross-chain process. Ensuring decentralization is a major challenge for all cross-chain solutions. aelf’s strategy is that the miner completes indexing independently, and the indexed data participates in the consensus verification process with the common data. Therefore, the aelf indexing process and data source are both completely decentralized, which guarantees the security of indexed data to the greatest extent.
The Cross-Chain index is divided into two parts: Parent-Chain index Child-Chain and Child-Chain index Parent-Chain.
- The parent-chain gets data from the child-chain. The parent-chain requests data for the child-chain needed to index it, as shown in Figure 2. The child-chain passes the Transaction Status Merkle Tree Root in the block to the main-chain.
- The parent-chain processes all the child-chain’s index data, generating a Merkle tree, and stores it inside the chain. As shown in Figure 3, the child-chain block has been indexed by the parent-chain, and must wait for the data to be confirmed by the network.
- The child-chain indexes the parent-chain’s block, that is, requests data from the parent-chain. As shown in Figure 4, the data returned by the child-chain: 1. Calculated Merkle Tree Root; Merkle Path.
The above steps include the whole process of the parent-chain indexing the child-chain’s block and the child-chain re-indexing the parent-chain’s block. It is important to emphasize that only irreversible blocks can be indexed by other chains. This is because the blockchain is a decentralized distributed ledger and the data may be reversed prior to confirmation. Only confirmed data is seen to be irreversible and can be trusted, which effectively protects the cross-chain’s security. Ensuring that there are enough nodes in the same state avoids the impact of cross-chain data on the chain.
Cross-chain verification
Cross chain verification is intuitively understood as verifying what happens on chain A and chain B. The design philosophy of aelf’s multi-chain structure is ‘one chain, one scenario’, and not all chains are directly connected. Chain-to-chain verification relationships are also consistent with the principles associated with scenario deployment, as follows:
- The parent-chain and the child-chain can verify each other
- The child-chain of the same level (sibling chains) can verify each other.
- Chains of other relationships can not verify each other
The common data structure applied by aelf is Merkle Tree. This data structure is also mentioned in the indexing process above. The leaf node contains specific data to hash the result value, and the leaf node will then hash up to the root node. Here, aelf uses the encryption algorithm of SHA256.
The Merkel tree was chosen because this process can be done at a very low cost. As shown in figure 6, the Calculation Path from the red leaf node to the root node in the tree is set to the Merkle Path. The Merkle Path can be easily extracted from the tree, as shown in the green node in figure 6. The Merkle tree root in the indexing process mentioned above is a 32-byte fixed-length data structure. The Merkle path only needs to pay the space complexity of log (n), which greatly reduces the load pressure of cross-chain data transmissions, ensuring cross-chain efficiency.
The structure of the tree and the SHA256 Algorithm ensure this: The consistency of the root node ensures the validity of the whole tree. Cross-chain verification is also designed based on such features. According to the characteristics of the Merkle tree, only the leaf node and the extracted Merkle path can be used to calculate the final yellow root node. In the cross-chain verification process, we only need to use the Merkle Path once from any leaf node to the root node to verify the data’s accuracy, using time complexity log(n) to ensure verification efficiency.
By using the above structure, the proof of data existence can be completed efficiently and cross-chain verification can be achieved. Existence proof is the core advantage of aelf’s cross-chain mechanism. The cross-chain module is not limited to a specific application, but provides an efficient platform to develop cross-chain applications by using the existence proof. Based on this, aelf can engage and implement more application scenarios in the future.
Conclusion
aelf is committed to building a decentralized cross chain platform by providing feasible cross chain solutions. Based on the design concept of ‘one chain, one scenario’, aelf’s cross-chain mechanism can achieve cross-chain data interoperability effectively and securely. At the same time, it can ensure the isolation of resources between each chain. The indexing service provided by the main-chain block’s node can ensure decentralization. The index data load is low, ensuring the efficiency of cross-chain interoperability. Only irreversible blocks are indexed by other chain rules, ensuring cross-chain security. The classical Merkle Proof method guarantees the efficiency of cross-chain verification.
— Join the Community:
· Get on our Telegram Discord Slack and Kakao channel
· Follow us on Twitter Reddit and Facebook
· Read weekly articles on the aelf blog
· Catch up with the develop progress on Github
· Telegram community in 한국, 日本 語, русский, العربية, Deutsch, Italiano and Tiếng Việt
· Instagram: aelfblockchain
· YouTube Channel: aelf
For more information, visit aelf.io
