Genesis parameters structure ("genesis file") [WIP]

[lamafab]

Preview: https://gist.github.com/lamafab/af5ff9f211599350ce96118e435618a9
(PSP Number can be adjusted, of course)

This sets a standard for the JSON structure (Kusama example) on how the genesis parameters including relevant data and metadata (which are not part of the state storage) should be saved and distributed.

Please note the TODO section:

• Why is the client side id mandatory while protocolId is not?
• Shouldn't id and protocolId be the same field/value?
• In the (kusama) JSON file, the property field has certain key/value pairs, but the Substrate code accepts anything. This behaviour makes sense in terms of the genesis parameters, since those values just get inserted into the state storage. But how can property be useful if those values are not predefined?
• What does the second object in "genesis" > "raw" do? See: "raw": [{},{}]. It's just empty.
• Since Polkadot has not been released yet, why is "consensusEngine" a legacy field?
• Those telemetry log levels are implementation specific and probably do not need to be standardized. Should the log levels be part of the genesis file? Should telemetry itself be part of the genesis file? If yes, then the behavior of the telemetry endpoint/interfaces must probably be specced, too.

pub const SUBSTRATE_DEBUG: &str = "9";
pub const SUBSTRATE_INFO: &str = "0";

pub const CONSENSUS_TRACE: &str = "9";
pub const CONSENSUS_DEBUG: &str = "5";
pub const CONSENSUS_WARN: &str = "4";
pub const CONSENSUS_INFO: &str = "1";

I passed the questions over to the Parity guys, ongoing process...

[FlorianFranzen]

With the introduction of code_substitute in #3093 getting a proper specification published should be expedited, as this is now necessary information to sync Polkadot.

[lamafab]

This is implementation specific and does not fall into the scope of a PSP.