TestNet (Validator) Release Plan

Release summary

Simple overview

Launch of the CasperLabs Testnet  will involve validators launching the network.  CasperLabs will participate by provisioning a bootstrap node, the node software, documentation and co-ordination activities to launch the network.  The desire for validator engagement is that the process be as decentralized as possible.

Validators will download and install the node software on the hardware they have provisioned for the TestNet.  Each validator will have already provided their public key via Github pull requests into the accounts.csv file for inclusion in the genesis block.  Ideally, the validators participating in test net will be a core subset of the main net validator set . Validators will start up their nodes with the data required to generate the genesis block. If they have done so correctly, they will peer up with each other and apply 'votes' to the Genesis block. 

TestNet is a step in the maturation process of the CL system. The prior step is DevNet and the subsequent step is MainNet.

• MainNet is separate from TestNet.  (The TestNet will have a faucet, MainNet will not)
• TestNet will continue to receive upgrades - think 'public beta' system - that persists - all updates hit TestNet first.
• Validators can come and go from TestNet, nodes provisioned by CL/ADAPtive will persist.
• It is expected that the TestNet validators will participate in MainNet Genesis
• Outside parties can participate in the TestNet with their own compute resources

Demonstration of TestNet

With the launch of the test net, we will demonstrate the functionality of the system in the following manner.  We will perform a series of token transfer operations via an automated test.  The token transfer operation will have 2 parts.  Setting up / creation &  funding of the accounts, and then transfer of the token from one set of accounts to another.  As the harness <The internal tooling we are using is Gatling, which is used for performance tests> sends the deployments to the system, metrics can be observed in the Grafana dashboard / and the Casper Explorer of the network processing the transactions.  The transactions will be token transfer transactions.  The first round of transactions will include the creation of the accounts ( the accounts will not exist on the system) and the second round will transfer token to the already existing accounts. Again, as the harness sends the transactions, processing of the transactions is monitored on the Grafana dashboard and Casper Explorer, and it is possible to observe the network process the transfers.  Once complete, we share the following data:

• Total number of transactions processed
• Time to finalization / transaction
• Safety of the transactions

On Decentralization:

The creation of the genesis block will require some co-ordination on the following areas:

• Addition of the genesis validator public keys into the process that generates the genesis block→ creation of accounts.csv
  • This should take place via GitHub commits.
• Genesis block will be part of the official package for launch.
• Date and time of launch

Process for launch

• Validators add their public keys for their validator id and bonded wallet to a file in a github repository. This file creates the list of genesis validators & associated stake amounts.
• Validators read a document on how to join the testnet, which will include some bootstrap addresses, and the software version - accessible via GitHub.

Details on the process

• Prospective Genesis validators must participate in the validator sale to purchase their stake.
• Prior to the launch of test net - the validators will need to work with the program manager to practice the launch of test net.  
  • Add their public key to the accounts.csv file, with their bond amounts, used to create the Genesis block.
  • Include their bond amounts and wallet addresses for this bond(this needs to be determined out of protocol)
  • Provision the necessary hardware 
  • Be on a Discord channel to co-ordinate testing of the software and practice launching the network.
  • Install the node software & be familiar with how the node software runs (CL should publish a Node Operator's Guide)
  • Expose a monitoring endpoint / logs for the purposes of monitoring the test net.
  • Expose an endpoint for accepting deployments

Size of the Network

We want a minimum of 50 nodes and a maximum of 100 nodes to participate in TestNet genesis.

Performance of the Network

Given the size of the network, 1000 Token transfer transactions / second is desirable.

Consensus Requirements

1. Parametrizable message overhead and latency to finalization , for n validators, so that overhead* latency to finality is O(n)
   1. Allowing O(1) overhead and O(n) latency to finality
   2. Allowing the optimistic execution latency to also be O(1)
2. Latest-message-ish, Plurality driven, stake weighted Fork choice rule
3. Has provable liveness (with or without epoch/leaders)
4. Finalizes transactions with the safety properties of CBC Casper
5. Fault tolerance threshold is an out of protocol parameter choice for deployers
6. Economic security
   1. The protocol is the market equilibrium: Slashing for safety and liveness faults
   2. Participation is rational: Incentives for good behavior
   3. The bonding mechanism can bound the validator count
7. Over 50 validators at launch to create genesis block

Node Features

Execution Engine Features

• State queries from within smart contracts
• Commutativity check 
• Threading model for high performance

DApp Developer features

• Library of Code snippets 
• Casperlabs scala client
• Initial Support for Typescript

Metric for tracking success (Internal only)

• Features added to help DApp developers
  • Account creation tools 
  • Tools to help with deployments?
• Features added to help node operators
  • Total gas processed metric
  • Storage metrics for DAG store
  • Single Docker image
• Number of things we have learned about the performance of the node as a result of the work in this release?
  • Let's fill this in by the time we ship. 
• Gas processed / 5 seconds

Technical overview

What is special about this release?

Are we doing something differently? If so, why are we doing it this way?

Before these features were available, what were developers able to do?

After these features launch, what will developers be able (and not able) to do?

Developers will be able to author simple smart contracts in RUST and run these contracts on the node.  Developers cannot create blocks or interact with the blockchain state. 

Description of release packaging

Release packaging will include:

Where do developers go to learn more and get started?

At release, links to installation packages and relevant documentation is available at 

Where will bugs be filed?

Report a bug

Where do developers go for support? What is the SLA? Who is on point?

NA

Open areas of Risk

• Protocol Liveness
  • Synchrony condition 
  • validator reward structured to encourage liveness?
• Economics 
  • Burn stake? (problem with nascent network)
    • Stake burning starts 12 months after the network is launched.
  • Fee schedule
  • Economics backlog.
• Protocol specifics
  • Finality oracle & proof
  • Slashing conditions
• Accounts & Secure Enclave support
• Block Merging
  • Commutative property and algebras
  • Performance of Block Merging
  • Does merging work with consensus?  Is it efficient?
• Global State/Accounts and Upgrades
  • Rework Global and Local State for upgrades
• Performance of EE 
  • threading model
  • wasmi
  • IPC
• Booting the network
  • Validator public keys that launch the network
  • Hash of the genesis block
• Economics
• Node
  • Max deploys / second supported
    • What is the UX when a deploy exceeds the max #
    • Do we need deploy queues