-
Notifications
You must be signed in to change notification settings - Fork 371
Conversation
| //! The Collator Selection pallet manages the collators of a parachain. **Collation is _not_ a | ||
| //! secure activity** and this pallet does not implement any game-theoretic mechanisms to meet BFT | ||
| //! safety assumptions of the chosen set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Collation is not a secure activity.
I agree with this for some definitions of "secure" but not for all. I agree that no matter how badly collators behave they can't cause the relay chain to finalize invalid parachain state transitions. That's a really cool and important aspect of Polkadot.
But there are still important ways in which a collator set can misbehave to cause nontrivial problems for a parachain:
- A collator can skip slots.
- A collator can censor transactions.
If this is coupled with an author-selection mechanism that selects only one author per slot in the consensus layer (like Aura), then a single malicious collator can cause the parachain to produce no block in that slot. The more collators do this the more the chain throughput decreases.
Regarding censorship, if the collator set ever becomes entirely colluding, they can retain unilateral control forever by censoring any transactions that would bond other accounts as collators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actualy, I think we could construct a minimal liveness proof that a block will be authored eventually from the kick_mechanism and an assumption that the chain is launched with at least one honest collator. But the practical concern still exists. One whale could stake a lot of accounts and skip all the corresponding slots.
Adding a slash to the kick mechanism would ensure that this whale attacker would eventually bleed enough stake to not be a problem, but there would still be an unstable transient period after launch before settling down to a steady state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There could be a slash, but it work similarly to the relay-chain staking where the slash is non-zero only for when a threshold go offline at once (and can be superlinear afterwwards).
We generally assume at most 33% byzantine. Worst-case, relay-chain governance can jump in, forcibly alter the state to one which kicks (and slashes, perhaps) all the bad collators. |
|
Looks fine to me, can you mention the Statemint repo commit that you copied so we can determine which other changes we need to move as well? |
|
So statemint will live here instead of its own repo? |
yes |
|
@gavofyork @bkchr Correct me if I'm wrong, but: |
apopiak
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This used statemint repo commit
9664809ad5de6ce43b6b78a6b3d12fbfece7f147.