Key concepts of the Lisk SDK blockchain

What is a blockchain?

At its core, a blockchain is a database shared across multiple computers.

Triggers for the database operations are called transactions The data contained in a transaction specifies the operation to be performed.

In an account-based blockchain, the validity of a new transaction is checked against a database of user accounts. An account is a portion of the database identified by the account address. This is opposed to UTXO-based blockchains (such as Bitcoin, see Wikipedia page), where there is no concept of account and the validity of a transaction is based on a database of referenced past transactions.

The cost of processing the transaction and updating the blockchain is specified in the transaction fee and paid using tokens.

Transactions are shared among nodes connected in a P2P network and are grouped together into blocks.

The validity of a block (and all transactions within it) is determined against the accounts state.

The consensus protocol specifies who has the right to forge a new block and how agreement on blocks is reached. After the block has been forged, it is added to the blockchain, and all state changes induced by the block transactions are applied.

Blockchain applications

What are blockchain applications?

A blockchain application is any kind of application which uses its' own blockchain as a database layer.

More specifically, within the Lisk documentation, every time we talk about blockchain applications, we are referring to applications running on blockchains that are compatible with The Lisk protocol.

Examples of blockchain applications

Examples of blockchain applications can be found in the tutorials, such as the Non-fungible token (NFT) Tutorial, or the Social Recovery System (SRS) Tutorial application.

Additionally, check out the apps list at

Network topology diagram

A blockchain application generally consists of a network of servers, which are also called nodes in this context.

A typical network of nodes is illustrated in the diagram below:

node network

Shared on-chain logic, optional off-chain logic

All nodes in the network need to share the same On-chain logic (Modules), while the Off-chain logic (Plugins) of the application may differ from node to node.

P2P: Unstructured partial mesh network

The P2P network of nodes is unstructured, which means that all nodes are equal participants in the network.

It is also a partial mesh network, which means that every node is only connected to a small subset of nodes in the network.

Unstructured partial mesh networks allow nodes to share information in the network in a very expeditious and secure manner with all other nodes. They also possess the ability to scale extremely well, even for large networks with thousands of connected nodes.

Architecture of blockchain applications

All important components of a blockchain application are displayed in the diagram below:


On-chain logic

The on-chain architecture is a layer of abstraction that provides a collection of features to configure and run any business logic on the blockchain.

In short, the on-chain logic covers the following points:

  • introduces state mutations through blocks [1] or transactions [2].

  • is part of the blockchain protocol.

  • is verifiable by anyone by synchronizing with the blockchain.

  • is located in modules.

When to create a module

Modules and assets are able to perform the following criteria:

  • Define how data is stored on the blockchain.

  • Define logic which is executed per block [1].

  • Define logic which is executed per transaction [2].

The following modules are already included in the default application, they provide a basic blockchain application with a DPoS blockchain which allows basic token transfers between users:

To extend and customize the application, register additional modules to the application.

To add a new module to your application, either reuse an already existing module from another blockchain application, or create a new module based on the specific requirements of your application.

Off-chain logic

In short, the off-chain logic covers the following points:

  • It introduces new blockchain application features.

  • It is not part of the blockchain protocol.

  • It is optional to execute on a full node.

  • It is located in plugins.

When to create a plugin

Plugins are able to perform the following:

  • search the blockchain data.

  • aggregate the blockchain data.

  • provide a UI for the blockchain application.

  • automate the blockchain logic, such as automatically sending transactions.

  • add a proxy to the application interfaces.

The default application does not include any plugins by default, however, the Lisk SDK is bundled with a few common plugins listed below, which can be imported directly:

To extend and customize the application, register the desired plugins to the application.

To add a new plugin to your application, either reuse an already existing plugin from another blockchain application, or create a new plugin based on the specific requirements of your application.

Communication interfaces / APIs

communication architecture

The communication architecture of the Lisk SDK allows internal application components and external services to communicate to the blockchain application via various channels.

The Lisk SDK provides two industry standard communication protocols: Inter Process Communication (IPC) and Web Sockets (WS). The communication protocol of the blockchain application is changed in the configuration.

It is possible to communicate to modules and plugins directly by invoking actions via a RPC request, or by subscribing to events.

