Polkadot — shared security or single point of failure?

Polkadot provides an infrastructure for blockchains to connect and share security with each other. This is achieved through one common relay chain on which other blockchains (parachains) are hooked in thereby participating in the consensus mechanism of the whole network. Polkadot aims to provide participating blockchains shared security through this setup. This article lays out concerns on this shared security being a potential single point of failure. The purpose of this article is to enable a debate on this issue to contribute to the soundness of Polkadot.

I have come to the conclusion that Polkadot is designed in a sophisticated and sound way to achieve a reasonable security of the network. However, there are some gaps that need to be closed: 1) Fishermen need to be incentivized to check validators independently on whether validators misbehave. 2) Fishermen and other validators need enough time to find and report compromised blocks which suggests a longer finality period than currently planned. However, this requirement is in direct conflict with the need for quick finality so that participants can trust and build on the latest state. 3) Fishermen should receive a higher reward the earlier they report a compromised block. 4) Transactions with bridges such as Ethereum may only be triggered when a block is considered final, i.e. non-revertible since independent blockchains can not be reverted.

This article is based on the white paper, published data from Polkadot/Parity and my conversation with Alistair Stewart, Alfonso Cevallos and Márton Csernai. Here I would like to thank Alistair, Alfonso and Márton for their time and their thorough answers to my questions. In these conversations, I realized that many concepts of the white paper were outdated. Thus, this article presents an overview on the status quo which is subject to change. It is very likely that complexity will increase even further as it did in the past. This is why it is important to test the network in Kusama (https://kusama.network/).

Canary bird representing the Kusama testnet. Photo by Bernal Fallas on Unsplash.

Those very familiar with Polkadot can skip the next chapters that discuss the basics on Polkadot and go directly to chapter “Collators are incentivized to behave honest”.

Roles in the Polkadot network

The figure below shows how parachains are hooked into the relay chain. On the left side of the picture an independent blockchain with own consensus is linked through a bridge. These blockchains are interoperable but do not share security. Parachains in turn rely on the security of the polkadot network (the same holds for parathreads — a lightweight version of parachains, for further information please check out the Polkadot wiki).

Figure taken from the Polkadot Wiki (https://wiki.polkadot.network/en/latest/polkadot/learn/parathreads/)

The figure above shows collators and validators. The Polkadot Wiki says “Collators maintain parachains by collecting parachain transactions from users and producing state transition proofs for validators […] Under normal circumstances, they will collate and execute transactions to create an unsealed block and provide it, together with a proof of state transition, to one or more validators responsible for proposing a parachain block.” So collators provide data on parachain transactions to validators of the parachain for them to find consensus. Collators do not directly participate in the consensus of Polkadot and therefore never stake.

Validators perform two roles: “First, verifying that the information contained in an assigned set of parachain blocks is valid (such as the identities of the transacting parties and the subject matter of the contract). Their second role is to participate in the consensus mechanism to produce the Relay Chain blocks based on validity statements from other validators.“ (https://wiki.polkadot.network/docs/en/maintain-validator).

Validators are randomly assigned to parachains by the Polkadot protocol for a given time interval. You can imagine a bunch of validators at each parachain validating parachain blocks (these are also sometimes referred to as the “parachain validators” of a specific parachain). As soon as these validators have successfully validated a parachain block, this block is broadcasted to the relay chain. Then, all parachain blocks are bundled and sealed on the relay chain i.e. written on the relay chain. This is done by the same entity that has just been validating the parachain but now performs the second role namely sealing parachain blocks on the relay chain.

In “some cases (e.g. multi-fork validation and invalid sub-block signing) validators cannot themselves easily detect each others’ misbehaviour since constant verification of each parachain block would be too arduous a task” (white paper, section 6.2.3, page 10) since storing the data of all chains requires too much bandwidth. For this case Polkadot introduces so called “fishermen” (white paper, section 6.2.3, page 10). Fishermen are checking proposed blocks in every part of the network. Ideally, some fishermen focus on one parachain, another group tackles another parachain and a group of fishermen checks relay chain validators. If they find a compromised block, then the creator of the block gets slashed and the fisherman receives a portion of this slashed stake as reward. Fishermen are particularly important when there is a group of validators colluding and proposing a compromised parachain block.

Consensus in Polkadot in a nutshell

The collators of each parachain create unsealed blocks which are blocks that are not validated in the overall consensus mechanism yet. These unsealed blocks are then handed to validators of the parchain. These validators create parachain blocks which are then broadcasted to the relay chain. Then, these parachain blocks are bundled and written on the relay chain https://wiki.polkadot.network/docs/en/learn-consensus.

But who bundles all these parachain blocks and writes them on the relay chain? Polkadot selects block producer candidates out of the total set of validators based on a random function: https://wiki.polkadot.network/docs/en/learn-randomness. According to the white paper, chapter 6.4, page 11 “The sealing process takes place under a single consensus-generating mechanism addressing both the relay-chain’s block and the parachains’ blocks which make up part of the relay’s content: parachains are not separately “committed” by their sub-groups and then collated later.” In the following, I analyze what happens if the mentioned parties misbehave. I start with the collators assuming that a parachain’s collator misbehave and collude.

Collators are incentivized to behave honest

Validators check the proposed transaction data and state transition proofs as provided by collators. Therefore, validators have to know the rules of the parachain. Transaction data which does not adhere to these rules are immediately rejected. As such, compromised blocks as proposed by collators are simply not picked up by validators. As a consequence, the parachain does not participate in consensus anymore and is put dormant. This is not in the interest of the collators who are stakeholders of their parachain. As a result, misbehaving collators are very unlikely.

For deciding on the soundness of a validated block, the rules of the underlying blockchain must be deterministic which means that with given data there is only one outcome.The protocol does exactly what it receives as code — whether the rules are economically sound are independent of that. Here validators strictly follow the rules of the parachain as written in code. Economical viability must be ensured by the parachain.

Validators proposing a parachain block can have an incentive to collectively misbehave

Validators check whether the unsealed parachain block they received from collators fit to the parachain’s rules. If the transaction data fits the parachain’s rule set, then the validators broadcast this parachain block to the network.

If there is a minority of validators on a specific parachain proposing a compromised parachain block, then the other parachain validators validating on this parachain will report this block. For conflict resolution, other validators of the network come in and download this block to check whether they consider it as compromised. So the remaining validators of the network judge whose claim is valid. If they come to the conclusion that the parachain block is indeed compromised, then the misbehaving validators are slashed. If they come to the conclusion that the block is not compromised, then those validators falsely accusing misbehavior are slashed.

It becomes very interesting when there is a majority of validators on a specific parachain proposing a compromised parachain block. This event is more likely if the collators collude with the validators in signing compromised blocks namely when the financial incentive to do so is sufficient. Polkadot assumes that fishermen will find compromised blocks that are proposed by colluding validators. However, this assumption is only legit if there are enough fishermen checking blocks. But a fisherman will only check blocks if he receives a reward. And with the current design, a fishermen only receives a reward if he finds faulty blocks. This can become a problem as I illustrate below.

If there was no compromised block for a long time, then fishermen would stop to pursue their work since they do not receive any rewards which makes their business unprofitable. However, the fewer fishermen are operating on the network, the higher the incentive for validators to compromise blocks. This increases the probability of compromised blocks which in turn increases fishermen to search for compromised blocks. Whether this balance can be kept permanently can be questioned though. It is definitely possible that the network swings from one extreme to the other: First, validators do not provide compromised blocks for a very long time since the punishment of losing the whole stake is too risky. If this state of non compromised blocks is kept for a very long time, then fishermen would stop working since they do not receive rewards and the field is set for an attack by colluding validators. This is exactly when the network goes to the other extreme.

If there are not enough fishermen, it is possible that a compromised parachain block is overseen and written on-chain. To alleviate this problem, fishermen must have an incentive to work independently of validators misbehaving. Details on this are illustrated in the recommendations further below. At least, Polkadot already randomizes the distribution of validators to parachains to reduce the opportunities for collusion.

Let’s have a closer look on the incentives of validators to collectively misbehave: Validators have an incentive to manipulate transaction data for their own interest (e.g. receiving a higher financial return by increasing the block reward or by inserting a transaction to their address or more complex manipulations). More precisely, validators have an incentive to provide compromised blocks if the additional reward through compromising the data exceeds the value of the slashed stake in case the fishermen find the flaw. The stake of validators highly impacts their incentive for them to misbehave. Polkadot so far does not require a minimum stake, however, this will probably change soon. The probability on fishermen finding the compromised block must be considered in this equation as well as the probable detrimental effect on collator and validator business in the future if the flaw is found. Also validators participate in a decrease in network value through attacks since validators are stakeholders of the network. So validators only have an incentive to compromise blocks if the financial return they receive exceeds the loss incurred by reduced token value.

Block producer candidate are unlikely to misbehave

Block producer candidates collect validated parachain blocks and write them on the relay chain (white paper, section 6.4, page 11). There is a challenge period in which the integrity of these blocks may be questioned before the block is considered final (white paper, section 6.5, page 12). In this time period, fishermen have the chance to find compromised blocks and report them so they can be reverted. If a fisherman finds a compromised block, then he receives a reward in the form of (a portion) of the stake of the validator who signed the compromised block. The validator loses all of his stake as a punishment for his misbehavior (white paper, Chapter 6.2.3, page 10). If a fisherman finds a compromised relay chain block after finality, then the misbehaving party is slashed in any case and the fisherman rewarded. The block is, however, not reverted as based on the current design — details on this are found in the next chapter. I recommend to reward fishermen with a higher portion of stake when the block is found within finality since a compromised block found within finality is much more valuable than if found after finality.

If a block producer is misbehaving and proposing a compromised block, then validators or fisherman will report this. Other validators then come in and make a judgement on the validity of the block. If they come to the conclusion that the block is indeed compromised, then the misbehaving block producer is slashed. If they come to the conclusion that the block is not compromised, then the falsely accusing validator or fisherman is slashed.

The majority of all validators combined has no incentive to misbehave since they are stakeholders of the network

If a majority of all validators is misbehaving, then the whole system is compromised. This would lead to a sharp decline in the value of the network and dot token — the native token of the Polkadot network. Since validators are stakeholders of the network, they would lose a tremendous amount of wealth in this scenario. For economic reasons, a majority of validators has no incentive to misbehave.

Compromised blocks written on-chain lead to either rollbacks or reduced data integrity.

The Polkadot Wiki defines finality as the “property of a block that cannot be reverted.” (https://wiki.polkadot.network/docs/en/glossary#finality). Taking this literally means that a compromised block that has become finalized cannot be made undone. However, when talking with Polkadot representatives I learned that this is not clear yet. There are two mutually exclusive options on how to handle compromised blocks found after the finality period:

1. Governance kicks in for deciding on reverting compromised blocks after finality period.
2. Compromised blocks are kept on-chain, no changes are made, only punishment of misbehaving parties.

After having thought about this, I realized that if a compromised block is found within finality, an automatic reversion could be reasonable instead of applying the lengthy governance process as described above. These questions are already posed to Polkadot representatives.

Importantly, a rollback means that ALL parachains are reverted: “All parachains share security and state, meaning if one chain has a message reverted, all chains get reverted” (see https://polkadot.network/faq/ under Technology, “What is Polkadot”). This means that all transactions in this time period are reverted which poses tremendous uncertainty and insecurity to the network. Research and early implementation has already started on a method to automatically replay transactions that were not compromised which would alleviate this problem. However, it is unclear to me what will be done with transactions to independent chains that are connected via bridges such as Ethereum. Apparently, information from and to bridges are only included after finality (Source: https://youtu.be/xBfC6uTjvbM) which hints towards the assumption that finalized blocks cannot be reverted.

Polkadot aims for achieving finality within 30 seconds after the block is written on-chain which results in a challenge period of only 30 seconds. This is a very short time frame for fishermen to find compromised blocks, report them and finding consensus on whether the allegation is justified. Merely regarding this aspect, I would assume that a challenge period of hours is much more reasonable. However, this results in more issues since users may only assume the validity of their transaction after the challenge period is over which may result in great latency.

Summary of attack vectors and recommendation for alleviating these

The greatest likelihood of validators misbehaving is at the validation of parachains. However, this is comparably unlikely since validators are assigned randomly to parachains. So, a random assignment of a majority of dishonest validators to one parachain would be necessary. However, this is more likely when there are only few validators assigned to a parachain. Therefore, the more validators are assigned to a parachain, the more secure is the network. The incentives to misbehave could increase tremendously when colluding with collators. In this case, fishermen are needed to report misbehavior. If not reported by fishermen, then validators colluding on one parachain would lead to compromised blocks written on the relay chain which is a single point of failure for the whole network.

Photo by Austin Neill on Unsplash

Currently, fishermen are only rewarded when they detect fraud. This in turn requires fraudulent validators. This might lead to a situation in which no validator acts fraudulently to not lose their stake. As a result, fishermen receive no rewards which makes them eventually leave the system. But a mechanism is needed in which fishermen are always incentivized to check whether blocks are compromised. Furthermore, a system that disincentivizes compromised blocks should be aimed for. Thus, fishermen should be incentivized to check validators independently on whether validators are fraudulent or not. I also recommend to design this mechanism in such a way that enough fishermen are incentivized to check blocks so the probability of a fraudulent fraud written on chain is reduced to a minimum. The required uptime of the network without regular rollbacks and sufficient data integrity may be only attained when there are hardly compromised blocks for which fishermen serve as an important building block.

Essentially, I recommend that fishermen receive a portion of the block reward. This requires a proof that fishermen checked the blocks validators produce. I could even envision a mechanism in which each parachain block requires a proof that it was checked by fishermen. Another very reasonable scenario is that block producer candidates only accept blocks that were checked by fishermen since validators would lose their bonds when proposing a block with compromised data even if they don’t know about it. So block producers have an interest in pre-checked parachain blocks. Pre-checking parachain blocks by fishermen reduces compromised parachain blocks to a minimum. In my conversation with representatives of Polkadot, I was told that they might implement a mechanism that rewards fishermen independent on whether they find compromised blocks by “burying” treasures.

In addition, I recommend a more distinguished fishermen reward. If a fisherman finds a compromised relay chain block after finality, then the fisherman should receive a smaller reward than if found within finality since a compromised block found within finality is much more valuable to the network than if found after finality. This translates into a reward mechanisms in which the fisherman receives a smaller portion of the stake of the misbehaving validator when found after finality than if found before finality. It is reasonable to elaborate the time factor of finding compromised blocks even further. The reward for a fisherman could be higher the earlier he has found a compromised block in general, e.g. the rewards for finding a compromised block are double as high in the first three relay chain blocks than in the next three relay chain blocks.

If a compromised block is not found before finality, then integrity is even further attacked since the compromised block would remain on-chain. This is why I recommend a challenge period that is long enough for fishermen to check blocks, report them and for finding consensus on whether the allegation is justified. This may reduce compromised blocks written on-chain to an absolute minimum. I also recommend that transactions to bridges may only be triggered after a block cannot be reverted in any case. This is reasonable since transaction with bridges cannot be reverted due to the independent nature of the connected blockchain.

The article showed that compromised blocks written on-chain pose a great threat to the system since the system’s reliability is tremendously reduced in the case of rollbacks. It is absolutely crucial that compromised blocks are found in time to ideally prevent them being written on chain. If a compromised block is written on chain it should be found as fast as possible.

Conclusion

Polkadot is tackling the gigantic challenge of providing shared security to many blockchains. They have solved this problem through complex mechanisms in which most attack vectors are smoothed out by design. However, fishermen are necessary to prevent collusion of parachain validators. This is why there should be an incentive mechanisms for fishermen to work permanently. In addition, the time for them to find, report and find consensus on whether the allegation is justified needs to be given. As a result, the finality cannot happen within a few seconds but must be extended. However, this should be balanced so that Polkadot can still provide a fast pace for finalized blocks. So I see Polkadot as a well thought through system in which, however, some adaptations must be undertaken in order for it to be reasonably secure. One question remained open in our analysis namely how Polkadot handles chain reversions in regards to transactions to independent blockchains connected via bridges. Here, further research is needed.