In the Polkadot white paper and W3F research papers and lots of other articles, Fishermen is frequently described. This Fishermen (parachain full node) role checks validity of blocks by pointing out potential fraud of Relaychain validators.

For example, one of articles it is written that

The availability check by the block author ensures that Polkadot will only include blocks for which the validators distributed their chunks, but it does not guarantee their validity. Because the number of validators on each parachain is so low, collusion is a reasonable concern. By separating block production (BABE) from finality (GRANDPA), Polkadot can perform extra validity checks after a block is produced but before it is finalized.[3] Polkadot has special actors, fishermen, who patrol Relay Chain blocks for invalid candidate receipts.

However, the thing is Fishermen role doesn't exist in current implementation. (ref: How do relaychain, parachain, collators, validators work together)

Why it was considered to be needed initially and what is the alternative for this to check the validity of blocks (at high level)? I feel there're not enough papers, some articles reflecting the latest information (It could be I just don't notice them). I would like to get references(links) to detailed information if possible.

1 Answer 1


https://polkadot.network/blog/polkadot-v1-0-sharding-and-economic-security/ This blog post contains a deep dive on how Polkadot currently provides economic security. It's actually a lot better than the fishermen plan because it defends against network-level adversaries. It uses a system of random assignment of validators to check each parachain block, which those validators broadcast to the network over gossip, and then corresponding approval messages that validators issue once they've checked the block and found it to be good.

Quoting from the blog post:

The security argument for Polkadot is based on Gambler’s Ruin. While it's true that an attacker who can take billions of attempts to brute-force the process would eventually be successful, we combine this process with a slashing system that ensures that each failed attempt is accompanied by a slash of the attacking validators' entire stake. Polkadot is a proof-of-stake network, and at the time of writing, each validator is backed by approximately 2 million DOT of stake. Most likely, each failed attempt would result in the slash of 10 or 20 validators. But even if only 1 validator gets slashed, it's still apparent that an attacker's funds would dry up quickly before success is likely.

We achieve this with a few other properties of approval checking:

  1. Validators' assignments to check a parachain block are secret until revealed by themselves.
  2. Validators' assignments are deterministically generated.
  3. Validators broadcast an intention to check a parachain block before recovering the data necessary to perform those checks.
  4. When validators broadcast an intention to check a parachain block and then disappear, this causes more honest validators to begin checking.

Property 1 ensures that an attacker doesn't know who to DoS to prevent them from checking a block.

Property 2 ensures that even if the attacker has gotten a lucky 'draw' and has enough malicious nodes to convince honest nodes that something has been checked, that there are most likely honest nodes that will do the checks alongside them, and those honest nodes will raise an alarm.

Property 3 ensures that honest nodes don't accidentally reveal themselves as checkers by requesting data from malicious nodes and then get taken offline by the adversary with nobody noticing. i.e. if the attacker tries to silence checkers it will be noticed by others.

Property 4 ensures that nodes that appear to have been DoSed will be replaced by even more nodes. Approval-checking is meant to be like the hydra: if you cut one head off, 2 more heads appear.

  • I see. Thank you for sharing!
    – Shunsuke
    Commented Jul 26, 2022 at 1:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.