Development team

Marketing team

Release Overview

Simple Overview

In this release we have primarily focused on optimizing, stabilizing and hardening the network and also on improving the user experience for dApp developers. In this release, we implement 'Deploy Dependencies', the mechanism by which users can explicitly enforce an ordering to their deploys. This important feature addresses use-cases where ordering of execution of deploys in a certain manner is essential for success of the task (e.g. I can't pay my rent until my salary is deposited into my bank account). We have also focused on improving the usability of our Execution Engine and have included several optimizations to speed up or make safe Node operations.

The CasperLabs hackathon in LA Blockchain week helped unearth some additional requirements and bugs in GraphQL. We are extending GraphQL Schema and also fixing the bugs in this release. 

Detailed Overview:

Execution Engine

Improved Usability

The contract_api module was broken into logical groupings of functions and made more explicit via sub-modules. This improves the user experience around discovering what capabilities are made available by the contract_api.  The groupings are: 

• account.rs
• contract_ref.rs
• error.rs
• runtime.rs
• storage.rs
• system.rs

and can be found at contract_api.

The contract-examples directory has migrated to CasperLabs/execution-engine/contracts/examples and the build process has been updated to be aware of the new location.  The directory where they had previously been located has been deprecated.  It is probably best to refresh and delete the deprecated directory.    

Node Optimizations:

• Algorithm for initial synchronization when a peer joins a network changed to start at the Genesis Block and traverse forward until tips (previously it was getting tips from peers and then traversing back to the Genesis block.)

• Ensuring a validator doesn't try to propose more than 1 block at the same time is essential to avoid equivocations. However, serializing the block processing itself for blocks created by other validators was an artificial restriction that limited throughput. In this release we remove the blockProcessingLock from MultiParentCasper that only allowed the node to process 1 block at a time. Now, the BlockAPI will take out a proposal lock, so a validator will not propose 2 blocks at the same time and the DownloadManager will feed the blocks in topological order to addBlock.

• We have optimized the way a Node handles backoff by switching to alternative sources when it can (even by interrupting its own backoff if an alternative pops). Only if all alternatives failed will a Node back off before trying again.

• Requeue orphaned deploys before proposing a new block rather than after adding blocks from any other validator. 

• To protect against accidentally sending a deploy to the wrong network, or to get it deployed there by somebody else (only for people who share the same account key), this release adds an optional Deploy.Header.chain_name field that users can set through the --chain-name CLI option during deployment. If set, it has to match the chain name in the ChainSpec. 

• Fork-choice requires so much traversing of the DAG that without the in-memory cache, SQLite is way too slow. To improve the performance, we preload DAG Store and store data in CachingDagStorage not only on inserts but also on lookups. During lookups (but not inserts) caches not only a single block but its neighborhood - blocks from the past and future. The radius of the neighborhood is configurable during construction.

• Adds new command for the Scala CLI client print-deploy to print information of a deploy created by make-deploy and possibly modified by sign-deploy. The command is configurable to:

  • use either JSON or Protobuf text encoding
  • use base16 bytes encoding or default one which is base64 for JSON and ASCII-escaped for Protobuf text encoding

• Block Validation: When block is received, node will validate that it was built using correct protocol version and mark block invalid if it wasn't.

• Adds a new chain_id field to the io.casperlabs.comm.discovery.Node.scala (generated from protobuf). Then uses this field to validate incoming requests rejecting peers with a different chainId from local one.

• To defend against malicious repeated downloads, a new component RateLimiter which allows limiting the rate of arbitrary F[A] has been added. This component is used to rate-limit the getBlockChunked intra-node RPC. The rate limitation is disabled by default.

Stabilizing

• Improved time to create blocks by copying deploy summary and body into buffered_deploys table to eliminate joins with the full deploys table.

• Removed leftover tests from earlier code where nonce was used.

Deploy Dependencies:

We implement in this release, the mechanism by which users can explicitly enforce an ordering to their deploys. This is an important feature since sometimes order matters (e.g. I can't pay my rent until my salary is deposited into my bank account). 

The node accepts deploy and block messages, validates these messages and creates blocks of its own. The node never accepts invalid deploys or blocks. Moreover, the node will not accept deploys with deploy.timestamp greater than some configurable number of milliseconds in the future (relative to its current time). This maximum future time is configurable node to node as opposed to mandated by the protocol (i.e. in the Chainspec) because this parameter is not visible at the protocol level since deploys can only go into blocks after their deploy.timestamp. Node operators may adjust this value depending on their own tolerance for storing deploys in their deploy buffer for some time before being able to include them in a block.

The node will also never produce an invalid block, therefore must also select deploys to include in a block which meet the block validity conditions.

For the purposes of this feature, a deploy will have four important fields (in addition to whatever fields are important to other features)

• Time to Live(TTL): optional unsigned 32-bit integer
• Timestamp: required unsigned 64-bit integer
• Deploy hash: 32-byte array, blake2b256 hash of the deploy header. This field uniquely identifies the deploy.
• Dependencies: optional list of 32-byte arrays, the list of deploys (referenced by their deploy hash) which must be executed before this one.

For more details about this feature, refer to document Deploy Dependencies Specifications.

GraphQL Related Improvements

• Resolving issues identified during LA Hackathon:
  • BlockAPI won't pull the full block into memory to produce the statistics, they are retrieved from block_metadata
  • deploy_cost_total has been added to BlockInfo.Stats and block_metadata so users don't have to iterate through the deploys, they can get it from just the block.
  • The view parameter is pushed to the storage layer so that if the user or the query only needs BASIC info about the deploy we don't retrieve the body (which has the Wasm) at all. The code and args aren't part of the GraphQL schema, so that will never retrieve it, but other gRPC endpoints can still opt into the FULL view to retrieve the code.
  • Logging GraphQL queries and measure their time
  • Added a simple validation of incoming requests, preventing queries with empty hash prefixes
  • Added block size and deploy error count to the `block_metadata` table
• Added two columns 'block size' and 'deploy error count' to table block_metadata. A method DeployStorage.getDeployInfo is then provided for use in BlockAPI as an optimization.

• Added methods to the SQLite storage layer to list deploys. The methods:

  • optionally filter deploys by account

  • limit the number of rows returned

  • order deploys by creation time descending and hash descending

  • optionally filter by creation time being less than a given value.

• Extended the GraphQL schema similarly to the gRPC API to support querying for the deploys of any account, or just the latest deploys in general. Check out https://graphql.org/learn/pagination/ for details.

• Added RPC method ListDeployInfos to support query for latest deploys for the specified account with pagination

• Renamed 'chain_id' to 'chain_name' in Block.Header and added the missing metrics findBlockHashesWithDeployHash to MeteredBlockStorage.

• The PENDING and DISCARDED statuses added to the buffer table in the API have been exposed

Devnet++

• We continue to build the foundation blocks for Devnet++. To ensure that justification timestamps are not in the future (a block with a timestamp higher than its justifications is not created), a sanity check to MultiParentCasperImpl.createBlock has been added. 

Node Features

Execution Engine Features

Consensus 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