| Page Properties |
|---|
| Target release | |
|---|
| Epic | |
|---|
| Document status | |
|---|
| Document owner | |
|---|
| Designer | |
|---|
| Developers | |
|---|
| QA | |
|---|
|
Goals
- Release upgrades to the RChain platform
...
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 shard will have its own block DAG
- Within each namespaceshard, 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.
- Not all validators will accept an update. If that is the case, the network will fork.
Requirements
| # | Title | User Story | Importance | Notes |
|---|
| 1 |
Upgrade effective point node operator, I must know when an upgrade is going to take effect on the systemMust Have | - See assumptions - block height cannot be used as implemented in current blockchain systems.
| 2| validator, I want to control whether I accept an update or not | Must Have | - Each shard has the option to accept an update or not. Validators that don't want to take on the update, have an option to unbond from their current shard and bond to another shard.
|
| 2 | Shard version number? | As a validator, I want to select a shard that is running a specific version of the RChain protocol | Must Have | - Each shard publishes the version of the protocol it is running in the block information.
|
| 3 | Consensus on updates? | As a validator, I would like to apply the update as the same time as the other validators in my shard, so that our shard doesn't have a fork | Nice to Have | - It would be really smooth if the validator set could come to consensus on when the update takes effect. This way an entire shard could update at once.
|
User interaction and design
...
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|
| When will a feature take effect? | |
|
|
Not Doing