Presentation by Guanglei
In the recent aelf event — the one year anniversary; Core developer, Guanglei presented a technical breakdown of how aelf is implementing the key features of the aelf blockchain ecosystem. In this article I’ll take his presentation and break it down even further, pulling out some of the key components to give a brief overview of the aelf blockchain components.
Firstly, let me state the overall goal of aelf — that is to create a blockchain platform that is able to support a large number of commercial scale dApps. In order to achieve this, one fundamental belief we hold firm to is that we should employ many of the experiences and technologies that have been developed in traditional IT related industries. For the current blockchain technology aelf has identified 3 main problems that are limiting the mainstream adoption of this technology through out the wider community. These issues are:
· Governance of blockchains
· Lack of resource segregation
· Poor processing performance
In order for aelf to achieve our goal, we must resolve these issues in the development of our new ecosystem.
The main ingredients of the aelf blockchain fall under five components:
2. Main Chain + Side Chains
3. Parallel Processing
4. Cluster Bases
Well let me take a look at each of these components.
This consensus protocol allows stakeholders to pass votes to elect delegate nodes who will be executing the smart contracts, building blocks and reaching agreements. Stakeholders will also vote on major decisions, such as, how to upgrade system smart contracts to implement new rules on the chain. Development has been done for a randomization mechanism which is used to set the order of the delegated nodes. The production of the blocks are broken down into rounds and each delegate will be given a timeslot to produce their corresponding block.
Main Chain + Side Chains
This is discussing the architecture of the blockchain. This is very unique as each sidechain will be related to only one business use case. The main chain is primarily to index and oversee all the Side Chains, and we are currently completing this technology. A benefit of this indexing is that any Side Chain can approach the main chain asking to verify some data about another chain, and all they need is the indexing information which will be the merkle tree root stored on the Main Chain. See more about Merkle Trees here.
The parallel processing component is primarily designed to support dApps that have high resource requirements. We are the first to employ this concept. If at any point in time these apps end up with high transaction flow, we must be able to support these requirements. The parallel processing puzzle is accomplished through a couple steps.
First, by separating each sidechain into specific use cases, we will already minimize the risk of interdependent transactions. We then identify which transactions within a specific sidechain are dependent on others within that same sidechain. This is achieved by pulling the metadata from the smart contract code and maintaining a call graph for all the function calls on the chain. From here we identify the resources to be used by the transactions.
The next step is to create a cluster node which is made up of multiple computers working together. These are able to process transactions simultaneously without the risk of any dependent transactions being processed out of order. This also allows for very easy scaling of the nodes without requiring expensive equipment.
The clusters components are deployed in their own ‘pods’. Kubernetes is used to manage all the pods. This creates each component in a modular and decoupled fashion, allowing us in finding any component which causes a bottleneck or inefficiency within the system. We are then able to optimize the specific component improving the whole system. An example of this is the separation of the processing component and the database storage component in the nodes. We were able to optimize each component separately allowing us to improve our testnet baseline TPS speed up to 15,000.
Indexing is to facilitate the verification of the existence and execution order of transactions. The Block header will be sent to the main chain in which a main chain miner will unpack the information along with all other block headers sent in and build a block on the main chain. The sidechain will retrieve the main chain block header to be used for verification.
We are continuing to look and push deeper improvements onto our chain development.
Smart contract writing and metadata extraction. We need to develop a standard on how the smart contracts are to be developed, ensuring the the system can find and extract the correct information.
Optimizing Grouping time. Transaction execution is the core part of the blockchain, and as such we want as little time as possible to be spent on the grouping process.
Signature & Verification. This is often a very time consuming operation. We have also introduced a parallel processing component to the verification stage of transactions.
Make sure you follow our medium publication to hear about the next steps in our path towards mainnet launch.
Join the Community:
· aelf Twitter
· aelf Facebook
· aelf YouTube
· aelf Instagram
· aelf Reddit
· aelf Medium (for the latest update and articles)
· aelf Github (complete aelf project codes)
For more information, visit aelf.io