Polkadot — An Early In-Depth Analysis — Part Three— Limitations and Issues

Security

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)

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)

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)

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)

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)

https://www.youtube.com/watch?v=xBfC6uTjvbM&feature=youtu.be&t=1905

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

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)

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

https://polkadot.js.org/apps/#/staking/targets

Shared State and Shared Safety Assumptions

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

Censorship Attacks and Front Running

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)

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)

https://github.com/paritytech/polkadot/issues/1348

Interoperability

Conclusion

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store