CasperLabs releases Node 0.9

BlockDAG in Highway with leaders and summits

CasperLabs is pleased to announce the release of Node 0.9*. In this release, we implement ‘Deploy Dependencies’, which lets users explicitly enforce an ordering to their deploys.

About this Release

As CasperLabs prepares for its public TestNet release, this release introduces many improvements. Node 0.9 includes enhancements to the GraphQL interface and optimizations to improve stability and performance of the system.

Imposing a total order on Deploys

The CasperLabs blockchain processes blocks concurrently. Contract authors may have specific requirements to impose a total order on their deployments. With Deploy Dependencies, users can explicitly enforce an ordering to their deploys. This important feature addresses use-cases where ordering of execution of deploys in a certain manner is essential for success of the task (e.g. I can’t pay my rent until my salary is deposited into my bank account).

Extended GraphQL schema

The GraphQL schema has been updated to include the following:

• Query the deploys of any account
• Obtain the latest deploys

Payment Amount is required

With Node 0.9, deployments must include the payment-amount parameter and specifically the amount of ‘100000000’. This is a temporary requirement, as the payment-amount parameter specifies the maximum amount of token that the caller is willing to pay for a transaction.

casperlabs-client --host localhost deploy --session ~/casperlabs-counter/target/wasm32-unknown-unknown/release/counter_define.wasm --payment-amount 100000000 --private-key ~/keys/Myprivate .private.key

To see the full set of features in the client, run the client with the help option.

casperlabs-client --help

Other changes in this Release

Improved Usability

The contract_api module was broken into logical groupings of functions and made more explicit via sub-modules. This improves the user experience around discovering what capabilities are made available by the contract_api. The groupings are:

• account.rs
• contract_ref.rs
• error.rs
• runtime.rs
• storage.rs
• system.rs

and can be found at contract_api.

New Client Features

• Users can explicitly state which instance of the CasperLabs blockchain a deploy is being sent to. The — chain-name option can be set during deployment. If set, it has to match the chain name in the ChainSpec on the validator that receives the deployment.
• Users can now print information of a deploy created by make-deploy and possibly modified by sign-deploy. The “print-deploy” command is configurable to:
• use either JSON or Protobuf text encoding
• use base16 bytes encoding or default one which is base64 for JSON and ASCII-escaped for Protobuf text encoding

System Optimizations:

• The algorithm for initial synchronization when a peer joins a network has changed to start at the Genesis Block and traverse forward until tips (previously it was getting tips from peers and then traversing back to the Genesis block.)
• Ensuring a validator doesn’t try to propose more than 1 block at the same time is essential to avoid equivocations. However, serializing the block processing itself for blocks created by other validators was an artificial restriction that limited throughput. In this release we remove the blockProcessingLock from MultiParentCasper that only allowed the node to process 1 block at a time. Now, the BlockAPI will take out a proposal lock, so a validator will not propose 2 blocks at the same time and the DownloadManager will feed the blocks in topological order to addBlock.
• We have optimized the way a Node handles backoff by switching to alternative sources when it can (even by interrupting its own backoff if an alternative pops). Only if all alternatives failed will a Node back off before trying again.
• Requeue orphaned deploys before proposing a new block rather than after adding blocks from any other validator.
• Optimized the Fork-choice by preloading the DAG Store and store data in CachingDagStorage on inserts and lookups. During lookups we cache not only a single block but its neighborhood — blocks from the past and future. The radius of the neighborhood is configurable during construction.
• Block Validation: When block is received, node will validate that it was built using correct protocol version and mark block invalid if it wasn’t.
• To defend against malicious repeated downloads, a new component RateLimiter which allows limiting the rate of arbitrary F[A] has been added. This component is used to rate-limit the getBlockChunked intra-node RPC. The rate limitation is disabled by default.
• The contract-examples directory has migrated to CasperLabs/execution-engine/contracts/examples and the build process has been updated to be aware of the new location. The directory where they had previously been located has been deprecated. It is probably best to refresh and delete the deprecated directory.
• Improved time to create blocks by copying deploy summary and body into buffered_deploys table to eliminate joins with the full deploys table.

Get Started with this release

At release, links to installation packages and relevant documentation is available on GitHub.

• Packages available on GitHub
• Docker images available via DockerHub
• Debian package
• RPM package
• tar.gz
• Docs available on GitHub (Wiki)

Where will bugs be filed?

Report a bug on GitHub

Where do developers go for support?

Join our community on Discord https://discord.gg/Q38s3Vh.

About CasperLabs

CasperLabs is building a transformative blockchain for all applications that require a high degree of security, fast execution, and predictable economics. Our technology is built on the purest implementation of the proof-of-stake CBC-Casper protocol. We deliver a fully-decentralized, permissionless, public, and open source blockchain platform that supports developers with robust tools, application insights, and predictable fee structures.

*Late announcement