Carthage bootstrapping plan

[bedeho]

Background

We are launching Carthage which will be a new chain, with a genesis block and launch process as close as possible to the mainnet launch. This issue defines how we bootstrap initial state after the genesis block.

Proposal

The genesis block will initially only hold accounts, most of which will be subject to vesting schedules that prohibit doing transfers. During the bootstrapping period of the rollout, no user can issue extrinsics - they are automatically filtered out, however there will be a designated sudo account which can, and it will create the initial set of members and founding members. A new type of extrinsic is being introduced to enable the latter.

The set of actual members will be the same as is found on the Rhodes network, from the snapshot block. Members should be segmented into two groups, founding member and non-founding member, and they should be created in Carthage bootstrapping using extrinsics make_founding_member and buy_membership respectively. The distinction between the two can be obtained based on the CRM. The root and controller accounts for the former is reported by the user when selecting accounts, and if they are not responsive, we have to pick alternatives. For the latter we just use accounts used in Rhodes.

Importantly, we are not bootstrapping anything else, for example

• proposals or proposal discussions
• working group roles
• forum categories, threads and posts
• channels, videos, NFTs, comments or reactions
• bounties

┆Issue is synchronized with this Asana task by Unito

[bedeho]

wip: data centers, what are the boot nodes?, comissions, extrinsics, stake set, number, etc. reference assumption about validator slots available.

Replace this comment later.

[mnaamani]

We will deploy with an initial set of 9 validators, validator count = 9 so all slots will be filled in initial phase (PoA).
The validators will bond 4x the minimum validator bond amount. The final minimum validator bond proposed in #4300 (comment)

In PoA phase sudo will increase the validator count to 13 before switching to PoS. (Validator count will be increased gradually as necessary).

The validators will be spread across three cloud providers, covering 3 geographic locations, Us-east, US-west, and Europe.

3 Non-Validator full (non-archival) nodes will also be deployed as "boot-nodes", one in each geographic location stated above. These will be configured in the chainspec.json file for the network.

2 high performance nodes will be deployed in a European data center, behind a load balancer to serve as a public RPC endpoint. (rpc.joystream.org)

2 query-node instances will be deployed in separate locations, one production and one standby, (query.joystream.org) using the public RPC endpoint. No load balancer will be used to keep configuration simple. Both nodes will share same SSL cert, and DNS record will be updated to point to the production node.

[traumschule]

done :)