Reference

Milestones

Stakeholders

Development team

Marketing team

Release Overview

Simple Overview

With this release we announce several features that support smart contract development on the Casper blockchain including Contract Headers, support for Ethereum keys and Contract Upgrades.

Detailed Overview

Contract Headers provide a mechanism for developers to specify public entry points into the functions of on-chain contracts. Contract arguments can also be named & typed, enabling arguments to be passed in any order when the contract is called. It’s also possible to invoke the contract as a session contract or a stored contract. Casper now supports signing of transactions with Ethereum keys (secp251k1), providing a smoother UX for dApps that need to work across Casper and EVM blockchains. Host side transfers enables a user to perform a transfer of a specified amount of tokens from a Purse in their account to another Purse without providing any wasm in the deployment.

Enhancements for developers

• Contract Headers

• Multiple key support for accounts

• WASM-less transfer
  
  

Work to support Testnet

Address issues discovered in the Testnet. Improve the performance of token transfers by moving the logic into the host module. Token transfers on the system will now use this contract versus contracts stored in the global state.

• Fixes to stabilize Testnet.

• Host side Token Transfer contract (Improves performance)

Work on the Rust implementation

By the end of this release cycle, we should have nodes peer up and exchange messages with each other. Peers can discover each other and send messages to one another. We should be ready to deploy this new node to an LRT and point a new version of STESTS at it.

The maximum supported network size is 5 nodes by the end of this release.

Nodes provide some logs from the inception. It is possible to see that the nodes are connected from the logs.

Tickets for this Release

Features/Stories

Defects Fixed

Metric for tracking the success:

What is special about this release?

This release completes the implementation of  Contract Headers.  Contract headers enable developers to specify the public entry points for their contracts. It’s possible to specify headers for functions within the contract, and not just the contract itself. Contract arguments will be named as well, which enables contract authors to send parameters in any order. Contract headers also provide the necessary features to support contract versioning for both the supported protocol version and contract version - enabling upgrades for a given contract. We introduce the notion of contract packages, which enable this notion of contract versioning. All the versions of a contract are stored in the package.

Ethereum keys are now supported by the system in addition to ed25519 keys for user accounts. Bonding wallets must use ed25519 keys.

For dApp Developers 

For Node Operators

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

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

Developers were able to invoke their stored contracts with the basic ‘call()’ method and send in runtime arguments in the same order they were specified in the contract when it was defined. Developers had to obtain the context of the account where the contract was stored before calling the contract. This was the only way to obtain the contract’s own context for execution.

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

Developers can specify if a stored contract will be executed as session code or a stored smart contract.

Developers can specify headers for methods in their contract and specify whether these methods are public or accessible for groups of accounts. Now the context for a contract need not be obtained in order to call it. Only the header information and is required.

It’s possible to name arguments in the contract definition. Once named, arguments can be passed to the contract in any order. Contract arguments need to be typed. CasperLabs has a type system that is enforced throughout the system, something that is important to reduce unintended behaviors in applications due to unenforced type mis-matches. (ex: string for an int and vice versa).

Description of release packaging

Release packaging will include:

• Debian package 

• Docker image

• Brew packages

• 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