Development team

Marketing team

Release Overview

Simple Overview

This release extends the functionality of DevNet launched in the last release 0.5, by adding more features. Smart contract deploys can now require payment, in the form of tokens, to be supplied in order to be executed. Successful execution of the payment and sessions contract would depend on whether or not sufficient payment was supplied and excess tokens will be returned to a user-specified refund purse.  This feature is turned "off" by default, but can be enabled with a command line flag when invoking the execution engine (details below).  WARNING: the payment code for ALL nodes in the network must be turned on for consensus to reach finalization.  The CasperLabs Devnet nodes do NOT have this turned on, so validators who wish to bond to Devnet must keep payment off for now.  

This release also allows accounts to associate multiple public keys with the account. This feature is useful to get access to the account in case the "main key" is compromised.  A previously associated key can be used to deploy contracts on behalf of the main account. The CasperLabs Explorer has been expanded to include the ability to view/traverse the blockchain DAG, and to access a GraphQL console for the blockchain. The CasperLabs Explorer can be found at explorer.casperlabs.io

Detailed Overview

Payment Code (

optional)

Payment for contracts can now be enabled using the 'use-payment-code' feature flag when launching the execution engine.  

casperlabs-engine-grpc-server ~/.casperlabs/.casper-node.sock --use-payment-code

If this is turned on in any node, it must be turned on in ALL nodes.  For this reason, the CasperLabs Devnet nodes do NOT have this enabled by default.  Otherwise, a node could mistakenly attempt to join without enabling payment code and the network will no longer be able to finalize on consensus.  To exercise this feature, the user will have to run a private network where all nodes will have payment code enabled. 

When enabled, users are required to pay for all computations, which includes the computation required for the payment code contract itself. This is enforced through the mechanism of "gas". Conceptually, each wasm op-code and FFI call costs some amount of gas. A gas limit is imposed at the start of each computation. If at any point in the execution, more gas is needed than was allocated at the beginning, then the computation is terminated. While gas is used internally as a measure for computational work, externally, users deal with tokens

. The standard unit for the conversion rate from tokens to gas ('Tokens / Gas'), is

To provide flexibility in how users pay for their computation, we allow custom logic (called 'payment code') to be executed. The maximum number of tokens a payment code execution can "cost" is enforced via the gas limit mechanism described above. The maximum itself is a constant in the system which we denote as max_payment_cost and is in units of Tokens. Therefore, using the previously defined conversion rate, the gas limit for all payment executions is max_payment_cost / conv_rate.

10⁸. 

Payment code refers to the wasm bytes of a the compiled standard payment contract (see provided below). It is allowed to perform arbitrary logic, but Amounts must be hard-coded before the deploy for this release.  It must transfer sufficient funds to the PoS_payment_purse (obtained via the PoS get_payment_purse function) before reaching its gas limit, or else the account will lose max_payment_cost amount of tokens and no effects from the computation will be persisted. Optionally, the payment code may specify where the refund for excess tokens may be sent by calling the PoS set_refund function. If this function is not called with a valid purse then by default the refund is sent to the main_purse of the account identified in the deploy.

The following represents the standard payment contract. More complex payment contracts are possible, but this captures the minimum behavior to satisfy the payment logic.

Technical note: Payment code should always be compiled in --release mode.

fn call() {
  let m = main_purse();
  let pos = get_uref("pos"); // pos: proof of stake system contract
  let p = call_contract(pos, "get_payment_purse", {});
  let amount = get_arg("amount");
  let transfer_result = transfer_purse_to_purse(m, p, amount);
  if let Err(_) = transfer_result {
    revert(99);
  }
}

Key Management

An account can now have multiple public keys associated with it. This is helpful in the event that the 'main key' of an account is compromised or lost.  First, a new account must be created per the existing account creation process. Then, a smart contract must be deployed that contains a call to

 pub fn add_associated_key(public_key_ptr: *const u8, weight: i32) -> i32;

PublicKey is the public key to be associated with the account doing the deploy. Weights are used to restrict the authority of associated keys so that no account with the associated key can behave maliciously.  

There are two types of actions that associated keys can perform once associated: managing keys and deploying contracts. Each of these actions has an associated threshold: key_management_threshold and deploy_threshold. In order to perform these actions, the associated key must have a weight greater than or equal to the related action's threshold. These additional FFI's exist to support key management and action thresholds:

 pub fn remove_associated_key(public_key_ptr: *const u8) -> i32;
 pub fn update_associated_key(public_key_ptr: *const u8, weight: i32) -> i32;
 pub fn set_action_threshold(permission_level: u32, threshold: i32) -> i32;

CasperLabs Explorer

A graphical Blockchain Explorer and a GraphQL endpoint have been exposed on our website, soon to be rebranded to "CLarity". It can be found at https://explorer.casperlabs.io.  

Visualize the DAG (Blockchain)

An example of a DAG looks like this:

with a more detailed block view available by selecting a node.  A sample detail view looks like this:

GraphQL

An easily accessible GraphQL console can be brought up with the 'view details' link on the GraphQL button. This console provides a convenient interface to query the state of the blocks in the blockchain.  

Persistent Deploy Buffers

The CasperLabs blockchain uses the kademlia protocol to discover peer nodes and optimize the sharing of seen messages between nodes. Deploys received by a node (either new or shared by other nodes) are now stored persistently on the node in an SQLite RDBMS. The advantage of this is that if a node goes off-line for any reason, it can recover its previous set of deploys it was processing at the time. This allows the node to "catch-up" to the current state more quickly.   

Node Features

Execution Engine Features

Consensus Features

Storage Features

Operations

EcoSystem

Tickets for this Release

Features/Stories

Defects Fixed

Metric for tracking the success:

What is special about this release?

• Payment for processing of smart contracts is now required throughout the system, which can now be enabled via a feature flag for the execution engine.  ALL nodes in the network must have the feature either enabled or disabled.  Payment provides the basis for validators to collect fees.
  • The CasperLabs Devnet nodes do NOT have this feature enabled. 
  • To use this feature, a private network will be required so all nodes can enable the feature. 
• The release provides an additional mechanism (Key management) to insure against keys being lost or compromised. With this support, token owners need not concern themselves with the possibility of losing their investment or their earnings.  
• This release provides intuitive interfaces to view and traverse the current state of consensus, as represented in the DAG. This is a crucial tool for tracing the consensus protocol implemented in our nodes. The ability to get details on the blocks aids application developers in understanding the state of their running applications. It can answer questions like "which block contains my deploy"?

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

We are persisting our deploy buffers on disk, rather than keeping them in memory only. This further insures token investments against interruptions in node operations.  A node can recover its deploy buffer and resume processing from its last stored state. This, combined with smart gossiping reduces the amount of time to recover to the current state and resume collecting processing fees.

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

Before this release, querying block and DAG state was possible but cumbersome. The easy access to GraphQL is a usability enhancement for developers to understand the state of the chain as a result of their deploys. 

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

• View and traverse the DAG
• Easily create queries of the state of blocks with the GraphQL console
• Create associated accounts to ensure access to their tokens
• Run a private network and enable payment for computation

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