Reference

Milestones

Stakeholders

Development team

Marketing team

Release Overview

Simple Overview

Release 20.10 delivers additional economic and security features and a functional Rust network that can stand up minimum 50 nodes stable for minimum 1 month. This release will support a testnet with 50 validators, complete with a block explorer and features that enable dApp developers to interact with the network.

Validators will receive seigniorage and the network will detect equivocations. Nodes are able to join the network through ‘bonding auctions’ and validator set rotation. It is possible to observe where a given bid ‘ranks' and the number of open validation slots via a command line interface, and via queries of the status of the auction contract. Nodes can sync up state prior to participating in the auction and then join the network. New nodes joining the network will do so by obtaining a trusted hash from a bonded validator and then request finalized blocks from the validators and begin building up global state. As the network processes transactions, the node will emit ‘events’ through an ‘Event stream’ that will send event data to all subscribers. The first events that will be available are: ‘blocks_finalized’, ‘blocks_added’ and ‘deploy_processed’ events.

The network will emit all necessary metrics and logging as required by the SRE to monitor performance of the network itself as well as the validators on the network and debugging of any bugs.

DApp developers can use a Rust Client to create keys, send deploys, sign deploys and query nodes when using the system. DApp developers can also spin up a local network by using the network control tool - a set of bash scripts that enable to creation and destruction of networks for the purposes of testing.

20.10 Release will include:

• Repeat Token Transfer per second tests on Rust network [F-178] (Can be done by Charlie validators)

• Rust Client: Feature parity with Python Client [F-199]

• Platform to provide API for external clients like CLarity and Rust client [CEP #9]

• Network rewards (Seignorage)

• Token Standard for Casper Token [F-52]

• Launch Charlie Testnet [F-174]

• Implementation of Event Stream [F-195]

• Implementation of Network Health monitoring (Metrics) [F-82]

• Highway Security - Part 1 [F-147]

• Improve Testing [F-175]

• Validator Set Rotation [F-193] - @Ashok Ranadive (Unlicensed) this is a must have.

Documentation

• Rust node documentation

• Rust Client usage

• dApp Developer guide update

• Bonding / Unbonding, How auctions work?

Ecosystem Product Updates

• Update UI/UX for Clarity and deploy separate instance to work with Rust Node .

SRE

• Metrics and logging as required by the SRE to monitor performance of the network and debugging of any bugs.

• Metrics and logging as required by the validators to monitor their node and debugging of any bugs.

Known Product Issues

• Security is not complete. It is possible to create equivocations in the system that are not slashed.

• The protocol is not secure against spam attacks and equivocation bombs as yet.

• The networking layer is still prototype code, it won’t hold up with large networks. We will be really pushing the envelope with 50 distributed validators.

• We have some metrics, but it probably isn’t enough yet to monitor network health.

• There are differences between the Scala RPC and Rust RPC endpoints. The Rust client is missing features.

• The node join/re-joining functionality is slow. During the joining process, the http server that serves the status endpoint is not yet active - making it difficult to determine what the status of synchronization is.

• There isn’t yet an endpoint to obtain the addresses of the system contracts. A work around is being put in place to resolve this, while the dev team builds the endpoint.

Tickets for this Release

Features

Ecosystem Features

Metric for tracking success:

• Duration that the network remains up (Number of blocks + Eras)

• Number of validators in the network

• Number of transactions (deployments) processed by the network

What is special about this release?

This release forms the basis of the Delta testnet that launches at the end of the month. We release a pure rust node that includes validator set rotation, bonding auctions and validator rewards. The network will be open for new validators to join, by submitting a bid to join the validator set.

For dApp Developers With this release, dApp developers can use a new rust client to generate keys, send deploys, create & sign deploys offline. The rust client will only work with the new rust node.

dApp developers can also query node endpoints for blockchain events. so they can learn about the work the network is performing and the status of their deploys.

For Node Operators

With this release it is possible to bond into the network via a bonding auction mechanism, and the validator set will rotate at the end of eras.

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

The Casper network is a decentralized, permissionless blockchain. What this means, is that it is open for participants to join the network, without having to pass through any voting mechanism. To facilitate this process, the system has an open process for new validators to join, known as the bonding auction (@Camilla McFarland (Unlicensed) I”m open to renaming this)

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?

Description of release packaging

Release packaging will include:

• Debian package for Ubuntu 18.04 and 20.04

Where do developers go to learn more and get started?

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

• Packages available at: http://github.com/CasperLabs/releases

• Docs available on GitHub.

Where will bugs be filed?

Github - part of the public release.

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

Discord Channel. @Medha Parlikar will be on point to support validators - along with @Joe Sacher .

In the event of a critical network failure, a bounce will take place in approx 24 - 48 hours to restore the network. Fixes will be delivered based on priority + nature of the issue.

Defects Fixed