Unsure if you are aware, but Korea has been determined as one of the top 10 Bitcoin friendly countries, where Forbes has further identified South Korea to be among the highest digital currency investing countries, and the third largest market in the world.
It would probably come without surprise that there are a number of public cryptocurrency related meetups in the country’s capital Seoul, with meetups focused on specific cryptocurrencies (Bitcoin, Ethereum, and NEM to name a few), and also general blockchain focused related meetups (i.e. Hyperledger, CoinEconomy, Hashed Lounge).
A couple of weeks ago, a member from our team attended a one-off cryptocurrency meetup — Blockchain 3.0; where at the meetup, the presenter went through the various generations of blockchain including generation 1.0 — cryptocurrency trading, i.e. Bitcoin; generation 2.0 — smart contracts, i.e. Ethereum; and currently at generation 3.0 — governance. The presenter then further went into detail about the Delegated Proof of Stake (DPoS) consensus algorithm being the future of cryptocurrencies and looking into this, articles have wrote that this technology is one of the most efficient, flexible and fastest consensus models.
In this article we wish to understand how DPoS differs from BOS Platform’s mFBA consensus backbone.
DPoS
Delegated Proof of Stake is different to the standard Proof of Stake (PoS), where members essentially stake a number of their tokens in order to operate a node to achieve consensus (i.e. generate the next block or ensure their ability to vote of proposals); however DPoS still has the staking component of PoS, but the rights of generating the next block and/or voting and are determined by the members of the public community.
This design was made to provide the power back to the community to ensure only members with higher reputation have the rights to affect consensus, adding trust and safety (see The Merkel and BitShares).
mFBA
BOS Platform’s modified Federated Byzantine Agreement (mFBA) consensus protocol combines the Stellar Consensus Protocol (SCP), Federated Byzantine Agreement (FBA), Proof of Stake and a Dynamic Quorum. Stellar’s FBA organises nodes into groups call quorums whereby overall consensus is met by:
- Quorum consensus among a certain amount of nodes (within a specific quorum); then
- Consensus among a certain number of quorums to finally determine the final consensus.
This design of consensus is supposed to ensure:
- Decentralized control;
- Low latency;
- Flexible trust;
- Asymptotic security.
From current tests conducted by the BOS team, the SCP FBA appears to only allow for static quorum configurations, whereby any changes to the network requires the network to be rebooted. BOS Platform’s mFBA will aim to allow for a dynamic quorum structure, allowing for nodes and/or quorums to be added and removed without impacting the availability of the network. The PoS will provide an extra level of security.
Tests are currently being conducted to understand the optimum configuration of the node-quorum structure.
So what?
Comparing the two consensus algorithms, they appear to have rather similar properties. As different blockchain projects design their particular consensus algorithms with different specifications, our comparison will be conducted at a qualitative level assessing the difference in concepts.
To assist with your understanding, please refer to the below table of definitions of consensus algorithm attributes to understand the scope of this comparison:
Decentralized Control: Participation
DPoS:
Anyone can apply to operate a node. All nodes will be used to store a copy of the blockchain, however in order for nodes to actually participate in consensus (operational), this includes creating the next block on the blockchain or participating in proposal voting, the node will need backing support from the community.
The number of nodes are limited within the network.
mFBA:
Anyone can apply to operate a node by fulfilling the conditions of freezing and having the required system requirements.
Theoretically mFBA has no limit to the number of nodes within the network, but due to performance optimisation we imagine there will be a limit within our BOS Platform eco-system (current TestNet will aim to determine the optimum number and structure).
Decentralised Control: Operational
DPoS:
The concept is that the community elects which nodes will be operational, however when performing the actual consensus appears to be at the node operators’ discretion — i.e the node operator will conduct the physical voting for proposals, and block generation is based on the system setup of the node.
mFBA:
Both block generation consensus and proposal consensus will be conducted by the node operator (based on system setup), however there will be an open forum for the wider community (i.e. all token holders) to participate in the discussions on all proposals.
Latency
DPoS:
DPoS adopts the PoS characteristic when conducting consensus. The number of nodes are probably limited by the network in order to ensure a quicker consensus. The lower the amount of nodes should generally create a much faster consensus.
mFBA:
mFBA will adopt the quorum characteristic of Stellar’s FBA to ensure a quicker consensus. mFBA in nature is suitable for a large amount of nodes to achieve lower latency.
Flexible Trust
DPoS:
The wider community has the freedom to back/support nodes/operators that best represents their interests. The top numbers of node/operator with the most backing will eventually operate the consensus component of the network/ecosystem.
mFBA:
Within each quorum, each node has the freedom to decide who to look to for consensus.
System Safety: Performance Incentive
DPoS:
As with flexible trust, the community elects which nodes will actually perform the consensus operations. This puts the onus on the nodes/operators to ensure they are well-behaved and maintain a good reputation, to create the trust within the community and gain backing/support from the community.
mFBA:
Stellar’s FBA has this feature embedded in their quorum configuration, by nodes identifying their quorum slices to gain consensus; the more trustworthy a node is, the more quorum slices they are a part of — hence to be included in a quorum slice, it is important to maintain a good reputation within the network/eco-system.
Ill-behaved nodes will be removed — which may be determined by a node not being part of any quorum slice other than their own.
System Safety: Personal Accountability (Nodes)
DPoS:
Yes, based on the PoS concept, nodes must initially stake an amount of tokens in order to be considered to be an operational node. Since the amount of nodes are limited, the higher the amount you stake, the higher the chance you will have to be an operational node.
mFBA:
Yes, based on the PoS concept, nodes must initially stake an amount of tokens (i.e. freeze BOS tokens) in order to be a node — nodes are penalised (frozen tokens confiscated into the Commons Budget) upon ill-behaviour. Within the BOS Platform, the amount needed to be a node is fixed.
Energy Consumption
DPoS:
Uses PoS concept, so energy usage is optimised.
mFBA:
Uses PoS concept, so energy usage is optimised, quorum consensus from FBA also allows for quicker and more efficient consensus
In conclusion, both DPoS and mFBA conceptually have many similarities. Both concepts allow for public input in proposal consensus; incentivises nodes/operators to maintain a good reputation; and have an added security level of each node to have a stake against it. However mFBA also includes a quorum configuration component, which aims to assist consensus latency, consensus safety, and operations.
