Development team

Marketing team

Release Overview

Simple Overview

We are proud to announce that CasperLabs now supports Smart Contract development in both Rust and AssemblyScript.  

We also present our first version of a contract development kit, that enables developers to run smart contracts in the CasperLabs runtime environment, enabling the use of Rust development tools like Cargo and CLion. 

The kit includes the system (Genesis contracts) and several example contracts, such as an ERC20 example and a set of integration tests.  Rust developers can use familiar tools and workflows to build their contracts and run them in the engine in the order they desire and observe the effects of contract execution in the global state (the shared database that is the blockchain) -all from within an IDE of their choice.

Placeholder for Consensus:

The Highway Protocol implements a partially synchronous liveness strategy for CBC-Casper.  As we run up to our TestNet launch, we completed the work in consensus to implement Eras, Rounds and leaders, along with an efficient fork choice rule.  

Detailed Overview

Execution Engine Enhancements

• Contracts 'SDK' (Contract API for the EE & cargo.toml for use with IDE)
• Preliminary support for Contracts in AssemblyScript

Consensus & Node Features

• Eras, Leaders, Efficient Fork Choice (not releasing until 13)
• GraphQL Enhancements
  • Account Balances in GraphQL
  • Validator / Blocks relationships 

EcoSystem:

• CLarity Enhancements
• dApp developer guide for writing smart contracts in Rust.
• Blog posts
• Token vesting contracts example

Test & Operations:

Tickets for this Release

Features/Stories

Defects Fixed

Metric for tracking the success:

What is special about this release?

For dApp Developers 

In this release, we are pleased to offer 2 large features to support dApp developers  - support for Assemblyscript contracts, and a Rust contract development runtime environment and documentation.  

Introducing cargo casperlabs

Developers wanting to use Rust (recommended for financial applications) can create a crates project for their smart contracts and run their contracts in a testing framework that has the CasperLabs contract runtime environment with it.  This enables developers to use a seamless workflow for authoring and testing their smart contracts.  This environment can also be used for continuous integration, enabling Rust smart contracts to be managed using development best practices.  The documentation on how to use cargo casperlabs is documented on Github (https://github.com/CasperLabs/CasperLabs/blob/dev/execution-engine/cargo-casperlabs/README.md )

As part of the Rust development environment enhancements, we also present Rustdocs for the contracts library.  The  Rustdocs are available at: https://docs.rs/crate/casperlabs-contract/0.1.0

Smart contracts in Assembly Script

For those  developers that  would prefer to use  a scripting type language,  the W3 foundation has implemented Assemblyscript (provide link) for Webassembly.  We have created a contracts library that enables developers to create smart contracts for Webassembly using Assemblyscript.  Quite often Assemblyscript is conflated with TypeScript, and while these 2 languages are both scripting languages, there are several differences which are documented (here- provide a link) and contract developers should be aware of these differences.

GraphQL enhancements:

We offer new relationships in GraphQL that support retrieving the child relationships given a block hash. 

query {
  block(blockHashBase16Prefix: "a3016e93f101da2781eae0696064df8c1ca770058b1d1eae261cfd4034f47547") {
    blockHash
    parents {
      children {
        blockHash
      }
    }
  }
}

Response:

{
  "data": {
    "block": {
      "blockHash": "a3016e93f101da2781eae0696064df8c1ca770058b1d1eae261cfd4034f47547",
      "parents": [
        {
          "children": [
            {
              "blockHash": "a3016e93f101da2781eae0696064df8c1ca770058b1d1eae261cfd4034f47547"
            }
          ]
        }
      ]
    }
  }
}

The GraphQL interface is available on every node, and public DevNet interface is at http://devnet-graphql.casperlabs.io:40403/graphql

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:

• 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