Sharding: Une autre possibilité d'évolutivité pour la Blockchain

Le 15 septembre 2022, Ethereum a achevé la Fusion (Merge). C'est un moment historique, Ethereum y a préparé pendant 5 ans, avec 6 reports. En raison d'un développement à long terme et d'une attention générale, beaucoup ont à tort supposé que la fusion apporterait naturellement une meilleure évolutivité, sécurité et durabilité, ce qui n'est pas le cas. La transition de la preuve de travail (PoW) à la preuve d'enjeu (PoS) n'est qu'un changement de "rails et roues", et ne conduit pas directement à une vitesse plus rapide, une plus grande capacité ou des frais réduits. Ce qui peut réellement réaliser ces objectifs, c'est un ensemble complet de solutions : un réseau principal avec des capacités de Sharding associé à des solutions Layer2 améliorant l'évolutivité.

Comme l'a souligné le fondateur d'Ethereum, Vitalik Buterin, le Sharding est une solution d'extensibilité dans le cadre du dilemme de l'évolutivité. En divisant les nœuds du réseau en groupes plus petits, il traite différents ensembles de transactions et permet le traitement parallèle. C'est comme faire ses courses chez Walmart : en ouvrant plusieurs lignes de caisse, cela peut réduire visiblement le temps d'attente et améliorer l'efficacité du paiement.

C'est la logique du Sharding, directe et simple, mais le diable est dans les détails. Le principe et la direction ne sont pas erronés, mais lors de la mise en œuvre, on rencontrera toujours de nombreux problèmes. Cet article vise à clarifier la direction et les dilemmes sur le chemin du "Sharding", en dessinant une carte de l'explorateur du Sharding qui regarde les étoiles tout en restant les pieds sur terre. En comparant les solutions de Sharding existantes, nous espérons trouver des problèmes communs et proposer une direction d'exploration viable : Shardeum et le Sharding dynamique.

I. À propos de "Sharding"

En termes simples, en tenant compte des contraintes du triangle impossible, en prenant Ethereum comme point d'origine du système de coordonnées (, 0), selon deux approches : "verticale" et "horizontale", nous classons les méthodes d'évolutivité actuelles de la Blockchain en deux grandes catégories :

Scalabilité verticale ( : réalisée en améliorant les performances du matériel existant du système. Établir un réseau décentralisé, où chaque nœud du réseau dispose d'une puissance de calcul super, c'est-à-dire que chaque nœud nécessite un matériel "meilleur". Cette méthode est simple et efficace, permettant d'atteindre une amélioration initiale du débit, particulièrement adaptée aux transactions haute fréquence, aux jeux et à d'autres scénarios d'application sensibles à la latence. Cependant, cette méthode d'extension limite le niveau de décentralisation du réseau, car le coût d'exécution des nœuds de validation ou des nœuds complets augmente. Le maintien du niveau de décentralisation est limité par la vitesse de croissance approximative des performances du matériel de calcul ) c'est ce qu'on appelle la "loi de Moore" : le nombre de transistors sur une puce double tous les deux ans, tandis que le coût de calcul est réduit de moitié (.

Scalabilité horizontale)Scaling horizontal(: La scalabilité horizontale a généralement plusieurs approches. L'une consiste, dans le contexte de la Blockchain, à répartir le volume de calcul des transactions d'un écosystème donné sur plusieurs Blockchains indépendantes, chaque chaîne ayant ses propres producteurs de blocs et capacités d'exécution. Cette méthode permet de personnaliser pleinement la couche d'exécution de chaque chaîne, par exemple les exigences matérielles des nœuds, les fonctionnalités de confidentialité, les frais de gas, la machine virtuelle et les paramètres de permission, etc. Une autre solution de scalabilité horizontale est la Blockchain modulaire, qui divise l'infrastructure de la Blockchain en une couche d'exécution, une couche de disponibilité des données)DA( et une couche de consensus. Le mécanisme de modularité de Blockchain le plus courant est le rollup. Une autre approche consiste à diviser une Blockchain en plusieurs fragments, permettant une exécution parallèle. Chaque fragment peut être considéré comme une Blockchain, ce qui signifie que plusieurs Blockchains peuvent être exécutées en parallèle. De plus, il y a généralement une chaîne principale, dont la seule tâche est de maintenir la synchronisation de tous les fragments.

![Explication détaillée de la nouvelle chaîne publique Shardeum : une autre possibilité de Sharding])https://img-cdn.gateio.im/webp-social/moments-7aa1677db6b8128b68accfe04fcda738.webp(

Il convient de noter que les idées d'extension ci-dessus ne sont pas isolées, chaque solution trouve un compromis dans le triangle impossible, associée à la conception de mécanismes d'incitation créés par les forces économiques dans le système, atteignant un équilibre efficace aux niveaux macro et micro.

Pour discuter de "Sharding", nous devons recommencer depuis le début.

En supposant toujours un tel scénario, lors du passage en caisse chez Walmart, afin d'améliorer l'efficacité du paiement et de réduire le temps d'attente des clients, nous avons élargi le nombre de caisses de 1 à 10. Afin d'éviter les erreurs de comptabilité, nous devons établir des règles uniformes :

