Consensus protocol in Lisk

Before explaining what the PoA consensus mechanism is, let us recall what consensus protocol means in Lisk. The consensus protocol in Lisk is divided into the following two parts.

The first part is responsible for the selection of block generators. On the Lisk Mainchain, this is performed using DPoS. Users holding LSK tokens can vote for delegates, and the delegates receiving the most votes in terms of LSK are allowed to generate blocks.

The second part of the consensus protocol describes how block generators choose the chain to which they add new blocks - in the case of a fork - and also when a block is considered final, i.e., is irrevocably deemed part of the blockchain. This part of the consensus protocol is realized by Lisk-BFT.

What is Proof-of-Authority?

PoA is an alternative to DPoS for the first part of the consensus protocol, i.e., for the block generator selection mechanism. When building a blockchain with the Lisk SDK version 6, one can choose between PoA and DPoS. The second part of the consensus protocol, Lisk-BFT, is the same for all chains, regardless of their choice of PoA or DPoS. That means, for instance, that the rules for finality are not influenced by the choice between PoA and DPoS.

How does PoA work?

As in DPoS, block slots are grouped in rounds, and at the beginning of each round, the block generators are selected. However, instead of choosing the block generators by a certain vote weight, PoA blockchains maintain a set of authorities eligible to generate blocks, namely the so-called active authorities, and each active authority will be assigned one block slot in which they can generate a block. The number of active authorities is also determining the length of a round. For example, if there are 10 active authorities, then a round consists of 10 blocks.

Most of the time, this set of active authorities does not change. Moreover, regular accounts in a PoA blockchain can not influence this set. This is also why they are called “authorities” instead of “delegates”. The block generators have the authority to generate blocks, no matter how much stake they have in the corresponding blockchain, and no matter how much other account holders would like to delegate some of their stake to them.

Nevertheless, the set of active authorities can be changed. New authorities can be added and existing active authorities can be removed. In particular, the number of active delegates, and therefore the round length, can be changed. Moreover, the BFT weights of the active authorities as well as the threshold for finality can be updated. All these updates must, however, be approved by a subset of the active authorities via signatures, whereby the sum of the weights of these authorities must be greater than or equal to the finality threshold.

Let us consider the example where the current set of active authorities consists of 10 authorities where each has the BFT weight of 1 and the finality threshold is 7. If one authority is supposed to be removed from the set of active authorities, then this update must be approved by at least 7 active authorities.

The PoA module, which must be used by PoA blockchains built with the Lisk SDK version 6, implements the following commands which facilitate the authority updates:

• Authority Registration Command: This command is similar to the delegate registration command in DPoS. An account willing to become an active authority must first send an authority registration transaction.
• Update Authority Command: This command updates the set of active authorities as mentioned above. An update authority transaction must contain an aggregate multisignature whereby enough active authorities have contributed to, such that the sum of the corresponding BFT weights meets the finality threshold.

Security of PoA

Being in the blockchain world, where most projects strive for decentralization and trustlessness, you may question the usefulness and the security of PoA. Indeed, PoA blockchains do not achieve as much decentralization as blockchains using, for instance, (Delegated) Proof-of-Stake or Proof-of-Work. In an extreme case, there may be only one or two authorities validating all transactions and contributing to the consensus protocol. Having very few authorities could increase the risk of censorship, i.e., intentionally not including certain transactions in the blockchain. Furthermore, as well as increasing the risk that a subset of active authorities with enough BFT weight could collude and behave maliciously, e.g., by reverting finalized blocks which allows, for instance, double-spending. The latter risk may appear concerning, especially since the authorities don’t need to have any tokens at stake, i.e., collateral tokens that are locked.

This may all sound rather disturbing, however, there are reasons why PoA blockchains are secure - if certain requirements are met. This is the case when the identities of the authorities are known and when their reputation and the reputation of the project could be damaged (note that it is expected that most authorities are connected to the project and have an interest in its success). In other words, the authorities have their reputation at stake. Consider the example where a few companies transact with each other by maintaining a PoA blockchain. Each company runs an active authority account, and it is known which authority account belongs to which company. If any company would behave maliciously, the reputation of this company would be heavily damaged, and this would result in most companies ceasing to do business with this particular company.

Therefore, PoA can be secure if certain requirements are met, and in some cases, it can be even more secure than DPoS, as we will see in the next section.

When is PoA useful?

Running a PoA chain has several advantages, and primarily, one of its key benefits is its simplicity. For example, no consensus token is required. In particular, it is possible to run a PoA sidechain that solely uses the LSK token for all its purposes. In contrast, every DPoS chain needs to create a custom consensus token used for block rewards. Moreover, no voting by any users is required, and no voting transactions need to be processed, which also increases the performance of the nodes. If simplicity and efficiency are crucial for a blockchain project, PoA may be the better choice.

As mentioned earlier, PoA may also be more secure in certain cases. For example, for blockchains where the expected staked capital is rather small if DPoS is chosen (in Lisk DPoS, the staked capital is the amount of locked tokens due to voting). For instance, if the staked capital of a DPoS chain is equivalent to 1 million USD and the finality threshold equals 67% of the number of active delegates, then a malicious entity staking an equivalent of 334,000 USD could result in stopping all blocks from being finalized. In addition, a malicious entity staking an equivalent of more than 667,000 USD could perform double-spending attacks. For such cases, PoA may be the safer choice as the staked reputations could be more valuable than the staked tokens in a DPoS chain.

Another case is whereby only a few entities are expected to transact with each other, as in the example mentioned above where some companies maintain a PoA chain, and each company runs an active authority account. In this case, it is much simpler to set up and maintain a PoA chain while having sufficient security, or even more security for certain attack models because no company could gain more control over the blockchain than any other company or entity.

PoA may also be deployed for sidechains used for scaling. For instance, one could create a PoA sidechain that is purely used for LSK balance transfers of low amounts. In this case, a high throughput of LSK balance transfers within the Lisk ecosystem is traded against decentralization. Restricting the transfers to low amounts justifies the reduced level of decentralization.

Another example is testing: If a project wants to perform some extensive testing of their custom module on a testnet, then using a PoA blockchain implementing these modules on a testnet simplifies this process, as the setup and maintenance of a PoA chain is much simpler.

Summary

PoA is an alternative consensus mechanism to DPoS in the Lisk SDK. It is less decentralized but offers a simple, efficient, and reliable block generator mechanism. The security of PoA relies on the staked reputation of the block generators instead of the staked tokens of the block generators and their voters. It is especially suitable for blockchains where the expected staked capital in the case of DPoS would not provide enough security, but staking the reputations of the active authorities would do so.

If you wish to dive deeper into the technical details, please read the specification of the PoA module in LIP 0047 or ask technical questions about PoA in the Lisk research forum.