Shardeum et le Sharding d'état dynamique : une autre possibilité du Sharding

Le 15 septembre 2022, Ethereum a terminé la tant attendue fusion (Merge). C'est un moment historique, Ethereum s'y préparait depuis 5 ans et a retardé 6 fois. En raison de débogages répétés et d'un développement à long terme, beaucoup ont cru à tort que la fusion apporterait naturellement une meilleure évolutivité, sécurité et durabilité, ce qui n'est pas le cas. La transition de PoW à PoS n'est qu'un changement de voie et de roues, elle n'apportera pas directement une vitesse plus rapide, une plus grande capacité, ou des frais réduits. Ce qui peut réellement réaliser cela, 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é Vitalik Buterin, le fondateur d'Ethereum, le Sharding est une solution d'évolutivité face au dilemme de la scalabilité, en divisant les nœuds du réseau en groupes plus petits, traitant différents ensembles de transactions et réalisant un traitement parallèle. En allégeant la charge de traitement de la grande quantité de données nécessaires pour résumer l'ensemble du réseau, tout comme lorsque nous faisons nos courses au supermarché et que nous choisissons plusieurs caisses pour réduire le temps d'attente et améliorer l'efficacité de la caisse.

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 rencontre toujours de nombreux problèmes. Cet article vise à clarifier la direction et les dilemmes sur le chemin du "Sharding", et à dessiner une carte des explorateurs du Sharding qui regarde les étoiles tout en restant les pieds sur terre. En comparant les solutions de Sharding existantes, nous chercherons à identifier certains 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 de référence (0,0), selon deux approches : "verticale" et "horizontale", nous classons les méthodes d'extensibilité actuelles de la blockchain en deux grandes catégories :

