Development team

Marketing team

Release Overview

Simple Overview

This release focuses on implementing some key features to gain efficiency and provide ease of operation for dApp developers and node operators. dApp developers can now call an existing contract on the blockchain using its address (without sending any Wasm code in the deploy) and by sending the arguments to the contract. This will minimize deploy size, ergo block size thus reducing the bandwidth required and increasing throughput. Also, to provide a flexible interface for the dApp developers, the Scala client has been updated to take both the contract WASM bytes and a list of arguments in Proto 3 JSON format. This release also adds 'Standard Payment Code' that is used as the default where no payment code is supplied for the deploy. Persistent deploy buffers, introduced in the last release, make use of nonce redundant to ensure sequential execution and prevention of replay attacks. We have therefore removed nonce in this release. We also introduce "Voting matrix", a high-performance implementation of "The Inspector" finality criterion that helps to identify finality of a block more efficiently (currently supports only acknowledgment level 1). This release adds a basic deploy selection strategy with a block size limit.

Detailed Overview

In previous releases, deploying a smart contract required that the calling dApp (first) hard-code arguments in the contracts (and then) precompile the contract (with arguments) into WASM.  Further, there were 2 sets of WASM bytes required: one for payment code and one for session code.  This design had two drawbacks: first, hardcoding arguments does not promote flexible application structure; and, the need to continually re-deploy the same basic contract is a waste of space on the chain.

This release addresses both of these usability issues. The deploy command can now accept a list of arguments for either (or both) of the payment and session contracts, as values of parameters --session-args and --payment-args.  It is a more flexible interface for dApp developers to use, but the original interface also remains. 

The list of arguments passed with --session-args and --payment-args should be a list of protobuf consensus.Arg objects serialized to Proto 3 JSON format, for example:

--session-args '[{"name": "amount", "value": {"long_value": 123456}}]

For detailed documentation and more examples see CONTRACTS.md.

Additionally, payment and session contracts previously stored on the chain can be called by providing the hash, uref, or name of the contract.    This cuts down on the amount of WASM passed and the amount of transaction data stored.  The following is a list of parameters now available in the deploy subcommand: 

-p, --payment    <arg> Path to the file with payment code.
--payment-hash   <arg> Hash of the stored contract to be called in the payment; base16 encoded.
--payment-name   <arg> Name of the stored contract (associated with the executing account) to be called in the payment.
--payment-uref   <arg> URef of the stored contract to be called in the payment; base16 encoded.
--private-key    <arg> Path to the file with account private key (Ed25519)
--public-key     <arg> Path to the file with account public key (Ed25519)
-s, --session    <arg> Path to the file with session code.
--session-hash   <arg> Hash of the stored contract to be called in the session; base16 encoded.
--session-name   <arg> Name of the stored contract (associated with the executing account) to be called in the session.
--session-uref   <arg> URef of the stored contract to be called in the session; base16 encoded.

Optimized Finalization: Voting Matrix

"Voting matrix" is a high-performance implementation of "The Inspector" finality criterion. The main idea is that every validator maintains a mutable data structure reflecting the most recent knowledge on consensus establishing process. This structure is a square matrix N x N. where N is the number of validators. The Cell (i, ,j) in the matrix reflects the information "V(i) can see V(j) voting for consensus value P.

The matrix is updated:

• every time V creates a new message
• every time V receives a message from the network

The key improvement in the voting matrix algorithm (as opposed to the "reference" algorithm described in "The Inspector" spec) is the incremental nature of the processing. Instead of restarting the whole finality detection from scratch on every new message appearing in j-DAG, it keeps a mutable representation of the "finality situation" accumulated so far, and incrementally updates this information on every new message. This saves a lot of computation time.

Voting matrix is an improvement over our current algorithm because it keeps the last known finalization score for each validator, for each DAG level in memory, which is continuously updated as new blocks are added. The finality of a block can be found more efficiently by looking up the current value in the matrix. The algorithm supports only acknowledgment level 1 (this is parameter K of finality detector specification).

Removal of Nonce

With the introduction of a persistent deploy buffer in the previous release, the nonce is no longer necessary to prevent replay attacks or guarantee sequential execution of conflicting deploys. The nonce has been removed from the API as well as from the Explorer, both the Scala and Python clients, GraphQL and the protobuf interfaces.  

Basic Deploy Selection Strategy:

This release adds a basic deploy selection strategy with a block size limit. The strategy is to lazily consume a stream of Deploys from the DeployBuffer and send it to the Execution Engine and collect commuting effects until it reaches the end of the deploy stream or reaches block size limit. There's a config parameter max-block-size-bytes (or CLI parameter --casper-max-block-size-bytes) that allow user to set the maximum block size (default is 10MB).

Standard Payment Code as default

If no payment code is supplied for the deploy, CL will assume the use of the standard payment code.  The standard payment code assumes that the calling account is the account paying for the execution of the payment and session contracts.  The following represents the standard payment contract. More complex payment contracts are possible, but this captures the minimum behavior to satisfy the payment logic.  The path to the WASM byte code can be found at ~/Casperlabs/client/src/main/resources/standard_payment_code.wasm.

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);
  }
}

Clarity (Formerly CasperLabs Explorer)

Rebrand to "Clarity"

New name

Faucet (Request Tokens)

New web interface

Deploy With Arguments

New web interface

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?

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

We have removed the nonce from deployments.  Nonce is used in Ethereum to prevent replay attacks.  We discovered that managing the nonce was difficult and quickly became the 'dApp developer's problem'.  The system will store the hash of the deployment and check whether the deploy has been seen by the node before. This will further simplify the amount of work required on the off-chain components of a decentralized application.

The most common mechanism for paying for deployments is 'sender pays', which means that the funds for payment are deducted from the account sending the deployment.  This mechanism is now the default payment mechanism.  If no payment code is specified, the system will deduct the funds from the account sending the deployment.  This simplifies the number of parameters required in a deployment.

Deployments can now accept a set of serialized arguments, providing more flexibility to dApp developers.  Application architectures with hardcoded arguments within it tend to become brittle and hard to maintain over time.  Being able to send serialized arguments to deployments will make dApp architectures simpler and more flexible.

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

Developers were able to send wasm code in their deployments and use nonces to prevent replay attacks. 

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

Developers will need to update their deployments to remove the nonce.  It is no longer required.  For deployments that need only basic payment code, no payment wasm is required as part of the deployment.  

Description of release packaging

Release packaging will include:

• Docker image
• 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?

You can find us on Discord!