Reference
Document status |
| ||||||
Release status |
|
Milestones
Start date |
|
Release |
|
Stakeholders
CTO | ||
CEO |
Development team
Program manager | Project Manager | Engineering Lead | SRE |
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)
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
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.
There are 2 modes at the network level that are supported, a closed loop network of validating nodes and an open network of gossiping nodes. A validating nodes is aware of its' trusted gossip node & the other validating nodes. The gossiping nodes are aware of their trusted validator node & all the other gossiping nodes in the network. Ashok Ranadive (Unlicensed) I believe we are not doing the closed loop anymore.The maximum supported network size is 5 nodes by the end of this release. Create the metrics module, nodes will report the following telemetry:
Peer count
Nodes will provide something around logs - is it possible to use what the EE has built for logging? Tom Vasile (Deactivated) should tell us what is useful in the logs versus the ‘/status’ endpoint.
Status endpoint that emits the peer count.
Work will be done to prepare STESTS for the new rust nodesome logs from the inception. It is possible to see that the nodes are connected from the logs.
Tickets for this Release
Features/Stories
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Defects Fixed
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
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