Reorg collators page - #6774
Conversation
- edited parachain blockl path paragraph
|
@bhargavbh can you please have a read and check if there is any missing/wrong information? |
- rewrite validator doc - reorg collator doc - better navigation and IA
bhargavbh
left a comment
bhargavbh
left a comment
There was a problem hiding this comment.
left some high level comments and slightly repharsed censorship resistance subsection.
| - [How to Use Validator Setup](https://docs.polkadot.com/infrastructure/running-a-validator/#running-a-validator) - Guide on | ||
| how to use Polkadot / Kusama validator setup. | ||
| - [Slashing Consequences](./learn-offenses.md) - Learn more about slashing consequences for running a validator node. | ||
|
|
There was a problem hiding this comment.
potentially you can add reference to the ELVES protocol securing parachains: https://eprint.iacr.org/2024/961
|
|
||
| 2. The signature of the collator is valid. | ||
| Collators maintain a full node for the relay chain and a full node for their particular parachain, meaning they retain all necessary information to author new parablocks and execute transactions like miners do on PoW blockchains. Under normal circumstances, they | ||
| will collate and execute transactions to create an unsealed block and provide it with a PoV to one or more validators on a Polkadot core. |
There was a problem hiding this comment.
Not sure if PoV are defined/introduced at this stage. Just expanding it should suffice
|
|
||
| 3. Validate the candidate by executing the parachain Runtime. | ||
| Collators are similar to validators on any other blockchain. Still, they do not need to provide security | ||
| guarantees because the relay chain provides those as a service to them via [coretime](./learn-agile-coretime.md). If a parachain block is invalid, it will get |
There was a problem hiding this comment.
'via' does not seem the most appropriate word here.
There was a problem hiding this comment.
Why is via not appropriate? Any suggestions for replacements?
| too many collators may slow down the network. The only nefarious power collators have is transaction | ||
| censorship. To prevent censorship, a parachain only needs to ensure that there are some neutral | ||
| collators - but not necessarily a majority. Theoretically, the censorship problem is solved by | ||
| The assumption that having more collators is better or more secure is incorrect. On the contrary, too many collators may slow down the network. The only power collators have is transaction censorship. To prevent censorship, a parachain only needs to ensure the collators set is [sufficiently decentralized](../general/web3-and-polkadot.md#decentralization) and that there are some neutral |
There was a problem hiding this comment.
the sentence "more collators is more secure is incorrect ...." and "only power collators..." can be removed. Rather what we want to emphasise is: rollup safety (i.e. invalid transaction are not included on the rollup) is ensured by the relay chain using ELVES. But the onus of liveness (i.e. new blocks are eventually produced) and censorship resistance on the rollup is completely on the collators. Hence, a sufficiently decentralised collator set ensures liveness and mitigates censorship resistance. In theory, a single honest collator can ensure liveness but with reduced throughput.
2 participants
No description provided.