-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Include PVF execution and preparation timeouts into executor environment parameters #6793
Comments
We do have three timeouts which relate to each other:
Timeout for backers has to be larger than the one for collators to make it very unlikely for them to reject a valid block. Timeout for approval checkers needs to be way larger than the timeout for backing to avoid false disputes. We currently have 6x backing timeout here. The latter is more critical than the previous one, so a smaller factor between timeout for collators to timeout for backers can be justified. Right now it is 4x. |
Timeouts for collators live in Cumulus in practice now, and IMO that is the right place for them: either Cumulus or whatever other collation binary may be created. It's the responsibility of the collators to not create anything that backers will reject, while the backers will reject according to rules set on the relay chain. It makes the most sense for Cumulus to make use of the backing timeout and adjust based on the specifics of the parachain's block authoring mechanism. |
@s0me0ne-unkn0wn let's prioritize this a bit. For fully utilizing async backing benefits we need that to be configurable, so we can bump it up in a secure way. Given that we don't have time disputes yet, we could cowboy it, but better if we had a proper configuration in place. |
As @rphmeier we don't care about the collator timeout, but for #paritytech/cumulus/2252 we will need that dedicated collator API for fetching execution environment parameters. |
Yeah, I also think it should be implemented asap. As for executor environments in collators, did you see this one? #6497 (comment) |
Thanks - No I did not. I realized this was mentioning PVFs instead of PoVs, which is what I was concerned about. |
PVF timeouts are crucial for determining candidate validity, and changing a timeout throughout the network may retrospectively affect the validity of already included candidates. Thus, such changes must be effective per session, not per network. Execution environment parameters are a natural place to keep track of timeout changes for the dispute period.
The text was updated successfully, but these errors were encountered: