Development team

Marketing team

Release Overview

Simple Overview

This release introduces the core implementation necessary for the very creation of this 'CasperLabs' Blockchain. We have included the required tooling for the formation and kick-starting of a new CasperLabs BlockChain in a simple but secure manner. The Genesis Process implementation in CasperLabs also allows for others to start their own, Private CasperLabs Network

Detailed Overview

Genesis Process

CasperLabs has designed the "genesis process" from the ground up with the following primary requirements:

• technical simplicity
• flexibility (allowing the possibility for this process to be done by others to start a private CL network)
• not allowing validators to start early

A CasperLabs network will be uniquely identified by its genesis block hash. Each node will present its genesis hash when attempting to peer up with another node and only the nodes, where the genesis hashes match will be permitted to peer with each other. This also eliminates the need for validators to "approve" of the genesis block.

We introduce the concept of a chainspec, which is a configuration file providing all the information needed to construct the genesis block. Each node (regardless of whether it is read-only or validating) will use its local copy of the chainspec to create a local genesis block. Once a node has this block, it may proceed with normal operation: peering with other nodes, gossiping blocks, creating new blocks in the case of a validating node, etc. 

To ensure that network cannot launch and validators don't start producing blocks prior to the "official" release of the 'chainspec', some amount of entropy into chainspec, which effects the genesis hash (e.g. the timestamp of the genesis block, or a random number).

The ChainSpec:

The chainspec is a configuration file which completely describes the initial state of the blockchain and provides the flexibility desired in the genesis process. It will contain the following information:

• Name: String (e.g. "cl-main"); the name used to identify the network – this is largely for human convenience as the genesis block hash is the true unique identifier of a network. Different values of this name must change the genesis block hash.
• Timestamp: Long; the millisecond timestamp to record in the genesis block
• Path to mint system contract installation wasm: String; (more details on the interface it must satisfy below)
• Path to PoS system contract installation wasm: String; (more details on the interface it must satisfy below)
• Path to initial accounts: String; path to a CSV file with the information about genesis accounts
• Costs table; a listing of the cost (in gas) of all the wasm op codes and host FFI functions
• List of system contract upgrades; see Upgrading System Contracts for more information

Content of the genesis block

The genesis header is determined based on the information in the chain spec and the post-state hash coming out of the EE. The genesis body is empty because no real deploys were executed and this block is never communicated over the wire anyways because by construction all nodes on the same network must have the same genesis block.

Refer Genesis Process Design Document and Genesis Process Specification Document for more details on the genesis process and ChainSpec.

RDBMS

Flexible BlockStore storage (RDBMS)

Blockstore is currently stored on disk in a raw file and the offsets of blocks in that file are stored in an LMDB database, which is not optimal for querying and retrieving.  We are migrating the BlockStore to SQLite to make it more accessible and allow optimal search and retrieval.

Persistent DAG storage (RDBMS)

DAG is currently stored currently entirely in memory backed up by a raw file. We are migrating the DAG store to SQLite to make the store accessible to be queried directly from EE. 

Separate SSL certificate for Public API:

An operator is now to be able to configure a SSL certificate that is signed by a trusted root CA, so that clients who want to deploy don't need to implement the custom validation logic.

Building Blocks for 'Highway' Implementation:

We continue to work on implementing building blocks for 'Highway' protocol implementation. Below are some of the key concepts implemented to take us closer to the final 'Highway' implementation.

• Handling Equivocations in fork-Choice and Finalization Detector
• Creation of Ballots

Optimizations:

We are continuing to work on optimizations to improve the performance of the network.  Below are some of the performance improvements that when in this release:

• Switching from 'Push' based Gossiping to 'Push & Pull' based Gossiping to improve efficiency
• Incorporating 'Time to Live' for erasing deploys after a specified time to save the buffers from blowing up
• Notifications to run in the background. A node that is slow to receive gossiped data slows down the entire process. There's no reason to wait for the notifications to finish though, so run them in the background so downloads and block proposals can continue unhindered. 
• Support for multiple Bootstrap Nodes

Theoretical Work

• CasperLabs released the Mathematical Paper describing the 'Highway' protocol with a proof for liveness and safety
• We also have the "Technical Specifications' (currently under review and expected to be published in a couple weeks) based on the 'Highway' protocol for implementation at CasperLabs
• We have also done a lot of economic research to understand the economic model for the 'Highway' protocol and implementation of Revenue Rewards, Slashing, etc

Additional node metrics in Grafana <@ashok to fill these in>

Node Features

Execution Engine Features

Consensus Features

Storage Features

Operations

EcoSystem

Tickets for this Release

Features/Stories

Defects Fixed

Metric for tracking the success:

What is special about this release?

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:

• Docker image (Supported on Linux only)
• Debian package 
• 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.

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?

Gitter developer channel