Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Reference

Document status

Status
colourGreen
titlecomplete

Release status

Status
colourGreen
titlein DevCOMPLETE

Milestones

Start date

 

Release

 

Stakeholders

Development team

Program manager

Project Manager

Engineering Lead

SRE

Medha Parlikar

Piotr Dziubecki

Ed Hastings (Deactivated)

Joe Sacher


Marketing team


Release Overview

Simple Overview

This release features a new networking layer, and several improvements fixes for system stability and a new node launcher component that supports protocol upgrades.

Detailed Overview

This release will improve networking by providing a robust node discovery and gossiping protocol to support message passing and node discovery for the Casper network. An integration with a custody provider will be partially completed during this release cycle. As part of this work, we have released a new Javascript SDK, which can be found on npm.

The Casper VM now supports immutable contracts, in addition to fully upgradeable contracts. Contract authors can specify at deploy time, whether a contract is upgradeable or not. The Node RPC deploy acceptor will throttle requests at a configurable threshold, to protect the node from deploy spam attacks.

Economic Updates:

Transfers of the system’s native token (CSPR) now cost exactly 10,000 motes (there are 1,000,000,000 motes in 1 CSPR token). When submitting transactions, a gas-price of 1 mote for 1 unit of gas must be provided. The node will not select transactions based on gas-price, but rather in the order which the deploys are received. In addition to providing gas-price, a parameter ‘payment-amount’ is also required, which indicates the amount the user is willing to pay for the transaction. Since the Casper network processes the transactions only after a block is finalized, refunds are not provided, as providing an inflated payment-amount could be a way to mis-represent the actual cost of a transaction to validators.

Consensus Security and Safety features

In the Delta test net we have observed a variety of issues associated with liveness failures, with validators going offline while bonded. Validators can now rejoin after a brief outage in the current era. The consensus protocol will also evict a validator that has been offline for too long.

A validator node will also detect a doppleganger (a clone of itself) and shut down, to prevent unintended equivocations if a node operator accidentally spins up a clone of another node’s configuration.

The Highway Protocol paper outlines an attack known as 'fork spam', a vulnerability present in all fork choice protocols. As part of this release, all of the security features as outlined in the paper have been implemented.

Protocol Features:

  • Validators can rejoin the network in the current era (recovery from liveness faults)

  • Improved joining from a trusted hash

  • DOS protection (throttling) against deploy spam.

Consensus Security Features:

  • Finality Signatures

  • Defense against fork spam

  • Doppleganger detection

Execution Engine

  • Remove wasm system contracts

  • Apply cost to wasmless transfers.

  • Apply costs to all host side system contracts.

  • Support immutable contracts.

Essential System Contracts

  • The Auction contract will be enhanced to include the vesting schedule to be compliant with the VFTA

Operations & Monitoring

  • Grafana dashboard for Rust node

  • Load and performance testing

  • Explainer guide on metrics - key metrics, what they are, why they matter.

Ecosystem

  • New Javascript SDK available on npm.

  • We will update our documentation at docs.casperlabs.io

  • Provide additional example contracts for use by developers

We will create video tutorial content for the following:

  • Deploying a token & calling it to send tokens to an account.

  • Deploying a contract and then upgrading it. Showing the change in version.

    • Walk through of code to upgrade.

Tickets for this Release

Features

Jira Legacy
serverSystem JIRA
maximumIssues20
columnskey,summary,status,priority
jqlQueryproject = FEAT and fixVersion in(21.01) AND ( labels not in ("ecosystem") or labels is EMPTY) ORDER BY priority
serverId74adbfdc-03f9-334e-80a4-d9a3f2a98ccf

Ecosystem Features

Jira Legacy
serverSystem JIRA
maximumIssues20
columnskey,summary,status,priority
jqlQueryproject = FEAT AND issuetype = Epic AND status in (Analyzing, Backlog, Implementing, "In Review", Planning) AND fixVersion = 21.01 AND labels =ecosystem ORDER BY priority
serverId74adbfdc-03f9-334e-80a4-d9a3f2a98ccf

Key Consensus Deliverables

Jira Legacy
serverSystem JIRA
maximumIssues20
columnskey,summary,assignee,status,sprint,priority
jqlQueryproject in (HWY) and Issuetype=story and fixVersion="21.01"
serverId74adbfdc-03f9-334e-80a4-d9a3f2a98ccf

Key Node Deliverables

Jira Legacy
serverSystem JIRA
maximumIssues1000
columnskey,summary,assignee,status,sprint,priority
jqlQueryissuetype !=Epic and project=node-rs and FixVersion=21.01 and labels is empty
serverId74adbfdc-03f9-334e-80a4-d9a3f2a98ccf

Key Contract Runtime Deliverables

Jira Legacy
serverSystem JIRA
maximumIssues1000
columnskey,summary,status,sprint,priority
jqlQueryproject = ee and fixVersion = 21.01
serverId74adbfdc-03f9-334e-80a4-d9a3f2a98ccf

Ecosystem Product Updates

  • Event Capturing Service, Event Store

  • Javascript SDK

  • Clarity supporting Rust Node

  • Enhancements to Signer

Jira Legacy
serverSystem JIRA
maximumIssues1000
columnskey,summary,assignee,status,sprint,priority
jqlQueryproject = eco and FixVersion = 21.01
serverId74adbfdc-03f9-334e-80a4-d9a3f2a98ccf

SRE

  • Network Health Monitoring

Documentation

  • Updated dApp developer guide for Rust Node

Defects Fixed

Jira Legacy
serverSystem JIRA
columnskey,summary,status
maximumIssues1000
jqlQueryissuetype = Bug AND fixVersion= 21.01 ORDER BY status DESC, key ASC
serverId74adbfdc-03f9-334e-80a4-d9a3f2a98ccf

Metric for tracking the success:

What is special about this release?

For dApp Developers 

For Node Operators

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?

Description of release packaging

Release packaging will include:

  • Debian package 

  • Docker image

  • Brew packages

  • RPM package

  • tar.gz file

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. http://docs.casperlabs.io

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?