Lisk Core Overview

Introduction

The Lisk Core is the program that actually implements the Lisk Protocol. In order to run a node which will participate in the network the Lisk Core must be installed. Furthermore, this also applies to every additional machine that is required to run a node.

Setting up the Lisk Core provides the user with the following options:

  • The ability to connect to a Network and communicate with other nodes in the network.

  • To have full control to configure the Lisk Core to specific and custom requirements.

  • To create your own Snapshot of the blockchain.

  • Use Lisk Core to perform actions on the Lisk blockchain, e.g. with Lisk Desktop.

  • Forge new blocks, (for active delegates).

An instance of the Lisk Core and a Lisk Peer can generally be defined by the following two statements below:

A Lisk Core instance connected to a network is referred to as a Lisk Node.

A Lisk Node connected to other Lisk Nodes is referred to as a Lisk Peer.

Both statements above refer to a machine which in turn now becomes a server, after the Lisk Core has been installed and executed. Subsequently, the server now participates in the network and provides the blockchain data to it’s clients.

Getting started

What is a node?

The Lisk blockchain is a decentralized network that consists of many different servers, (or nodes). Node operators are required to set up Lisk Core on a server, and then connect it to the desired network.

There are over 600 nodes around the world that are maintained by individuals, and these nodes communicate with the network. For example, by broadcasting and receiving blocks or transactions from their peers. In addition, Lisk nodes are also required to forge/add new blocks to the blockchain. It is possible to view the live network statistics by accessing the following URL: Lisk’s Blockchain Explorer.

Who should operate a node?

If you fall under one of the following categories listed below, then it is recommended to set up your own node:

  • Exchanges and other services that rely on a stable API interface to the network.

  • Delegates who have registered a delegate and would like to actively forge.

  • Users who do not trust external sources and want to be in full control over their node.

Why operate a node?

There are several advantages why one would wish to set up a node:

  • To have your private entry point to communicate with the network. This is especially important when running an exchange and implementing LSK tokens.

  • To acquire full control in order to configure the node to your specific requirements.

  • To create your own Snapshots of the blockchain.

  • To have the option to Forge new blocks (assuming you are an active delegate).

To learn how to set up a node, please go to Getting Started

Networks

The Lisk Core can be connected to different networks. Please be aware that there are two key accessible public networks existing which are entirely independent of each other. These are the Mainnet and the Testnet which are described below:

Mainnet

The Mainnet is where the true Lisk economy exists. Within this network the Lisk users can transfer LSK tokens from one account to another, register accounts as delegates; and vote for other delegates or register dApps. For further information, please visit the Lisk Explorer.

Testnet

The Testnet is an independent replica of the Lisk Mainnet, whose main function is to test the upgrades first before they are run on the Lisk Mainnet. Subsequently, this is where new/updated versions and fixes of the Lisk Core are tested. For further information, please visit the Lisk Testnet Explorer.

Distributions

Lisk Core supports the following three distributions listed below:

  • Binary

  • Lisk Commander

  • Docker

  • Source

This is the default procedure to setup the Lisk Core. The Binary installation consists of a simple and mostly automated procedure to set up the Lisk Core. This includes almost entirely automated update scripts, coupled with a selection tools to help seamlessly maintain a Lisk Node.

Use Lisk Commander to conveniently install and manage Lisk Core.

Docker adds support for running a Lisk node with other platforms. For example, running a Lisk node inside of a Docker in Windows, and then connecting it via a custom Node on Lisk Desktop to Lisk Core, without the need to rent an additional server.

This is designed for anyone wishing to develop and code on the Lisk Core codebase. It also consists of an extensive test-suite. Please see more detailed information in the README file. The installation from Source enables a developer to work on the latest codebase for the Lisk Core, which may not yet have been tagged for a release.

Snapshots

A snapshot is a backup of the complete blockchain. It can be used to speed up the sync process, instead of having to validate all transactions starting from genesis block to the current block height. Lisk provides official snapshots of the blockchain which can be found in the following link: http://snapshots.lisk.io

How to both rebuild from a snapshot, and to create your own snapshots is explained in the Administration section for each distribution of the Lisk Core.

It is recommended to use Lisk Core Binary for creating your own snapshots, as a script is provided to conveniently create snapshots.

Technology stack

The Lisk Core consists of the following 4 main technologies:

  • Node.JS

  • Swagger

  • PostgreSQL

  • Redis

Node.js

Node.js serves as the underlying engine for code execution in the Lisk Core. Node.js is an open-source, cross-platform JavaScript run-time environment, that executes the JavaScript code server-side. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.

Swagger

Swagger is an open source software framework backed by a large ecosystem of tools that helps developers design, build, document, and consume RESTful Web services. As part of the Lisk Core documentation, the whole API specification can be explored interactively via the Swagger-UI interface.

PostgreSQL

PostgreSQL is a powerful, open source object-relational database system with over 30 years of active development; subsequently it has earned a strong reputation for reliability, feature robustness, and performance. All Information on the Lisk mainchain is stored inside of the PostgreSQL databases.

Redis

Redis is an open source, in-memory data structure store. Lisk Core mainly uses it to cache API responses. This prevents performance drops in the application. For example, when the same API request is sent repeatedly.

Versioning schemes

Lisk Core is described in 2 different versioning schemes. The Software Implementation Version and the Protocol Version as described below:

Software implementation versioning

All Lisk Core software changes except for the logging system, are communicated following the exact rules specified by the SemVer.

Software implementation versioning has a version prefix v followed by a 3 digit notation <MAJOR>.<MINOR>.<PATCH> , whereby the individual digits represent the following types of software changes shown below:

v<MAJOR>.<MINOR>.<PATCH>

v     - Version prefix
MAJOR - Breaking change
MINOR - New feature
PATCH - Bug fix

The software implementation version follows the popular SemVer scheme and provides a quick overview for developers about breaking and non-breaking changes in the software.

Protocol versioning

The protocol version is denoted by two digits, H.S.. The first digit, H, depends on the number of hard forks, and is incremented with each hard fork. S represents the number of soft forks since the last hard fork.

The initial protocol version 1.0 is defined as the version that was implemented by Lisk Core v1.0.0.

For example, the protocol version is used in P2P communication between Lisk Core nodes, in order to determine if the nodes have compatible versions of the Lisk protocol implemented.

Update vs Migration

When to update, and when to migrate Lisk Core?

Every time that a new Lisk Core software update is performed, this introduces a hard fork in the network, it is necessary to migrate your existing Lisk Core version.

In all other cases the normal update process can be performed, according to the distribution being used. Please see the following upgrade processes listed below: