Runtime & Node Parameter Model

[bedeho]

Background

Parameters

By parameter we mean either

• a constant (but we are dropping the majority of those)
• a stored value that must have some non-empty/null state when the system begins

which is read, and thus impacts, some business logic.

Complexity of Selecting Values

We must select values for such parameters both at launch, but also while the system operates through the proposal system. The challenge in setting these values in both contexts is caused by three distinct concerns

1. Currently, and increasingly, there is a very large number of parameters impacting the technical, economic and social dimensions of the operation of the Joystream blockchain.
2. There are also complex interdependencies between parameters which are easily overlooked.
3. The ideal values depend on the desired tradeoff in use of various system and community resources, hence a reasonably precise understanding is required of this ideal tradeoff.

Modelling

We need a model which allows the community to reason about how changes in parameter values will impact the behavior and constraints of the system. Such a model must be

• easy to maintain and update as the system changes
• easy to operate, even for less technically savy users
• easy to share the result of analysis exercises with third parties

The primary context in which it would be used would be at launch and in advance of proposals or runtime upgrades to deal with new features or shifting constraints and objectives.

Proposal

This is WIP ideas, as this is a complex exercise.

Develop a spreadsheet model which separates exogenous inputs from endogenous modeling outputs. The inputs would be things like

• $USD Market cap of $JOY
• Issuance of base unit
• Desired block time
• Max block size
• Max block weight
• Weight profiles of all extrinsics and on_finalized methods
• A detailed utilization model for each part of the system (council, wgs, content directory, storage, etc.) which allows us to capture assumption about the level and growth in utilization. There will by implication be an association between such utilization values and invocations of various extrinsics and on_finalized.

The outputs would be values for all parameters in the system not listed among the inputs, so things like

• weight fee
• length fee
• default invitation balance
• etc.

and also whether the input values are actually a feasible set of requirements.

Automation

Importantly, the ideal way this would work if it was somehow possible to just get exported values for all extrinsics and on_finalize calls in the runtime into some format that could just be pasted into some raw input sheet of the spreadsheet, that way its quite low effort to maintain over time as weights change. Even this may not be ideal, as some extrinsics perhaps disappear, and then you start having problems correctly interpreting the input sheet in a stable way. Anyway, better ideas are needed.

Resources

• Olympia Runtime Params #3451 (comment)
• Storage & Bandwidth System Review #2793
• Document critical state bloat parameters #3505
• Add weight-to-fee analysis notebook #2107
• Update fee analysis readme #2353

┆Issue is synchronized with this Asana task by Unito