What would you like to search for?

Notices|24 MIN. READ

Elastos DPoS Consensus Mechanism, Supernodes, and Election


Elastos Chief Architect, Yipeng Su discusses the Elastos consensus mechanism.

The Elastos consensus mechanism is AUXPoW+DPoS. Merged mining is essentially the same as PoW, only it utilizes the hash rate of Bitcoin. One reason that we have added the DPoS agreement is to further strengthen the reliability of the consensus, as well as the fact that the allocations of rights should embody the will of the community.

Merged mining uses the hash rate to protect the reliability of the ledger. The question then becomes, why would we also add DPoS? One reason is to solve the problem of forking. Everyone knows that DPoS exists underneath PoW, so the problem of forking is rather difficult to solve; what is more important is direction of development being controlled by a more and more centralized hash rate.

For example, imagine that a technology upgrade protocol was set and that the upgrade protocol would be beneficial to the entire community, but miners believed that it would be detrimental to them, causing them to refuse this upgrade. This situation causes what is known as a soft fork. This chain would then run using the obsolete protocol. Once the DPoS mechanism is added, if miners do not upgrade, the blocks they produce cannot be qualified by the DPoS supernode. As long as the DPoS supernode acknowledges this upgrade, even if most miners do not acknowledge this upgrade, it is still effective.  In this situation, DPoS supernodes arise from community voting and elections, during which rights are reallocated between hash rate miners and DPoS supernodes, and blockchain rights are jointly held by both the hash rate and capital, rather than just the hash rate.

 The Elastos AUXPoW+DPoS mechanism also has some other differences, especially DPoS. In broad terms, our DPoS actually has two sets of DPoS mechanisms. The first set of mechanisms is the DPoS supernode election that was recently released, in which supernodes are arranged by computers. The supernodes are responsible for the safety of the ledger. There is also another type of supernode, or in other words, DPoS mechanism, which is the CRC that we talked about at the anniversary in August.

 In this type of consensus mechanism, each committee member elected in the CR election can be regarded as a supernode, and ELA-holding community members can be regarded as regular nodeseveryone has the right to vote in community affairs. The reason to establish the CRC is that DPoS manages the blockchain algorithm, transaction reliability, immutability, and safety, but CRC was designed to utilize the open transparency and immutability of the blockchain; secondly, in order to allow all community members to participate in community affairs and governance, we will decide the future direction of the community together.

 Here is an example which also shows us something about the soft fork which I just mentioned. We can actually solve the problem of a soft fork through the AUX+PoW mechanism. At the same time, let’s also talk a little bit about the historically famous example of a permanent forking, such as BTC and BCH, ETC and ETH, as well as the recent forking between BCH and SV. First of all, let’s talk about the reason that the permanent forking occurred. We can see that it was more so caused by differences of opinion with regards to technological concepts. For example, the split between BTC and BCH was caused by a difference of opinion with regards to the expansion plan, which in the end would only result in a permanent forking. The reason for this is essentially that neither the BTC community, Ethereum community, nor the BCH communityconsensus mechanisms exist, and there are no channels through which coin-holders can participate in the community. At the time when BTC experienced a forking something called the Hong Kong Consensus existed, but it wasn’t actually a consensus. It was a just a discussion between the main personnel of the factions. Normal BTC participants didn’t have any opportunities or effective channels through which to participate.

Now suppose that the BTC community had such a consensus mechanism which allowed everyone to participate in it. They could decide in the future whether they should use the 8-megabyte expansion plan or the SegWit expansion protocol. If the main personnel from both sides were able to see the will of the community and whether the majority preferred a certain protocol, then it would have reduced the possibility of a hard forking, because if they would have been able to clearly see that most people weren’t in support of their actions, then the effect that the forking would have would have been predictable. That is the first thing.  Secondly, since the community consensus had already been formed, but it still didnt abide by that consensus, it essentially betrayed the community. Certainly, once these community consensus mechanisms are in place, it not only solves the problem of the hard forking, it can also solve problems related to the direction in which the future blockchain project will develop. This is the most fundamental reason for establishing the community consensus.

 About node allocation. Previously, a draft was published explaining that overall, there will be 36+72, for a total of 108 effective nodes. Of those, 36 will be elected nodes and 76 will be candidate nodes, which is to say that the actual work is done by 36 of them: 36 of them vote to confirm the current block and 72 of the candidate nodes are supplemented in when the others cannot perform work or when they have been eliminated, and are replaced according to the dynamic number of votes. Something I want to add is that 12 out of the 36 elected nodes will be retained from the previous group. The community will actually vote to elect 24 nodes instead of 36 and among those, 12 of them automatically become elected nodes. The reasons these 12 nodes are retained is for CRC. One aspect is in consideration of safety and to prevent capital from controlling all of the nodes. Another aspect is in consideration of the rights of the CRC committee members, as all benefits from the 12 nodes become the property of CRC members.

