Beta TestNet Release -
Reference
Document status | DRAFT |
Release status | PLANNING |
Related pages |
Milestones
Start date | Mar 31, 2020 |
Sprint | |
Sprint | |
Demo | |
Release | Jun 30, 2020 |
Stakeholders
Name | Role | Reviewed? |
@Mrinal Manohar | CEO | |
@Kevin Watt | CMO |
Development team
Program manager | Project manager | Engineering Lead | SRE Lead | Page owner |
Ashok Ranadive | Piotr D | @Ed Hastings (Deactivated) | @Tom Vasile (Deactivated) | Medha Parlikar |
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 Beta 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.
Beta testnet is a step in the maturation process of the CL system. The prior step is Alpha testnet and the subsequent step is Delta 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 need to come in as part of a new Genesis.
Objectives:
Demonstrate Progress to investors and the broader community
Continue to practice engagement with the validator community
Begin the process of building our developer community.
On Decentralization:
We will empower the developer DAO to build our developer community.
Details on the process
What Validators need to do:
Sign up for the Testnet program and agree to the terms and conditions.
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 (optional)
Size of the Network
We want a minimum of 25 nodes and a maximum of 50 nodes to participate in Beta TestNet.
Node System Specifications
Estimates based on this data.
4 Core / 32 GB RAM / 100GB Disk
Network: 10 MBPs Upload /Download minimum.
Stability of the Network
This is a beta 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 will be stable.
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.
It is desirable to limit the number of times we have to update the network. Contract authors will face disruptions with network bounces.
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.
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:
Leaders
Rounds - fixed but configurable
Ballots & Omega blocks
Eras
Multiple Eras & Switch blocks
Base blocks
Skip List
Optimized Fork choice rule validation
Finalization stream (k=1) and fixed FTT (1/3rd)
Separate Clarity Instance
Separate Public Grafana instance
Deploy gossiping
Excludes:
Equivocation detection
Slashing & throttling
Adjustable round lengths
Block Merging
Rewards & Seignorage
Social Consensus API
Protocol Upgrades
Merkle Tree Based Justifications
Bonding / Unbonding
Execution Engine Features
Initial Typescript support
Support for Secure Enclave (multiple Key types)
Host side system contracts & payment code
DApp Developer features
Contract Headers
Support for multiple key lengths / key types
Metric for tracking success (Internal only)
Count of Validator nodes
Count of deployments
Number of Blocks
Gas processed / 5 seconds
Total Gas processed
What is special about this release?
This marks the public Beta 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 Alpha Testnet
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.
Developers can begin building their dApps using CasperLabs’s technology.
Launch partners can start prototyping against the contract API.
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?
Where do developers go for support? What is the SLA? Who is on point?
NA
Open areas of Risk
Performance & Stability
Node
Max deploys / second supported
What is the UX when a deploy exceeds the max #
Stability of finalization
What do we want to learn?
About Validators
How many participate?
Do we have interest from people not involved in the private sale?
Do the validators spin up hardware for the network?
Where are these servers located?
How easy is it to spin up a node and participate?
How does the upgrade process work?
Are the monitoring tools for Node operators good? Are they easy to use?
About the Protocol
How does the preliminary portions of the consensus protocol perform?
What is the resource utilization of nodes? How do different configurations perform?
Collect feedback on the performance of different configurations.
Operations team has to learn how to monitor the health of the network.
Attempt to load test the network - learn how the network performs under load.
About DApp developers / Developer community
Are there any material UX changes for the end user with this new protocol?
How many dApp's engage with the platform.
How many contracts are deployed to the platform?
Build and extend our Validator community
Engagement with Validators and create community.
Perform testing sessions with the validator set against the network.
Work with the DAO and create validator tools (or provide validators what they need in order to create these tools)
What is the contribution to Validators? Where is their value?
Observe progress on the project. Hopefully get confidence in the system.
Interact with the platform and become familiar with the software.
Earn token by participating in the network.
What do we need to not do?
Talk about economic security in this network, there won't be any.
We don't want a ton of validators. We need to limit to 40.
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.
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.
Game of stakes - We need to figure out what kind of games we want to support. @Ashok Ranadive (Unlicensed) You can add them here.
Best overall validator (Most engaged, best uptime)
First 5 to sign each block (Consistently one of the first 5 validators to sign Genesis)
Developer Awards:
First dApp on the network
Best deFi dApp on the network
Bug bounties
Paid out via criticality
How will Validators Co-ordinate (if at all)
Make announcements - changes on Genesis processes, rounds, games, status updates, etc
Confluence page in Release
Link page to Discord in Validator channel
Obtain feedback
Jira Service Desk (Medha to configure)
Cadence for Weekly workshops
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#