Lisk Core

Overview

The Lisk Core can be defined as a blockchain application running on the Lisk Mainnet that implements/enforces the Lisk protocol, enabling a user to easily set up a node and participate in the network. To provide a high level overview, the main functionalities are listed below:

  • The possibility to connect to a subset of peers in the Lisk mainchain’s P2P network.

  • To synchronize with the Lisk blockchain including requesting, forwarding and processing of the blocks, which also contain the transactions.

  • To maintain the transaction pool, which might contain a subset of unconfirmed transactions.

  • To request and forward the unconfirmed transactions.

  • To possibly generate new blocks when running a validator node.

Furthermore, Lisk Core nodes are able to store all current addresses, balances, and transactions.

With the latest version of Lisk Core, there will be new configurable settings and the modules described in the Modules sub-section will also be used.

To migrate from Lisk Core v3 to v4 please follow the migration process as covered in the migration guide.

Migration overview

The Lisk SDK v6 has introduced some new configurable settings, including certain constants that need to be specified for each chain, which must also be specified in Lisk Core v4. A brief overview of the migration process from Lisk Core v3 to Lisk Core v4 is depicted graphically in the illustration below in Figure 1.

migration v3 v4
Figure 1. Migration process overview

In Figure 1 above, the blocks in pink are generated by the Lisk Core v3 nodes, including the state snapshot. The snapshot block is shown in green, and is generated by the migrator tool. Finally, the blocks in yellow are generated by the Lisk Core v4 nodes post migration.

Modules

Within Lisk Core v4, the following modules will be registered and used in the specified order:

  • Auth

    • The Auth module is responsible for handling and verifying nonces and for transaction signature validation, including transactions from multisignature accounts.

  • Validators

    • The Validators module is responsible for validating the eligibility of a validator for generating a block and the block signature. Furthermore, it maintains information about the registered validators in its module store and provides the generator list.

  • Token

    • This module allows any chain in the ecosystem to handle and transfer tokens in a coherent, secure, and controlled manner. Furthermore, the Token module also handles cross-chain token transfers.

  • Fee

    • The Fee module is responsible for the handling of the transaction fees, including the extra command fees, (e.g., the validator registration fees, relayer fees, etc.). It allows chains to choose the token used to pay the fee, and to define a minimum fee for the transactions to be valid.

  • Interoperability

    • The Interoperability module provides basic functionalities to transmit information between interoperable chains in the Lisk ecosystem using cross-chain messages. In addition, it also supports / defines the chain lifecycle.

  • PoS

  • Random

    • The Random module handles the validation of the inputs and computation of outputs for the commit and reveal process for a Lisk blockchain. Hence, it manages the validation of the inputs for the commit and reveal process, as well as the random seeds that are used for delegate ordering in a round, and also for picking standby validators.

  • Dynamic Block Rewards Module

    • The Dynamic Block Rewards module is responsible for providing the base reward system for the Lisk blockchain according to the delegate weight. It computes the block rewards according to the delegate weight for active delegates, and includes specific logic for rewarding the standby validators. The rewards will now be automatically shared using an on-chain reward sharing mechanism, more details on this can be found here.

  • Legacy

    • The Legacy module maintains all accounts on the Lisk mainchain that received balance transfers to their address in the old 8-byte format, and for which no public key is associated. The Legacy module also implements a command allowing delegates without a BLS key to register one.

Within the protocol used by Lisk Core v4, each validator needs a separate key known as a generator key in order to generate blocks. More information on the generator key can be found here in LIP 0044.

The state of an interoperable chain in the Lisk ecosystem is maintained in a global state store. Furthermore, as a part of the interoperability solution, validators of each chain certify the current state of the chain. The certification is performed by using certificates that are signed once the block is finalized and used in cross-chain communication. In addition, the new certificate generation mechanism verifies all the required information for the cross-chain updates, including the state root, which allows the authentication of cross-chain messages, and the validators hash, which authenticates the validators changes, and therefore the signers of future certificates.

Finally, a new event mechanism has been introduced designed to emit events from the application domain during the block processing. These events are included in a sparse Merkle tree (SMT), as leaf nodes. Hence, the root of the SMT being the event root, is added as a new property to block headers. Using the event root, it is possible to provide inclusion or non-inclusion proofs for events, proving whether an event was emitted during the block processing.

Module State Store

Within the chain each module that is registered defines its own state and the possible state transitions. The state transitions could be induced by the transactions defined within the module or the methods that can be called by other modules.

Within Lisk core v4 an updated state storage will be used. This new state architecture is now substantially different, as previously, the state of a chain was organized per account rather than per module. For example, a user’s balance would be stored together with all the other properties related to that specific user. Alternatively, with the new state model, the balance of a user is stored in the token module state and is separated from the properties of other modules, (e.g. public keys).

The chain maintains a global state store, which can be determined as a collection of key-value pairs defining the state of the blockchain. Following the modular architecture, the state store is further split into several module stores, namely, collections of key-value pairs that are defined within the state specific to the module.

The state tree is the sparse Merkle tree built on top of the state store. More information on SMTs can be found here in LIP 0039.

The illustration below in Figure 2 depicts the general structure of the state sparse Merkle tree for a Lisk blockchain using two application-specific modules. The state root is the Merkle root, and as described above each module defines its own module store. The keys of the leaf nodes start with the store prefixes, so that each module subtree is separated from the others. Please note, not all modules are shown in this illustration.

state tree
Figure 2. State sparse Merkle tree

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 almost 2,000 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 Core nodes are also required to generate/add new blocks to the blockchain.

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.

  • Validators who have registered as a validator and would like to actively generate new blocks.

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

Why operate a node?

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

  • To create your own snapshots of the blockchain.

  • To create transactions and send them to the network.

  • To have the option to generate new blocks, (assuming you are an active validator).

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

To learn how to set up a node, please see the NPM setup page.

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 networks are covered below in this section.

Chain Identifiers

The chain identifiers (synonymous to the previously known, network identifiers), are mainly used within the interoperability protocol in order to distinguish between different blockchains running in the ecosystem. In addition, they are also used for transaction, block header, and arbitrary signatures, whereby they are able to prevent replay attacks and the re-usage of signatures. More information on chain identifiers can be found in here in LIP 0037.

Therefore, network identifiers (nethash), are not exposed anymore, and the network can be determined based on the chainID. Chain identifiers are 4-byte values, and the first byte is set to the CHAIN_ID_PREFIX_MAINNET for chains running in the mainnet network, and hence to the CHAIN_ID_PREFIX_TESTNET for chains running in the testnet network. The most significant byte within the chainID is the first byte which is used to determine the network, and the remaining 3 bytes are used to determine the chain.

Table 1. Public networks of Lisk
Network Port (default)

Mainnet

8001

Testnet

7001

Network Name Type ChainID Prefix

Mainnet

CHAIN_ID_PREFIX_MAINNET

bytes

0x00

Testnet

CHAIN_ID_PREFIX_TESTNET

bytes

0x01

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 validators.

Mainnet blockchain 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.

To start using the Testnet, please download your free LSK Testnet from the Testnet faucet.

To connect to the Testnet via Lisk Desktop, simply enable the "Network Switcher" in the settings and then use it to switch the network to Testnet.

APIs

Table 2. Available APIs for Lisk nodes
API Transport Architecture Port (default) Comment Reference

RPC Endpoints

WS

RPC

Depends on the network, see: Networks

To enable, enable RPC websockets in the node config.

RPC endpoints

The Lisk API documentation can be found here.

Token

The native token for the Lisk Mainchain is the LSK. Each LSK is further subdivided into 108 Beddows. At this time there are no other tokens supported.