Application-specific blockchains (appchains) explained in a nutshell

Application-specific blockchains (appchains) explained in a nutshell

Note: Throughout the article we interchangeably use two terms that have the same meaning: application-specific blockchains and multi-blockchain networks.

In our first Everscale Deep Tech article, we compared the three main networks that allow the creation of application-specific blockchains. Today, we would like to shed more light on this topic. In order to better understand how multi-blockchain platforms came into being, we have provided a short overview of the three blockchain categories that paved the way to the current status quo. Further, we outline the shortcomings of single-blockchain networks, and the pros offered by multi-blockchain networks. Also, for illustrative purposes, we have put together an animation depicting how Everscale’s application-specific blockchains work in practice. It highlights Everscale’s competitive advantage compared to other multi-blockchain platforms in terms of throughput achieved via parallel smart contracts execution.

Blockchain categories

Blockchain platforms are classified into three categories. Each one of them has its own characteristics and solves a certain range of tasks.

First — Bitcoin, Litecoin, ZCash

The main purpose of these platforms was to create some sort of decentralized version of money. Each platform chose its own path, implementing different tech solutions. For instance, ZCash offers strong privacy properties. Bitcoin, in spite of its strong security, is slow and environmentally unfriendly due to its PoW consensus algorithm. Litecoin, on its part, lost the competition to its main competitors in terms of usability. Basically, in spite of its high energy consumption, only BTC achieved the status of decentralized money. It was officially recognized as legal tender in El Salvador.

Second — Ethereum, Tezos, EOS

The main purpose of these platforms is enabling the creation of decentralized applications via programmable logic. Each platform achieves this with its own specific features. However, with the growing popularity of second category blockchain platforms, the problems that plagued the first category have significantly worsened. The most acute of them are performance, energy efficiency and costs. In order to solve these issues, a third category of blockchain platforms has been set into motion.

Third — Everscale, Cosmos, Avalanche

These platforms provide horizontal scaling via multichain network architecture, meaning that they all give developers the tools needed to create their own blockchains. If necessary, these newly created blockchains can interact with each other. Each network has its own approaches and compromises to achieve cross-chain communication. They are aimed at creating an interconnected blockchain that can accommodate millions of active users and fully realize the conceptual vision of Web3 as an internet completely owned and controlled by users.


A new version of Ethereum is in the development stage. According to its design features, it will also belong to the third category of platforms. However, the results remain to be seen.

The shortcomings of one-blockchain networks

Virtual machine blockchains like Ethereum came to the fore with new functionality. This new functionality consisted in their state machines including a virtual machine capable of processing smart contracts. Although smart contracts are extremely useful for certain use cases (one-time processes), they can not efficiently handle complex decentralized applications. Let’s see why:

  • Smart contracts are mainly written with the help of specific programming languages that can be interpreted by the underlying virtual machine. These programming languages are often limited by the constraints of the virtual machine itself. For instance, EVM does not allow developers to implement automatic execution of code. Devs are also limited to the account-based system of the EVM. Additionally, they can only choose from a limited number of functions for their cryptographic operations. Coupled together, these issues depict the lack of flexibility that this kind of smart contract environment brings about.
  • All smart contracts are processed by the same virtual machine and have to compete for computational resources. This, in turn, can critically limit performance. It is especially true in times of heightened network activity. Even if the state machine were to be split via sharding, smart contracts would still need to be processed by a virtual machine. This would limit performance compared to a native application implemented at state machine level.
  • Smart contracts sharing the same network also leads to sovereignty limitations. A dApp is an entity that incorporates several players. If it is built on a single-blockchain, its developers have very limited control over their application. They are limited by the governance of the underlying blockchain and if there is a bug in the application, very little can be done about it.
  • Application-Specific Blockchains have been developed to address these shortcomings.

The pros of application-specific blockchains

Application-specific blockchains offer maximum flexibility. In essence, their advantages revolve around performance, security and sovereignty. We briefly discussed them in our last article. Please follow this link in case you missed it. As for now, we will examine them in more detail.


The performance of decentralized applications built with smart contracts is limited by the underlying network. So, in order for a decentralized application to enhance its performance, it ought to be built on an application-specific blockchain. The benefits brought by an application-specific blockchain in terms of performance are the following:

The devs of application-specific blockchains can opt to operate with an innovative consensus algorithm such as Everscale’s Catchain. Besides its many other strengths, it offers tremendous gains in terms of throughput. An application-specific blockchain does not have to compete with other dApps on the network for computation and storage. This is the opposite of most non-sharded virtual machine blockchains, where all smart contracts compete for computation and storage.

Even if we consider the possibility of application-based sharding coupled with an efficient consensus algorithm, the performance would still be reduced by the virtual machine itself. This is due to the fact that the main cause of congestion (reduced throughput) is the state machine. Requiring transactions to be interpreted by a virtual machine significantly increases the computational complexity to process them.


There is limited ability to measure security. This is due to the many unquantifiable factors that impact it. However, let’s see what are some important benefits an application-specific blockchain can bring in terms of security:

In the case of Everscale, developers can choose proven programming languages such as Solidity and C++ to build their application-specific blockchains. This is in contrast to smart contract programming languages that are not so mature yet. Developers are not limited by the cryptographic functions provided by the underlying virtual machines. More than that, they can use their own custom cryptography, and use well-audited crypto libraries. Devs also do not have to worry about potential bugs in the underlying virtual machine. This, in turn, makes it easier to think about the security of the application.


A decentralized application is an entity that involves many players, such as users, developers and other interconnected dApps. When developers build on virtual machine blockchains like Ethereum where many decentralized applications coexist, the community of the application is different from the community of the underlying blockchain. Therefore, if there is a bug or if a new feature is needed, the application’s developers have very little chance to upgrade the code, and no changes are possible If the community of the underlying blockchain refuses them.

This issue is solved with maximum efficiency by application-specific blockchains. Due to the fact that application-specific blockchains provide the possibility to operate a single application, stakeholders of the application have full control over the entire blockchain (workchain). This guarantees that the community will not be stuck if a bug is discovered. Also, the community can decide how the particular blockchain will be developed in the future.

Everscale’s competitive advantage over other application-specific blockchains

Exchange — any trading platform can exist as an application-specific blockchain, irrespective of its trading volume. On Everscale, a separate blockchain, called workchain can process an almost infinite number of transactions. This is due to parallel smart contract execution. As we show below, when the number of transactions significantly increases, for instance, in the case of severe market fluctuations, the workchain bursts and two new threads come into play to process the increasing number of messages. The whole process can continue up to 256 threads, meaning that it practically eliminates any congestion risks even if market turbulence amplifies and continues longer than expected.

Social Media app — a messenger or email service can easily exist as a separate blockchain. In order for you to better understand how parallel smart contract execution works, let’s think of a different case. Let’s imagine that there is breaking global news that sparks discussions in our messenger (workchain). As the number of messages increases the workchain bursts and two threads come into play to be able to process them. However, as in most cases, the news does not have a lasting effect, and the discussion on the messenger slows along with the flow of messages to the threads. Once the activity dies down, the respective threads are gradually merged back to the initial state with one workchain.

Local food delivery app — for illustrative purposes we have also depicted a case in which there is no need for parallel smart contracts execution. Food delivery companies serve as a perfect example in this respect. Although they operate with large customer databases, in most cases there is no unexpected activity that can suddenly lead to a heightened number of orders. Basically, there is a stable flow of transactions (orders) which the workchain can handle perfectly well.

Stay tuned! In the next article we will draw some parallels between the evolution of computer technology and blockchains.

Read More