Sharding models in Everscale and Near, compared [Deep Tech]

Blockchain developers are facing new challenges, and the biggest one is solving the blockchain trilemma — finding the right balance between decentralization, security, and scalability. The blockchain trilemma proposes that decentralization, security, and scalability cannot be achieved on a high level simultaneously, and that we should find a compromise between them.

At Everscale, we solved the trilemma with the innovative Soft Majority Fault Tolerance (SMFT) consensus by adding a new axis to this theorem, which is probability.

In a nutshell, with the unique architecture of SMFT and sharding design, the chances of decentralization, security, or scalability being compromised at some point are slim to none.

Also, we need to take into account that each attack on network security would make no economic sense, and malicious behavior holds no prospect of financial gain for any network participant. Speaking of decentralization, Everscale’s architecture allows for running up to 4,000 validators in one Workchain, while Workchains can be added infinitely according to demand, as well as Masterchains, with an economic incentive.

In this series of articles, we’d like to explain more about sharding and compare sharding designs of other networks with the Everscale design. We have already published an article comparing Everscale and Elrond sharding models.

Let’s deep dive into Everscale’s and NEAR’s sharding models.

NEAR protocol — a short introduction

NEAR solves the problem of increasing the performance and capacity of the blockchain with sharding technology. Currently, the blockchain is divided into four shards, each with its own validator pool and nodes. Validators are selected for a certain period, called epochs, based on criteria such as stake size.

NEAR smart contracts run in WASM and are written in Rust. The ecosystem of NEAR services is relatively small, as it is young and only gaining momentum. The Aurora network, which uses a NEAR-based EVM, is also gaining popularity.

How does sharding work on NEAR?

The NEAR protocol’s sharding design is called Nightshade. The Nightshade sharding model runs as a single blockchain. Each validator/network participant only maintains a blockchain state that corresponds to shards that they validate transactions for, and the list of all the transactions in the block is split into chunks, one chunk per shard.

Each block produced contains all the transactions for all shards, and each block changes the whole state of all the shards. That means each transaction goes through all shards and atomically changes the blockchain state in all shards. It works great as an idea, but there are many questions regarding the practical use of this model.

For example, if a transaction affects a million accounts, how would it work in practice? How do the changes get locked in the first chunk before they get to the last one? A chunk receives a transaction after three blocks. Meanwhile, the state has changed in the block. But at what height would the corresponding changes be counted, at the initial height block or the already changed one?

Some of the questions still need to be clarified from the documentation on how it would work in practice if transactions affect a lot of chunks. It looks like an excellent idea when all transactions are paralleled, but in practice it would theoretically be possible to organize a sophisticated queue of transactions and halt the network or even stop nodes.

Block production in the NEAR blockchain

There are two roles in block production in NEAR — block producers and chunk producers. Both chunk and block producers rotate in each block according to a fixed schedule.

A group of block producers can potentially be in cahoots with each other and perform malicious actions on the network. In that case, if a malicious block is being produced, observing nodes called fishermen can challenge the invalid block, increasing the waiting period between chunks and delaying network finality.

NEAR doesn’t solve the blockchain trilemma in its architecture — there is still a potential problem with its sharding model and the total amount of validators in shards. If malicious validators manage to insert a malicious block into the blockchain state, in the time between it getting into the network and the fishermen finding it out, the malicious block can affect most accounts, and the butterfly effect can potentially change the whole state dramatically.

In this situation, there’s simply no turning back and all the blockchain data will be changed immutably.

How does sharding work on Everscale?

We already described how the Everscale sharding model works in the Elrond comparison article. In a nutshell, The whole Everscale blockchain can be divided into Masterchain, Workchain, and Threads (or shards).

Masterсhain —  The Masterchain is part of SMFT protection and collection of proofs (it listens for malicious blocks) from Workchains.

Currently, there is only one Masterchain, and its blocks contain the main data of the state, ensuring that verification of all data in Workchains is correct. In the future, it will be possible to add more Masterchains in order to scale the network. All blocks in a given Masterchain are collections of proofs that the Workchains connected to it are working correctly.

Workсhain —  These are blockchains built specifically for particular network tasks or specific dApps. Workchains are completely different from each other.

Threads (processing shards) —  These are basic elements which can be described as small blockchains. A set of Threads forms a Workchain.

There are groups of validators that execute different sets of smart contracts, which are separated by accounts. That’s precisely why we have infinite scalability: because we can now add these validators linearly as and when we need to execute more programs.

Our sharding model consists of a Masterchain and corresponding Workchains (which can be added infinitely by adding more validators to create more Workchains). Each Workchain is capable of running about 256 Threads (processing shards) in full synchronization.

That’s the practical number with a global network bandwidth of 1Gbit. With a global increase of network throughput, it could be increased 10–20 times more. Of course, when 256 processing Threads (shards) isn’t enough, you can launch a new Workchain, i.e. add 1,000 more validators and get a new Workchain.

Collators and verifiers change each block — each block has an individual set of verifiers. Each Workchain can have up to 4,000 validators.

Currently, the basic configuration of the Everscale mainnet is a combination of a Masterchain and a single Workchain with the native EVER token and the virtual machine TVM, which is written in RUST from scratch.

Our core team developers are planning to add an EVM-compatible Workchain type and Workchains designed for data storage (Drivechains) soon.

Summary

NEAR incorporates an interesting approach to sharding and blockchain design in general. However, although it works well in theory, the practical use of the blockchain is fundamentally different. Moreover, we couldn’t find the exact answers to certain questions in the technical documentation, and there are potential vulnerabilities for a wide range of attacks on the NEAR blockchain. We are open to any dialogue and would be happy to discuss all the missing parts with the NEAR core team in order to learn more about the blockchain.

With increased crypto adoption and blockchain usage, the industry is going to demand a high level of security, decentralization, and scalability. We have already seen a vast number of hacks and exploitations in different blockchains, and this number is increasing. The initial blockchain designs work in theory, but in practice, hackers would always be trying to cheat blockchains and steal users’ funds.

Meanwhile, Everscale’s architecture has enabled incredible scalability and blockchain speed to date without sacrificing network security. In real tests on a public network with 300 validators, the speed of Everscale in a 10-Workchain configuration reached 63,000 TPS.

The Everscale ecosystem has great potential, making it one of the most promising investment options on the market (not financial advice). Moreover, Everscale didn’t host an ICO or any token sales for early investors, which makes it more decentralized and fairly distributed, unlike other blockchains in the crypto industry.