Constrain parachain block validity on a specific core #103
Conversation
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
sandreim
changed the title
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
|
|
||
| At present time misbehaving collator nodes, or anyone who has acquired a valid collation can prevent a parachain from effecitvely using elastic scaling by providing the same collation to all backing groups assigned to the parachain. This happens before the next parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core. | ||
|
|
||
| The session index of candidates is important for the disputes protocol as it is used to lookup validator keys and check dispute vote signatures. By adding a `SessionIndex` in the `CandidateDescriptor`, validators no longer have to trust the `Sessionindex` provided by the validator raising a dispute. It can happen that the dispute concerns a relay chain block not yet imported by a validator. In this case validators can safely assume the session index refers to the session the candidate has appeared in, otherwise the chain would have rejected candidate. |
There was a problem hiding this comment.
Considering that we now changed this RFC to also add the session index I would change the title of the RFC (which only mentions the core index commitment).
Either this or I would mention here that this change is not needed for elastic scaling but we are taking advantage and bundling these unrelated changes into one
There was a problem hiding this comment.
Yeah and the motivations reads itself a little bit bumpy. Just a little introduction on that you try to solve two issues whatever.
There was a problem hiding this comment.
dispute concerns a relay chain block not yet imported by a validator
If this is the case, doesn't this also means that the CandidateDescriptor is unknown and thus, we need to trust the validator giving us a valid descriptor? And the attack here basically is that the validator would maybe check against the wrong set?
There was a problem hiding this comment.
Can you not just slash the validator for it asking you to check an invalid session index? It signs the dispute and if the session index is wrong, we should be able to proof this to the runtime or?
There was a problem hiding this comment.
By having the SessionIndex in the descriptor, it is either valid or it does not exist on any chain (as the chain checks on import). If it does not exist on any chain, then the dispute is just spam and won't resolve anyways, hence there is no risk.
Can you not just slash the validator for it asking you to check an invalid session index? It signs the dispute and if the session index is wrong, we should be able to proof this to the runtime or?
Not easily. You would need to be able to prove the session of a block of another fork.
And the attack here basically is that the validator would maybe check against the wrong set?
yes.
It is also just "nice" as it makes candidates more self-contained: With the SessionIndex provided in the descriptor you can validate the state transition without any knowledge of the fork it appeared in.
It is true that the SessionIndex could be made up, but so could be the persisted validation data. Essentially what a checker checks when validating is: This is valid, assuming you find a chain that would accept the candidate/has accepted the candidate: Both persisted validation data and SessionIndex are verified on chain, thus it is not necessary to prove their validity off-chain: "Assuming this actually exists, I can confirm it is valid."
I am mostly sanity checking myself here. Any more concerns, please bring them up. @burdges @rphmeier thoughts?
|
|
||
| The UMP queue layout is changed to allow the relay chain to receive both the XCM messages and `UMPSignal` messages. An empty message (empty `Vec<u8>`) is used to mark the end XCM messages and the start of `UMPSignal` messages. | ||
|
|
||
| This way of representing the new messages has been chosen over introducing an enum wrapper to minimize breaking changes of XCM message decoding in tools like Subscan for example. |
There was a problem hiding this comment.
It will still break for them. They will not be able to decode the rest.
|
|
||
| At present time misbehaving collator nodes, or anyone who has acquired a valid collation can prevent a parachain from effecitvely using elastic scaling by providing the same collation to all backing groups assigned to the parachain. This happens before the next parachain block is authored and will prevent the chain of candidates to be formed, reducing the throughput of the parachain to a single core. | ||
|
|
||
| The session index of candidates is important for the disputes protocol as it is used to lookup validator keys and check dispute vote signatures. By adding a `SessionIndex` in the `CandidateDescriptor`, validators no longer have to trust the `Sessionindex` provided by the validator raising a dispute. It can happen that the dispute concerns a relay chain block not yet imported by a validator. In this case validators can safely assume the session index refers to the session the candidate has appeared in, otherwise the chain would have rejected candidate. |
There was a problem hiding this comment.
Yeah and the motivations reads itself a little bit bumpy. Just a little introduction on that you try to solve two issues whatever.
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
There was a problem hiding this comment.
I'm fine with the general structure of the RFC. I'm only requesting some more clarifications, especially around the offset/selector. Thank you for the work!
I also want to see that the UMPSignal is optional. Maybe we will never need, but there is also no harm in having it, especially as for single core chains there is no downside in omitting it.
| the start of `UMPSignal` messages. | ||
|
|
||
| This way of representing the new messages has been chosen over introducing an enum wrapper to | ||
| minimize breaking changes of XCM message decoding in tools like Subscan for example. |
There was a problem hiding this comment.
I don't think this is true. They will probably just skip the empty message and choke on the unknown umpsignal. So, they will require some way to handle this any way.
There was a problem hiding this comment.
This doesn't say things don't break, only that the impact of breakage is smaller compared to the alternative.
|
|
||
| ## Drawbacks | ||
|
|
||
| The only drawback is that further additions to the descriptor are limited to the amount of |
There was a problem hiding this comment.
Not really. As long as the start of the descriptor until the version field stays the same, we can implement some custom decoder.
There was a problem hiding this comment.
Yes, this is true, but the RFC assumes all future changes we make to the descriptor are backward compatible to not break other parts of the stack.
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
Signed-off-by: Andrei Sandu <[email protected]>
|
/rfc propose |
|
Hey @bkchr, here is a link you can use to create the referendum aiming to approve this RFC number 0103. Instructions
It is based on commit hash 01719f7b8e74839056a3285e722658823743c81f. The proposed remark text is: |
|
Voting for this referenda is ongoing. Vote for it here |
|
PR can be merged. Write the following command to trigger the bot
|
|
/rfc process 0xdcbb1a70e58737edfbfdb0b866cf977bebafcea08479808340ae03e492922b3e |
|
The on-chain referendum has approved the RFC. |
Partially implements #5048 - adds a core selection runtime API to cumulus and a generic way of configuring it for a parachain - modifies the slot based collator to utilise the claim queue and the generic core selection What's left to be implemented (in a follow-up PR): - add the UMP signal for core selection into the parachain-system pallet View the RFC for more context: polkadot-fellows/RFCs#103 --------- Co-authored-by: command-bot <>
anaelleltd
added
Implementing
Following the discussion on #92, this is a proposal to introduce the required core index commitments to make elastic scaling work securely with open collator sets.