Purpose

The Testnet Committee’s purpose is to improve and expand the reach of Secret Network by fostering an optimised, fast and reliable space to enable developers to easily test their contracts in a production-like environment.

Responsibilities

The Committee will hold itself to the following core responsibilities:

  1. Run and maintain stable testnet validators to enable new developers to join the network more easily, without having to deal with the pains of having to find a reliable testnet node.

  2. Maintain documentation.

The following information must be easily accessible and maintained for the current public testnet, and possibly any betanet config where validators can test network upgrades before applying to mainnet;

  1. Script to run your own public testnet, using docker-compose to start the secret node, as well as an nginx server directing traffic from the internet to the correct container (initially only the node and faucet, in future there may be more services like stats or explorer) Letsencrypt will create the self-signed certs. This will allow devs collaborating to test shared contracts or bleeding edge features of an upcoming release in their own environment, without the risk of this committee introducing new bugs or downtime for upgrades while they’re relying on features already released in secret.

This script can also be used to spin up a staging env on demand, once the release is nearer completion, so as not to incur year-round costs for a short term need.

  1. Test upcoming upgrades, then upgrade the main public testnet so that other testnet validators can confidently do so too. If there are any issues with the upgrade, the public testnet is unaffected.
  2. Monitoring, including a webpage showing the current status of any public endpoints.
  3. Keep 3rd parties such as explorers Secret Nodes and Ping Pub informed of any changes, such as chain-id and endpoints
  4. Deploy and maintain testnet faucet, under faucet.pulsar.scrttestnet.com

Maintain Stable Testnet Validators

The testnet committee leader will run and maintain 4 stable testnet validators, in 3 or more datacenters.

These 4 validators will be supported by 4 additional backup nodes.

During normal usage, the backup nodes will just be used to load balance requests to the public api endpoint, and also used for a quick validator key migration if one of the 4 committee validators go down. Then when new binaries need to be tested, they will be used to run the beta testnet and taken off load balancing duties for those few weeks. (So the fork genesis would just have the 4 committee validators and the rest jailed, and those 4 validator keys can get put on the nodes being used for betanet)