Alpha TestNet Release - March 31,2020

Reference

Milestones

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.

The launch of the test net needs to demonstrate the viability of the CasperLabs protocol and blockchain to investors, dApp developers and validators.

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. 

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

• 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

Objectives:

• Demonstrate Progress to investors and the broader community

• Practice engagement with the validator community

• Learn & prepare a pipeline for the Beta Testnet launch

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 could take place via GitHub commits and pull requests.

• Genesis block will be part of the official package for launch.

• Date and time of launch will need to be determined.

 Details on the process

• Prospective Genesis validators may participate in the validator sale to purchase their stake.  If their stake is unknown, a stake amount will be assigned to them depending on the order in which they join the TestNet program.

• Prior to the launch of test net - the validators should participate in the Weekly workshops, so they can be trained in the operation of the node.

• What Validators need to do: 

  • Add their public key to the accounts.csv file, with their bond amounts, 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 and ship logs for the purposes of monitoring the test net.

  • Expose an endpoint for accepting deployments

  • Configure each validator node in the load balancer (provided by CL) 

Size of the Network

We want a minimum of 5 nodes and a maximum of 10 nodes to participate in TestNet genesis.

Node System Specifications

Estimates based on this data.

• 8 Core / 32 GB RAM / 100GB Disk

• Network: 10 MBPs Upload /Download minimum.

Stability of the Network

• This is an alpha TestNet, there is no SLA for re-starting the network.

  • Contracts will need to be re-deployed with a code refresh, and as needed in the event an issue is found and an emergency patch is required.

• The network should stay up for a minimum of 7 days with base transactional load of 15 token transfers /second.

• The Rust contract API should be stable.  This means that contract authors can write their smart contracts in Rust with some degree of confidence.

• The Assemblyscript contract API is expected to need some updates, as it is new.

Updating the Network

• We will update the network when we need to deploy a new version of the software

• We will re-start the network with a new chain name.  Validators will have to update their nodes with the latest software, obtain the new chain name and re-join the network.

During and After an Update:

• Test the process of communicating an update

• Observe how long it takes to update the network

• Practice the Genesis process

Consensus Features

Honest Highway consensus with the components required for liveness.  No validator set rotation.  The protocol will build a blockchain of transactions and a DAG of justification messages.

Includes:

1. Leaders

2. Rounds - fixed but configurable

3. Lanes

4. Ballots

5. Eras

6. Multiple Eras & Switch blocks

7. Skip List

8. Optimized Fork choice rule validation 

9. Finalization stream (k=1) and fixed FTT (1/3rd)

10. Separate Clarity Instance

11. Separate Public Grafana instance

12. Each validator will have their own deploy endpoint.

Excludes:

• Equivocation detection

• Slashing & throttling

• Adjustable round lengths

• Block Merging

• Rewards & Seignorage

• Social Consensus API

• Protocol Upgrades

• Base block support

• Merkle Tree Based Justifications

• Bonding / Unbonding

• Gossip deploys to the leader - Excluded. Deploys will remain in buffer until leader slot (we will need to consider if a node has multiple deployments with large wasm bytecode - that this will likely have to stay in the buffer for some time.

Execution Engine Features

• Initial Typescript support

• Support for Secure Enclave (multiple Key types)

• Host side system contracts & payment code

DApp Developer features

• Rust SDK

• Initial Support for Typescript

Metric for tracking success (Internal only)

• Count of Validator nodes

  • Validator Node uptime (level of participation in the network)

• Count of deployments

• Count of installations (Define contracts)

• Number of Blocks

• Gas processed / 5 seconds

• Total Gas processed

What is special about this release?

This marks the public Alpha TestNet milestone

This network is backed by infrastructure provided by the Genesis validators

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

Validators can only join the network when it is re-started because Validator Set rotation isn't in place as yet.

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

Developers could interact with the DevNet

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

Developers can work with the CasperLabs TestNet, and submit deployments to prospective genesis validators.

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

• Performance of Consensus

• Node

  • Max deploys / second supported

    • What is the UX when a deploy exceeds the max #

  • Deploy Gossiping / UX of sending a deploy to a non-leader node. 

    • Incentives around deploy gossiping?

  • Stability of finalization

What do we want to learn?

1. How many validators participate in Genesis?

   1. Do we have interest from people not involved in the private sale?

   2. Do the validators spin up hardware for the network?

   3. Where are these servers located?

2. How easy is it to spin up a node and participate?

3. How does the upgrade process work?  
   
   

   1. We are not certain that we need to test this during this testnet phase.

4. Are the monitoring tools for Node operators good?  Are they easy to use?

5. How does the preliminary portions of the consensus protocol perform?

6. Are there any material UX changes for the end user with this new protocol?

7. How many dApp's engage with the platform.

8. How many contracts are deployed to the platform?

9. What is the resource utilization of nodes?  How do different configurations perform?

   1. Collect feedback on the performance of different configurations.

10. Operations team has to learn how to monitor the health of the network.

11. Attempt to load test the network - learn how the network performs under load.

12. Engagement with Validators and create community.

    1. Perform testing sessions with the validator set against the network.

What is the contribution to Validators? Where is their value?

1. Observe progress on the project.  Hopefully get confidence in the system.

2. Interact with the platform and become familiar with the software.

3. Earn token by participating in the network.

What do we need to not do?

1. Talk about economic security in this network, there won't be any.

2. We don't want a ton of validators. We need to limit to 10.

3. Talk about new validators bonding at any time, they won't be able to at this milestone.  The validators will need to be bonded at launch.

Rewards for Participation:

We need to kick off a virtuous cycle of participation.  The more participation we have, the more viable the project is.  We need to announce ~ 6 weeks in advance.

There will be 3 rounds of games - each round is 4 weeks.

1. Uptime & blocks validated/produced - data would be obtained from Grafana.  We would need to grab the prometheus logs and store them securely.  Each validator ID would be mapped.

2. Game of stakes - We need to figure out what kind of games we want to support. @Ashok Ranadive (Unlicensed) You can add them here.

   1. Best overall validator (Most engaged, best uptime)

   2. Most Live (Signs the most blocks overall)

   3. First 5 to sign each block (Consistently one of the first 5 validators to sign Genesis)

   4. Innovative attacks 

3. Developer Awards:

   1. Most transactions that use the least storage (Reward the use of stored contracts rather than sending wasm)

4. Bug bounties

   1. Paid out via criticality

How will Validators Co-ordinate (if at all)

1. Make announcements - changes on Genesis processes, rounds, games, status updates, etc

   1. Confluence page in Release

   2. Link page to Discord in Validator channel

2. Obtain feedback

   1. Jira Service Desk (Medha to configure)

3. Cadence for Weekly workshops

4. Decentralize relaunching of the TestNet.

Where will Transactions come from?

• Demo applications 

  • Voting dApp for Hackathons

  • Funding of accounts in CLarity 

Who are we Targeting?

• Investors (token purchasers)

• Application developers

• Prospective validators

Why should they care?

(write a reverse press article about the network - what do we want it to say?)

https://docs.google.com/document/d/1KS3Yle4fOeSsoCSva8_JGeIkEAkpf4b5ebq5WhyRlx4/edit#

Work in this Release