Scaling Vertical ( : Réalisé 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 possède une puissance de calcul supérieure, c'est-à-dire que chaque nœud nécessite un matériel "meilleur". Cette méthode est simple et efficace, permettant 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 au délai. Cependant, cette méthode d'extension limite le niveau de décentralisation du réseau, car le coût de fonctionnement des nœuds de validation ou des nœuds complets augmente. Le maintien du niveau de décentralisation est limité par le taux de croissance approximatif 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, et le coût de calcul est réduit de moitié (.

Horizontal Scaling): L'extension horizontale se décline généralement en plusieurs approches. L'une d'elles, dans le contexte de la blockchain, consiste à 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, les machines virtuelles et les paramètres de permission, etc. Une autre solution d'extension horizontale est la blockchain modulaire, qui divise l'infrastructure de la blockchain en couche d'exécution, couche de disponibilité des données(DA) et couche de consensus. Le mécanisme de modularité blockchain le plus courant est le rollup. Une autre approche consiste à diviser une blockchain en plusieurs fragments, qui s'exécutent en parallèle. Chaque fragment peut être considéré comme une blockchain, ce qui signifie que plusieurs blockchains peuvent s'exécuter 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.

Il convient de noter que les approches d'extensibilité ci-dessus ne sont pas isolées, chaque solution représente un compromis trouvé dans le triangle impossible, en conjonction avec la conception des mécanismes d'incitation créés par les forces économiques du système, afin d'atteindre un équilibre efficace aux niveaux macro et micro.

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

Supposons toujours un tel scénario : lors du paiement dans un supermarché, afin d'améliorer l'efficacité de la caisse et de réduire le temps d'attente des clients, nous passons d'un unique point de paiement à 10 fenêtres de paiement. Pour éviter les erreurs de comptabilité, à ce moment-là, nous devons établir des règles uniformes :

Premièrement, si nous avons 10 caissiers, comment les répartirons-nous pour travailler à quelle caisse ?

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

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

Quatrièmement, comment éviter que les caissiers ne fassent des erreurs afin d'é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 appartiennent les nœuds/validateurs sur l'ensemble du réseau ? C'est-à-dire : comment effectuer le réseau de Sharding (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 la blockchain sont-elles stockées dans différents Sharding ? C'est-à-dire : comment effectuer le State Sharding (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é de l'ensemble du système ?

( 01 Réseau Sharding )

Si nous comprenons simplement la blockchain comme un livre de comptes décentralisé, que ce soit le mécanisme de consensus PoS ou PoW, c'est pour permettre à chaque nœud de rivaliser pour le droit d'enregistrement selon certaines règles établies, tout en garantissant l'exactitude du livre de comptes dans ce processus. Le Sharding fait référence à la nécessité d'une autre règle établie, qui divise le réseau blockchain en fragments, permettant à chaque fragment de traiter les transactions sur la chaîne tout en réduisant au maximum la communication entre eux, et de rivaliser pour le droit d'enregistrement - c'est-à-dire, les règles de regroupement des nœuds.

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

Un fondateur d'une blockchain publique a décrit ce problème de cette manière : si une chaîne unique avec X validateurs décide de se diviser en chaînes de sharding et de répartir X validateurs en 10 shards, chaque shard n'a maintenant que X/10 validateurs. Pour détruire un shard, il suffit de détruire 5.1%###51% / 10( du nombre total de validateurs. Cela soulève le deuxième point : qui choisit les validateurs pour chaque shard ? Il est nuisible de contrôler 5.1% des validateurs seulement lorsque tous ces 5.1% se trouvent dans le même shard. Si les validateurs ne peuvent pas choisir dans quel shard ils effectuent la validation, il est très improbable que les participants contrôlant 5.1% des validateurs placent tous les validateurs dans le même shard, ce qui réduit considérablement leur capacité à nuire au 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 Sharding externes. Jusqu'à présent, la meilleure réponse possible est de s'assurer que le nombre de validateurs à l'intérieur du Sharding est supérieur à un certain seuil minimal, de sorte que la probabilité que des validateurs malhonnêtes dominent un seul Sharding soit très faible. La méthode la plus courante consiste à construire un certain degré de randomité impartiale, 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 aléatoirement des validateurs d'un Sharding à partir de tous les validateurs, et tous les 6,4 minutes ) la durée d'un epoch ( les validateurs changent.

Pour le dire simplement, il s'agit de regrouper aléatoirement les nœuds, puis d'attribuer le travail à chaque groupe de nœuds pour qu'ils vérifient de manière indépendante.

Cependant, il convient de noter que la randomité dans la 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 pour maintenir 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 (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 le problème de double dépense. Les différentes modèles de registre de la blockchain peuvent 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 étant typiquement représenté par le BTC et le second par l'ETH.

Modèle UTXO : Dans les transactions BTC, chaque transaction a une ou plusieurs sorties. UTXO fait référence aux sorties de transactions blockchain qui n'ont pas é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 ressemble à 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 ensuite 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. Un moyen possible est de : traiter une valeur d'entrée de sa transaction avec une fonction de hachage pour générer une valeur de hachage discrète afin de déterminer vers quel shard les données devraient aller.

Pour s'assurer que les entrées sont placées de manière cohérente dans les bons Sharding, les valeurs saisies dans la fonction de hachage doivent provenir de la même colonne. Cette colonne est appelée clé de Shard. Par la suite, les transactions générant une valeur de 1 sont réparties dans le Sharding 1, tandis que celles générant une valeur de 2 vont dans le Sharding 2. Cependant, le inconvénient de cette méthode est que les Sharding doivent communiquer entre eux pour éviter les attaques par double dépense. Si les transactions inter-Sharding sont limitées, cela restreindra la disponibilité de la plateforme, tandis que si les transactions inter-Sharding sont autorisées, il faudra peser le coût de la communication inter-Sharding par rapport aux bénéfices en termes de performance.

Modèle de compte/solde : Le système enregistre le solde de chaque compte. Lorsqu'une transaction est effectuée, 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. La transaction ne peut être effectuée que si le solde du compte est supérieur au montant du virement requis. Dans le modèle de compte/solde, étant donné qu'une transaction n'a qu'une seule entrée, il suffit de fragmenter la transaction selon l'adresse de l'expéditeur pour garantir que plusieurs transactions du même compte soient traitées dans le même fragment, ce qui empêche efficacement la double dépense. Par conséquent, la plupart des blockchains utilisant la technologie de Sharding fonctionnent comme un système de livre de comptes de type Ethereum.

( 03 État Sharding )State Sharding (

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

En continuant avec notre exemple de la file d'attente au supermarché, chaque comptoir a une comptabilité. Comment leur livre de comptes est-il enregistré ? Si : un client se met dans une file, il est enregistré dans ce livre, par exemple, si le client A se rend au comptoir A, alors le lendemain, ce client se rend à un autre comptoir de paiement, par exemple, le comptoir B, et le comptoir B n'a pas d'informations sur le compte précédent de ce client ), par exemple concernant les méthodes de paiement comme la carte prépayée, que faire ? Appeler les informations de compte de ce client au comptoir A ?

Le partitionnement d'état est le plus grand défi du sharding, plus délicat que le partitionnement de réseau et le partitionnement de transaction mentionnés ci-dessus. En effet, dans un mécanisme de sharding, les transactions sont traitées dans différents shards selon les adresses, c'est-à-dire que l'état ne sera stocké que dans le shard correspondant à son adresse. À ce stade, un problème auquel il faut faire face est que les transactions ne se déroulent pas uniquement dans un shard, mais impliquent souvent un ###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 à Sharding 1, l'enregistrement de la transaction sera également stocké dans Sharding 1. L'adresse de B est attribuée à Sharding 2, l'enregistrement de la transaction sera donc stocké dans Sharding 2.

Une fois qu'A souhaite transférer des fonds à B, une transaction inter-Sharding sera formée, Sharding 2 devra appeler les enregistrements de transactions passés de Sharding 1 pour confirmer la validité de la transaction. Si A envoie fréquemment des fonds à B, Sharding 2 devra interagir continuellement avec Sharding 1, ce qui réduira l'efficacité du traitement des transactions. Cependant, si on ne télécharge pas et ne vérifie pas...