Node 0.11 Release Plan

Reference

Document status

REVIEW

Release status

RELEASE

Related pages


Milestones

Start date

 

Sprint 26 (2 weeks)

 

Sprint 27 (2 weeks) 

Release

 

Stakeholders

Name

Role

Reviewed?

Medha ParlikarCTO 
  •  
Mrinal ManoharCEO
  •  

Development team

Program manager

Project manager

Developer

Developer

Developer

SRE

Ashok RanadiveRita AllenMichael BirchAkosh FarkasHenry TillTom Vasile

Marketing team

Marketing lead

Content owner

TBDTBD

Release Overview

Planned

  • CLTypes
  • Performance boost in EE
  • Node Operator guide
  • Optimized block fetching in the node
  • Propagate payment code execution errors to the user
  • Improved dApp developer guide.
  • Consensus implementation (Initial production code)
    • New fork-choice rule
    • Eras

Simple Overview

In this release we introduce basic contract headers (CLTypes) and more performance optimizations.

Detailed Overview

For dApp Developers

In this release we introduce the CasperLabs type system, CLTypes, with the implementation of CLValue.  This system creates a more type safe boundary to our smart contracts.   It is also the first step toward supporting the future Contract Headers and Contract Registry features.  The CasperLabs system supports turing complete payment code, within a single deployment, 2 blocks of wasm bytecode can be sent (one for payment, one for session).  Before this release, only errors in session code execution were returned.  Now, errors from payment code execution are returned to the user.

Contract authors will want to know when transactions are finalized by the system.  For this purpose, we present a gRPC endpoint that provides a stream of finalized blocks to the caller.  

We have corrected an inconsistency in the system where accounts were referenced using the base64 and base16 representation. We have opted to use the base16 representation of keys throughout the system.

Users can now upload existing keys to the CLarity interface (private keys are not stored, only public keys) - so they can fund these keys from the faucet via the CLarity web interface.  The system supports EC25519 keys, and supports assigning a human-readable name to the key, for simpler management.  Users still need to safely store their private keys carefully offline, or in a secure location.

We also introduce an example token contract modeled after ERC20 that includes buy and sell methods, which enables dApp developers to create their own token on the platform and move this token between accounts.  CLX will be required to fund these transactions.  

Execution Engine Enhancements

  • CLTypes - the CasperLabs type system
  • Performance Optimizations
  • Propagate payment code execution errors to the user

Execution Engine Tickets

key summary assignee status
Loading...
Refresh


Node & Consensus Tickets

  • Ballots
  • Eras
  • Optimized block fetching in the node

key summary assignee status
Loading...
Refresh


EcoSystem

  • ERC20 example contract
  • More work on ZKSnarks (became blocked)
  • Begin work on a dApp developer guide that describes working with the Contracts API & the platform features.

Ecosystem tickets

key summary assignee status
Loading...
Refresh

Tickets for this Release

Features/Stories

key summary assignee status type
Loading...
Refresh

Defects Fixed

key summary assignee status
Loading...
Refresh

Metric for tracking the success:

What is special about this release?

We are pleased to announce the CasperLabs type system for smart contract authors.  Types are important in computer systems because they define interfaces across the different portions of a system and provide a means to verify that all the parts are connected consistently.   


For dApp Developers 

For Node Operators

Are we doing something differently? If so, why are we doing it this way?

As part of this release, the system will send payment code errors to the user.  In the CasperLabs system, it's possible to create custom payment code, which is a completely separate contract, purely for funding the execution of the session code.  As with any contract, it's possible that the payment code can experience failures during execution, and these error messages need to be returned to the user, so they can be addressed.  

Before these features were available, what were developers able to do?

Developers were able to use the custom payment code, but the error messages were not returned in the event of a failure. Developers had to debug the error messages outside of the system.  Deployments contain 2 wasm contracts, and errors were only being returned for 1 of the contracts (session contract).

After these features launch, what will developers be able (and not able) to do?

Now developers can receive messages in the event of a payment code execution failure.  

Now developers can receive a stream of finalized blocks from a gRPC endpoint. 

Description of release packaging

Release packaging will include:

  • Docker image (Supported on Linux only)
  • Debian package 
  • Brew package
  • RPM package
  • tar.gz file

Where do developers go to learn more and get started?

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