Delta Testnet Launch

Owned by Medha Parlikar
Last updated: Oct 19, 2020
5 min read

Reference

Document status

DRAFT

Release status

PLANNING

Related pages



Milestones

Start date

Apr 20, 2020 

Release

Oct 30, 2020  

Stakeholders

Name

Role

Reviewed?

@Mrinal Manohar

CEO

 

@Camilla McFarland (Unlicensed)

Marketing

 

Development team

Program manager

Project manager

Engineering Lead

SRE

Page owner

@Medha Parlikar

@Piotr Dziubecki

@Ed Hastings (Deactivated)

@Joe Sacher

Medha Parlikar



Release summary

Simple overview

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

The purpose of the Delta test net is to test the protocol, accelerate the customer feedback process & deepen the engagement with key validators from the Incentivized testnet program.

Validators will download and install the node software on the hardware they have provisioned for the TestNet.  There will be a set of ‘Founding Validators’ that must remain bonded for the duration of the testnet. Coordination activities for the Delta Testnet will be run through the Developer DAO.

 

The network should support the following:

  • Peering up of nodes and exchanging of messages

  • Processing of deploys & validation of blocks, which updates the global state

  •  

  • The network should stay up for at least 30 days initially.

 

  • Nodes that crash can re-join the network by restarting.

  •  

The Charlie TestNet is the first step in the maturation process of the CL Rust node. The subsequent step is the public Delta TestNet.

Objectives:

  • Flush out issues with consensus and communications

  • Deepen engagement with the validator community

  • Obtain feedback on the Rust node from validators

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

    • Validators will provide their keys for inclusion in accounts.csv

    • Validator accounts will be funded with a large number of motes, to enable transfer deploys.

    • The CasperLabs bootstrap node will hold 20% of the stake

    • CasperLabs will also run a single node in the network. This node will hold 20% of the stake in the network.

  • Date and time of launch will be communicated to validators in advance.

 Details on the process

  • This will be a closed network, comprising of approximately 5 - 10 validators.

  • The validators must have successfully participated in the Alpha testnet first & must be willing to invest time in testing the software.

  • They will be provided a set of instructions to configure and launch the network.

  • CasperLabs will provide a bootstrap node & a config.toml file that provides the connection information for this bootstrap node.

 

  • What Validators need to do: 

    • Provide their public key for inclusion in the accounts.csv file, with their bond amounts, to create the Genesis block.

    • 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 using the Node Operator's Guide

    • Expose a monitoring endpoint and ship logs for the purposes of monitoring the test net.

    • Create deploys to create accounts and transfer tokens.

Size of the Network

We want a minimum of 5 nodes and a maximum of 10 nodes to participate in this network.

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

  • 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 Rust contract API should be stable.  This means that contract authors can write their smart contracts in Rust with some degree of confidence.

  • For the first iteration of the network, there is no query functionality. Transfers will work, but it will not be possible to call contracts.

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 specification 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. Finality Oracle

  8. Skip List

  9. Optimized Fork choice rule validation 

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

  11. 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

Execution Engine Features

  • Same as the Beta testnet

DApp Developer features

  • Same as the Beta Testnet with the exception of events and queries

Metric for tracking success (Internal only)

  • Count of Validator nodes participating

  • Number of Blocks

  • Duration of stability of the network

 

What is special about this release?

This marks the first testnet milestone for the Rust node.

This network is backed by infrastructure provided by 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 won’t work with the Rust node.

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:

Debian packages pushed to bintray.

Where do developers go to learn more and get started?

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

  • github/release

  • Bintray

Where will bugs be filed?

Report a bug

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

NA





What do we want to learn?

  1. How many validators participate?

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

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

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

  5. What is the resource utilization of nodes? 

    1. Collect feedback on the performance of different configurations.

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

  7. Attempt to load test the network - see if validators can script up some token transfers and load the network.

  8. 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.

  4. Observe how their seignorage rewards pay out for participating in consensus.

What do we need to not do?

  1. Talk about the security of the protocol at this point, not all the security features will be implemented.

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

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

  3. Cadence for Weekly workshops

Where will Transactions come from?

  • Token transfers via wasmless transfer in Rust client.

Who are we Targeting?

  • Validators from the Alpha testnet

Why should they care?

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

 



Work in this Release