MultiversX Wiki - Multi-shard, The answers to certain questions
  Multi-shard, The answers to certain questions
Published by Olag ⚡ | The 02/17/2022  |  Category: Thread

Biggest challenges on Elrond is to make applications multi-shard to take advantage of scalability How does Elrond scale? What can happen if dApps are not multi-shard? What are current problems?

Elrond is very scalable and scales horizontally (Elrond is also the only one to do the 3 main types of sharding, state, transaction and network sharding). Elrond has 3 shards and a metachain, each shard can process around 5k transactions per second (EGLD transfer type transactions) and therefore with 3 shards Elrond has a capacity of 15k TPS. Elrond can add a new shard depending on the demand, i.e. if tomorrow we needed more capacity, we could add a new shard and increase the capacity by 5k tps, etc etc. without having to abandon decentralization or speed (there are currently enough validators to be able to add new shards, but there will be new shards only if the demand on the network is high) and of course it is possible to make cross-shard transactions (transaction of a shard A to a shard B)  In terms of speed, it's 6 seconds for an intra-shard transaction and between 20 and 50 seconds for a cross-shard transaction.

I tried to briefly explain Elrond and how it scales to be able to move on, so now let's get into why currently dApps like Maiar Exchange don't *yet* use Elrond's scalability and how much it can to become “catastrophic” if it stays like this.The current problem of Maiar Exchange is that it is on a single shard, currently it is the only dApp that is used a lot, but the DEX must become multi-shard as soon as possible, why?

Imagine, tomorrow an application that needs to interact with the DEX, a game or a Yield Optimizer that redeposits your funds in the DEX farms, what will it choose between:

  •  deploy its smart contracts in the same shard as the DEX and obtain a speed of 6 seconds per transaction (for synchronous calls)
  •  deploy on another shard and get between 20 and 50 seconds for a transaction (asynchronous call)

Obviously the project will choose the 1st solution to obtain the best speed for its users, and imagine the other applications which will be deployed but which will use the smart contracts of the other smart contracts for their project and so on it will be endless and everything will develop on a single shard but what's the problem?

From a moment, it risks congesting the shard, because the transactions will come from the different shards but the transactions/execution of smart contracts will only be done in a single shard, this shard should support the capacity of a “supershard” while all shards are similar and therefore in the end it will congest the shard and it will become unusable (same with all the applications on it) 

Basically, since Maiar Exchange is on shard 1, it encourages other applications that use the DEX to deploy in the same shard to obtain faster transactions and in the end this shard will be used by many applications which will congest it.

And if we want to use the scalability of Elrond and add a new shard, it will be useless since the transactions will be executed in shard 1, it will just add one more place for which shard 1 will execute contract calls.

But then how do we use Elrond's scalability? We must make the dApps multi-shard so as not to use only one shard to use the entire network but how do we do it?  You may say: “You just have to deploy the contracts on the other shards to be multi-shard”, so yes, but it's a little more complicated

Elrond is one of the only blockchains to do full state sharding, this has a lot of advantages like the fact that the validators assigned in a shard only have to keep their shard in memory rather than storing the whole blockchain but what also creates *difficulties*, like an SC that's in shard 1, can't know what's going on in an SC that's in shard 2, which isn't practical when you want to have a DEX AMM or for lending/borrowing not knowing what's going on in the other shards and therefore it would be necessary to synchronize prices and liquidity between the shards.

There are solutions that are envisaged by Elrond for Maiar Exchange, for example it intends to synchronize the liquidity and the price every 5 minutes if the local price compared to the global prices has changed by more than 1% thanks to a new mechanism it will be enough to call a "trigger" and the SC will take care of the rest (without needing an oracle), so we imagine that the SC will take care of the cross-shard arbitration?

 

But for applications that do not need to maintain a ratio or simply do not need to know what is happening in the other shards, they can simply deploy on the 3 shards and then put the same owner for the 3 contracts for example: the wrapping smart contract (the SC to wrap your EGLDs in order to use them on the DEX) is multi-shard.

The DEX will become multi-shard in 2 parts, first the farms and then the liquidity and therefore the swaps (farming is the simplest, as I said a little earlier, managing liquidity between shards is a little more complicated), and there will be no more cross-shard transactions, transactions to the DEX will therefore be 6 seconds regardless of the shard . (it will only be intra-shard transactions)

I think once the DEX is multi-shard, Elrond and his dApps will be in “god mode”, I think Elrond will manage to pass the “barrier” that other blockchains like Solana, BSC and others have trouble (this is just my opinion). but in terms of scalability (not only scalability by the way, scalability does not stop at TPS) it will be difficult to do better.

PS: We hope to have “tools” by the Elrond team to make multi-sharding easier, for example by allowing us to deploy on all shards at the same time (currently, the SC is automatically deployed in the shard of the one who deploys it, nd therefore we must deploy from 3 different addresses on the 3 shards and then finally change the owner to put the same for the 3).

  Source

  Twitter

Written by Robin and translated by Wesley Kress

  Advertising

Tweet Share  
Olag ⚡
@olag

Founder of MultiversX Wiki

Twitter    Telegram     Website

To be able to publish your comment on this article Login
  Comments

  Event
No event :(
  Creator Studio
This tool is designed to facilitate the addition of collections & NFT Artists & also the addition of tokens of projects built on MultiversX. New options coming soon.
  Creator Studio
  Advertising
  Scam or not ?
...

You can check if you are not dealing with a scam

Check now