Node 0.3 Release Plan

Release summary

Simple overview

Block passing (gossiping) is enhanced to leverage Kademlia-based proximity, block headers, sync DAG on demand, and distinction of "new" and "seen" blocks for further performance optimizations.  Nodes that join a network must first sync with a bootstrap node's DAG before it can participate in consensus by proposing and gossiping blocks.  While it is sync-ing with the bootstrap DAG, it will "stash" other received blocks until the sync is complete. The global state is stored in a key value store on disk, backed by LMDB.  When a node is restarted, the global state will be restored from disk.  

Technical Overview

DApp developers: Persistent State Storage

CasperLabs storage has several components that work cooperatively to support consensus and machine state.  These are now persistent, which enables nodes to recover state when they rejoin the network - as a result of expected or unexpected downtime:

• blockdag storage - BlockDagFileStorage is a representation of the directed a-cyclical graph that represents the relationship of approved blocks in the network.  It stored in-memory and persisted to files on the disk so that a node can recover on restart. 
• BlockStore storage- FileLMDBIndexBlockStore LMDB key-value storage of blockHash, blockMessage, where blockMessage is stored in a file and blockHash is the location of the file. 
• Global State storage -  Merkle trie stored using LMDB. When a contract is executed, the pre-state context is retrieved from the global state store using the contracts pre-state key (including the local state cache). The contract executes, the effects to the global state are recorded, and the new post-state context is stored with its key.  Any local context created during contract execution is returned; only the effects to the global state is saved. 

BlockStore and BlockDag work in conjunction and are updated in an atomic way.  They function virtually as one storage mechanism to represent the state of the DAG.  

DApp developers: Calling Smart Contracts

The API to call contracts has been updated to take arguments in their original form rather than an array of byte arrays.  This makes calling contracts more intuitive.  Specifically, API method call_contract has been simplified. Instead of requiring arguments passed in the binary form it now accepts tuples up to 8 elements. It is required that for every type in the tuple there exists an instance of ToBytes trait.  The byte representation for each tuple argument must be ABI compliant. 

Operations: 

Python Testing Client

A Python CasperLabs client API and CLI was created in this release. The client communicates with node via gRPC Deploy service. This is primarily intended to help us write more robust integration tests but may also be used by external Python developers in the future.

Integration tests for these areas were constructed and added to CI/CD:

• Persistent BlockDag Store
• Deploy/Propose scenarios
• Block Merging
• Consensus Integration tests

Tests that need to pass for this release 

• Blockstore integration tests
• integration tests for a single deploy, multiple propose scenario.
• Test multiple deploys followed by single propose behaviour
• Regression test for block merging

• Deploy three different contracts and propose each on different node, and call each contract from another node.

• missing hash_string check (for block/dag store)
• Node uses persistent block/Dag store on restart

Metric for tracking success (Internal only)

• Features added to help DApp developers
  • Feature to make calling smart contracts easier
  • Persistent Storage
• Features added to help node operators
• Number of things we have learned about the performance of the node as a result of the work in this release?

What is special about this release?

Persistent storage (BlockDag and Global State), Smart Gossiping, user interface improvements (calling contracts) 

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

• Caps is now implemented more efficiently via a bit? or byte? array for improved efficiency.  
• Smart gossiping to reduce our resource dependency and optimize block propagation
• Use of Python Client for Integration tests
• Optimizations for heap memory usage

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

Build, install and run nodes, deploy simple contracts (i.e. contracts that could not take parameters) to the chain, and propose blocks between nodes.  

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

Developers can write more complex smart contracts, more easily track the execution for debugging and regain state after a node is restarted.   They can also keep their node software up-to-date automatically.   Developers are not able to acquire tokens and/or receive payment for execution. 

Description of release packaging

Release packaging will include:

• Docker images
• Debian package 
• RPM package
• tar.gz 

Where do developers go to learn more and get started?

At release, links to installation packages and relevant documentation is available at 

• Packages available on GitHub, Bintray, repo.casperlabs.io
• Docker images available via DockerHub
• Docs available on GitHub (README, DEVELOPER.md)

Where will bugs be filed?

Report a bug

Where do developers go for support? What is the SLA? Who is on point?

NA

Tickets for this Release

Defects Fixed in this Release