Everscale vs. Elrond: Two sharding models, compared

Everscale vs. Elrond: Two sharding models, compared

Sharding is the only solution to scale blockchains

Blockchain tech is inevitably entering our daily life, and average users are interacting more and more with blockchain. At the same time, some believe that in the future, most users won’t need to know anything about blockchain, just as now they don’t need to think about JavaScript or HTML; everything is processed under the hood.

Now we come to the scalability issue. Any solution reaches its limits in terms of computational resources and overall capacity, and this is where scaling comes in. In this series of articles, we’d like to explain more about sharding and compare sharding designs of other networks with the Everscale design, as sharding is a key solution to solve the scalability problem.

Each network is limited by 3 resources

It would be fair to compare any sharding models in terms of what they actually shard. This can be divided into three types:

  1. Sharding of disk or storage resources
  2. Sharding of network resources
  3. Sharding of computational resources

If we jump ahead a bit here, the first bottleneck that each network faces is computational resources, and Everscale solves this problem through its asynchronous model.

The bottleneck of sharding

The first bottleneck is computation. In a nutshell, sharding means splitting the entire blockchain into n-amount of shards (or blockchains) that each stores and/or processes its own data.

The Elrond network’s implementation of sharding divides the blockchain state into shards held by subsets of nodes, where one subset stores one piece of data, while another subset stores another piece of data. Basically, this is the first iteration of sharding approaches mentioned back in 2012–2013 — the first ideas on how to scale a blockchain.

This is where all the beauty lies. If you divide a blockchain into n-states, then n-amount of parallel chains appear. All chains (shards) exist independently and store their own set of data. This is what’s called data sharding.

According to this approach, each shard has its own set of validators to produce blocks, and if shards need to pass a message to each other, there’s a requirement to perform cross-chain transactions, like Elrond does (Elrond tech doc).

How sharding works on Everscale — what is computation sharding?

There is a set of validators, let’s say 1,000, forming a workchain (data shard). Each block for a processing shard is produced in one round. A leader (collator) in a processing shard is determined every round among validators — the collator proposes a block. All other validators in the processing shard accept this block and the next round starts. A new collator is determined every time.

One block is formed (collated) once per second in each chain; after that, a total of 1.5 seconds is required to finalize the block, and after finalization it is passed on to all validators, which broadcast all messages between each other.

According to this process, the workload for each instance of processing is 0.5MB every 2 seconds, which means that when using 1Gbit network bandwidth, 200 processing shards can be in full synchronization.

Full sync between all processing shards means that all chains communicate with each other (sending blocks to each other) and any validator of a workchain (data shard) can verify any block that is produced by any shard.

The validators don’t need to perform any cross-chain transactions, as all messages are already written within each block. This means that the data between all validators of processing shards stays the same — we don’t need to create parallel chains with sharded data, but computation takes place in a parallel way.

Of course, when 200 processing shards isn’t enough, you can launch a new workchain, i.e. add 1,000 more validators and get a new data shard.

What’s the difference?

Each chain (shard) on Elrond lives by itself — it doesn’t send any blocks to other chains. All of the data is different on all chains. These are parallel blockchains with a common mechanism to perform cross-chain communications — if there is a need to send any information between chains, it has to be done via the masterchain.

Meanwhile, each chain (shard) on Everscale’s workchain can see and verify all blocks from other chains. In producing a block, each chain receives messages from other chains. There is no need to send transactions to the masterchain — all messages are already included in every block. That’s why all validators rotate, which gives us a completely different level of security: 1,000+ validators to each workchain against Elrond’s 10–20 validators per chain.

This is a crucial difference. Basically, on Everscale, 1,000 validators share the same data between each other, but processing is divided between them.

Elrond’s security

In order to validate, you need the blockchain state — it’s not possible to validate without the whole state.

What Elrond does is create n-amount of parallel chains with different data that communicate with each other. Accordingly, when the state is being sharded, and when only a small set of validators have access to it, the problem arises of security being at risk at this very moment.

In fact, if there is a collusion between these validators, that’s literally it — it could lead to terrible consequences. They can produce any block, so it’s not merely a shard problem, but a problem for the whole blockchain. Validators can issue trillions of any token and ruin the entire blockchain state within one block, even though it only concerns one shard.

Everscale’s security

Everscale’s blockchain state is held by a large set of validators. We divide the whole state into processing shards (or threads). Everscale validators can verify blocks and sharding validation outside of their shard without the need for cross-chain transactions between each other, as all messages between shards are included in each block, and validators can check how all processing is being done.

Validators that check the blocks are verifiers. With a maximum network bandwidth of 1GB, the total number of validators can reach 4,000. If the number of validators displaying malicious behavior is less than 50%, they cannot affect the network. Any attacker would thus have to gain control of 2,000 validators.

Compare this to the 33% of the classic Byzantine Fault Tolerance (BFT) consensus for a small data shard. For instance, 33% of 15 validators would be just five malicious ones that could potentially attack a shard and, as a result, the whole network!

Of course, it is far easier for such a small number of validators to conspire to change a state than the 2,000+ theoretically required in the Everscale network. Everscale’s level of security in this regard compared to Elrond therefore speaks for itself.

Summary

Everscale is the only blockchain able to perform both computational and data sharding. Moreover, its unique design and approach that allows us to solve the first bottleneck of blockchain scaling leads to top-level security that is increased exponentially as the network scales.

In this article, we have tried to explain Everscale’s innovative, both data and computational sharding design in simple terms. Please feel free to dive deeper into our technical documentation, and don’t hesitate to ask any questions within our community!

Read More