DPoS Election Draft Explained

Node Election Rules:

There are three types of nodes: participant nodes, elected nodes (supernodes), and candidate nodes.

Participant nodes: All nodes that have successfully submitted the election participation transaction and who have pledged ELA according to the rules will be seen as participant nodes. Community members are welcome to establish nodes together.

Elected nodes: The top 24 participant nodes will be ranked from highest to lowest according to the number of votes obtained by each, plus the existing 12 elected nodes, for a total of 36 rotating supernodes.

Candidate nodes: Nodes ranked numbers 25 to 96 according to the votes obtained will be the candidate nodes.

 Election Requirements:

Participant nodes must make a deposit of 5,000 ELA (this quantity of ELA may not be used for voting), which will be used to penalize nodes who violate the rules.

 Election Process:

Nodes must register for the election in the Elastos Wallet (by issuing the election participation transaction) and provide information required for participation in the election (node name, public key, location, node website, etc); once the 5,000 ELA deposit is confirmed and the election participation transaction has been successfully issued, the node will become a DPoS supernode election participant.

 After participating in the election, the entire community of ELA-holders will vote amongst the participant nodes and the system will automatically rank the nodes according to the number of votes obtained.

 If a node wishes to withdraw from the DPoS supernode election after confirming their participation, a cancelation transaction must be issued, after which the node will no longer be allowed to participate in the election. If no actions have been taken which are in violation of the rules, the ELA on deposit will be returned to the address corresponding with the public key that was used at the time of registration within 72 hours of issuing the cancellation transaction.

When the election participation transaction and the cancelation transaction are issued, no fees besides the normal transaction fees will be incurred.

With regards to election hardware allocation requirements, technical personnel are assessing the entire network situation and the requirements of the code on resources while also giving consideration to comprehensive aspects, such as security and the network. Basic advice for hardware allocation will be raised in December.

Node Profits:

 DPoS votes will be recounted every 72 minutes, where 24 elected nodes and 72 candidate nodes will be selected, and 12 elected nodes will be retained. The profits are as follows:

 (1) The annual 35% increase in ELA is the total annual profit allocation for DPoS;

(2) 25% of the total profit allocation for DPoS will be distributed to the 36 elected nodes based on averages;

(3) 75% of the total profit allocation for DPoS will be distributed to the 108 nodes (elected nodes and candidate nodes), and profits will be distributed according to the ratio of votes obtained by each node.

 Voting Rules:

1. Circulating ELA has the right to vote in DPoS node elections. The Cyber Republic fund account that are frozen or who have not issued the transaction cannot vote, nor can ELA in foundation accounts for the same reason

2. Fees for voting in a DPoS node election are the same as those of normal transactions;

3. There is no reward for voting in DPoS node elections.

4. Rules for Voting Rights:

(1) 1 ELA can be used to vote for a maximum of 50 different nodes and a single node can only use 1 ELA to cast one vote;

(2) After exercising the right to vote, the corresponding ELA can no longer be used in circulation. This means that after voting, transferring the ELA will cause the vote you cast to naturally be retracted indefinitely.

(3) At the same time, ELA used for casting votes in the DPoS supernode election can be used for matters like community self-governance elections.


Questions from Community Members

Is the website necessary?

The purpose of the website is to provide a communication channel for the node to communicate externally. The website is made by the node, but this rule is not necessarily enforced.

 Wouldn’t a deposit of 5,000 ELA be too small?

When we discussed the question of how much ELA needs to be deposited, we discussed all different kinds of situations. Ultimately we hoped that more community members would be able to participate and if the deposit was set at too high of an amount, then this could pose too great of a hurtle for community members. Additionally the act of depositing ELA is not seen as votes cast for that particular node. If too much ELA needed to be put on deposit, then the number of votes that could be cast wouldn’t be as ample. After comprehensive consideration, the current deposit is 5,000 ELA.

 What permissions are given to elected nodes, candidate nodes and supernodes?

