...
Now we can analyze each parameter with several criterias:
| Parameter | Possible Values | Should it be synchronized between Peers | Should it pass consensus | Can it be applied without restart | Will it affect clients |
|---|---|---|---|---|---|
| Key Pair | Valid Key Hash | No | No | Yes | Yes |
| Kura Mode | strict/fast | No | No | Yes | No |
| Block Store Path | Valid Unix path | No | No | With additional development | No |
| Peer Id | Valid URL + Key Hash | Yes (Other Peers should update old Id to the new one) | No | With additional development | Yes |
| List of Trusted Peers | Valid URL + Key Hash | Yes | Yes | Yes | No |
| Block Time | unsigned 128 bit integer | Yes | Yes | Yes | No |
| Maximum amount of Faulty Peers | unsigned 32 bit integer | Yes | Yes | Yes | No |
| Commit Time | unsigned 128 bit integer | Yes | Yes | Yes | No |
| Transaction Receipt Time | unsigned 128 bit integer | Yes | Yes | Yes | No |
| Client-side URL | Valid URL | No | No | Yes | Yes |
| Peer-side URL | Valid URL | Yes | No | Yes | No |
| Maintenance URL | Valid URL | No | No | Yes | Yes |
| Gossip Period | unsigned 128 bit integer | Yes | Yes | Yes | No |
| Batch Size | unsigned 32 bit integer | Yes? | Yes | Yes | No |
| Maximum Transactions Block | unsigned 32 bit integer | Yes? | Yes | Yes | No |
| Transaction Time to Live | unsigned 128 bit integer | Yes? | Yes | Yes | No |
| Maximum Logging Level | TRACE/INFO/DEBUG/WARN/ERROR | No | No | Yes | No |
| Terminal Color Enabled | true/false | No | No | Yes | No |
| Date Time Format | String | No | No | Yes | No |
Solution
So solution may be to use Iroha Special Instructions for management consensus dependent parameters like "Gossip Period", storing set of parameters under a Peer entity in World State View and propagating these parameters and their updates into subsystems via Iroha channels.
Parameters that can be managed without consensus can avoid usage of Iroha Special Instructions and implemented separately as API for system administrators.
Decisions
- Split parameters into consensus dependent and maintenance related
- Use Iroha Special Instructions for consensus related
- Put management of other parameters under Maintenance Endpoint
- Implement "hot reload" mechanisms in Iroha subsystems
Alternatives
- Use Iroha Special Instructions for all parameters - brings additional set of instructions to maintain, increases load on blocks store and blocks synchronization, won't guarantee non-functional requirements from system administrators perspective (each update will take time needed to finalize block)
- Use Maintenance Endpoint for all parameters - brings additional complexity in terms of parameters synchronization and open security related issues (who can change "Batch Size" on all Peers?)
- Do not synchronize any parameters between Peers - may be a good option
Concerns
Lack of real use cases and strong opinions on topic from potential users gave no ability to make a really welcoming decision.
Assumptions
Maintenance Endpoint will be "unstable" during 2.0 release.
Risks
- Solution will not cover all needs `[4;6]`
- Requirements will be simpler than expected `[3;3]`
- "Hot reload" mechanisms will require a lot of work `[6;7]`
Additional Information