It is recommended to use the IPC/WebSocket protocols where possible, as they provide a more enhanced performance in regard to the response times, (see the blog post: Benchmarking Lisk Core v3.0.0 against Lisk Core v2.1.6). However, if you prefer an HTTP API, it is possible to add support for custom APIs by registering additional plugins, such as the HTTP API plugin.

For more information about the communication architecture, check out the endpoints explanation.

Frontend & backend

Blockchain applications usually consist of a frontend and a backend part, just as normal web applications.

In contrast to normal server-client applications, there is not one central backend, but rather a whole network of nodes which together secure and maintain the status of the blockchain. Each node can handle complex business logic and provides a flexible and customizable API. The blockchain itself is used as a database layer for the application.

The frontend allows users to interact conveniently with the blockchain application. The implementation of a frontend is totally flexible. For example, this can be achieved in the following ways:

  1. Create a new plugin for the blockchain application. An example implementation of a frontend as a plugin is the LNS UI plugin for the example application Lisk Name Service.

  2. Use your favorite framework/ programming language to develop a user interface, and communicate to the node via the Communication interfaces / APIs. One example is the frontend of the SRS example application , which has been developed with React.js. Another example is the UI for the Hello World application, detailed in the guide Creating a user interface.

  3. For later requirements in a production environment, a middleware similar to Lisk Service should be used, which will aggregate the data from the blockchain network and possibly other 3rd party sources as well. The frontend can then request this data via API requests from the middleware.

ui diagrams

Blockchain applications vs. dApps

As blockchain applications are also in a sense decentralized applications, you may wonder what is the difference between blockchain applications and dApps, or if there is any difference at all.

In short, the main difference between dApps and blockchain applications is that blockchain applications each run on their own blockchain/sidechain, while dApps are sharing the blockchain network with other dApps.

dApps are generally constructed as smart contracts, for example on the Ethereum blockchain. The development of blockchain applications is quite different, because it is much more similar to building a normal web application.

Most functionalities of smart contracts can be implemented in blockchain applications much easier and in a more straight forward manner. However, there is one important difference here to dApps, when it comes to applying new On-chain logic to the application: New smart contracts can be directly applied on the running blockchain, while adding new on-chain logic to blockchain applications always requires a hard fork in the network. Therefore, blockchain applications are less flexible than dApps, when it comes to uploading new logic on the running chain.

If the flexible characteristics of smart contracts are desired inside a blockchain application, it is of course also possible to develop a blockchain application which supports smart contracts. For example, a new module could be added to the application, which accepts smart contracts. This way it is possible to have the best of both worlds combined.

Additionally, smart contracts can reuse an already existing blockchain, which saves time when launching the application, as it is not necessary to take care of setting up an independent blockchain network, finding delegates [3], etc.

Blockchain applications on the contrary rely on their own blockchain, and therefore also need to take care of maintaining their own network. In the beginning, this will make the launch of the application slightly more complex, however, having an independent network comes with numerous benefits which are covered in the following paragraphs.

The Lisk documentation is referring to applications built with the Lisk SDK as "blockchain applications" and not "dApps". In order to clarify the difference here, applications are not sharing a common blockchain, but instead are each running on their own chain. As a result blockchain applications have the following advantages:

  • Lower transaction fees, as high traffic of one blockchain application has no effect on other blockchain applications.

  • The blockchain for the application can be designed with the optimal characteristics for the specific use case, (for example by adjusting the block time or the number of delegates, or even changing the whole consensus algorithm).

  • A much more scalable blockchain, as it only handles the data from one blockchain application. Therefore it is growing much slower in size, and doesn’t suffer so much from potential bottlenecks in the network, which can happen during times of high workload on many different dApps.

  • Interoperability: Register a blockchain application as a sidechain to connect it to the Lisk Mainchain, (this is coming soon). This will provide seamless interoperability to the Lisk Mainchain and all of its' connected sidechains.

1. For more information about blocks, check out the Blocks page of the Lisk protocol.
2. For more information about transactions, check the Transactions page of the Lisk protocol.
3. For more information about delegates, check the Consensus algorithm page of the Lisk protocol.