CasperLabs Releases Node 0.2
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.
- Unforgeable: Specific unforgeable Refs cannot be re-created by any source code, though new, yet unused ones, can be. Unforgeable references enable Capabilities security by allowing applications to delegate authority (e.g. to access data or perform some action) using these references. Note: A read-only unforgeable reference can be created from the complete reference.
- Account Address: These addresses are forgeable — they can be written down by anyone at any time, however, the account security is maintained via cryptography.
- Contract hashes are (as the name would suggest) derived from the hash used to label a contract stored on-chain. These hashes are derived from the triple (public key, nonce, ID), where the public key and the nonce come from the account that made the deploy which is storing the contract and the ID is simply a sequential identifier allowing each deploy to store multiple contracts and still have a unique hash for each of them. Like addresses, these are forgeable keys.
Values
- Unforgeable Refs point to a mutable cell of some data type. The basic supported data types are: Int, String, and Float. Additionally, products (tuples) and arrays of the basic types are supported. Moreover, “Smart Contracts” are also an allowed data type. The precise definition of “Smart Contract” is left purposely vague here because we want to remain agnostic to the detail of the local state.
- Account address Refs, as the name would suggest, have a corresponding value which is an account.
- Contract hash Refs, reference “smart contracts”. The security is maintained via immutability instead of cryptographic authentication. The contract referenced by a hash is immutable by a rule enforced by the runtime.
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
- Determines the particular global state to query. The post state of the block with the given hash is used.
- The hash is presented as a base-16 encoded string.
Key type
- Specified the type of key from which to start the query. Allowed values are “address”, “hash” and “uref”, same as the types of keys described above.
Key bytes
- The bytes which are used to identify the particular key. URef and Hash type keys use 32-byte identifiers, while Address uses only 20 bytes (these bytes are commonly known as the account address).
- The bytes are presented as a base16-encoded string.
Path
- The sequence of human-readable names which can be used to reach the desired key to query. This makes use of the human-readable name associations accounts and contracts have for keys.
- The path is presented as a ‘/’-separated string of identifiers.
Description of release packaging
Release packaging includes:
- Docker images available via DockerHub
- Debian package
- RPM package
- tar.gz (EE Mac variant included)
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?
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.
