Node 0.1 Release Plan
Reference
Document status | APPROVED |
Release status | RELEASED |
Related pages |
Stakeholders
Name | Role | Reviewed? |
| Medha Parlikar | CEO, CasperLabs | |
| Former user (Deleted) | CTO, Adaptive Holdings |
Development team
Program manager | Project manager | Developer | Developer | Developer | SRE | Page owner |
| Medha Parlikar | Rita Allen (Unlicensed) | Former user (Deleted) | Mateusz Gorski | Former user (Deleted) | Tom Vasile (Deactivated) | Rita Allen (Unlicensed) |
Marketing team
Marketing lead | Content owner |
| TBD | TBD |
Release Overview
Simple Overview
Casper consensus 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.
Detailed Overview
This release introduces the CasperLabs block DAG (Directed Acyclic Graph) with a simple community of nodes coming to and maintaining consensus on blockchain state, known as "global state". Validating nodes must be part of the network before the first block is proposed. 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 de-centralized 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 validators have included the block 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 distributed computer.
Node Features
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. According to this protocol every Node has the following properties:
idis a Keccak-256 digest of the Public Key from the SSL certificate of the nodehostis the public endpoint where the node is reachablediscovery_portis where the gRPC service implementing theKademliaServiceis listeningprotocol_portis where the gRPC service implementing the consensus related functionality is listening
The KademliaServiceitself has to implement only two methods:
Pingis used by thesenderto check if the callee is still alive. It also gives the callee the chance to update its list of peers and remember that it has seen thesendernode.Lookupasks the node to return a list of Nodes that are closest to theidthesenderis looking for, where distance between two Nodes based on the longest common prefix of bits in theirid.
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
idby 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
idand perform a lookup by a random node.
Clients send Deploys to one or more nodes on the network who will validate them and try to include them in future Blocks. To do this Clients need to make a call to the DeploymentService. The specifics can be found under Deployment API.
Global State
The Global state is the state which is (implicitly) replicated by the blockchain. It is accessed by a Ref - A pointer to some data in the global state. Op is an ADT describing the possible ways a deploy could interact with a Ref. Op forms a commutative monoid. Op is used to track the commutative properties of the interaction with 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.
State query mechanism - Need to find out, observe the safety of a block
They can view the DAG that is created
The global state is a key/value data store, described below:
Keys
A Ref corresponds to a key in the global state. The keys come in three flavors: 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 OCaps 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.
Metrics
Grafana dashboards have been integrated into the node to display memory usage, CPU usage, deploys received, blocks proposed
Block counts on a given node, helps to observe how blocks propagate through the network.
Using the tools to spin up a 3 node network - Link to Docker/readme.md enables the user to observe these metrics and send deploys to the node.
Metrics for Memory, CPU, DeployNode Features (includes Metrics)
- Block Passing
- Nodes connect to bootstrap
- Nodes form p2p network, perform handshake and connect to each other
- Unit Tests
Execution Engine Features
- Continued support of contract execution
- Login and contract execution
- Return cost of execution
Consensus Features
- Block passing and simple gossiping
- Fork choice rule
- Counter contract
- Integration Tests
Storage Features
- BlockDAG
- Global State
- History and Rollback
Operations
- Grafana Dashboards for Metrics
- Test Execution
Metric for tracking success
- Demonstration of Consistent, Persistent Global State
- Grafana Dashboards exist and reflect behavior
What is special about this release?
This release introduces the CBC-Casper fork-choice rule, and the requisite global state storage mechanism that supports the state trie. Contract authors can create objects in the global state and reference them.
Are we doing something differently? If so, why are we doing it this way?
We have separated execution into several phases to enable concurrency (future release) and more efficient use of memory when updating state. During contract execution, a temporary local state is used to update the blockDAG and record changes; these resources are released once execution is complete. Updating the global state of the blockchain is done separately based on the changes recorded during execution. This structure maximizes the possibility for executing deploys in parallel as well as updating the global state in parallel. Increased parallel processing will potentially increase performance and allow more transaction throughput.
We are hard-coding validating nodes and associated accounts for this release. This is because we have not yet implemented validator bonding contracts.
Before these features were available, what were developers able to do?
The previous release demonstrated that our architecture could support execution using a WASM interpreter and a mix of Scala and Rust components with acceptable performance. This release extends the proven architecture by supporting consensus logic: execution of smart contracts and the maintenance of a persistent and consistent global state.
After these features launch, what will developers be able (and not able) to do?
Developers will be able to create a network of validator nodes, deploy contracts, propose blocks and observe the fork-choice rule. Developers will also be able to view the in-memory DAG
Description of release packaging
Release packaging will include:
- Docker image (Supported on Linux only)
- Debian package
- 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