In our Spotlight Series 3 we give a thorough analysis of our unique hybrid consensus mechanism.
To view article in PDF:
Background and History
In the blockchain industry, the value of a project is weighted heavily on the consensus mechanism that its blockchain employs. Bitcoin, the very first blockchain, introduced the revolutionary tool for securing data and transactions known as the Proof of Work (PoW) consensus mechanism. In PoW, a miner who finds a valid hash first is allowed to add a new block of transactions to the blockchain. This mining process is extremely labor intensive. In a Proof of Stake (PoS) consensus mechanism, which is based on the participants’ ownership of the blockchain’s native token, the more coins a staker has, the more likely the staker will add a new block of transactions to the blockchain. This mining process is less energy-intensive and this type of system is suited for platforms with static coin supply. In a Delegated Proof of Stake (DPoS) consensus mechanism, which is a variation of PoS, coin holders can use their balances to elect a list of nodes to be possibly allowed to add new blocks of transactions to the blockchain. Coin holders can also vote on changing the network parameter. While PoS can be likened to winning a lottery, DPoS gives all coin holders more influence and ownership in the network. Proof of Work (PoW) can be likened to a true democracy, Proof of Stake (PoS) to an oligarchy, and Delegated Proof of Stake (DPoS) to a democratic republic. There are also other obscure but interesting consensus mechanisms that are still being experimented with such as Practical Byzantine Fault Tolerance (PBFT), Directed Acyclic Graph (DAG), and Ethereum’s new hybrid PoW/PoS system called Casper Friendly Finality Gadget (FFG).
While there are many consensus mechanisms that various blockchain projects are implementing and experimenting with, each mechanism has its own advantages and disadvantages. There is no such thing as “one consensus fits all” because there are many different problems facing various projects and industries, and while one solution might work for some, it may not work for others. Elastos employs a hybrid consensus mechanism of AuxPoW+DPoS for its main blockchain where each block is packaged by miners and then signed by DPoS supernodes, thereby creating a finality to blocks which prevents the blockchain from forking. Beneath the simplicity of Elastos’ hybrid consensus mechanism lies a highly sophisticated multi-stakeholder solution which provides maximum security and optimal network decentralization.
The miners who package blocks are actually bitcoin miners who merge-mine both BTC and ELA simultaneously. This means that Elastos is able to borrow massive hashpower from the Bitcoin network to secure its own. It is also noteworthy that the supernodes on Elastos are not like supernodes from other blockchain projects. On most blockchain platforms that employ DPoS consensus, the supernodes both package blocks and sign them. On Elastos however, the job of a supernode is to sign and verify the blocks. Consequently, DPoS supernodes can collectively choose to reject malicious blocks packaged by merged-miners and also provide the final stamp of validation for solved blocks – called “finality.”
On Elastos, there is an annual inflation of roughly 1,320,000 ELA that are added to the total supply. From these, 35% – roughly 462,000 ELA – are distributed to the PoW miners, another 35% – roughly 462,000 ELA – are distributed to the DPoS supernodes, and the remaining 30% – roughly 396,000 ELA – are distributed to the Cyber Republic fund, which is managed by the Cyber Republic Consensus (CRC) to fund various ecosystem projects. Elastos’ block time is 2 minutes and rewards are distributed after each round. Each round contains 36 blocks over the course of roughly 72 minutes. So then, the rewards for DPoS will be distributed at approximate 72-minute intervals.
Elastos and Finality of Blocks
The main issue with PoW consensus – apart from being computationally intensive – is that there is a high probability of a fork when the miner community is divided. For example, Bitcoin forked into Bitcoin and Bitcoin Cash. More recently, Bitcoin Cash forked further into Bitcoin ABC and Bitcoin SV. This happens whenever the community is divided and cannot reach a consensus on what features and upgrades to implement or eliminate on the blockchain. When there is enough support on both sides, the miners split up, causing the blockchain to split into multiple blockchains. In order to prevent such a catastrophic event, Elastos employs a hybrid consensus mechanism where the miner community must always follow the voice of the majority of the community members, as decided by democratic vote. The miners who do not follow these rules are deemed invalid, in which case the DPoS supernodes will not sign these particular blocks. By splitting up the power of packaging blocks and signing blocks into two different processes, Elastos creates an ingenious method to ensure finality in each block. In doing so, Elastos prevents any sort of fork occuring in its blockchain. Of course, no consensus mechanism is perfectly secure, but the hybrid consensus mechanism employed by Elastos certainly adds an additional layer of security, further strengthening the network.
In addition, there are 12 CRC (Cyber Republic Consensus) supernodes that are active at all times and are always included in the 36 active supernodes that take part in the consensus mechanism. Thus, only 24 of the 36 active supernodes are elected by the community at any one time. Because the DPoS consensus for the Elastos blockchain requires ? of the active nodes’ signatures, a block must be signed by at least 25 supernodes. This creates yet another layer of security for the hybrid consensus that Elastos employs. Not only do the PoW nodes have to be compromised, but the DPoS supernodes as well. As it is already astronomically costly and difficult to amass over 50% of the Bitcoin hashpower, it will be just as hard to amass over 50% of the Elastos hashpower. Furthermore, adding the DPoS layer to the mix means that even if the PoW nodes are somehow compromised, it will be the DPoS supernodes who have the final say in which blocks to sign and which to ignore. Thus, the DPoS supernodes can collectively ignore the malicious blocks that were sent to the blockchain P2P network. Also, if we hypothetically assume the worst – that all merged-miners and all of the 24 supernodes are compromised – the best a malicious actor can do is halt the production and signage of blocks. In this circumstance, the malicious entity will be limited because it will not be able to acquire the necessary 25 signatures to validate faulty blocks. The 12 CRC supernodes, which are controlled by private keys held by the 12 Cyber Republic council members, will always act honestly and will never accept any malicious blocks, as it is in their best interest to do so. After all, each council member must deposit 5,000 ELA to be considered for the Cyber Republic election and each can be voted out by the community at any time if he or she does not act in the best interest of the collective community voice.
The worst case scenario is that blocks will not be added to the blockchain because blocks cannot earn 25 signatures and the blockchain comes to a halt. If such an event were to occur and continue for an hour without any blocks being added to the blockchain, the 12 non-working arbitrators would be voted out and replaced by the next batch of 12 elected supernodes that take part in the DPoS consensus, thereby resolving the issue and ensuring that there are 36 active supernodes at all times.
The DPoS consensus for the Elastos blockchain works differently than a typical DPoS consensus mechanism, with the community playing a major role in the consensus process. The PoW mining is conducted via merged-mining, a process which utilizes Bitcoin mining machines to package transactions into a block. Then, the supernodes take action by signing each block. The community can submit different proposals to Cyber Republic and may include changes to the present consensus mechanism for new sidechains or propose the creation of a new sidechain dedicated to a specific application. The proposal may also include an architectural change to be implemented on the main chain code. Should the proposal be accepted by the Cyber Republic Council, the supernodes upgrade to account for said change. Soon after, if any of the PoW miners fail to upgrade their clients accordingly, the blocks packaged by the miners will not be accepted by the supernodes. In this way, the majority of the power is given to the Cyber Republic community rather than the miners themselves, which prevents forks from occuring in the first place.
How does each block get added to the blockchain?
- Bitcoin miners use special machines to mine Bitcoin. They also mine ELA through auxiliary mining techniques via a process called merged-mining. Each block is protected by PoW consensus and each block is then broadcasted to the P2P network.
- Arbitrator nodes receive each PoW mined block. If the arbitrator is on duty (only one of the 36 arbitrators is on duty), it sends a proposal for each block to the rest of the 35 arbitrators, where each signs the block using its private keys. The arbitrator network is another P2P network that connects all 36 arbitrators. Each arbitrator checks transactions and then signs each block. Every block that is signed by each arbitrator is also broadcast to all arbitrators in the arbitrator network in order for it to be verified and confirmed.
- Each arbitrator also broadcasts each signed block to all the nodes in the PoW miner P2P network. When the PoW miner node sees that the block has ? signatures from arbitrators, it puts the signed blocks into the blockchain and starts packaging the next set of transactions into a new block. The reason that each arbitrator broadcasts its signed block to the PoW P2P network is because it is more efficient and prevents some issues that might occur if only the on-duty arbitrator were to broadcast the block.
Some issues and how Elastos addresses them
We know that each arbitrator broadcasts its signed block to the PoW P2P network. Let us look at an example where this is not only efficient, but also more resilient. Let us assume that an arbitrator signs two different blocks at the same height and the same view number, and both blocks are broadcast to the blockchain P2P network. This scenario would produce a fork because arbitrators should not be signing two different blocks at the same height and the same view number. This may be done with malicious intent in the hopes of producing a fork of the blockchain and all its sidechains. If one does this, evidence can be detected by every node in the network and the guilty arbitrator would be punished to the tune of 5,000 ELA, as this is a very serious issue. Also, the temporary fork that is created would be corrected by the new arbitrators.
First of all, this malicious arbitrator would immediately lose access to its 5,000 ELA that it deposited to be part of one of the supernodes. When the 5,000 ELA for the supernode is deposited initially, it is transferred to a special address. The private key for this special address is held by the owner of the arbitrator, but there are rules that need to be followed to retrieve this 5,000 ELA from said special address. Even if the arbitrator has the private key corresponding to the special address, if it is deemed malicious, the 5,000 ELA can not be retrieved. This can be likened to the burning of 5,000 ELA because no one will be able to retrieve these funds since they can no longer be accessed. If the arbitrator did not do anything bad and tries to opt out of the supernode election, it will be returned the 5,000 ELA. Every normal PoW miner is able to verify which arbitrator is malicious by looking at each block proposal on the blockchain. In turn, this mechanism provides more incentive for supernodes to act honestly.
There may also be a case when the on-duty arbitrator tries to selectively favor a block produced by a specific miner for nefarious purposes; it may even attempt to package its own block. How can such behavior be prevented? Let’s say there are two arbitrators – A1 and A2 – and 2 blocks – B1 and B2. Let’s assume that the time it took for B1 to be received by the on-duty arbitrator is t1, and for B2, it is t2. Let’s also assume that B1 took slightly longer, so t1 > t2. FInally, let us say that the interval between these two times is more than 5 seconds. If the on-duty arbitrator (A1) tries to send a proposal for B1 first (even if it should really send in B2 first because it came in first), other arbitrators will know that this is illegal, so they will reject B1 proposal from A1 and the network will change the view from A1 to A2. Now, A2 is converted to on-duty arbitrator, so it takes part in sending the block proposal for both B2 and B1 in sequence. As follows, the view changes once again and a new on-duty arbitrator is selected (A3) and the consensus resumes as normal again.
We briefly mentioned there are 12 CRC supernodes at all times and that they always act honestly. We work under the assumption that any or all of the other 24 may be malicious. As an example, when ELA is transferred from the main chain to a sidechain, it is locked on the main chain address while it is unlocked on the sidechain address. Because a sidechain does not necessarily have the same consensus as the main chain, it is important to prevent users from withdrawing ELA via the sidechain. It is for this reason that we absolutely need the consensus of the sidechain to be as secure as possible. If we know that 12 CRC arbitrators are always acting honestly, even if all 24 of the elected supernodes are malicious and try to collude with each other, it does not satisfy the requirement to initiate the transaction (recall that more than ? signatures are required). It is very difficult to collude with all 24 supernodes and also the CRC supernodes because the private keys of each of the 12 supernodes are controlled by 12 different council members.
Last but not least, there is one final issue that might arise. Each round lasts 72 minutes, as that is the time period for which an arbitrator is elected to serve as an active supernode. After 72 minutes, the vote is recounted and the new set of supernodes may join the active pool if they get enough votes to replace the active supernodes. Let’s assume one arbitrator is inactive and thus does not submit a block proposal for 2 consecutive days (roughly 40 rounds, 1,440 blocks, or 48 hours). In such a scenario, this arbitrator will be unable to participate in supernode consensus for 7 days, which also means it will not receive any rewards – independent of how many votes it receives. Thus, the inactive arbitrator will be prevented from performing any work for 7 days. This arbitrator can be identified because every block has a block proposal mapped to it that contains information on who is supposed to be creating that particular proposal. In such a case where a particular arbitrator does not send a proposal for a block, this task is passed on to the next arbitrator in line, who then sends a proposal for that block, and so on.
The timeout penalty threshold for sending a proposal is 5 seconds. Each proposal contains a block hash and the signature. When the original arbitrator does not send a proposal for 40 consecutive rounds, the first punishment is 7 days of being disabled and a potential 10% penalty off of the 5,000 ELA from its stake. If after 7 days, the same arbitrator does not send a proposal for 40 consecutive rounds yet again, the same punishment applies which is another 7 days of being disabled and a 10% penalty of its remaining 4,500 ELA. Note that the exact number is subject to change in the future. If an arbitrator continues to be absent and its total remaining ELA falls below 4,000, it cannot participate in supernode consensus until it deposits another 1,000 ELA, so as to reach the 5,000 ELA threshold again. Note that the inactive arbitrator that was banned for 7 days needs to wait at least 720 blocks (roughly 24 additional hours) after its ban is lifted and then it should send a special transaction to the blockchain that notifies the network that it is active and ready to take part in consensus again. The votes that this supernode accumulates over the ban period still remain when it decides to become active again.
One last thing to mention regarding an inactive arbitrator is that there may come a time when the DPoS consensus doesn’t receive at least 25 signatures (? vote). This happens when only 24 supernodes sign a particular block. In such a scenario, if neither of the remaining 12 supernodes sign that particular block for more than an hour, they have 100 ELA taken away as penalty for not signing a block for up to an hour. And these nodes will become inactive directly afterward. Note that the inactive arbitrator needs to wait at least 720 blocks (roughly 24 hours) after its inactive and then it should send a special transaction to the blockchain that notifies the network that it is active and ready to take part in consensus again. The votes that this supernode accumulates over this period still remain when it decides to become active again.
It is yet to be decided how to handle the ELAs that are supposedly inaccessible to arbitrators for their malicious activity. There are two options at present that could be pursued but have not yet been decided and are subject to change in the future:
- Burn the ELAs that are inaccessible due to punishment
- Send the ELAs that are inaccessible due to punishment to the Cyber Republic fund
Sidechains of Elastos
If you would like to read about sidechains in more detail, refer to our Spotlight Series 2: Elastos Sidechains and Scalability.
The DID sidechain, Token sidechain and NeoVM sidechain have PoW consensus because they are all based on the Elastos main chain code and consensus. The Ethereum sidechain, on the other hand, uses DPoS consensus – which can be considered Proof of Authority (PoA). Every arbitrator has a relation to two addresses on the Ethereum sidechain and it works the same for any other sidechain as well. For example, if there is an ELA main chain address but that same main chain address also has a corresponding Ether address, these two addresses are related by a transaction on the main chain so the SPV module can recognize the relation and identify the arbitrator. This is how the network knows who has the right to generate blocks of the Ethereum sidechain. A user can transfer ELA from the main chain to the Ethereum sidechain and use the ELA on the Ethereum sidechain for running smart contracts. There is a lower bound of 10,000 SELA for running smart contracts on the Ethereum sidechain, but this number is subject to change in the future if the need arises. Also, the block size of the Ethereum sidechain is the same as the Ethereum public blockchain. As a result, the sidechain has a gas limit rather than a fixed block size. Because the Ethereum sidechain is also DPoS, it can support much higher TPS (Transactions Per Second) than the public Ethereum blockchain.
As mentioned in the Spotlight Series 2: Elastos Sidechains and Scalability, there can be multiple sidechains of the same kind. This goes not only for the Ethereum sidechain but also for the Token sidechain and NEO sidechain. For instance, a user could have one DApp that is utilizing the Token sidechain 1 and another that is utilizing Token sidechain 2. This is theoretically possible on the Elastos architecture. One thing to note is that all three sidechains of Elastos – Token sidechain, Ethereum sidechain and NEO sidechain – are able to issue both fungible and non-fungible tokens to DApps running in the Elastos ecosystem. The only difference is that the Token sidechain does not support smart contracts, while the Ethereum and NEO sidechains do.
Also of note is that there is likely not going to be a scenario where there will be 2 DID sidechains running on Elastos because this offers no benefit concerning what the DID sidechain was designed to do. DID sidechain only records the transactions and KYC info of users. The transactions will not be changed frequently and the sidechain will be used mostly as a read-only sidechain for verification purposes. As such, the consensus for this sidechain need not be super fast either. Because of this, the PoW consensus was chosen for the DID sidechain and is therefore merged-mined with Elastos. However, this is also subject to change. If the need arises, the consensus can be easily changed from PoW to DPoS consensus in the future.
How do arbitrators work?
1. Every arbitrator must run several nodes: one node for the ELA main chain, one for DID sidechain, one for Token sidechain, one for NEO sidechain, one for Ethereum sidechain, and so on. In doing so, the arbitrator configures itself to connect to the various nodes and thus enables itself to generate blocks for each sidechain. This does not mean that all of the sidechain nodes necessarily have to be running in one machine. Each sidechain node and even main chain nodes can run on different machines while the arbitrator process connects to these various nodes running on different machines through proper configuration. Even the actual data can be stored on different machines. By way of this mechanism, cloud services like AWS, Azure, and Google Cloud, may very well be utilized to run each sidechain node on separate machines while also using cloud storage solutions for actual blockchain data storage so as to reduce the burden of running all processes on one machine.
2. Only the on-duty arbitrator packages and signs the blocks for each sidechain. This goes for all the sidechain blocks (both PoW and DPoS sidechains). In case of a PoW sidechain, the on-duty arbitrator packages and signs blocks and sends them to the main chain for merged-mining PoW. Once confirmed, the blocks are added to their respective sidechain. In case of a DPoS sidechain, the on-duty arbitrator packages each block and sends a block proposal to be signed by all the other arbitrators. As soon the block gets ? votes(25 signatures), the DPoS sidechain block is confirmed and added to the blockchain. Every other arbitrator can verify whether the blocks packaged and signed by the on-duty arbitrator are valid. If invalid or malicious blocks are signed, that supernode will receive a punishment and will have some or all of its ELA taken and may be voted out of the supernode consensus completely, depending on the severity of the circumstance.
3. If there are 3 arbitrators, they must be connected to each other. At any given moment, there are always two connections from each arbitrator. Therefore, if there are 36 arbitrators, there are always 35 connections from each arbitrator. On the arbitrator network, everyone is connected to each other because there are only 36 nodes – meaning the overhead is not significant. In the PoW network however, not every node is connected to every other node, as it is infeasible to do so given the thousands to hundreds of thousands of nodes in the network.
4. How do normal nodes know which arbitrator is on-duty? There is a sequence of on-duty arbitrators that advances every 72 minutes. This is determined by the public keys of each arbitrator. Every proposal is proposed by a different on-duty arbitrator because arbitrators rotate after each block. Each round consists of 36 blocks, each of which lasts roughly 72 minutes. Therefore, the arbitrator that will be on-duty is determined beforehand. An election occurs every 72 minutes and determines the order of the on-duty arbitrators. There is a list of arbitrators and their respective votes that is cached in every PoW node which is accessible to anyone. From this resource, it is quite easy to check which arbitrator is going to be on-duty at any point in time.
5. Every arbitrator can vote or withdraw its vote at anytime. At the beginning of the nth round, the votes will be collected for n+1, n+2 round so the sequence of on-duty arbitrators is known by nodes beforehand.
This series may have taken a deep technical dive, but if there is one easily digestible takeaway from all of this, it is that the hybrid consensus mechanism that Elastos employs is very unique in its own right because it adds multiple layers of security. With its hybrid consensus algorithm, Elastos establishes a resilient network without sacrificing scalability potential in the process. Most importantly, it remains totally decentralized and autonomous. It is very difficult to balance the trilemma of the blockchain industry: security, scalability, and decentralization. Elastos effectively balances all three with a unique approach unseen anywhere else in the crypto-space. While perfection continues to be an unreachable target, Elastos is set on developing a system that is backed by the most powerful and secure consensus mechanism it can create.