Premièrement, si nous avons 10 caissiers, comment les répartir pour travailler à quel guichet ?

Deuxièmement, si nous avons 1000 clients en attente, comment décider à quel guichet chaque client doit se rendre pour régler?

Troisièmement, comment résumer les 10 livres de comptes individuels correspondant à ces 10 fenêtres ?

Quatrième, comment prévenir les erreurs des caissiers pour éviter les situations de désaccord dans les comptes ?

Ces quelques questions correspondent en fait à plusieurs problèmes clés dans le Sharding, à savoir :

Comment déterminer à quel sharding les nœuds/validateurs du réseau appartiennent ? C'est-à-dire : comment effectuer le sharding du réseau )Network Sharding(;

Comment déterminer à quel sharding chaque transaction est attribuée ? C'est-à-dire : comment effectuer le sharding des transactions )Transaction Sharding( ;

Comment les données de Blockchain sont-elles stockées dans différents Shardings ? C'est-à-dire : comment effectuer le Sharding d'état )State Sharding( ;

La complexité implique des risques. Sur la base de tout ce qui précède, comment éviter la fragmentation de la sécurité du système entier ?

) 01 Réseau Sharding ###Network Sharding (

Si nous comprenons simplement la Blockchain comme un registre décentralisé, que ce soit le mécanisme de consensus PoS ou PoW, il s'agit de permettre à chaque nœud de revendiquer le droit d'enregistrement selon certaines règles établies, tout en garantissant l'exactitude du registre. Le sharding du réseau signifie qu'il faut une autre règle établie pour diviser le réseau Blockchain en fragments, permettant à chaque fragment de traiter les transactions sur la chaîne tout en minimisant la communication entre eux, c'est-à-dire la règle de regroupement des nœuds.

Cependant, le problème rencontré dans ce processus est que, à mesure que les nœuds internes de la Blockchain sont divisés en différents Shardings, la difficulté et le coût pour les attaquants diminuent fortement. Nous pouvons en déduire que, en supposant que les règles et les résultats de ce processus de regroupement sont fixes et prévisibles, un attaquant souhaitant contrôler l'ensemble du réseau Blockchain n'a besoin que de contrôler de manière ciblée un seul Sharding et de corrompre certains nœuds à l'intérieur de ce Sharding.

Le fondateur de Near, Alexander Skidanov, décrit ainsi ce problème : si une chaîne unique avec X validateurs décide de se diviser en une chaîne de sharding et de répartir les X validateurs en 10 shards, chaque shard n'a alors que X/10 validateurs. Pour compromettre un shard, il suffit de détruire 5,1 % ) 51 % / 10( du nombre total de validateurs. Cela soulève un deuxième point : qui choisit les validateurs pour chaque shard ? Il n'est nuisible de contrôler 5,1 % des validateurs que si tous ces 5,1 % sont dans le même shard. Si les validateurs ne peuvent pas choisir dans quel shard valider, il est très peu probable que les participants contrôlant 5,1 % des validateurs regroupent tous les validateurs dans le même shard, réduisant ainsi considérablement leur capacité à compromettre le système.

Le système de Sharding doit développer un mécanisme pour faire confiance au réseau afin qu'il ne puisse pas inverser ces transactions à partir de Shards externes. Jusqu'à présent, la meilleure réponse pourrait être de s'assurer que le nombre de validateurs dans un Shard est supérieur à un certain seuil minimum, de sorte que la probabilité que des validateurs malhonnêtes dominent un seul Shard soit très faible. La méthode la plus courante consiste à construire un certain degré de randomité non biaisée, en s'appuyant sur des méthodes mathématiques pour minimiser la probabilité de succès des attaquants. Par exemple, Ethereum, la solution d'Ethereum consiste à sélectionner de manière aléatoire des validateurs pour un Shard parmi tous les validateurs, et tous les 6,4 minutes ) la longueur d'un epoch (, les validateurs changent.

Pour le dire simplement, cela consiste à regrouper les nœuds de manière aléatoire, puis à attribuer le travail à chaque groupe de nœuds pour qu'ils valident de manière indépendante.

Cependant, il convient de noter que la randomité dans le Blockchain est un sujet très complexe. Logiquement, le processus de génération de ce nombre aléatoire ne devrait pas dépendre du calcul d'un fragment spécifique. Pour ce calcul, de nombreuses conceptions existantes consistent à développer une Blockchain distincte, maintenant l'ensemble du réseau. Cette chaîne est appelée chaîne Beacon dans Ethereum et Near, chaîne Relay dans PolkaDot, et Cosmos Hub dans Cosmos.

![Explication détaillée de la nouvelle blockchain Shardeum : une autre possibilité de Sharding])https://img-cdn.gateio.im/webp-social/moments-6e8d3331d7d68cb512eb2eb47bd9064d.webp(

) 02 Transaction Sharding ###

