Goals
- Release upgrades to the RChain platform
Background and strategic fit
There needs to be a way that platform updates can be released in such a way that node operators know when the upgrade takes effect. In non-shared blockchain implementations, this is handled by block height. However, RChain aims to be sharded by namepsace, which means that the block height mechanism probably won't work.
Assumptions
- Each namespace will have its own block DAG
- Within each namespace, the block DAG will add new blocks at different rates.
- Updates need to be released and installed on the node well in advance of the date when the update takes effect. Particularly for changes to the protocol, where a hard fork is likely.
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Upgrade effective point | As a node operator, I must know when an upgrade is going to take effect on the system | Must Have |
|
| 2 |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| When will a feature take effect? | |