A breakdown of the aelf blockchain whitepaper — Part 2

Breaking down the aelf side-chain

Cloud computing, parallel processing, and AEDPoS have greatly improved the execution performance of any kind of smart contract, but when they are applied to enterprise-level scenarios, new problems crop up. To begin with, in software design, it is a rather bad idea to program all the methods in the same class. We always write a series of classes to inherit a base class, in order to decouple the functionalities and make the class extensible whenever needed. The same also applies to blockchain design. Second, since all the data and transactions are accessible to anyone through a blockchain explorer, if we put the smart contract and data of different enterprises or government sectors on a single blockchain, then everyone can see them, which means there will be no data privacy. Although there are encryption techniques which can mask data, such as zero knowledge proof, it is always better to put the data of different enterprises on different blockchains.

Based on these considerations, long before other projects even realized it, aelf proposed that side-chain technology should be applied to this scenario. Unfortunately, for someone who is new to blockchain, it is almost impossible to understand how side-chain works. Side-chain is not what it literally means, it is not subordinate to the main chain. On the contrary, a side chain is a blockchain distributed system with the same functions and nodes as a main chain (say, the aelf blockchain). As mentioned above, we can put the data of different enterprises on different blockchains. This means we can build many blockchains, and work magic (of course not magic in its literal sense) to make these chains connect to the aelf main chain (in fact, we can call any of these blockchains a main chain and the rest side chains). Currently, the most popular method of connecting any two blockchains, which we also call cross-chain, is using a middle-man. When we want to use bitcoin to play a decentralized game on Ethereum, we need to send a transaction with some amount of bitcoin to a locking bitcoin address, then the middle-man will exchange the locked BTC for ETH at a certain exchange rate and allocate to you the equivalent amount of ETH on Ethereum, which you can use for playing games.

But in aelf, we use a metadata indexing method, which is more straightforward. Unlike other projects who built on the blockchains of those already successful projects (such as Ethereum or the HyperLedger fabric framework for consortium blockchains), the aelf team has writen all the code and build the infrastructure from scratch. From the beginning, the aelf team has defined how the data structure of a blockchain, a block, a transaction etc. should look like in C#. In an aelf blockchain data structure, there is an attribute called blockchain ID, which is a unique hash; and in block data structure, there are several attributes called blockchain ID , Merkle tree root and related side chain block list. There is also one more important thing: all of aelf’s data structures are serialized and stored in Redis (a popular key-value pair database system), so is the side chain information. As a result, as the aelf main chain is growing with block production by BPs, other side chains can send transactions to cross-chain contracts, which then execute the related code to connect to the main chain’s network port and request the main chain to index the side chain block and pay the indexing fee.

The core issue here is how to index a side chain: when a main chain (the block data structure on the main chain, or the data records with main chain ID in Redis), receives a request from a side chain, it adds the side chain’s block head data structure to the related side chain block list, which means theoretically we have indexed or related a side chain. We have mentioned that there is also a blockchain ID in each block, this attribute allows a main chain to index blocks from different side chains. When a user on a main chain wants to access data on a side chain or vise versa, they just need to find the target block on the main chain and its related side chain block list, and then find the target block on the side chain via key indexing.

As we will explain later, blockchains for different application scenarios generate blocks at different speeds. Under such circumstances, a chain with slower speed might index many blocks from a chain that produces blocks faster. This method can be applied to scenarios such as forking.

In practice, we can build any number of blockchains, and relate it via indexing to the aelf main chain, with a specific category of smart contracts running on each of them. For example, we can allow only banking-related smart contracts deployed on a specific blockchain, and e-commerce smart contracts on another. Our whitepaper summarizes it best:

One chain, one contract.

Moreover, the indexing method can make many blockchains into a hierarchical tree structure, the root being the so-called main chain. That’s because a related blockchain can then again index another blockchain as its side chain, and the process can keep going on. Logically, this is in perfect accordance with hierarchical taxonomy, for example, the financial sector has many subcategories, such as banking, lending, investment and insurance, and under investment banking, there are venture capital, investment bank etc… Each subcategory is supported by an indexed blockchain.

So how do these blockchains collaborate in a distributed system? First we need to be know that any node in a distributed system is just a software instance running on your computer, or a process. In TCP/IP, a node is allocated a port number, so we can run any number of this type of instances on a computer. However, each instance has its own port number: we can run several blockchain nodes, one IPFS node, one bit-torrent node and etc. simultaneously. In aelf, you should first start a main chain instance, and then you can build and run a side chain instance. Transactions broadcast on the side chain are collected by the BP nodes (block production nodes) on the main chain. When smart contracts deployed on the side chain is triggered, the BP and full nodes on the main chain will run them.

Aelf — a blockchain based operating system

To perfect the design of our software system, aelf made the system extensible, flexible and pluggable. Just as there are thousands of Linux OS with only one Linux kernel. As Ethereum Founder Vitalik Buterin has explained, Ethereum can be seen as a world computer because there are lots of smart contracts running on it, and the contract execution results are consistent in all the distributed systems around the world. This idea is also embedded in aelf’s system and we call it a “blockchain infrastructure operating system”, or a distributed operating system.

Just like any OS, aelf has a kernel and a shell. In fact, aelf’s kernel is not something like a Linux kernel, it is just an analogy. There is a special concept in aelf’s kernel called the minimum viable blockchain system, which defines the most fundamental aspect of a blockchain. If a developer wants to create a new blockchain system or a new blockchain project, he does’t have to start from scratch, instead, he can directly extend and customize using the aelf blockchain open-source code. The technologies described above are all included in the minimum viable blockchain system. With these, anyone can customize:

• Block property: block data structure, block packaging speed, transaction data structure, etc.
• Consensus type: AEDPoS is used by default, but you can also use incentive consensus, like PoW and PoS. And you can also use the consensus of traditional distributed systems, like PoS and Practical Byzantine Fault Tolerance, or PBFT. In fact, the f evil nodes of 3f+1 nodes are the upper limit for any distributed system to reach a consensus, which is called the Byzantine Fault Tolerance, or BFT. In order to do this, there is a specific algorithm, but in 1999, a much more efficient algorithm to reach this consensus came along, that is the PBFT. In scenarios like private blockchain or consortium blockchain where there is no need for a incentive model, PBFT will be a good option.
• Smart contract collection: In aelf, there are many predefined smart contracts that can be used directly by other contracts, such as token contract, cross-chain contract (also called CCTP, or cross chain transfer protocol), consensus contract, organization voting contracts, etc. Of course, you can also create your own contract with a brand new implementation logic.
• Others.

Summary

So this is our breakdown of the aelf blockchain whitepaper. In previous articles, we first introduced two basic concepts which are often misinterpreted by other articles. After helping you get these two concepts straight, we then introduced aelf’s vast arsenal of powerful technology. If these articles helped you understand the aelf blockchain better, then I have reached my goal. But I must advise you to read the whitepaper for a more detailed explanation. With all this knowledge at your disposal, I believe you will be much more comfortable developing DApps on aelf.

Check Part 1 here: https://medium.com/aelfblockchain/a-breakdown-of-the-aelf-blockchain-whitepaper-part-1-a63fc2e3e2e7

— 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