Skip to content
Pre-release
Pre-release

@arcolife arcolife released this Aug 16, 2019

Technical Description & Scope of Work:
This release extends the functionality of DevNet launched in the last release 0.5, by adding more features. Smart contract deploys can now require payment, in the form of tokens, to be supplied in order to be executed. Successful execution of the payment and sessions contract would depend on whether or not sufficient payment was supplied and excess tokens will be returned to a user-specified refund purse. This feature is turned "off" by default, but can be enabled with a command line flag when invoking the execution engine (details below). WARNING: the payment code for ALL nodes in the network must be turned on for consensus to reach finalization. The CasperLabs Devnet nodes do NOT have this turned on, so validators who wish to bond to Devnet must keep payment off for now.
This release also allows accounts to associate multiple public keys with the account. This feature is useful to get access to the account in case the "main key" is compromised. A previously associated key can be used to deploy contracts on behalf of the main account. The CasperLabs Explorer has been expanded to include the ability to view/traverse the blockchain DAG, and to access a GraphQL console for the blockchain. The CasperLabs Explorer can be found at explorer.casperlabs.io

Assets 12
Pre-release
Pre-release

@TomVasile TomVasile released this Jul 13, 2019 · 634 commits to master since this release

Merge pull request #839 from CasperLabs/release-v0.5

Release v0.5.1
Assets 12
Pre-release
Pre-release

@TomVasile TomVasile released this Jul 10, 2019 · 769 commits to master since this release

This release completes the necessary features to support a public DevNet. The objective of Devnet is to provide a working Casperlabs proof-of-state network that provides the first CasperLabs network to run distributed applications (dApps). With this release, CasperLabs will host 4 public nodes that will accept deployments from dApp developers as well as bonding requests from public nodes that want to join the network as a validator and participate in Proof-of-Stake consensus. A faucet exists to provide tokens to bond as a validator.

Assets 12
Pre-release
Pre-release
Pre-release

@TomVasile TomVasile released this May 18, 2019 · 2817 commits to master since this release

Update to v0.3 to add functionality that makes the lmdb map size configurable and sets a default map size of 1 GiB.

Assets 13
Pre-release
Pre-release
Pre-release

@TomVasile TomVasile released this Apr 9, 2019 · 3386 commits to master since this release

This release introduces physical storage for the global state key value store. The global state will need to persist on the nodes, and this is the first body of work to support this persistence. The Casper VM is more stable due to improved usage of idiomatic type-safety constructs and more descriptive error messages. There is also extensive unit testing in place and integration tests have been enabled, both of which captured issues which were addressed (see tickets). A new GossipService has been introduced to optimize block propagation throughout the network. This service will be fully operational in the next release. Cost of execution is calculated and returned and can be viewed as part of log output. Object capabilities has been implemented to enforce permission based security, paving the path to minting tokens in a future release.

Assets 14
Pre-release
Pre-release

@TomVasile TomVasile released this Mar 4, 2019 · 4099 commits to master since this release

In this version of node the CBC-Casper consensus protocol is running. Smart contracts are deployed for storage and execution, nodes come to consensus on blocks and build a Directed Acyclic Graph (DAG) and maintain a global state. Simple node metrics are now visible on Grafana dashboards. Users can also generate an image of the DAG created by a node.

Release Notes:

  • The node does not persist the state upon restart. If the node is part of a network, and restarts, this could lead to the node 'forking' off the DAG
  • Block merging is naive, and may lead to different post states even when deployments are run in the same order.
  • All deploys must be made from the same account "--from 00000000000000000000"
  • Fault tolerance calculation is naive and may yield different results
  • Block validation is naive
Assets 11
Pre-release
Pre-release

@TomVasile TomVasile released this Jan 24, 2019 · 4646 commits to master since this release

This release will verify our restructuring by executing a simple "Hello World" smart contract written in Rust. The base architecture is forked from RChain with some major modifications. Unlike RChain, it is not a monolith build, but a series of "components" implemented in different languages chosen to optimize the functioning of each layer and to best position the blockchain for development adoption. There are four layers: Node, Consensus, written in Scala; and the parity Wasm execution engine. The use of different languages requires that the Node layer is extended to include inter-process communications (IPC) to send messages between the Scala/Rust layers. The Storage layer is non-functional in this release as storing blockchain state is not necessary to execute Hello World.

Assets 5
You can’t perform that action at this time.