CasperLabs Releases Node 0.2

Medha Parlikar
Apr 16 · 4 min read
Example Rust code creating urefs

CasperLabs is pleased to announce the release of Node 0.2. With this release, dApp developers can associate a contract with an unforgeable name, and the VM is more stable due to improved usage of idiomatic type-safety constructs and provides more descriptive error messages. Execution costs are calculated and returned and can be viewed as part of log output.

It is possible to run a Docker network of 3 nodes on a standard personal computer using a single command. Our packages are also now registered with yum and apt for simpler upgrades.

The CasperLabs node runs smart contracts that compile to WASM. Presently, compilation targets for C/C++ and Rust are available. With this release, the CasperLabs system supports the upgrading of contracts through Capability Security Model.

Smart Contracts are stored under unforgeable (unguessable) references. Before this release, contracts had to be stored under a reference generated by the system only. Now dApp developers can associate a contract with an unforgeable name. Once a contract has been stored under a hash, it is immutable. Contract authors can share this unforgeable name to their contract, so others can invoke the contract. If the contract author wants to change the behavior of their contract, they can replace what the unforgeable name points to (because they own the unforgeable name, they can write to it). Once that is done, the new version of the contract is presented to who ever is invoking the contract via the unforgeable name.

Unforgeable references now have a type associated with them. A Ref corresponds to a key in the global state. The keys come in three types: unforgeable, account addresses and contract hashes.

Values

The ability to maintain consensus on state with minimal overhead is crucial for scalability of the blockchain. The team is beginning work on a new service for block gossiping. In the existing paradigm, all nodes receive all blocks (in entirety) and in turn gossip all blocks received (in entirety) to all other nodes. This is inefficient on several levels: the amount of data (entire blocks) that is passed quickly floods the network; the messages sent between peers are unnecessarily duplicated (overwhelms the node); and nodes send messages to other nodes unnecessarily.

Developers can perform enhanced state queries. The API for the state query has the following structure. Querying the global state provides information such as transaction safety, contract data, block and transaction information.

The State Query API has been documented in USAGE.md.

The queryState gRPC method of the CasperLabs node accepts a message with four parameters:

Block hash

Key type

Key bytes

Path

Description of release packaging

Release packaging includes:

Where do developers go to learn more and get started?

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

Where will bugs be filed?

File Issues on GitHub

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

Visit https://forums.casperlabs.io with questions, members of the core development team will respond.

CasperLabs

Building the decentralized future

Medha Parlikar

Written by

Building the decentralized future

CasperLabs

Building the decentralized future