First, what is scalability?
In programming, scalability refers to the ability of an application, network, algorithm, protocol, or system to evolve with increasing load to perform a wider range of functions and serve an increasing number of users. In centralized computing systems, performance can be improved in two ways: by updating the hardware software to more efficiently perform an increasing range of tasks, or by adding computing power (servers). Blockchain scalability most often refers to the ability to process more transactions per second, the so-called TPS (transactions per second).
The problem of blockchain scalability on the example of Ethereum
The growing load on the Ethereum network greatly increases the cost of transactions. The problem is that network fees, which are calculated in units of gas, are dynamic. During periods of bursts in the load on the network, validators can select and process those transactions (crypto transactions) that offer more gas, thereby increasing competition and further increasing network fees. This is one of the main obstacles to the deployment of an increasing number of applications on the air network and, accordingly, an increase in the number of users. In his latest article, Vitalik Buterin outlined the problem of “Three transitions”. The author emphasizes that without solving three challenges, one of which is scalability, the air will not only not be able to attract more users, but will begin to lose existing ones at an accelerated pace.
The animation below illustrates how senders compete to include a transaction in a block by increasing network fees.
Everscale – Scalable 5th Generation Blockchain
Everscale has a unique, horizontally scaling heterogeneous blockchain architecture (we will cover such complex designs in more detail in another article), in which everything is a smart contract. Interaction between smart contracts is carried out using messages. Even your Everscale cryptocurrency wallet is a smart contract. Simply put, a smart contract is an object with attributes such as address, code, balance, and other data. In addition to storing data, a smart contract can execute instructions received from other smart contracts. The exchange of instructions between smart contracts occurs by passing messages. Receiving a message and subsequent successful execution of the TVM (Threaded Virtual Machine) instruction code can lead to the following changes in the smart contract or shard:
Overwriting data in a smart contract (instructions, balances and other data);
Sending an outgoing message by a smart contract to create another smart contract;
Sending multiple outgoing messages by a smart contract.
Interaction of smart contracts:
Sending a message by a smart contract generates a transaction. The execution of instructions by one smart contract is carried out sequentially to ensure the orderliness of messages generated by one smart contract. Routing directs messages from outgoing queues to their corresponding incoming queues, allowing all messages to be delivered one after the other. The transactions themselves are sent to the Masterchain.
Blocks containing information about transactions form a chain. In order to reach a consensus on the state, the nodes processing transactions need to periodically agree on the state of the smart contract.
A block can contain information about multiple transactions thanks to a process called transaction packaging. It should be noted that packaging cannot break the logical sequence of transactions and include a transaction in the master chain block before its parent transaction is included in the block.
In addition, the block with transactions contains all the information about the interaction of smart contracts whose transactions were included in the block. In other words, the block also records the incoming and outgoing messages processed by each shard within the same workchain.
Sharding – scalability
In the event of an increase in activity in the network, the shard can be easily divided. Imagine the situation: we have one shard that processes messages from a certain number of accounts (smart contracts). At some point (a new bull cycle has begun), the need to process more transactions per second (TPS) increases dramatically, or, in other words, smart contracts begin to exchange an increased number of messages per unit of time. The pool of smart contracts that are processed by one shard can be divided into two shards. In this case, there will be half as many smart contracts per shard, and both sets of smart contracts will be processed on an individual subset of nodes. Depending on the configuration, the number of shards within a single workchain can be up to 256. In practice, this means that the network is able to seamlessly process millions of transactions per second without any impact on network fees.
Splitting a shard is not possible if it processes messages from only one smart contract.
If the load on some of the shards decreases, on the contrary, they are combined into one shard responsible for processing all messages from smart contracts that were previously processed by several shards.
Uneven load distribution:
Merging shards is possible only when there is more than one shard in the workchain – messages from smart contracts are processed by more than one shard.
In Everscale, the totality of all shards with the accounts they serve, interacting in accordance with established rules, is called a workchain.
The blockchain architecture allows the creation of many workchains. Each workchain, if necessary, can have its own internal coin, virtual machine (for example, an EVM for an Ethereum application) or commission policy. They can work simultaneously and interact using cross-workchain communication, sending messages along the chain.
The main working chain handles normal user transactions. With a large number of user transactions (high network activity), the working chain can be divided into shards (as demonstrated above). Each shard is in turn assigned to a random subgroup of validators from the global network of validators. Subgroups are selected for a relatively short period of time (round). Accordingly, one of the subgroups is always responsible for the execution of transactions in one shard. At the same time, this subgroup constantly downloads blocks from all other shards of its workchain.
An architectural feature of Everscale requires nodes to reach consensus on state. This is where the masterchain comes into play, as its blocks contain the final block hashes of the rest of the shards in the network. Every two or three seconds, each shard sends so-called block release proofs to the masterchain. Thus, the state of all shards of the network is determined using only one block of the master chain.
Masterchain interaction with other network workchains and cross-workchain communication:
In the near future, it will be possible to create new workchains
The Everscale architecture allows you to create up to 232 workchains, each of which, if necessary, can be divided into 256 shards, which allows you to process a huge number of transactions during periods of increased network activity. Thanks to this, any application option (payment systems, logistics solutions, social networks, or even a food delivery service) can function smoothly in a separate workchain. Each workchain can have its own configuration, virtual machine, commission policy, and local currency.