On-chain shard configuration storage.

Motivation

1. To allow seamless experience for new node joining the shard. Casper protocol has variables that all nodes in a shard have to obey, otherwise peers can slash each other. At the moment some of them are defined on node startup with CLI option/config file. The most obvious one is --max-number-if-parents. These parameters should be on chain, so node operator has no option aside from following on-chain configuration.

2. To increase decentralisation by extracting shard level variables from the scope of the core protocol. Core protocol for RChain network is a set of rules all nodes in the network have to obey and is governed by RChain Cooperative. But there are variables that each shard free/can/have-to to decide on. Core protocol contracts (e.g. PoS) should only reference shard configuration.

3. To give ability for shard variables to be changed with multisig. Each shard can have its own governance process for shard level variables, from social consensus to on-chain stake weighted voting. Multisig covers all cases.

4. To prepare for future sharding implementation. All shard level logic have to be abstracted from the core protocol.

Subject of this RCHIP

Concrete implementation of on-chan shard configuration
Modification of PoS contract (core protocol) to support on-chain shard configuration
Procedure for deploying shard configuration to shard root on mainnet
Procedure for updating core protocol on mainnet

Design

Current definition of core protocol: PoS contract
The following variables have to be extracted into shard configuration

Name	Definition
shardName	Name of a shard
faultToleranceThreshold	Number from [-10^8; 10^8]. Actual faultToleranceThreshold is this value divided by 10^8
maxNumberOfParents	Maximum number of parents allowed
maxParentDepth	Maximum depth of parent allowed (see https://github.com/rchain/rchain/pull/2816)
finalizationRate	Finalization will be triggered when (block-height % finalizationRate) = 0
synchronyConstraintThreshold	Node is allowed to create block only when % of stake in justification blocks is more then this percent of total stake in the shard
heightConstraintThreshold	(experimental) Node is allowed to create block only if last finalised block is behind tip no more then this value
deployLifespan	Validators will try to put deploy in a block only for next `deployLifespan` blocks. Enable protection from re-submitting duplicate deploys
casperVersion	Version of Casper that shard is running
configVersion	Version of this config
bondMaximum	Max bond amount allowed in the shard
bondMinimum	Min bond amount allowed in the shard
epochLength	Epoch length. On epoch change the following events happen: new validators bonding, validator rotation, rewards distribution. TBD, clarification is needed
quarantineLength	Quarantine length. TBD, clarification is needed

Shard configuration should be a rholang Map with the following keys and datatypes

{
    shardName: GString,
    faultToleranceThreshold: GInt,
    maxNumberOfParents: GInt,
    maxParentDepth: GInt,
    finalizationRate: GInt,
    synchronyConstraintThreshold: GString,
    heightConstraintThreshold: GInt,
    deployLifespan: GInt,
    casperVersion: GInt,
    configVersion: GInt,
    bondMinimum: GInt,
    bondMaximum: GInt,
    epochLength: GInt,
    quarantineLength: GInt
}

Values for shard configuration are decided at genesis block and can be changed by shard validators later.

Implementation

Shard config storage in rholang

/*
The table below describes the required computations and their dependencies

No. | Dependency | Computation method | Result
----+------------+--------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------
1.  |            | given              | sk = a9585a0687761139ab3587a4938fb5ab9fcba675c79fefba889859674046d4a5
2.  |            | given              | timestamp = ???
3.  |            | lastNonce          | nonce = 9223372036854775807
4.  | 1,         | secp256k1          | pk = 047b43d6548b72813b89ac1b9f9ca67624a8b372feedd71d4e2da036384a3e1236812227e524e6f237cde5f80dbb921cac12e6500791e9a9ed1254a745a816fe1f
5.  | 4, 2,      | genIds             | uname = ???
6.  | 3, 5,      | registry           | value = ???
7.  | 6,         | protobuf           | toSign = ???
8.  | 7, 1,      | secp256k1          | sig = ???
9.  | 4,         | registry           | uri = ???
----+------------+--------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------
*/
new shardConf, 
rs(`rho:registry:insertSigned:secp256k1`),
uriOut
in {
contract shardConf(@"get", returnCh) = {
returnCh!({
  "casperVersion": 1,
  "configVersion": 1,
  "shardName": "root",
  "parentShardId": "/",
  "faultToleranceThreshold": -100000000,
  "finalizationRate": 1,
  "maxNumberOfParents": 1,
  "maxParentDepth": 1,
  "synchronyConstraintThreshold": 99,
  "heightConstraintThreshold": 0,
  "deployLifespan": 50,
  "bondMinimum": 1,
  "bondMaximum": 9223372036854775807,
  "epochLength": 10000,
  "quarantineLength": 50000
})
} |
// Registers signed write-only shardConf contract bundle.
rs!(
"???".hexToBytes(),
(9223372036854775807, bundle+{*shardConf}),
"???".hexToBytes(),
*uriOut)
}

Rholang template (.rhox) example to get shard configuration. $$shardConfigContractAddress$$ is address of config map deployed to shard's Registry
```
new config, rl(`rho:registry:lookup`), shardConfCh in {
rl!($$shardConfigContractAddress$$, *shardConfCh) | 
shardConfCh!("get", config)
}
```
Description of the process of updating shard config. TBD

rchain / rchip-proposals