About This Release
CasperLabs is pleased to announce our first public pre-production release of the node.
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 (of the distributed computer). Simple node metrics are now visible on Grafana dashboards. Users can also generate an image of the DAG created by a node.
A detailed overview of the notable features of the node is described below. A demonstration of node 0.1 was delivered during the CasperLabs launch event on February 22nd.
The Casper DAG
This release introduces the Casper block DAG (Directed Acyclic Graph) with a simple community of nodes coming to and maintaining consensus on blockchain state, known as “global state”. Validator identities and bond amounts are manually defined in bonds.txt on the bootstrap node. When the bootstrap node starts, it creates a genesis block using the information in bonds.txt, which it shares with all nodes that join the network. In this version of node, validators must be started using the private key that corresponds to the public key in bonds.txt in order to bond on to the network. Once all validators have joined the network, deploy processing and block proposal can proceed. In this version of node, all the validating nodes must be present before any deploys are processed.
Consensus forms the basis for security and reliability in the decentralized computer, therefore it is the central concept to any blockchain technology. The CasperLabs node implements Vlad Zamfir’s CBC-Casper Proof of Stake consensus protocol. Validators in this protocol must provide a bond in order to propose blocks and receive rewards. Proof of Work blockchain technology uses the concept of ‘longest chain’, which is where new blocks are added. In Proof of Stake, the concept of ‘longest chain’ is replaced with ‘fork-choice’. A block that is the fork choice is considered the block with the greatest weight/stake behind it. These weights are derived from a combination of parent justification messages and the stake weight of the block the validators have included in their local DAG. When a block becomes the fork-choice, validators have accepted the block as the tip of the ‘heaviest chain’, and have proposed new blocks with the fork-choice as the parent. Casper Proof of Stake has a concept of ‘shared future’ versus an exact replica of the blockchain on each node. This means that validating nodes can have slightly different DAG’s locally. When a block becomes the fork-choice tip, there are guarantees that the transactions contained within it are part of the canonical state of the decentralized computer.
The Casper Virtual Machine
A feature of the Casper architecture is concurrent execution of transactions. Transactions execute in separate instances of Wasm, and update the global state through functions. Transactions can run deterministically within the local state, independently of one another. Objects created in the local state do not persist after execution completes, rather, their execution effects are captured and mapped to transformations in the global state, which does persist.
The Global state is the state of the decentralized computer, which is replicated by the blockchain. It is accessed by a pointer (Ref) to some data in the global state. The ExecutionEffect can be thought of as a blueprint for a function GlobalState => GlobalState. That is, it encodes how the deploy would like to modify the global state. This effect is encoded by the pair (Map[Ref, Op], Map[Ref, Transform]), where the first component contains information about what the second does. The second component is used to perform the actual updates to the global state. Note that from an application perspective, the code is really performing the desired updates to the global state.
Nodes form a peer-to-peer network, constantly communicating with each other to reach consensus about the state of the Blockchain. A node is not necessarily a single physical machine, but it appears as a single logical entity to the rest of their peers by having a unique ID and address where it responds to requests.
Nodes periodically try to discover each other based on elements of the Kademlia protocol. Unlike the original Kademlia which uses UDP, nodes are using point-to-point gRPC calls for communication. The specifics can be found under Kademlia API.
At startup the nodes should be configured with the address of a well known peer to bootstrap themselves from. To discover other nodes they can pick from multiple strategies:
- Perform one-time lookup on their own id by the bootstrap node (which doesn’t know them yet) to receive a list of peers closest to itself. Recursively perform the same lookup with those peers to accumulate more and more addresses until there are nothing new to add.
- Periodically construct artificial keys to try to find peers at certain distances from id and perform a lookup by a random node.
CasperLabs intends on building a high performance node that uses system resources efficiently. The node emits a variety of metrics, which can be used to monitor its performance. Grafana dashboards are available as part of the Docker packaging which displays these metrics.
Getting Started with Node 0.1
The easiest way to work with Node 0.1 is to use Docker.
- Pull the docker images
- Obtain contract examples
- Compile the contracts
- Spin up Grafana
- Send the deployments
- View the metrics
- View the DAG
I would like to thank the development team for their hard work and community members for their continued support.
We welcome comments and feedback in our developer channel at https://forums.casperlabs.io
This is pre-release software, it has some known issues.
Please file issues on our Github: https://Github.com/CasperLabs/CasperLabs/issues
Expect more releases in the coming months as we build the Casper blockchain. More information is available at https://casperlabs.io