It is more accurate to refer to them as “rights.” The common success of elected nodes is to become a supernode. There are a total of 36 elected nodes: in addition to the 12 nodes which are retained, the other 24 are chosen through voting. These nodes are responsible for confirming the block ledger which is produced every two minutes. The 36 nodes take turns recording the ledger.

 Candidate nodes do not have the right to record the ledger. They serve as reserves at the ready at any time. They enjoy profit allocation from the DPoS mechanism, where 75% of 35% of the annual 4% increase is allocated to the 108 nodes (96 nodes after removing the 12 elected nodes).

 If there is no benefit to voters for voting, how can they be mobilized to actively vote?

 About profits for voters, we are considering whether to directly allocate a portion as an average profit for voting, but for now, it is most appropriate for participant nodes to allocate their profits to voters, which is also the simplest way for voters to be rewarded. In the future, if the majority of people think that the method of profit allocation should be updated, then it can be decided by voting in the CRC mechanism.

 Where does the profit for the 12 retained nodes come from and what is the ratio?

 The 12 retained nodes are supernodes that provide servers and run DPoS node code, which requires resources. This portion of nodes profits directly according to the average allocation to the 36 nodes of 25% of the total DPoS profit allocation.

 If the nodes are allocated dynamically, how does the annual profit actually reach the node after it has been sent?

 At the time when nodes issue the election participation transaction, they provide the nodes individual name, public key, and web address or other publicity channel. The public key will correspond to their ELA wallet address. Exactly how the profits are allocated and when will take place according to the software development details. When the election participation transaction is issued, nodes will also submit their public key (which corresponds to their walled address). When allocating profits, the allocation will automatically be sent to the corresponding wallet address.

 Do the tokens for participating in elections come with other rights?

 In the draft protocol, there are currently no limits for voting with ELA in the Elastos ecosystem. ELA used for voting in the DPoS supernode election can also be used for things such as airdrops and community self-governance elections.

 One thing that needs to be said is that whether requirements and voting in different application scenarios will require locking might have different rules and the rules for the that scenario will be the rule.

 Each year, the profits of mining circulate into the market. Won’t this cause fluctuations?

 The 4% mined each year is 4% of 33,000,000, which equals approximately 1,320,000. 35% of that is given to the elected nodes as a reward, which is 462,000, and is then distributed to the 108 nodes according to the number of votes. In addition to the 12 retained elected nodes, 96 nodes are voted into being by the community and the corresponding scope of distribution is rather broad. Votes are taken at the polls every 72 minutes, reducing affects to the entire market to as low as possible.

 You can refer to BTC’s previous mining growth situation and compare it to Elastos. In addition, a standpoint I would like to discuss is this: we make the cake, we don’t cut the cake.  We should be thinking about how to make the cake bigger, rather than how to get a bigger piece of it.

 On what date do you expect the election to take place next year?

The current plan is to hold the DPoS supernodes election in the first quarter of 2019 and to hold the CRC election in the third quarter of 2019.

 POW provides the basis for the stable blockchain consensus and DPoS is more of the power behind the assets. How do these two forces provide a more balanced service for Elastos?

 PoW and DPoS balance each other. PoW is the hash rate and DPoS is the assets. They have the right to balance each other. I have already given an example about soft forks. When these two exist at the same time, they cannot independently decide the direction of a blockchain and rather they must decide together. Currently we can’t see anywhere when they are not balanced.

 If nodes provide centralized service, could they be the target of centralized attacks? How could that be solved?

 That is possible. So, the node should distribute itself as much as possible in its location. Secondly, it should distribute itself on top of the Elastos Carrier. For example, imagine these 12 nodes. First of all, location distribution is easy to solve. All you need to do is purchase cloud computing service in some different locations. This way, Carrier can rent nodes that use different Carriers, rather than operating on one single Carrier.

 Because 1 ELA can get 50 votes, won’t it be easy for big users holding a lot of ELA to just reserve the remaining 24 supernodes?

 First, let’s talk a little bit about why we have made 1 ELA equal to 50 votes. Currently, 12 nodes are retained so the corresponding number of votes will go down. This is what is referred to as “approval voting.” From the perspective of community operations, when the rules were created, we first wanted to ensure that they were effective and secondly that they were simple.  If you search for approval voting, you will find that its main idea is to prevent major shareholders (or big users) to monopolize all of the positions on the board of directors through direct voting, so the approval voting system gives medium and small users a way to band together so that they have the opportunity to select the representative of their benefits.

 With regards to the possibility that big users will “reserve all the spots,” if we look at it from a different perspective, Elastos has not yet produced a commercial DApp in the true sense of the idea. In this situation, wouldn’t it be a good thing if ELA-holders are not willing to sell because they believe in the future development of Elastos, are willing to set up servers and nodes themselves in order to participate in the supernode election, uphold the stability and strength of the Elastos network with the community, remain loyal during project development and ecosystem emergence until the market heats up again, and support the stable development of the Elastos SDK, Runtime, Carrier and blockchain?

Disclaimer: “All elected Supernodes are expected to abide by the rules and standards outlined in the Elastos DPoS Supernode Election Process. As Elastos is a decentralized and distributed network system, and DPoS Supernodes are selected through an election via the network’s official wallet, the Elastos Wallet, the Elastos Foundation is not responsible for the actions taken or views expressed by any elected Supernodes (operators or owners), nor is it responsible for setting up nodes, arranging mining pools, guaranteeing uninterrupted services, or compensating party losses that may arise throughout the staking process.”


Next Posts

Weekly Updates|2 MIN. READ

Elastos Weekly Updates – 14 December 2018

Weekly Updates|9 MIN. READ

Elastos Weekly Updates – 07 December 2018

Tech Announcements|44 MIN. READ

Elastos DMA Completes First Milestone

00:00 / 0:00:00