Le sharding des transactions fait référence à l'établissement de règles concernant "quelles transactions doivent être attribuées à quels shards", ce qui permet à la fois d'atteindre l'objectif de traitement parallèle et d'éviter l'apparition de problèmes de double dépense. La différence des modèles de livre de la blockchain peut influencer le développement du sharding des transactions.

Actuellement, il existe deux types de méthodes de comptabilité dans le réseau Blockchain, à savoir le modèle UTXO( (Unspent Transaction Outputs) et le modèle de compte / solde. Le premier est typiquement représenté par le BTC, tandis que le second est comme l'ETH.

Modèle UTXO : Dans les transactions BTC, chaque transaction a une ou plusieurs sorties. UTXO fait référence aux sorties des transactions de blockchain qui n'ont pas encore été dépensées et peuvent être utilisées comme entrées pour de nouvelles transactions, tandis que les sorties de transactions déjà dépensées ne peuvent plus être utilisées. Cela est similaire à la situation de paiement et de rendu de monnaie avec des billets de banque, où le client remet un ou plusieurs billets au commerçant, qui lui rend alors un ou plusieurs billets. Dans le modèle UTXO, le sharding des transactions nécessite une communication inter-shard. Une transaction peut inclure plusieurs entrées et plusieurs sorties, sans concept de compte et sans enregistrement de solde. Une manière possible est : en fonction de la valeur d'une certaine entrée de sa transaction, elle est traitée par une fonction de hachage pour devenir une valeur de hachage discrète afin de déterminer vers quel shard les données devraient aller. Comme suit :

Pour s'assurer que les entrées sont placées de manière cohérente dans les bons Shard, les valeurs saisies dans la fonction de hachage doivent provenir de la même colonne. Cette colonne est appelée Shard Key. Ensuite, les transactions générant une valeur de 1 sont placées dans le Shard 1, tandis que celles générant une valeur de 2 sont placées dans le Shard 2. Le inconvénient de cette méthode est que les Shards doivent communiquer pour éviter les attaques de double dépense. Si les transactions inter-Shards sont limitées, cela restreindra la disponibilité de la plateforme, tandis que permettre des transactions inter-Shards nécessitera de peser les coûts de communication inter-Shards contre les bénéfices des améliorations de performance.

Modèle de compte / solde : le système enregistre le solde de chaque compte. Lors d'une transaction, le système vérifie si le compte dispose d'un solde suffisant pour le paiement, similaire à un virement bancaire où la banque enregistre le solde de chaque compte. Une transaction ne peut avoir lieu que si le solde du compte est supérieur au montant à transférer. Dans le modèle de compte / solde, comme une transaction n’a qu’une seule entrée, il suffit de fragmenter la transaction par adresse de l'expéditeur pour garantir que plusieurs transactions du même compte soient traitées dans le même fragment, empêchant ainsi efficacement les doubles dépenses. Par conséquent, la plupart des blockchains utilisant la technologie de sharding sont des systèmes de livre de comptes de type Ethereum.

![Explication détaillée de la nouvelle blockchain Shardeum : une autre possibilité de Sharding])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(

) 03 État Sharding (State Sharding )

L'état de sharding fait référence à la manière dont les données de la blockchain sont distribuées et stockées dans différents shards.

En utilisant toujours notre exemple de file d'attente chez Walmart, chaque fenêtre a un compte, comment leur livre de comptes est-il enregistré ? Si : un client fait la queue dans une file, il enregistre ce compte, par exemple, si le client A est allé à la fenêtre A, alors le lendemain, ce client va à une autre fenêtre de paiement comme la fenêtre B, et la fenêtre B n'a pas les informations de compte antérieures de ce client ###, par exemple concernant les cartes de valeur stockée et d'autres méthodes de paiement (, que faire ? Appeler les informations de compte de ce client à la fenêtre A ?

Le sharding d'état est le plus grand défi du sharding, plus complexe que le sharding réseau et le sharding de transactions mentionnés ci-dessus. En effet, dans un mécanisme de sharding, les transactions sont traitées dans différents shards en fonction des adresses, c'est-à-dire que l'état ne sera stocké que dans le shard correspondant à son adresse. À ce stade, un problème à relever est que les transactions ne se déroulent pas uniquement dans un shard, elles impliquent souvent des transactions inter-shards )Cross-Sharding(.

Considérons un cas de transfert : le compte A transfère 10U au compte B, et l'adresse de A est attribuée au Sharding 1, l'enregistrement de la transaction sera également stocké dans le Sharding 1. L'adresse de B est attribuée au Sharding 2, l'enregistrement de la transaction sera donc stocké dans le Sharding 2.

Une fois qu'A souhaite transférer des fonds à B, une transaction inter-sharding se forme, et le shard 2 devra appeler les enregistrements de transaction passés du shard 1 pour confirmer la validité de la transaction. Si A envoie fréquemment des fonds à B, le shard 2 devra interagir constamment avec le shard 1, ce qui réduira l'efficacité du traitement des transactions. Cependant, si les participants ne téléchargent pas et ne vérifient pas l'historique complet d'un shard spécifique, ils ne pourront pas nécessairement...