Delegated Proof of Stake Consensus

Delegated Proof-of-Stake (DPoS) consensus is a fast, efficient, decentralized, and highly flexible blockchain design. The BitShares blockchain leverages the power of stakeholder approval voting, to resolve consensus issues in a manner which is democratic and fair. All network parameters, from fee schedules to block intervals and transaction sizes, can be tuned via elected delegates (Committee). Deterministic selection of block producers (Witnesses) allows transactions to be confirmed in an average of just 1 second. Perhaps most importantly, the consensus protocol is designed to protect all participants in a free and fair, transparent environment.

BitShares is first and foremost a globally distributed database that is used as a ledger to track ownership of digital assets. To allow the database to remain consistent and universally agreed upon, all updates must be validated and applied in the proper order. Reaching a consensus over every ledger update is the purpose of Delegated Proof-of-Stake (DPoS).

The questions that must be answered by any consensus process include, but are not limited to:

1. Who will produce the next block of updates to apply to the database?
2. When will the next block be produced?
3. What transactions should be included in the next block?
4. How are changes to the blockchain protocol applied?
5. How should competing transaction histories be resolved?

By answering these questions, the goal of the BitShares blockchain is to ensure the consensus process is robust against attackers gaining control over the Delegated Proof-of-Stake network. In practice, control means acquiring the ability to unilaterally censor transactions (and corrupt or centralize the consensus protocol). The process must be autonomous against any inconsistency attack to the database state on different computers.

The term witness was chosen because it is a literal metaphor and noun which describes the autonomous function of the ‘Witness Node’ servers, and those elected to operate them. Witness also happens to be a legally neutral word, free from trademark or brand copyrights. Traditional contracts often have a place for witnesses to sign. For extremely important contracts, a public notary is sometimes used. Neither are party to the contract, but they serve a very important role of certifying that the contract was signed by the specified individuals at the specified time. In BitShares, witnesses serve a similar role of validating signatures and timestamping transactions by including them in blocks.

Under Delegated Proof-of-Stake (DPoS), the stakeholders can elect any number of witnesses to generate blocks. A block is a group of transactions which update the state of the database. Each account is allowed one vote per share per witness, a process known as approval voting. The top N witnesses by total approval are selected. (N) is defined such that at least 50% of voting stakeholders believe there is enough decentralization. When stakeholders express a desired number of witnesses, they should also vote for at least that many. A stakeholder cannot vote for more decentralization for which they actually cast votes.

Each time a witness produces a block, they are paid for their services. Their pay rate is set by the stakeholders via the elected delegates. If a witness fails to produce a block, they are not paid. The record of missed blocks is kept, and may lead to a witness becoming voted out in the future.

The slate of active witnesses is updated once every maintenance interval (1 day) when the votes are tallied. They are then shuffled, and each witness given a turn to produce a block at a fixed schedule of one block every 2 seconds. After all the witnesses have had a turn, they are shuffled again. If a witness does not produce a block in their time slot, then that time slot is skipped, and the next witness produces the next block.

Historically, BitShares has maintained a 99% witness participation rate. Anyone can monitor the network health by observing this metric. Any time witness participation falls below a certain level, users of the network can allow more time for transactions to confirm, and be extra vigilant about their network connectivity. This property gives BitShares the unique advantage of being able to alert users of a potential problem within 1 minute of it occuring.

Delegates known as the ‘Committee’ can also be elected in BitShares. The delegates each become a co-signer on a special account that has the privilege of proposing changes to the network parameters. This account is known as the genesis account. These parameters include everything from transaction fees, to block sizes, witness pay, and block intervals. After the majority of delegates have approved a proposed change, the stakeholders are granted a 2 week review period. During the review, stakeholders may vote out delegated committee members and nullify the proposed changes. The Committee are unpaid, however the parameters are not changed very often. (note – please see 2020 update also Sustenance of Blockchain funds).

This design was chosen to ensure that delegates technically have no direct power, and all network parameter changes are ultimately approved only by the stakeholders. With this delegated Proof-of-Stake, we can truly say that the administrative authority is fully decentralized and in the hands of the users (BTS token holders), and not the delegates nor the witnesses.

The genesis account can technically perform any action that any other account can perform. This means it is possible to send funds to the genesis account or specify the genesis account as an escrow agent. The genesis account can also be used to issue new assets. This method provides a very high degree of trust and accountability, which creates an untold number of applications whereby elected delegates can perform tasks to aid stakeholders.

From time to time, it is necessary to upgrade a network to add new features. Under DPoS, all changes must be triggered by active stakeholder approval. While it is technically possible for the witnesses to collude and change their software unilaterally, it is not in their interest to do so. A witness is selected based upon their commitment to remain neutral to blockchain policy, which protects them against false allegations they are the administrators/managers/owners/operators of the network. A witness is merely an employee of the stakeholders.

Developers may implement whatever changes they deem appropriate, so long as those changes are contingent upon stakeholder approval. This policy protects the developers as much as it protects the stakeholders and ensures that no individual has unilateral control over the direction of the network.

The threshold for changing the rules is the same as replacing 51% of the elected witnesses. The more stakeholder participation in electing witnesses, the harder it becomes to change the rules.

Ultimately, changing the rules depends upon everyone on the network to upgrade their software, and no blockchain level protocol can enforce how rules are changed. This means that hard-forking “bug fixes” can be rolled out without requiring a vote of the stakeholders, so long as they remain true to the universally expected behavior of the code.

In practice, only security critical hard-forks should be implemented in such a manner. The developers and witnesses should wait for the stakeholders to approve even the most minor changes.

A double spend can occur anytime a blockchain reorganization excludes a previously included transaction. For instance, the witnesses have a communication breakdown caused by a brief global Internet disruption. With DPoS, the probability of a communication breakdown enabling a double spend attack is very low. The network can immediately detect any loss in communication, as witnesses fail to produce the blocks on schedule. The network can throttle itself so users have to wait until half of the witnesses have confirmed their transactions, which could be up to a minute or two.

Each transaction on the network may optionally include the hash of a recent block. If this is done, the signer of the transaction can be confident that their transaction may not be applied to any blockchain instance that does not include that block. A side effect of this process is that, over time, all stakeholders end up directly certifying the long-term integrity of the transaction history.

Because all witnesses are elected, highly accountable, and granted dedicated time slots to produce blocks, there are rarely any situations where two competing chains can co-exist. From time to time, network latency will prevent one witness from receiving the prior block in time. If this happens, the next witness will resolve the issue by building on whichever block they received first. With 99% witness participation, a transaction has a 99% chance of being confirmed after reaching a single witness.

While the system is robust against natural chain reorganization events, there is still some potential for software bugs, network interruptions, or an incompetent or malicious witness to create multiple competing histories longer than a block or two. The software always selects the blockchain with the highest witness participation rate. A witness operating on their own can only produce one block per round, and it will always have a lower participation rate than the majority. There is nothing that any witness (or minority group of witnesses) can do to produce a blockchain with a higher participation rate. The participation rate is calculated by comparing the expected number of blocks produced vs the actual number of blocks produced.

Under DPOS, every stakeholder has influence that is directly proportional to their stake, and no stakeholders are excluded from exercising this influence. Every other consensus system on the market excludes the vast majority of stakeholders from participating. There are many different ways that alternatives exclude stakeholders. Some alternatives use invite-only systems. Others exclude participation by making it cost more to participate than they earn. Still other systems technically allow everyone to participate, but they can be safely ignored by a few large players who produce the vast majority of all blocks. Only DPOS ensures even distribution of block production among the most people, and that everyone has a viable means to influence who those people are.