Un des plus gros challenges sur Elrond, c’est de rendre les applications multi-shard pour pouvoir profiter de la scalabilité de Elrond, Comment Elrond scale ? Qu’est ce qu’il peut arriver si les dApps ne sont pas multi-shard ? Quels sont les problèmes actuels ?

Elrond est très scalable et scale de manière horizontale (Elrond est également le seul à faire les 3 grand types de sharding, le sharding d’état, transaction et de réseau). Elrond a 3 shards et une metachain, chaque shard peut traiter environ 5k transactions par seconde (des transactions type transfère de EGLD) et donc avec 3 shards Elrond a une capacité de 15k TPS. Elrond peut ajouter un nouveau shard en fonction de la demande, c’est à-dire que si demain on avait besoin de plus de capacité, on pourrait ajouter un nouveau shard et augmenter la capacité de 5k tps, etc etc. sans pour autant devoir délaissé la décentralisation ou la vitesse, (il y a actuellement assez de validateurs pour pouvoir ajouter de nouveau shards, mais il y aura de nouveau shards uniquement si la demande sur le réseau est élevé) et évidemment c’est possible de faire des transactions cross-shard (transaction d'un shard A vers un shard B).

Au niveau de la vitesse c’est 6 secondes pour une transaction intra-shard et entre 20 et 50 secondes pour une transaction cross-shard.

J’ai essayé de vous expliquer brièvement Elrond et sa façon de scale pour pouvoir passer à la suite, alors maintenant rentrons dans pourquoi actuellement les dApps comme Maiar Exchange n’utilise pas * encore * la scalabilité d’Elrond et à quel point ça peut devenir “catastrophique” si ça reste comme ça le problème actuel de Maiar Exchange c’est qu’il est sur un seul shard, actuellement c’est la seule dApp qui est beaucoup utilisé, mais le DEX doit devenir multi-shard le plus vite possible, pourquoi ?

Imaginez, demain une application qui a besoin d’interagir avec le DEX, un jeu ou un Yield Optimizer qui redépose vos fonds dans les farms du DEX, qu’est ce qu’il va choisir entre :

• Déployer ses smart contracts dans le même shard que le DEX et obtenir une vitesse de 6 secondes par transaction (pour les calls synchrones).
• Déployer sur un autre shard et obtenir entre 20 et 50 secondes pour une transaction (call asynchrone).

Evidemment que le projet va choisir la 1ère solution pour obtenir la meilleure vitesse pour ses utilisateurs, et imaginez les autres applications qui vont se déployer mais qui vont utiliser les smart contracts des autres smart contracts pour leur projet et ainsi de suite ça sera sans fin et tout se développera sur un seul shard mais quel est le problème?

A partir d’un moment, ça risque de congestionner le shard, parce que les transactions viendront des différents shards mais les transactions/exécution de smart contract ne se feront que dans un seul shard, ce shard devrait supporter la capacité d’un “supershard” alors que tous les shards sont similaires et donc au final ça congestionnera le shard et il deviendra inutilisable (pareil avec toutes les applications qui sont dessus). 

En gros, vu que Maiar Exchange est sur le shard 1, ça incite les autres applications qui utilisent le DEX a se déployer dans le même shard pour obtenir des transactions plus rapide et à la fin ce shard sera utilisé par beaucoup d’applications ce qui le congestionnera.

Et si on veut utiliser la scalabilité d’Elrond et ajouter un nouveau shard, ça ne servira a rien vu que les transaction seront exécutés dans le shard 1, ça rajoutera juste un endroit de plus pour qui le shard 1 exécutera les contracts calls. Mais alors comment on fait pour utiliser la scalabilité d’Elrond ? On doit rendre les dApps multi-shard afin de ne pas utiliser qu’un seul shard pour utiliser le réseau entier mais comment on fait ?

Vous allez peut-être dire : “Il suffit simplement simplement de déployer les contracts sur les autres shards pour être multi-shard”, alors oui mais c’est un peu plus compliqué. Elrond est une des seules blockchain à faire du state sharding complet (sharding d’état), cela a beaucoup d’avantages comme le fait que les validateurs assignés dans un shard ne doivent garder en mémoire que leur shard plutôt que de stocker toute la blockchain mais ce qui les autres shards et donc il faudrait synchroniser les prix et la liquidité entre les shards.

Il y a des solutions qui sont envisagées par Elrond pour Maiar Exchange, par exemple il compte synchroniser la liquidité et le prix toutes les 5 minutes si le prix en local par rapport aux prix global a changé de plus de 1% grâce à un nouveau mécanisme il suffira d’appeler un “déclencheur” et le SC s’occupera du reste (sans avoir besoin d'oracle), on imagine donc que le SC s’occupera de l’arbitrage cross-shard ?

Mais pour les applications qui n’ont pas besoin de tenir un ratio ou simplement pas besoin de savoir ce qu’il se passe dans les autres shards, elles pourront simplement se déployer sur les 3 shards et puis mettre le même owner pour les 3 contrats par exemple :

Le smart contract de wrapping (le SC pour wrap vos EGLD afin de les utiliser sur le DEX) est multi-shard. Le DEX deviendra multi-shard en 2 parties, d’abord les farms et ensuite la liquidité et donc les swaps (le farming est le plus simple,comme j’ai dis un peu plus tôt, gérer la liquidité entre les shards est un peu plus compliqué), et il n’y aura plus de cross-shard transactions, les transactions vers le DEX seront donc de 6 secondes peu importe le shard. (ce ne sera plus que des transactions intra-shard).

Je pense qu’une fois que le DEX sera multi-shard, Elrond et ses dApps seront en “god mode”, je pense qu’Elrond arrivera à passer la “barrière” que d’autres blockchains comme Solana, BSC et d’autres ont du mal (ce n’est que mon avis) mais en terme de scalabilité (pas uniquement scalabilité d’ailleurs, la scalabilité ne s’arrête pas a des TPS) ça sera difficile de faire mieux. 

PS: On espère avoir des “outils” par la team Elrond afin de rendre plus simple le multi-sharding, par exemple en nous permettant de déployer sur tous les shards en même temps (actuellement, le SC est déployé automatiquement dans le shard de celui qui le deploy, et donc on doit déployer depuis 3 adresses différents sur les 3 shards et puis enfin changer l’owner pour mettre le même pour les 3).

Elrond Wiki

@ElrondWiki

Contributeur

Twitter    Telegram     Site web