Collator Executor Environment Parameters

[eskimor]

We should provide an additional API to be used by collators for querying (a subset) of our execution environment parameters.

Collators are way slower to upgrade than validators. Hence if we blindly expose everything we need to be very careful (and slow) with the introduction of new parameters. At the same time there are quite a few parameters which are irrelevant or at least not strictly required for collators.

With a separate API, we are able to iterate fast on new parameters that are irrelevant to collators, by not returning those newly not (yet) understood variants to collators, while at the same time utilize them fully on validators already.

Once collators have upgraded their nodes and are up2date we can return those parameters to them and they will find validators already prepared.

[eskimor]

Once we have this API, we can make collators honor the execution environment as exposed to them to ensure they are not producing collations which would be seen as invalid by validators.

[bkchr]

We should provide an additional API to be used by collators for querying (a subset) of our execution environment parameters.

IMO we should make the api return values that can detect unknown variants and ignore them. There should be no extra api for collators.

Collators are way slower to upgrade than validators.

This also only true currently, because there is only one fully functional Polkadot node implementation. In a more decentralized future, you can also not do these changes and expect everybody to upgrade in x days. Currently this is the case because we are still early, but I would expect that this gets slower.

[eskimor]

IMO we should make the api return values that can detect unknown variants and ignore them. There should be no extra api for collators.

Agreed. This should work as well. Parameters are a Vec, we could just ignore elements we cannot decode.

This also only true currently, because there is only one fully functional Polkadot node implementation. In a more decentralized future, you can also not do these changes and expect everybody to upgrade in x days. Currently this is the case because we are still early, but I would expect that this gets slower.

True, but at that point in time we are very likely also fine with moving slower ;-) Also the addition of new variants becomes more unlikely the more we matured.

[bkchr]

Agreed. This should work as well. Parameters are a Vec, we could just ignore elements we cannot decode.

The current api doesn't support this. There was this discussion around the types and "controlled decode failing", but we don't have implemented them this way. We would need to prefix every variant with its length to skip it, if decoding fails.