A breakdown of the aelf blockchain whitepaper — Part 1
Why cloud computing is a must
We have already mentioned that cloud computing is a key feature. For Bingo Game, the aelf team only deployed 2 simple smart contracts (compile a C# file into intermediate code and upload it onto the aelf blockchain by creating a transaction with a special contract). Anyone can compile C# contracts and deploy them on the blockchain so that other people can invoke the contract to do whatever they want, say, developing a DApp. If only a few people are using the aelf blockchain, then it does not really matter. However, for any enterprise-level scenarios, this blockchain architecture is a recipe for disaster, just think of the torrent of data flowing in a supply chain. Under such circumstances, the number of deployed contracts will be in the MILLIONS, and if they are invoked by a lot of people, the transactions and contract code executions can easily soar to BILLIONS! As mentioned, a full node or mining node (also “block producer”) executes contract opcode under the dotnet framework, if we give millions of contracts for this node to execute, it will take so long a time that no application can handle. Try to imagine if there are 2,500,000 contracts queuing up to be executed by a single computer before your contract is executed, it would be so frustrating! For a common blockchain, this is called “network congestion”.
It is therefore easy to see why a cloud computing solution comes in handy. Instead of using a run-of-the-mill computer as a full node, why not use a super-computer?
Why not run in parallel?In addition to cloud computing, nodes can also run smart contract code in parallel on the aelf blockchain. Before aelf, smart contracts on all blockchains are executed in a single-threaded way, like the event loop of the Javascript engine. But the aelf team, excelling at C#, found that the C# infrastructure can support parallel execution, so they applied this feature to the design of the aelf blockchain architecture. Combined with some designing patterns, the aelf team finally designed this mechanism, ushering in a new era of blockchain nodes with parallel execution.
For example, suppose there are 1,000 tasks to be executed (transactions or contracts), the aelf system will first check if these tasks change the same value simultaneously, if they do, then they will be executed in sequence because we don’t want these tasks to conflict with one another during parallel execution. If they don’t, then these non-conflicting tasks can be executed in parallel where they are divided into several groups according to whether they conflict with each other. So the result will be, say, 4 groups: [200 tasks, 300 tasks, 250 tasks, 250 tasks], and the overall execution speed will roughly be 4 times faster.
Just like Marvel superheroes assembled together to fight Thanos, aelf combined cloud computing and parallel processing to make sure any enterprise-level use cases have a seamless experience. Now let’s dive deeper into the technical stuff..
Delegated Proof of Stake (DPoS) and aelf Delegated Proof of Stake (AEDPoS)As mentioned in “What is a blockchain” in the last article, in a distributed system, it always takes time for a transaction or a block to be broadcast to every node when there is a large number of nodes involved. We know that in the Bitcoin system, only mining nodes are responsible for producing new blocks, so why not reduce the number of mining nodes as much as possible? As a result, the Delegate Proof of Stake(DPoS) consensus mechanism came along. Proof of Stake is a variety of consensus algorithms that use something (for example, the token amount) as stake to package new blocks, the higher the stake, the likelier this new block will be confirmed. In DPoS, there aren’t so many mining nodes (strictly speaking, there is no mining concept in PoS, rather, they are called validating nodes), because we simply delegate a very few validation nodes to produce blocks and broadcast them to other delegated nodes. Clearly, DPoS solved the problem of long broadcast time in the blockchain distributed system. However, since there are only a few validating nodes at play, how can we prevent these nodes from plotting with each other to manipulate the whole chain and undermine the decentralized principle? That’s why all types of DPoS have a strict voting mechanism to ensure these elected delegates act fairly and transparently.
In fact, DPoS stems from the EOS blockchain project. In DPoS’s design, there are at least three types of nodes: block producer (BP, or less strictly, mining node), candidate node and common node. The candidate node is a block producer (BP) candidate who applies for the role via a smart contract. Theoretically, any common node with sufficient computing power (in aelf, we recommend a computer with at least a 8-core CPU, 8GB of RAM and 500GB SSD) can be a candidate node. In practice, only a small fraction of them can be real BP through voting by other common nodes. On the financial side, a typical blockchain project which chose DPoS as its consensus mechanism always rewards nodes with some tokens if they vote for candidates, thus encouraging participation. The voting mechanism is essentially a smart contract with voting methods that request voting node’s address, who it votes for and how many tokens they want to stake (the higher the stake, the greater the vote weight). In aelf, we don’t know how many common nodes can become candidate nodes, but only the 17 candidate nodes with the most votes can become a BP.
With some special techniques, aelf has upgraded DPoS to the unique AEDPoS (aelf DPoS). The creators have drafted a specific suite of round-based block production mechanism. If you look this up in the whitepaper you’ll see lots of mathematical expressions, but don’t worry, the core concept behind it is quite simple and straightforward.
Before explaining, let me remind you of two things: First, the real random number generation method (we’ll talk about this in details in the next articles). This method can not only generate a random number, but also shuffle a collection (say, a list), which makes the process impossible to be predicted, manipulated and plotted. Second, the Byzantine General Problem. Let’s have a quick recap of this problem: formally proposed by Lamport et. al in 1982, the Byzantine General Problem imagines a three-generals scenario, as was mentioned in the last article, if anyone of the three is a traitor who wants to alter the message, it is impossible for the three of them (the whole system) to reach consensus. Based on this observation, Lamport deduced that in the case of 3n nodes (n is a countable number) in the system, if there are at least n nodes who are traitors, the whole system can never reach a consensus. So in many other articles, you can always see the following statement:
If there are f evil nodes, there should be at least 3f+1 nodes for the distributed system to be useful.
In aelf’s DPoS, if the aelf main/test net is launched, the default setting is 2N+1 BPs, in the first year N=8, and N increases by 1 every year. There are 17 BPs at the very beginning. If 13 (no more than 5 BPs corrupt the network) of them behave normally, all the BPs will finally reach a consensus. Under this condition, aelf defines a round in which every BP packages blocks sequentially, and after that, aelf randomly picks a BP to package blocks. After this round, we shuffle the BP list, and repeat this process. The key is that the block production sequence is random enough to prevent BPs from plotting with each other. Of course, there are other designs involved, but we don’t need to know them to understand how AEDPoS works.
Like common DPoS, the BP list is always changing based on their votes. A common node can vote for BPs and candidates at any time (the aelf blockchain now supports this feature), and the aelf system will check the ranking every month, those who are at the bottom will be replaced by candidate nodes with higher rankings.
Latest news: 
. 
. 
. 
. 
. 
. 
Shop
Topic: AELF BLOCKCHAIN ($ELF) | Aelf Will Launch Mainnet on 10th December (Read 34842 times)