Development team

Marketing team

Release Overview

Simple Overview

This release completes the necessary features to support a public DevNet.  The objective of Devnet is to provide a working Casperlabs proof-of-state network that provides the first CasperLabs network to run distributed applications (dApps).  With this release, CasperLabs will host 4 public nodes that will accept deployments from dApp developers as well as bonding requests from public nodes that want to join the network as a validator and participate in Proof-of-Stake consensus.  A faucet exists to provide tokens to bond as a validator. 

Smart contracts are executed in the context of an "account".  Accounts are created by generating a (or using a compatible existing) set of ed25519 public/private key pairs.  The public key is used to create an account on the network by making a request to transfer ERC-20-like tokens to the account's purse. Only the account has access to its purse.  If the account does not exist, it is created, and the tokens are transferred.  Tokens are transferred if the account is existing.  Deploys must be signed by the public key of the account making the deploy.  

Nodes may join the network in several modes: standalone, which generates its own genesis block; read-only, which requires a certificate to be supplied; and validator, which requires a certificate and public/private key pairs for the validator.  In all, depending on the desired interaction with CasperLabs, there are three possible sets of keys that may be required: account keys, node certificates and validator keys.  

Deploys contain both a payment (smart) contract and a session (smart) contract.  Deploys are processed in 2 phases:  login and execution.  During login, the account is validated, and cost of execution is estimated for both the payment contract and the session contract.  Proper sequencing of smart contracts is insured with a nonce that must be incremented with every deploy for the same application.  Additionally, a metric exists to show total execution costs incurred per second. 

Blocks may be automatically proposed at regular intervals, or proposed manually via a CLI command.  

A web-based user interface exists to facilitate some of the security requirements.  For any dApp developer, the first step will be to sign up for our devnet using the interface found <IP address of Casper User Web here>.  This site also provides an interface for creating accounts on CasperLabs: generating keys and requesting tokens.  There is an interface to easily create signed deploys as well.  You will need the wasm code for the smart contracts (payment and session), your CasperLabs account public key, and the nonce.   Lastly, there is an interface to query the state of deploys, blocks and the DAG.  

Detailed Overview

Node Features

The new paradigm for block gossiping (sync on demand) is now turned on by default, but can be configured to use the previous "broadcast everything to everyone" paradigm. A genesis block has been created to contain the system contracts used to implement the protocol of the Casperlabs blockchain.  Blocks may bootstrap to any known validator and request the genesis block, or they may create their own genesis block (Ref) and have existing validators approve it as a valid genesis block.  

Deploys must now be signed by default.  Additionally, accounts must increment the nonce for each deploy in a given dApp to ensure proper execution sequencing.  Deploy signature and nonce validation have an option to be bypassed to facilitate dApp development, however, these options will be removed in the coming releases.  

Execution Engine Features

Accounts, which contain purses, which contain tokens now exist.  They can only be created with a request to transfer tokens.  They are secured with an ed25519 compatible key pair.  When an account is created, a purse is created in the mint, tokens are transferred to the new purse, and a new account object is written to the global state under the passed PublicKey.  The account also includes additional fields for thresholds, associated_keys, and account_activity, which will be important for reclaiming access to an account in the event a key is compromised (in a future release).  

As deploys are received from an account, the account public key is used to access the execution pre-state context from global state.  The contract is executed, the execution effects are applied to the pre-state to compute the post-state and the post-state is stored in global state under the account's public key.  This post-state will now be the "pre-state" for the next deploy for the account.  

A genesis process has been implemented to bootstrap the devnet network so that nodes can join and bond as validators.  A run_genesis process executes, creates a system account (faucet) with minted tokens, and puts system contracts (which encode the CL protocol) into the global state.  

Consensus Features

Nodes can now request to bond and unbond from the network by making requests (via deploys) to the Proof-of-State contract on the chain. The node operator sends a deploy from its account with the bonding request.

The devnet consensus protocol is called "Mainchain".  It is a CBC-Casper Proof-of-Stake protocol based on a single-parent GHOST fork-choice rule.  The GHOST rule assigns to each block B a score: the total weight of all non-equivocating validators whose latest block is a main descendant of B. It uses the weight values from the post-state of B's main parent. The rule starts at the genesis block, and iterates, picking the highest-scoring main child. When a tip is reached, i.e. a block that does not yet have any main children, that block is selected by the GHOST rule: It will be used as the new main parent.  

"The Inspector" algorithm determines the number of validators (by weight) that would have to equivocate for a block to be considered not final (part of the canonical DAG, or history of transactions). Given a threshold t and a block B, it detects cases where that block will be finalized unless at least t equivocate.  The finalization test returns a value between -1,1 where -1 means the block will never be included in the canonical DAG and 1 means the block will always be included in the canonical DAG.  

Operations

Integration tests have been created for:

• Deploy validation (nonce and digital signature)
• Bonding
• Unbonding
• Account Creation
• Genesis

EcoSystem

There are three pages available in this initial version: Accounts, Contracts & Query.  The accounts screen provides an easy interface to generate account keys for signing deploys and for creation of accounts on the chain.  The contracts page facilitates dApp development with an intuitive interface to include payment and session contracts (with associated arguments) into a deploy request to the chain.  Finally, the query page offers an easy interface for querying the current state of the blockchain.   

Tickets for this Release

Defects Fixed

Metric for tracking success (Internal only)

• Features added to help DApp developers

  • Account creation tools 

  • Tools to help with signing and submitting deploys

  • Tools to query the global state
  • Cumulative gas spent

• Features added to help node operators

  • Extended Grafana metrics 

  • Documentation for running the node and joining the network

• Number of things we have learned about the performance of the node as a result of the work in this release?

  • Heap memory tends to stay stable at around 500MB 

  • Fixed several found defects around OOM errors after approximately 10K blocks (~ 2 days continuous deploying and proposing)

  • Deploy buffers require careful management of "orphaned" and "invalid" blocks in the absence of slashing rules 
  • Optimization opportunities found to be prioritized for:
    • Finalization check
    • Fork-choice rule
    • Deploy buffer management
    • Invalid block management
    • Global state storage
    • Block/DAG storage

• Gas processed / second

  • Metric now included on Grafana dashboards

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

Test Cases (Temporary)

• Block proposals (aka consensus message) --DevNet
  • Submit block proposals with the following fields missing, present but empty, and present but with invalid values
    
    • Version
    • Validator (creator) public key
      
      • Also: Valid node public key for non-validator node
    • Parent block hash(es)
    • Justifications
      • Validator public key
      • Block hash
    • Execution semantics
    • Pre-state hash
    • Post-state hash
    • Timestamp
    • Deploys
      • Deploy count does not match deploy count field in header
      • All tests specified in the Deploy bullet above
      • Cost
      • Error value
    • Signature

• System API's -->DevNet
  • For each system function, test argument error conditions that are not statically detectable (the compiler will catch statically detectable errors)
  • Add more details
    • Handle errors that not detectable statically (via compilation)