Polkadot — An Early In-Depth Analysis — Part Three— Limitations and Issues
I would like to thank Alistair Stewart, lead researcher of Polkadot, for verifying the accuracy of the article and answering any questions I had. There are lots of excellent research papers, articles and videos which were extremely helpful in researching the project and always great to see so much interaction with the community. As with other articles I will provide links that reference to sections, as well as include a list of sources at the bottom of the article for you to look into specific areas in more detail if required.
Part One — Polkadot Overview and Benefits
Part Two — In-Depth look at the Consensus
Part Three — Limitations and Issues (This article)
In part one we covered an overview of Polkadot. In part two we looked at the consensus mechanism used by Polkadot. In this part we will look at potential limitations / trade-offs and issues that still need to be resolved.
Security
With the design of Polkadot, the security of the relay chain is paramount, should that be compromised then all connected chains will also be compromised.
The DOT ICO took place in October 2017 and raised over 145 million USD in Ethereum. Less than 2 weeks later, over 90 million USD of the funds raised during the ICO were permanently frozen due an exploit of a vulnerability in Parity’s (makers of Polkadot) multisig wallet code. Although there have been efforts to retrieve the funds, over 500,000 ETH are still locked to this day.
Four months earlier the parity wallet was previously attacked draining $30 million USD of ETH. More recently Ethereum was attacked as a result in a vulnerability with Parity’s client for Ethereum, forcing them offline. It did not manage to bring down the entire Ethereum network though as the GETH Ethereum client was immune to the attack.
Whilst the above is relevant because it’s the same company making Polkadot, that’s not to say the Polkadot platform is insecure. Polkadots security is backed through multiple processes of validity checks which we will look at in more detail below.
Validity Check 1 — Security of assigned validators to each parachain
The first validity check of a PoV block is executed by the corresponding parachain validators. If they verify the PoV block then they sign and distribute the erasure codes of the blob, including the PoV block, to each validator. — (4.4.2 Validity and Availability Overview of Polkadot and its Design Considerations)
One of the ways Polkadot differs from Ethereum 2.0 is the security of each shard / parachain. Ethereum 2.0 requires at least 111 validators per shard to run the network and 256 validators per shard to finalize all shards within one epoch. Both rotate the validators between shards and employ a similar finality gadget protocol. Polkadot uses a much small number of validators per parachain for scalability (around 10 per parachain with a minimum of 5), whilst claiming to be as secure with the other points detailed below.
The chances are significantly higher of collusion between the small number of validators assigned to each parachain, either through waiting until nodes the attacker controls are assigned to the parachain, or easier method of having malicious collators bribe validators so that they validate an invalid blob. Additional checks are required which are discussed below.
Imagine a parachain with a few collators. We can assume that they may be malicious and collaborate with the malicious validators. In this case, the validators will not have any report. So, there will be 0 extra checks. As soon as all parachain validators are malicious in this malicious parachain, they can add invalid block headers and cannot be caught. The security argument says here that they need to wait around 50 years for this, so the attack is not possible. However, in the real life, since the attack does not have any risk, the collators can bribe parachain validators with their stake and parachain validators validate an invalid blob — (Page 26 Availability and Validity Research Paper)
Validity Check 2 — Fishermen
We rely on nodes acting as fishermen to report the invalidity of a blob as a second level of validity checking. They would need to back any claim with their own stake in DOTs. —( 4.4.2 Validity and Availability Overview of Polkadot and its Design Considerations)
To assist with finding validators that have colluded and included an invalid block like explained above, fishermen are bounty hunters that perform checks and report them to receive a reward. However there is no incentive to keep continuously checking and “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” as explained in this great article below.
While fishermen are part of the security model of Polkadot, the design would be secure without them. Since there is no incentive model for fishermen designed yet we need to keep Polkadot secure in their absence. Adding an incentive model for fishermen is part of our future work. (3.1 Roles Overview of Polkadot and its Design Considerations)
To find an invalid block before it is finalised, fishermen currently have a very small time period of just 60 seconds. In comparison Ethereum finalises blocks every epoch (6 minutes), but the recommended time for full finality is 2 epochs (12 minutes). The longer the time period, the more secure the network is, as there is more time for additional checks to be performed and reported but at the expense of finality.
We require that approval validity checks complete before finality. We cannot however require that all validator checks conclude before finality, or even ask fishermen to begin checks before finality, so invalidity can be detected after finality. — (Page 1 Availability and Validity Research Paper)
If an invalid block is detected after it has been finalised it will have to roll back the state of ALL parachains and all transactions, which will also break light clients, “All parachains share security and state, meaning if one chain has a message reverted, all chains get reverted” This means that all transactions in this time period are reverted which poses tremendous uncertainty and insecurity to the network. The alternative is to do not roll back the state and the invalid block from one of the parachains could then corrupt the other connected parachains.
Validity Check 3 — Additional checks performed by a few randomly and privately assigned validators
The third level of validity checking is executed by a few randomly and privately assigned validators. We determine the number of validators in the third level of validity checking considering the amount of invalidity reports given by fishermen and unavailability reports given by collators. If an invalid parachain block is detected, the validators who signed for its validity are slashed. We wait for enough of these randomly assigned checkers to check the block before voting on it in GRANDPA. — 4.4.2 Validity and Availability Overview of Polkadot and its Design Considerations
The minimum number of validators to validate a parachain is 14 to ensure the probability that waiting for malicious validators to be randomly assigned to the same parachain checks would be unrealistic (50 years). If there are 10 validators performing the check in Check 1 detailed above, then a minimum of 4 additional validators will need to perform additional checks. Validators need to do considerably more work in the additional checks with requesting the erasure coding chunks from 1/3 of the network for each parachain and performing validation, and so will limit scalability of the relay chain. In the event that all the assigned validators have colluded in check 1, the graph below shows the probability of the attack succeeding with the number of additional checks (µ). One additional check brings the probability down to 50% of succeeding, just over 25% with 2 checks, 13% with 3 checks and 7% with 4 checks.
However, if a malicious validator is selected to produce a block in the relay chain, then they can first include a legitimate block from a parachain in the relay chain block to then discover who the hidden additional validators are, thus remove the risk of being caught and potential to collude, which removes the advantage of them being hidden in the additional checks. They can then equivocate (vote on another block in the same slot) which includes the malicious block on the parachain and the attack will succeed. Equivocated blocks also can’t be invalidated because that would enable attacks on finality.
4.2.6 Equivocation: We say two distinct relay chain blocks R and R0 are equivocation for one another if they use the same VRF output ˆωR0 = ˆωR for the relay chain randomness. We say R has an equivocation R0 in this case, or just has equivocations to merely express the existence of R0 . We distrust relay chain blocks with equivocations of course, and must mark them as having equivocations, but we sadly cannot invalidate them because doing so creates attacks on finality.
We therefore fear an adversary might create an R0 with an innocent B0 on ρ merely to learn the approval checkers determined by ˆωR for ρ, but then equivocate with another R that contains a malicious B on ρ. In this scenario, our equivocation R triggers exactly the same approval checks for B as R0 did for B0 , which wrecks our advantage over the adversary — (4.2.6 Equivocation Availability and Validity Research Paper)
Cost to attack in Polkadot
We also want to ensure that the block is available before selecting the randomly assigned validators. This means that the parachain validators have to commit running a high risk of being slashed for a small probability of getting an invalid block finalised. This means that the expected cost of getting an invalid block into Polkadot is higher than the amount of stake backing a single parachain. — 4.4.2 Validity and Availability Overview of Polkadot and its Design Considerations
When validators are found to have performed misconduct a percentage of the stake will be slashed depending upon the severity. For Level 4 security threats such as collusion and including an invalid block then 100% of the stake will be slashed. What’s really important to understand is that both the validators own stake and the nominated stake will be slashed, so you could lose all your DOT that you have staked against a validator if they perform maliciously.
Having skin in the game is important to deter attacks, but with the combination of 0% commission rates, incentives to split stake across all validators and no minimum own stake required, then this can lead to potentially dangerous scenarios.
As you can see from below Zug Capital have 19 out of 197 validators participating in consensus and have 10% of the total stake. They are not earning any commission and only stake 10 DOT of their own stake for each validator, whilst the remaining 3.011 million DOT are from people delegating to them. This means that if they were to perform an attack they would only lose 190 DOT (cost of around $855 currently) and controls 10% of the entire stake. Thus bribes to act maliciously don’t have to be that large, especially when compared to the amount of money that could be made shorting DOT and performing an attack. It is the nominators which take the vast majority of risk. (many of which I imagine don’t even realise they could lose 100% of their DOT). Checking the security of setups used by validators is also incredibly difficult, and whilst there are registrars to confirm identities, these can also succumb to bribes / false information provided. In the example of Zug Capital they have verified their identity on-chain using their website, which you can see from polkadot.js UI. However if you click on zugcapital.com website, it just redirects to the nomination UI! So they are even anonymous.
Shared State and Shared Safety Assumptions
One of the main selling points of Polkadot is the Shared State infrastructure between the Relay Chain and all of the connected parachains. If the Relay Chain must revert for any reason, then all of the parachains would also revert. This is to ensure that the validity of the entire system can persist and no individual part is corruptible.
The shared state makes it so that the trust assumptions when using Polkadot parachains are only those of the Relay Chain validator set, and no other. Since the validator set on the Relay Chain is expected to be secure with a large amount of stake put up to back it, it is desirable for parachains to benefit from this security. — https://wiki.polkadot.network/docs/en/learn-architecture
Every parachain makes the same trust assumptions as detailed above in this article, and as such the relay chain validates state transition and enables seamless interoperability between them.
In return for this benefit, they have to purchase DOT and win an auction for one of the available parachain slots. Due to the limited number of parachain slots available, the amount to purchase could be very significant with winners having to hold large amounts of a very volatile asset, so whilst you get the DOT back should you lose the renewal of the lease period, then the value could be significantly different to what you initially deposited.
However, parachains can’t just rely on the relay chain for their security, they will also need to implement censorship resistance measures.
Censorship Attacks and Front Running
Recall from Part Two which discussed how consensus works, the very start consists of collators for each parachain collating transactions and proposing blocks to be validated on the relay chain. The selection for which collators turn it is to propose the block is determined by the parachain itself. Thus, each parachain will need to implement Proof-Of-Work or Proof-Of-Stake on each of the parachains to provide censorship resistance and protect against sybil attacks.
Collators don’t stake DOT but instead are rewarded in each of the parachains native token, thus the notion of “shared security” where people have to pay for security without having to worry about having sufficient stake / hash power for their own blockchain is flawed.
To aid in censorship resistance, a parachain may want to use proof of work or proof of stake to select collators, where the selection strategy is up to the given parachain — (4.4.1 Block Production Overview of Polkadot and its Design Considerations)
Collators could choose to not include certain transactions in a parachain to censor them or front run them with their own transaction. The collators could also DOS the assigned validators to prevent them from being able to propose blocks to the relay chain. In addition, there is also a smaller chance for censorship with the creation of the relay chain blocks and not including certain parachain blocks.
The process can also be slowed by sending fake unavailability reports to increase the additional number of validators required to validate and thus lengthening the process and consuming more resources.
However, we cannot measure the reliability of unavailability reports as fisherman’s reports since it is not possible to show the correctness or incorrectness of any unavailability reports. Malicious collators do not lose anything by just sending fake unavailability reports — (Page 28 Availability and Validity Research Paper)
For parathreads the issue is even harder to solve as even if each parathread implements pos/pow, there is a pool of parathreads that compete with each other in an auction to have their parachain block be included in the next slot on the relay chain. Enabling front running from transactions from other parahtreads and putting a high transaction fee to ensure it is selected first, or just preventing others from having their chains validated through charging higher transaction fees.
The censorship / front running attacks effects all use cases but particularly finance, trading, gambling, oracle uses cases.
Interoperability
Polkadot’s strength is providing seamless interoperability within its ecosystem, connecting parachains and parathreads together. It is also possible to connect Polkadot to other ecosystems through bridges. Bridges are specifically designed parachains or parathreads that are custom made to interact with another ecosystem such as Ethereum, Bitcoin and Cosmos for example, enabling interoperability. Because these other ecosystems don’t use the same shared state of Polkadot, finality is incredibly important because whilst the relay chain can roll back all the parachains, it can’t roll back the Ethereum or Bitcoin blockchains for example. Thus there needs to be sufficient time to ensure no roll backs will occur with Fishermen challenges so is likely to be a significant amount of time (60 minutes was suggested in the whitepaper) which adds a lot of latency, particularly if going from Bitcoin to Ethereum through Polkadot.
Each parachain is capable of around 1,000 tps and they hope to be able to achieve 1000 validators on the relay chain, which would enable up to 100 parachains. (The number of parachains is limited by the number of validators, and the number of validators is limited by scalability of the network / relay chain). As custom parachains are required for each blockchain this isn’t going to scale well, as ultimately there is a relatively small number of available parachain slots. By using more for bridges, then less are available for projects that would actually benefit from the bridges. Parathreads will be an option for some of the current slower blockchains, but technology is rapidly progressing, and existing chains are getting upgraded and newer chains offering ever higher performance, which will only increase as time goes on. Permissioned blockchains such as R3 Corda, Consensys Quorum, and Hyperledger are capable of 20,000 tps+ and each are their own separate instance. It’s just not going to be feasible to connect all of those to Polkadot and especially not as a solution to connect them all together.
Conclusion
There’s no question that Polkadot is a great project with a talented team and strong adoption. Whilst there are limitations / trade-offs and issues to resolve, as with all blockchain projects, it’s still incredibly early in this space and solutions to some are being worked on. The launch of Polkadot further advances the current state of blockchain significantly, bringing it closer to mainstream adoption. There won’t be one platform to rule them all however, with some uses cases better suited to one platform over another, and it’s not a zero-sum game. Blockchain is going to completely revolutionize industries and the Internet itself. The more projects researching and delivering breakthrough technology the better, each learning from each other and pushing each other to reach that goal earlier. The current market is a tiny speck of what’s in store in terms of value and adoption and it’s going to be exciting to watch it unfold.
For additional reading please see a list of articles / research papers I found particularly useful whilst researching.
Whitepaper, Overview of Polkadot and its Design Considerations, BABE Research Paper, GRANDPA: a Byzantine Finality Gadget, Video with NEAR explaining Polkadot consensus, Polkadot Wiki, Path of a Parachain block, Block Production and Finalization in Polkadot, Availability and Validity Research Paper, Polkadot’s Data Availability and Validity Scheme, Consensus Part 2 — Grandpa, Consensus Part 3 — BABE, Consensus Part 4 — Security, Slashing Mechanisms, Check Validators / Stake, Censorship, Polkadot Bridges, Polkadot, Substrate and Ethereum, Polkadot — shared security or single point of failure?, Projects building on Polkadot, Polkascan Block Explorer, Polkadot, The Ethereum 2.0 or The Mighty Race
The Network of Networks, Scalable Interoperability to Unleash the True Potential of Blockchain
How the Overledger Network Community Treasury is powering the Network of Networks
