How should a scalable blockchain actually work [Deep Tech]

First off, what is scalability?

In programming, scalability refers to the ability of an application, network, algorithm, protocol or system to accommodate a growing workload, be able to execute a wider range of functions and serve an increasing number of users. In centralized computing systems, scalability can be improved in two ways: updating the software so that it can perform an increasing number of tasks more efficiently or adding computing power (servers). Blockchain scalability is most often measured by the number of transactions per second, or TPS, a blockchain can perform.

Ethereum’s scalability problem

The growing workload on the Ethereum network has had a direct impact on the cost of transactions on the network. The problem lies in the fact that network commissions, which are calculated in units of gas, are dynamic. That is to say, during periods of high network activity, validators can select and process the transactions that offer more gas. As a result, competition increases among those sending transactions and, consequently, so does the size of commissions. This is one of the main drawbacks of having a large number of dApps on the network. In his latest article, Vitalik Buterin outlined the “three transitions” problem. Buterin emphasizes that, without solving three key challenges, one of which is scalability, Ethereum will not be able to attract more users. More than that, it will start losing its existing ones at an accelerated pace.

The animation below illustrates how transaction initiators (senders) have to compete to include a transaction in a block.

Everscale is a scalable fifth-generation blockchain

Everscale is a heterogeneous horizontally scalable blockchain (what that means exactly and how it works will be discussed at length in later articles). Every object that exists on Everscale is a smart contract — even your Everscale wallet is a smart contract. Smart contracts communicate by sending messages to each other. To put it simply, a smart contract is a blockchain entity with its own attributes, e.g. address, balance, code and other data. Apart from storing data, smart contracts can execute instructions received from other smart contracts. Instructions are conveyed within messages mentioned a couple of strings above. When a smart contract receives a message with instructions and those instructions are successfully executed by the TVM (Threaded Virtual Machine), the state of the smart contract, as well as the state of other smart contracts and shards can be modified:

1. The data stored in a smart contract (instructions, balances, some other data) can be modified;

2. A new smart contract can be generated to execute this or that instruction;

3. One or multiple outgoing messages can be sent.

Smart contracts interaction:

Once a smart contract sends a message, a new transaction is generated. Smart contracts can only execute instructions consecutively, so the transactions are generated in logically correct sequences. Messages are routed from the outgoing queue to the incoming queue in order to ensure that they are also delivered in the right order. After a transaction is generated, it is put into a block of the Masterchain.

So what’s next?

Chains

Blocks containing transaction data are linked in a chain. To be sure that consensus is reached, transaction processing nodes must periodically check the states of smart contracts.

A single block can contain information on several transactions thanks to the transaction batching mechanism. Although it may seem that transactions are piled up in no particular order, in reality, a child transaction cannot be included in a block before its parent transaction in the course of batching.

Apart from transaction data, a block includes smart contract interaction information, i.e. it stores all the messages processed by the shards of the Workchain.

Shard splitting is key to scalability

Spikes in network activity bear no risks for Everscale’s operability as shards can be easily split into several new shards. Imagine the following — there is a shard processing messages from several smart contracts. All of a sudden (as always happens during bull runs), there is an influx of transactions that must be processed at the same speed as before. Now the shard must process more transactions per second. To maintain appropriate processing time, the pool of smart contracts can be divided and processed by two separate shards, leading to a 50% decrease in resource consumption by a single shard. Now, as we have two separate shards, each shard has its own set of validators working with its messages. Depending on the configuration, one Workchain can contain up to 256 shards. Such scalability allows the blockchain to process millions of transactions per second without leading to an increase in network fees.

Shard splitting:

A shard cannot be split if it is only processing messages from one smart contract.

Shard merging

As shards become less loaded, they can merge back into one shard that will again process all the messages from all existing smart contracts.

Uneven allocation of the workload:

Merging of shards is possible when there is more than one shard operating in the Workchain at the moment.

Blockchain

In Everscale, a Workchain is a chain of messages that are distributed to all of the shards for processing according to the predefined rules.

Everscale architecture makes it possible to create numerous Workchains. Every Workchain can leverage its own virtual machine, e.g. EVM for Ethereum applications, and can have its own currency and fee policy. Workchains can work in parallel with the help of a cross-Workchain communication mechanism that allows them to send on-chain messages to each other.

Main Workchain

In the main Workchain, casual transactions from users are processed. If there is a workload spike, a Workchain can leverage multiple shards (that undergo the splitting process shown above). Every shard is delegated to a select group of validators picked from the validator global network. Validator groups remain active for short periods of time called rounds. Transaction executions are always each validated by one group of validators who also have to keep track of the state of all other shards of their Workchain.

Masterchain

Everscale architecture requires nodes to reach consensus on the state of the chain. This is where the Masterchain enters the field. Masterchain blocks contain hashes of the blocks of other shards. Every 2–3 seconds, each shard broadcasts so-called ‘proofs of blocks’ to the Masterchain. Thus, a single block of the Masterchain knows the state of every shard.

Interaction of the Masterchain with other Workchains and cross-Workchain communication:

More Workchains to appear in the near future

Everscale architecture can support up to 232 Workchains with up to 256 shards each. This ensures the unhindered processing of transactions, even when network activity is at its peak. Almost unlimited network throughput ensures that any application (payment system, transport system, social network, etc) can operate without interruption in its own Workchain. Each Workchain can be configured independently from other Workchains and have its own virtual machine, fee policy and currency.