update elastic scaling guide #6739
Conversation
| //! backing groups. A solution is being discussed | ||
| //! [here](https://github.com/polkadot-fellows/RFCs/issues/92). | ||
| //! 4. **Fixed scaling.** For true elasticity, the parachain must be able to seamlessly acquire or | ||
| //! The development required for lifting this limitation is tracked by |
There was a problem hiding this comment.
I would name it an optimization rather than limitation.
| //! With the addition of [RFC-103](https://polkadot-fellows.github.io/RFCs/approved/0103-introduce-core-index-commitment.html), | ||
| //! the parachain runtime has the responsibility of selecting which of the assigned cores to build | ||
| //! on. It does so by implementing the `SelectCore` trait. |
There was a problem hiding this comment.
I would rephrase this to smth: RFC-103 enables parachain runtimes to constrain the execution of each block to a specified core. This ensures better security and liveness properties as described in the RFC. To make use of this feature ...
| @@ -0,0 +1,12 @@ | |||
| title: update elastic scaling guide for untrusted collator set | |||
There was a problem hiding this comment.
| title: update elastic scaling guide for untrusted collator set | |
| title: elastic scaling documentation changes for RFC103 |
| //! } | ||
| //! ``` | ||
| //! | ||
| //! ### Phase 3 - Configure fixed factor scaling in the runtime |
There was a problem hiding this comment.
This paragraph seems fuzzy. It is not really clear what fixed factor scaling is and where the elasticity comes from. I think what we are configuring here is the maximum scaling factor.
If it is fixed or elastic, that is a concern which is not yet implemented. Currently we rely on an external party to provision arbitrary amounts of cores to the parachain at each relay chain block via either bulk or on-demand.
| //! | ||
| //! - The `DefaultCoreSelector` implements a round-robin selection on the cores that can be | ||
| //! occupied by the parachain at the very next relay parent. This is the equivalent to what all | ||
| //! parachains on production networks have been using so far. |
There was a problem hiding this comment.
Hmm. Shall we rename this as part of this PR? It seems like LookaheadCoreSelector should be the "default" as we expect any new parachain to use asynchronous backing?
| //! <div class="warning">If you configure a velocity which is different from the number of assigned | ||
| //! cores, the measured velocity in practice will be the minimum of these two. However, be mindful | ||
| //! that if the velocity is higher than the number of assigned cores, it's possible that | ||
| //! <a href="https://github.com/paritytech/polkadot-sdk/issues/6667"> only a subset of the collator set will be authoring blocks.</a></div> |
There was a problem hiding this comment.
The question is why do we need to configure a velocity at all, seems redundant.
There was a problem hiding this comment.
Once the slot based collator can produce multiple blocks per slot we should also add that we recommend slot durations of at least 6s, preferably even 12. (better censorship resistance)
Resolves #5050
Updates the elastic scaling guide, taking into consideration:
This PR should not be merged until:
CandidateReceiptV2node feature bit is enabled on all networksexperimental-ump-signalsfeature of the parachain-system pallet is turned on by default (which can only be done after 1)TODO: