Session length and sessions per era is no longer configurable

[xlc]

Previously (before #2802) session length and sessions per era are configurable in chain_spec and can be dynamically changed using sudo call.

It doesn't seems possible now as the value are hardcoded in runtime/src/lib.rs file.

This makes e2e tests harder as we can't easily create different chains with different block time / session length / era length.

[bkchr]

It maybe is "harder" to generate different chains with the new approach, but it is clearly much faster and you don't have to access the storage.

[pepyakin]

Related #2400, #2883

I remember raising a question (but I don't remember getting an answer...) about changing these parameters of such parameters for the runtime that hardcodes these parameters. Won't it be harder to reach consensus on such an upgrade?

Another question would be, is it possible to have a special feature to compile these parameters as in storage? Would it help @xlc for you use-case?

[bkchr]

Most of the parameters could not be changed in the runtime. If you would implemented support for changing these parameters, it would have been a root call. So, changing a parameter in storage would be a root call and issuing a runtime update is a root call.
I don't see the difference in reaching consensus :D

For @xlc's use case we maybe need to provide some kind of tool that generates the code.

[xlc]

One possibility is have two config module, one uses parameter_type, and another one uses storage. Then people can pick which module to use for their runtime.
I would like to keep things flexible at least in development testnet.

Another thing is it is trivial to audit a set_session_length proposal but much harder to audit a runtime upgrade. Even with reproducible build, not everyone can understand the source code change.

[kianenigma]

One possibility is have two config module, one uses parameter_type, and another one uses storage. Then people can pick which module to use for their runtime.
I would like to keep things flexible at least in development testnet.

Can't deny that this is nice to have, but @bkchr's fact holds that both are root.

And regarding the main issue concept (session length), note that this is a radical change that needed to be applied for compatibility with srml/babe. I am not aware of all the details but it needed a fixed bound on the minimum session length.

[xlc]

This issue maybe should be breakdown into two parts:

• Ability to specify the config values at chain setup time (via genesis config or code generation or something else). This allow people to create a new chain with different configs fast and easy. We need this feature.
• Ability to modify the config values with a sudo call. This may no longer be possible for some values due to babe restriction which is fine. One benefit to modify config value via set_value sudo call is it is more lightweight (smaller tx size), easier to audit, and can be automated. (I don't think have automation tool to modify source code and recompile and submit transaction is a good idea). Less a requirement for us but still good to have.

[gui1117]

• Ability to specify the config values at chain setup time: should be doable by including values in runtime in a way.

• Ability to modify the config values with a sudo call: that implies having those values in storage isn't it ? that means we loose the optimisation of having them const. We only have for now a single storage.

[bkchr]

* Ability to specify the config values at chain setup time: should be doable by including values in runtime in a way.

How do you want to instantiate a constant from the chain spec? We can solve this with some traits, but this still does not make it configurable from JSON.
@xlc are hardcoded chainspecs okay?

[xlc]

Previously I can define multiple chains with different block time in chainspec, it will be good if we can do the same thing as well. So I can do something like --chain=dev for 2s testnet and --chain=staging for 6s testnet.
Bonus point if it can be made code generator friendly. So that we can just use something like Handlebars to generate the chainspec file from JSON.

[burdges]

I posted some notes on constraints from polkadot in paritytech/polkadot#47 (comment) I'll note here that BABE can have either one or two meaningful epoch lengths and that GRANDPA might not have any meaningful epoch length, although maybe some concerns I'm not thinking about this morning impose an epoch length on GRANDPA.